bosh-dns can't resolve dns records with instance index number although director.local_dns.include_index is enabled

@cppforlife
Our environments rely on instance index based DNS records, so I enabled local_dns.include_index property in the Director job.
    director:
      local_dns:
        enabled: true
        include_index: true

But the instance index based DNS records like 0.nats.default.gubin-cf-new.bosh can't be resolved by bosh-dns on the vm where bosh-dns job is deployed.
# nslookup 0.nats.default.gubin-cf-new.bosh
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53

*** Can't find 0.nats.default.gubin-cf-new.bosh: No answer

But it can resolve dns records with instance ID:
# nslookup fdee12da-da5c-4254-8768-1ef188918098.nats.default.gubin-cf-new.bosh
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53

Name:	fdee12da-da5c-4254-8768-1ef188918098.nats.default.gubin-cf-new.bosh
Address: <IP_ADDRESS>

I checked /var/vcap/instance/dns/records.json and found the instance index based DNS records like 0.nats.default.gubin-cf-new.bosh are only propagated in the "records" section
  "records": [
    [
      "<IP_ADDRESS>",
      "fdee12da-da5c-4254-8768-1ef188918098.nats.default.gubin-cf-new.bosh"
    ],
    [
      "<IP_ADDRESS>",
      "0.nats.default.gubin-cf-new.bosh"
    ],
...

But bosh-dns only resolves the records in "record_infos" section. Only dns records with instance ID like fdee12da-da5c-4254-8768-1ef188918098.nats.default.gubin-cf-new.bosh are propagated in the "record_infos" section.
I tried to add 0.nats.default.gubin-cf-new.bosh to "record_infos" section copying fdee12da-da5c-4254-8768-1ef188918098.nats.default.gubin-cf-new.bosh's example with "id" changed to "0". After that, bosh-dns can resolve 0.nats.default.gubin-cf-new.bosh:
# nslookup 0.nats.default.gubin-cf-new.bosh
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53

Name:	0.nats.default.gubin-cf-new.bosh
Address: <IP_ADDRESS>

Would you please also propagate the  instance index based DNS records like 0.nats.default.gubin-cf-new.bosh to "record_infos" section in /var/vcap/instance/dns/records.json?
Also, would you please remove the records in /etc/hosts? I believe this is not needed when bosh-dns is deployed and will cause confusion in the case when I can ping 0.nats.default.gubin-cf-new.bosh (record is in /etc/hosts) but indeed bosh-dns can't resolve it (nslookup fails).
Thanks.
/cc @maximilien  @mattcui

@cppforlife Any comments?

@cppforlife Any comments for this issue? Thanks.

@gu-bin looks like it's not being honored even though loaded in https://github.com/cloudfoundry/bosh-dns-release/blob/fcca7163423cac73398898d3c7f27d27e17dcd30/src/bosh-dns/dns/server/records/record_set.go#L258-L259. i think we should add this feature.

We tried on bosh-dns release 1.10.0 and the problem is still not fixed. Do you have any plan when it will be fixed? Thanks.
It can resolve dns records with instance ID:
nslookup 7f5b5ad5-c2b3-4650-9a0e-4ce3e2775fae.uaadb.default.stage0.microbosh
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53

Name:	7f5b5ad5-c2b3-4650-9a0e-4ce3e2775fae.uaadb.default.stage0.microbosh
Address: <IP_ADDRESS>

But can't resolve dns records with instance index:
nslookup 1.uaadb.default.stage0.microbosh
Server:		<IP_ADDRESS>
Address:	<IP_ADDRESS>#53

*** Can't find 1.uaadb.default.stage0.microbosh: No answer

@gu-bin we have not looked into this and since indices are not recommended (the UUIDs are preferred), we're not planning on working on this. If you are interested in this functionality, feel free to look into it yourself and submitting a pull request. If it's a small enough set of changes, we can likely merge and support it.

is there a way then to look up all the instances of an instance_group using a "dig" so for example, I want to know all the *.uaadb.default.stage.bosh?  I know there are 3 instances but I don't know the GUIDs so how can I look them up with the GUID if I don't know them?

@andrew-edgar currently you'd need to consume a link and iterate over link('uaadb').instances if you wanted individual GUIDs. However, typically you should be addressing a link by it's general hostname, not by individual VMs. Can you explain more about the use case you're working with? We might be able to find an alternative.


Ignoring ! char in ACL name of use_backend clause

Should be fixing #2 temporarily until a better solution is found
Also added ability to generate a Hash for each object for comparisson and extended parsing a bit

Thanks for your adding great work!
Can I merge it now?

Yes, go ahead

Merged.
Thank you.


Errors you may encounter when upgrading this dependency

Dependency that may cause problem:
github.com/urfave/cli
-Latest Version: v2.2.0   (Latest commit d648edd on 6 Mar)
-Where did you use it:
https://github.com/remind101/empire/search?q=urfave%2Fcli&unscoped_q=urfave%2Fcli
-Detail:

github.com/urfave/cli/go.mod

module github.com/urfave/cli/v2
go 1.11
require (
	github.com/BurntSushi/toml v0.3.1
	github.com/cpuguy83/go-md2man/v2 v2.0.0-20190314233015-f79a8a8ca69d
	gopkg.in/yaml.v2 v2.2.2
)

github.com/urfave/cli/docs.go

package cli
import (
	"github.com/cpuguy83/go-md2man/v2/md2man"
	…
)

This problem has existed since version v1.22.1 . If you try to get these version, you will get an error: no package exists at "github.com/cpuguy83/go-md2man/v2/md2man"
Why?

These dependencies all added Go modules in the last version.

They all comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules. Such as: Repo github.com/my/module opted in to Modules on version v3.x.y. Then the import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg").

This "github.com/my/module/v3/mypkg" is not the physical path. So earlier versions of Go (including those that don't have minimal module awareness) plus all tooling(like dep, glide, govendor, etc) don't have minimal module awareness as of now and therefore don't handle import paths correctly See golang/dep#1962, golang/dep#2139.

Note: creating a new branch is not required. If instead you have been previously releasing on master and would prefer to tag v3.0.0 on master, that is a viable option. (However, be aware that introducing an incompatible API change in master can cause issues for non-modules users who issue a go get -u given the go tool is not aware of semver prior to Go 1.11 or when module mode is not enabled in Go 1.11+).
Pre-existing dependency management solutions such as dep currently can have problems consuming a v2+ module created in this way. See for example dep#1962.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Solution
1.Migrate to Go Modules.
Go Modules is the future, If you want a better upgrade package experience, you can opt into Go Modules.
2. Keep using the dependencies manage tool(like dep, glide, govendor, etc).
If you insist on using the dependencies manage tool(like dep, glide, govendor, etc), you would better see how github.com/moby/moby does it.
https://github.com/moby/moby/blob/master/VENDORING.md
https://github.com/moby/moby/blob/master/vendor.conf
In the vendor directory, github.com/moby/moby adds the /vN subdirectory in the corresponding dependencies.
This will help downstream module users make better use of your package, or they will be stuck in github.com/urfave/cli v1.22.4 .
Because the modular mechanism and the non-modular mechanism understand paths differently.

https://github.com/golang/go/wiki/Modules#semantic-import-versioning
https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
https://github.com/golang/dep/issues/1962
https://github.com/golang-migrate/migrate/issues/103

If this report helps you a little, please let me know

@ejholmes  @russellballestrini Could you help me review this issue? Thx :p


fixed my conflict and sychronising with main repo

it's nothing, please, help me merge sir

we go run the remaining parts, later in the month

we go run the remaining parts, later in the month

let me create issue for them now self

let me create issue for them now self


Cloud Deploy read error

I am attempting to use this for Google oAuth2. When I authorize, I get the following error:
Traceback (most recent call last):

  File "/home/adminuser/venv/lib/python3.9/site-packages/streamlit/web/server/component_request_handler.py", line 55, in get

    with open(abspath, "rb") as file:

IsADirectoryError: [Errno 21] Is a directory: '/home/adminuser/venv/lib/python3.9/site-packages/streamlit_oauth/frontend/dist'

My code structure is like:
your-repository/
├── .streamlit/
│   └── config.toml
├── your_app.py
└── requirements.txt

and in config.toml I have
[server]
enableCORS = false
enableXsrfProtection = false

Others seem to have fixed that problem but I'm not sure how specifically this accomplished this.

This worked perfectly. localhost still fails to reload but that's not a huge problem. Thank you so much for a great component


Qduino mini board manager

When preparing a sketch using the qduino mini i noticed the IDE does not have drivers for this board and found info online suggesting it can easily be bricked if using the wrong setup. i was able to find the board manager and set it up easily enough but a note reminding makers to be aware of this may be good.
i used the following site to get mine set as it has full directions.
https://www.hackster.io/team-qtechknow/qduino-mini-quickstart-guide-8b2d68

Thank you! I added the Qtechknow quickstart guide to the README.

Hi Andrew,
i was wondering if you had any issues getting the Qduino Mini to work with
the IDE. I've gone through the full setup to install the board manager and
drivers, everything is up to date. When i launch the IDE it shows Qduino
Mini on COM PORT2 in the bottom right of the application, and is also
selected as the board being used, the problem I'm having is that the Ports
menu is grayed out and inaccessible, and if i try to compile and upload
anything it says it cant reach the board.
there appears to be a hardware issue that says the device needs further
installation, but the drivers and files are all up to date.
So far I haven't been able to find anything useful in any of the forums
about this subject.
Thanks for any insight you may have,
Chris
On Tue, Apr 18, 2017 at 11:44 AM, Andrew Thaler<EMAIL_ADDRESS>wrote:

Closed #11 https://github.com/OceanographyforEveryone/OpenCTD/issues/11.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/OceanographyforEveryone/OpenCTD/issues/11#event-1046922306,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Aab5pS2OmMf_UB4v941IlkcYoLc-QmM4ks5rxNpAgaJpZM4M_4ik
.

Hi Chris,
If the comm ports don't show up, that generally means there's a driver issue. Have you tried installing all the default Arduino drivers, not just the Qduino specific ones?
If that doesn't work, try pinging https://twitter.com/Qtechknow, they are super helpful and responsive.


Improve the performance of curryN/curry

We can improve the performance of curryN/curry with _curry1. Let's look at the performance.
Before:

curry
Count
Hertz

_x4(100)
592421
9868550.23950353

mult4(100)
152955
2609371.9307046887

manual(100)
4406550
76401537.32172365

After:

curry
Count
Hertz

_x4(100)
628122
11911507.368938653

mult4(100)
226094
4277420.856223587

manual(100)
4400142
82213774.10192372

Also, I try to use _curry2 and _curry3 to improve the performance. But I found that we have to modify _curry2 and curry3 in order to pass test case, and those modifications will slow down _curry2 and _curry3 a lot.

I'd like to know a little more about the actual test cases, especially as the change is performance varies so widely between them.  Are these tests comparing only the calls to curry itself or the calls to the curried function?
I'm also curious about why you're going about this.  Do you think curry is a bottleneck in code that uses Ramda?  I certainly don't mind performance-focused PRs, but I always want to know why, and I always want to balance them against other  important factors in our system, such as API cleanliness and stability (no change here) and code simplicity (only a very minor issue with this PR.)  But first and foremost, what is driving this?

I just run npm run bench. Actually, I have not met performance problems in Ramda, but this idea pop up while reading the source code of Ramda. Sorry to trouble you :-)

I have thought of the exact same thing myself.
What changes did you have to make to _curry2 and _curry3 for it to work?

I just run npm run bench.

Oh, I simply didn't recognize our test case names!  :-)

Actually, I have not met performance problems in Ramda, but this idea pop up while reading the source code of Ramda.  Sorry to trouble you :-)

