ERROR, script not working

Describe the bug
Hello,
I wanted to check if the script was working, but I noticed that the logs were completely empty. Therefore, I executed the following commands:
source .venv/bin/activate
python3 main.py
However, I encountered the following error:
Traceback (most recent call last):
File "/home/ubuntu/oracle-freetier-instance-creation/main.py", line 67, in
config = oci.config.from_file(oci_config_path)
File "/home/ubuntu/oracle-freetier-instance-creation/.venv/lib/python3.10/site-packages/oci/config.py", line 120, in from_file
invalid_key_file_path_checker(config, expanded_file_location, profile_name)
File "/home/ubuntu/oracle-freetier-instance-creation/.venv/lib/python3.10/site-packages/oci/config.py", line 224, in invalid_key_file_path_checker
raise InvalidKeyFilePath(message)
oci.exceptions.InvalidKeyFilePath: Config file /home/ubuntu/oracle-freetier-instance-creation/oci_config is invalid: the key_file's value '</home/ubuntu/oracle-freetier-instance-creation/oci_api_private_key.pem> # TODO' at line 6 must be a valid file path. For more info about config file and how to get required information, see https://docs.oracle.com/en-us/iaas/Content/API/Concepts/sdkconfig.htm
Instance Type (please complete the following information):

ARM 4 core and 24 of ram
Micro Second Instance: yes
Custom Image or default: ubuntu 22

Environment (please complete the following information):

Micro Instance or Local: VM.Standard.E2.1.Micro
OS: ubuntu
Version: 22

Additional context
here's my oci.env config:
OCI Configuration
OCI_CONFIG=/home/ubuntu/oracle-freetier-instance-creation/oci_config
OCT_FREE_AD=AD-1,AD-2,AD-3
DISPLAY_NAME=main
The other free shape is AMD: VM.Standard.E2.1.Micro
OCI_COMPUTE_SHAPE=VM.Standard.A1.Flex
SECOND_MICRO_INSTANCE=True
REQUEST_WAIT_TIME_SECS=600
SSH_AUTHORIZED_KEYS_FILE=/home/ubuntu/oracle-freetier-instance-creation/id_rsa.pub
SUBNET_ID to use ONLY in case running in local or a non E2.1.Micro instance
OCI_SUBNET_ID=
OCI_IMAGE_ID=
The following will be ignored if OCI_IMAGE_ID is specified
OPERATING_SYSTEM=Canonical Ubuntu
OS_VERSION=22.0

it clear says that the oci API private key is not present. double check if it's placed in the correct location

i followed the tutorial, and it should be present

this is the what the ls command shows
LICENSE             launch_instance.log  oci_api_private_key.pem  sample_oci_config
README.md main.py              oci_config               setup_and_info.log
email_content.html  oci.env              requirements.txt         setup_init.sh

is your direcor

whats the project location?
is it /home/ubuntu/oracle-freetier-instance-creation/ or something different?

yes it is, can you check if the permission for the key and config are right?

ok, I think i found the error; I removed the comment .TODO in the oci_config file, now it's popolating the log with the message:
2024-06-26 08:52:36,212 - INFO - Command: launch_instance--
Output: {'status': 500, 'code': 'InternalError', 'message': 'Out of host capacity.'}
is it correct?


[BUG]:

How are you running AnythingLLM?
Docker (local)
What happened?
Found no where in anythingllm-chat-widget.min.js to update the chatbot widget icon

Are there known steps to reproduce?
Please provide steps to fix so. Much appreciated.

You can find the documentation for the embedded chat here: embedded chat docs.
Adding the data-assistant-icon attribute to the script code you are adding to your website will allow you to change the icon.

Added, does not see it rendered, what am I missing? Appreciate your help Sean.
`

`

@shatfield4 can you replicate this? Latest script built should be published and have this in it.

@shatfield4 @timothycarambat, I understand you guys have alot to maintain this awesome tool and have alot to answer, but I've looked through all the docs and issues and tried to find a workaround in the min.js file but haven't found one yet. Would appreciate if yall can replicate and find a fix for this. Thanks in advance


Hardfault on boot when only usb console is used

