Fix turbolinks mount event

This change fixes "The node you're attempting to unmount was rendered by another copy of React." error when navigating to cached page using Turbolinks.
More info can be found at https://github.com/renchap/webpacker-react/pull/14#issuecomment-282500093 and https://sevos.io/2017/02/27/turbolinks-lifecycle-explained.html

This change is

Coverage remained the same at 97.898% when pulling 8ea86471f95127d144e397e2ac58087e90e41920 on szyablitsky:master into bd974c0924f8ea4500d77454c195641ab5d5f7b1 on shakacode:master.

@szyablitsky Thanks! Any details on how you resolved this issue?

Reviewed 3 of 3 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

node_package/src/clientStartup.js, line 201 at r1 (raw file):

      );
    }
    reactOnRailsPageLoaded();

@szyablitsky Are we sure that the event handlers on turbolinks:render or page:change won't  causes a double render?

Comments from Reviewable

I included a link to the article where this issue explained in full details.
In short, when user visits cached page, Turbolinks first render cached version, then (when page is loaded) render loaded version, so we have two turbolinks:before-render events and one turbolinks:load event. Second turbolinks:before-render tries to unmount components but they are already unmounted. So we use turbolinks:render which is called  after each turbolinks:before-render. And we should mount components on page load (DOMContentLoaded), because Turbolinks do not fire turbolinks:render on first page render.

Review status: all files reviewed at latest revision, 1 unresolved discussion.

node_package/src/clientStartup.js, line 201 at r1 (raw file):
Previously, justin808 (Justin Gordon) wrote…
@szyablitsky Are we sure that the event handlers on turbolinks:render or page:change won't  causes a double render?

My bad. Forgot about Turbolinks 2. Will fix now.

Comments from Reviewable

Coverage remained the same at 97.898% when pulling d987b38f45f26915e44a5dfc9045fb7a17acd398 on szyablitsky:master into bd974c0924f8ea4500d77454c195641ab5d5f7b1 on shakacode:master.

Looks good. 100% sure we can ship, @szyablitsky?

Reviewed 1 of 1 files at r2.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks broke.

node_package/src/clientStartup.js, line 201 at r1 (raw file):
Previously, szyablitsky (Sergey Zyablitsky) wrote…
My bad. Forgot about Turbolinks 2. Will fix now.

Let me know when you're sure we're good to go and I'll release this!

Comments from Reviewable

We need to rebuild on CI because it's timed out on bundle install.

As soon as I can get this to pass CI, I'll release.