Not at all.  Not only is it no bother, it's absolutely worth considering.  I was wondering exactly this, whether it was the code that was troubling you or the actual performance.  It's clearly time that we take on curry and try to get it in as good a shape as we can.

@CrossEye all of you are so kind :-) Actually, I am considering to recommend FP to my teammate, and Ramda is a cool library to start from.So I am trying to make it clear.
@paldepind take _curry2 for an example. My solution will modify 4 lines of codes in order to forward extra arguments(To pass test case, 'forwards extra arguments'. See: path-to/ramda/test/curryN.js:68).
var _slice = Array.prototype.slice;
function _curry2(fn) {
  return function f2(a, b) {
    var n = arguments.length;
    if (n === 0) {
      return f2;
    } else if (n === 1 && a === __) {
      return f2;
    } else if (n === 1) {
      return _curry1(function(b) { return fn.apply(this, [a].concat(_slice.call(arguments))); });  // (1)
    } else if (n === 2 && a === __ && b === __) {
      return f2;
    } else if (n === 2 && a === __) {
      return _curry1(function(a) { return fn.apply(this, [a].concat(b).concat(_slice.call(arguments, 1))); });  // (2)
    } else if (n === 2 && b === __) {
      return _curry1(function(b) { return fn.apply(this, [a].concat(_slice.call(arguments))); });  // (3)
    } else {
      return fn.apply(this, arguments);  // (4)
    }
  };
};

I have not test the performance of this solution, but my instinct told me that it is dirty and slow XD. Maybe you have better solution.

What's the plan here?

I have no problem merging this.  It looks like a nice little optimization.  Are there reasons we should not do it?

I don't object. @benjycui, could you git rebase master?

Sorry for the delay, and it is OK now.


Put Docker Image Inside Build Folder

Keep the built docker image inside of a "build" folder (or some other folder). This way we're "hosting" docker images ourselves instead of relying on the docker hub.

Hey @namesty, thank you for implementing this.
After further consideration, I think the approach I've suggested of "putting the dockerfile inside the build folder" is naive and will lead to problems in the future. Here are some additional details:
Size of Docker Image:
Given a simple test polywrapper (test-cases/cases/apis/asyncify/), the docker image.tar file is ~450mb. If you pipe the image through gzip, it becomes ~150mb.
Diving deeper into what's causing the bloat inside the image.tar file, it's ~80% due to the base linux image that's added in the first couple of layers. If you open up the .tar image file, you can see this for yourself.
IPFS Storage Optimization:
In IPFS, folders & files are stored as DAGs, where each node in the DAG is a hash of a file/folder. This is to help optimize storage and reduce redundancy.
My fear is that, if we store the large image.tar as a single file, IPFS won't properly optimize its storge. Ideally IPFS would be able to store the individual layers, which would help reduce redundancy, because common layers (such as a base linux image) would be replicated and not duplicated. More research is needed to better understand IPFS's default functionality, and how well the image.tar file "plays nice" with this, or if it makes it harder for this de-duplication to occur.
Additional Research Needed:
We need to research the following two properties of IPFS:

Large File Storage - Does IPFS store large files as chunks? If so, does the image.tar make it harder for IPFS to store these things nicely? I suspect the answer is "no, it hurts IPFS's default storage optimization". This is because, even if there are common layers, they may exist in different "slices" of the image.tar file, meaning the DAG may look different from one image to another. This can be fixed if we store the image.tar as a decompressed directory of sub-folders containing only the image's tar file. This is what the image.tar has inside of it already, so no additional work is needed here. This way IPFS nodes can easily reference common layers more easily.
Folder Pinning - If a folder is pinned to an IPFS node, does that IPFS node then store all files within the folder? I think the answer is "yes". This would mean that to "pin" a polywrap package, it'd require the pinning node to also contain the image.tar, which is not ideal.

Ideal Future State:
IMO, in the future, the ideal state would be:

Store Polywrap "packages" as their own folder, minimizing the amount of space needed to keep them "online" within an archive node which pins polywrap packages for quick retrieval.
Store Polywrap "source images" as their own folders, and having a seperate set of archive nodes keep that information online. This data would only be needed for source-code-verification & auditing. Instead of just storing the image.tar file as a single file, we would instead extract the contents and store those in a folder. This will help IPFS optimize the storage of common docker image layers. Additionally in the future, this will help us flag a build image's layers as "audited" or "known good" to help speed up audits. For example, a "known good" layer has of 0x58... which represents a known good linux image would be marked green, and auditors could largely ignore it and move onto other "unknown" layers that are specific to the API at hand.

