Feature Request: Image Outline

Hi,
Just a feature request.
I think it would be really useful to have a coloured border. Would be a nice dynamic feature.
Great coding. :)

@kleisauke : Maybe add something like &border=9 for 9 pixels of border, or &border=9,6 where 9 is top/bottom and 6 is left/right (like CSS).
I think it would just add to the image dimension? So &w=300 with &border=9 would be 318 pixels wide.

This is a slippery slope, then you'll want a param &boxSizing=borderBox to ensure that w=300 with a border=9 stays 300 (sarcasm, don't worry.)
I think for most implementations of the API, CSS (web) or native-level borders (native) can be added by users; blurring, masking, etc., are great image serving CDN but I think borders might be going overboard. Next feature request will be shadows, otherwise. 👐

That's true, let's give it some consideration. @garycarlyle : What would be the user case? Could you give an example of the result you'd like? For solid borders CSS seems to be more appropriate indeed.

Taking another look, and I still agree with @AnandChowdhary on this issue. But if there are any compelling user cases, let us know, and we will reconsider this!

Borders are very practical, particularly when dealing with screen shots, and they cannot be compared to shadows or other fancy things. I am really missing this feature.
A typical use case is posting screen shots on bulletin boards. If bulletin board background and screen shot background are in the same colour (very often both are white), you really want to add some border in order to separate posted picture from the rest of your post.
Yes, there are alternatives. For example, one can make a table with a single cell just to have a border around that cell. But on some bulletin boards tables may be unavailable, on some other they may be borderless, and on some others simply cumbersome in use. Even if you cannot use tables, you can always download a screenshot, add a border in some image editor, and re-upload it to a hosting service. Yes, that would work, but I thought avoiding it is one of the goals of this project.
I've provided a use case. Hence, I suggest re-opening this issue.
Regarding what new parameters are needed, border colour is enough for my use case. Border thickness is not critical, but won't hurt either, especially that users will surely look for it in docs. My suggestion is to support only these two options. Obviously, default setting should be no border. If border thickness is set but border colour is not, then it should be black. If border colour is set but thickness is not, then it should be 2px. Doesn't really matter if w=300 parameter would mean picture width including border or excluding it, but it would be good to document this.

Let's rediscuss this, as we now do have use cases.

Sorry I have not logged into this account for ages. Was really cool of you to consider this. I think my use case was when using images on a website in a scenario that you would want border but would be more practical doing it with this rather than CSS. I cant remember why I would have liked that rather than CSS but I must of had a reason. :)
Actually @skalee seems to have covered what I think was on my mind at the time.

I'd be interested in this feature. I'm using weserv to generate circle GitHub avatars in a Github README, which is a case where I cannot use CSS (since Github strips it from <img> tags). It would be cute to include a light grey border around the circle mask, similar to how Github itself displays circle avatars.

https://github.com/mmcloughlin/avo#adopters


micsthepick: Blacklist Nitridex

micsthepick requests the blacklist of the keyword Nitridex. See the Metasmoke search here and the Stack Exchange search here.

Nitridex has been seen in 47 true positives, 0 false positives, and 0 NAAs.

!!/approve

Coverage remained the same at 65.093% when pulling 90c4796b47d20ef7f5cb72f0b6f81d9951def6a2 on auto-blacklist-1520735716.1118858 into db867e1d5bbdfe58fe1638450713fa27e1f75941 on master.


how to connect with oracle or postgres or mysql database

i am using vanna jupyter notebook except that i am using this for connection...
db_user = "root"
db_password = "aman"
db_host = "localhost"
db_name = "jeevika"
cs=f"mysql+pymysql://{db_user}:{db_password}@{db_host}/{db_name}"
vn.connect_to_sqlite(cs)
...but i am getting this error....---------------------------------------------------------------------------
InvalidSchema                             Traceback (most recent call last)
 in <cell line: 1>()
----> 1 vn.connect_to_sqlite(cs)
5 frames
/usr/local/lib/python3.10/dist-packages/requests/sessions.py in get_adapter(self, url)
792
793         # Nothing matches :-/
--> 794         raise InvalidSchema(f"No connection adapters were found for {url!r}")
795
796     def close(self):
InvalidSchema: No connection adapters were found for 'mysql+pymysql://root:aman@localhost/jeevika'

Please see the instructions here under "Other Database"
https://vanna.ai/docs/other-database-openai-vanna-vannadb.html


New recipe/diagnostics: recipe_deangelis_for_gmdpart4.yml for Axels GMD Paper

Before you start, read CONTRIBUTING.md and the guide for diagnostic developers.
Please discuss your idea with the development team before getting started, to avoid disappointment later. The way to do this is to open a new issue on GitHub. If you are planning to modify an existing functionality, please discuss it with the original author(s) by tagging them in the issue.

Tasks

[x] Create an issue to discuss what you are going to do, if you haven't done so already (and add the link at the bottom)
[x] Give this pull request a descriptive title that can be used as a one line summary in a changelog
[x] Make sure your code is composed of functions of no more than 50 lines and uses meaningful names for variables
[x] Circle/CI tests pass. Status can be seen below your pull request. If the tests are failing, click the link to find out why.
[x] Preferably Codacy code quality checks pass, however a few remaining hard to solve Codacy issues are still acceptable. Status can be seen below your pull request. If there is an error, click the link to find out why. If you suspect Codacy may be wrong, please ask by commenting.
[x] Please use yamllint to check that your YAML files do not contain mistakes
[x] Add documentation for the recipe to the doc/sphinx/source/recipes folder and add a new entry to index.rst
[x] Add provenance information

If you need help with any of the tasks above, please do not hesitate to ask by commenting in the issue or pull request.

Closes #1575

Hi Javier,
thanks for looking at the flake 8 errors in deangelisf2ext.py! It would be good if you could first look at deangelisf3f4.py. At deangelisf1b.py I currently work on a larger change (to not restrict it to certain model experiments) and deangelisf2ext.py I still needs provenance and possibly some other changes (and is the least important for the paper).

Ok. I will focus in deangelisf3f4.py. Let me know if you need help with something else

Ok, thanks! I'll have to leave soon for today, but I hope I manage to finish the change for deangelisf1b.py late this evening.

deangelisf1b.py is ready for testing, but with the models given in the recipe now, I'd expect trouble on DKRZ with the derived variables.
I discovered a small issue on deangelisf3f4.py with the test I put in yesterday, I now try to solve that and then I try to reduce the models (for both deangelisf1b.py and deangelisf3f4.py) to the ones, which should work on DKRZ without extra links

I discovered a small issue on deangelisf3f4.py with the test I put in yesterday, I now try to solve that and then I try to reduce the models (for both deangelisf1b.py and deangelisf3f4.py) to the ones, which should work on DKRZ without extra links

The delta not being displayed in the pictures. I already solved that. I'm uploading it along with a clearer dict definition for the models.
By the way, your code looks quite good

I also moved the main so it is the first function you find when opening the file.

Thanks! For me for deangelisf3f4.py the check for not more than two model experiments leads to an error now, when I test on many models. I guess there is something wrong with a model in the long version of the recipe. I try to clean it up to working models now.

Thanks! For me for deangelisf3f4.py the check for not more than two model experiments leads to an error now, when I test on many models. I guess there is something wrong with a model in the long version of the recipe. I try to clean it up to working models now.

I just tested with one

I just tested with one

I tried with 20 this morning, but I guess the reason is actually, that the observations have  "exp = None" to the config. I probably best remove the thing I added yesterday:
if len(available_exp) != 2:         raise ValueError("The diagnostic needs two model experiments: " +                          "pre industrial control and 4 times CO2.")
I think you don't have that in your version and it would also create trouble if combining CMIP5 and CMIP6 in any way.

I just tested with one

I tried with 20 this morning, but I guess the reason is actually, that the observations have  "exp = None" to the config. I probably best remove the thing I added yesterday:
It would also create trouble if combining CMIP5 and CMIP6 in any way.

I tried to put the two checks, which are working into your version of deangelisf3f4.py
Unfortunately now I have the remaining prospector message:

esmvaltool/diag_scripts/deangelis15nat/deangelisf3f4.py
Line: 49
mccabe: MC0001 / main is too complex (12)

I'll test now if it is running and then try to get rid of the message.

deangelisf3f4.py is running, (tested with 20 models and without special links on DKRZ), I try now to get rid of the prospector message.

Fixed prospector issue of deangelisf3f4.py, now I have to leave for today (I start another test on deangelisf3f4.py and deangelisf1b.py on DKRZ, hope they work now, but one never knows :) ).

With 19 models deangelisf3f4.py. and deangelisf1b.py are working on Mistral. I'll include example figures to the documentation now and then try to solve the provenance and prospector issues for deangelisf2ext.py

Documentation is updated now. Since everything is ready expect the deangelisf2ext.py script (provenance and my favorite trouble with prospector about too many variables), should I remove this diagnostic now (its figures are not used in the paper) and add it in a new pull request later? I guess I'd need 1-2 days to finish it.

If the diagnostic is working you can leave it in and open an issue that provenance needs to be fixed for it.

Running some tests now...

When trying to run this recipe, I get the following error message:
2020-04-30 00:27:30,406 [34789] INFO     deangelisf2ext.py,347  Saving analysis results to /mnt/lustre02/work/bd0854/b380103/esmvaltool_output/recipe_deangelis15nat_20200429_180349/work/deangelisf2ext/deangelisf2ext/fig2a.nc Traceback (most recent call last):   File "/mnt/lustre02/work/bd0854/b380103/ESMValTool/esmvaltool/diag_scripts/deangelis15nat/deangelisf2ext.py", line 818, in <module>     main(config)   File "/mnt/lustre02/work/bd0854/b380103/ESMValTool/esmvaltool/diag_scripts/deangelis15nat/deangelisf2ext.py", line 812, in main     plot_slope_regression(cfg, data_dict)   File "/mnt/lustre02/work/bd0854/b380103/ESMValTool/esmvaltool/diag_scripts/deangelis15nat/deangelisf2ext.py", line 365, in plot_slope_regression     iris.save(cube_to_save_vars(list_dict), target=diagnostic_file)   File "/mnt/lustre02/work/bd0854/b380103/ESMValTool/esmvaltool/diag_scripts/deangelis15nat/deangelisf2ext.py", line 276, in cube_to_save_vars     units=list_dict["name"][iii]['units'])])   File "/mnt/lustre02/work/bd0854/b380103/miniconda3/envs/esmvaltool/lib/python3.7/site-packages/iris/cube.py", line 774, in __init__     self.var_name = var_name   File "/mnt/lustre02/work/bd0854/b380103/miniconda3/envs/esmvaltool/lib/python3.7/site-packages/iris/_cube_coord_common.py", line 270, in var_name     raise ValueError(emsg.format(name)) ValueError: 'dlvp/dtas' is not a valid NetCDF variable name.
@katjaweigel Could you possibly take a look? I guess this might be relatively easy to fix?!