error:
Installing rails-html-sanitizer 1.0.3
Installing capybara 2.12.1
Gem::RemoteFetcher::UnknownHostError: timed out
(https://rubygems.org/gems/pry-rescue-1.4.5.gem)
An error occurred while installing pry-rescue (1.4.5), and Bundler
cannot continue.
Make sure that `gem install pry-rescue -v '1.4.5'` succeeds before bundling.
The command "bundle install" failed 3 times.
The command "travis_retry bundle install" failed and exited with 5 during .
Your build has been stopped.

I'll restart

Thanks @szyablitsky


Arabic templates: fix size of the logo in the header

This is a matter of including a different image asset.

This is moved to https://github.com/international-labour-organization/drupal-templates/issues/27


Batch knnQueries and Batch element insertion support?

Batch knnQueries:
The method knnQuery(query_point, k) takes float[] as query point. What if we want to perform batch queries for float[][] type multiple elements from index? (This feature is particularly needed take full advantage of internal hardware SIMD and parallelism of CPU)
Batch element insertion:
In the given examples, the method addItem() takes an float[] array for insertion. What if a user has float[][] of feature vectors? there should be addAll() function (like this)

Hi @ashfaq92,
Yeah, that is a limitation we have in our library. JNA doesn't support multi dimensional arrays and that's why it wasn't included here.
https://stackoverflow.com/questions/42042453/jna-two-dimensional-arrays/42049334
BR,
Hussama

alright, Thanks. So we can use for loops.

Hi @ashfaq92,
I hope you're well.
Did it work fine for you using the loop for to add items? I'm looking into the possibility of implementing the batch add/queries operations (and checking SIMD). I forgot to say but in our unit tests we have an example of adding multiple items using a multi-threaded approach (which brings a good speed up). However, indeed, we could provide it within the library so that users could easily profit from it. I'll do it! :D
BR,
Hussama

adding elements using for loop works but  takes linear time which can be increased by using threading. I shall check out the threading examples again. However, it would be great if there is a support for batched queries. Today, I tried FAISS, it had batched queries support.
Get Outlook for Androidhttps://aka.ms/ghei36

From: Hussama Ismail<EMAIL_ADDRESS>Sent: Monday, July 6, 2020 4:29:43 PM
To: stepstone-tech/hnswlib-jna<EMAIL_ADDRESS>Cc: Muhammad Ashfaq<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [stepstone-tech/hnswlib-jna] Batch knnQueries and Batch element insertion support? (#6)
Hi @ashfaq92https://github.com/ashfaq92,
I hope you're well.
Did it work fine for you using the loop for to add items? I'm looking into the possibility of implementing the batch add/queries operations (and checking SIMD). I forgot to say but in our unit tests we have an example of adding multiple items using a multi-threaded approach (which brings a good speed up). However, indeed, we could provide it within the library so that users could easily profit from it. I'll do it! :D
BR,
Hussama
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/stepstone-tech/hnswlib-jna/issues/6#issuecomment-654093561, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AG27DQSRZQVUN5BKB3X72RDR2GDPPANCNFSM4OMJ6MUQ.

Thanks a lot @ashfaq92 for the remarks. It's still on my plate to think about how to implement the batch queries. Could you please point me to FAISS example? do you think their approach suits you and other use cases well? Would you have other suggestions?
The addAll is also a good option to speed up the model building but I'm still thinking if we should work with an object like the native Java version does (which contains a vector and an id) or work with separated lists like the native hnswlib does. In meanwhile, I added an example of how to build an index with multi-thread. (https://github.com/stepstone-tech/hnswlib-jna/blob/master/hnswlib-jna-example/src/main/java/com/stepstone/search/hnswlib/jna/example/App.java)
Have a great afternoon! :D

hi @hussamaa, according to my knowledge, FAISS is good for small scale nearest neighbor search. It has extremely fast indexing speed with little trade off on query accuracy and query efficiency. But if you need to make indexing more often especially when the size of index changes more often, FAISS can be the candidate. In my application domain, my nearest neighbor queries are incremental. In other words, batch queries has to be performed on data-set and then add some elements in data set. This process repeats. In this way, HNSW or Annoy may not ensure good performance. However, more experiments need to be done on that. So far, FAISS is only available in C++ on Linux platforms. So batch queries and multithreading of FAISS is only available in its native C++ (which is not a big deal because HNSW also supports it in its C++ and Python version). But, our this project i.e. HNSW with JNA comes with inherited limitations of JNA. Therefore, it will become challenging to use full features of an algorithm by calling it through JNA.
I have tried  this FAISS example. In terms of use cases, it depends upon person to person and application domain to decide which nearest neighbor algorithm to use. I suggest to read this and this. It will help to understand general overflow of algorithms.
In terms of FAISS setup, I am available to guide if you face any problem.


WN: SignalR distributed tracing: Pre-work moving as is to include

Contributes to #33546
This is just the pre-work of moving the content as-is from the Product Unit into an include that is easier to diff from once I edit it.

Internal previews

📄 File
🔗 Preview link

aspnetcore/release-notes/aspnetcore-9.0.md
What's new in ASP.NET Core 9.0

@BrennanConroy, this is just a prep for moving your original content to an include for the What's New before I do an edit and move inline code to a project and link it back in.
However, it looked like I should combine the new SignalR client ActivitySource and previous server ActivitySource into one section.  I have not edited yet, basically just added those two sections under one parent section.  Does that generally look OK?  If so I will merge this, and then you will see a diff in the next PR for any edit changes I make if needed.  Thanks.

I will go ahead and combine the two ActivitySource sections into one grouping and merge, then create a new PR to edit and move the code out to a project and link back in.
This PR was just prep only so we have something to diff against for edit.


lr_scheduler do not support ReduceLROnPlateau

ReduceLROnPlateau takes an metric( such as validation loss) as input. But on LRPolicy.on_epoch_begin do not received metrics.

Hi @zheLim,
If you need to use ReduceLROnPlateau in the meanwhile, you can quickly add this in classifier_compressor.py manually.
Cheers
Neta

Support added with #182. It allows passing additional keyword arguments to on_epoch_begin. In the case of LRPolicy using ReduceLROnPlateau, if an argument named metrics was passed it'll be passed on the LR scheduler.
Note that the examples in the PyTorch docs show that ReduceLROnPlateau is called at the end of the epoch. We call it at the beginning, similarly to other LR schedulers, which means special handling is required on the first epoch. We might change this in the future.
For a usage example see the image classification sample:
https://github.com/NervanaSystems/distiller/blob/master/examples/classifier_compression/compress_classifier.py#L275-L277


请求发射羊毛功能扩展

目前已经可以发射羊毛或者火
请求增加下可以发射凋灵骷髅（凋零发射的那个）、雪球、烈焰人飞弹的扩展功能。
谢谢！

Translate: Request to extend the function of PowerRainbow
To make it able to fire wither skull, snowball and fireball.

Wouldn't it be better to create a new power for each projectile like it is done with the arrow power? The Rainbow power is designed to shoot blocks instead of standard projectiles.


[OSCI] Adds new author rileyli

Description
Added Riley Li as author for #osci2023
Issues Resolved
Completed Task1 of OSCI_2023
Check List

[☑ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the BSD-3-Clause License.

@MadaniKK can you address Josh's requests? Thank you!

@MadaniKK can you address Josh's requests? Thank you!
Done! Thank you!


Confusion over document and async support

Hi,
Really enjoying using suricatta in my project but I have the follow question.
I am trying to add support for async queries to my project The docs suggest to do the following,
(defn execute
  ([ctx q] (execute ctx q {}))
  ([ctx q opts]
   (let [act (.-act ctx)
         fun #(% (exc/try-on (sc/execute ctx q)))]
     (p/promise
      (fn [deliver]
        (send-off act (fn [_] (fun deliver))))))))

(defn fetch
  ([ctx q]
   (fetch ctx q {}))
  ([ctx q opts]
   (let [act (.-act ctx)
         fun #(% (exc/try-on (sc/fetch ctx q opts)))]
     (p/promise
      (fn [deliver]
        (send-off act (fn [_] (fun deliver))))))))

However I get the following error
java.lang.IllegalArgumentException: No matching field found: act for class suricatta.types.Context
So it seems like I don't have access to the actor for that type. I am assuming that -act is the actor we we use send-off later on.
I can see that the actor was refactor out in this commit,
https://github.com/funcool/suricatta/commit/d599e22fbcf3cacf6081372ddd7fc7147a63c431
What is the correct way to support aysnc queries? Was this removal on purpose?
Thanks

Yes, it is a temporary change, but I pretty sure I will include (again) async support just out of the box.
For this moment you can use your own thread pool for schedule the blocking calls.

Is your suggestion to follow what you been doing in the uxbox-backend project?


Import and other accounts

The team uses many special purpose accounts like http://www.openstreetmap.org/user/nammala_labuildings - for LA building imports. Let's track these also.
cc @batpad @maning

@mapbox/team-data - can you all list your import and other OSM accounts we use to map for various projects? Thank you!

Upendra:
Regular OSM account username - upendrakarukonda
LA building OSM account username - upendra_labuilding

Regular account: saikabhi
LA building imports: saikabhi_LA_imports
SF imports: saikabhi_sfimport

OSM Regular: Fa7C0N
OSM Imports: Fa7C0N_imports

Here are the import accounts I have used so far.

BharataHS_laimport
BharataHS_import
BharataHS_sfimport

OpenStreetMap accounts
Regular account: jinalfoflia
LA building imports: jinalfoflia_labuilding

My OSM accounts
OSM normal account: Chetan_Gowda
LA building imports: chetan_labuildings
SF imports: chetan-sfimport

Regular account: andygol
I manage special account for import addresses in Dnipro, Ukraine - dnipro_import

Regular account: samely
LA building import: samely_labuildings

Regular account: dannykath
LA building imports: dannykath_labuildings

thank you everyone. fixed in #14

Regular account: nammala
LA building account: nammala_labuildings

Regular account: Jothirnadh
LA building account: Jothirnadh_labuildings


Fix HTML typo in README.md

tag </a> was in a wrong place

@mathemage, your fix was promoted to DAAL 2018 Beta Update 1 branch. See the commit:  eb19c19


Bug: Getting GLIBC not found errors on Ubuntu

Describe the bug
In the Ubuntu terminal I am seeing GLIBC_2.32 not found and GLIBC_2.34 not found errors when trying to run the CLI.

Steps to reproduce

Install the CLI in Ubuntu using npm i -g pizza
Run the pizza command

Browsers
Other (add additional context)
Additional context (Is this in dev or production?)
The environment is Ubuntu 20.04 (WSL)
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Contributing Docs

[ ] I agree to follow this project's Contribution Docs

Ah, we're not building with CGO_ENABLED=0
https://github.com/open-sauced/pizza-cli/blob/ae5a165ed871301b38b2a77ab73463c034c79c47/.github/workflows/release.yaml#L74-L81
this means that the binary that is produced, by default where CGO_ENABLED is 1, expects a gcc compiler to be on the system. We should build statically linked binaries since we're not sure what types of dependencies consumers will have on their system.


LCOWSupported method is not available in newer docker libs

With code that uses recent versions of github.com/docker/docker, the following error is reported:
/go/pkg/mod/github.com/openshift/imagebuilder@v1.2.4-0.20220711175835-4151e43600df/dockerfile/parser/parser.go:122:12: undefined: system.LCOWSupported
/go/pkg/mod/github.com/openshift/imagebuilder@v1.2.4-0.20220711175835-4151e43600df/dockerfile/parser/parser.go:157:12: undefined: system.LCOWSupported

This appears to be the reason: https://github.com/moby/moby/pull/42451

This was fixed in #246, but we still need to tag a release with it.  I'm hoping to get #245 and a couple of other ones that it'll unblock in soonish.

hi @nalind seems this issue has been fixed month ago, I'm wondering is there a planned release date？

We tagged v1.2.4, so I'm closing this one.


Reduces watches in serverset

This will skip nodes that already have watches on them, hopefully fixes #1221.
Goroutine count after adding this patch to one of our test instance (prometheus-a):

/cc @brian-brazil who knows his way around serversets/ZK.

If memory serves the problem here is that the zookeeper library we're using offers no way to remove a watch, so we have to keep the goroutines around to handle those watches finally arriving.
The options are either to improve that upstream, or rework how this whole bit of code works to not use a go-routine per watch.

Can you squash your commits please?

Done!

@brian-brazil is this :+1:?

Yip, must have missed the email. Thanks!


query_aggregate() limited to certain field types

Might be obvious from a database perspective, but took me a loong time to figure out: the axes argument in query_aggregate() is apparently limited to "date" and "keyword" field types, if I'm not mistaken. Relatedly, the set_fields() function seems to work only on empty indices (i.e. before uploading documents).
Both issues should be flagged in the documentation and/or backed by more informative error messages than the current 'internal server error' (HTTP 500) to save future users some time ...
Thank you!
# No field specification
my_data <- data.frame(date = rep(as.Date("2020-01-01"), 6),
                      title = paste0("Title ", seq(1:6)),
                      text = paste0("bla bla blub ", seq(1:6)),
                      aggregator = c("A", "A", "A", "B", "B", NA))
create_index("my_index", description = "My Index")
upload_documents("my_index", my_data)
get__fields("my_index")
query_aggregate(index = "my_index",
                queries = NULL,
                axes = list(list(name="aggregator",
                                 field="aggregator")))  # HTTP 500 error
set_fields(index = "my_index", list(aggregator = "keyword")) # HTTP 500 error

# With field specification
my_data <- data.frame(date = rep(as.Date("2020-01-01"), 6),
                      title = paste0("Title ", seq(1:6)),
                      text = paste0("bla bla blub ", seq(1:6)),
                      aggregator = c("A", "A", "A", "B", "B", NA))
create_index("my_index", description = "My Index")
set_fields(index = "my_index", list(aggregator = "keyword")) # Before upload!
get__fields("my_index")
upload_documents("my_index", my_data)
query_aggregate(index = "my_index",
                queries = NULL,
                axes = list(list(name="aggregator",
                                 field="aggregator")))  # Ah!

I added a specific error to flag this:
library(amcat4r)
amcat_login("http://localhost/amcat", cache = 2L)
#> ✔ Authentication at http://localhost/amcat successful!
# No field specification
my_data <- data.frame(
  date = rep(as.Date("2020-01-01"), 6),
  title = paste0("Title ", seq(1:6)),
  text = paste0("bla bla blub ", seq(1:6)),
  aggregator = c("A", "A", "A", "B", "B", NA)
)
create_index("my_index", description = "My Index")
upload_documents("my_index", my_data)
get_fields("my_index")
#> # A tibble: 5 × 2
#>   name       type
#>   <chr>      <chr>
#> 1 aggregator text
#> 2 date       date
#> 3 text       text
#> 4 title      text
#> 5 url        url
query_aggregate(
  index = "my_index",
  queries = NULL,
  axes = list(list(
    name = "aggregator",
    field = "aggregator"
  ))
)
#> Error in `query_aggregate()`:
#> ! Aggregation axes need to be either date or keyword fields. Check the
#>   field types with `get_field()`

Created on 2023-09-21 with reprex v2.0.2
Generally, the error 500 thing is a little annoying. Generally I think it would be better if we would pipe the errors from amcat through to the user. However, in this case the error I see in the server logs are quite confusing as well:
'Fielddata is disabled on [aggregator] in [my_index]. Text fields are not optimised for operations that require per-document field data like aggregations and sorting, so these operations are disabled by default. Please use a keyword field instead. Alternatively, set fielddata=true on [aggregator] in order to load field data by uninverting the inverted index. Note that this can use significant memory.'


docker volume inspect returns inconsistent driver options and labels

Summary
Using rexray/ebs, driver options and labels are not returned when docker volume inspect is called on a different ec2 instance
Bug Reports
Calling docker volume inspect on the same EBS volume from 2 different ec2 instances return inconsistent result. On the instance from which the docker volume create was issued, "Options" and "Labels" fields are correctly populated. On a different instance, they are always null.
Version
rexray version doesn't work when rexray is installed through docker plugin install. However, this was the latest version (rexray/ebs:latest) as of Aug 13 2018, so I believe it is v0.11.3.
This is a snippet from docker plugin inspect which maybe relevant:
        ...
        "Id": "fef1d260ec6ef247a8f2b6d5f56087ac62aabd555a336786595c7080555b9db8",
        "Name": "rexray/ebs:latest",
        "PluginReference": "docker.io/rexray/ebs:latest",
        ...

Expected Behavior
docker volume inspect result should be consistent  for the same volume, regardless of where the call was issued from.
Actual Behavior
"Options" and "labels" fields are null if the docker volume inspect is called from an instance that didn't create the volume under inspection.
Steps To Reproduce

I installed rexray using docker plugin command on ec2 instance 1, with correct aws creds configured: docker plugin install rexray/ebs
Then created an EBS volume with driver options and labels:

$ docker volume create --driver rexray/ebs \
> --opt size=5 \
> --opt volumetype=gp2 \
> --label domain=test \
> ebsvol

Inspecting the created volume on the same instance returns Options correctly populated:

$ docker volume inspect ebsvol
[
    {
        "CreatedAt": "0001-01-01T00:00:00Z",
        "Driver": "rexray/ebs:latest",
        "Labels": {
            "domain": "test"
        },
        "Mountpoint": "/var/lib/docker/plugins/fef1d260ec6ef247a8f2b6d5f56087ac62aabd555a336786595c7080555b9db8/rootfs",
        "Name": "ebsvol",
        "Options": {
            "size": "5",
            "volumetype": "gp2"
        },
        "Scope": "global",
        "Status": {
            "availabilityZone": "us-west-2c",
            "fields": null,
            "iops": 100,
            "name": "ebsvol",
            "server": "ebs",
            "service": "ebs",
            "size": 5,
            "type": "gp2"
        }
    }
]

On a different ecs instance, say ec2 instance 2, where rexray/ebs is installed in the same manner as in step 1 above using the same creds, ebsvol is discoverable through docker volume ls. However, docker volume inspect result returns null for "Options" and "Labels" fields:

$ docker volume inspect ebsvol
[
    {
        "CreatedAt": "0001-01-01T00:00:00Z",
        "Driver": "rexray/ebs:latest",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/plugins/172a1a453cd6ef55d44e9fb9036c7dc92e9c8785299d3c79aebf8c6c30d92c46/rootfs",
        "Name": "ebsvol",
        "Options": null,
        "Scope": "global",
        "Status": {
            "availabilityZone": "us-west-2c",
            "fields": null,
            "iops": 100,
            "name": "ebsvol",
            "server": "ebs",
            "service": "ebs",
            "size": 5,
            "type": "gp2"
        }
    }
]

Hello @yunhee-l,
The parameters in the "Status" field are what REX-Ray is able to return. The "Options" are stored solely by Docker. If you want those options globally visible then Docker Swarm would likely need to be used so it carries over the options among hosts. I am not 100% sure whether it does this today.

Closing this, we have implemented workaround to allow customers to choose name-only comparison or full config comparison for volumes. Thank you.


Enable building with dotnetcli for non-Windows

To debug some of the issues that only repro on non-Windows, need to be able to build.
Created separate PSReadLine.csproj edited to work with dotnetcli and .NetStandard2.0.
Added build.ps1 to make this easier.
Partially covers #652

You should add a new task in PSReadLine.build.ps1 instead of adding the new file build.ps1.
The new task should probably be invoked from appveyor.yml.
And I would much rather see changes to PSReadLine\PSReadLine.csproj - I'm guessing there are about 2 lines of real difference between the files.

@lzybkr I'm fine having a single csproj, but wasn't sure if you preferred keeping the existing project as-is.

Does building against PowerShell Standard work against Windows PowerShell 5.1 on Win7 and Win10 without shipping type forwarding dlls? If so, they fine, but I'm guessing there isn't a clean solution to that problem yet.
A single csproj can build multiple ways with conditions though - and that's what I was suggesting.

@lzybkr If Win7 doesn't have .Net 4.7, the shims are needed.  Newer Win10 has 4.7.x.  We plan to have a module that contains the .Net Std shims that other modules can reference.

@lzybkr are you ok if we move both the Windows and non-Windows build to dotnetcli?  Would simplify things quite a bit.

@SteveL-MSFT - if you submit a PR so I can see how it's simpler, that would help.
I don't want to distribute unnecessary private copies of dlls, I'm already unhappy about needing System.Runtime.InteropServices.RuntimeInformation.dll.
I also don't want runtime logic that might affect startup time, e.g. path searching for type forwarders dlls.

I'm going to have to put this on hold for now.  Got it building and tests running with dotnetcli, but tests fail to run correctly.

Almost got this working

@lzybkr I think this is ready for review

@lzybkr verified solution builds and tests run in VS2017

@lzybkr the .psd1 file wasn't changed in this PR and looking in my repo, it's still set to 2.0.0


Added three ESDIRK schemes [RK_solvers]

I added the implicit trapezoid rule, L-stable ESDIRK-32, and A-stable ESDIRK-33. The latter two are stiffly accurate, and all three have stage-order two.

@tzanio what is the deal with this? It seems to pass all the tests. Are there other things I need to do?

@bensworth, when it is ready you are also supposed to add the ready-for-review label :)
The bot is just reminding us that the PR is old and has not been processed, which is a good thing...

@bensworth could you run these through the convergence tests, see tests/unit/linalg/test_ode2.cpp.

@bensworth could you run these through the convergence tests, see tests/unit/linalg/test_ode2.cpp.

@vladotomov What's the correct way to do this? I added the new integrators to test_ode.cpp in /tests/unit/linalg directory, but the linalg directory doesn't seem to copy to my build directory. In my_build/tests/unit/' the only executables I see  psedov_tests_cpu    punit_tests      sedov_tests_debug psedov_tests_debug  sedov_tests_cpu  unit_tests. Note, when I run make -j test ` in my build directory, I pass all but one test:
99% tests passed, 1 tests failed out of 84

Total Test time (real) = 118.06 sec

The following tests FAILED:
	  4 - punit_tests (Failed)
Errors while running CTest

This happens with or without the new integrators though.

It should be encapsulated in the unit_tests executable. Your tests belong into test_ode.cpp not the second order ODE integrator test.
Depending on what build system you use (with cmake you run make unit_tests in your build directory). Then you can run
./tests/unit/unit_tests -s

and grep for your test tag, or just run the tag separately.

Thanks @jandrej, added unit tests and they all pass.

Travis seems not happy with the code formatting. Can you run make style with the correct astyle version in your mfem root directory? If that's too much of a setup, let me know and I'll apply the style changes to the branch.

I don't know about the make style/astyle? I did a quick look at travis and think the issue was I used 4-space tabs, not three. If that doesn't fix it, if you could run the astyle that would be great.

@jandrej, can you approve?

Merged in next for testing...

Merged in post v4.2 next.

Should this be mentioned in CHANGELOG?

Thanks for adding these Ben!


Use crazy scalac flags

See details here: http://tpolecat.github.io/2014/04/11/scalac-flags.html. We probably might want to use those flags.

I've started adding flags to the compiler and have run up against some interesting warnings:

Xlint - "it is not recommended to define classes/objects inside of package objects" -- This happens all over the project
xLint - "Selecting value Db from object Main, which extends scala.DelayedInit, is likely to yield an uninitialized value" -- -Xlint causing trouble again
Ywarn-value-discard -- This actually raises a bunch of warnings in our tests, especially around calling intercept.

The first warning suggests a pretty massive restructuring of Finch might need to happen. Basically, we can't define classes/traits inside package objects.
For the second warning, I probably just need to fiddle with where DB is defined (will probably put it in its own object).
The third warning is more annoying than anything else because we are intentionally discarding those values.
Additionally, I'd like to -Xfatal-warnings to make warnings to be fatal, but cannot at the moment because of #86.
Thoughts on these (especially issue 1, 3, and using -Xfatal-warnings)?

Nice job @rpless on this comprehensive analysis!
I think we can postpone enabling Xlint flag for now (I have some plans on how to reduce the amount of code in package.scala classes, but this is not urgent at all). We can definitely enable xLint and -Xfatal-warnings (once we fix #86). I'm not sure I understood Ywarn-value-discard flag semantic. Do we really use intercept? I was thinking I replaced them all with an [Exception] should be thrownBy. But it's probably the same as intercept.

We still have a couple of intercepts hanging around and its also happening on an [Exception] should be thrownBy.

Done by @rpless.


Remove unneeded threshold for text drawing tests

The only remaining test failures for text drawing tests are caused by Windows version differences between the build machines and local development machines.  The only places where any differences occur is in tests with transformed text matrices but followed no regular pattern, which suggests that slight floating point differences are being handled differently when anti-aliasing.  The differences are incredibly small, with just a 1 bit difference on some part of the outside edges of some letters (say 127/127/127 RGB vs 128/128/128).  Because these are just value differences we can safely use PixelComparisonModeMask to ignore them, while removing the threshold to keep the test sensitive to any future regressions.
Some test images have been updated to reflect updated output which fell behind slightly due to thresholds.
Fixes #2107

@DHowett-MSFT I neglected to mention this to you after you came back, but I have a proposal.
https://en.wikipedia.org/wiki/Color_difference I didn't read through all of it, but basically the 1976 primitive measurement of minimal perceptible color difference by the human eye is something like an RGBA difference of 2.3*256/100 = ~5.8.
Rather than shifting everything to mask, I think we should add a comparator that treats pixels as the same if they fall within an RGBA distance of... let's say half that, so 3. Thoughts?

Updated because they were failing on dev box with blue failures.  I think a few were still failing w/ perceptual comparison but don't want out of date images ykwim

Nit: reword everything in title and body to better reflect what we are now doing


Window appears in the ALT-TAB switcher despite being minimized to the system tray

Fixed in v<IP_ADDRESS>


Hot reloading of configuration

Describe what you would like to achieve
Currently the configuration is only read on startup, changing the monitored prefixes requires restarting the instance.
In an environment which has many prefix monitors, the configuration of which change in a relatively dynamic manner this requires restarting the process very regularly (hourly/daily) interval.
Describe why the current solution (if any) is not satisfactory

During the process restart any RIS messages are lost, potentially causing missed messages
alarmOnlyOnce only applies during the single run, causing messages to re-trigger at the restart interval
notificationIntervalSeconds only applies during the single run, causing messages to re-trigger at the smaller of notificationIntervalSeconds and the restart interval

Provide an example
Start the instance with a prefixes.yml;
<IP_ADDRESS>/24:
    asn: [54113]
    description:  example prefix 1
    ignore: false
    ignoreMorespecifics: false

Once running update prefixes.yml;
<IP_ADDRESS>/24:
    asn: [54113]
    description:  example prefix 2
    ignore: false
    ignoreMorespecifics: false

<IP_ADDRESS>/24:
    asn: [54113]
    description:  example more specific prefix
    ignore: false
    ignoreMorespecifics: false

No new prefixes will be subscribed to, any withdrawals, announcements etc will not be notified.
Your information
@DamianZaremba, Fastly / Infra Bits

I think there are generally 2 approaches to this problem;

Implement hot re-configuration and support the relevant subscribing/unsubscribing in each connector & monitor filters.

Implement persisting alert state externally (either at runtime, or during a clean shutdown) and loading alert state on startup, reducing the impact of restarting on alerting. This could also be useful for things such as #60.

It doesn't touch the issue of potentially dropping messages, however there are numerous other cases (reconnects) where that could happen, so I think that could be treated separately.

Hi @DamianZaremba,
I implemented your proposal n.2 here: https://github.com/nttgin/BGPalerter/pull/273. It will probably go out with the next release. The status of the application is persisted now.
Thanks for your feedback.

That looks great, thanks for taking care of this @massimocandela!

Hi Damian, in the end I implemented also a hot reloading in case of changes in prefixes.yml
This issue has been opened, closed, re-opened, re-closed... 😛

That's great.
I did notice a side effect of 'restart while persisting alerts' being that the new release notifications are either super spammy (notify on startup) or never triggered (if restarting faster than 5 days)... so this is hopefully a better solution for my setup :)

Hey Damian, could you elaborate?
In particular I didn't get the part "the new release notifications are either super spammy".
I'm interested in understanding if there is something I can improve.
Thanks
Ciao,
Massimo

Hey, sure;
When you have a configuration with checkForUpdatesAtBoot: true and a newer release is available, the pending update is notified at every startup; in the case that the service is restarted every hour for configuration updates then you get a pending update notification every hour (which can be more regular than prefix notifications, causing a lot of noise).
When checkForUpdatesAtBoot: false is configured the hard coded time of 5 days is used (https://github.com/nttgin/BGPalerter/blob/master/src/connectors/connectorSwUpdates.js#L75) which will never be hit if the daemon is restarted at an interval of less than 5 days (or at least this doesn't appear to get persisted with the persistAlertData option).
For my specific use case disabling the checkForUpdatesAtBoot and accepting the connectorSwUpdates connector was then essentially redundant was acceptable given the desire for up to date prefixes.
Now there is the option of hot reloading I'm trying the current dev branch with checkForUpdatesAtBoot: true re-enabled which I expect will give me both software updates after 5 days & updated prefixes.
Hopefully that makes sense.


Use a plot method instead of _repr_html

For combined plots (e.g., ConfusionMatrixAdd), we're relying on _repr_html_ to display them; however, it'd be best to display the plot directly.
We can follow this: https://github.com/scikit-learn/scikit-learn/blob/433600e68fbb12e72d8c5e0707916f5603bb7057/sklearn/metrics/_plot/roc_curve.py#L10
Essentially, the constructor calls a plot method that calls plt.subplots:
class Plot:
    def __init__(self, x, y):
        self.plot(x, y):

   def plot(self, x, y):
        fig, ax = plt.subplots()
        ax.scatter(x, y)
        self.ax_ = ax
        self.figure_ = fig

this has been implemented already in an abstract class. we're currently migrating the plots tot this new API


Kotlin Traffic plugin PoC

In order to experiment with Kotlin I thought that translating the Traffic Plugin into Kotlin would be a great proof of concept.
Here are my initial findings:

Convert Java File to Kotlin File AS option doesn't work that well... Especially with complex classes. I tried to convert TrafficPlugin.java and Kotlin generated class was full of errors, so I decided to do it step by step porting each class/method slowly but surely (learning all pitfalls along the way).
I found a bunch of problems dealing with type safety of Java Generics (e.g. Function.java) because Kotlin compiler is much stricter.
Varargs in Kotlin are a bit different. You need to use the spread operator (prefix the array with *) to indicate that it's a vararg.

Next steps:

[ ] Calling Kotlin from Java

[ ] Understand Kotlin-related annotations (i.e. @JvmName, @JvmField, etc.)

[ ] Take advantage of FP and Kotlin features (e.g. extension functions) to build well-designed DSLs across our SDKs
[ ] Documenting Kotlin Code (KDoc)
[ ] Analyze

[ ] klint
[ ] detekt

[ ] Continue exploring and experimenting
[ ] Add your topic here

cc/ @zugaldia

What's the status on this plugin or was this just an experiment to learn Kotlin? The traffic plugin already exists so I'm not sure what the difference between this plugin and the one already released is.

@cammace

What's the status on this plugin or was this just an experiment to learn Kotlin?

It was an experiment which its main purpose was to start exploring how to build plugins completely written in Kotlin (analyzing pros and cons, pitfalls, etc.) and to start thinking about using the language across our SDKs (examining what it offers us in terms of implementing better libraries).

The traffic plugin already exists so I'm not sure what the difference between this plugin and the one already released is.

Actually, there is no difference. No need to get merged.
But it could be useful though to compare a plugin written in Java vs one written in Kotlin and take it as a case of study.
What do you think?

Actually, there is no difference. No need to get merged.
But it could be useful though to compare a plugin written in Java vs one written in Kotlin and take it as a case of study.

Before we close this PR (agreed on not needing to merge it) I'd like to save any learnings from this process while we keep researching https://github.com/mapbox/mapbox-plugins-android/issues/15. @Guardiola31337 How about we move the most relevant pieces of this PR to a wiki page in this repo? It could be a resource that we share with developers starting to use our SDKs with Kotlin.

I think this PR is safe to close now? Otherwise I can rebase since we have adjusted the file structure in this project.

stale


[v0.0.9a - ready] Find MAC address automatically + add option to deactivate proximity scanner

Implement dedicated function to find MAC from VIN:

Derive BLE LNAME from VIN using sha1sum. I cannot find origin post about this, though documented here in python
Find MAC address using bluetoothctl scan. Credit to BogdanDIA

Add option to activate/deactivate proximity sensing.
Rule:

if proximity sensing is activated and BLE_MAC is defined to a non empty string the listen_to_ble function will be called as in v0.0.8
if proximity sensing is activated and BLE_MAC is not defined or is empty string the calc_ble_from_vin will be used to find the mac address to enable calls to listen_to_ble. It is tried at container startup and periodically if the MAC cannot be detected.
if proximity sensing is deactivated, none of the above is done

I took a completely different approach with a Expect scripts - it's an all-in-one app.
Here's a snippet of the available settings. I just added tons of more comments so you understand better.  - The MQTT topics have pre/post options but those 2 aren't implemented. I wanted to have a discussion w/ you guys on what makes sense.
After the settings, an explanation of the current script's features.
Settings:
# Single VIN or regex "SabcdefghijklmnopC|SponmlkjihgfedcbaC"
export VIN_REGEX=

# Default first bluetooth controller
export BLE_CONTROLLER=

# After how long the vehicule is considered not present
export PRESENCE_TTL=180

export MQTT_SERVER=mqtt.zutzut.com
export MQTT_SERVER=<IP_ADDRESS>
export MQTT_PORT=1883
# Default mqttv31
export MQTT_PROTOCOL=

# Default anonymous
export MQTT_USERNAME=
export MQTT_PASSWORD=

# Example: tesla_ble/1/binary_sensor/presence
export MQTT_POST_TOPIC=binary_sensor/presence
export MQTT_PRE_TOPIC=tesla_ble/$CAR or $VIN ???
export MQTT_TOPIC=tesla_ble/binary_sensor/presence

# Obsolete
# CHG status messages tells us if the vehicule is present or not
# The cache might be wrong due to bugs but a CHG message tells us exactly
# what we need.
export REMOVE_CACHE=false

# Probably not needed anymore
export SCAN_TIMEOUT=60

Current features:

Supports single or multiple VINs via a regex
Runs non-stop in background
Spawn bluetoothclt background process and listens to live messages
Automatically find BLE MAC addr associated to a Local Name
Spawns background mosquitto_pub process (if it dies, mqtt server restart? - it relaunchs)
MAC addr array associated with a TTL
Uses CHG and NEW status messages to refresh MAC addr's TTL
Publish to MQTT (ON/OFF) only when needed by relying on the MAC addr array
Able to publish ON or OFF to a MQTT topic

Todo:

"auto-discovery / stalker" mode - anything that matches a Tesla BLE Local Name S.....C  - Your friends&family coming to you place? HA can send you a notif when they arrive or leave.
Perhaps allow end user to track anything Bluetooth... disable bluetooth_le_tracker? 🤔
Possibly move away from env var and user command line args
Move to command line arguments, instead of environment vars
MQTT encryption / client certificate options...... proxy?!

Question:
Why is the presence value currently defined as ON & OFF instead of a bool True & False?
With the live listening implementation, I had 0 BLE dongle issues at all and it's something I've been doing very very often .. and even let it run overnight.
... Any suggestions / comments / questions?
I am available tomorrow for Discord or WhatsApp audo or video. Not sure if Discord does video or audio?  I think it would be easier to discus over voice/video than chat.

In case someone read the above comment minutes ago, I just updated it.

Implement dedicated function to find MAC from VIN:

Derive BLE LNAME from VIN using sha1sum. I cannot find origin post about this, though documented here in python
Find MAC address using bluetoothctl scan. Credit to BogdanDIA

Add option to activate/deactivate proximity sensing.
Rule:

if proximity sensing is activated and BLE_MAC is defined to a non empty string the listen_to_ble function will be called as in v0.0.8
if proximity sensing is activated and BLE_MAC is not defined or is empty string the calc_ble_from_vin will be used to find the mac address to enable calls to listen_to_ble. It is tried at container startup and periodically if the MAC cannot be detected.
if proximity sensing is deactivated, none of the above is done

Regarding the credit for using sha1sum, I also got the idea from https://teslabtapi.lexnastin.com/docs/start#vehicle-ble-name so that seems good unless @BogdanDIA or @baylanger have another reference

Keeping this one as draft until https://github.com/tesla-local-control/tesla_ble_mqtt_core/pull/12 is merged


fix compiler error on macos 13.3

there is some compile error on the new macos 13.3 with Apple clang version 14.0.3 (clang-14<IP_ADDRESS>.1)

error message when compiling hfuzz_cc/hfuzz-cc.c
["clang: error: '-x objective-c' after last input file has no effect"](clang: error: '-x objective-c' after last input file has no effect [-Werror,-Wunused-command-line-argument])

Please re-open if you decide to sign the CLA.


TargetFramework net6.0-windows10.0.19041.0 does not work

Describe the bug
Using both WPF or Test projects targeting net6.0-windows10.0.19041.0 does not appear to work.  It seems to assume a WinRT platform path based on the stack trace.
System.InvalidOperationException : Exception of type 'System.InvalidOperationException' was thrown.
Data:
  Description: <null>
  RestrictedDescription: <null>
  RestrictedErrorReference: <null>
  RestrictedCapabilitySid: <null>
  __RestrictedErrorObjectReference: <null>
  __HasRestrictedLanguageErrorObject: False
   at WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|20_0(Int32 hr)
   at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
   at ABI.Windows.Storage.IApplicationDataStaticsMethods.get_Current(IObjectReference _obj)
   at Windows.Storage.ApplicationData.get_Current()
   at Microsoft.Datasync.Client.Platforms.ApplicationStorage..ctor(String containerName)
   at Microsoft.Datasync.Client.Platforms.CurrentPlatform.<>c.<.ctor>b__6_0()
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.get_Value()
   at Microsoft.Datasync.Client.Platforms.CurrentPlatform.get_ApplicationStorage()
   at Microsoft.Datasync.Client.Utils.Platform.GetApplicationInstallationId()
   at Microsoft.Datasync.Client.Utils.Platform.<>c.<.cctor>b__12_1()
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
   at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
   at System.Lazy`1.CreateValue()
   at System.Lazy`1.get_Value()
   at Microsoft.Datasync.Client.Utils.Platform.get_InstallationId()
   at Microsoft.Datasync.Client.Http.ServiceHttpClient..ctor(Uri endpoint, AuthenticationProvider authenticationProvider, DatasyncClientOptions clientOptions)
   at Microsoft.Datasync.Client.DatasyncClient..ctor(Uri endpoint, AuthenticationProvider authenticationProvider, DatasyncClientOptions clientOptions)
   at Microsoft.Datasync.Client.DatasyncClient..ctor(Uri endpoint, DatasyncClientOptions clientOptions)

To Reproduce
Change the .csproj TargetFramework to use net6.0-windows10.0.19041.0.  Construct a new instance of the Microsoft.Datasync.Client.DatasyncClient and an exception is thrown.
Expected behavior
Should be able to use the DatasyncClient in desktop apps leveraging Windows Runtime APIs
What platforms?

Server (ASP.NET Framework, ASP.NET Core, NodeJS):
n/a

Client (.NET, JavaScript, iOS, Android):
WPF
net6.0-windows10.0.19041.0
Haven't tried other targets using the WinRT APIs in Desktop apps, but my guess is other targets may be broken too.

This is going to be a bit of a bear.  See https://github.com/microsoft/WindowsAppSDK/issues/1721
Basically, you need to package to be able to support ApplicationStorage.
I'm going to have to re-think the whole ApplicationStorage thing and how it is manifest in the product, which will take some time.

In the interim, use ClientOptions.InstallationId to set a specific installation ID:
var options = new DatasyncClientOptions { InstallationId = "test" };
var client = new DatasyncClient(serviceUri, options);

This can be set rather easily in the TodoApp.Data project - add it to the default options handler at line 91 in the RemoteTodoService.cs file.

The fix is in.  Basically, if you have an unpackaged app, then the ApplicationDataStore is not available and you SHOULD set the InstallationId accordingly.  If you don't, then a unique ID is set and used instead.  This is "as good as it gets" for the setup.
Will be in next release.

Seems fine enough.  Although I'm not sure what you're using the InstallationId for?  Is it critical? Is it just used in the HTTP request headers for client request tracking server side?

Yeah - it's for client request tracking server side.

"Fixed" in #582


[Performance]A17 PRO ANE has much more computing power than M2, but its stable diffusion performance is worse than M2?

Hello, as the title indicates and snapshot from the benchmark of stable diffusion xl in this project, it can be seen that the performance of A17Pro 35T ANE is worse than M2 ANE 15.8T. Is there any other reason besides the large memory bandwith gap?
It seems that the A17Pro 35T's high computing power is not being used very effectively at all.

As a supplement, I used diffusers app to inference SD1.5 using ANE on my iPhone15 pro(A17Pro), and I found that E2E times were about the same as M2.

https://www.cpu-monkey.com/en/compare_cpu-apple_a17_pro-vs-apple_m2_pro_12_cpu_19_gpu
I think you might consider about their cores.

https://www.cpu-monkey.com/en/compare_cpu-apple_a17_pro-vs-apple_m2_pro_12_cpu_19_gpu I think you might consider about their cores.

unet runs on ANE, as can be seen from the specifications. Both the A17Pro and M2 ANE have 16 cores, but the A17Pro is much more powerful, 35T VS 15.8T, but the performance is worse. It's incredible.

You cannot just see the "ANE" part. The compute Unit is "CPU and NE". Maybe the CPU part add M2 power.
Or just Apple got screwed.
When using CPU + ANE, CPU will also use a lot power.

You cannot just see the "ANE" part. The compute Unit is "CPU and NE". Maybe the CPU part add M2 score. Or just Apple got screwed.
When using CPU + ANE, CPU will also use a lot power.

The CPU will always have power consumption, that's not the point.
I encourage you to use the instrument coreml template for further analysis, you will see that all the unet operators are executed on ANE. The cpu has only a very small amount of workload. It is also very small compared to the latency of ANE computation.
Our view from a more microscopic decomposition point of view is that the time of unet ANE computation is already slightly slower than M2.

Thank you for your information.
I met similar problem on M2 Pro and M2 that M2 Pro runs slower than M2, and when using computeUnit==All will run twice slower than CPU_AND_NE.
Maybe I can use this to check if M2 Pro has something wrong that it runs slower than M2 when it runs through unet.


Stop sandbox implicitly on rmp

A running sandbox should be stopped before removal so allow proper unmounting of all devices. I would like to see this feature in crictl, WDYT?

This is reasonable with an extra --force or -f option. @saschagrunert Would you like to compose a PR for this?


Define DSL1 explicitly, as Nextflow made DSL2 default

Signed-off-by: Lehmann_Fabian<EMAIL_ADDRESS>Cannot start DSL1 workflows with the newest Nextflow version. So I had to define the DSL version explicitly.
The Dev-Branch is already on DSL2, so this should be merged directly into the master to avoid problems with the stable version.
nf-core/chipseq pull request
Many thanks for contributing to nf-core/chipseq!
Please fill in the appropriate checklist below (delete whatever is not relevant).
These are the most common things requested on pull requests (PRs).
PR checklist

[ ] This comment contains a description of changes (with reason)
[ ] If you've fixed a bug or added code that should be tested, add tests!
[ ] If necessary, also make a PR on the nf-core/chipseq branch on the nf-core/test-datasets repo
[x] Ensure the test suite passes (nextflow run . -profile test,docker).
[ ] Make sure your code lints (nf-core lint .).
[ ] Documentation in docs is updated
[ ] CHANGELOG.md is updated
[ ] README.md is updated

Learn more about contributing: CONTRIBUTING.md

Thanks @Lehmann-Fabian! We have discussed doing a patch for the current stable version of the pipeline as you suggest on this PR. However, we have decided at the moment not to do it since we are close to publishing the dsl2 version and you can still run the current version of the pipeline using the -dsl1 flag of Nextflow, e.g. NXF_VER=22.04.0 nextflow run nf-core/chipseq -profile test,docker -dsl
Hence, I will close this PR by the moment.

You are right @JoseEspinosa . Running with -dsl1 is the same. I was only confused why the workflow had problems running with the newest Nextflow version as it worked before. It took some time to figure out the DSL problem as it was nowhere documented. That's why I proposed to change the master to avoid confusion for other chipseq users.


New Attribute Parser

Goals:

[ ] Support for deprecated containers, fields and variants
[ ] Support for field and variant doc comment exporting

fixes #144 #116 #32

This has got outta date with main.


Error on opening Pod Logs

Katacoda: keynote demo
I'm not sure if this is a Katacoda issue or a Scope problem. But with the Sockshop launched in katacoda, I am getting a no such node error in trying to retrieve container logs from the Cart pod.
http://recordit.co/0Tteg7dEfd

I very much doubt this is a scope bug; looks like a problem with the katacoda environment / the k8s setup on it.
Alas, I cannot get that tutorial to work at all; I get stuck at step 3 - Weave Cloud doesn't think there are any agents connected.

You have to paste in the kubectl apply + token command from Weave Cloud in step 2 and then configure Flux.
I will post this issue over in the katacodas issue. I suspected as much since maybe all the nodes are actually running on the same virtual machine?

You have to paste in the kubectl apply + token command from Weave Cloud in step 2 and then configure Flux.

Ah yes, am just doing that now...

I am getting the same error in the katacoda shell:
root@master:~# kubectl -n sock-shop logs cart-2013512370-v9xxq
Error from server: Get https://node01:10250/containerLogs/sock-shop/cart-2013512370-v9xxq/cart:
dial tcp: lookup node01 on <IP_ADDRESS>:53: no such host

Looks like name resolution is broken in this katacoda setup.

Ok thx I will log this one in the katacoda issues.


Crash when using h2 database

digdag crashed and cannot restart process only executing # systemctl restart digdag
/var/log/digdag/digdag-error.log
General error: "java.lang.NullPointerException" [50000-192]
        at com.google.common.base.Throwables.propagate(Throwables.java:160)
        at io.digdag.core.database.DataSourceProvider.createSimpleDataSource(DataSourceProvider.java:70
...
Caused by: org.h2.jdbc.JdbcSQLException: 一般エラー: "java.lang.NullPointerException"

It fixes with command below.
$ sudo systemctl stop digdag
$ sudo mv /var/digdag/database /tmp
$ sudo systemctl restart digdag

I guess this crash caused by resteasy-client bug.
https://issues.jboss.org/browse/RESTEASY-1238
and the bug fixed by this PR which released in 3.0.23.Final
https://github.com/resteasy/Resteasy/pull/1169
My envirtonment

OS: ubuntu 16.04.2 LTS
digdag version: 0.9.12

database.type=h2

java:

openjdk version "1.8.0_162"
OpenJDK Runtime Environment (build 1.8.0_162-8u162-b12-0ubuntu<IP_ADDRESS>-b12)
OpenJDK 64-Bit Server VM (build 25.162-b12, mixed mode)

So I bumped up resteasy-client in this PR. https://github.com/treasure-data/digdag/pull/754
But CI failed with executing webpack which mentioned to my another issue. https://github.com/treasure-data/digdag/issues/753

@takanamito thank you for reporting and suggesting. To take a look this issue, can you tell us 1) Your full stacktrace if you can. 2) How to reproduce this issue I'm still not sure why this error happened.

@takanamito thank you for sharing. let me take a look.

@takanamito roughly checked your stacktrace and https://issues.jboss.org/browse/RESTEASY-1238. I agree with you and https://github.com/resteasy/Resteasy/pull/1169 could mitigate this issue. Please re-create or re-open ticket to upgrade resteasy library?

@takanamito if my understanding is correct, this issue was already fixed. i close this ticket but, please let me know if you have anything.


sets project name if empty fixes #5597

Summary
When a project name does not exist it uses the name based on the main rootDir. This causes the incorrect resolver to be selected since all projects names resolve the same. The fix is to create a unique name for projects that do not have one.
fixes: https://github.com/facebook/jest/issues/5597

Test plan
Added unit test:

projects without names
projects with rootDir
projects with names

The tests do not pass right now because I am having trouble with the types. If anyone has advice I would appreciate it.

Huh, I had no idea name was a thing. You learn something every day!

Thanks for the fix! I'm a bit worried that this diff will only fix this issue for uses of the multi project runner where the config objects are passed in but it won't work when specifying multiple paths to various configuration files.

@cpojer I think I can see what you are getting at. I spiked combining https://github.com/facebook/jest/blob/master/packages/jest-cli/src/cli/index.js#L228 and https://github.com/facebook/jest/blob/master/packages/jest-cli/src/cli/index.js#L248 to something like:
  if (projects.length > 0) {
    const parsedConfigs = projects
      .filter(root => {
        if (
          typeof root === 'string' &&
          fs.existsSync(root) &&
          !fs.lstatSync(root).isDirectory() &&
          !root.endsWith('.js') &&
          !root.endsWith('.json')
        ) {
          return false;
        }

        return true;
      })
      // readConfig recursively finds project paths by looking in `parsedConfig.projects`  `globalConfig.projects` and parses them as usual
      .map(root => readConfig(argv, root, true, configPath))
      .flatten();
...
  }

but I could not find a solution that I was happy with.

It looks like the only failing test is a test that is failing in master.

Failing test tracked in #5871

@cbelsole you are right, I think that's the right location to make this change. What exactly were you not sure about?

@cpojer I needed more background on how the config path was being passed in. It was not being set for me when I needed it to. So I backed that change out as to not blow up the scope of this pr.

@thymikee All tests seem to be passing besides for the known issue. Can you merge this?

I wonder if we should also have en integration test for #5597 specifically?

Codecov Report

Merging #5862 into master will increase coverage by 0.04%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #5862      +/-   ##
==========================================
+ Coverage   64.39%   64.44%   +0.04%
==========================================
  Files         217      217
  Lines        8274     8279       +5
  Branches        3        4       +1
==========================================
+ Hits         5328     5335       +7
+ Misses       2945     2943       -2
  Partials        1        1

Impacted Files
Coverage Δ

packages/jest-config/src/normalize.js
94.56% <100%> (+0.54%)
:arrow_up:

packages/jest-config/src/utils.js
90.56% <0%> (+1.88%)
:arrow_up:

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 5a21be3...80d21e6. Read the comment docs.

Whoops, I've missed that :<. I'll have to look closely tomorrow!

@cbelsole do you think we could land this? Maybe @paularmstrong has some thoughts on Christoph's suggestion?

I'm not sure I understand @cpojer's request. For me as an end-user: as long as it works, I'm happy :) Currently working around this by manually specifying project name

@cbelsole ping 🙂


Once a project is made public, it cannot be undone

In the "Permissions" page, for each project, an admin can choose to make the project accessible to everyone. Unfortunately, this decision cannot be undone. The "Preferences" page for the project is not shown anymore and any try to show it results in an error message (red block) which says "Accès interdit" (forbidden access). A project admin should be able to untick the "Allow everybody to access to this project" option.
In fact, the problem is that a project owner doesn't see the "Preferences" menu item anymore... Only a kanboard admin can.
Configuration
Copy and paste the configuration section from the Kanboard settings page or fill these fields:

Kanboard version: 1.0.27

This issue is now solved in master. Thanks.


Add explicit GCC support

Previously, I've switched from GCC to Clang to match tt-metal's toolchain in #74
@joelsmithTT raised a concern that there is no reason for us to force the user to use clang while gcc is available on the ubuntu images we support. Also switching to Clang breaks gdb debugging which is also useful.
The consensus on the chat is to support GCC as the default compiler, but leave the option for building with Clang, through Cmake options. Tasks related to this issue:

Build by default using gcc compiler, use a cmake flag for clang CMAKE_CXX_COMPILER / CMAKE_C_COMPILER

Double check if the flags can be matched with tt-metal's flags for consistency

Change CI jobs to build using both (if we're officially supporting both)
Change README accordingly

Double check that sudo apt install commands from Readme actually work


Set "preserveSymlinks" to true in tsconfig.json to support VSCode autocomplete when using PNPM

Clear and concise description of the problem
As a developer using Vite, I want to have VSCode's auto import/complete features working correctly when using pnpm as the package manager, so that I can improve the development experience.
Suggested solution
Set preserveSymlinks option to true by default in the tsconfig.json file when scaffolding a new project.
Alternative
No response
Additional context
For more context, see the issue I created in pnpm's repository.
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

It's not the silver bullet apparently, even I have set the preserveSymlinks to true, some variables' types are still not recognized, like the cssprop from the@emotion/react` in my case.

@pot-code can you try reloading the window (e.g. Ctrl + Shift + P > Developer: Reload Window) or restarting the Typescript server (e.g. Ctrl + Shift + P > TypeScript: Restart TS Server)? It seems to be working fine for me, see the picture below:

@Maikuh thanks, I'll try later

Is this required? I'm using pnpm without the config and I don't have any issues with Intellisense

Is this required? I'm using pnpm without the config and I don't have any issues with Intellisense

No, it works excellent now😇

Closing as it seems this was fixed some other way.


Use interface for Keybase "global" context for chat package

Instead of using GlobalContext or Contextified directly make a KeybaseContext interface.
It's important not to use GlobalContext directly unless you really want chat to know about the world.
It turns out this package only needs logging, clock and loading of users.
And it becomes easier to test as well.. E.g. you don't need every dependency in our app to parse a time string.

@mmaxim
cc @patrickxb @maxtaco

The commits bba082d7db6a...1884a55e7eec introduce visual changes on linux. :mag_right: 1 changed

Changed: New_Proof_PGP_generating-Generating_PGP (before) (after)

The commits bba082d7db6a...fe1af8b2a3a0 introduce visual changes on linux. :mag_right: 1 changed

Changed: unlock_folders-Single (before) (after)


slowly lower the min length

Classify this as another attempt of trying to make the launch softer and slower without severely crippling the ENS functionality:

Lower the initial auction period to 2 weeks
Make it so that the initial name length starts at 12
Every month, automatically reduce that limit one letter, arriving at the current state of 7 letters or more after 6 months

I would suggest just starting it at whatever upper limit you think is appropriate to slow start the platform and expose a protected method that the multisig can call to reduce the limit (still with some lower bound).
That way you aren't locked into a specific schedule.  Seems bad to hard code those values since things change.

To bring in a comment I made out of band: This is insufficient as it stands, since anyone can invalidate a name once, and it will remain invalidated indefinitely. Thus, I could invalidate 'ethereum.eth' on day 1, and it would be unregisterable even once the min length is short enough that it should be allowed.

Some thoughts this:

Remove the Forbidden state.  My current understanding suggests this would allow someone to continually re-register an invalid name.  Given that invalidating it again should be trivial and there is a financial incentive to do so, this seems like it could be an acceptable compromise.
With the minimum no longer being a constant, entries should contain a copy of what the minimum was at the time the auction was started. Invalidation should be done against this number rather than the current number.

Yes, with Nick's comment I think this approach is rather unviable as it would require lots of rewriting. If we have to refactor the forbidden state, add a new function etc, then it seems it would be easier simply to deploy a new contract and upgrade everything you want to lower the length

On 28 Mar 2017, at 18:44, Piper Merriam<EMAIL_ADDRESS>wrote:
Some thoughts this:
Remove the Forbidden state. My current understanding suggests this would allow someone to continually re-register an invalid name. Given that invalidating it again should be trivial and there is a financial incentive to do so, this seems like it could be an acceptable compromise.
With the minimum no longer being a constant, entries should contain a copy of what the minimum was at the time the auction was started. Invalidation should be done against this number rather than the current number.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

I think Piper's suggestion of just removing the forbidden state is a reasonable solution. And while I agree that shortening it makes more sense as a manual operation than a timed one, doing that would require introducing new fields - to track who's authorised to make that call.

I changed the code so that minLength is a getter and that forbidden mode only starts applies after it has reached the target of 6.
What's your opinion? Would this add too much complexity and micromanagement for the contract? Is it worth for the purpose of making the launch a softer and slower event?

To answer your other questions: I think this could be made workable if it just ditched the 'invalid' state entirely, per Piper's suggestion. I also think that if it were to be implemented, it would make sense as he suggests to make the method callable by the keyholders, so they can adjust the schedule of length decreases to suit conditions.
I'm of two minds about whether it's a good idea overall. On the one hand, reducing the length in stages would help spread out the initial 'land rush' and make it more manageable for people to keep up with it. On the other hand, it adds complexity that I'm not sure is justified.

The more I've thought about this the more I think that this should just be done by deploying a new registrar configured for a lower length.  Benefits I see in this approach.

Reduced registrar complexity.
Forces our hand to figure out a good deed migration pattern

I do think it's worth it to figure out a way to start with a high limit and lower it.  Slowing down the land grab will reduce a lot of risk while ENS get's battle tested.

I like this suggestion - it means that the registrar doesn't have to give special permissions to anyone. However, it would require some way to upgrade the registrar that preserves running auctions - and I don't see any way to do that short of a more or less complete rewrite to use Piper's suggested database abstraction.

Closed in favor of https://github.com/ethereum/ens/pull/105


refactor(keyvaluestorage): externalize node and react-native storage dependencies

Part of:

https://github.com/WalletConnect/walletconnect-monorepo/issues/937

Key changes

Removes storage options being passed as opts in constructor
Externalizes @react-native-async-storage/async-storage dependency for react-native entry target
Externalizes better-sqlite3 dependency for node/main entry target
Fixes tests and module mocks for new approach

Todo

[x] Test against browser runtime
[x] Test against node.js runtime
[ ] Test against React Native runtime
[ ] Followup PR for<EMAIL_ADDRESS>to integrate these changes and use @walletconnect/keyvaluestorage
[ ] Update docs where necessary as part of https://github.com/WalletConnect/walletconnect-docs/issues/166

One of the big missing bits is updating webpack config to include async storage and sqlite dep as externals i.e. just having it as peed / dep dependency won't be enough during bundling if these are used

No need for declaring externals as far as I'm aware. The webpack config for the UMD build only bundles the browser entry target: https://github.com/WalletConnect/walletconnect-utils/blob/refactor/externalize-storage-dependencies/misc/keyvaluestorage/webpack.config.js#L6
And for CJS/ESM it's just transpiling not bundling, since what is actually installed as deps only depends on dependencies in package.json 👍


Delete error when composite primary key includes timestamp

Hello, I am running into the following error when I am trying to execute a simple delete command:
DELETE FROM tableA WHERE id=1
In this case tableA has a composite primary key which includes a timestamp. The following is the resulting error:
CloudSpannerSQLException: Error while parsing sql statement DELETE FROM `tableA` WHERE `ID`=? AND ... AND `TIMESTAMP`=?: Unsupported type [java.sql.Timestamp] for argument: 2018-04-19 17:00:00.0`

The error is being thrown from nl.topicus.jdbc.shaded.com.google.cloud.spanner.Key on L187, where the class of the values seem to be in different namespaces.
If I change the sql statement to be a SELECT or an UPDATE the operation will be executed as expected. Is this a bug or a user error? Thanks for your help!

Confirmed as bug, I'll look into it.

Fixed in version 1.0.1 and further.


Make turn on sync wording consistent

The wording of this:

Should match:

Or alternatively just say "Preferences Sync"

Also I think we should change this to simply "Turn On":

This is just the preview warning though.


fix status updates on dims changes

Description
This PR fixes #286 by causing the status message to update when the dims slider changes. It does this for the Image, Labels, and Markers layers. The Shapes and Vectors layers do not currently support > 2D so it is not needed there yet, but will be implemented when needed.
Type of change

[x] Bug-fix (non-breaking change which fixes an issue)

How has this been tested?

[x] run examples/nD_image.py and examples/nD_markers.py

Final checklist:

[x] My PR is the minimum possible work for the desired functionality
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] I have added tests that prove my fix is effective or that my feature works

There was an issue with multichannel data that was causing an error on mouse move on master, but with this PR because an error on launch of set_themes.py because it uses an rgb image, that has now been fixed.

it's failing here. my first guess would be that it probably incurred circular callbacks

@kne42 this PR is passing now, I think we've got wires crossed on our two PRs


Add the average line for a bar race chart.

Add the average line for a bar race chart.

@alex-macedo , this would be an interesting addition to this chart type. This is currently not supported but I keep this open as a to do list.
Thanks for your suggestion.


A.2, A.3...

This issue has been extracted from the issue list on:https://ies-svn.jrc.ec.europa.eu/issues/2685
Comment
Use 'ISO' for ISO standards, not 'iso'.
Proposed Change
Change.

Proposed resolution:

Implement proposed change.


Uniqueness types in ISLE

Feature
When working on lowerings in ISLE, it's convenient to rely on implicit conversions to de-clutter the implementation. However this can hide bugs, as in the following example:

(decl x64_palignr (Xmm XmmMem u8 OperandSize) Xmm)

(convert Value Xmm put_in_xmm)
(convert Value XmmMem put_in_xmm_mem)

(decl swiden_high (Value) Inst)
(extractor
    (swiden_high x)
    (inst_data (InstructionData.Unary (Opcode.SwidenHigh) x))
)

(rule (lower (has_type $I16X8 (swiden_high val @ (value_type $I8X16))))
      (x64_pmovsxbw (x64_palignr val val 8 (OperandSize.Size32))))

In this example, val has type Value, but is used with x64_palignr at two different types: Xmm and XmmMem. Defined elsewhere are two conversions, one from Value -> Xmm and one from Value -> XmmMem that will potentially sink a load into this use if the Value is only used once at the clif level. Because the swiden_high instruction has only one argument, using it twice in its lowering could produce a bug where val is sunk into the XmmMem arg and also used as the Xmm argument, yielding a panic during register allocation.
One approach to solving this problem would be to not permit a Value to be converted into an Xmm or XmmMem more than one time. This could be accomplished by adding an annotation to arguments to ISLE declarations, indicating which arguments must be used uniquely. The clean language uses ! for this, so you could imagine the signature of the swiden_high extractor changing to the following to indicate that Value may only be used once:
(decl swiden_high (!Value) Inst)
(extractor
    (swiden_high x)
    (inst_data (InstructionData.Unary (Opcode.SwidenHigh) x))
)

Another approach would be to allow functions to be marked as explicitly consuming their inputs from the typing environment, using an annotation like in the Mezzo language. In this case we would want to mark both put_in_xmm and put_in_xmm_mem as consuming their arguments, so let's use @ as a straw-man sigil:
(decl put_in_xmm (@Value) Xmm)
(decl put_in_xmm_mem (@Value) XmmMem)

We would get two benefits from this approach: we could call other functions on val before it was used with either of the functions that convert it to an Xmm or XmmReg, and it would be an error to try to call both of those functions on the same value. The initial example of (x64_palignr val val ...) would become a type error, as the two uses of val would lead to independent applications of put_in_xmm and put_in_xmm_mem, both of which consume their arguments.
Benefit
Adding some form of uniqueness typing to ISLE would help us to avoid bugs where the api has a notion of uniqueness that right now must be preserved manually. In the case of the example above, this would help us to enforce that sinking a load into another instruction does not lead to situations where the result of that original load is also expected to be in a register.
Alternatives
We can add assertions to require that we respect the invariants of the underlying apis that the ISLE code interacts with, or refactor those underlying apis to track sinkable loads on the vcode instead of the clif.

I think having implicit conversions for anything that has side effects is probably not the right call, so I think actually just removing the Value to Reg etc conversions would be sufficient, and also a whole lot easier.

That's a good point. The only downside that I can see there is that we'd need to be really careful that we were always introducing the RegMem variants when it makes sense, but that seems pretty manageable.

@elliottt and I talked about this a bit, and I definitely agree that this is sufficient; the main downside though is that we're getting away from the very clean (rule (lower (iadd a b)) (x64_add a b))-style rules we had. Perhaps less magic is warranted here, indeed. I wonder if removing the sink_inst implicit converter (so the implicit conversions for memory operands) is enough, while leaving Value->Reg intact. (I can convince myself if I squint right that "get the register for a value" is an idempotent operation, which we allow for implicit conversions, while "sink the load" is an operation that includes the side-effect of disallowing one to use the original result register, so should not be an implicit conversion.)
All of that said, there is still a safety issue here where it is possible to write a rule that does both, while affine types allow us to encode the restriction directly. I like that as an aspirational goal, but maybe we don't have to get there in one step.


Package: klaus + dependencies

This is WIP!
This PR adds klaus, the git viewer that just works, plus its dependencies.
While the package is already building, I cannot start it by now, as there are runtime errors. So please do not merge yet!

Can someone please have a look?
@jagajaga maybe you?
The point is: With buildInputs as dependency list, this results in a runtime error. With propagatedBuildInputs though, it works. I know that propagatedBuildInputs shouldn't be used here, am I right?
So... how to tackle this?

cc @domenkozar

I will squash asap you tell me that everything is fine! :-)

If you have successfully tested it then squash and I'll merge.

@jagajaga here we go.


Make glyphSet param consistently optional for pens

The following pens have glyphSet as a required param to their constructor:

ControlBoundsPen, BoundsPen
CocoaPen
PointInsidePen
QtPen
ReportLabPen
SVGPathPen
T2CharStringPen
TTGlyphPen
WxPen

All other pens make it optional (defaulting to None):

AreaPen
FilterPen, ContourFilterPen, ReverseContourPen
MomentsPen
PerimeterPen
PointToSegmentPen, SegmentToPointPen, GuessSmoothPointPen,
ReverseContourPointPen
RecordingPen, DecomposingRecordingPen
StatisticsPen
TeePen
TransformPen

Of the above pens that require glyphSet (to be passed into the parent constructor for DecomposingPen--a superclass of BasePen), only TTGlyphPen actually uses self.glyphSet and addComponent (a method added by DecomposingPen). Several pens override addComponent or call it on pens they own (such as TeePen, which calls it on all of its subpens).
The fact that so many pens (which on the surface seem like they may need to support addComponent--like AreaPen, StatisticsPen, etc.) make glyphSet optional indicates that it should be safe to make it more uniformly optional. This way, it isn't so cumbersome to construct an SVGPathPen, for example.
Note that PointInsidePen cannot have glyphSet made optional, because it is followed by a required param:
def __init__(self, glyphSet, testPoint, evenOdd=False):

Reordering the params to accommodate would be a breaking change.

I will review this later, but here's a historical note:
Originally all pens (derived from BasePen) required the glyphSet argument (which is often just passed to BasePen, which deals with components in a default way), and it's mostly later pens that aren't consistent with the original idea, which was: make it explicit you don't need support for composite glyphs by passing None as the glyphSet argument.
That said, I'm not against making it more consistently optional now, and I've often considered doing it as it is indeed more convenient in some cases.

I don't know if it's a good idea.. Letting glyphSet be None by default means that, e.g. in ControlBoundsPen if there's a composite glyph, the addComponent method of DecomposingPen will be called with a None glyphSet, which means TypeError exception.
If caller is sure there are no composite glyphs, then one can pass None in the constructor, thus the responsibility is on the user.

Of the above pens that require glyphSet... only TTGlyphPen actually uses self.glyphSet and addComponent

that's not true. All the subclasses of BasePen that you listed, and that require glyphSet argument in their constructor, may need to call addComponent if they are used to draw a composite glyph.
And to be able to draw a composite glyph, you need a non-None glyphSet. That's why it is required for those.

If we want to relax this requirement and allow BasePen subclasses to skip over composite glyphs (instead of letting a TypeError exception propagate as this PR does), then we may change the BasePen constructor like this:
$ git diff
diff --git a/Lib/fontTools/pens/basePen.py b/Lib/fontTools/pens/basePen.py
index e0d3ae06..10415e2c 100644
--- a/Lib/fontTools/pens/basePen.py
+++ b/Lib/fontTools/pens/basePen.py
@@ -194,7 +194,7 @@ class BasePen(DecomposingPen):
        """

        def __init__(self, glyphSet=None):
-               super(BasePen, self).__init__(glyphSet)
+               super(BasePen, self).__init__(glyphSet if glyphSet is not None else {})
                self.__currentPoint = None

        # must override

Thene DecomposingPen by default will skip over missing components and only issue a logging warning (unless the pen's skipMissingComponents attribute is set to False, in which case KeyError exception is raised on missing components).

If we make the glyphSet argument optional (I don't care much either way), I do want to always get an exception when a component is being drawn, not just a logging warning. A KeyError may be confusing, as it suggests there is a glyph set, that just happens to not contain the requested glyph.

that's why I prefer not making it optional, if it the default value can produce an error. If the client knows what they are doing, they can set it to None (meaning "I don't have or need to resolve component references in this case") or to an empty dict (meaning "I don't have a glyphSet at hand, even if there are components but I don't really care if they draw empty so just skip them"); or the client can set skipMissingComponents attribute to False (like the RecordingPen does) if they do have a glyphSet available but some component may actually be missing from it.
If this is not clear, the docstrings could be changed to make this clearer.

Oh! I fundamentally misunderstood what composite glyph meant (the doc strings for DecomposingPen.addComponent led me to believe that it was doing something different--BasePen.addComponent is more clear). Apologies.
If it is the case that you do need the glyphset to render a glyph (because it is possible a glyph contains components--is this the proper terminology?), then I'd agree with @anthrotype that making it optional seems like the wrong move.
If I may, I think giving the Pen a glyphset might be going about this wrong. Pens shouldn't need to be concerned with internals of a glyphs they've been given.
Say we made glyphSet a required constructor param for all pens. Then you could do something like this:
comic_sans = TTFont('Comic Sans.ttf')
wingdings = TTFont('Wingdings.ttf')

p = SomePen(wingdings.getGlyphSet())
p.draw(comic_sans.getGlyphSet()['a'])

Here, the developer building the pen needs to remember where the glyph they're about to draw came from. If they forget or mess up, you end up with something nonsensical like this. And if the a glyph from Comic Sans had components, this would potentially KeyError because Wingdings might not have those component glyphs.
It seems like the better solution is to have a glyph know which glyphset it came from. Then a situation like this can never arise.
This is a bit more substantial of a rework, but I think the design is more sound. It eliminates the case of None/{} being ambiguous about whether a glyphset exists. glyph.glyphSet is None implies a glyph didn't come directly from a font. If it's possible to add glyphs to a font, you just need to set this when adding.
In effect, this solution is what the API currently requires of consumers (keeping the glyphset and glyph together if you ever want to do anything with pens). Since it's possible to get wrong, why not do it correctly once in the API so usage can look like:
p = SomePen()
p.draw(glyph)

Pens shouldn't need to be concerned with internals of a glyphs they've been given.

which is why Glyph objects have a draw method that takes a Pen, and not viceversa. Only the glyph knows its internals, and only calls method from the public interface of a Pen. The glyph draws itself using the given pen.
But the pen may need to know where to search components, hence the need to pass in a glyphSet.
I like to keep the Glyph and the glyphSet (i.e. Dict[str, Glyph]) separate to prevent the circularity of the references between the container and the contained.

Everything @anthrotype said. It was to keep the requirements for glyph objects to a minimum, and at the same time give pens the options to either retain component information or expand into outlines.
This design is close to 20 years old and has proven to be very useful for people. Sure, alternate designs are possible, but I really don't think it makes sense to change it now.
Let's leave it as it is, and live with the fact that there are some pens in our code base that do treat the glyphSet constructor argument as optional. As I said earlier, those are the ones that aren't consistent...

Oops, realized I flipped the order in my example. It should've been glyph.draw(pen).
Sure, but doesn't passing the glyphset to the pen make the pen need to know specifics about the glyph (in particular, from which glyphset it came)?
I partially understand the aversion to cyclic references, but shouldn't it be weighed with ease of use of the API? The current way feels rather cumbersome to me:
pen = SomePen(font.getGlyphSet())
font.getGlyphSet()['a'].draw(pen)

Versus what adding the cyclic reference would allow:
pen = SomePen()
glyph.draw(pen)

Additionally, is passing the wrong glyphset not a concern?
As an API consumer, within my code I can't just pass around glyph objects. I need to pass around glyphs with their glyphsets if I ever want to be able to use pens. FWIW, I've wrapped the different font types in a wrapper class for a current project I'm working on. I also have a glyph wrapper. And it currently does this tying the knot thing (technically not really cyclic--but it's the spirit) so that you can indeed just pass my glyphs around:
class Font:
    def get_glyph(name: str) -> Glyph:
        return Glyph(self._font.getGlyphSet()[name], self)

class Glyph:
    def __init__(self, glyph: FontToolsGlyph, font: Font) -> None:
        self._glyph = glyph
        self._font = font

    @property
    def svg_path(self) -> str:
        pen = SVGPathPen(self._font._font.getGlyphSet())
        self._glyph.draw(pen)

        return pen.getCommands()

In effect, I see not doing this at the fontTools level just kicking the can down the road. At some point an API consumer will need to do this. So the net effect of this can kicking is the API is harder to use (and learn--I didn't understand components until now, and I don't think I should've needed to understand that to use a pen) and more error prone.

Versus what adding the cyclic reference would allow:
pen = SomePen()
glyph.draw(pen)

What exactly does this allow?
It would make the glyph.draw() method responsible for either calling pen.addComponent() or expanding its components. Right now, this is a decision made by the pen object.

Additionally, is passing the wrong glyphset not a concern?

I have not heard of a single case where this caused problems.

glyph.draw() is indeed supposed to call pen.addComponent(). For the pen to be able to decide what to do next (expand the component to an outline or not) it's pen.addComponent() that needs to use the glyph set.
Cyclic references have been accidentally added to the code base by people who didn't realize that having no cyclic references was a design goal. There are more examples like the one you mention. It's not a problem these days, but when fonttools was designed, it was still a concern.
Still, to require a glyph to have a reference to its owning glyphset is a burden on the API, too. Right now, a glyphset needs to be dict-like, which needs to support __getitem__, and the returned glyph object should have a draw() method that takes a pen as its single argument. So, while it may be a little odd that a pen needs a glyph set reference, it does allow for a lot of simplicity on the glyph side.
fonttools by no means offers a perfect API:

The issue is that API allows this mistake.

Oh dear, you are in for a world of pain using fonttools... There are way worse things that can happen, and there are many more examples of (pieces of) API that could be better or cleaner in this respect. It's a low level toolbox.
For higher level stuff, you don't want to use (eg.) TTGlyph objects, but your own objects, that are most suitable for the tasks you need to do. For example, the defcon and fontParts libraries offer glyph objects that do have back references to their glyph sets. That is totally understandable at that level. But fonttools is designed to make little assumptions about its host app, and there's a lot of duck typing going on. The pen protocol is one example of this. It's relatively light-weight, which makes it easy to integrate with other code. Sure, you need to remember to pass a (correct) glyphset object to certain pens, but I stand by this tradeoff, that asks very little of glyphset and glyph objects.

fonttools by no means offers a perfect API

Fair enough. My aim was to improve the API, but that's obviously in conflict with the current design standards.
Thanks for indulging me! I appreciate the references too. I'll check out defcon and fontParts. I may not need to be working at this low of a level indeed.

My aim was to improve the API

There's a lot of code out there that depends on how these things work. Changes that don't offer 100% API compatibility are usually problematic. We necessarily have to be very conservative in these areas.

I wanted to change this for a while... Easiest would be to pass glyphSet to the addComponent() call directly.  Not sure how to roll that out with backwards compatibility though.


Forcing cursor at next available slot

Is there a way to for the cursor to be at next available slot?
example:
mask: ['(', /[1-9]/, /\d/, /\d/, ')', ' ', /\d/, /\d/, /\d/, '-', /\d/, /\d/, /\d/, /\d/]
value: '15'
so it shows: (15 )    -     for now
If I focus the input, I'd like to have an option to get the cursor forced at next position (3rd slot), because that's how an <input type="text"> would behave, when you are typing a phone number, you don't really want to type the end first then point back at the start
When using '\u2000' or any other empty char as placeholder, it becomes even more needed

We're having the same issue. It causes weird UX issues where users can't type their whole phone number.
It's fixed by turning off guide, but then you can't backspace through special characters, which is more important.

@Directive({
selector: '[phone]'
})
export class PhoneMaskCursorProcessorDirective {
@HostListener('click', ['$event'])
keypress(event: MouseEvent) {
let input = ( event.target);
input.focus();
if (input.selectionEnd <= 2) {
input.setSelectionRange(2, 2);
} else {
let valueSelected = input.value.substring(0, input.selectionEnd);
let match = valueSelected.match(/\d/gi);
let lastDigitIndexInSelection = valueSelected.lastIndexOf(match[match.length - 1]) + 1;
if (input.value.substring(lastDigitIndexInSelection, lastDigitIndexInSelection + 1).match(/[-\s]/)) {
lastDigitIndexInSelection++;
}
input.setSelectionRange(lastDigitIndexInSelection, lastDigitIndexInSelection);
}
}
}

A simple workaround would be to execute the following code whenever you want to set the cursor to the end of the user input:
function selectAfterUserInput() {
  let placeholder = '_';
  let i = input.value.indexOf(placeholder)
  if (i === -1) { i = input.value.length; }
  setTimeout(function() { input.setSelectionRange(i, i); }, 0);
}

Works in Chrome, Firefox, Safari. Haven't tested IE


Fix #5

fix #5
In SceneLoader to change_scene, change_scene_to_loading_screen and
change_scene_to_resource to not play the open transition
Rename _wait_after_load in _force_wait_after_load it is more
comprehensive

everytinhg okay I would just change desretion of changes as it is hard to read.
Please use `` for classes, vars, methods, etc.

Rename _wait_after_load in _force_wait_after_load it is more
comprehensiveshould be: Rename_wait_after_load()to_force_wait_after_load()` as it is more
comprehensive


ML Extension v2.0.3 - Unable to authenticate: 'AccountKeyCredentials'` object has no attribute 'key'

Extension name (the extension in question)
ml, version 2.0.3
Description of issue (in as much detail as possible)
Attempting to download a pipeline run's artifacts fails and raises an exception:
'AccountKeyCredentials'` object has no attribute 'key'

Example command:
az ml job download -n <RUN_ID> -g <RG> -w <WORKSPACE_NAME> --include-children false

In this instance, the Azure CLI is authenticated via a service principal.
Version 2.0.2 does not raise an exception and completes successfully.

route to service team

@MickayG This should be fixed in a re-release of that version. Please run
az extension remove -n ml
az extension add -n ml

to get the update version and try the job download again.

@yonzhan please close


"1. Invalid data type for [parameter_name]" with typespec boolean().

In the create view http://localhost:8001/admin/model/create/example, are there values the form which would be accepted as the boolean atoms?
The error message doesn't give the user enough information to resolve this on their own.
src/model/example.erl:
-module(example, [Id, Name, Description, Notes, Enabled::boolean()]).
-compile(export_all).

Same error appears for datetime() fields both update/create actions


Make autocomplete auto-learn unknown suggestions that are applied

The keyboard should automatically learn unknown suggestions that are applied by the user, since that indicates that the user wants to use them from now on.
The standard keyboard action handler should therefore automatically call the autocomplete provider's learn function whenever an unknown suggestion is triggered.
This will hopefully improve the typing experience over time, since the system should learn more words as the user keeps applying them.

This has been added to the v8.7 branch.


Integration that called async_setup_platforms instead of awaiting async_forward_entry_setups; this will fail in version 2023.3

Restarting my HA installation today threw this error and said to report it:
Logger: homeassistant.helpers.frame
Source: helpers/frame.py:77
First occurred: 12:26:14 PM (1 occurrences)
Last logged: 12:26:14 PM

Detected integration that called async_setup_platforms instead of awaiting async_forward_entry_setups; this will fail in version 2023.3. Please report issue to the custom integration author for weatherflow using this method at custom_components/weatherflow/__init__.py, line 167: hass.config_entries.async_setup_platforms(entry, WEATHERFLOW_PLATFORMS)

Mine too!

Closed with release 1.0.11