NOTE: The "package" would link to the "source image" within its web3api.build.yaml file.
Conclusion
All of this said, I think we should discuss what the ideal future state should be, and create an execution plan around that. That would probably lead to us closing this issue and opening up new ones.
Please let me know your thoughts.

Checkout: https://github.com/jvassev/image2ipfs/ It may help

I'll retake this

After a bit of research, I had an idea:

Standardize the Dockerfile layering
Build the image and instead of saving the whole .tar as we were doing or saving it as a whole image, we would
Deconstruct the image in layers with https://github.com/larsks/undocker/, which is very simple to use and output the layers to an "build-env image" folder, excluding the OS layer. (Doing this programatically is something I have to look into, as there seems to be no instant solution already created)
We could then pin this to IPFS, which is the actual essential data
And for auditing purposes in the future, we could (as an auditor) rebuild the image locally with the OS layer and all, and then compare that locally built image, with the layers retrieved from IPFS (using a tool like dive).

Does this make sense?

Yes that makes perfect sense, I came to the same conclusion after unzipping the docker .tar file and seeing they have all the layers right there!
We could have the OS layer still there, and ideally with IPFS hashing it would de-duplicate it. Would require more investigation to make sure this is the case.
I worry that if we don't have the OS layer, we would have a hard time reproducing the build again.

@namesty after speaking with a developer who's spent the past 3 years researching & building with IPFS & IPLD, he confirmed to me that "if multiple folders have the same files, IPFS will automatically deduplicate these files due to the preservation of the content hash in the IPLD database.


Latest changes from Jacob

@rfleschenberg please peer review, ie. test if you can run the demo shop in Python3

On Python 2, the demo seems to run fine. On Python 3, I am seeing the issue below.
(shoptest)rene@rex /tmp/django-shop/example (develop*) $ ./manage.py migrate
Operations to perform:
  Synchronize unmigrated apps: clipboard, haystack, sharable, cms_bootstrap3, treebeard, adminsortable2, segmentation, sekizai, django_select2, sass_processor, django_filters, shop_stripe, djng, parler, rest_framework, staticfiles, rest_auth, optimize, django_fsm, fsm_admin, extra_fields, sitemaps, polymorphic, compressor
  Apply all migrations: auth, shop, email_auth, sites, menus, contenttypes, myshop, djangocms_text_ckeditor, cmsplugin_cascade, cms, authtoken, sessions, filer, admin, easy_thumbnails, post_office
Synchronizing apps without migrations:
  Creating tables...
    Running deferred SQL...
  Installing custom SQL...
Running migrations:
  No migrations to apply.
  Your models have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.

(shoptest)rene@rex /tmp/django-shop/example (develop*) $ ./manage.py makemigrations --dry-run
Migrations for 'filer':
  0005_auto_20160407_2350.py:
    - Alter field subject_location on image
Migrations for 'post_office':
  0003_auto_20160407_2350.py:
    - Alter field language on emailtemplate
    - Alter field name on emailtemplate
Migrations for 'shop':
  0003_acceptconditionformpluginmodel_billingaddressformpluginmodel_breadcrumbpluginmodel_cataloglinkplugin.py:
    - Create proxy model AcceptConditionFormPluginModel
    - Create proxy model BillingAddressFormPluginModel
    - Create proxy model BreadcrumbPluginModel
    - Create proxy model CatalogLinkPluginBaseModel
    - Create proxy model CheckoutAddressPluginBaseModel
    - Create proxy model CustomerFormPluginBaseModel
    - Create proxy model CustomerFormPluginModel
    - Create proxy model DialogFormPluginBaseModel
    - Create proxy model ExtraAnnotationFormPluginModel
    - Create proxy model GuestFormPluginModel
    - Create proxy model PaymentMethodFormPluginModel
    - Create proxy model ProcessBarPluginModel
    - Create proxy model ProcessNextStepPluginModel
    - Create proxy model ProcessStepPluginModel
    - Create proxy model RequiredFormFieldsPluginModel
    - Create proxy model ShippingAddressFormPluginModel
    - Create proxy model ShippingMethodFormPluginModel
    - Create proxy model ShopAddToCartPluginModel
    - Create proxy model ShopAuthenticationPluginModel
    - Create proxy model ShopButtonPluginBaseModel
    - Create proxy model ShopCartPluginModel
    - Create proxy model ShopCatalogPluginModel
    - Create proxy model ShopLinkPluginBaseModel
    - Create proxy model ShopOrderViewsPluginModel
    - Create proxy model ShopPluginBaseModel
    - Create proxy model ShopProceedButtonModel
    - Create proxy model ShopSearchResultsPluginModel
(shoptest)rene@rex /tmp/django-shop/example (develop*) $

I encountered this myself. In django-filer a lot of stuff changed and apparently they forgot to add one migration. This can be ignored though.

Hmmm, ok, but what about the migration in django-shop? And in django-post-office?

Oh, I am actually seeing the same problem on Python 2. I guess this is just because the demo does not use a version of Cascade that has the latest hack to avoid migrations for proxy models. Alright. I think we can ignore this for the demo.
Otherwise, it seems to run fine so far. I did not test it very extensively. Anyway, I think it is ok to go with a "risky" release policy at the moment.
Should we maybe release a new version of djangocms-cascade first, and then require that version in the next release of django-shop? Anyway, I am fine with merging this PR.


Problems with fastai imports

Can you specify which fastai version is used.
I am having problems with several fastai imports like fastai.torch.core.children and fastai.callbacks.
PS. Looks like I found out already. Tried again with
conda install "fastai<2" -c fastai -c pytorch

and now the imports work.

Hi Hannu @htoyryla the version we used was:
fastai.__version__ = '1.0.53'
We are planning to upgrade to the latest version of fastai when we find some time, hopefully soon :)


Action sync does not respect pagesize

I'm using this config:
tables:
- source: table_name
  action: sync
  partition: hour
  pagesize: 50

However, I see this request being issued with a 10k limit:
20:09:43 WARN JsonRequest [main] table_name RESPONSE: GET https://<servicnow-url>/api/now/table/<table_name>?sysp
arm_limit=10000&sysparm_exclude_reference_link=true&sysparm_display_value=false&sysparm_fields=sys_id%2Csys_created_on%2Csys_updated
_on&sysparm_query=.....

I see in Synchronizer.java that this might be hardcoded and not respecting the pagesize option:
https://github.com/gflewis/sndml3/blob/8b38980d1fac5dcd0f8aef2a5d413f38c5092a38/src/main/java/sndml/datamart/Synchronizer.java#L98
I did not see this same issue when using since: last

This appears to be resolved with the following pull request https://github.com/gflewis/sndml3/pull/42


[subset] Make sure GDEF is processed before GSUB and GPOS

See https://github.com/fonttools/fonttools/pull/3114#pullrequestreview-1437266522

LGTM. Thanks.


Increase imports timeout

Looks like https://github.com/iterative/dvc/issues/4485 improved performance by >10  times. So, in recent master, it seems it finished in ~10m.
So, 10 * 10 * 60 = 6000.
I'll reduce it after checking the logs after this gets built.

@pared, I'm merging this. I'll check logs after the build finishes and will adjust to the sweet spot.


Prevent DiagnosticsStackTrace truncation

Fixes #52732
Background
Currently when an AssertionError is thrown, the stack trace gets truncated to the first 5 entries:
════════ Exception caught by widgets library ═══════════════════════════════════════════════════════
The following assertion was thrown while finalizing the widget tree:
setState() or markNeedsBuild() called when widget tree was locked.