@axel-lauer Thanks for your test, message, I'll run a test now.

Unfortunately I need a new Core, that could slow it down since there is an recent issue on core installation ...

Are you referring to https://github.com/ESMValGroup/ESMValCore/issues/624 ?
This is only when installing in development mode, if you install ESMValCore as a dependency in the standard way it should not be an issue.

@mattiarighi thanks, but I usually use development mode, but for me
pip install -e '.[develop]' worked, see other issue

@axel-lauer I changed the variable names for the netCDF files, can you chek if theses work for you (here is runs with both versions)?

Rerunning the test of deangelisf2ext.py...

All tests have been successful now! The plots look good. Ready to be merged!


Opening EGshelfIIseas2km_ASR bug

od = ospy.open_oceandataset.from_catalog('EGshelfIIseas2km_ASR')
gives:
ValueErrorTraceback (most recent call last)
 in
1 # Open the oceandataset
----> 2 od = ospy.open_oceandataset.from_catalog('EGshelfIIseas2km_ASR')
3 #od = ospy.open_oceandataset.from_catalog('get_started')
4
5 # Report some basic information on the oceandataset
~/workspace/Storage/Thomas.Haine/persistent/OceanSpy_dev/oceanspy/oceanspy/open_oceandataset.py in from_catalog(name, catalog_url)
199
200     # Merge
--> 201     ds = _xr.merge(datasets)
202
203     # Consistent chunking
~/miniconda3/lib/python3.7/site-packages/xarray/core/merge.py in merge(objects, compat, join)
530         for obj in objects]
531
--> 532     variables, coord_names, dims = merge_core(dict_like_objects, compat, join)
533     # TODO: don't always recompute indexes
534     merged = Dataset._construct_direct(
~/miniconda3/lib/python3.7/site-packages/xarray/core/merge.py in merge_core(objs, compat, join, priority_arg, explicit_coords, indexes)
443
444     coerced = coerce_pandas_values(objs)
--> 445     aligned = deep_align(coerced, join=join, copy=False, indexes=indexes)
446     expanded = expand_variable_dicts(aligned)
447
~/miniconda3/lib/python3.7/site-packages/xarray/core/alignment.py in deep_align(objects, join, copy, indexes, exclude, raise_on_invalid)
215
216     aligned = align(*targets, join=join, copy=copy, indexes=indexes,
--> 217                     exclude=exclude)
218
219     for position, key, aligned_obj in zip(positions, keys, aligned):
~/miniconda3/lib/python3.7/site-packages/xarray/core/alignment.py in align(*objects, **kwargs)
144                     'aligned because they have different dimension size(s) %r '
145                     'than the size of the aligned dimension labels: %r'
--> 146                     % (dim, unlabeled_sizes, labeled_size))
147
148     for dim in unlabeled_dim_sizes:
ValueError: arguments without labels along dimension 'Z' cannot be aligned because they have different dimension size(s) {55} than the size of the aligned dimension labels: 216

OK, I see the name of the dataset changed. od = ospy.open_oceandataset.from_catalog('EGshelfIIseas2km_ASR_full') works.
I was confused because od = ospy.open_oceandataset.from_catalog('EGshelfIIseas2km_ASR') gives "Opening EGshelfIIseas2km_ASR." immediately then waits ~50secs before throwing the error message. Parse the input string first and filter the errors straightaway?

Yes I agree. Waiting 1min because of a typo is annoying and confusing. I've added a check on the datasets stored on SciServer.


Screenshot without saving the image

Hello.
Is it possible to make a screenshot without saving the image? I mean, get the image as base64

Hello,
It is not possible as-is, as browsers launched in headless mode directly generate an image file.
However, if you feel like tinkering, you may try to use html2image with Chrome CDP like so:
from html2image import Html2Image

with Html2Image(browser='chrome-cdp') as hti:
    my_base64_data = hti.screenshot(url='https://python.org', save_as='python_org.png')

But you'll have to modify the screenshot method a tiny bit (locally, on your machine):
https://github.com/vgalin/html2image/blob/e8816ebbde3318e3a94efed16f2884f7e56cea70/html2image/browsers/chrome_cdp.py#L143-L153
Instead of writing the base64 data to a file, you can just add a return img_data instead.

Please note that Chrome CDP support is undocumented, on stand-by, and can sometimes break. If you're not familiar with the principle behind the Chrome DevTools Protocol, you can think of it as:

Launching a browser with a special parameter that makes it open a WebSocket server
Sending instructions to the server to control the browser

When using the with context manager like so:
with Html2Image(browser='chrome-cdp') as hti:
    ...

A CDP server is opened behind the scenes, so if you want to take multiple screenshots, it is better to stay in the with block to keep the server open and avoid the startup delay before every screenshot.


wrong output for a custom yolov4 model trained and tested within tlt

I trained a resnet34_yolov4 model with tlt and tested the exported model inference via the yolov4 Jupiter notebook and it works fine. However, when testing with deepstream, the model output is completely wrong. The output is very small dimensions (x,y values of < 10 and w,h values of < 1 (always almost 0 or a very small number)) with wrong classes predictions. Is this caused by the custom batched NMS functions?

The issue has been solved.
The problem was that I used to copy this file https://github.com/NVIDIA-AI-IOT/deepstream_tlt_apps/blob/master/TRT-OSS/x86/TRT7.2/libnvinfer_plugin.so.7.2.2 to replace the "libnvinfer_plugin.so*" directly without building TRT-OSS again. I assumed that it would work because my version is also 7.2.2, and actually it did succeed in running the model but the output was all wrong and weird.
After I follow the steps from https://docs.nvidia.com/metropolis/TLT/tlt-user-guide/text/object_detection/yolo_v4.html#tensorrt-oss-on-x86, now it works as expected.


v6.0.0 contains .NET SDK 6.0.418 instead of the latest LTS (8.0.x)

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
As can be seen from this build log, .NET SDK 6.0.418 is present (and .NET SDK 8.0.x is not).
Expected Behavior
I would expect .NET SDK 8.0.x to be present. Take note of https://github.com/super-linter/super-linter/pull/5047
Super-Linter version
v6.0.0

Relevant log output
6.0.418 [/usr/share/dotnet/sdk]
  ------
  2024-02-07 09:47:23 [INFO]   Command output for CSHARP:
  ------
  The command could not be loaded, possibly because:
    * You intended to execute a .NET application:
        The application 'format' does not exist.
    * You intended to execute a .NET SDK command:
        A compatible .NET SDK was not found.

  Requested SDK version: 8.0.100
  global.json file: /github/workspace/global.json

  Installed SDKs:

  Install the [8.0.100] .NET SDK or update [/github/workspace/global.json] to match an installed SDK.

  Learn about SDK resolution:
  https://aka.ms/dotnet/sdk-not-found

Steps To Reproduce

Specify .NET SDK 8.x in global.json:{
  "sdk": {
    "version": "8.0.100",
    "rollForward": "latestMajor"
  }
}

Try and use super-linter v6.0.0

Anything else?
No response

Hi!
I think the issue is that we install the .NET SDK using the channel option, that works as follow:
-Channel|--channel <CHANNEL>

Specifies the source channel for the installation. The possible values are:

STS: The most recent Standard Term Support release.
LTS: The most recent Long Term Support release.
Two-part version in A.B format, representing a specific release (for example, 3.1 or 6.0).
Three-part version in A.B.Cxx format, representing a specific SDK release (for example, 6.0.1xx or 6.0.2xx). Available since the 5.0 release.

Supported LTS and STS versions are available here.
As you noted, in #5047 we set it to LTS (it was set to STS before), but the behavior is the similar.
I think we should just set it to a fixed value (8.0 in this case), instead of selecting a channel.
Also, it would make sense to have a global.json defined for our test environment so we can catch this issue when building the image.

@ferrarimarco please see https://github.com/super-linter/super-linter/pull/5244


Confused about select! and tokio::timer::Delay

futures-preview 0.3
tokio 0.2
Code A
    let mut heartbeat = timer::delay_for(Duration::from_secs(3)).fuse(); // here
    let mut heartbeat2 = timer::delay_for(Duration::from_secs(15)).fuse(); // here

    loop {
        select! {
            _ = heartbeat => println!("send heartbeat"),
            _ = heartbeat2 => println!("send heartbeat2"),
            complete => break,
        }
    }

Code B

    let mut heartbeat = timer::delay_for(Duration::from_secs(3));
    let mut heartbeat2 = timer::delay_for(Duration::from_secs(15));

    loop {
        select! {
            _ = heartbeat => println!("send heartbeat"),
            _ = heartbeat2 => println!("send heartbeat2"),
            complete => break,
        }
    }

They are almost the same, but code A works good, and code B can print nothing.
According to my understanding, The Delay has already implemented the FusedFuture trait, but why I still need to use the fuse to convert it. Can anybody explain it?

This is a Tokio bug, the FusedFuture impl for Delay is incorrect

Yeah, is_elapsed here isn't the correct check. Even though the timer has elapsed, the future may not yet have yielded an output.


Docker: Database doesn't exist, creating a new one

Unifi Protect Backup version: 0.8.1
Unifi Protect version: 2.2.6
Python version:
Operating System:
Are you using a docker container or native?: Docker

Description
When running version 0.8.0 or 0.8.1 in Docker, I get the following error when starting the container:
2022-12-04 22:44:24 [   INFO    ] unifi_protect_backup.unifi_protect_backup  :	Database doesn't exist, creating a new one
2022-12-04 22:44:24 [   ERROR   ] asyncio                                    :	Task exception was never retrieved
future: <Task finished name='Task-1' coro=<run.<locals>.new_coro() done, defined at /usr/lib/python3.10/site-packages/aiorun.py:227> exception=OperationalError('unable to open database file')>
Traceback (most recent call last):
  File "/usr/lib/python3.10/site-packages/aiorun.py", line 237, in new_coro
    await coro
  File "/usr/lib/python3.10/site-packages/unifi_protect_backup/unifi_protect_backup.py", line 296, in start
    self._db = await create_database(self._sqlite_path)
  File "/usr/lib/python3.10/site-packages/unifi_protect_backup/unifi_protect_backup.py", line 168, in create_database
    db = await aiosqlite.connect(path)
  File "/usr/lib/python3.10/site-packages/aiosqlite/core.py", line 137, in _connect
    self._connection = await future
  File "/usr/lib/python3.10/site-packages/aiosqlite/core.py", line 102, in run
    result = function()
  File "/usr/lib/python3.10/site-packages/aiosqlite/core.py", line 397, in connector
    return sqlite3.connect(loc, **kwargs)