I've moved from NuttX 8.2 to NuttX 10.0.0.  If uart console is used booting is ok. But if only usb console is used (CONFIG_CDCACM_CONSOLE) I get hardfault on each boot.
Digging in debug showed that it occurs on first use of stdout or stderr!
As I see with commit b0797263ca2817cf536be8b843ac5b5aac5d4d9c stdout and stderr are now gotten from dynamic stream list
https://github.com/apache/incubator-nuttx/blob/d987dd2f5aa5d26f814c66d01eb4509b1efb1672/include/stdio.h#L81-L83
I supposed due to latter usb console initialization in my case nxsched_get_streams()->sl_head is null, so nxsched_get_streams()->sl_head->fs_next causes hardfault.
stdout, stderr could be easily used in board_app_initialize, but stderr is certainly used in
apps/nshlib/nsh_console.c:
https://github.com/apache/incubator-nuttx-apps/blob/3b884cfb870d21d02542d7e8434d286228e359f6/nshlib/nsh_console.c#L510
on usb console initialization in apps/nshlib/nsh_usbconsole.c
https://github.com/apache/incubator-nuttx-apps/blob/3b884cfb870d21d02542d7e8434d286228e359f6/nshlib/nsh_usbconsole.c#L269
before cdcacm_initialize() is called. I haven't dig further, but I suppose stream allocation is made with /dev/console registration, right?
(If it is matters, I'm working with custom board and firmware based on latest PX4. But issue definitely related to NuttX)
So it looks like deferred console is special case that should be treated carefully.
@xiaoxiang781216, hope for your help, thanks in advance.

Do you have these patch which should fix you problem:
https://github.com/apache/incubator-nuttx/pull/1993
https://github.com/apache/incubator-nuttx/pull/1997
https://github.com/apache/incubator-nuttx-apps/pull/425

Do you have these patch which should fix you problem:

No, I didn't have these patches. Now I have, but it doesn't help.
As I see patches were aimed on fclose of the builtin streams, while in my case they are not yet allocated on init in nsh_newconsole and board_app_initialize.

But, there is a special patch for usb console:
https://github.com/apache/incubator-nuttx-apps/pull/425/commits/2b9d283ed547a6bb6049f1142dea00772c6ac88b
@masayuki2009 hit the similar issue with stm32f4discovery:usbnsh and fixed by the above patch.

But, there is a special patch for usb console:
apache/incubator-nuttx-apps@2b9d283
@masayuki2009 hit the similar issue with stm32f4discovery:usbnsh and fixed by the above patch.

Patch is certainly here, but nsh_configstdio func is called further in nsh_consolemain func while hardfault is occurring in nsh_newconsole

Here is a part of the task initialization process:
https://github.com/apache/incubator-nuttx/blob/master/sched/group/group_setupstreams.c#L71

Here is a part of the task initialization process:
https://github.com/apache/incubator-nuttx/blob/master/sched/group/group_setupstreams.c#L71

Thanks! In this place inside fs_fdopen the fs_checkfd func returns ENOENT, because inode is null.

@lukegluke See https://github.com/PX4/PX4-Autopilot/blob/master/platforms/nuttx/src/px4/common/px4_init.cpp#L45
This is how we fixed the changes in upstream NuttX that are caused by the dynamic allocation of the streams. When there is no console.

The root cause in that the 3 fds are not initialized in sched then the stream leaves the stream initialized.
See group_setupidlefiles.c
If the CONFIG_DEV_CONSOLE is not defined
https://github.com/apache/incubator-nuttx/blob/8c464b0e7a35bf6ae94fcecdccc31dd31af9cd29/sched/group/group_setupidlefiles.c#L98-L125
this https://github.com/apache/incubator-nuttx/blob/8c464b0e7a35bf6ae94fcecdccc31dd31af9cd29/sched/group/group_setupidlefiles.c#L129-L131
does nothing.

@lukegluke See https://github.com/PX4/PX4-Autopilot/blob/master/platforms/nuttx/src/px4/common/px4_init.cpp#L45
This is how we fixed the changes in upstream NuttX that are caused by the dynamic allocation of the streams. When there is no console.

Thanks for feedback, I have this code and call px4_platform_init in my board_app_initialize, but it doesn't get into px4_platform_console_init. CONFIG_DEV_CONSOLE is not defined. And CONFIG_DEV_NULL also, but according to configuration docs it is set by default, but looks like it doesn't. I'm trying to investigate this further.

@lukegluke See https://github.com/PX4/PX4-Autopilot/blob/master/platforms/nuttx/src/px4/common/px4_init.cpp#L45
This is how we fixed the changes in upstream NuttX that are caused by the dynamic allocation of the streams. When there is no console.

Thanks for feedback! In fact I already had this code and call px4_platform_init in my board_app_initialize. It was just my misconfiguration (I missed that CONFIG_DEV_CONSOLE is set by default, and I need to unset it explicitly). Now this workaround works for me.
But it is still the issue for NuttX itself. I suppose it is not a good thing to fall in hadrdfault if there is no console, or it is failed to open.

As I suspected, I'm getting bit by the same bug. In my case I disabled console since I'm working with a device with inaccessible UART. The moment I do a printf() from my app it crashes. I'm finding that group->nxsched_get_streams also has a NULL head.
I'm not fully understanding if this is a recent problem or something that was always problematic. @davids5 you are using a workaround in PX4, was this reported here? @xiaoxiang781216 what can we do to fix this properly on NuttX?
Note that I'm using master

Ok, I avoided the crash if I do enable DEV_CONSOLE but enable console->syslog redirection. It seems the problem is missing /dev/console. Maybe this shouldn't be an option?
BTW, the config is really confusing, at first glance it appears as if you would be able to make console go to syslog and make syslog go to console simultaneously. The symbol names are even more confusing: CONFIG_CONSOLE_SYSLOG and CONFIG_SYSLOG_CONSOLE. If you enable CONFIG_CONSOLE_SYSLOG, the other option is still selectable. Seems a depends on is missing.

@v01d , Ok, I will provide a patch to preallocate stdin/stdout/stderr, so the printf don't crash at least.

Great. Maybe this could be added as an option to have the console go to /dev/null. Don't know what is easier.

@davids5 you are using a workaround in PX4, was this reported here? @xiaoxiang781216 what can we do to fix this properly on NuttX?

@v01d Yes - years before ASF. But for a different reason. The one you found printf had a side effect. It would write to a file if  0,1,2 are not stdxxxx. Then 0,1,2 becomes the first, second and third file opened in a group. printf corrupts the file. @patacongo rejected my fix at the time. He expected that we should ifdef all the printfs. I disagreed and implemented what I posted.
When https://github.com/apache/incubator-nuttx/pull/1755 came in it broke systems with out a /dev/console. as shown https://github.com/apache/incubator-nuttx/issues/2203#issuecomment-721146799
All the nuttx bootloders in PX4 do not use a console and where hardfaulting in sercon 's printf.
Since my concept was rejected, I saw no point in rehashing the issue.
I agree @xiaoxiang781216 soult fix it properly and we need to test better (we being me too, i missed the bootloader test case when I approved the #1755)
I agree that CONFIG_CONSOLE_* is confusing and we should have a doc that explains all the console options and what is mutually exclusive and why. There should also be code to enforce it.  I think this was cased by organic growth. Unfortunately I have lost context and would have to reverse engineer it and still might misconstrue the intent.

Not really need, it is enough to initialize the preallocated FILE structure to zero, because stdio function will find the flag is invalid and return directly. On the other hand, /dev/null isn't reliable because user can disable /dev/null too.

Not really need, it is enough to initialize the preallocated FILE structure to zero, because stdio function will find the flag is invalid and return directly. On the other hand, /dev/null isn't reliable because user can disable /dev/null too.

@xiaoxiang781216 - that sounds like the way to go.  But please test it.

I will test it as well in my config

I believe this backport PR resolve this issue on 10.0 branch https://github.com/apache/incubator-nuttx/pull/2293


1446 - Created Swagger UI for OpenAPI Specifications

close https://github.com/opendatadiscovery/odd-platform/issues/1446


Updates to kli for External GAR

[x] Fix kli confirm to support multisig delegator
[x] Write credential file to place specified on command line.
[x] Update vc list to prompt for alias when not specified.

Done


Allow queries to be specified in the workflow configuration, overriding those set in the config file

@robertbrignull do you think it's worthwhile adding an integration test for this feature?
In time, this will be extended to allow additive behaviour as well as overriding, but I'm currently planning on doing that in a separate PR.
Furthermore, re overriding - the way that this PR is implemented means that queries in the workflow file (the newly-added feature) take precedence over the configuration file. I think that's what's wanted from the discussion, but do say if I've got this wrong (CC @jhutchings1).
The queries specified in the workflow configuration are comma separated. I'm deliberately not including the ability to escape commas here, as that adds a lot of complexity to support a definite edge case (commas in file names/paths).  This is different than what @robertbrignull and @rneatherway proposed (they wanted escaping), so feel free to push back on this one, Robert and Robin.
Merge / deployment checklist

[x] Confirm this change is backwards compatible with existing workflows.
[x] Confirm the readme has been updated if necessary.

Furthermore, re overriding - the way that this PR is implemented means that queries in the workflow file (the newly-added feature) take precedence over the configuration file. I think that's what's wanted

Yes, I agree.
We want that by default if you see an option in the workflow file then you know exactly what it's doing. Once there's syntax for additive behaviour, then when you see that syntax you know you need to also look in the config file too to fully understand it.
Making the default behaviour to override also means there isn't a difference in behaviour between list-based properties like the queries, and single-valued properties like booleans or strings.

The queries specified in the workflow configuration are comma separated. I'm deliberately not including the ability to escape commas here, as that adds a lot of complexity to support a definite edge case (commas in file names/paths)

I'm mostly ambivalent about escaping. I agree that having commas in one of these options is unlikely so it's definitely an edge case. I also think we should ideally still do it if we can, but we could certainly do it later, or wait until we have a better idea of how much of an edge case it is. So I'd prefer to work with that in mind and try to plan to be compatible for the future, and I think we'll be doing that with this plan so I'm happy.

I'm mostly ambivalent about escaping. I agree that having commas in one of these options is unlikely so it's definitely an edge case. I also think we should ideally still do it if we can, but we could certainly do it later, or wait until we have a better idea of how much of an edge case it is. So I'd prefer to work with that in mind and try to plan to be compatible for the future, and I think we'll be doing that with this plan so I'm happy.

I think I agree with this. However, let's work it through to be sure. Let's imagine that the escaping would work something like:

Input text
Interpreted result

,
<list separator>

\,
,

\\
\

\(?!,)
\

This means that we are at risk if people use backslashes in their configurations, which is presumably quite possible for Windows users. Will they work in paths at the moment? However, the final rule, which is somewhat debatable, basically allows an invalid escape sequence to be treated just as the literal text and means that the only currently "valid" configuration that we would change the behaviour of is a Windows-style paths where one element of the "list" has a trailing backslash. I don't believe that a directory is a valid input as a query specification is it? If not then we're in the clear.
As an example, I think the current implementation would do:
"hello.ql,path\to\,query.ql" => ["hello.ql", "path\to\", "query.ql" ]
and with the above escaping we would instead get:
"hello.ql,path\to\,query.ql" => ["hello.ql", "path\to,query.ql" ]

I don't believe that a directory is a valid input as a query specification is it? If not then we're in the clear.

It sounds like you're saying we would be in the clear if a directory wasn't valid input and we also adopted the escaping rules you specify, rather than saying we're in the clear now.  But I think we are in the clear now (at least in terms of your example).  I'll explain why in a mo, but first to your point about whether directories are allowed:
https://docs.github.com/en/github/finding-security-vulnerabilities-and-errors-in-your-code/configuring-code-scanning#running-additional-queries says:

You can specify a single .ql file, a directory containing multiple .ql files, a .qls query suite definition file, or any combination.

And here's why I think we're doing the right thing.  Taking your example of current behaviour:
"hello.ql,path\to\,query.ql" => ["hello.ql", "path\to\", "query.ql" ]

I think that this is the "right" behaviour.  This output assumes that the input was a file, a directory with a trailing slash, and a file.  I believe that this is a far more likely scenario than "hello.ql,path\to\,query.ql" being intended to mean a file, and a filepath which contains a comma.

Code looks mostly fine but I think there's been a misunderstanding as to what the intended semantics are meant to be. Feel free to disagree if I've got the wrong end of things, but I'll explain how I think it should work.

Your points make sense, @robertbrignull; I think this does need changing.  I'll do that.  Thanks for the detail about a better approach; much appreciated.

It sounds like you're saying we would be in the clear if a directory wasn't valid input and we also adopted the escaping rules you specify, rather than saying we're in the clear now. But I think we are in the clear now (at least in terms of your example). I'll explain why in a mo, but first to your point about whether directories are allowed:

My comment was actually about whether it would be safe to ship this PR as it is and then later add the escaping rules if it turns out that people need them. It was a thought experiment about whether any configurations would have their meaning changed. Thanks for the quote from the docs:

You can specify a single .ql file, a directory containing multiple .ql files, a .qls query suite definition file, or any combination.

This means that as it stands "hello.ql,path\to\,query.ql" => ["hello.ql", "path\to\", "query.ql" ] would be a valid configuration that we would break if we later added escaping, so this PR is not entirely safe in that respect.
To be clear I think the chance of "specifying a directory using windows path separators and a trailing separator" is pretty remote. I was just being thorough.

I believe that this is a far more likely scenario than "hello.ql,path\to\,query.ql" being intended to mean a file, and a filepath which contains a comma.

I agree with this point, however we have to be a bit careful when we make things impossible to express.

Thanks @rneatherway.  I understand what you're getting at now.  I like your checking-for-future-incompatibilities approach 🚀
I think we should solve this by bumping the major version number if we introduce escaping - it's effectively a backwards-incompatible change, and that's what major version numbers are for.  That way, we get to keep the code simple, avoid doing too much in one PR, but still leave the door open for the future.


SerenityJS on Docker

Hello all! I'm trying to create a docker image version on Serenity/JS, any tips of what should I use or do in order for Serenity/JS to run successfully on docker? Thanks! ^_^V

Hey @marktigno! What's your setup like and what are you hoping to accomplish? Would you like to have serenity tests deployed to a docker container together with your system under test, or run them locally via docker?

hello @jan-molak! Thanks for the reply, i like to do both for some reasons:
Scenario 1 -  will be included running on our deployment pipeline and artifact the report generated from there. And Scenario 2 - running them on my local machine to checking newly committed scripts and do maintenance. I have created a Dockerfile that I'm testing on my local machine (CentOS 7 image with NodeJS 8) but Chrome crashes abnormally when I run it.

Hello @jan-molak, I was able to build a Docker image running Serenity/JS on it. I did some trial and error on it and now I successfully run on Docker (yehey!). I'm closing this ticket for now. And if someone likes to ask how I made it then I can share the steps on how to do it on Docker. Thanks! ^_^V

very interested in this as well

@marktigno - that sounds great! Let me know if you'd like to publish your docs on serenity-js.org, or link to them :-)

Hello! Sorry for the delay on this one (went on holiday recently ^_^V). I'm currently creating a docker repo now to enable you all start running your tests on docker. I'll publish the Dockerfile there and steps on how to run it. Thanks! :)

Hi guys! I've created a repo here to upload the docker file: https://github.com/marktigno/serenityjs-docker
This is still a working progress but I'll let you all know once done on this. Thanks!

Hello all! I'm done testing the docker build for the serenityjs-docker version. I've already pushed the a git repo of a running version of serenityjs on the link I've posted before. Next to do is to push the Dockerfile on "https://hub.docker.com/r/marktigno/serenity-js/". Will update on it once done. Thanks! ^_^V

Hello @jan-molak,
Looks like I stumble upon on a problem when I checked the screenshots of the report. It seems the font used on the TodoMVC app is not recognized by the browser or CentOS itself. I have the screenshot attached on this comment. Mind to check on this one? Thanks! :)

Hello all! You may start pulling it from docker: https://hub.docker.com/r/marktigno/serenityjs-docker/
Thanks! ^_^V

Another image for running Serenity within GitlabCI (maybe other CI servers too) can be found here:
https://hub.docker.com/r/paolocarrasco/serenity-js-for-gitlab-ci
It can be used by putting this in the .gitlab-ci.yml:
image: docker.io/paolocarrasco/serenity-js-for-gitlab-ci:<version>

cache:
  paths:
    - node_modules/

stages:
  - build
  - test

build:
  stage: build
  script:
    - npm install

execute-examples:
  stage: test
  script:
    - npm test```


Have all parameters being in configuration files

Describe the bug
some parameters are exposed only in the configuration file, some parameters are exposed only on the command-line, that would good if all parameters exposed to command-line could be set in the configuration file to avoid extra-long cmdline (important thing like replication.
Or perhaps that would be simplier in the code for each setting this is either possible to set it in configuration file or in command-line.
in thr event of both are set, command-line would take offer option set in configuration.
For those using systemd that would also avoid having to run "systemd reload" to take into account change done on the systemd unit files before restarting the unit.

Some related examples

parameter names vary if you're running masternotserver -- -master.peers=... becomes -peers=... etc this is extremely confusing to be certain you're putting data in the right places
there are many apparently overlapping -dir ... settings, at first glance its not clear which ones override others

The parameter names are related to legacy reasons. It is not good to revamp all the parameters which may cause more confusion.
Having parameters set in configuration files will basically add one additional place to set the parameters. It will be harder to tell which value is taking effect.

I understand. How can we make this more clear then?

make it clear in the wiki that config files should be used in preference to command line parameters
make it clear in the wiki which command line parameters aren't found in config files
maybe in some arbitrary future version, issue a deprecation warning for any command-line parameters that are duplicated in config files

fixed in https://github.com/chrislusf/seaweedfs/pull/1823
see see https://github.com/chrislusf/seaweedfs/wiki/Use-Config-File-for-Command-Line-Options


Some HTTPS Feature Requests

I was sitting in @ashfall and @radix's talk at PyTennessee and we discussed adding subdomains or other configurations to httpbin to give people ways to test how clients handle some of the less common corner cases around HTTPS.
Some ideas we had:

Invalid certificates

Hostname mismatch
Expired certificate

Self-signed certificate (no trust chain)

And I'm forgetting the other things. Hopefully they'll help flesh these out and @Runscope/owners can help us figure out what's possible.

We've had similar ideas, but probably at something like tlsbin.org

Yeah! tlsbin makes sense. I wonder if the following also makes sense for features on tlsbin:

A subdomain that supports at best TLSv1.0
The reason being that sometimes the protocols that a client supports are not well documented so having a way to test if your client will support SSLv2/SSLv3 would be convenient. A response from this subdomain could probably at least list the protocols and ciphers that client supports.

A subdomain that does not support either SSLv{2,3} and only TLSv1.0+.

I think a generic GET /detect HTTP/1.1 to tlsbin.org which returns as much information as it can about the client's capabilities and the negotiated protocol/cipher could be simultaneously helpful and redundant. There's already https://www.howsmyssl.com/ but that generally just grades you and gives you similar information about what your client supports.
Thoughts?

Other things:

revoked certs
subdomains that use SNI (maybe all of these domains will use SNI, but specifically users should have a way to know that their client is doing SNI correctly)
also, maybe servers that only support SSL2 or SSL3 so people can test their clients won't be downgraded to those

especially when it comes to proto versions and cipher suites, we could spend all day adding to the feature list, but obviously we have to stop at some point.

https://badssl.com covers a bunch of these and I think it's out of scope for httpbin so I'm going to close this issue.

:+1: Yeah, this was never meant to be implemented in httpbin. It just seemed to be a good related project to brainstorm on. Cheers!


[autoversion] Add new parameter mender-convert-client-version

To let the release responsible update this independently of mender
client tagging.

Updated mender-convert release checklist accordingly.


Updated version

As a temporary fix, I simply downloaded a new version of chromedriver from here.
Would it be better to just make a script for this somewhere? Maybe in __init__.py?

@ToJen would be a solution, but It's even better to have none at all :D


Missing support for unnumbered margin notes

The current sidenote filter does not support unnumbered margin notes. The filter is a reimplementation of the Haskell sidenote filter in Python and does not have feature parity yet.

This is addressed in the most recent update.


updated tests and code to new pandoc 2.0

Readme modified
Tests are passing in pandoc 2.0

fixes #2

Should fix pandoc installation on travis to version 2.0

Coverage remained the same at 95.105% when pulling 2f07092fb836d46fc22ed466c4e26ba179628c8a on updatePandoc2 into 61fc962c861dd80020778564b207524bbc7e39e9 on master.


DBZ-5496: Compatibility with changes in SqlServerConnection API

See https://github.com/debezium/debezium/pull/3881 (DBZ-5585) and https://github.com/debezium/debezium/pull/3874 (DBZ-5496).

@jpechane could you review this, please? It causes build failures at least on two Debezum pull requests: https://github.com/debezium/debezium/pull/3898, https://github.com/debezium/debezium/pull/3901.

I think @jpechane made a change that included this.  Is this safe to close now @morozov ?

As long as it's no longer relevant, it can be closed.


Mark asm code with no-executable-stack.

Newer versions of binutils (2.39 and above) complain if you have assembly without explicitly marking that it is not using an executable stack (see
https://www.redhat.com/en/blog/linkers-warnings-about-executable-stacks-and-segments for more details).  Mark it here to quiet that warning.

CI for this is in https://github.com/ros2/mimick_vendor/pull/32#issuecomment-1644242107

This looks like something that should also be contributed upstream. Would it be appropriate to open a PR there as well?

Yes, agreed.  I will go ahead and do that.
That said, we have a bunch of other patches here (which is why we still have this fork), so I think we'll need to take this PR anyway.  Someday we should clean this up and submit all of our patches upstream.

...I think we'll need to take this PR anyway.

Agreed.

Someday we should clean this up and submit all of our patches upstream.

We can dream.

Do we ever build Mimick with non-GNU toolchains?

Do we ever build Mimick with non-GNU toolchains?

Good question.  We do!  Both MSVC and clang.
In the MSVC case, this definitely won't make a difference, as Mimick uses a different file for Windows (trampoline-x86_64-win.S).
However, there is some possibility this could be a problem with the clang build.  Let's see what CI looks like there (and while we are at it, also RHEL).  I've launched the builds in the other PR, just so the CI is all in one place: https://github.com/ros2/mimick_vendor/pull/32#issuecomment-1652235804

It looks like both MSVC and Clang are OK with this change, so I think this (and https://github.com/ros2/mimick_vendor/pull/32) can be reviewed again.

Here's the upstream PR for tracking purposes: Snaipe/Mimick#38

Thanks!  I'm going to go ahead and merge this one in, then fix up https://github.com/ros2/mimick_vendor/pull/32 to point to the correct hash.

However, there is some possibility this could be a problem with the clang build.

Unfortunately breaks compilation on M1 macs.
[  4%] Building ASM object CMakeFiles/mimick.dir/src/asm/trampoline-aarch64.S.o
/Users/rhys/Code/ros2/rolling/ros2-rolling/src/Mimick/src/asm/trampoline-aarch64.S:80:19: error: unexpected token in '.section' directive
.section .note.GNU-stack, "", @progbits

% clang --version
Apple clang version 14.0.3 (clang-14<IP_ADDRESS>.1)
Target: arm64-apple-darwin22.5.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

/Users/rhys/Code/ros2/rolling/ros2-rolling/src/Mimick/src/asm/trampoline-aarch64.S:80:19: error: unexpected token in '.section' directive

Oh, that's interesting.  It works on aarch64 (gcc), it works on clang (amd64), but it fails on clang aarch64 (at least with that version of clang).  Looking around, this probably has to do with the assembler on macOS: https://stackoverflow.com/questions/59799671/error-unexpected-token-in-section-directive-section-multiboot .
I'm open to ideas on what to do.  I don't have an aarch64 macOS machine to test on, unfortunately.


Disabling clock tooltip has no effect

This config:
{
	"modules-center": ["clock"],
	"clock": {
		"tooltip": false,
	}
}

fails with the tooltip still being visible at hover. While the option tooltip on the clock module is documented in the wiki, it is not in the manpage waybar-clock, so it may not even be implemented. Is this intended behavior? If yes, which reason had the non-implementation?
The tooltip is slightly annoying when switching screens over barrier/waynergy and the cursor stays at the top of the screen, but nothing too bad.

Disabling the tooltip works now, thanks @gemmelos! Will this be documented in the manpage, too? I did not see any change to man/waybar-clock.5.scd in the PR.

Disabling the tooltip works now, thanks @gemmelos! Will this be documented in the manpage, too? I did not see any change to man/waybar-clock.5.scd in the PR.

Good catch, I forgot about that. #1421
(I assumed this was a universal/global option that worked the same for each module, and was documented like this. Seems like it is documented for each module separately)

Nice, thanks!


feat: Data upload: upload a CSV data set

towards #347.
[x] upload a CSV file and map headers.
[x] map administration ID to dosing compartment.
[x] map observations to model variables.
[x] data stratification UI.
[x] data stratification in the Django models (subject groups.)
[x] generate groups of simulations from datasets.
[x] data visualisation.

Siwtiched the Unit and Variable selections around in the previous screenshot. Choosing a variable, then a unit, feels like a more natural interaction (and reduces the number of choices for unit.)


fallen link

link with title "Global Temperature Anomaly" and url "https://www.ncei.noaa.gov/access/monitoring/climate-at-a-glance/national/time-series/globe/land_ocean/ytd/12/1880-2016.json" returns 404

Good catch. Want to make a PR?

done :+1:


Why is path to pos_file required when the path to the log file itself does not exist?

If the path to the log file does not exist, fluentd will happily wait for the path to get created and will start watching the file:
# /usr/bin/fluentd -c example.conf
2016-04-01 20:29:47 +0000 [info]: reading config file path="example.conf"
2016-04-01 20:29:47 +0000 [info]: starting fluentd-0.12.5
2016-04-01 20:29:47 +0000 [info]: gem 'fluent-plugin-add' version '0.0.3'
2016-04-01 20:29:47 +0000 [info]: gem 'fluentd' version '0.12.5'
2016-04-01 20:29:47 +0000 [info]: using configuration file: <ROOT>
  <source>
    @type tail
    path /var/log/_nonexist_/my.log
    tag foobar
    format /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) (?<message>.*)/
    time_format %F %T.%L
  </source>
  <match **>
    type stdout
    output_type json
  </match>
</ROOT>
2016-04-01 20:29:47 +0000 [info]: adding match pattern="**" type="stdout"
2016-04-01 20:29:47 +0000 [info]: adding source type="tail"
2016-04-01 20:29:47 +0000 [warn]: 'pos_file PATH' parameter is not set to a 'tail' source.
2016-04-01 20:29:47 +0000 [warn]: this parameter is highly recommended to save the position to resume tailing.
2016-04-02 20:30:27 +0000 [info]: following tail of /var/log/_nonexist_/my.log
2016-04-02 20:30:27 +0000 fluent.info: {"message":"following tail of /var/log/_nonexist_/my.log"}

However, if the configuration specifies pos_file and the directory does not exist, fluentd errors out with ENOENT:
# /usr/bin/fluentd -c example.conf
2016-04-01 20:33:30 +0000 [info]: reading config file path="example.conf"
2016-04-01 20:33:30 +0000 [info]: starting fluentd-0.12.5
2016-04-01 20:33:30 +0000 [info]: gem 'fluent-plugin-add' version '0.0.3'
2016-04-01 20:33:30 +0000 [info]: gem 'fluentd' version '0.12.5'
2016-04-01 20:33:30 +0000 [info]: using configuration file: <ROOT>
  <source>
    @type tail
    path /var/log/_nonexist_/my.log
    pos_file /var/log/_nonexist_/my.log.pos
    tag foobar
    format /^(?<time>\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\.\d{3}) (?<message>.*)/
    time_format %F %T.%L
  </source>
  <match **>
    type stdout
    output_type json
  </match>
</ROOT>
2016-04-01 20:33:30 +0000 [info]: adding match pattern="**" type="stdout"
2016-04-01 20:33:30 +0000 [info]: adding source type="tail"
2016-04-01 20:33:30 +0000 [error]: unexpected error error_class=Errno::ENOENT error=#<Errno::ENOENT: No such file or directory - /var/log/_nonexist_/my.log.pos>
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/plugin/in_tail.rb:77:in `initialize'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/plugin/in_tail.rb:77:in `open'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/plugin/in_tail.rb:77:in `start'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/root_agent.rb:111:in `block in start'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/root_agent.rb:110:in `each'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/root_agent.rb:110:in `start'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/engine.rb:201:in `start'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/engine.rb:151:in `run'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/supervisor.rb:481:in `run_engine'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/supervisor.rb:140:in `block in start'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/supervisor.rb:266:in `call'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/supervisor.rb:266:in `main_process'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/supervisor.rb:241:in `block in supervise'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/supervisor.rb:240:in `fork'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/supervisor.rb:240:in `supervise'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/supervisor.rb:134:in `start'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/lib/fluent/command/fluentd.rb:167:in `<top (required)>'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require'
  2016-04-01 20:33:30 +0000 [error]: /usr/share/gems/gems/fluentd-0.12.5/bin/fluentd:6:in `<top (required)>'
  2016-04-01 20:33:30 +0000 [error]: /usr/bin/fluentd:23:in `load'
  2016-04-01 20:33:30 +0000 [error]: /usr/bin/fluentd:23:in `<main>'
2016-04-01 20:33:30 +0000 [info]: shutting down fluentd
2016-04-01 20:33:30 +0000 [info]: process finished code=0
2016-04-01 20:33:30 +0000 [warn]: process died within 1 second. exit.

If fluentd knows when the file comes into existence, why can't it wait until the point to create the pos_file?

pos_file is created during start phase so No such file or directory - /var/log/_nonexist_/my.log.pos happens when directory doesn't exist.

I'm not sure what is the problem.

@repeatedly, so are you saying that it is expected that fluentd should fail when a pos file is specified with a missing directory path, but not fail with a log file is specified on the same path?  If so, why?

pos_file is created by fluentd but log file is created by another system.
I think dynamic pos_file creation has no merit.

Huh, so if the log file does not exist yet, but will be created shortly, fluentd dies and won't work.  But once the path to the log file is created, then the pos file could be created.
So why not wait until the log file exists and is actually being tracked by fluentd before creating the pos file?

In other words, don't fail fluentd if a log file does not exist to be tracked.  Once it does exist, fluentd should fail if it can't create the log file, as that would be a bad configuration. And when the file winks out of existence again, the pos file should not be touched or considered.
Does that seem reasonable?

The current use case is for OpenStack.  I have about 17 different OpenStack services I would like to track their log files, but some services run in fail-over modes, where the paths to the log files might not be created yet.  So I don't want to have to update my fluentd configuration file when a service fails over.

Hmm... I can't still imagine what is the problem.
pos_file content is updated after actual log file is created. So creating it during the start phase is no problem.

So I don't want to have to update my fluentd configuration file when a service fails over.

If you know the log file path of fail overed services, writing it in in_tail seems enough.

@repeatedly, in the example posted, the path to the log file does not exist initially, meaning there is a missing directory.  Fluentd does great with that, it just waits patiently for the entire path to come into existence and then it will start tailing the log file.
However, if that log file does not exist, it still tries to create the position file.  Today, I have create a positio file in an existing directory since the position file must be created at startup time.  But if I want to keep my position file with my log file, because I don't readily have another place to keep the position file, I can't use a position file.
So what I am asking is, don't create the position file until fluentd actively starts tailing a log file.  And if the log file disappears, don't access the position file anymore.
That way, I can keep the position file with the log file, and not have to ensure a directory exists just for position files.

But if I want to keep my position file with my log file, because I don't readily have another place to keep the position file, I can't use a position file.

Why? I want to know why you don't want to create position file in existing directory.

@portante pos_file has position in reading in file, and also has inode of files to be tracked. It is required to detect log rotation and others such like that.
If fluentd removes pos_file when tracked file (and its directory), fluentd cannot track log rotation using directory renaming or deleting-and-creating parent directory.

We can implement delay pos_file initialization but it introduces lots of complexity to in_tail, e.g. seperate routines for /path/to/fixed and /path/to/*, avoid race condition and etc.
I think the merit of delay pos_file initialization is smaller than above complexity.

So here is the fluentd configuration we have: https://gist.github.com/portante/407ffdecdfe4326ccfae50e82c075c28
All of these files are log rotated (via logrotate).
We have a jinja template the generates this.  If I add a pos file in the cinder stanzas, creating a file along side the cinder log file, then I can't start fluentd on those boxes because the cinder directory does not exist.
I can create a separate /var/log/fluentd directory and put all the pos files there, but then I'll have pos files created that I don't need.
So should just one the same pos_file /var/log/fluentd/pos.file in each stanza and share it that way?

"Shared pos file" is a kind of idea of "Plugin Storage" which is now I'm developing to introduce it in v0.14.
If @portante can wait it, you can use it.

@tagomoris, sounds good.

@tagomoris, any updates on these related efforts?

I'll be done after #1059 merged (in other words, it's proceeding).

#1395

— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------
— Load RUN 2 ---------------------------------------------------------------

2016-04-01 20:33:30 +0000 [error]: unexpected error error_class=Errno::ENOENT error=#<Errno::ENOENT: No such file or directory - /var/log/_nonexist_/my.log.pos>

Such error doesn't occur on Fluentd 1.14.3, because the directory and pos_file are created automatically.

#1395

Although this feature isn't implemented yet, I think the problem mentioned in this issue is already fixed.
So I close this.


Install chromium on ARM Linux 64

I tried each channel input through a matrix in my github action on a self hosted runner.
$> uname -a
Linux ubuntu 5.15.0-84-generic #93-Ubuntu SMP Tue Sep 5 17:18:46 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

Attempting to download stable...
Acquiring stable from https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
Installing chromium...
/usr/bin/ar x /home/runner/actions-runner/_work/_temp/8a74a472-51ef-4214-b5a7-bcc0aecc9435
/usr/bin/tar -xf /tmp/deb-2ssm7q/data.tar.xz --directory /tmp/chrome-KPYDZd --strip-components 4 ./opt/google
Successfully Installed chromium to /opt/hostedtoolcache/chromium/stable/arm64
/tmp/chrome-KPYDZd/chrome --version
/tmp/chrome-KPYDZd/chrome: 1: Syntax error: ")" unexpected
Error: The process '/tmp/chrome-KPYDZd/chrome' failed with exit code 2

Run browser-actions/setup-chrome@latest
Setup chromium beta
Attempting to download beta...
Acquiring beta from https://dl.google.com/linux/direct/google-chrome-beta_current_amd64.deb
Installing chromium...
/usr/bin/ar x /home/runner/actions-runner/_work/_temp/bca453e9-e2f2-4dcd-a48f-b35586ef5eab
/usr/bin/tar -xf /tmp/deb-EmLAHT/data.tar.xz --directory /tmp/chrome-QgpTT2 --strip-components 4 ./opt/google
Successfully Installed chromium to /opt/hostedtoolcache/chromium/beta/arm64
/tmp/chrome-QgpTT2/chrome --version
/tmp/chrome-QgpTT2/chrome: 15: Syntax error: Unterminated quoted string
Error: The process '/tmp/chrome-QgpTT2/chrome' failed with exit code 2

Run browser-actions/setup-chrome@latest
Setup chromium dev
Attempting to download dev...
Acquiring dev from https://dl.google.com/linux/direct/google-chrome-unstable_current_amd64.deb
Installing chromium...
/usr/bin/ar x /home/runner/actions-runner/_work/_temp/6a44785f-39ae-47b2-abb9-4f8a279997b2
/usr/bin/tar -xf /tmp/deb-8j02vP/data.tar.xz --directory /tmp/chrome-UCtrkl --strip-components 4 ./opt/google
Successfully Installed chromium to /opt/hostedtoolcache/chromium/dev/arm64
/tmp/chrome-UCtrkl/chrome --version
/tmp/chrome-UCtrkl/chrome: 1: Syntax error: Unterminated quoted string
Error: The process '/tmp/chrome-UCtrkl/chrome' failed with exit code 2

Run browser-actions/setup-chrome@latest
Setup chromium canary
Attempting to download canary...
Error: Chrome canary not supported for platform linux arm64

Unfortunately, the setup-action we cannot ARM Linux 64 until the chrome support it. The Google Chrome currently supports only x86_64 for Linux. Please refer to this discussion as well GoogleChromeLabs/chrome-for-testing#1. Thank you.


Fix: Immutability of Int is broken by BigInt method (#332)

The interface of Int assumes the value is immutable but a reference to
its content is leaked through the BigInt() method, which is mutable.
This fix resolves the leak by:

making a copy of the *big.Int in MakeBigInt()
returning a copy of the *big.Int content in BigInt()
creating an internal method bigInt() for internal use that still
returns reference to the internal big.Int

Fixes: #332

No problem! comments have now the fixes requested

No problem! comments have now the fixes requested


Username lookup via email

Currently there appears to be no way for a user who has forgotten the username to look up the username given the email address only. We can build a page similar to the "username -> password reset link" page. It will take an email address, and we will send an email listing all usernames associated with that email address.

Ivan pointed out that we also want to add the username to the "Welcome" email.


Add --include-only/-i option

This PR adds a path filter that can be enabled with --include-only or -i. If given, only linter errors whose paths contain the given string will be output. For instance, if --include-only foo was passed, even if some other property bar that wasn't a child of foo had linter errors, they would not be seen in the output. Internal errors lack path information (since they may not even have anything to do with a particular schema node) and are always output, however.

The PR generally lgtm. Got one question while playing with the function: it prints out all errors when I tried to filter with -i P. Here is the output:
        string "spec.validation.openAPIV3Schema.properties[spec].properties[bar]" missing maxLength
        array "spec.validation.openAPIV3Schema.properties[spec].properties[foo]" missing maxItems
        string "spec.validation.openAPIV3Schema.properties[spec].properties[foo].items" missing maxLength

/lgtm

Few questions:

This PR just supports a simple filter with string match, are we planning to do an exact match on specific field in the future or this would be all?
How it works with multiple files?
Should it be documented if we plan to support other scenarios?
Thanks

Another question:
Since we differentiated the err type in code, should we also support the filter based on error type?

Sorry click the button too soon.
The simple string match filter can be done in other ways instead of a specific flag. Filter based on err type might be more useful for users and maybe adding support for multiple err types would be even better

Few questions:

This PR just supports a simple filter with string match, are we planning to do an exact match on specific field in the future or this would be all?
How it works with multiple files?
Should it be documented if we plan to support other scenarios?
Thanks

I think matching against a specific field in the future might be nice to have, though admittedly I couldn't think of a use case where the simple string match wouldn't also work to some extent. Did you have one in mind?
Right now there's no support for linting multiple files at once in the CLI (it wouldn't be hard to add) - I'd imagine applying the filter flag to multiple files should give the same output as linting each of those files individually with the filter applied, though.
Definitely - the design document isn't public at the moment, so do you think maybe an issue on Github would be better? Or maybe the design doc could be made public.

Sorry click the button too soon. The simple string match filter can be done in other ways instead of a specific flag. Filter based on err type might be more useful for users and maybe adding support for multiple err types would be even better

Being able to filter on error types sounds good to me - were you thinking of an additional flag? Something like:
celvet -i someStr -t limit crd.yaml

That way you could search for a specific string and then do a boolean AND/filter further down to a specific error type, say, cost limit errors. I don't think a boolean OR would be possible with this setup, but maybe that's not a problem.

It would be great to have the design settled before the implementation work. The questions are around what would be the use case, what is the expected behavior(what kind of information user expect), what if multiple CRD files are passed, etc.
Filter based on error type could be a good start. Let's discuss those in the design doc before the implementation work. Thank you :)


option to show shared contexts seperately.

Feature Request
when you have an item with multi @ contexts, it always puts them into their own section which is super annoying, simpletask which is my todo.txt editor for my phone allows you to have them show up under both contexts that they list.
TLDR:
if something has 2+ @ contexts, just list it under both, rather than making a combined group. Best would be a settings option to choose between both behaviours.

Hi @smellymoo . I don't understand what this feature request is about. Can you please help more precise and share examples from Simpletask?

I am unsure if I am using the right word. But when you have a list item, you can put "@" or "+" as category or sub category.
When you give something 2 different "@" categories, it creates a new category just for ones that have both tags. It would be better if it showed up in both categories.
And for users that like it like this, if it had a option to switch mode :). Thank you, love you work, tried the new 2.0 version and it worked well, I will continue to point out any issues.


vscode C# extension version 2.1.2 is buggy. IntelliSense is not working properly. I downgraded to v1.26.0 to resolved the issue.

Environment data
dotnet --info output:
.NET SDK (reflecting any global.json):
Version:   6.0.413
Commit:    10710f7d8e
Runtime Environment:
OS Name:     debian
OS Version:  12
OS Platform: Linux
RID:         debian.12-x64
Base Path:   /usr/share/dotnet/sdk/6.0.413/
global.json file:
Not found
Host:
Version:      6.0.21
Architecture: x64
Commit:       e40b3abf1b
.NET SDKs installed:
6.0.413 [/usr/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.21 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.21 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
VS Code version:
C# Extension version: 2.1.2
Actual behavior
Additional context
Add any other context about the problem here.

Duplicate of https://github.com/dotnet/vscode-csharp/issues/6335


Imported view duplicates echo of async function

Issue summary
When import a view that contains echo with async function, the async function is duplicated after each import.
Expected behavior
Async function should behave the same as sync ones
Steps to reproduce

Open reproduction demo
import_view make the output show 2 async echo

Browser and OS
Additional notes
The more import_view are added, the more duplicated lines
As many extra async functions as there are import_view calls.

This is a race condition, this works fine:
term.clear();
term.echo(async () => `<yellow>this is async function</yellow>`);

setTimeout(() => {
    const view = term.export_view();
    term.clear();
    term.import_view(view);
});

Not sure if this is worth fixing, Maybe just document, to not export view after async echo.

This is more problematic, the solution above only works when the async function does nothing. The export view needs to happen after the function is resolved.


Fix warnings on IAR

Description
This PR fixes the build errors and compilation warnings for the IAR compiler.
Test Steps
Build succeeds without errors or warnings other than unreferenced static functions.
Checklist:

[x] I have tested my changes. No regression in existing tests.
[ ] I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue
Build issues and warnings in IAR build.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/bot run uncrustify


refactor: Migrate Demo Search to use FluentAutocomplete

Pull Request
📖 Description
This refactors away from Listbox -> autocomplete which is keyboard navigable.
I had to make some changes & bug fixes to the autocomplete, however this results in API changes - keen for feedback before I keep going

🎫 Issues

👩💻 Reviewer Notes

📑 Test Plan

✅ Checklist
General

[ ] I have added tests for my changes.
[ ] I have tested my changes.
[ ] I have updated the project documentation to reflect my changes.
[ ] I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

[ ] I have added a new component
[ ] I have added Unit Tests for my new compontent
[ ] I have modified an existing component
[ ] I have validate Unit Tests for an existing component

⏭ Next Steps

I've got some unit tests to write - however the rest should be good to go

Sorry - been a bit busy. Going to find some time to write these tests :)


[ROCm]: Add ROCm command buffer support for triton kernel

@hawkinsp  @jakevdp  Please review. Thanks!


Send flow log to es/db

Hi, can we send flow log to es/tsdb to analyze some issue.

https://github.com/antrea-io/antrea/blob/main/docs/network-flow-visibility.md
ping


Effortsheet integration

Targets #1008
Description

This PR creates a cron job that syncs the effort sheet data with the database.
Added one more field in the user's table ( nickname ) that matches the portal user with the user name in the google sheet.

Note: Need to add google client id in env to link google sheets
Checklist:

[x] I have performed a self-review of my own code.

Looks good to me. @GauravGusain98 you can also take a look and then we should be good to merge the PR.


Implement delete expenditure and list savings and expenditure

This commit contains the code for deleting expenditure and listing savings and expenditure.

Resolves #63 fully


zplug command doesn't work on masOS when installed with brew

Type:

[ ] Bug
[ ] Enhancement
[x] Feature Request
[ ] Question

zplug --version:
zsh --version:
uname -a:

zsh version is : 5.3 (x86_64-apple-darwin17.0)

Instead please install this via recommended way:
curl -sL --proto-redir -all,https https://raw.githubusercontent.com/zplug/installer/master/installer.zsh | zsh

Unfortunately, the installation way from brew is not maintained now. I will delete it from the README in the near future.

@b4b4r07 Could you elaborate on why installation via Homebrew is no longer supported? In my opinion, it is both easier and more robust to install all software using a standard package manager rather than to use a specialized installer for each package.

@b4b4r07 thanks a lot

@raxod502

In my opinion, it is both easier and more robust to install all software using a standard package manager rather than to use a specialized installer for each package.

Basically, I agree with you. However, in many cases it is binary to be distributed but in case of zplug, it's only scripts. In case of zplug, it is easy and suitable to distribute via own installer, I think.
In addition, in the case of zplug, it seems that installation by brew is not used much. Even if we do not abolish it right now, aggressive support may not be done. Please let me organize it once.

Installation via Homebrew is still on the README, and an updated README would have saved me a dozen minutes to find this issue thread.

@b4b4r07 If neither you nor anyone else is willing to support installation via Homebrew, then it's actively harmful for a Homebrew formula to exist. Please consider submitting a pull request to delete the formula, and removing the corresponding documentation from the README.

@Zeta611, after installing via curl were you able to get the zplug command to work? I removed by Homebrew installation and tried the curl installation but it still isn't working for me.

@Baron-burton Yes, installing with curl does work for me.

Instead please install this via recommended way:
curl -sL --proto-redir -all,https https://raw.githubusercontent.com/zplug/installer/master/installer.zsh | zsh

Unfortunately, the installation way from brew is not maintained now. I will delete it from the README in the near future.

Consider this:
brew uninstall zplug
rm -f /Users/*name/.zplug


Nested Routes

Hi guys, How can I use nested Routes? lets say I have a /users route which has various subroutes. If I want to go to /users/:id/reservations/events/ how can I do it? as I understand I will have to add it with Router.add(route, page) however I think it will call again the server the new rendered page, but I dont want to call the server again if I am already in /users page.
Any Ideas?
thanks,
Ed

Hey, please see shallow routing: https://github.com/zeit/next.js/blob/canary/readme.md#shallow-routing
It’s the same option when using Router from next-routes

I'd love to see an example for nested routes support. What would the routes.js file look like to support this? Thanks!


proposal: func (m *sync.Mutex) LockIfNoWait() bool

What version of Go are you using (go version)?

$ go version
go version go1.16.3 darwin/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tyem/Library/Caches/go-build"
GOENV="/Users/tyem/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/tyem/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/tyem/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/4w/l3sttpnj00xctgf981g1t2cr0000gq/T/go-build590339154=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
Try to fix several bugs with locking contention in net/http/h2_bundle.go.
What did you expect to see?
A non-blocking way to test if a mutex is locked.
What did you see instead?
A years-old proposal that was eventually closed due to nobody laying out a convincing enough case to provide such a feature, https://github.com/golang/go/issues/6123.  I was unable to find a way to re-open an old, locked issue so I am raising it fresh now that I believe I can make a convincing case for the need for this feature.
I think fixing several years-old serious lock-up problems with h2 provides a good justification for this functionality.  I believe I have a quite small and simple fix for the following open issues:
x/net/http2: client can hang forever if headers' size exceeds connection's buffer size and server hangs past request time
https://github.com/golang/go/issues/23559
x/net/http2: pool deadlock
https://github.com/golang/go/issues/32388
net/http: a "bad" https connection which uses Header.Set could potentially block all https requests more than 15 mins in production environments
https://github.com/golang/go/issues/33006
x/net/http2: Blocked Write on single connection causes all future calls to block indefinitely
https://github.com/golang/go/issues/33425
To lay out the justification for readers not familiar with any of these bugs...
You have a pool of network connections.
You have a sync.Mutex for preventing races when accessing this pool struct.
Each network connection also has a sync.Mutex for preventing races when accessing the connection struct.
Several operations on the pool need to query the state of one or more connections.
In particular, consider a function for making a new connection that needs to see if any existing connections can be reused.
This function must:
Lock the pool mutex.
Look up existing connections to the same endpoint.
Ask each connection if it is in a state where it can be used for a new connection.
That last question requires looking inside of the connection struct which would require locking the connection's mutex.
Despite a great deal of effort over years, the complexity of a network connection is such that it is still possible for the connection mutex to be locked when an operation that is usually fast is done and then that operation takes a long time, leaving the connection mutex locked for a non-trivial duration.  It is desirable to prevent such situations but there have been so many cases of this and several of them could not be eliminated after years.  So the risk of such is always going to be present.
While having such a problem impact a single connection object is often not much of a problem, having it make it impossible for any new network connections to be made is a very serious problem and we should prevent that.  The problem is so serious that h2_bundle has been disabled in important situations just to avoid this.
If I am holding a lock on the pool's mutex and need to ask the question, "Is this particular connection available to take this request?", then, I believe, the connection's mutex being locked means that I should be able to immediately answer with "No, this connection is not available to take a new request, because it is busy doing something that requires its mutex to be locked.  We hope this situation will progress very quickly to a state where the mutex is no longer locked and at that point we could ask the question again, but, no, right now, the connection is not ready and available."
But sync.Mutex does not currently allow me to code that, and I think it is completely reasonable to allow such.  This can be easily done via the simple addition of:
// LockIfNoWait either locks m immediately if it is not in use, returning
// true, or, when a lock on m is already held, immediately returns false.
func (m *Mutex) LockIfNoWait() bool {
    if atomic.CompareAndSwapInt32(&m.state, 0, mutexLocked) {
        if race.Enabled {
            race.Acquire(unsafe.Pointer(m))
        }
        return true
    }
    return false
}

Such an addition then allows fixes to h2_bundle.go that are also very simple.
Now, even if we do a great deal of complicated work to eliminate all of the places where a connection mutex is held during a call that has a rare chance of taking a bit of time and even convince ourselves that we won't ever let such bugs ever creep in again, I would still prefer that "Is this connection available?" be answered immediately with "no" if the question is asked while the connection's  mutex is held.  Having the "open a new connection" function have to potentially wait for any number of connection mutexes to be unlocked just does not sound like a good strategy for making a pool that provides high performance when there are tons of connections being managed.
One of the places this has happened is holding the connection mutex when the connection is Close()d.  It is completely reasonable for the connection struct to remain locked during such an operation as nothing useful can be done with a connection that is in the process of closing... except, of course, if you need to ask the connection a question and you are in a context where waiting for the answer would tie up all progress for anybody wanting to deal with network connections.
And the cases that cause this to happen are often sudden, ungraceful loss of network connectivity to a service.  In such a case, it doesn't matter much if the mutex for connections to such a server are locked or not because you won't be able to make useful connections to the service anyway (better to try a new connection where that gets done in a way that doesn't hold the new connection's mutex locked).  But having one service failing slowly block all other network connections is terrible.
Another approach would be to have two layers to a connection object and 2 mutexes.  And simple state information would be handled by one mutex and complex information would be handled by another.  You'd have to be very careful to always lock the slow mutex before locking the fast one.  And be very careful about which things are protected by which mutex.  What are the trade-offs of such an approach?  Cons: A great increase in complexity, lots of ways to easily make mistakes about what is fast vs slow, pool operations may have to wait for any number of fast connection mutexes to be unlocked, and fixing the above long-lived serious bugs will take other people spending a long time working on them (vs. me already having a simple fix).  Pros: You don't have to add a basic feature of mutexes that is provided by most other implementations and has been requested by several people and that I've seen lots of reasonable uses for.  (I would have piled on to the request for this myself a few times before this but the issue was already there and locked so I just did a more disruptive design change to work around this basic lack.)
So I'm hoping that case is convincing so I can make more progress on fixing those bugs.
Thanks!

See also #27544.
Personally I think TryLock is a better name than LockIfNoWait.

TryLock appears to be a pretty common name for this.  There were objections to that name in https://github.com/golang/go/issues/6123 so I endeavored to pick a name more in keeping with Go traditions.  But I'm not picky about the name.
I suspect we don't want net/http depending on a 3rd-party module, a solution offered in https://github.com/golang/go/issues/27544.  Though I suppose an alternate mutex implementation (using a channel?) could be bundled into h2_bundle.go (and not exported).  That would be better than not fixing h2 anyway.

You have a pool of network connections.
You have a sync.Mutex for preventing races when accessing this pool struct.

As in #27544, why not replace the sync.Mutex with a 1-buffered channel?
You could even store the pool itself in the channel's buffer, so that the pool isn't even in scope when it isn't locked.
To lock the pool, receive it from the channel.
To unlock the pool, send it back to the channel.
To TryLock, receive in a select with a default case.
(I examine this pattern in much more detail starting around slide 52 of my talk on Rethinking Classical Concurrency Patterns.)

As in #27544, why not replace the sync.Mutex with a 1-buffered channel?

By the same argument, why not replace all sync.Mutexes with channels?

By the same argument, why not replace all sync.Mutexes with channels?

Honestly? I think that's a great idea. 😁
(But we can't remove sync.Mutex because of Go 1 compatibility, and because  it would be a gratuitous breaking change. If we we starting Go over from scratch, I would certainly argue for its omission.)

To avoid a lot of thrash in h2 code, I'd just bundle a replacement implementation of a Mutex using a 1-buffer channel and replace the sync.Mutex on each member with such and use TryLock()...
Why not include such an implementation in sync as a differently named Mutex?  Having a Mutex implemented using a channel sounded like something desirable.  Or just replace the guts of Mutex with a channel-based implementation?

@TyeMcQueen, I would love to see a generic channel-based Mutex implementation. You could even imagine one using typed callbacks, based on the sync.Once signature:
package sync

type TypedMutex[T any] …

func (mu *TypedMutex[T]) Do(func(T) T)
func (mu *TypedMutex[T]) Try(context.Context, func(T) (T, error)) error

Locks are for protecting invariants. If the lock is held by someone else, there is nothing you can say about the invariant.
TryLock encourages imprecise thinking about locks; it encourages making assumptions about the invariants that may or may not be true. That ends up being its own source of races.
There are definitely locking issues in http2. Adding TryLock would let us paper over them to some extent, but even that would not be a real fix. It would be more like the better your 4-wheel-drive the farther out you get stuck.
I don't believe http2 makes a compelling case for TryLock.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

When the question is "Is it ready to be used for another connection?" when it is locked, the precise answer is actually "No, it is not ready".
And I believe that is the better approach even if we eliminated all cases of locks for individual connections being held around blocking operations.  In theory, we could achieve that.  In practice, it hasn't happened for years and I don't see it happening for years more, and once it is achieved, I expect that success to be short-lived (due to the complexity of an h2 connection).
Building a system where a minor mistake leads to serious lock-up is not good design.  In some ways it may be purer; it is not better.
And at least many of the cases of "locking problems" for h2 connections are not really problems when dealing with a single connection (see late in my original, long proposal for more on this) and so I'm not convinced that eliminating them is worthwhile, or at least worth the effort required.
In my experience, preventing the use of techniques because you believe that coders with less skill, care, experience, or judgement may misuse them often leads to even worse approaches being chosen to work around this lack.  So I prefer to document the better approaches and the reasons why a feature should not be used in some way, rather than just prohibit it.  It leads to more learning, not just less frustration.
Shifting gears...
Having spent some time thinking about the several ways we could get a TryLock() available to h2, I think several of the approaches are reasonable.  I think it would be cool to create a channel-based mutex implementation that prevents you from even accessing the object before you obtain the lock and allows you to use a context to even wait "for a while" when trying to obtain a lock.  And, if that proves valuable enough, it would be cool to include that in the standard go library (perhaps so it can be used by other things in the standard go library).  But I also think such would need time to prove that it deserves such inclusion.  And I probably wouldn't replace sync.Mutex with that implementation.  The simpler (and probably more efficient version) is probably worth having for when you don't need more.
But I now really do believe that even with alternatives out there in other libraries, this very specific, very simple addition to sync.Mutex is really something that should be added.  (In the beginning, I was less convinced of that, more just wanting to fix serious problems in h2.)
It is quite easy to start using sync.Mutex because it is a perfect fit for your situation and then come to a place where "I want to do X, but if I can't do it right now, I don't want to do anything, and waiting would be a terrible choice".  And it is a sign of respect for the users of our language to give them the option to use TryLock() to get their work done while they file a "technical debt" ticket to rework how locking is done because the design has shifted to the point that a simple Mutex is not the best fit any longer.  Will this lead to that technical debt never getting fixed?  Surely it sometimes will.  But the better way to encourage such design improvements is documentation, not prohibition.
I've personally run into this situation twice already that I can remember.  Forcing the more significant redesign just to get past this hurdle was not helpful to me.  And it didn't even always lead to a better design, just one that didn't need TryLock().
There really are situations where Lock, Unlock, and TryLock is just exactly what you need.  Those situations can also be satisfied with channels and semaphores and other more complex and powerful things.  If you need to ask "Are you still busy?", that's a perfectly reasonable question to be able to ask.  And if the thing you need to ask that of is just one thing and you also need a mutex around it and that mutex already perfectly captures "Yes, I'm busy", let people do that.
Just TryLock() is not enough to warrant a whole separate abstraction.  This is reinforced by how easy it is to implement for sync.Mutex.
So I like having Lock, Unlock, and TryLock as one set of features over having Lock+Unlock in one object and Lock+Unlock+TryLock in another.  And I like having such a simple thing, not just an all-singing, all-dancing thing that can also be used as a mutex.

It is easy to build a TryLock-able Mutex out of a Mutex and an atomic word. It is probably worth doing that in http2 to see if it solves your problem.
Adding TryLock just for http2 does not seem worthwhile. We would need a more compelling case.

@rsc I've seen variations of this across several commercial projects I've been involved in. And while I agree that TryLock is not an example of "good code" maybe it can be added just for the sake of preventing people from using such hacks. Although

It is easy to build a TryLock-able Mutex out of a Mutex and an atomic word

Maybe it would be a good idea to implement reference implementation inside x/sync?

Thinking more about this, there is one important benefit to building TryLock into Mutex compared to a wrapper:
failed TryLock calls wouldn't create spurious happens-before edges to confuse the race detector.
I'm still not convinced we should do this, but I put together a CL to see what it would look like at https://golang.org/cl/319769.
/cc @dvyukov for thoughts

FWIW, the gVisor project uses a modified sync package with TryLock and came up with an implementation almost 100% identical to @rsc's: https://cs.opensource.google/gvisor/gvisor/+/master:pkg/sync/rwmutex_unsafe.go;l=109?ss=gvisor%2Fgvisor

I think that TryLock is almost always an indication of sloppy thinking about invariants, but I'm not convinced that it's always a mistake. And I'd rather see a single TryLock implementation that can be reasoned about rather than many custom ones.
A channel-based implementation as @bcmills suggests is possible, but performs poorly in comparison. There's a reason we have sync.Mutex rather than just using channel for locking.

I don't have much to add. Yes, TryLock may be needed in some cases; yes, it's needed very rarely in Go; yes, part of the current uses is papering over sub-optimal design; yes, an implementation in std lib can cooperate with race detector, with starvation prevention logic in Mutex, with contention profiler; yes, adding TryLock to std lib will increase number of unjustified uses.
I've searched our internal code base for "TryLock() bool" and found:

gvisor
https://pkg.go.dev/v.io/x/lib/nsync#Mu.TryLock
https://github.com/trivago/tgo/blob/master/tsync/mutex.go#L53
and one internal implementation build on a channel
So it's not much, frankly I expected to find more. But I did not look how/where they are used.

I need TryRLock() for the mnm client app. I can explain the use case if asked.
It's not trivial to implement with a wrapper.

OK, I retract my objections. Everyone agrees it's unfortunate but sometimes necessary.
Does anyone else object to adding it?

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

Can it be exposed in x/sync instead?

@kaey what is the point for that?

Re: https://golang.org/cl/319769
Will this make to 1.17, or it is too late, sorry?

We are in the feature freeze for 1.17.  This will be for 1.18.

This is a good idea. I definitely can see my team using this for our internal tooling.

Kindly ping @rsc and @ianlancetaylor about https://golang.org/cl/319769

I like this idea.

Another potential advantage of TryLock is: If you TryLock something, and get false, you can report the circumstances and reasoning that led you to believe that a lock should have succeeded, even if there's nothing else you can do.

FYI, I believe the HTTP/2 client bugs listed in the original issue (#23559, #32388, #33006, #33425) have all been fixed now, without using TryLock. This isn't an argument against adding TryLock, just a data point that it wasn't needed here.


NOISSUE: fix metrics

- What I did
fix metrics rate and datasource
- How I did it
- How to verify it
- Description for the changelog

Codecov Report

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

@@           Coverage Diff           @@
##           master     #169   +/-   ##
=======================================
  Coverage   72.70%   72.70%
=======================================
  Files          55       55
  Lines        3851     3851
=======================================
  Hits         2800     2800
  Misses        896      896
  Partials      155      155

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 8bd3e16...45035eb. Read the comment docs.


Binance Run no longer shows Candlestick or fibonacci details in logs

Describe the bug
I am currently running the v.2.13.3 bot for binance api and the following is my run command.
To Reproduce
Steps to reproduce the behavior:

Run the below command
Check for candlestick close (based on granularity) related information.

rm pycryptobot.log; rm orders.csv; git reset --hard; git pull; clear; python3 pycryptobot.py --market LTCBUSD --live 1 --verbose 0 --graphs 1  --sellatloss 1 --selllowerpcnt "-2"

When running this bot, i have seen through around 8 hours of run and I do not see any information about possible BUY or SELL strategies. Or even the candlestick close position details which would usually say ' Last Action WAIT'
Example log:

2021-05-26 03:45:00 | LTCBUSD | 15m | Close: 191.21 | ^ EMA12/26: 188.3225 > 184.9816 ^ | ^ MACD: 3.3408 > 3.0712 ^ | WAIT | Last Action: BUY | -7.5552% (delta: -15.42)

Here is the full logs where the above example never prints:

                       Python Crypto Bot
          Release : v2.13.3
         Bot Mode : LIVE - live trades using your funds!
      Bot Started : 2021-05-26 15:13:37.462783

2021-05-26 15:15:40 | LTCBUSD | 1h | Current Price: 199.55
2021-05-26 15:17:42 | LTCBUSD | 1h | Current Price: 198.82
2021-05-26 15:19:43 | LTCBUSD | 1h | Current Price: 198.87
2021-05-26 15:21:45 | LTCBUSD | 1h | Current Price: 199.44
2021-05-26 15:23:46 | LTCBUSD | 1h | Current Price: 199.98
2021-05-26 15:25:48 | LTCBUSD | 1h | Current Price: 200.26
2021-05-26 15:27:49 | LTCBUSD | 1h | Current Price: 200.45
2021-05-26 15:29:51 | LTCBUSD | 1h | Current Price: 199.78
2021-05-26 15:31:52 | LTCBUSD | 1h | Current Price: 200.35
2021-05-26 15:33:54 | LTCBUSD | 1h | Current Price: 200.22
2021-05-26 15:35:55 | LTCBUSD | 1h | Current Price: 200.21
2021-05-26 15:37:57 | LTCBUSD | 1h | Current Price: 200.31
2021-05-26 15:39:58 | LTCBUSD | 1h | Current Price: 201.89
2021-05-26 15:42:00 | LTCBUSD | 1h | Current Price: 201.0
2021-05-26 15:44:01 | LTCBUSD | 1h | Current Price: 201.68
2021-05-26 15:46:03 | LTCBUSD | 1h | Current Price: 201.37
2021-05-26 15:48:04 | LTCBUSD | 1h | Current Price: 201.25
2021-05-26 15:50:06 | LTCBUSD | 1h | Current Price: 200.76
2021-05-26 15:52:08 | LTCBUSD | 1h | Current Price: 201.24
2021-05-26 15:54:09 | LTCBUSD | 1h | Current Price: 201.54
2021-05-26 15:56:11 | LTCBUSD | 1h | Current Price: 202.07
2021-05-26 15:58:13 | LTCBUSD | 1h | Current Price: 203.6
2021-05-26 16:02:16 | LTCBUSD | 1h | Current Price: 203.19
2021-05-26 16:04:18 | LTCBUSD | 1h | Current Price: 203.65
2021-05-26 16:06:20 | LTCBUSD | 1h | Current Price: 200.84
2021-05-26 16:08:22 | LTCBUSD | 1h | Current Price: 199.21
2021-05-26 16:10:23 | LTCBUSD | 1h | Current Price: 198.91
2021-05-26 16:12:25 | LTCBUSD | 1h | Current Price: 196.85
2021-05-26 16:14:27 | LTCBUSD | 1h | Current Price: 198.2
2021-05-26 16:16:29 | LTCBUSD | 1h | Current Price: 196.89
2021-05-26 16:18:31 | LTCBUSD | 1h | Current Price: 197.05
2021-05-26 16:20:32 | LTCBUSD | 1h | Current Price: 197.46
2021-05-26 16:22:34 | LTCBUSD | 1h | Current Price: 198.44
2021-05-26 16:24:36 | LTCBUSD | 1h | Current Price: 198.0
2021-05-26 16:26:37 | LTCBUSD | 1h | Current Price: 198.41
2021-05-26 16:28:39 | LTCBUSD | 1h | Current Price: 199.59
2021-05-26 16:30:40 | LTCBUSD | 1h | Current Price: 199.97
2021-05-26 16:32:42 | LTCBUSD | 1h | Current Price: 200.58
2021-05-26 16:34:43 | LTCBUSD | 1h | Current Price: 201.57
2021-05-26 16:36:45 | LTCBUSD | 1h | Current Price: 202.08
2021-05-26 16:38:47 | LTCBUSD | 1h | Current Price: 202.5
2021-05-26 16:40:49 | LTCBUSD | 1h | Current Price: 200.8
2021-05-26 16:42:50 | LTCBUSD | 1h | Current Price: 200.66
2021-05-26 16:44:52 | LTCBUSD | 1h | Current Price: 200.26
2021-05-26 16:46:53 | LTCBUSD | 1h | Current Price: 199.58
2021-05-26 16:48:55 | LTCBUSD | 1h | Current Price: 198.5
2021-05-26 16:50:57 | LTCBUSD | 1h | Current Price: 199.69
2021-05-26 16:52:58 | LTCBUSD | 1h | Current Price: 199.56
2021-05-26 16:54:59 | LTCBUSD | 1h | Current Price: 199.76
2021-05-26 16:57:01 | LTCBUSD | 1h | Current Price: 198.7
2021-05-26 16:59:02 | LTCBUSD | 1h | Current Price: 199.83
2021-05-26 17:03:05 | LTCBUSD | 1h | Current Price: 200.84
2021-05-26 17:05:07 | LTCBUSD | 1h | Current Price: 200.51
2021-05-26 17:07:09 | LTCBUSD | 1h | Current Price: 201.15
2021-05-26 17:09:10 | LTCBUSD | 1h | Current Price: 201.62
2021-05-26 17:11:12 | LTCBUSD | 1h | Current Price: 201.66
2021-05-26 17:13:14 | LTCBUSD | 1h | Current Price: 201.23
2021-05-26 17:15:15 | LTCBUSD | 1h | Current Price: 201.0
2021-05-26 17:17:17 | LTCBUSD | 1h | Current Price: 202.01
2021-05-26 17:19:19 | LTCBUSD | 1h | Current Price: 202.2
2021-05-26 17:21:20 | LTCBUSD | 1h | Current Price: 201.27
2021-05-26 17:23:22 | LTCBUSD | 1h | Current Price: 200.79
2021-05-26 17:25:23 | LTCBUSD | 1h | Current Price: 200.24
2021-05-26 17:27:25 | LTCBUSD | 1h | Current Price: 200.04
2021-05-26 17:29:26 | LTCBUSD | 1h | Current Price: 199.6
2021-05-26 17:31:28 | LTCBUSD | 1h | Current Price: 200.0
2021-05-26 17:33:29 | LTCBUSD | 1h | Current Price: 198.91
2021-05-26 17:35:31 | LTCBUSD | 1h | Current Price: 199.2
2021-05-26 17:37:32 | LTCBUSD | 1h | Current Price: 200.46
2021-05-26 17:39:34 | LTCBUSD | 1h | Current Price: 200.2
2021-05-26 17:41:35 | LTCBUSD | 1h | Current Price: 199.18
2021-05-26 17:43:37 | LTCBUSD | 1h | Current Price: 199.67
2021-05-26 17:45:39 | LTCBUSD | 1h | Current Price: 200.38
2021-05-26 17:47:41 | LTCBUSD | 1h | Current Price: 200.99
2021-05-26 17:49:42 | LTCBUSD | 1h | Current Price: 201.37
2021-05-26 17:51:44 | LTCBUSD | 1h | Current Price: 201.76
2021-05-26 17:53:46 | LTCBUSD | 1h | Current Price: 202.33
2021-05-26 17:55:47 | LTCBUSD | 1h | Current Price: 201.37
2021-05-26 17:57:49 | LTCBUSD | 1h | Current Price: 201.5
2021-05-26 17:59:51 | LTCBUSD | 1h | Current Price: 200.01
2021-05-26 18:03:54 | LTCBUSD | 1h | Current Price: 201.39
2021-05-26 18:05:55 | LTCBUSD | 1h | Current Price: 200.89
2021-05-26 18:07:57 | LTCBUSD | 1h | Current Price: 198.33
2021-05-26 18:09:59 | LTCBUSD | 1h | Current Price: 197.58
2021-05-26 18:12:00 | LTCBUSD | 1h | Current Price: 199.13
2021-05-26 18:14:02 | LTCBUSD | 1h | Current Price: 198.6
2021-05-26 18:16:04 | LTCBUSD | 1h | Current Price: 198.31
2021-05-26 18:18:05 | LTCBUSD | 1h | Current Price: 199.12
2021-05-26 18:20:07 | LTCBUSD | 1h | Current Price: 199.55
2021-05-26 18:22:08 | LTCBUSD | 1h | Current Price: 200.49
2021-05-26 18:24:10 | LTCBUSD | 1h | Current Price: 199.21
2021-05-26 18:26:12 | LTCBUSD | 1h | Current Price: 199.96
2021-05-26 18:28:13 | LTCBUSD | 1h | Current Price: 198.67
2021-05-26 18:30:15 | LTCBUSD | 1h | Current Price: 198.32
2021-05-26 18:32:16 | LTCBUSD | 1h | Current Price: 199.16
2021-05-26 18:34:18 | LTCBUSD | 1h | Current Price: 198.17
2021-05-26 18:36:19 | LTCBUSD | 1h | Current Price: 199.51
2021-05-26 18:38:21 | LTCBUSD | 1h | Current Price: 199.66
2021-05-26 18:40:23 | LTCBUSD | 1h | Current Price: 198.96
2021-05-26 18:42:24 | LTCBUSD | 1h | Current Price: 198.82
2021-05-26 18:44:26 | LTCBUSD | 1h | Current Price: 198.3
2021-05-26 18:46:27 | LTCBUSD | 1h | Current Price: 199.58
2021-05-26 18:48:29 | LTCBUSD | 1h | Current Price: 199.34
2021-05-26 18:50:30 | LTCBUSD | 1h | Current Price: 199.39
2021-05-26 18:52:32 | LTCBUSD | 1h | Current Price: 199.55
2021-05-26 18:54:34 | LTCBUSD | 1h | Current Price: 198.02
2021-05-26 18:56:35 | LTCBUSD | 1h | Current Price: 198.58
2021-05-26 18:58:37 | LTCBUSD | 1h | Current Price: 198.11
2021-05-26 19:02:40 | LTCBUSD | 1h | Current Price: 198.19
2021-05-26 19:04:41 | LTCBUSD | 1h | Current Price: 197.87
2021-05-26 19:06:43 | LTCBUSD | 1h | Current Price: 198.35
2021-05-26 19:08:44 | LTCBUSD | 1h | Current Price: 197.06
2021-05-26 19:10:46 | LTCBUSD | 1h | Current Price: 197.78
2021-05-26 19:12:47 | LTCBUSD | 1h | Current Price: 196.86
2021-05-26 19:14:49 | LTCBUSD | 1h | Current Price: 197.5
2021-05-26 19:16:51 | LTCBUSD | 1h | Current Price: 197.91
2021-05-26 19:18:52 | LTCBUSD | 1h | Current Price: 198.0
2021-05-26 19:20:54 | LTCBUSD | 1h | Current Price: 198.83
2021-05-26 19:22:55 | LTCBUSD | 1h | Current Price: 198.6
2021-05-26 19:24:57 | LTCBUSD | 1h | Current Price: 198.07
2021-05-26 19:26:58 | LTCBUSD | 1h | Current Price: 199.0
2021-05-26 19:29:00 | LTCBUSD | 1h | Current Price: 198.83
2021-05-26 19:31:02 | LTCBUSD | 1h | Current Price: 198.55
2021-05-26 19:33:04 | LTCBUSD | 1h | Current Price: 198.62
2021-05-26 19:35:06 | LTCBUSD | 1h | Current Price: 198.6
2021-05-26 19:37:07 | LTCBUSD | 1h | Current Price: 198.55
2021-05-26 19:39:09 | LTCBUSD | 1h | Current Price: 198.43
2021-05-26 19:41:11 | LTCBUSD | 1h | Current Price: 198.71
2021-05-26 19:43:13 | LTCBUSD | 1h | Current Price: 198.2
2021-05-26 19:45:15 | LTCBUSD | 1h | Current Price: 198.67
2021-05-26 19:47:17 | LTCBUSD | 1h | Current Price: 198.12
2021-05-26 19:49:19 | LTCBUSD | 1h | Current Price: 198.11
2021-05-26 19:51:21 | LTCBUSD | 1h | Current Price: 197.88
2021-05-26 19:53:23 | LTCBUSD | 1h | Current Price: 198.59
2021-05-26 19:55:25 | LTCBUSD | 1h | Current Price: 198.59
2021-05-26 19:57:26 | LTCBUSD | 1h | Current Price: 199.19
2021-05-26 19:59:28 | LTCBUSD | 1h | Current Price: 200.19
2021-05-26 20:03:31 | LTCBUSD | 1h | Current Price: 199.8
2021-05-26 20:05:33 | LTCBUSD | 1h | Current Price: 200.2
2021-05-26 20:07:34 | LTCBUSD | 1h | Current Price: 200.97
2021-05-26 20:09:36 | LTCBUSD | 1h | Current Price: 201.62
2021-05-26 20:11:38 | LTCBUSD | 1h | Current Price: 201.85
2021-05-26 20:13:40 | LTCBUSD | 1h | Current Price: 201.49
2021-05-26 20:15:41 | LTCBUSD | 1h | Current Price: 201.45
2021-05-26 20:17:43 | LTCBUSD | 1h | Current Price: 201.66
2021-05-26 20:19:45 | LTCBUSD | 1h | Current Price: 201.77
2021-05-26 20:21:46 | LTCBUSD | 1h | Current Price: 202.02
2021-05-26 20:23:48 | LTCBUSD | 1h | Current Price: 202.4
2021-05-26 20:25:50 | LTCBUSD | 1h | Current Price: 202.02
2021-05-26 20:27:51 | LTCBUSD | 1h | Current Price: 201.99
2021-05-26 20:29:53 | LTCBUSD | 1h | Current Price: 202.18
2021-05-26 20:31:55 | LTCBUSD | 1h | Current Price: 201.76
2021-05-26 20:33:56 | LTCBUSD | 1h | Current Price: 201.27
2021-05-26 20:35:58 | LTCBUSD | 1h | Current Price: 200.43
2021-05-26 20:38:00 | LTCBUSD | 1h | Current Price: 200.22
2021-05-26 20:40:02 | LTCBUSD | 1h | Current Price: 200.55
2021-05-26 20:42:03 | LTCBUSD | 1h | Current Price: 201.49
2021-05-26 20:44:05 | LTCBUSD | 1h | Current Price: 201.07
2021-05-26 20:46:07 | LTCBUSD | 1h | Current Price: 200.85
2021-05-26 20:48:08 | LTCBUSD | 1h | Current Price: 201.18
2021-05-26 20:50:10 | LTCBUSD | 1h | Current Price: 200.91
2021-05-26 20:52:11 | LTCBUSD | 1h | Current Price: 200.56
2021-05-26 20:54:13 | LTCBUSD | 1h | Current Price: 200.76
2021-05-26 20:56:15 | LTCBUSD | 1h | Current Price: 201.38
2021-05-26 20:58:17 | LTCBUSD | 1h | Current Price: 201.37
2021-05-26 21:02:20 | LTCBUSD | 1h | Current Price: 199.93
2021-05-26 21:04:21 | LTCBUSD | 1h | Current Price: 198.34
2021-05-26 21:06:23 | LTCBUSD | 1h | Current Price: 197.39
2021-05-26 21:08:25 | LTCBUSD | 1h | Current Price: 197.32
2021-05-26 21:10:26 | LTCBUSD | 1h | Current Price: 197.49
2021-05-26 21:12:28 | LTCBUSD | 1h | Current Price: 196.23
2021-05-26 21:14:30 | LTCBUSD | 1h | Current Price: 196.38
2021-05-26 21:16:31 | LTCBUSD | 1h | Current Price: 194.99
2021-05-26 21:18:33 | LTCBUSD | 1h | Current Price: 195.45
2021-05-26 21:20:35 | LTCBUSD | 1h | Current Price: 193.91

Here is my config file if that is required :

{
"binance" : {
"api_url" : "https://api.binance.com",
"api_key" : "",
"api_secret" : "",
"config" : {
"base_currency" : "LTC",
"quote_currency" : "BUSD",
"granularity" : "1h",
"live" : 0,
"sellatloss" : 0,
"disablebullonly" : 1,
"disablebuyobv" : 1,
"disablebuyelderray" : 1,
"disablelog" : 1,
"disabletracker" : 1
}
},
"telegram" : {
"token" : "",
"client_id" : ""
}
}

Expected behavior
The weird part is the simulation did show the fibonacci and retracement values.
Attaching the sample logs for the simulation.
SimulationPyCryptoBotv2.13.3.pdf
I had previously been using v.2.7.0 which did not face this issue (the CLOSE and the MACD, fibonacci values did get printed).
System Information
OS: macOS Catalina
Version v10.15.7 (19H1030)

Seems to be removed here: https://github.com/whittlem/pycryptobot/commit/cd52fbe19cc52c15ca6fd478c4b38718d263cfad#diff-e993188fef490d7c7a77635e2d96ab6c07beb3af5dbb4457aa89ad002f93e625L611
Weird thing, I'm also used to see this kind of output, the logging approach does nothing for me ATM.

The log entries should be still saved in the log and output in the console. I believe the purpose of the PR was to not have two separate parts to log and to print but to unify the messages. Are you still seeing the expected full output printed to the screen? Is this only related to what is being logged to the log file?

Actually I know why I didn't use INFO because a lot of non bot messaging was being included in the logs. I'll change that back to DEBUG now.

Should be fixed now. Please confirm?

Sorry i waited for the next 15m cycle to check if it prints the candle close values, but it does not.
Here is the latest run using the latest pull.

cryptobot % ./runLTCBUSD.sh
rm: pycryptobot.log: No such file or directory
rm: orders.csv: No such file or directory
HEAD is now at 7f36821 changed logging.info back to logging.debug
Already up to date.

                        Python Crypto Bot
          Release : v2.13.5
        Bot Mode : LIVE - live trades using your funds!
      Bot Started : 2021-05-26 22:37:06.405568

2021-05-26 22:39:09 | LTCBUSD | 15m | Current Price: 194.28
2021-05-26 22:41:11 | LTCBUSD | 15m | Current Price: 194.34
2021-05-26 22:43:12 | LTCBUSD | 15m | Current Price: 193.92
2021-05-26 22:47:15 | LTCBUSD | 15m | Current Price: 194.5

My parameters is same as before, just added a 15m granularity to check through the output.
I am guessing the issue is probably not due to the logging.debug / logging.info changes.
Are there any recent changes to the API calls at the end of candlestick times? e.g. at every 15m or at every 1h intervals?

I didn't read through the entire thread, but I noticed a similar behaviour.
Looking at the code, I noticed that in this line the variable current_df_index is compared against state.last_df_index to be different, when earlier they are being set to be identical. Now, I didn't go through the logic of that condition, but this feels odd.

Thanks @yanone, but I don't think that is an issue. That is expected and the bot would not work at all if there was an issue there.
I'm not seeing this issue myself. I'll ask in the Telegram chat if anyone else is experiencing this.

I'm also no longer seeing the following output:
2021-05-26 03:45:00 | LTCBUSD | 15m | Close: 191.21 | ^ EMA12/26: 188.3225 > 184.9816 ^ | ^ MACD: 3.3408 > 3.0712 ^ | WAIT | Last Action: BUY | -7.5552% (delta: -15.42)

Seems to be removed here: https://github.com/whittlem/pycryptobot/commit/cd52fbe19cc52c15ca6fd478c4b38718d263cfad#diff-e993188fef490d7c7a77635e2d96ab6c07beb3af5dbb4457aa89ad002f93e625L611 - which would be good if the logging would work for me, but I can't get the bot to output anything via logging. All I get is the output via print().
Can we get this particula print(output_text) back, please?

@whittlem  - Can we get back the print line as mentioned by @happz - So that we can see the various conditions the bots is taking before deciding on whether to BUY , WAIT or SELL.

Is this still a problem?


prevent empty interfaces and configs

- What this PR does and why is it needed
follow up to #446 PR to update manifests and update unit-test
fixes #444

/assign @martinkennelly

/lgtm