This _ModalScope<dynamic> widget cannot be marked as needing to build because the framework is locked.
The widget on which setState() or markNeedsBuild() was called was: _ModalScope<dynamic>-[LabeledGlobalKey<_ModalScopeState<dynamic>>#6d889]
  state: _ModalScopeState<dynamic>#a176a
When the exception was thrown, this was the stack:
#0      Element.markNeedsBuild.<anonymous closure> (package:flutter/src/widgets/framework.dart:3901:9)
#1      Element.markNeedsBuild (package:flutter/src/widgets/framework.dart:3911:6)
#2      State.setState (package:flutter/src/widgets/framework.dart:1168:14)
#3      _ModalScopeState._routeSetState (package:flutter/src/widgets/routes.dart:664:5)
#4      ModalRoute.setState (package:flutter/src/widgets/routes.dart:784:30)
...

This only happens for errors that wrap their stack trace in a DiagnosticsStackTrace, which is later truncated by the TextTreeRenderer used in dumpErrorToConsole.
Solution
The simple fix is to override allowTruncate in DiagnosticsStackTrace.


TypeError: Invalid comparison between dtype=datetime64[ns, America/New_York] and datetime

This is my code:
import quantstats as qs

qs.extend_pandas()

stock = qs.utils.download_returns('GLD', period="10y")

qs.reports.html(stock, title='PTL Investments', output='output/gld.html')

qs.reports.html(stock, "SPY", title="GLD vs. SPY", output='output/gld_vs_spy.html')

stock = qs.utils.download_returns('QQQ', period="10y")

qs.reports.html(stock, "SPY", title="QQQ vs. SPY", output='output/qqq_ovs_spy.html')

stock = qs.utils.download_returns('TQQQ', period="10y")

qs.reports.html(stock, "QQQ", title="TQQQ vs. QQQ", output='output/tqqq_vs_qqq.html')

tickers = {
    'FB': 0.2,
    'AAPL': 0.2,
    'AMZN': 0.2,
    'MSFT': 0.2,
    'GOOG': 0.2
}

fmaga = portfolio = qs.utils.make_index(tickers)

qs.reports.html(fmaga, "qqq", output="output/fmaga_vs_qqq.html")`

and this is my output:
TypeError: Cannot compare tz-naive and tz-aware datetime-like objects

The above exception was the direct cause of the following exception:

InvalidComparison                         Traceback (most recent call last)
...
     33     typ = type(right).__name__
---> 34     raise TypeError(f"Invalid comparison between dtype={left.dtype} and {typ}")
     35 return res_values

TypeError: Invalid comparison between dtype=datetime64[ns, America/New_York] and datetime

I have the same issue:
InvalidComparison: 2022-11-01 00:00:00
During handling of the above exception, another exception occurred:
---> 34         raise TypeError(f"Invalid comparison between dtype={left.dtype} and {typ}")
35     return res_values
36
TypeError: Invalid comparison between dtype=datetime64[ns, America/New_York] and datetime

+1

+1

+1

+1

+1

Any solution available for this yet, still facing the issue on this...

There is a work around:
SPY_qs = qs.utils.download_returns('SPY', period="6Y")
qs.reports.plots(SPY_qs, mode='full')

@yenla9 Thanks, I see benchmark comparison also works with individual plot reports... But is there a solution available with HTML tearsheet with benchmark comparison? Issue is coming when we have benchmark comparison with html report

Not sure if this is what you're after, but I download benchmark first, convert, and then add DataFrame to report
adding benchmark
benchmark_SPY = pd.DataFrame(qs.utils.download_returns('SPY'))
benchmark_SPY.index = benchmark_SPY.index.tz_convert(None)
qs.reports.html(df, benchmark_SPY)

yes, stock.index = stock.index.tz_convert(None) solved my problem, Thank you guys :)

SPY_qs = qs.utils.download_returns('SPY', period="6Y")
qs.reports.plots(SPY_qs, mode='full')

This worked Thanks alot, not sure why tz ocnversion is not built within...

@MidjoV, Thanks a lot your suggestion worked... not sure why tz conversion is not built within quantstats module...

I did the above but I am now experiencing an issue with the tearsheets:

stock = qs.utils.download_returns("SPY")
bench = qs.utils.download_returns("SPY")
stock.index = stock.index.tz_convert(None)
bench.index = bench.index.tz_convert(None)
qs.reports.html(stock, bench)

when i run the above for the SAME underlying security(in this case the strategy and bench are both SPY) I do get a working plot but I do not get identical plots or identical output data...is anyone else experiencing this? They should be the same?

I have come across the same issue recently and it took me some time to dig into it. Here are my findings. quantstats version 0.0.55
the problem in my view arises from the fact that yfinance always returns non-naive with-timestamp data (in my case BTC-USD, tzinfo=UTC), this data is aligned with your returns and then, subsequently passed to reports.py, metrics() function, which computes different metrics, including monthly returns and so on, but then it creates naive datetime, which fail to compare with returns/benchmark df, see https://github.com/ranaroussi/quantstats/blob/main/quantstats/reports.py#L518
@wazimar fix, in https://github.com/ranaroussi/quantstats/pull/221 will probably fix it, but I believe it may require some edge case reviewing and treatment
I have solved it by manually downloading prices for the period of interest (I am passing actual portfolio values, quantstats seems to translate them nicely to returns by itself
def download_benchmark(self, benchmark: str, ind) -> pd.Series:
        """download benchmark data, for the (daily) indices given in 'ind'
        """
        # for last timestamp, require one day more, b/c otherwise since the timestamp is at 00:00
        # yfinance seems to actually filter last day
        first_ts = ind[0]
        last_ts = ind[-1] + dt.timedelta(days=1)
        benchmark_df = yfinance.Ticker(benchmark).history(interval='1d', start=first_ts, end=last_ts)

        # drop tz info, we assume it is UTC, we sanity check first index
        benchmark_df.index = pd.DatetimeIndex([d.replace(tzinfo=None) for d in benchmark_df.index])
        benchmark_pv = benchmark_df["Close"]

        # set correct benchmark name (instead of 'CLOSE')
        benchmark_pv.name = benchmark

        return benchmark_pv

subsequently it is passed to quantstats.reports.html(returns=pv, benchmark=benchmark_pv)
note that I am passing here actual portfolio values.
Passing returns also possible, but then previous day should also be pulled from yahoo, and also initial 0 returns added the day before, so that plots start at 0..

I have the same problem if my portfolio has a timezone-aware index, I can't get it to work even without using a benchmark.

I have the same problem if my portfolio has a timezone-aware index, I can't get it to work even without using a benchmark.

yes, this is because internally metrics() function is always creating default naive (no tz) dates, see my analysis above

Finally got it to work with:
import quantstats as qs
import pandas as pd
stock = pd.DataFrame(qs.utils.download_returns('AAPL'))
stock.index = stock.index.tz_convert(None) # make timezone agnostic.
stock = stock.squeeze() # back to a series
benchmark = pd.DataFrame(qs.utils.download_returns('MSFT'))
benchmark.index = benchmark.index.tz_convert(None) # make timezone agnostic.
qs.reports.html(stock, benchmark)

I did this and got it to work:
stock.index = pd.to_datetime(stock.index.strftime('%Y-%m-%d'))


Error occurred while detecting SCA version

Current Behavior
Using SAST chart 23.2.0 with controller and sensor 23.2 (or any more recent version, as well) I receive this error when the worker/sensor tries to start:
launcher.log will be stored in "/fortify/.fortify/scancentral-23.2.0/log" directory. Checking for updates... No update available or auto update is disabled on the controller. scancentral.log will be stored in "/fortify/.fortify/scancentral-23.2.0/log" directory. Setting up SCA version... Retrieving SCA version... Error occurred while detecting SCA version Shutting down with errors. Please see log for details.
This environment variable is present:
COM_FORTIFY_VERSION_SCA=23.2.0
The controller is up and running, and accessible to the worker.  It is also connected to SSC.
Expected Behavior
Sensor to start up without error
Steps To Reproduce
In a kubernetes environment, deploy scancentral-sast 23.2.0 chart with fortifydocker/scancentral-sast-controller:23.2 and fortifydocker/scancentral-sast-sensor:23.2
Environment
No response
Anything else?
No response

Hi, thanks for raising this issue, and sorry for the delay in getting back to you. We’ve been transitioning the Fortify Helm charts to Docker Hub, and the older Helm charts that used to be hosted in this repository have now been deprecated. If you think this issue is still relevant for the new Helm charts hosted on Docker Hub, please raise a support ticket through the regular OpenText support channels. We will no longer be monitoring issues raised on this repository. For more information on this change, please see the repository README file.


add missing endpoint

This was breaking FF imports on dev. Shouldn't these always be added to all environments?

i think i know what happened with these actually.... these two environment files (beanstalk and qa) did not used to exist, so maybe they were in PR status when those environment files were introduced and we didn't spot it in review.
beanstalk.prod and qa were added recently while implementing ECS / Jenkins job changes because we are temporarily deploying via 2 different pipelines. The "old" way was to actually always deploy the environment.prod config regardless of environment, which is still the case, but it was renamed beanstalk.prod to separate it from the "new" build configs. Those configs really are based on each environment. A staging one existed already even though it wasn't used, so a qa one needed to be added as well. These configs will map to the new domain envs.


Fix missing type annotations in documentation

mkdocstrings does not seem to support PEP 484 type comments

Hi! We definitely support type hints :) don't hesitate to open issues with minimal reproducible examples in our bug tracker ^^

Ah, sorry, I read type hints instead of type comments. We don't support comments indeed.

What I like about PEP 484 type comments for function annotations is that they can make many function signatures much more readable. For example:
def process_data(raw_data: List[Dict[str, str]], config: Optional[Dict[str, str]] = None) -> List[int]:
    """Process raw data according to config."""
    pass

becomes:
def process_data(raw_data, config=None):
    # type: (List[Dict[str, str]], Optional[Dict[str, str]]) -> List[int]
    """Process raw data according to config."""
    pass

And type comment based function annotations are well supported by mypy and IDEs like PyCharm.
@pawamoy Do you think that would be something to consider to support with griffe?

Fortunately, ast can parse type comments, so we can consider supporting them. Not a priority though since we have type annotations. Could be an Insiders feature :)


how to use webUI ( downloaded) correctly?

Self Checks

[X] I have searched for existing issues search for existing issues, including closed ones.
[X] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
[X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
[X] Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.
I tried to use it on the website ,and downloaded the model ,trained and i received a bad model ,worse than that i generated on the website , so i think there may be something wrong with my work ,and i don't know where the problem is . I ran the install_env.bat , downloaded something ,and started the webUI ,selected the audio path ,clicked on "start training" button , then started the inference server , audio generated sound like it didn't be trained at all.... something i did wrong ? Please forgive my poor english and poor technical skills .
2. Additional context or comments
No response
3. Can you help us with this feature?

[ ] I am interested in contributing to this feature.

Did you do lora training?

你参加过 lora 培训吗？
有相关的培训链接吗？

https://tts.byylook.com/ai/text-to-speech


Return Behavior

Some methods in rocketpyAlpha return None, while others return self. This behavior should be consistent so that its predictable.
I see no problems in all methods which edit an object either returning the object itself or valuable information relating to the edit.

This issue is being addressed with issue #6.


feat: txpool persistence

This PR adds a new implementation of a TxPool based on the kv-store introduced in #3628. It also amends the p2p-client's bootstrap flow.
The p2p-client saves the block number its on to the database and restores it the next time it is started. The initial sync happens as before (it syncs to the the tip of the chain, but instead of syncing from 0, it syncs from the last known block number) and after that, it re-publishes any transactions in its TxPool that haven't been processed already.
Fix #3365

Benchmark results
Metrics with a significant change:

node_history_sync_time_in_ms (5): 37,441 (+141%)
node_history_sync_time_in_ms (10): 77,127 (+160%)
node_database_size_in_bytes (10): 6,038,968 (+42%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 43aa603f and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,444
179,588
716,132

l1_rollup_calldata_gas
222,984
868,268
3,449,672

l1_rollup_execution_gas
842,071
3,595,376
22,205,334

l2_block_processing_time_in_ms
1,367 (+2%)
5,144
21,207 (+1%)

note_successful_decrypting_time_in_ms
339 (-1%)
1,057 (+1%)
3,873 (-1%)

note_trial_decrypting_time_in_ms
49.8 (-4%)
39.3 (+13%)
133 (-2%)

l2_block_building_time_in_ms
13,530
53,685
217,282

l2_block_rollup_simulation_time_in_ms
9,998
39,748
161,133

l2_block_public_tx_process_time_in_ms
3,502
13,885
55,938

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
:warning: 37,441 (+141%)
:warning: 77,127 (+160%)

note_history_successful_decrypting_time_in_ms
2,490
4,885 (-9%)

note_history_trial_decrypting_time_in_ms
83.4 (+10%)
207 (+48%)

node_database_size_in_bytes
3,768,229 (-4%)
:warning: 6,038,968 (+42%)

pxe_database_size_in_bytes
29,940
59,499

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
200
43,109
20,441

private-kernel-ordering
114
25,833
9,689

base-rollup
2,056
244,144
881

root-rollup
85.0
4,088
889

private-kernel-inner
260
64,516
20,441

public-kernel-private-input
171
25,203
20,441

public-kernel-non-first-iteration
170
25,245
20,441

merge-rollup
11.2 (+1%)
2,608
881

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
10,331
26,367


fix(package.json): make package.json version match npm

During the most recent lerna publish, I selected patch version bump for @most/prelude and minor version bump for all others.  However, lerna still bumped the minor version when publishing @most/prelude.
This seems like a lerna bug, and I'll work on reporting it.  In the meantime, this PR updates @most/prelude's package.json version to match what is actually published in npm, 1.6.0.

🐑 🇮🇹


HTTPS Proxy broken in current master/git version

HTTPS Proxy is not working in current master, pictures are not displayed.
Apache error log: "malformed header from script. Bad header=200: php-fcgi-starter"
Stable version 1.1.8 works without problems.

Bug is now in stable version 1.1.9, too.
Steps to reproduce:

Activate "Enable image proxy" in Preferences.
Add feed "cad-comic.com" and activate "Download full content".
Open latest feed item. No picture.
Deactivate "Enable image proxy" in Preferences.
Open latest feed item. Picture is there.

I just tried with my own of instance of Miniflux which is running with HTTPS/image proxy enabled and it's working fine for me (with your feed).
Can you provide any logs?

Strange. Just tried it again and 1.1.8 is working, 1.1.9 is not. On the same server.
Proxy URL is exactly the same.
Apache just says: "Internal Server Error. malformed header from script. Bad header=200: php-fcgi-starter"
Steps for debug log: Flush messages, click feed item, click download content, copy log.
I see nothing strange in both logs...
If you know some other info I can provide, please tell.
 Adding cad-comic.com feed and opening the first feed item. Image not showing.
miniflux-debug-118-1.txt: Same, but version 1.1.8. Image okay.
miniflux-debug-118-2.txt: Only opening feed item. Image okay. With 1.1.9 log is empty.

And some more information.
So this commit broke the https image proxy for me: https://github.com/miniflux/miniflux/commit/079545daed91f44807377d8f018c694cfe1dcb92
And to be more precice this one: https://github.com/fguillot/picoFeed/commit/456b13bbfb81f9d39f0b74b624b68ad02478b20a
I don't know php, so sadly I can't isolate it anymore.

@fguillot Same here (on miniflux master) – it looks like the passthrough handling broke with 456b13bb:
I dug down a bit and if it looks like the HttpHeaders::parse will parse
list($status, $headers) = HttpHeaders::parse(explode("\n", $this->response_headers[$this->response_headers_count - 1]));

into
# $headers
Array
(
    [0] => HTTP/1.1 200 OK
Server: nginx/1.9.4
Date: Mon, 14 Mar 2016 12:49:17 GMT
Content-Type: image/png
Content-Length: 473831
Connection: close
X-Object-Meta-Sha1base36: 7ceymti31x4aj1z8gafb00gzips9qit
Last-Modified: Tue, 07 Oct 2014 10:32:19 GMT
Etag: 814a0034f5549e957ee61360d87457e5
X-Timestamp:<PHONE_NUMBER>.82587
X-Trans-Id: tx938ef20d7a88468eb087d-0056e3df85
X-Varnish: 114042779 64113606, 537945258 312565030,<PHONE_NUMBER><PHONE_NUMBER>, 266691787 262578307
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 185288
X-Cache: cp2026 hit(4), cp1063 hit(76), cp3044 hit(145), cp3035 frontend hit(18)
Strict-Transport-Security: max-age=31536000
Set-Cookie: WMF-Last-Access=14-Mar-2016;Path=/;HttpOnly;Expires=Fri, 15 Apr 2016 12:00:00 GMT
X-Analytics: https=1;nocookies=1
X-Client-IP: 2a00:d0c0:200:0:b9:1a:9c0c:300
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Age, Date, Content-Length, Content-Range, X-Content-Duration, X-Cache, X-Varnish
Timing-Allow-Origin: *

)

# $status
200

which is why we're seeing the malformed header from script. Bad header=200: php-fcgi-starter.
Let me know if I can supply more information! :)

Probably a small typo, but after reading it for the second time it is more obvious. The header() function should probably receive headers instead of the http status. Patching it fixes the proxy for me.
I've opened a small PR: https://github.com/fguillot/picoFeed/pull/252

I merged your PR, thanks.
I will update master when the PR in progress will be merged in PicoFeed.

@fguillot Thanks! :+1:

You can test the current Miniflux master and check if that fix your issue. If yes, close this ticket.
Thanks.

It works! Thanks!
@peter2517 close?

Sorry for the late reply.
Yes, it's fixed now. Thank you both.


"pyenv shell --help" is broken on fish

Command "pyenv shell --help" is broken on fish, rather than print out the help, I got this:
> pyenv shell --help
Expected a string, but instead found end of the statement
/var/folders/h1/q7bx8x6n4czgns3fkj_g_1bc0000gn/T//.psub.ZdeiJbNt0M (line 1): Usage: pyenv shell <version>
       pyenv shell --unset
                                                                                ^
from sourcing file /var/folders/h1/q7bx8x6n4czgns3fkj_g_1bc0000gn/T//.psub.ZdeiJbNt0M
        called on line 175 of file /usr/local/Cellar/fish/2.3.0/share/fish/config.fish

in function '.'
        called on line 7 of file ~/.config/fish/functions/pyenv.fish

in function 'pyenv'
        called on standard input
        with parameter list 'shell --help'

source: Error while reading file '/var/folders/h1/q7bx8x6n4czgns3fkj_g_1bc0000gn/T//.psub.ZdeiJbNt0M'

I think it was caused by pyenv:123, because of '--help', the command was intercepted by pyenv-help, rather than sh-shell, fish tried to interpret the output of pyenv-help and failed.
  shift 1
  if [ "$1" = --help ]; then
    exec pyenv-help "$command"
  else
    exec "$command_path" "$@"
  fi

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/35627328-pyenv-shell-help-is-broken-on-fish?utm_campaign=plugin&utm_content=tracker%2F282009&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F282009&utm_medium=issues&utm_source=github).

Good catch. I confirmed it is also broken with zsh. The help messages should be written to 2.
% pyenv shell --help
(eval):2: parse error near `\n'

What a good idea~! While I was thinking about passing an extra parameter to pyenv-help and output a bunch of echo commands~...

Prepared #651 as the workaround. It'd be better to send same PR to https://github.com/rbenv/rbenv as well.

I've pushed e93ae00ca1420de631055bd5b7b05565fb95b6db. Now we can expect all help messages will be written to stdout.


dependencies(RR): update RR

Reason for This PR

update RR-plugins to v2.6.1

License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the MIT license.
PR Checklist
[Author TODO: Meet these criteria.]
[Reviewer TODO: Verify that these criteria are met. Request changes if not]

[x] All commits in this PR are signed (git commit -s).
[x] The reason for this PR is clearly provided (issue no. or explanation).
[x] The description of changes is clear and encompassing.
[x] Any required documentation changes (code and docs) are included in this PR.
[x] Any user-facing changes are mentioned in CHANGELOG.md.
[x] All added/changed functionality is tested.

Codecov Report

Merging #123 (6e1c877) into master (d269941) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #123   +/-   ##
=======================================
  Coverage   65.38%   65.38%
=======================================
  Files          18       18
  Lines        1043     1043
=======================================
  Hits          682      682
  Misses        268      268
  Partials       93       93

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 d269941...6e1c877. Read the comment docs.


Daily Restart

Hey there!
I have created some crontabs to update my server. Now i have the question is it possible to do an restart every 24h if there is no update availible?
Dont want to do a simple "arkmanager restart" ever 24h, maybe there was an update 15min ago.
Thanks, talpidae

0 3 * * * [ -z "$(find ~/ARK/steamapps/appmanifest_376030.acf -mtime -1)" ] && arkmanager restart --warn

Very nice! Thank you <3 :D


Debugging, chapter 1, Sunday Roll Call

Leave a comment with these two things:

A summary of your last chapter using only emojis
Something you'd like to share, anything goes! (within respect)

emoji cheat sheet

😁👍

😞😵💫😤😭🥲☺

😄

:thinking:  :face_in_clouds:

👍

💻💭😱❌🧐🗯😅

💻❌🧐🤨

👍

👍 ☺

🧐🗯😅💻


Sandbox numba

Could be possible to sandbox a python code with numba and restrict functions objects and variable it could access?

@rspadim thank you for asking about this. Please supply more information about the use-case and what exactly you expect to happen, thank you.

In general this is going to be extremely difficult / impossible to do and get correct, see e.g. https://stackoverflow.com/questions/3068139/how-can-i-sandbox-python-in-pure-python
I think the answer to this is that it's not possible to do, and isn't an intended use case of Numba.


Fix errbit notification

This fixes two problems:

Airbrake notifications not working on newer Errbit instances (I used #4 as the reference for this but implemented and tested the suggestion from @fazibear)
Fixed up the test in test/airbrakex/exception_parser_test.exs to not fail on different versions of Elixir. I am instead asserting that the backtrace is not empty, and that the message and type match.

Any idea when this fix might get merged?  :)

@veverkap Sorry about delays, now its fixed, and released

THANKS!!!!!
I hope I wasn't too pushy :)


Fix docs.rs windows build

We can just not build SPIRV-Cross when building documentation on docs.rs.
Fixes #148
Also added all features for docs.rs so they show up on the page.

Don't know how the commit messages got messed up but fixed now.


Sensors of cpu and memory

Hi!
Thanks for a integration, it's a long awaited and cool! :)
One question 'bout cpu and memory sensors, I just added the integration, and seems my cpu and memory sensors is still at zero point - it's normal or what the period for update they?

This screenshot for 15 minutes after integration is done.
Thanks.

Oh sorry. As I understood it's only for OpenMediaVault 5? 'coz I'm using 4.1.35-1 now.

ah yes, OMV4 will be EOL at the end of next month, so adding support for it would not make sense.
I recommend upgrading, its really simple :)