sqlite3.OperationalError: unable to open database file

Reverting back to image: ghcr.io/ep1cman/unifi-protect-backup:0.7.4 allows the container to run successfully again.
Anything I could try to get the database to be created within the container?

Could you post the part of the log where it shows all the config settings, specifically the SQLite path? (Redact anything you don't want to share)
Also, as of 0.8.0 you will need to add an addition volume mount for the database file (check the reader) to persist the database.
I suspect the issue here is that the directory /config/database doesn't exist unless said volume mount is added.

Yep, that was it. Once I specified a volume mount for the database the container started up as expected, and the database was created. The container had auto-updated from version 0.7.4, and this is what had made it fail when it was recreated at 0.8.0/0.8.1. Thanks for the heads up!

BTW the new functionality to back up the missed video files till the retention period allowed me to get the files that I missed while my Docker container was down. Really, really great addition here!


Documentation and ReadtheDocs

Version Bump to 0.1.7

Codecov Report
All modified lines are covered by tests :white_check_mark:

Comparison is base (2fcf55d) 83.23% compared to head (58a051d) 83.23%.
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #24   +/-   ##
=======================================
  Coverage   83.23%   83.23%
=======================================
  Files          35       35
  Lines        2964     2964
=======================================
  Hits         2467     2467
  Misses        497      497

Files
Coverage Δ

src/nuropb/contexts/context_manager.py
94.66% <ø> (ø)

src/nuropb/rmq_api.py
79.45% <ø> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


error: Required feature `init-local' was not provided

I get the below error at load time. Strange thing is that I do have init-local.el in ../lisp
The file does load as the keybinding defined in that file are active upon load.
What could be the issue?
Warning (initialization): An error occurred while loading /home/XXXX/.emacs.d/init.el':                                                                                error: Required feature init-local' was not provided

You probably created an init-local.el file, but forgot to include a (provide 'init-local) statement in it as directed.

That will do it.

Great!


If yarn is not installed running rake yarn:install fails silently

Agree
Can you submit pr ?

sure

@rsaphala Thanks
Closed in #1690


Add API for style insertion point

Related: #860 #1253
Specificity in styled-components is supported through repeated selectors, i.e:
const Button = styled(Button)`
   &&&& {
     display: block;
   }
`

This works but it is rather bizzare, is tedious to write, and adds code smell, especially if this needs to be done for every component in a library (such as material-ui)
My proposal is to allow something like jss insertion points, which defines where the styles are injected into the DOM.
What will it allow you to do that you can't do today?
It will allow me to write the above as:
const Button = styled(Button)`
   display: block;
`

While it may seem simple enough, consider that something like this can appear a LOT in a single app.
How will it make current work-arounds straightforward?
(Above example)
Would love to hear if you guys are open to adding something like this.
What potential bugs and edge cases does it help to avoid?
It should prevent unnecessary repeated selectors - which in turn should avoid 'selector races' similar to 'z-index races' where the z-index grows too much arbitrarily. Since repeated selectors becomes the norm, extending components like this might entail just adding more and more ampersands.

See #1102.


http: rename http client logger

Redpanda uses this logger name for its http client and we choose to change the logger name in Seastar to avoid duplicate logger registration exceptions.

I guess we have our own http client, so this is unlikely to be used.

Right. With shared libraries the duplicate registration occurs. With static build clang seems to be smart enough to know that we don't ever invoke it and doesn't static initialize it so we don't see the issue.


Feature/wdl file prov for dirs

This fixes WDL file prov during launch so that it does not fail if an input file is a directory. Instead it just creates an associated directory in the directory where we put cromwell input (cromwell-input/hash/).
When copying files/dirs to the cromwell-input dir, we will also maintain the directory structure, as before we just put all of the input files into the same directory.

[x] Check that you pass the basic style checks and unit tests by running mvn clean install

Changes Unknown when pulling 98181ec50b13ff3d0085a21bf0f2be1779957e49 on feature/wdl_file_prov_for_dirs into ** on develop**.


Remove istio config manifests in /hack for istio versions v1.7 to v1.9

The istio version v1.7 and v1.9 fail to install on Kubernetes v1.24 which is what we e2e test in.
See https://github.com/cert-manager/istio-csr/pull/163.
Rather than trying to play a dance with running different kube versions with different istio versions, let's just drop support for v1.9 and below istio-csr. v1.9 has been EOL since 2022-10 anyway.
/hold
Until we are ready to release so people who are using the current istio-csr version can still find the config.

/retest

From looking at istio's supported releases the only version which actually explicitly supports + tests Kubernetes 1.24 is 1.14!
It looks like our test matrix is a little off if we're using 1.24 for everything?
I suppose that's a tangent for this PR though!

/override pull-cert-manager-istio-csr-k8s-v1-24-istio-v1-7
(looks like this test was removed from our tests - maybe overriding will make it go away here)

/override pull-cert-manager-istio-csr-k8s-v1-24-istio-v1-8
(as above)

We're good to unhold this now :slightly_smiling_face:
/unhold


Fix typos

What kind of change does this PR introduce?
Fix some typos

Did you add tests for your changes?
N/A

If relevant, link to documentation update:
N/A

Summary
N/A

Does this PR introduce a breaking change?
Nope

Other information
N/A

Thanks


Add header title / logo for hoster or faculty

User Story
As a:
User | Hoster
I want:
to see who host the geli page or to which faculty does it belongs.
so that:
that i know that I'm on the right page
Acceptance criteria:

[ ] add a optional string in the header for the faculty or hoster
[ ] add a optional icon for the logo of the faculty or hoster

Additional info:

Setting a textual logo under or next to our geli logo.

This can be closed. It was solved through #216


"fileDropEnabled" generates problems when "true" for dragging and dropping elements in the HTML - The same goes for the "Draggable" and "VueDraggableNext" components [bug]

Describe the bug
Video showing the bug in action - On YouYube

I'm having a problem that I'm not finding a solution to, when I enable "fileDropEnabled" in tauri.config.json, I can get the full path of my files, the problem is that when this function is active, I can no longer use components like "Draggable " or "VueDraggableNext", I tested with both and have the same problem.
In the video above I'm using "Draggable":
import Draggable from 'vuedraggable'

Maybe there is a conflict between the native drag and drop and the "fileDropEnabled" feature, I tried several ways to get around this problem and I can't.
As unfortunately native drag and drop does not allow getting the full path of the file (not that I have found a way), I am dependent on a solution to set "fileDropEnabled" to "true" to still allow dragging and dropping files.
Reproduction

Start a new application with Tauri and Vue 3 (I don't know if this problem happens in react too).
Install any drag and drop component:

npm i vuedraggable

create a simple example like the ones in the official documentation:
https://www.npmjs.com/package/vuedraggable
Test with "fileDropEnabled" as "false" to make sure everything is working.
enable "fileDropEnabled" in tauri.config.json and you will see that after doing this you will not be able to move any more elements in the list

Expected behavior
The expected behavior would be that the "fileDropEnabled" tool works without affecting native functions or native events of the application
Full tauri info output
[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 120.0.2210.121
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.69.0 (84c898d65 2023-04-16)
    ✔ cargo: 1.69.0 (6e9a83356 2023-04-12)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
    - node: 18.16.0
    - yarn: 1.22.19
    - npm: 9.5.1

[-] Packages
    - tauri [RUST]: 1.4.1
    - tauri-build [RUST]: 1.4.0
    - wry [RUST]: 0.24.3
    - tao [RUST]: 0.16.2
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.9

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: http://localhost:1420/
    - framework: Vue.js
    - bundler: Vite

Stack trace
No response
Additional context
No response

This is indeed expected behavior (that we don't want either), see https://github.com/tauri-apps/wry/issues/904. We still did not find a solution that we're happy with.
There is a user-side workaround by abusing the webview's NewWindowRequested event that i've wanted to showcase for ages but never got to it. I'll see if i can get to it over the weekend, maybe it's usable for you.

Este é realmente um comportamento esperado (que também não queremos), consulte tauri-apps/wry#904 . Ainda não encontramos uma solução que nos satisfaça.
Há uma solução alternativa do lado do usuário, abusando do evento NewWindowRequested do webview que eu queria mostrar há muito tempo, mas nunca consegui. Vou ver se consigo fazer isso no fim de semana, talvez seja útil para você.

Thank you very much @FabianLars for all your help, any alternative solution, even temporary, is found, let us know. Because these components like Draggable help a lot with the user experience and unfortunately they will have to be inactive because I need "fileDropEnabled" to capture the entire path of files dragged via 'tauri://file-drop'.
I will leave in my application an alternative solution to move the item using up and down arrows.

This is indeed expected behavior (that we don't want either), see tauri-apps/wry#904. We still did not find a solution that we're happy with.
There is a user-side workaround by abusing the webview's NewWindowRequested event that i've wanted to showcase for ages but never got to it. I'll see if i can get to it over the weekend, maybe it's usable for you.

Would like to see the workaround as well, any help is appreciated!

+1

+1

+1

+11


Meeting Minutes November 26th

To do:

Complete figure captions (Kiran)
Output dataframe with model performance and interpret model performance (Nick)
Small description of all the scripts in the README file (Rakesh)
Create proposal.md file and make the release (Lynn)

Proof-reader: Lynn

Update script usage in README.
https://github.com/UBC-MDS/abalone_age_classification/pull/60

proposal.md file created and saved under docs/
Overwrite proposal section on README file according to Milestone 2 requirements
fix link to Milestone 2 Report on README file
Removed EDA figures from the EDA section on README file since we already have a link that points to the detailed EDA file

update test script to include an output table
add train and test plots to Milestone 2 Report
add model interpretation to the report


Update pphelper.rb for depens_on and zap

Update pphelper.rb for depens_on and zap

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

fixed


Adding a watched file in module: changing the file causes server to restart but still getting old contents

Environment

Operating System: Linux
Node Version:     v18.18.0
Nuxt Version:     3.8.2
CLI Version:      3.10.0
Nitro Version:    2.8.1
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools
Runtime Modules:  -
Build Modules:    -

Reproduction
https://stackblitz.com/edit/nuxt-starter-aa9kax?file=data%2FhelloData.ts

Run the app
The console logs: data: change  me
Modify the data variable in helloData.ts and save
Nuxt server restarts and the console logs the same thing: data: change me

expected behavior:
After changing the data variable and saving, the console should log the updated value.
Describe the bug
I am creating a Nuxt module where I need the server to restart when a file changes, so I have added it to the nuxt.options.watch list, now when changing the contents of that file the server restarts as expected, but I am still getting the old contents as described above, am I missing something?
// modules/hello.ts

import { createResolver, defineNuxtModule } from 'nuxt/kit';
import { data } from '../data/helloData';

export default defineNuxtModule({
  meta: {
    name: 'hello',
  },
  async setup(resolvedOptions, nuxt) {
    const { resolve } = createResolver(import.meta.url);
    nuxt.options.watch.push(resolve('../data/helloData.ts'));

    console.log('data:', data);
  },
});

Any help is appreciated, thanks!
Additional context
No response
Logs
No response

I was able to get the updated content by calling Nuxt's restart hook with {hard: true} option, not sure if this is the correct way of doing it:
https://stackblitz.com/edit/nuxt-starter-r3jt6p?file=data%2FhelloData.ts,modules%2Fhello.ts
export default defineNuxtModule({
  meta: {
    name: 'hello',
  },
  async setup(resolvedOptions, nuxt) {
    const { resolve } = createResolver(import.meta.url);
    nuxt.options.watch.push(resolve('../data/helloData.ts'));

    nuxt.hook('builder:watch', (ev, path) => {
      if (path.includes('helloData.ts')) {
        nuxt.callHook('restart', { hard: true });
      }
    });

    console.log('data:', data);
  },
});

I think your example is the problem here.  The module is simply getting the data initially and keeps on feeding that for the module itself. The app is watching and reloading, but not the module itself.
Was able to do quite similar stuff here, maybe there some confirmation in it: https://github.com/Jesse1989pp/nuxt-custom-watcher/blob/main/modules/nuxt-custom-watcher.ts

Hi @Jesse1989pp, the problem is I need to use the data for initializing a mock server msw, so I need to restart the mock server with fresh data when the mock files change, right now the only way I could find is by doing a hard restart, Is there a better way for achieving this?
export default defineNuxtModule({
  meta: {
    name: "mswjs",
  },
  async setup(_, nuxt) {
    // handlers is where the mock data lives
    let server = setupServer(...handlers);
    server.listen({ onUnhandledRequest: "bypass" });
    console.log("msw server listening...");

    nuxt.hook("builder:watch", (ev, path) => {
      if (path.includes("handlers.ts")) {
        server.close();
        nuxt.callHook("restart", { hard: true });
      }
    });
  },
});

https://github.com/unjs/ofetch/issues/295#issuecomment-1878598205
We fixed it for now by using above solution.
Its a issue with ofetch and msw.
This is the reason we could't get mocking to work in server/api to external api's.
now it works:
export default defineEventHandler(async (event) => {
  const data = await createFetch()(
    'https://jsonplaceholder.typicode.com/todos/1',
    {
      method: 'GET',
      headers: {
        'Content-Type': 'application/json',
      },
    },
  )
  console.log(JSON.stringify(data))
  return {
    hello: 'world',
  }
})


Endless illegal instructions when running elf executables

I am using the simple system example of Ibex to run a program with Verilator, the program is generated by a random instrucion generator.
A short example of assembly files look like this:
.section .text
.global _start

_start:

    .word 0x73800093
    .word 0xca600113
    .word 0xff700193
    .word 0x56a00213
    .word 0xaea00293
    .word 0xbab00313
    .word 0x0b400393
    .word 0xfe300413
    .word 0xb4000493
    .word 0x39a00513

I use riscv gnu toolchain to compile it with command:
riscv64-unknown-elf-gcc -march=rv32imac -mabi=ilp32 -nostdlib -nostartfiles -o test test.s
the disassembly looks as below, and it seems to be no problem:
test:     file format elf32-littleriscv

Disassembly of section .text:

00010054 <_start>:
   10054:       73800093                li      ra,1848
   10058:       ca600113                li      sp,-858
   1005c:       ff700193                li      gp,-9
   10060:       56a00213                li      tp,1386
   10064:       aea00293                li      t0,-1302
   10068:       bab00313                li      t1,-1109
   1006c:       0b400393                li      t2,180
   10070:       fe300413                li      s0,-29
   10074:       b4000493                li      s1,-1216
   10078:       39a00513                li      a0,922

However, when I simulate the simple system example of Ibex with this elf using Verilator and command:
./build/lowrisc_ibex_ibex_simple_system_0/sim-verilator/Vibex_simple_system -t --meminit=ram,test
ibex seems to be not able to execute these instructions as all I've got is endless illegal instruction like this:
 3249: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3255: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3261: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3267: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3273: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3279: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3285: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3291: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3297: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3303: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3309: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3315: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3321: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3327: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3333: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3339: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3345: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3351: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3357: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3363: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3369: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3375: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3381: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3387: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3393: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3399: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f
                3405: Illegal instruction (hart 0) at PC 0x00100000: 0x464c457f

Can anybody help me as to point out at which step I am making a mistake?

I notice that the first PC that is reported is 0x00100000, but your code starts at _start, which has address 0x0010054. And the reported instruction contents are 0x464c457f, which don't match anything in the objdump.
Is the problem just that you've started at the wrong address?

0x464c457f, which don't match anything in the objdump.

0x464c457f is the ELF magic number, could the file have been loaded 'raw'?
Also shouldn't the code be at 0010xxxx but the disassembly seems to be 0001xxxx?

now the first instruction is at the address of 0x00100000 in objdump:
00100000 <_start>:
  100000:       21600093                li      ra,534
  100004:       33a00113                li      sp,826
  100008:       c7300193                li      gp,-909
  10000c:       8ad00213                li      tp,-1875
  100010:       10200293                li      t0,258
  100014:       6f200313                li      t1,1778
  100018:       b9f00393                li      t2,-1121
  10001c:       b2100413                li      s0,-1247
  100020:       1f500493                li      s1,501
  100024:       7e600513                li      a0,2022
  100028:       69100593                li      a1,1681
  10002c:       f1d00613                li      a2,-227
  100030:       a1500693                li      a3,-1515
  100034:       a7f00713                li      a4,-1409
  100038:       e3d00793                li      a5,-451

instructions are still reported illegal but at a different address again:
Simulation running, end by pressing CTRL-c.
Tracing enabled.
Writing simulation traces to sim.fst
                  17: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                  97: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 177: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 257: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 337: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 417: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 497: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 577: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 657: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 737: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413
                 817: Illegal instruction (hart 0) at PC 0x0016d3fc: 0x00010413

I'd suggest taking a look at the simulation trace that's coming out. Notice that the cycle counter in the first column is now going up by 80 each line (instead of just one). My guess is that Ibex thinks it's running 79 valid instructions in the gaps...

actually the boot address of ibex is not 0x100000 but 0x100080, we should start the program at that address.


bugfix/test for remove when called on empty slot

Fix and test for issue #22:

on remove, if the entry is already empty, do nothing
changed private replace_ to receive the local index (usize) directly

Thanks! Merged: 44f9f41a1680e69db7d370d1912898fb0f90b1f8


Simulator Keeps crashing

The simulator crashes from time to time using the multiplier tool or when i hit (play) start, there is no error message of any kind the app exits immediately, it happens with an empty world or full world, so I assume it has something to do with something deeper in the engine.
What could this be?

Hi,
could you please start ALIEN with the command line argument -debug and then posting the log.txt after the crash occurred?

Hi, could you please start ALIEN with the command line argument -debug and then posting the log.txt after the crash occurred?

I will report here as soon as I have sufficient (debug) because I dont know what triggers it, meanwhile i keep that flag on so when it does, i can convey that to you.

Alright! The simulation runs a bit slower (~15%) with this flag on.

Alright! The simulation runs a bit slower (~15%) with this flag on.

2023-09-20 19-03-30: device 0 is set
2023-09-20 19-03-30: initialize simulation
2023-09-20 19-03-32: resize arrays
2023-09-20 19-03-32: cell array size: 300000
2023-09-20 19-03-32: particle array size: 300000
2023-09-20 19-03-32: auxiliary data size: 300000
2023-09-20 19-03-32: 710 MB GPU memory used
2023-09-20 19-03-46: resize arrays
2023-09-20 19-03-46: cell array size: 300000
2023-09-20 19-03-46: particle array size: 300000
2023-09-20 19-03-46: auxiliary data size: 900000
2023-09-20 19-03-46: 723 MB GPU memory used
2023-09-20 19-03-49: resize arrays
2023-09-20 19-03-49: cell array size: 300000
2023-09-20 19-03-49: particle array size: 300000
2023-09-20 19-03-49: auxiliary data size: 2700000
2023-09-20 19-03-49: 728 MB GPU memory used
2023-09-20 19-14-33: CUDA error. Location: Base.cuh:225 code=719(cudaErrorLaunchFailure) "cudaMemcpy(&result, source, sizeof(T), cudaMemcpyDeviceToHost)"
2023-09-20 19-14-33: CUDA error. Location: CudaSimulationFacade.cu:152 code=46(cudaErrorDevicesUnavailable) "cudaGraphicsMapResources(1, &cudaResourceImpl)"
2023-09-20 19-14-33: network: logout
2023-09-20 19-14-34: close simulation

It doesn't look like the log is from a debug mode, since the cudaErrorLaunchFailure error is not generated by cudaMemcpy, but by a previous kernel call.
When the debug mode is enabled, there is a synchronization point after each kernel call and an error checking.
Only then the error information from the log is useful.
You can check if ALIEN is in debug mode, if after starting via alien.exe -debug (on Windows) the loading screen shows DEBUG.

It doesn't look like the log is from a debug mode, since the cudaErrorLaunchFailure error is not generated by cudaMemcpy, but by a previous kernel call. When the debug mode is enabled, there is a synchronization point after each kernel call and an error checking. Only then the error information from the log is useful.
You can check if ALIEN is in debug mode, if after starting via alien.exe -debug (on Windows) the loading screen shows DEBUG.

Oh, I dont know what else to give you, I did you use that -debug flag and this is all it gives:
2023-09-22 12-42-08: CUDA error. Location: SimulationKernelsLauncher.cu:86 code=719(cudaErrorLaunchFailure) "cudaGetLastError()"
2023-09-22 12-42-08: CUDA error. Location: CudaSimulationFacade.cu:152 code=46(cudaErrorDevicesUnavailable) "cudaGraphicsMapResources(1, &cudaResourceImpl)"

Ok, that looks better. On the Discord server you wrote it occurs after multiplication of structure during a running simulation? Can you please give more details.

Ok, that looks better. On the Discord server you wrote it occurs after multiplication of structure during a running simulation? Can you please give more details. Can you give an instruction to reproduce the bug?

The bug occurs 99% of the time when I add random spores and at the moment of the sim starting and begin to replicate the spores (few seconds into the run) it exits the app, this happens usually 3 times in a row and interestingly after that no crashes anymore, I can run your sim for hours (days probably).

Ok, I'm still not able to reproduce the crash. Maybe I have not yet understood the precise steps. I guess the following steps from the description:

Create a new sim (here I need the sim parameters)
Add a spore (I need the genome code)
Run simulation
Multiply the spore in a running sim (multiplication factor is 100?)
And then it crashes non-deterministically after few seconds.

Is that correct?

Could it be memory issue, because this GFX card does not have plenty of it , maximum of 4gb. because if i push my GPU little too hard on the Stable Diffussion it too succumbs to insufficient memory (SD 2.0XL for instance is a no go)

Yeah it seems when I use the multiplicative tool, it gave me an error as message box.

2023-09-25 13-00-18: DEBUG mode
2023-09-25 13-00-18: set windowed mode
2023-09-25 13-00-18: starting ALIEN v4.3.0
2023-09-25 13-00-19: network: login user 'TheBarret'
2023-09-25 13-00-19: network: get simulation list
2023-09-25 13-00-19: network: get user list
2023-09-25 13-00-19: network: get liked simulations
2023-09-25 13-00-24: 1 CUDA device found
2023-09-25 13-00-24: device 0: NVIDIA GeForce GTX 1050 Ti with compute capability 6.1
2023-09-25 13-00-24: device 0 is set
2023-09-25 13-00-24: initialize simulation
2023-09-25 13-00-26: resize arrays
2023-09-25 13-00-26: cell array size: 300000
2023-09-25 13-00-26: particle array size: 300000
2023-09-25 13-00-26: auxiliary data size: 300000
2023-09-25 13-00-26: 707 MB GPU memory used
2023-09-25 13-00-26: resize arrays
2023-09-25 13-00-26: cell array size: 300000
2023-09-25 13-00-26: particle array size: 300000
2023-09-25 13-00-26: auxiliary data size: 4520073
2023-09-25 13-00-26: 719 MB GPU memory used
2023-09-25 13-00-33: close simulation
2023-09-25 13-00-33: device 0 is set
2023-09-25 13-00-33: initialize simulation
2023-09-25 13-00-35: resize arrays
2023-09-25 13-00-35: cell array size: 300000
2023-09-25 13-00-35: particle array size: 300000
2023-09-25 13-00-35: auxiliary data size: 300000
2023-09-25 13-00-35: 707 MB GPU memory used
2023-09-25 13-04-45: resize arrays
2023-09-25 13-04-45: cell array size: 300000
2023-09-25 13-04-45: particle array size: 300000
2023-09-25 13-04-45: auxiliary data size: 900000
2023-09-25 13-04-45: 719 MB GPU memory used
2023-09-25 13-06-09: message dialog showing: 'Non-overlapping copies could not be created.'
2023-09-25 13-06-09: resize arrays
2023-09-25 13-06-09: cell array size: 300000
2023-09-25 13-06-09: particle array size: 300000
2023-09-25 13-06-09: auxiliary data size: 42000312
2023-09-25 13-06-09: 837 MB GPU memory used
2023-09-25 13-06-16: message dialog showing: 'Non-overlapping copies could not be created.'
2023-09-25 13-20-28: network: refresh login
2023-09-25 13-21-31: close simulation
2023-09-25 13-21-31: device 0 is set
2023-09-25 13-21-31: initialize simulation
2023-09-25 13-21-33: resize arrays
2023-09-25 13-21-33: cell array size: 300000
2023-09-25 13-21-33: particle array size: 300000
2023-09-25 13-21-33: auxiliary data size: 300000
2023-09-25 13-21-33: 707 MB GPU memory used
2023-09-25 13-22-28: resize arrays
2023-09-25 13-22-28: cell array size: 300000
2023-09-25 13-22-28: particle array size: 300000
2023-09-25 13-22-28: auxiliary data size: 900000
2023-09-25 13-22-28: 719 MB GPU memory used
2023-09-25 13-22-37: CUDA error. Location: SimulationKernelsLauncher.cu:99 code=719(cudaErrorLaunchFailure) "cudaGetLastError()"
2023-09-25 13-22-37: CUDA error. Location: CudaSimulationFacade.cu:153 code=46(cudaErrorDevicesUnavailable) "cudaGraphicsMapResources(1, &cudaResourceImpl)"
2023-09-25 13-22-37: network: logout
2023-09-25 13-22-37: close simulation

Please only one bug per issue ;)
I was able to reproduce the bug and it is fixed now in the latest commit.

Thank you very much for your effort and time.

It still ocours and i finally captured what the logger did not appended, and i think this is the details you where asking for:
Microsoft Windows [Version 10.0.19045.3448]
(c) Microsoft Corporation. All rights reserved.

d:\Apps\alien2\bin>alien
Not implemented error. File: D:\dev\alien\source\EngineGpuKernels\GenomeDecoder.cuh, Line: 221
Not implemented error. File: D:\dev\alien\source\EngineGpuKernels\GenomeDecoder.cuh, Line: 221
Not implemented error. File: D:\dev\alien\source\EngineGpuKernels\GenomeDecoder.cuh, Line: 221
...(gets repeated a lot of times)...

An uncaught exception occurred: CUDA error. Location: CudaSimulationFacade.cu:153 code=46(cudaErrorDevicesUnavailable) "cudaGraphicsMapResources(1, &cudaResourceImpl)"


Synced Login Button Hover Effect with 'Get Started' Button  for visual consistency and improved user experience

Fixes Issue

Closes #385
Changes proposed
Improved the login button's hover effect to match that of the 'Get Started' buttons, enhancing overall visual consistency.

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[ ] This PR does not contain plagiarized content.
[ ] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Sorry, I'm closing this as a duplicate of #391
Thanks for raising the Pull Request, feel free to pick any other open issue 🙏


Add support for credhub

With upcoming credhub support in cloudfoundry, see specs https://docs.google.com/document/d/1Sp7gNqyOyJgsaMUIGde6BCvSiqwvSQQK9PNdZycIBnM/edit# the brokers are expected to move from returning plain credentials such as
{
  "credentials": {
    "access_token_uri": "https://p-example-services.cf.example.com/oauth/token",
    "client_id": "p-example-server-876cd13b-1564-4a9a-9d44-c7c8a6257b73",
    "client_secret": "rU7dMUw6bQjR",
    "uri": "https://config-86b38ce0-eed8-4c01-adb4-1a651a6178e2.apps.example.com"
    }
}

into credhub references of the following form, after having written them into credhub:
{
  "credentials": {
    "credhub-ref": "((/c/p-example-services/p-example-server/86b38ce0-eed8-4c01-adb4-1a651a6178e2/credentials-json))"
  }
}

Static-creds should support a syntax allowing users to specify credhub-ref (pointing to credentials that are populated out of band by static-creds operator). At binding time, the broker should grant the bound application credhub permission to fetch the associated reference.

See somewhat related https://github.com/cloudfoundry/secure-credentials-broker and associated stories in the services api backlog This broker is similar to a user-provider-service but instead stores user-provided-credentials in credhub in order to securely serve them to apps.


libinput: 1.15.6 -> 1.16.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/libinput/versions.
meta.description for libinput is: "Handles input devices in Wayland compositors and provides a generic X.Org input driver"
meta.homepage for libinput is: "http://www.freedesktop.org/wiki/Software/libinput"
meta.changelog for libinput is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

0 of 0 passed binary check by having a zero exit code.

0 of 0 passed binary check by having the new version present in output.

found 1.16.0 with grep in /nix/store/q42v711342sjks1r5b9380l5dgb9f0jh-libinput-1.16.0-bin

directory tree listing: https://gist.github.com/99b37893fcc1837eb8eb4b1344f64e7e

du listing: https://gist.github.com/42c5e39c692cf777b13004e2e3ec758e

Rebuild report (if merged into master) (click to expand)

4975 total rebuild path(s)

1749 package rebuild(s)

1749 x86_64-linux rebuild(s)
1619 i686-linux rebuild(s)
6 x86_64-darwin rebuild(s)
1601 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
AusweisApp2
adapta-gtk-theme
adwaita-qt
aj-snapshot
akonadi
akregator
albert
amarok
amarok-kf5
ams
android-file-transfer
anki
ankisyncd
antimicroX
antimony
ao
apitrace
apmplanner2
appcsxcad
appstream-qt
aqemu
ark
arx-libertatis
asymptote
audacious
audaciousQt5
avidemux
awesomebump
bambootracker
barrier
bcompare
beamerpresenter
beets
bibletime
bino3d
birdtray
bitcoin
bitcoin-abc
bitcoin-classic
bitcoin-gold
bitcoin-unlimited
bluedevil
bomber
bomi
boomerang
bovo
breeze-grub
breeze-gtk
breeze-icons
breeze-plymouth

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/q42v711342sjks1r5b9380l5dgb9f0jh-libinput-1.16.0-bin \
  --option binary-caches 'https://cache.nixos.org/ https://r-ryantm.cachix.org/' \
  --option trusted-public-keys '
  r-ryantm.cachix.org-1:gkUbLkouDAyvBdpBX0JOdIiD2/DP1ldF3Z3Y6Gqcc4c=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(r-ryantm's Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A libinput https://github.com/r-ryantm/nixpkgs/archive/a901a07d7471156591ca6a8bdb0c4ea65e1133a1.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/q42v711342sjks1r5b9380l5dgb9f0jh-libinput-1.16.0-bin
ls -la /nix/store/q42v711342sjks1r5b9380l5dgb9f0jh-libinput-1.16.0-bin/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings
cc @codyopel for testing.

Looks like there was a regression: https://lists.freedesktop.org/archives/wayland-devel/2020-August/041590.html


API display button

This button should display a pop-up panel containing the JSON and associated raw curl and python urllib syntax for accessing the results of a user-created query from the command line or a script.

@bruth any thoughts about this?

This looks good, thank you for mocking this up. Where do you expect the button to open this dialog would be placed? It will likely be used the most in the results page, but it may be useful in the workspace for saved queries.

yes, i was thinking next to Save/Share Query buttons
there is some precedence for this feature in
http://useast.ensembl.org/biomart/martview
but i'm sure you can do something slicker

any movement on this?

Yes, it will be implemented this week.

On Apr 25, 2016, at 3:29 PM, Jeremy Leipzig<EMAIL_ADDRESS>wrote:
any movement on this?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub https://github.com/chop-dbhi/cilantro/issues/777#issuecomment-214492104


Make VNode generic type param optional

I suggest we make the VNode generic parameter optional by providing a default type for it.
Adding a generic parameter to the VNode interface breaks the types of many preact libraries that reference or extend VNode. Until many of these libraries update their types to provide a value for the VNode type parameter, I suggest we make it optional. Making it optional unblocks Preact TypeScript users to adopt 8.2.8+ without having to wait for all other libraries to catch up.
Below are some of the libraries that I've found that would need updating. I'll update this list with PRs to take advantage of the type parameter once they are opened. Post a comment here if you open one.
Libraries that need updating to provide a type param to VNode:

[ ] developit/preact-router
[ ] developit/preact-render-to-string
[ ] mzgoddard/preact-render-spy

@andrewiggins I believe it is a good suggestion

LGTM - we can make the change here and then update the other libraries after, right?

That's the plan


Unable to get My Rewards in a market with zero liquidity

I have a small amount of My Rewards to collect in a market, but I am unable to use the Remove Liquidity button to do so as the liquidity is valued at 0.
https://bafybeickragxfpsva6b5zbpcmfiu35aeuawuzmsscvmiyhpe44mbyxn6ty.ipfs.dweb.link/#!/market?id=0x6d2e53d53aec521dec3d53c533e6c6e60444c655-18

I get the "Failed" popup in the UI.
Tested on 1.4.2 and 1.5.0 (non-sports book).

I think my liquidity value went to zero when the fight was cancelled/delayed.  It looks like I had $101 of liquidity added and none withdrawn.
The LP My Rewards shows up in the Pools page as it has for the past 20 days.  So it's been refreshed multiple times.


NancyHal Organisation

Hi all and in particular to @danbarua , the creator of Nancy.Hal.
I'd like to suggest that we create an Github Organisation for Nancy.Hal. It is essentially a convenience for manging both the code and the CI assets. We can grant access for all organisation members to the circleci assets. It also means that sensitive items such as nuget keys can be moved into the ci pipeline (where it can only be viewed by organisation members) rather than being part of the repo where everyone can see them.
What is the consensus?

@danbarua are we able to get this project moved to https://github/NancyHal organisation? That way we can get the CI build going for https://github.com/danbarua/Nancy.Hal/pull/32 so we can have .net standard 1.6 support.

Hi,
This has been done!
On 4 June 2018 at 07:29, Drew Freyling<EMAIL_ADDRESS>wrote:

@danbarua https://github.com/danbarua are we able to get this project
moved to https://github/NancyHal organisation? That way we can get the CI
build going for #32 https://github.com/danbarua/Nancy.Hal/pull/32 so we
can have .net standard 1.6 support.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/danbarua/Nancy.Hal/issues/31#issuecomment-394247742,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcoyGyRve2d7tpEWAG0QbSBmgE8yjzZks5t5NPfgaJpZM4RHnWk
.


can't build the example

I am studying gRPC.!
I am building the example Helloworld for C++ by command make in dir /grpc/examples/cpp/helloworld by it error:
DEPENDENCY ERROR
You don't have the grpc c++ protobuf plugin installed in your path.
Please install grpc. You can find it here:
https://github.com/grpc/grpc
Here is what I get when trying to detect if you have the plugin:
which grpc_cpp_plugin
Makefile:104: recipe for target 'system-check' failed
make: [system-check] Error 1 (ignored)
Makefile:104: recipe for target 'system-check' failed
make: *** [system-check] Error 1
how to fix it?? I tried a lot of way and  have done the correct guide of grpc installation but not successful

Please check this suggestion: https://github.com/grpc/grpc/issues/12403#issuecomment-389347261.
Please re-open if that doesn't solve your issue.


Outreach and continuous learning

Description of changes:

explore efforts to incorporate RSE teaching in undergraduate statistics courses and high school biology courses
discuss the effects of gamification on continuous learning and engagement in GitHub and Fedora
expand bibliography on RSE teaching material and RSE good practices guides

I will notify the others about your MR and I want to discuss it this friday. Thank You!

@jngrad I think I've synchronized all the open MRs into the main branch that we considered open last friday. You can now move forward, fix the conflicts, and merge your branch into main if you think it's  done.


Issue with template sensors after v0.18.0

Hi!
I'm using LocalTuya with some smart plugs for measuring the power consumption of devices.
Since the integration exposes Voltage, Current and Consumption as attributes of a 'switch' entity, I'm using 'template' sensors as described in the LocalTuya Github repo.
Home Assistant: core-2022.2.9
Home Assistant OS: Home Assistant OS 7.2
HACS: 1.22.0
This had been working great with PowerCalc (v0.17.0) with the following configs:
configuration.yaml
powercalc:
  # create_utility_meters: true
  # create_energy_sensor: true
  # utility_meter_types:
    # - daily
    # - weekly
    # - monthly
    # - yearly
  # power_sensor_naming:
  # energy_sensor_naming: "{} kWh consumed"

(including the commented out lines because for some reason Home Assistant won't accept any of them as valid)
sensors.yaml
- platform: template
  sensors:
    tuya_sw01_voltage:
      value_template: >-
        {{ states.switch.washing_machine_plug.attributes.voltage }}
      unit_of_measurement: "V"
    tuya_sw01_current:
      value_template: >-
        {{ states.switch.washing_machine_plug.attributes.current }}
      unit_of_measurement: "mA"
    tuya_sw01_current_consumption:
      value_template: >-
        {{ states.switch.washing_machine_plug.attributes.current_consumption }}
      unit_of_measurement: "W"

- platform: powercalc
  entity_id: switch.washing_machine_plug
  power_sensor_id: sensor.tuya_sw01_current_consumption

customize.yaml
sensor.tuya_sw01_current_consumption:
  device_class: power

After updating to v0.18.0 PowerCalc fails to set up sensors with the following trace:
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
    await asyncio.shield(task)
  File "/config/custom_components/powercalc/sensor.py", line 219, in async_setup_platform
    entities = await create_sensors(hass, config, discovery_info)
  File "/config/custom_components/powercalc/sensor.py", line 284, in create_sensors
    new_sensors = await create_individual_sensors(
  File "/config/custom_components/powercalc/sensor.py", line 404, in create_individual_sensors
    energy_sensor = await create_energy_sensor(
  File "/config/custom_components/powercalc/sensors/energy.py", line 58, in create_energy_sensor
    registry_entry = find_related_real_energy_sensor(hass, power_sensor_id)
  File "/config/custom_components/powercalc/sensors/energy.py", line 104, in find_related_real_energy_sensor
    if not entity_entry.device_id:
AttributeError: 'NoneType' object has no attribute 'device_id'

Basically, this ent_reg.async_get(power_sensor_id) is returning an empty value.
custom_components/powercalc/sensors/energy.py, line 103

Thanks for the report. There has been some changes under the hood from 0.17 to 0.18 which have caused this.
Powercalc now tries to find an related energy sensor for an existing power sensor, and will not create an energy sensor when this is the case. Otherwise you'll get duplicate energy sensors. The related issue about this was #547.
The problem is you are using a template sensor as input, which does not exist in HA entity registry (because it has no unique_id).
I will fix this asap.
What do you mean by "including the commented out lines because for some reason Home Assistant won't accept any of them as valid"?

Just released v0.18.1. Should be fixed now.

Wow, thanks for the swift response!
Now the entity still needs a unique_id else it produces an error again.
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 249, in _async_setup_platform
    await asyncio.shield(task)
  File "/config/custom_components/powercalc/sensor.py", line 223, in async_setup_platform
    entities = await create_sensors(hass, config, discovery_info)
  File "/config/custom_components/powercalc/sensor.py", line 289, in create_sensors
    new_sensors = await create_individual_sensors(
  File "/config/custom_components/powercalc/sensor.py", line 409, in create_individual_sensors
    energy_sensor = await create_energy_sensor(
  File "/config/custom_components/powercalc/sensors/energy.py", line 77, in create_energy_sensor
    if power_sensor.unique_id:
AttributeError: 'RealPowerSensor' object has no attribute 'unique_id'

But setting a unique_id on the template sensor doesn't seem to fix it.
As for the commented out part, I just wanted to provide as many details as possible, in case the issue was due to error in my broader configuration.
Home Assistant reports "incorrect configuration" when I try to add any of the commented out lines to the config.

I am away for a few hours now. Will have another look again when I am home. Will also create similar template sensor and see if I can reproduce. This will also make sure it won't break again in the future.
Regarding the config, I see one issue in your global config. power_sensor_naming must have a value. Other configs looks correct. What error message does HA show exactly?

Ok, no problem. Rolled back to v0.17.0 for now and will update when needed to provided details.
So, regarding the global config, when for example I uncomment and use the following:
powercalc:
  create_energy_sensor: true

I get:
Invalid config for [powercalc]: [create_energy_sensor] is an invalid option for [powercalc]. Check: powercalc->powercalc->create_energy_sensor. (See /config/configuration.yaml, line 100).

And with the full global config respectively:
powercalc:
  create_utility_meters: true
  create_energy_sensor: true
  utility_meter_types:
    - daily
    - weekly
    - monthly
    - yearly

Invalid config for [powercalc]: [create_energy_sensor] is an invalid option for [powercalc]. Check: powercalc->powercalc->create_energy_sensor. (See /config/configuration.yaml, line 99).

The attribute you mentioned was there for testing and had a value prior to being commented out.

It should be create_energy_sensors not create_energy_sensor. See https://github.com/bramstroker/homeassistant-powercalc#global-configuration.
create_energy_sensor is for the sensor specific configuration not the global configuration.

Yeap, that fixed it.
That's what I get for skipping parts of the README.
Thanks!

Yeap, that fixed it. That's what I get for skipping parts of the README.

Still found some time to fix this issue. Are you able to test with the master branch? You can install that also with HACS (click three dots, redownload, and check the beta versions checkbox).
When it is working for you I will release v0.18.2 soon.

Ok, so I installed the master branch and it seems to work.
For some reason I had to remove the integration and then restart 2-3 times (kept showing an HA websocket energy warning), but after that it was cool.
I'd like to test for a little bit to verify, before you release if possible.

Thanks a lot for testing. The restart issue could not be related to powercalc as I don't do anything with the websockets API of HA.
Let me know if everything works stable for you, than I will release v0.18.2

Just released v0.18.2. Let me know if you are experiencing any issues

Hello. Thank you for the fix and all the support.
I tested a bit yesterday and all seemed good.
HACS seems to think that v0.18.1 is the latest version for some reason, but manually selecting and installing v0.18.2, it works as it should.


How to add cams

Hello,
how to you add more cameras in the code (for example Cam2):
cams: [
{
alias: "Cam1",
name: "NAME_IN_DS",
}
]
How should the code look like for 2 or more camera?
Thanx.

Hi,
if both cams are connected to the same diskstation simply add a second object to the cams array:
cams: [
{
alias: "Cam1",
name: "NAME_IN_DS",
},
{
alias: "Cam2",
name: "NAME_OF_SECOND_Cam_IN_DS",
}
]

Thank you! It workes perfect!

Great to see one more user that is happy


Migrated consul to traefik as a reverse proxy.

The Caddy plugin for managing Let's Encrypt DNS challenges with Route53 is broken, despite some fixes being applied. Traefik is a more widely used and adaptable proxy service that also includes built-in support for Let's Encrypt, so we are migrating to use it in place of Caddy.
Description
Migrated consul to traefik as a reverse proxy.
Motivation and Context
The current builds of Consul are broken due to the lack of certificate handling in Caddy.
How Has This Been Tested?
Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Enhancement (improves on existing behavior)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[X] My code follows the code style of this project. (Did you install and run the pre-commit hooks?)
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

This isn't fully tested yet because I was rate-limited by LetsEncrypt.

:+1:


[Feature] Add support for potential fixes

The VS Code extension is working great, but when e.g. implementing a new interface, I usually switch back to Visual Studio to get their feature of "applying potential fixes" which helps me to implement missing interface methods, apply linter suggestions, etc.
Is there a feature request for that already somewhere or is it out of scope for this extension?

@mxschmitt If you have omnisharp.enableRoslynAnalyzers set to true in your VSCode Settings then we should be analyzing your code and offering suggestions.
You can fix individual suggestions through the light bulb that appears on the line with Problems.

You can fix all suggestions by invoking one of the fix all commands.

I tried to enable the setting, but it does not yield to any differences. See for example this warning:

After updating Roslynator.Analyzers from 3.0.0 to 3.3.0 it was working. Important to note here was the progress bar in the VS Code status bar (bottom of the application).
Closing by that, thanks!


CORS support should be optional

While I don't understand tne implications fully, I think [CORS][] should not be enabled for every microservice and thus should be made optional.
It's rather an easy fix but needs some changes all around (code, docstrings, possibly examples).
In principle, this is what needs to be done, as far as I can tell:

[ ] A config parameter enable_cors should be added to the SecurityConfig model (set default to True) in foca/models/config.py; update docstring accordingly, including example and, if necessary, dependent examples (search file for any mentions of SecurityConfig)
[ ] In the main FOCA file (foca/foca.py), the value of the config parameter should be read to decide whether to call enable_cors() in line 49 (i.e., add an if ... around that call and the log message, maybe add another log message to say that CORS is disabled in the else ... block)
[ ] Check if any documentation needs to be updated

Can you please assign me this issue? @uniqueg


feat(esp-idf-monitor): Add --retry-open flag  (IDFGH-13270)

esp-idf-monitor frequently fails when trying to open the serial port of a device which deep-sleeps often.
e.g.:
# idf.py monitor -p /dev/cu.usbmodem6101
--- esp-idf-monitor 1.4.0 on /dev/cu.usbmodem6101 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
[Errno 2] could not open port /dev/cu.usbmodem6101: [Errno 2] No such file or directory: '/dev/cu.usbmodem6101'
Connection to /dev/cu.usbmodem6101 failed. Available ports:
/dev/cu.usbmodemF554393F21402
/dev/cu.AspergitosII
/dev/cu.Bluetooth-Incoming-Port

esp-idf-monitor currently already waits for the serial port if it was opened successfully. This, however, doesn't help when opening the device for the first time.
This makes developers add unnecessarily long sleeps when the main CPU is awake, in order to give esp-idf-monitor the chance to find the serial port.
This PR adds a new flag --retry-open which retries opening the port indefinitely until the device shows up:
# idf.py monitor -p /dev/cu.usbmodem6101  --retry-open
--- esp-idf-monitor 1.4.0 on /dev/cu.usbmodem6101 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
[Errno 2] could not open port /dev/cu.usbmodem6101: [Errno 2] No such file or directory: '/dev/cu.usbmodem6101'
Retrying to open port ......
ESP-ROM:esp32s3-20210327
rst:0x15 (USB_UART_CHIP_RESET),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4037b516
[...]

I edited the commit message so that it conforms the pre-commit hook (the PR description is slightly longer to help explaining what it does)

CC @sudeep-mohanty who I am sure will appreciate the feaure when developing risc-v ULP code :)

BTW, we should probably set ESPTOOL_RETRY_OPEN_SERIAL accordingly after/if https://github.com/espressif/esptool/pull/995 is merged, just like it is done with ESPPORT:
https://github.com/espressif/esp-idf-monitor/blob/d49533f5331e3ad85f8ea7fbfa6ccb22a4fcab90/esp_idf_monitor/idf_monitor.py#L400
Happy to do that right away if you think it makes sense.

I ended up setting ESPTOOL_RETRY_OPEN_SERIAL based on --retry-open so that we can invoke  esptool properly through idf.py.
This is needed in order to properly invoke esptool with --retry-open-serial through idf.py  (I will create a patch in esp-idf later on)

Hello,
I'm wondering if it would be possible to re-use the current re-connect logic.
diff --git a/esp_idf_monitor/base/argument_parser.py b/esp_idf_monitor/base/argument_parser.py
index 0ec426210bdb..4ce780afba44 100644
--- a/esp_idf_monitor/base/argument_parser.py
+++ b/esp_idf_monitor/base/argument_parser.py
@@ -139,4 +139,10 @@ def get_parser():  # type: () -> argparse.ArgumentParser
         default=False,
         action='store_true')

+    parser.add_argument(
+        '--retry-open',
+        help='Indefinitely retry opening the port device for the first time',
+        default=False,
+        action='store_true')
+
     return parser
diff --git a/esp_idf_monitor/base/serial_reader.py b/esp_idf_monitor/base/serial_reader.py
index a49d02dfbe37..cbe913beffd9 100644
--- a/esp_idf_monitor/base/serial_reader.py
+++ b/esp_idf_monitor/base/serial_reader.py
@@ -25,14 +25,15 @@ class SerialReader(Reader):
     event queue, until stopped.
     """

-    def __init__(self, serial_instance, event_queue, reset, target):
-        #  type: (serial.Serial, queue.Queue, bool, str) -> None
+    def __init__(self, serial_instance, event_queue, reset, retry_open, target):
+        #  type: (serial.Serial, queue.Queue, bool, bool, str) -> None
         super(SerialReader, self).__init__()
         self.baud = serial_instance.baudrate
         self.serial = serial_instance
         self.event_queue = event_queue
         self.gdb_exit = False
         self.reset = reset
+        self.retry_open = retry_open
         self.reset_strategy = Reset(serial_instance, target)
         if not hasattr(self.serial, 'cancel_read'):
             # enable timeout for checking alive flag,
@@ -46,30 +47,40 @@ class SerialReader(Reader):
             try:
                 # We can come to this thread at startup or from external application line GDB.
                 # If we come from GDB we would like to continue to run without reset.
-                self.open_serial(reset=not self.gdb_exit and self.reset)
+                self.reset = not self.gdb_exit and self.reset
+                self.open_serial(reset=self.reset)
+                # Successfully connected, so any further reconnections should occur without a reset.
+                self.reset = False
             except serial.SerialException as e:
                 print(e)
-                # if connection to port fails suggest other available ports
-                port_list = '\n'.join([p.device for p in list_ports.comports()])
-                yellow_print(f'Connection to {self.serial.portstr} failed. Available ports:\n{port_list}')
-                return
+                if not self.retry_open:
+                    # If the connection to the port fails and --retry-open was not specified,
+                    # recommend other available ports and exit.
+                    port_list = '\n'.join([p.device for p in list_ports.comports()])
+                    yellow_print(f'Connection to {self.serial.portstr} failed. Available ports:\n{port_list}')
+                    return
             self.gdb_exit = False
         try:
             while self.alive:
                 try:
-                    data = self.serial.read(self.serial.in_waiting or 1)
+                    if self.serial.is_open:
+                        # in_waiting assumes the port is already open
+                        data = self.serial.read(self.serial.in_waiting or 1)
+                    else:
+                        raise serial.PortNotOpenError
                 except (serial.SerialException, IOError) as e:
                     data = b''
                     # self.serial.open() was successful before, therefore, this is an issue related to
                     # the disappearance of the device
-                    red_print(e.strerror)
+                    red_print(str(e))
                     yellow_print('Waiting for the device to reconnect', newline='')
                     self.close_serial()
                     while self.alive:  # so that exiting monitor works while waiting
                         try:
                             time.sleep(RECONNECT_DELAY)
                             # reset on reconnect can be unexpected for wakeup from deepsleep using JTAG
-                            self.open_serial(reset=False)
+                            self.open_serial(reset=self.reset)
+                            self.reset = False
                             break  # device connected
                         except serial.SerialException:
                             yellow_print('.', newline='')
diff --git a/esp_idf_monitor/idf_monitor.py b/esp_idf_monitor/idf_monitor.py
index 9d6b35938591..d97e4cb5f550 100644
--- a/esp_idf_monitor/idf_monitor.py
+++ b/esp_idf_monitor/idf_monitor.py
@@ -90,6 +90,7 @@ class Monitor:
         make='make',  # type: str
         encrypted=False,  # type: bool
         reset=DEFAULT_TARGET_RESET,  # type: bool
+        retry_open=False,
         toolchain_prefix=DEFAULT_TOOLCHAIN_PREFIX,  # type: str
         eol='CRLF',  # type: str
         decode_coredumps=COREDUMP_DECODE_INFO,  # type: str
@@ -128,7 +129,7 @@ class Monitor:
             # testing hook: when running tests, input from console is ignored
             socket_test_mode = os.environ.get('ESP_IDF_MONITOR_TEST') == '1'
             self.serial = serial_instance
-            self.serial_reader = SerialReader(self.serial, self.event_queue, reset, target)  # type: Reader
+            self.serial_reader = SerialReader(self.serial, self.event_queue, reset, retry_open, target)  # type: Reader

             self.gdb_helper = GDBHelper(toolchain_prefix, websocket_client, self.elf_file, self.serial.port,
                                         self.serial.baudrate) if self.elf_exists else None
@@ -408,6 +409,7 @@ def main() -> None:
                       args.make,
                       args.encrypted,
                       not args.no_reset,
+                      args.retry_open,
                       args.toolchain_prefix,
                       args.eol,
                       args.decode_coredumps,

The passing of retry option for the cmake target (e.g., esptool) is not included. Additionally, if the reset logic only applies to the initial connection, the gdb_exit test might be unnecessary. This is just a preliminary idea, so feel free to ignore.
Thank you

I'm wondering if it would be possible to re-use the current re-connect logic.

I will take a look at the code and see

The passing of retry option for the cmake target (e.g., esptool) is not included.

Do you mean https://github.com/espressif/esp-idf-monitor/pull/15/commits/e894d66826606da03be9324b5bd45d43ccce070c ? (I think I may have forgotten to push it yesterday)

Hello,

I'm wondering if it would be possible to re-use the current re-connect logic.

Thanks, I will take a look at the code and see if I can reuse it.

As you stated in your original report

esp-idf-monitor currently already waits for the serial port if it was opened successfully. This, however, doesn't help when opening the device for the first time.

This made me wonder if we can reuse it. I might have overlooked something, so please take it as just an idea. Others who are more familiar with the monitor might have different opinion.

The passing of retry option for the cmake target (e.g., esptool) is not included.

Do you mean e894d66 ? (I think I may have forgotten to push it yesterday)

Yes, but I meant that I did not include this change in my patch I posted above. There is nothing missing in your PR. Sorry for the confusion, and thank you very much for looking into this!

@fhrbata Ah, gotcha. Your code was much cleaner though

I have also increased the period with which we check the port to 100ms (while still keeping the screen feedback to 1 dot every 500ms)

I have also increased the period with which we check the port to 100ms (while still keeping the screen feedback to 1 dot every 500ms)
This will greatly increase the chance of catching more logs in devices which deep-sleep.

Thank you very much! I'm tagging @peterdragun, who is responsible for the monitor. Peter, what are your thoughts?

@2opremio Thank you for your contribution! Overall the changes look good to me.
Can you please squash the commits so the git history will be cleaner?

@peterdragun Done! (Although I am sure you know it can be done a merge-time)

Thank you!

(Although I am sure you know it can be done a merge-time on GitHub)

yes, you are right, but it helps our internal process if the PR author did the squash and rebase. Also, I would add myself as a co-author and "steal" the credits.

@peterdragun I added a minor correction (I think it was a preexisting problem) by extending the exception capturing. Do you want me to squash it?

I added a minor correction (I think it was a preexisting problem) by extending the exception capturing. Do you want me to squash it?

It is okay to keep it as a separate commit. Thank you.
Just a clarification from the PR description:

This makes developers add unnecessarily long sleeps when the main CPU is awake, in order to give esp-idf-monitor the chance to find the serial port.

I don't think this is true and also I don't think this PR will help to remove such waits. The wait is there mainly for USB JTAG/Serial, the reason why it was necessary to add it is because unlike with a USB-to-UART bridge, the port will disappear and it takes some time for the OS to notice the port. AFAIK, the main purpose is not to allow users to catch this moment, but rather for the already running monitor to establish the connection. The only part that can help is the reduced RECONNECT_DELAY time.

Hi @2opremio, I am sorry that it is taking so long, but I have one last request for you. Can you please remove the dependency on Esptool PR (the env variable part)? That way we won't rely on the esptool PR getting merged and we would unblock this PR.
We will reconsider the connection between the tools in the future and maybe we will get it back once the esptool PR gets merged.
Thank you for your cooperation and contribution!

Sure thing, but it is not really a dependency per se (in the sense that the env variable can simply be ignored if not used).
However, I understand you don't want to have a dangling env variable which may not be used.

I have removed the env variable but please note it's impossible to have a complete system which retries opening (i.e. esptool) without it.
I myself am running a patched version of esptool locally which doesn't work without the env variable.

What's holding this PR back? Is it just the conflicts? (It's been ready for a while)

I've just rebased and fixed the conflicts

What's holding this PR back?

I am sorry that it takes so long. The delay was mainly caused by the vacation season. We have also decided that we will wait for the esptool PR to merge in the end. We will get this merged soon, but there will probably be some small changes compared to your solution.
Thank you for being so patient.


API function to update existing bot created issue with new comments

@epicallan , to update them in what way, with a comment ? i.e updated issue?

@epicallan , to update them in what way, with a comment ? i.e updated issue?

@epicallan

we search for all issues by term _bot_and sort them by comments
then we call the addIssuesToRepo function

Get issues created by bot

Each issue has a predictable issue title, hence we can update particular issues basing on that.
https://github.com/Akilihub/github-todos/blob/master/src/lib/github/issue-presenter.ts#L23

So if our new comments are for a TODO issue we need to add our new comments (body) to our existing TODO issue as a new comment.

So we need an API function that adds a comment to an existing issue.


Adding client auditing session properties

Request to add automatic client auditing information as is available in vertica's sessions table.
Some were already available. Newly added properties are client_pid, client_type, client_version, client_os, and client_os_user_name

This PR also contains the necessary version upgrades for vertica-nodejs 1.1.1. v-protocol, v-pool, and v-connection string are all untouched. However v-pool has a peer dependency on vertica-nodejs so vertica-nodejs and v-pool are on 1.1.1, v-protocol and v-connection-string stay on 1.1.0


Documentation for commands/commands.go

Description
Documentation for commands/commands.go
Fixes #242
Type of change

Documentation update

Testing steps
N/A

Codecov Report

Merging #307 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #307   +/-   ##
=======================================
  Coverage   70.95%   70.95%
=======================================
  Files          12       12
  Lines         730      730
=======================================
  Hits          518      518
  Misses        208      208
  Partials        4        4

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5f5c713...1005a0c. Read the comment docs.


Case statement with wrong indents could give better hints

I had a working program (elm 0.18.0), and tried to add a simple NoOp branch to my update function. I was doing a copy-paste, which accidentally added an extra space.
update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
  case msg of
    Name name ->
      ( { model | name = name }, Cmd.none )
     NoOp ->
      ( model, Cmd.none )

The compiler gave me this error, which was quite confusing.
-- SYNTAX PROBLEM --------------------------------------------- ./src/Update.elm

Arrows are reserved for cases and anonymous functions. Maybe you want > or >=
instead?

30|      NoOp ->
              ^
Maybe <http://elm-lang.org/docs/syntax> can help you figure it out.

Detected errors in 1 module.

It would have helped if the compiler saw the arrow and gave a hint: "if was supposed to be part of your existing case statement, it's not indented properly."  For completeness, if you have too little indent, you get this error, which could use a similar heuristic to give the same hint.
-- SYNTAX PROBLEM --------------------------------------------- ./src/Update.elm

I ran into something unexpected when parsing your code!

30|   NoOp ->
      ^
I am looking for one of the following things:

    end of input
    whitespace

Thank you for reporting this! I am finishing up a revamp of the compiler that is able to produce much nicer error messages. Based on your example, I made a tweak in https://github.com/elm/compiler/commit/aaa2d65d09672b31b6da6c3c317e12bf6b796d47 to make the message super relevant! My development build is producing:
-- UNEXPECTED ARROW --------------------------------------------------- temp.elm

I am parsing a `case` expression right now, but this arrow is confusing me:

6|      NoOp ->
             ^^
It makes sense to see arrows around here, so I suspect it is something earlier.
Maybe this pattern is indented a bit farther than the previous patterns?

Note: Sometimes I get confused by indentation, so try to make your `case` look
something like this:

    case maybeWidth of
      Just width ->
        width + 200

      Nothing ->
        400

Notice the indentation! Patterns are aligned with each other. Same indentation.
The expressions after each arrow are all indented a bit more than the patterns.
That is important!

Thank you for reporting this! It makes it really easy to check if the error message is giving information that is relevant to the reader!


[question] get Battery Level

I would like to call the battery level of my motion sensor periodicaly (e.g. all two weeks). Because Fibaro Motion Sensor does not deliver on wake up or on other events.
How can I do that with zwave2mqtt? Is there a posibility?
I already tried with a topic .../128/1/0 and an JSON payload. ... but that's just try n error.

I've got it!
Topic:
zwave/_CLIENTS/ZWAVE_GATEWAY-<name>/api/refreshValue/set
Payload:
{"args":[2,128,1,0]}
--> args: node_id, class_id, instance_id, index_id

You can also set refresh value automatically in gateway values table on settings tab.
Daniel

On 5 Nov 2019, at 21:02, Qaldak<EMAIL_ADDRESS>wrote:

I would like to call the battery level of my motion sensor periodicaly (e.g. all two weeks). Because Fibaro Motion Sensor does not deliver on wake up or on other events.
How can I do that with zwave2mqtt? Is there a posibility?
I already tried with a topic .../128/1/0 and an JSON payload. ... but that's just try n error.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.


Change PR trigger phrase match criteria

Use timeout with phrase match
Use find instead of matches
Change compile target to java8

Thank you Tuminoid for your input. I have run a couple of tests on some large chunks of text it seems they all executed under 100ms.

Cool, thanks. It might be different when the server is under load, but that should be fine for 99% of the cases at least. And we can later increase it if it becomes an issue.

Yes, that is also an important consideration. In case of a timeout, we are logging the contextual information.


Resilience4J Bulkheads - Thread doesn't get interrupted with Timelimiter & Bulkhead

Describe the bug
When using a timelimiter + semaphore bulkhead, if the timelimiter's time is exceeded, the underlying thread executing is not interrupted but the bulkhead permit is released. This means if the restricted section inside the bulkhead is consistently timing out, more concurrent requests are submitted than what the bulkhead should allow.
This happens because the Resilience4JBulkheadProvider uses  CompletableFuture.supplyAsync and Completable Futures can't be interrupted.
From the CompletableFuture.cancel docs:

Parameters:  mayInterruptIfRunning - this value has no effect in this implementation because interrupts are not used to control processing.

Additional Article on CompletableFuture and interrupts: https://nurkiewicz.com/2015/03/completablefuture-cant-be-interrupted.html
Affected Versions
2.x and 3.x
Sample
Sample repository: https://github.com/Mistborn94/spring-r4j-bulkhead-demo
The sample repository contains two test classes that are almost identical: BulkheadDisabledTests and BulkheadEnabledTests. BulkheadDisabledTests passes but BulkheadEnabledTests fails because the thread is not interrupted.
Possible solution

Use Bulkhead.decorateSupplier instead of Bulkhead.decorateCompletionStage to create the bulkhead and then use an executor service with a normal future (possibly the same one that is already used in the  Resilience4JCircuitBreaker ) for the time limiter.
Swap the order of the bulkhead and the timelimiter so the time limiter happens inside the bulkhead and can interrupt the task (This would also fix the thread pool bulkhead which works only with CompletionStage and has a similar problem)

I would be willing to submit a pull request for this

@Mistborn94 a PR would be quite welcome!

Not su if it is related but currently, the ThreadPoolBulkhead is not auto closing resources.
Tested by using Spring Cloud Circuit Breaker in a batch job, the batch hangs and never finishes as the bulkhead threads are not closed. When configure to use semaphore works fine.
More info here:
https://github.com/resilience4j/resilience4j/issues/1199