Sure I thinking 'bout upgrade. Okay buddy, thanks I think I will be upgrade soon.

I used these steps and it was smooth transition. Even all settings stayed the same.
Of course, I set up DNS properly, not like that guide.

okey, good luck :)


Unable to make overleaf-registration  work

Hello,
First off, thank you for the work you have done.
I'm trying to set this up but nothing seems to be working.
docker-compose.yml:
version: '3'

networks:
  traefik_net:
    external: true

services:
  overleaf-registration:
    image: ghcr.io/studentiunimi/overleaf-registration
    container_name: overleaf-registration
    environment:
      CAPTCHA_SERVER_KEY: 6LdUWT4qAAAAAM8Zr5l-Ak1KizgXhgoXlMiWBAom
      CAPTCHA_CLIENT_KEY: 6LdUWT4qAAAAAPVISfT18MbRuOHVY8-ewyDuXiM-
      OF_INSTANCE: ''
      OF_ADMIN_EMAIL: '*******'
      OF_ADMIN_PASSWORD: '*******!'
    networks:
      - traefik_net
    deploy:
      labels:
        - "traefik.enable=true"
        - "traefik.http.services.overleaf-registration.loadbalancer.server.port=8000"

For the variable OF_INSTANCE I tried to set the ID of the docker container sharelatex and the url of the overleaf frontend, but neither worked.
docker ps:
CONTAINER ID   IMAGE                         COMMAND                  CREATED       STATUS                 PORTS                     NAMES
**ea7957873908**   sharelatex/sharelatex:5.1.1   "/sbin/my_init"          13 days ago   Up 10 days             <IP_ADDRESS>:80->80/tcp   sharelatex
31bf7c16d8c6   redis:6.2                     "docker-entrypoint.s…"   13 days ago   Up 10 days             6379/tcp                  redis
9996ac77e21b   mongo:6.0                     "docker-entrypoint.s…"   13 days ago   Up 10 days (healthy)   27017/tcp                 mongo

Please help me to see clearer.

I've created an api client and server key with V2 reCapcha at google website and worked, that type of recapcha implementation is of V2

Thank you @cosmicbeams @evilhalba, I've fixed the README with the correct CAPTCHA version. Have a good day! :)


addChannelAcquisitionContextInCosmosDiagnosticsBasedOnLatency

Changes:
populating ChannelAcquisitionTimeline in CosmosDiagnostics based on the duration spent in channelAcquisitionStarted timeline stage.
By default if the channelAcquisitionStarted took more than 1s, then extra details will be populated in  CosmosDiagnostics  in section transportRequestChannelAcquisitionContext
Examples:

API change check
API changes are not detected in this pull request.

/azp run java - cosmos - tests


Remove "m" library dependency on Windows.

On Windows, the "m" library is not required, and in fact does not exist.

Thanks


Business day calculation wrong for weekends

I am currently working in Ruby 2.4.4 and Rails 5.1.6
I am calculating Business days from specific dates and I am currently facing following problem

When I calculate 1 business day from Sunday, the next business day is Tuesday, but when I calculate 1 business day from Today which is Wednesday, it gives me Thursday as next busiess day. It is adding one extra day for Sunday.

This is not a bug, it is operating as designed.  This has caused confusion before though; let me explain the logic.
The business day clock only ticks on business days.  Sunday is not a business day.  When you ask for the next business day, it rolls forward to Monday, adds one business day, and reports Tuesday.
The original use-case for this library was calculating deadlines.  If you got a task on Sunday and it was due  in "one business day", that would not be Monday, that would be Tuesday.
One way or the other, people are going to have an issue with this... it is a business requireent to interpret it this way, not a technical problem.


[question] Is PPO2 with multiple workers the same as DPPO?

Hi! I believe that Distributed PPO uses multiple workers for data collection and gradient calculation (the gradients are then averaged to update the policy). Is using PPO2 with multi-processing equivalent to DPPO?

Hello,
Looking at the paper, there are some similarities and some differences.
I wouldn't call it DPPO, more "multiprocessed" PPO with a single process for doing the gradient update.
First, it uses several workers to gather data. However compared to DPPO, PPO2 does not average gradients from the workers, it samples from the all the experience gathered by the workers (see here).
Then, PPO2 uses the "clip" variant of PPO (instead of the kl penalty) and does not have (for now) any check on the estimated kl divergence (see https://github.com/hill-a/stable-baselines/issues/213), which is a feature that would nice to have.
Finally (and there are maybe more differences but I did not read the paper thoroughly yet), the OpenAI PPO version (PPO2) also clips the value function (but since #343 you can deactivate that or tune it) and normalizes the advantage. Note that those changes were not documented by OpenAI.

Then, PPO2 uses the "clip" variant of PPO (instead of the kl penalty) and does not have (for now) any check on the estimated kl divergence (see #213), which is a feature that would nice to have.

What feature would you suggest exactly? (Maybe early stopping?) I am not sure that would make much sense since this requires clever hyperparameterizing, and having few hyperparameters is originally one strength of PPO-clip, unless I am missing something?
(First time here, I may start contributing to this nice repo)

What feature would you suggest exactly? (Maybe early stopping?)

yes, it is the feature describe in #213, because the clipping strategy is not an hard constrain, it may be violated (see here).

I am not sure that would make much sense since this requires clever hyperparameterizing, and having few hyperparameters is originally one strength of PPO-clip, unless I am missing something?

The idea would be at least to allow the user to set it up (so deactivating this feature by default, in the same vein of what was done with clipping the value function in #343 ) or having a very high value by default.

(First time here, I may start contributing to this nice repo)

Contributions are welcomed =) (please don't forget to read the contribution guide first)


build(project): adds footnotes linkTitle to strapi and Post component

closes #840

this branch is goofed


checkout page completed

Related Issue
[Cite any related issue(s) this pull request addresses. If none, simply state "None”]
#982
Description
[Please include a brief description of the changes or features added]
i added checkout page on checkout button click then show checkout page
Type of PR

[x] Bug fix
[x] Feature enhancement
[ ] Documentation update
[ ] Other (specify): _______________

Screenshots / videos (if applicable)
[Attach any relevant screenshots or videos demonstrating the changes]

Checklist:

[x] I have performed a self-review of my code
[x] I have read and followed the Contribution Guidelines.
[x] I have tested the changes thoroughly before submitting this pull request.
[x] I have provided relevant issue numbers, screenshots, and videos after making the changes.
[x] I have commented my code, particularly in hard-to-understand areas.

Additional context:
[Include any additional information or context that might be helpful for reviewers.]

@Suchitra-Sahoo ,review it

@Varsani2520 it is the frontend of checkout page so try to show the items which are added in cart and total amount shown in cart to reflect on payment page. And remove that paragraph below summary. Link the make payment option and submit option to direct back to the cart as right now there is no backend.

Ok

@Suchitra-Sahoo ,can you please 1 chance
because my laptop is in fault so i dont have laptop few day ,now i have so please assign i completed within a day

@Varsani2520 I have just closed the PR you can raise another PR


What does BFH refer to?

@myrmoteras in your hackathon topic 8 you refer to "BFH", what is this?

Bfh = Berner Fachhochschule. Homeinstitution of Beat Estermann. Partner in our Swissfunded eBioDiv project
Cheers
Donat Agosti
Get Outlook for Androidhttps://aka.ms/AAb9ysg

From: Quentin Groom @.>
Sent: Saturday, August 14, 2021 12:05:16 PM
To: pensoft/BiCIKL @.>
Cc: Donat Agosti @.>; Mention @.>
Subject: [pensoft/BiCIKL] What does BFH refer to? (#7)
EXTERNAL SENDER
@myrmoterashttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmyrmoteras&data=04|01||e4cc1a17d31d4cb3f19c08d95f0b0404|be0003e8c6b9496883aeb34586974b76|0|0|637645323202662954|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=j6BAByPo51Ycg5agSJmJxqDIz8z7OWHjgfKD8ht%2FbDo%3D&reserved=0 in your hackathon topic 8 you refer to "BFH", what is this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpensoft%2FBiCIKL%2Fissues%2F7&data=04|01||e4cc1a17d31d4cb3f19c08d95f0b0404|be0003e8c6b9496883aeb34586974b76|0|0|637645323202672910|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=TWA%2FUOJcUI1xs8LczFBYgcL1pmXpNGYtzScdDCz9tu8%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABDFPJC42BUJ3D46K4JWDFDT4Y5VZANCNFSM5CE6D65A&data=04|01||e4cc1a17d31d4cb3f19c08d95f0b0404|be0003e8c6b9496883aeb34586974b76|0|0|637645323202672910|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=aXrVa9kr%2BQnECqinerV40W6zT%2FTP9t0lCtsU0dn91F0%3D&reserved=0.

Thanks!


get doc site running under node-swig

I made a node-swig.github.io repo (see here: http://node-swig.github.io/), we definitely have gh pages working.  I think we just need to push to the gh-pages branch for this to work.
I tried running the make gh-pages target on my box and it errored out with
module.js:338
    throw err;
          ^
Error: Cannot find module 'swig'
    at Function.Module._resolveFilename (module.js:336:15)
    at Function.Module._load (module.js:278:25)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.exports.swig (/Users/lochlan/Documents/dev/swig/node_modules/still/node_modules/consolidate/lib/consolidate.js:123:50)
    at /Users/lochlan/Documents/dev/swig/node_modules/still/lib/build.js:42:24
    at /Users/lochlan/Documents/dev/swig/node_modules/still/lib/data.js:50:9
    at /Users/lochlan/Documents/dev/swig/node_modules/still/lib/data.js:29:5
    at fs.js:334:14
    at FSReqWrap.oncomplete (fs.js:95:15)

The offending line in the gh-pages target recipe is
node_modules/.bin/still docs -o tmp -i "layout" -i "json" -i "less" -v

I'm pretty sure we could just edit a file on the gh-pages branch, or something like that, although we should figure out why make gh-pages isn't working.
As an aside, I'm not that into the way the gh-pages branch works here, I don't like the heavy build process.

So I was hacking around in the makefile and I managed to get the docs site up, which worked as soon as I pushed to the gh-pages branch: http://node-swig.github.io/swig/
I have not yet gotten node_modules/.bin/still docs -o 'tmp' -i "layout" -i "json" -i "less" -v working.  If I install this still project globally I am able to run still docs -o 'tmp' -i "layout" -i "json" -i "less" -v successfully.  I will dive a little deeper and see if I can't figure out why this consolidate call is failing

This is some kind of circular dependency issue.  I'm not necessarily a super node expert and I'm unfamiliar with this class of problem in node, but the issue seems to be that node_modules/still/node_modules/swig does not exist.  If I rectify that issue then the makefile recipes seem to work.
I'm not sure what the actual fix is here—@cdaringe or @paulcpederson do either of you know?

@Lochlan global install of still will work, but I don't think that's the answer as that would force all contributors to install it globally. Could have problems with different versions, etc.
Since npm 2.0.0 you can just specify Local Paths for modules. I just tried this locally and it worked great. Basically in devDependencies  you just add:
"devDependencies": {
  "swig": "./"
}

That way still will find a module called swig that is just whatever is in the folder.

i think as @paulcpederson suggests is fine for now.  looks like still uses consolidate, which eventually tries to require in the specified engine.  perhaps we can also add a postpublish hook to auto-build those docs everytime we bump version.

@cdaringe I think we could set it up so that successfull travis builds on master build the docs using a travis script provider.

Guys, consider this as workaround until you make the documentation available from node-swig.
I have made changes manually in all index files to make the documentation come online here https://prakaashkpk.github.io/swig-docs/
I have been trying to compile the entire project myself and not yet succeeded.
Thanks for taking initiative to make this project come alive again. Will be happy to contribute to this project in my spare time.

Where is this project at right now? I've just invested the past 3 month's building a swig based project with an indefinite life expectancy so I'm more than happy to contribute where I can. That said I'm running it on gulp-swig so it would be good to see that project updated to use swig-templates if this is indeed the most likely predecessor to the original project.
One way or another this engine needs to be preserved because nothing else I've tried to date comes close to what's on offer here.

All targetted and issue associated PRs welcome!  No one is full time on this lib, but there are people watching it and caring about its critical parts.  Even if maintenance is sparse, swig-templates is very stable.

@nedkelly it looks like https://github.com/colynb/gulp-swig is pretty stale itself.  I would suggest opening a PR on that project to point to our package, and if it doesn't land I would suggest forking gulp-swig.

I have the doc site running locally, but am unable to commit because npm ls is exiting with an error :/
It's actually pretty interesting how it works currently, essentially it's set up to use the jsdoc command to output to stdin and redirecting that into a json file. That JSON file is what still uses to generate the site.
If we moved to another static site generator we could basically just point it at the same json file and keep the existing doc template and indiana jones it.
I'll try a bit more, but we may need to generate the docs with something else.

Your conclusion mirrors mine but I was thinking that the lift to get to a
new site generator might be too heavy for the short term goal of getting
docs working.  If you see a good (read: easy) path forward, though, I say
go for it.  Always down to hack on this after work, too, if you want to
stop by or meet up somewhere downtown.
On Monday, August 29, 2016, Paul Pederson<EMAIL_ADDRESS>wrote:

I have the doc site running locally, but am unable to commit because npm
ls is exiting with an error :/
It's actually pretty interesting how it works currently, essentially it's
set up to use the jsdoc command to output to stdin and redirecting that
into a json file. That JSON file is what still uses to generate the site.
If we moved to another static site generator we could basically just point
it at the same json file and keep the existing doc template and indiana
jones it.
I'll try a bit more, but we may need to generate the docs with something
else.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/node-swig/swig-templates/issues/8#issuecomment-243322139,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABK4jF6IfH3jriosbmlbu7fnQ7VQdRX5ks5qk6GhgaJpZM4Hg3m8
.

I got the docs site running by changing the repo name to "swig" as that was what was being pointed at.  Take a look here: http://node-swig.github.io/swig/
I hope you guys don't mind that I went ahead and did that for the sake of getting docs working.  I personally prefer the repo name being "swig" anyway, even if the package is now called "swig-templates".
@paulcpederson I fixed the VERSION assignment in the makefile which I think might have been your "npm ls" issue?  I have a handle on how to build and run the docs generator and push to the gh-pages branch although not in a good way, I'm doing some weird hacky setup things locally.
Working on updating the docs now.

I had a change of heart about whether or not renaming the repo was a reasonable idea.  Got the relevant baseurl assignments fixed so now we're back to "swig-templates" with working docs!  :tada:

@Lochlan what "weird hacky setup" things are you doing locally?

@paulcpederson I didn't really understand the comment you made about local paths (perhaps you can explain in greater/more explicit detail what steps you go through to make line 169 in the makefile succeed?), I still have the same "Cannot find module 'swig'" issue I mentioned earlier.  To combat it I installed still globally (as I previously mentioned) and changed line 169 to this:
@still docs -o ${TMP} -i "layout" -i "json" -i "less" -v

But then the rest of the gh-pages makefile recipe fails because of uncommitted changes in my working tree (the Makefile itself), so I have to add the following line right after:
git reset --hard head

thus undoing the changes to the makefile I just made.  This is obviously a super weird approach.  Basically if you can explain how to ensure that still knows where to find swig then we can have a repeatable way of updating docs.

ok, I had the local thing working back when I wrote that, but I tried it this week and now it doesn't work. (Maybe because I upgraded node?)
In any case, you got docs up on the internet, which are now the only docs for swig, so that is a huge victory.
I'm working on an experimental branch where I'm just ripping out still entirely so I'll let you know how that goes.

Marking this issue as closed as docs are now functional

make thinks my coverage is 0% so I can't commit at all...

@paulcpederson git commit --no-verify to get through the git hooks, assuming that's what you're talking about.
You can also get around the git hooks if you don't install them when setting up.


Can you please resolve the deprecation ember-cli-version-checker ?

The message keeps showing when moving the ember light table into an engine.
ember-in-viewport is the dependency of ember-light-table, isn't it?
DEPRECATION: An addon is trying to access project.nodeModulesPath. This is not a reliable way to discover npm modules. Instead, consider doing: require("resolve").sync(something, { basedir: project.root }). Accessed from:   DependencyVersionChecker.NPMDependencyVersionChecker (/Users/bzhang2/Project/mg-ui/node_modules/ember-in-viewport/node_modules/ember-cli-version-checker/src/npm-dependency-version-checker.js:11:32)

It seems the ember-in-viewport has been updated.
Would you please update the package as well? Thanks!