Compaction of a heavily updated view - file descriptor leak (known as ".deleted" issue)

Race condition can cause that compaction of heavily update view leads to file descriptor leak. The leaked descriptor is shown as deleted file, which still consumes the space on the storage device.
It is very hard to reproduce, currently I am unable to make easy example which would reproduce the issue. But the bug is there, i was able to record in on a video (twice in row)
https://youtu.be/dQb7Fm3gAUQ
Please fix it as soon as possible, because it is real problem. I also found, that this problem was reported in earlier versions
https://issues.apache.org/jira/browse/COUCHDB-1652 (version 1.2)
The bug can be reproduced on the version 1.7.1. The recorded version is 1.6.0
Expected Behavior
No files should left open
Current Behavior
Deleted files left open after compaction
Possible Solution
Steps to Reproduce (for bugs)
It is hard to reproduce. The view is heavily updated. The bug is not triggered always. It seems that
it happens during "Restarting" phase.
[Sun, 19 Nov 2017 20:54:14 GMT] [info] [<0.4067.0>] Compaction restarting for db: btcusd-orders idx: _design/index
[Sun, 19 Nov 2017 20:54:14 GMT] [info] [<0.4067.0>] Compaction started for db: btcusd-orders idx: _design/index
[Sun, 19 Nov 2017 20:54:14 GMT] [info] [<0.4067.0>] Compaction finished for db: btcusd-orders idx: _design/index

The bug is only the view related, not database related
I am going to continue in investigation. Please do not wait, and start to locate bug using currently known information.
Context
Your Environment
Recorded on 1.6.0
Ubuntu 16.04
Thank You!

UPDATE: Steps to reproduce

Create blank database ("testleak" in my example)
Create simple view ("_design/test/_view/test" in my example)

in first terminal

Create some dummy documents
$ curl -H "Content-Type:application/json" --data-binary "{}" http://localhost:5984/testleak
Update view and ask for changes using the the same connection
$ curl http://localhost:5984/testleak/_design/test/_view/test "http://localhost:5984/testleak/_changes?since=now&heartbeat=true&feed=continuous"

In other terminal

become root
pidof beam.smp (2200 in my case)
cd /proc/2200/fd
ls -la | grep -iE "(delete|mrview)"

you will see just only opened mrviews
lrwx------ 1 couchdb couchdb 64 lis 21 12:49 28 -> /var/lib/couchdb/.testleak_design/mrview/62e2ed5df6a6694c0438c7724137ca0c.view

compact the view _design/test

repeat step 8

lrwx------ 1 couchdb couchdb 64 lis 21 12:49 28 -> /var/lib/couchdb/.testleak_design/mrview/62e2ed5df6a6694c0438c7724137ca0c.view
lrwx------ 1 couchdb couchdb 64 lis 21 12:48 55 -> /var/lib/couchdb/.delete/bd46813bf2ecea0dad0c41dbbc89cb83 (deleted)

The deleted file stays there until the connection is closed (press control-c in the first terminal). If you want to see multiple deleted files, you will need to create script, which uses single connection to repeatedly update the view. Each compaction generates new deleted file. These files are persists, until  the connection is disconnected.
Sometimes it could be very difficult to disconnect some connections, for example if the connection is used to receive changes.
Version 1.7.1

Having a similar issue on CouchDB-1.6.x
Here are some additional debugging info, if that could help:
lsof in my case show leak on file descriptor #23.
beam.smp 2471 root   23u      REG    253,0     2355299   95256735 /ghostcache/edgedata/data/.delete/0d697973b6cd6b71c0d726878c1ffaed (deleted)
Here is a backtrace reported by process_info on erlang PID that holds that descriptor:
[{current_function,{gen_server,loop,6}},
 {initial_call,{proc_lib,init_p,5}},
 {status,waiting},
 {message_queue_len,0},
 {messages,[]},
 {links,[#Port<1941.3912>,<1941.244.0>]},
 {dictionary,[{'$ancestors',[<1941.241.0>]},
              {'$initial_call',{couch_file,init,1}}]},
 {trap_exit,true},
 {error_handler,error_handler},
 {priority,normal},
 {group_leader,<1941.111.0>},
 {total_heap_size,1597},
 {heap_size,987},
 {stack_size,9},
 {reductions,1749931},
 {garbage_collection,[{min_bin_vheap_size,46368},
                      {min_heap_size,233},
                      {fullsweep_after,65535},
                      {minor_gcs,987}]},
 {suspending,[]}]

 {<1941.242.0>,^M
  {backtrace,<<"Program counter: 0x00007f5924aeed40 (gen_server:loop/6 + 264)\nCP: 0x0000000000000000 (invalid)\narity = 0\n\n0x00007f592b3e5fe0 Return addr 0x00007f5924ae72b0 (proc_lib:init_p_do_apply/3 + 56)\ny(0)     []\ny(1)     infinity\ny(2)     couch_file\ny(3)     {file,{file_descriptor,prim_file,{#Port<0.3912>,23}},true,2445427,<0.244.0>}\ny(4)     <0.242.0>\ny(5)     <0.241.0>\n\n0x00007f592b3e6018 Return addr 0x00000000008a6278 (<terminate process normally>)\ny(0)     Catch 0x00007f5924ae72d0 (proc_lib:init_p_do_apply/3 + 88)\n">>}},^M

And here is a backtrace reported by process info of linked process{links,[#Port<1941.3912>,<1941.244.0>]}
{backtrace,<<"Program counter: 0x00000000008a6270 (unknown function)\nCP: 0x00000000008a6278 (<terminate process normally>)\narity = 3\n   proc_lib\n   wake_up\n   [gen_server,wake_hib,[<0.241.0>,<0.244.0>,{db,<0.244.0>,nil,<<16 bytes>>,<0.3382.2688>,#Ref<0.0.3410.8669>,{db_header,6,15,0,{125165,{6,0,115324},2264},{116902,6,1558},{140103,[],5187},0,nil,nil,1000},15,{btree,<0.3382.2688>,{125165,{6,0,115324},2264},#Fun<couch_db_updater.btree_by_id_split.1>,#Fun<couch_db_updater.btree_by_id_join.2>,undefined,#Fun<couch_db_updater.btree_by_id_reduce.2>,snappy},{btree,<0.3382.2688>,{116902,6,1558},#Fun<couch_db_updater.btree_by_seq_split.1>,#Fun<couch_db_updater.btree_by_seq_join.2>,undefined,#Fun<couch_db_updater.btree_by_seq_reduce.2>,snappy},{btree,<0.3382.2688>,{140103,[],5187},undefined,undefined,undefined,nil,snappy},15,<<3 bytes>>,\"/ghostcache/edgedata/data/dbs.couch\",[],[],nil,{user_ctx,null,[<<6 bytes>>],undefined,write},nil,nil,1000,[before_header,after_header,on_file_open],[sys_db,{user_ctx,{user_ctx,null,[<<6 bytes>>],undefined,write}}],snappy,nil,nil},couch_db_updater,[]]]\n">>}
ok

In that particular case it's related to dbs.couch.
I've seen similar issues related to nodes.couch  as well as data and view files.

Is anyone seeing this in 2.x?
1.x is on sustaining support at this point - we will only release a new 1.x build if there is a security patch necessary.
Once 3.0 comes out, support for 1.x will terminate.

I tried to reproduce the issue on 2.1.1.
I have to run compaction directly on port 5986 - on appropriate shard. The deleted file appears as leaked, however it is cleaned after a short period of time (without reporting anything to the log file).
It seems that somebody have already fixed this in the newest version. It probably performs some cleanup periodically (aprox each minute)
Before you close the issue please verify my observation.

I'll leave this open as a 1.x issue in the eventuality someone wants to contribute a patch. Once 3.x releases I will mass-close all 1.x issues.


5999 gas limit api

PR Description
Adds Gas Limit endpoints to validator API
Fixed Issue(s)

https://github.com/ConsenSys/teku/issues/5999
Documentation
- [ ] I thought about documentation and added the doc-change-required label to this PR if updates are required.
Changelog

[ ] I thought about adding a changelog entry, and added one if I deemed necessary.

#5999

Here it is https://github.com/ConsenSys/teku/pull/6068

There's too much in this PR, i think it should probably be broken down...

There's too much in this PR, i think it should probably be broken down...

we can split out moving the pubkey definition to a nice easy PR
can split out defining the change to the data structure without any apis, and tests for that

I think then it becomes pretty simple, but there may be other things that make sense as a small easy to review PR...

I ended up splitting it into 4 Prs:

Adding the gas limit to the runtime config: https://github.com/ConsenSys/teku/pull/6068
Adding the gas limit to the beacon proposer preparer: https://github.com/ConsenSys/teku/pull/6080
Extracting the Rest API common constants: https://github.com/ConsenSys/teku/pull/6081
The Gas Limit APIs: https://github.com/ConsenSys/teku/pull/6057

They must be reviewed in the mentioned order since each PR is rebased on the previous one


Cluster not found error

I see a "Cluster not found" error when viewing workloads or sources locally

and in staging

As discussed with @joshri , it must be a new issue. At least I have not found an existing issue for this yet. @joshri has a hypothesis that

maybe it's expecting management to be the name and you don't have a cluster with that name.

Locally, I created two Kind clusters names wego-dev (the active one) and wge-dev.

I see the same in our deployment. Values for helm:
    envVars:
      - name: WEAVE_GITOPS_FEATURE_OIDC_BUTTON_LABEL
        value: "Login with AzureAD"
      - name: WEAVE_GITOPS_FEATURE_TENANCY
        value: "true"
      - name: WEAVE_GITOPS_FEATURE_CLUSTER
        value: "false"
    additionalArgs:
      - --auth-methods=oidc

Errors from pod when we are browsing:
2023-09-19T11:37:10.144Z	INFO	gitops	middleware/middleware.go:65	server error	{"uri": "/v1/object/rester-helm-dev?namespace=rester-helm-dev&kind=GitRepository", "status": 500}
2023-09-19T11:37:10.155Z	ERROR	gitops	middleware/middleware.go:39	server error	{"error": "cluster= not found"}
2023-09-19T11:37:10.155Z	INFO	gitops	middleware/middleware.go:65	server error	{"uri": "/v1/object/flux-system?namespace=flux-system&kind=GitRepository", "status": 500}
2023-09-19T11:37:10.160Z	ERROR	gitops	middleware/middleware.go:39	server error	{"error": "cluster= not found"}
2023-09-19T11:37:10.160Z	INFO	gitops	middleware/middleware.go:65	server error	{"uri": "/v1/object/rester-plain-dev?namespace=rester-plain-dev&kind=GitRepository", "status": 500}
2023-09-19T11:37:10.162Z	ERROR	gitops	middleware/middleware.go:39	server error	{"error": "cluster= not found"}
2023-09-19T11:37:10.162Z	INFO	gitops	middleware/middleware.go:65	server error	{"uri": "/v1/object/rester-kustomize-dev?namespace=rester-kustomize-dev&kind=GitRepository", "status": 500}
2023-09-19T11:37:10.164Z	ERROR	gitops	middleware/middleware.go:39	server error	{"error": "cluster= not found"}
2023-09-19T11:37:10.164Z	INFO	gitops	middleware/middleware.go:65	server error	{"uri": "/v1/object/rester-kustomize-test?namespace=rester-kustomize-test&kind=GitRepository", "status": 500}
2023-09-19T11:37:10.164Z	ERROR	gitops	middleware/middleware.go:39	server error	{"error": "cluster= not found"}
2023-09-19T11:37:10.164Z	INFO	gitops	middleware/middleware.go:65	server error	{"uri": "/v1/object/rester-helm-test?namespace=rester-helm-test&kind=GitRepository", "status": 500}

@Cajga thank you for confirming the issue and providing additional info!

It is possible it is not a UI issue, I just came across it while testing another UI issue.


SQL over CSV with tests and docs

Added support for SELECT, UPDATE, DELETE over CSV data sources in csvSQL template function.
Intention is to allow users to simulate a persistent CRUD datastore in a straightforward manner.
This in addition to template function earlier for simpler datasource manipulation.
Have included tests and documentation.
I am not sure how the documentation will render once compiled.

Cool. This is nice 👍


Don't always enable Wi-Fi after jb

I have read comments in twitter, mentioning that Wi-Fi enables shortly after jailbreak completes.
This seems to be the desired choice when Wi-Fi is already enabled before jailbreaking. However, if someone chooses to have Wi-Fi disabled, then Dopanine enables it for him too.
I guess you need to add something like this after jailbreaking:
If (Wi-Fi was enabled)
Re-enable it
And don't enable it in all cases.

Dopamine already has this logic, since 1.0.

I had it like this before, the problem with this was, the exploit is unreliable so it would disable wifi on the first run, kernel panic and then not reenable it on a latter try when the jailbreak actually worked. So to compat that I made it always turn on Wifi after jailbreaking.


Update NP_NAT defenition to fix TypeError bug

Solution for https://github.com/quantopian/trading_calendars/issues/224

This repo is no longer maintained. Please use
https://github.com/gerrymanoim/exchange_calendars  or
https://github.com/rsheftel/pandas_market_calendars


refactor: rewrite or something

TODO:

[ ] Testing. This needs clarity on how the tournament is gonna be set up regarding teams and all that.
[ ] Clarification why getTournament and getAll are unused.

About the thing of getAll and getTournament unused, I used get All to get the I'd of the one tournament I needed and the other was there to see how shitty and complicated the the parameters in the api way


bug : set pointer byte

I'll fix Selene in a bit, but make sure you run StyLua and update code in both the Roblox and Vanilla files.


[FEAT]: Knowledge Graphs Support with Anything-LLM

What would you like to see?
I would like to see the support for adding Knowledge Graph with RAG .
something similar to this .

Being experimented in a branch called knowledge-graph-support and it works on topic expansion and helps make answers more reliable, but I'm not sure how reliable this is when you start to use OSS LLMs

That is great , I will be looking forward to try it when this gets merged to the main branch.

Also can we integrate this with neo4j .

The graph in that branch runs totally locally at this time. I decided to stay away from neo4J since it doesn't run locally and I didn't want to force users to sub or set up neo4j locally since that can be quite complex.
I understand neo4j comes with a lot of convenience though like the UI and graph browser.

First of all, thanks for the contribution to the knowledge graph attempt, we have an internal project which might rely on AnythingLLM for document understanding, we would like to try knowledge graph for improve the correctness of the queries, is there any documentation or guideline which can guide us to setup the knowledge graph branch locally? Thank you very much. :D

@timothycarambat we should integrate https://github.com/microsoft/graphrag.git to this and see the results for the same.

I am interested in GraphRAG support as well. The last commit to the knowledge-graph-support commit was 6 months ago, but this thread was last updated 6 weeks ago. Is this feature still being developed?

+1 for Knowledge Graph / GraphRAG support


Maintain aspect ratio of non-square avatar uploads

Gitea version (or commit ref): 1.1.0
Git version: irrelevant
Operating system: irrelevant
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[ ] SQLite

Can you reproduce the bug at https://try.gitea.io:

[ ] Yes (provide example URL)
[ ] No
[x] Not relevant

Log gist:

Description
When uploading a non-square image as an avatar, it gets resized to a square image. This results in distorted avatars. In my opinion, It would be reasonable to crop the image and maintaining the original aspect ratio.
https://github.com/go-gitea/gitea/blob/master/models/user.go#L431
Unfortunately, the used library for image resizing (https://github.com/nfnt/resize) does not seem to support cropping.

Gogs issue: https://github.com/gogits/gogs/issues/4132

I would pad, rather than crop, the uploaded image.

https://github.com/oliamb/cutter

I think that this could be done on the front-end before it is uploaded (similar to GH)  using something like this

Automatic closing of Issues make no sense.
Please give a status about this Issue? Is it fixed? Will it be fixed?

Sorry, It is fixed by #7025


Selected robot plugin is not always grayed out in robots menu

Describe the bug
When using the lab, one selects a robot plugin from the start carousel. The corresponding entry in the robots menu (2nd from top left) should be grayed out, so as to notify the user which robot is currently being used (there are quite a lot of robot plugins now! :smiley: ).
This is not always the case. On first selecting the robot from the start carousel, the entry in the robots menu is grayed out as expected. However, upon switching over to the Configuration tab and checking the robots menu again, one sees that the entry for the selected robot plugin is not grayed out anymore. Switching over to the Program tab again has the same effect, the selected robot plugin is not grayed out.
To Reproduce
Steps to reproduce the behavior:

Go to lab.open-roberta.org.
Select any robot plugin, for instance, Open Roberta xNN.
Click on robots menu, 2nd from top left.
See the grayed out text of your selected robot plugin, this is the expected behaviour.
Click on Configuration tab, then click on robots menu, 2nd from top left.
See the lack of grayed out text in the list.
Click on Program tab, then click on robots menu, 2nd from top left.
See the lack of grayed out text in the list.

Expected behavior
The selected robot plugin should be grayed out in the robots menu, irrespective of the tab being used.
Screenshots
The selected robot plugin in this example is Open Roberta xNN.

Upon selecting the robot from the start carousel:

Upon switching over to the Configuration tab:

Device information

Type: Desktop
OS: Ubuntu 20.04
Browser: Firefox v115.0

Solved by the new start page


[nativescript-downloader] Could not find androidx.tonyodev.fetch2:xfetch2:3.1.6

Package fails to install with error message:
Build file '............../app/platforms/android/app/build.gradle' line: 575
A problem occurred configuring project ':app'.
Could not find androidx.tonyodev.fetch2:xfetch2:3.1.6.
Required by:
    project :app

"@nativescript/android": "~8.3.1",
"@nativescript/core": "~8.3.4",

Hi, did you solve the issue?

I found what my problem was.
I was using jcentral() but it's deprecated.
I changed it to mavenCentral() as suggested by many and then the error occours.
By putting jcentral() back into settings.gradle the error disappears. Yet it's not a fix.

The issue we are having: https://github.com/tonyofrancis/Fetch/issues/586

Are there any workarounds for this? @triniwiz

We've migrated to the following library https://github.com/VoiceThread/nativescript-plugins because we coudln't find any workarounds for this.
The above seems to be working fine so far.

Same issue, can't build my project right now


Add menyo_20k_mt dataset

Add menyo_20k_mt dataset

looks like your PR includes changes about many other files than the ones for menyo 20k mt
Can you create another branch and another PR please ?

Yes, I will


Add UUID for Xcode 7.3

Xcode 7.3 has been released today with a new UUID item.

:+1: Oh thx~

:+1:

+1

+1

For those who wants to use XVim on Xcode 7.3 without waiting for this PR:
https://github.com/inket/update_xcode_plugins

+1

Did anyone feel using XVim in Xcode 7.3 crashes a lot ? :cry:

@caoer #939 could be causing your crashes. It is for me, at least.

@joemasilotti yeah! it could be. sometimes it also crash when I press cmd+x.
some times, the editor won't show the correct content. then after around a few seconds. Xcode is going to CRASH..
crashes 20+ times each day... :cry:

Please post the crash log as an new Issue. I'll see it.

👍
Can this please be merged? Thank you! /cc @JugglerShu

Is this still needed ? Everything works fine for me.

I read this https://twitter.com/jugglershu/status/738352750069587968 is at it shouldn't be needed, however installing via Alcatraz it does not work for me.

installing via Alcatraz still does not work

Just clone the project and run make. Make sure that have xcode-select -p points to the correct version of Xcode first

+1


Docstrings on annotated definitions + on strings stolen by preceding top level macros

NOTE: This is absolutely horrendous! It is at least a solution to https://github.com/JuliaEditorSupport/zed-julia/issues/15#issue-2502596294 as promised, but I'm more than happy to leave this out for now and implement it in a cleaner way if/when we can get the grammar fixed.
The following cases were broken before, but are now highlighted correctly:

Essentially, the problem is that the docstrings are incorrectly parsed as arguments to the preceding macro. The workaround is querying for items which can have docstrings and are immediately following a macro call which has a string as its last argument, but not as its only argument. This very specific query avoids incorrectly highlighting strings in common macros like this:

Looks less horrendous than I'd expected 😃!

Heh :-) Yeah, its not really a complicated query, I might have exaggerated a little. It is just silly that this needs to be done like this in the first place. As far as ugly workarounds go, I suppose you can argue this is quite mild.
I went ahead and added some syntax test cases with some clarifying comments, in particular the cases where this workaround leads to incorrect highlighting. I think this should give a pretty good overview of the benefits and drawbacks of the workaround:

I could still go either way as to whether this is sensible to merge. I don't know off the top of my head any macros with more than one argument that use string literals as their last argument, which are also common to use at the top of a file, but they may very well exist.

I like your solution. It's definitely better than what we had before and it covers the common patterns. Docstrings are important and it's wrong to treat them as plain strings. We need these queries in injections.scm anyway so why not use them for highlighting as well. BTW, that was my thinking when I wrote this awful block to match short function definitions. I  had to do it for outline.scm (have you ever tried the outline modal?) and carried it over to highlights.scm.

The two test cases for begin and let blocks can be either removed or changed to "should not have MD injected." We ought to use @doc per the Julia manual. The queries are correct.

An idea for the two broken test cases at the end of docstrings.jl (from line 107 on): docstrings are usually triple-quoted and arguments are more often than not single-quoted. We improve our chances of being right with:

(source_file
  (string_literal) @comment.doc
  .
  [
    (identifier)
    (macrocall_expression)
    (open_tuple
      (identifier))
  ]
  (#match? @comment.doc "^\"\"\""))   ; ADDED

Not pretty I know… would need to be done in all of your four blocks (2 × module_definition and 2 × source_file) plus the same in injections.scm. What do you think?

have you ever tried the outline modal?

Didn't even know about it until now :v)

The two test cases for begin and let blocks can be either removed or changed to "should not have MD injected." We ought to use @doc per the Julia manual. The queries are correct.

 Somehow they made their way into Main, so I got them back when i merged the upstream changes. I will remove them.

An idea for the two broken test cases at the end of docstrings.jl (from line 107 on): docstrings are usually triple-quoted and arguments are more often than not single-quoted. We improve our chances of being right with: ...

That's clever! Pretty sure that should cover virtually all reasonable cases. As you say, it is not pretty, but it's not that gnarly so I reckon it's worth it.

Not pretty I know… would need to be done in all of your four blocks (2 × module_definition and 2 × source_file) plus the same in injections.scm. What do you think?

It should only be necessary in the queries for docstrings stolen by macros, so I added the match to the ones with macrocall_expressions only, that avoids breaking stuff like this:
"single-line docstring"
function foo end

Which i think is actually sometimes found in the wild.
However in testing this, I noticed that this doesn't currently work anyways, because the basic Markdown injection query is restricted to triple-quoted strings.

Removing the restriction of the basic markdown injection query to single-quoted strings doesn't seem to have led to any regressions in the test cases as far as I can tell. I thought that might lead to function calls and macro calls being broken again, but it looks like it's fine. Probably precedence I guess.

You made some good points! Let's think this over again. We know it's messy and impossible to do right because of the ambiguous syntax tree.
Looking at some real code from a user's view gives the impression that the highlighting is a bit unpredictable. We have so many exceptions now.
How about incorporating the Julia manual as closely as possible?

We dump the original query (note: I realized it's missing (global_statement)).
We only capture top level docstrings (the way you did in your first commit). Nested docstrings are supposed to use the @doc macro anyway.
We accept single- and triple-quoted docstrings. I assume restricting to triple-quoted strings in injections.scm was done to make nvim's offset predicate work.
Expressions may be prefixed with one ore more macro calls. That's very common.
We would only need three queries in highlights.scm (I mixed together what we had):

((macrocall_expression
  (macro_identifier "@" (identifier)) @function.macro
  (macro_argument_list
    .
    (string_literal) @comment.doc))
  (#eq? @function.macro "@doc"))

(source_file
  [
    (string_literal) @comment.doc
    (macrocall_expression
      (macro_argument_list
      (_)+
      (string_literal) @comment.doc .))
  ]
  .
  [
    (assignment)
    (const_statement)
    (global_statement)
    (abstract_definition)
    (function_definition)
    (macro_definition)
    (module_definition)
    (struct_definition)
    (macrocall_expression)
    (identifier)
    (open_tuple
      (identifier))
  ])

(module_definition
  [
    (string_literal) @comment.doc
    (macrocall_expression
      (macro_argument_list
      (_)+
      (string_literal) @comment.doc .))
  ]
  .
  [
    (assignment)
    (const_statement)
    (global_statement)
    (abstract_definition)
    (function_definition)
    (macro_definition)
    (module_definition)
    (struct_definition)
    (macrocall_expression)
    (identifier)
    (open_tuple
      (identifier))
  ])

Plus three queries in injections.scm:

((macrocall_expression
  (macro_identifier "@" (identifier)) @_macro
  (macro_argument_list
    .
    (string_literal) @content))
  (#eq? @_macro "@doc")
  (#set! "language" "markdown"))

(source_file
  [
    (string_literal) @content
    (macrocall_expression
      (macro_argument_list
      (_)+
      (string_literal) @content .))
  ]
  .
  [
    (assignment)
    (const_statement)
    (global_statement)
    (abstract_definition)
    (function_definition)
    (macro_definition)
    (module_definition)
    (struct_definition)
    (macrocall_expression)
    (identifier)
    (open_tuple
      (identifier))
  ]
  (#set! "language" "markdown"))

(module_definition
  [
    (string_literal) @content
    (macrocall_expression
      (macro_argument_list
      (_)+
      (string_literal) @content .))
  ]
  .
  [
    (assignment)
    (const_statement)
    (global_statement)
    (abstract_definition)
    (function_definition)
    (macro_definition)
    (module_definition)
    (struct_definition)
    (macrocall_expression)
    (identifier)
    (open_tuple
      (identifier))
  ]
  (#set! "language" "markdown"))

Yes, those two test cases in docstrings.jl are still broken but they should be quite rare at the top level. One can easily write @info("Yo", "This should _not_ have markdown injected!") to clean that up.

Those are good suggestions, that cleans it up a lot. I'll probably have time to update the PR sometime this week. From a quick glance it looks like your queries there should pretty much just work.

Alright, I pretty much got it done, but I noticed that this approach gives us slightly worse granularity. I thought I might be able to apply the #match? @content "^\"\"\"" only to the "stolen by preceding macro" case, like this:
[
  (string_literal) @content
  ; Workaroud: Find strings stolen as the last argument to a preceding macro
  ; https://github.com/tree-sitter/tree-sitter-julia/issues/150
  ((macrocall_expression
    (macro_argument_list
    (_)+
    (string_literal) @content .))
    (#match? @content "^\"\"\""))
]

But that doesn't seem to actually work. All constraints on the capture appear to be global. So restricting @content to be triple-quoted will break otherwise sensible docstrings, such as
"This _should_ have `markdown` injected!"
function foobar end

While most docstrings are triple-quoted, I think single-quoted docstrings are fairly common in the wild for docstrings that are just a one-sentence summary.
I would say we go ahead with it still, and say that for the time being people just have to triple quote docstrings or use @doc, because it is a very good restriction for weeding out false positives.

Yeah, that's better. Looks good to me.


evaluate library is missing

Hi All! Thanks for the great repository.
I wanted to point out that the link in the readme file pointing to the evaluation script is broken and I cannot find how to evaluate a saved model. Would you mind checking this out?

Thanks! I'm updating the link to point to the right place: https://github.com/google-deepmind/meltingpot/blob/main/meltingpot/utils/evaluation/evaluation.py


ImportError: Package 'textual.widgets' has no class 'TextLog'

This happens on the tests on main branch, here is a recent re-run of the CI and another run with the patch
After installing dev packages on a fresh venv, then running pytest, one gets this error:
================================================================== ERRORS ===================================================================
___________________________________________ ERROR collecting redun/tests/test_static_analysis.py ____________________________________________
ImportError while importing test module '/work/redun/redun/tests/test_static_analysis.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
redun/tests/test_static_analysis.py:21: in <module>                                                                                for module in import_all_modules(redun)
redun/tests/utils.py:466: in import_all_modules                                                                                modules.extend(import_all_modules(module))
redun/tests/utils.py:464: in import_all_modules
    module = importlib.import_module(full_name)
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)                                                                              redun/console/app.py:16: in <module>
    from redun.console.screens import (                                                                                redun/console/screens.py:17: in <module>
    from textual.widgets import Footer, Input, Label, Static, TextLog
/home/gabriel/.local/share/virtualenvs/redun-gyVl-7AX/lib/python3.11/site-packages/textual/widgets/__init__.py:98: in __getattr__
    raise ImportError(f"Package 'textual.widgets' has no class '{widget_class}'")
E   ImportError: Package 'textual.widgets' has no class 'TextLog'

A quick google shows this: https://textual.textualize.io/FAQ/#no-widget-called-textlog

No widget called TextLog¶
The TextLog widget was renamed to RichLog in Textual 0.32.0.

The dev requirements don't explicitly list textual as a dependency, and pip installed version 0.36.0 for me. I added a pinned version of textual=0.31.0 to avoid this issue - see PR
I also had another error with pip trying out and rejecting all versions of pygraphviz -- so I pinned version 1.11 which was installed in the last test execution on github actions. But now tox complains about that version, it wants versions <=1.8 on the older python versions.

Thanks for posting this. We have fixed this in a our dev branch, but I forgot to push it to our public one.
Commit with a fix for the textual change: https://github.com/insitro/redun/commit/bf82ef819fcda0ba7a85f5b2fc8fa2d8821e57eb#diff-2b9f88b7d249ad141e9647d11d2a514071b5917a14367dc3f083cb9a849fa5adR200


chore: add LICENSE file

Signed-off-by: Jennifer Power<EMAIL_ADDRESS>

New commit, but just changed the misspelling of the word license.


feat: add CreateJobEntity and JobForm component

What does this pull request change?
add a CreateJobEntity component to make it easier to create a job entity for the user. Avoid hard coding values for the job entity.
with form

with default entity

Issues related to this change
#280

styling is very bad, so any feedback here is much appreciated!


new format for Elowitz

simulatedData sheet needs to be filled

offset_fluorescence missing in parameter table

same probably for scaling_fluorescence and sd_fluorescence. However, there exist suspicious scale and sigma parameters in the parameter tsv

as mentioned during the hackathon, we can only correctly simulate this model, if we transform the measurement values. in discussions at the hackathon, it became clear that this should not happen. In which case the measurement data seems off. I'll make a pull request with the transformed data.


Incompatibility with RTL in react-with-styles-interface-aphrodite

The react-with-styles-interface-aphrodite interface has its own RTL layout support (docs: https://github.com/airbnb/react-with-styles-interface-aphrodite#built-in-rtl-support)
We'd like react-dates' RTL implementation to work harmoniously with this interface. To do this, we could:

add /* noflip */ to the relevant directional styles in react-dates, and
use the contextual css method from react-with-styles

cc: @majapw
for reference, the current workaround is to "disable" react-with-style's RTL support:
<DirectionProvider direction={DIRECTIONS.LTR}>
  <div dir={direction}>
    <DayPickerRangeController
      {...props}
      isRTL={direction === DIRECTIONS.RTL}
    />
  </div>
</DirectionProvider>

This has been fixed by #1482/#1492 in v18.3.1 of react-dates


Effects performance: use of concatMap

This issue is for a:
- [ ] bug report -> please search issues before submitting
- [x] feature request
- [x] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce
It seems that currently all effects run through concatMap. I agree that this is safe and a must for write actions. The downside of this is performance, but we can improve that by doing optimistic state updates if we choose to.
What I disagree on, is that this should be used for read actions. In my opinion, actions like QUERY_ALL, QUERY_BY_KEY and QUERY_MANY should definitely not be concatted. Doing this will make sure your app's performance is suboptimal. I'll try to make that clear in the following two examples:

Paginated query data sets. The user wants to quickly skip to page 5, so he clicks 'Next page' 4 times in quick succession. Using concatMap will cause the query for each page to complete, before executing the query for the next page. Result: consider a query takes n time to return data. Showing the results for page 5 in this case has a response time of 4 * n. When using switchMap the response time would be n.

Imagine that same query data set shows entities that have a link to a second entity. For example, we're querying orders, and each order has a companyId property. When showing these entities, we want to fetch the related company and show it's name. So for a query result of 10 entities, we dispatch 10 QUERY_BY_KEY actions. Using concatMap will cause these to be fetched one by one, even if some have the same key. Response time = 10 * n. This can be optimised by grouping these actions by key, then merging into exhaustMap. This makes sure we only fetch each key once, and we fetch each key concurrently. Response time = n, with a lower total load on the server. I've been using the following custom operator to do so:

import { Observable } from 'rxjs/Observable';
import { exhaustMap, groupBy, mergeMap } from 'rxjs/operators';

/**
 * Operator to fetch resources by id.
 *
 * Requests for entity 1 will run concurrently with requests for entity 2.
 * In addition, when multiple requests are scheduled for entity 1, it will
 * only run the first one.
 */
export const fetchById = <O>(request$: (id: string) => Observable<O>) => (
  source: Observable<string>
) =>
  source.pipe(
    groupBy(id => id),
    mergeMap(grouped => grouped.pipe(exhaustMap(request$)))
  );

This could be further improved by (optionally) filtering out entities we have already fetched before. This makes sure we don't fetch the same company again when we go to the second page of orders.
import { Observable } from 'rxjs/Observable';
import { filter, map, withLatestFrom } from 'rxjs/operators';

/**
 * Operator which does not emit when an id already exists.
 */
export const filterById = (currentIds$: Observable<string[]>) => (
  source: Observable<string>
) =>
  source.pipe(
    withLatestFrom(currentIds$),
    filter(([id, ids]) => !!id && !ids.includes(id)),
    map(([id, ids]) => id)
  );

These are just two simple examples, but many other cases exist!
Expected/desired behavior
I hope I've made it clear that using concatMap for all effects can result in big performance hits. What I expect is that using ngRx data will result in optimal performance, or at least allows me to configure it to do so.
Mention any other details that might be useful
I really LOVE the concept of this library and I'm guessing this could truly cut my codebase in half  🎉

Thank you for taking the time to express these critical observations!
I enthusiastically agree that using concatMap for all possible queries will adversely affect performance, especially in the scenarios that you describe.
I argue that every one of your examples is a special case that should not be handled by the persist$ effect!
Instead you should make your own HTTP calls for these cases (in a service of course), assemble the results, and issue the appropriate actions to the store. You'll find the ngrx-data cache-only actions quite useful for this purpose.

You could do all this in your own effect. Personally, that's more bother than value but you may have a different feeling about that.

But for mainstream, no brainer ngrx-data, the concatMap approach is  the only safe one. I don't see what kind of "configuration" would make it better.
Reminder: the goal of ngrx-data is to eliminate boilerplate, not eliminate the use of ngrx.  The scenarios you've identified - all of them worthy - are NOT boilerplate. They are that 10% of activities that you should carefully craft by hand.
Your issue reminds me that we should make this point emphatically in the documentation. We could reinforce the point by including your examples in the documentation, the samples, or in tests.
We love pull requests.
I'll give you a chance to respond. Then I will  likely close as there is no obvious action we should take at this point ... unless you come up with one.
Thanks again.

Thanks for your extensive reply!
I think I agree with you. I probably got my hopes up too fast in thinking all would be perfect by default, but of course there's never a "zero config" perfect default for all edge cases.
On actions to take though I have several ideas:

It should be clearly documented that the default effects use concatMap and that this can impact performance. I had to dig through the source, which might be a good thing as well though.

It should be clearly documented how to customize effects, using the cache-only actions you mention, or other ways that exist.

The name of persist$ and persistOps is confusing to me. I understand these actions are persistent on the client side, but my first thought was only write actions that are persistent on the server side were handled by this persist$ effect.

Still really love the concept here compared to other ngrx boilerplate eliminators that are out there!

Great suggestions. Let me see what I can do. Holding this open until I act upon them.


Minor: amount of errors in title bar is always appended

Describe the bug
A window with errors gets updated, but the title always has the counter added near the end one. See screenshot.
To Reproduce
I used a buggy script.
Expected behavior
The title is replaced with a fresh counter each time.
Screenshots

Environment (please complete the following information):

OS: Win10
Java Version:
Ghidra Version: 9.2

Corrected for Ghidra 9.2.3

Corrected for Ghidra 9.2.3


queen-attack: Provided stub file doesn't match usage from test

The stub file only does provide a Queens.new/1 which has @spec new(nil | list), while the tests do call it either without any arguments or with two seperate arguments but not a list.

yep, the exercise was updated and forgot about the @spec


test() and find() do not find the same strings as valid/invalid links

Hello there 👋.
Going straight to the point:
find()
linkify.find('1.nf3')

Output:
[{
  "type": "url",
  "value": "1.nf",
  "isLink": true,
  "href": "http://1.nf",
  "start": 0,
  "end": 4
}]

test()
linkify.test("1.nf3")

Output:
false

I understand that Linkify is not 100% spec compliant, but shouldn't test() and find() return the same output? More importantly, linkify.find('1.nf3') should return [] because .nf3 is not a valid TLD while .nf is (ref).
Is this a bug, or is this somehow intended?

Hi @rfgamaral, thanks for the report. The output of find has 1.nf, which is a valid URL. Notice that it excludes the final 3. test returns false because while "1.nf3" does contain a valid URL, the full string is not a URL.
You can see this this clearly when you run linkify.tokenize:
linkify.tokenize("1.nf3").map(token => token.toObject())

Output:
[
    {
        "type": "url",
        "value": "1.nf",
        "isLink": true,
        "href": "http://1.nf",
        "start": 0,
        "end": 4
    },
    {
        "type": "text",
        "value": "3",
        "isLink": false,
        "href": "3",
        "start": 4,
        "end": 5
    }
]

linkify.test runs tokenize and expects exactly one token with isLink: true.
Hope that helps

@nfrasser Thank you for the quick reply, however, this creates a problem on our side, that I'm not exactly sure how to fix.
This issue was first reported to one of our products in the context of a rich-text editor. A user typed 1.nf3, and ended up having the 1.nf string linked, while the 3 at the end was not. From our perspective (and the users', nothing should be linked in this string). Our rich-text editor uses Tiptap, which in turn uses Linkify and the find function to find links. While typing a string such as 1.nf3<space>, when pressing <space>, this is when the find function is executed and finds the link. From a rich-text editor perspective, typing something like 1.nf3 shouldn't auto link the string because .nf3 is not a valid TLD, which the test function seems to be aware of.
Do you have any suggestions on how to approach "fixing" or improving this behaviour based on the rationale explained above? The auto linking mechanism in Tiptap provides a validate function before doing the actual auto linking in the editor, I could use that and call linkify.test(str) to validate the link based on the test function. Would that make sense, or do you think that could cause issues down the line?

@rfgamaral thanks for the additional explanation, I can definitely empathize with the expected behaviour here. Unfortunately I don't have an easy fix for this. Linkify's parser implementation has to support cases where there are no spaces around the URL. A fix for this would likely mean breaking other valid cases. It comes down to the inherent ambiguity of mixing plain-text with machine-readable strings.
Related issues to showcase the kinds of challenges I have to account for:

#351
#360
#446

If you haven't already, I would suggest reporting this issue with Tiptap. Perhaps they can tweak their editor's implementation to avoid detecting links in the string immediately before the <space> when only one token is detected.
Another potential option: Try linkify v3 instead of v4, which has a slightly different parsing implementation. The drawback there is that since it's an older version, it might have other bugs or missing features.

If you haven't already, I would suggest reporting this issue with Tiptap.

I'm prepared to tackle this myself and open a PR against Tiptap, I'm just trying to understand what would be the best solution.

Perhaps they can tweak their editor's implementation to avoid detecting links in the string immediately before the <space> when only one token is detected.

I think that might effectively disable auto-linking for things like example.com, which is not the intended behaviour. Instead, I was thinking that I could use tokenize (instead of find, which is what Tiptap currently uses), and add some logic to validate links, perhaps comparing the end and start positions of multiple tokens, or, even better, do the same validation that test already does:

linkify.test runs tokenize and expects exactly one token with isLink: true.

My only concern is that docs mention that tokenize is an internal function, so I'm not sure if I should be using that directly. Right?
However, this feels like the type of link validation that I would expect to exist in a rich-text editor with auto-linking functionality. So, to summarize, I could open a PR in Tiptap to use tokenize instead of find and do the same validation that test does, or, alternatively, use the validation that Tiptap provides to call test to validate the link. The advantage of the latter would be that I could push this change to our users immediately, without waiting for PR approval on the Tiptap side (and they could not agree with the solution), and a new version to be published. Unless, there's some downside, I should be aware?

FYI, I ended up opening a PR on Tiptap replacing find with tokenize, and do a similar check as test (ref).

Similar situation here:
linkify.test("https://linkify.js.org/docs/    https://linkify.js.org/docs/     https://linkify.js.org/docs/    https://linkify.js.org/docs/")
return as false, whereas
linkify.find("https://linkify.js.org/docs/    https://linkify.js.org/docs/     https://linkify.js.org/docs/    https://linkify.js.org/docs/")
returns
[
    {
        "type": "url",
        "value": "https://linkify.js.org/docs/",
        "isLink": true,
        "href": "https://linkify.js.org/docs/",
        "start": 0,
        "end": 28
    },
    {
        "type": "url",
        "value": "https://linkify.js.org/docs/",
        "isLink": true,
        "href": "https://linkify.js.org/docs/",
        "start": 32,
        "end": 60
    },
    {
        "type": "url",
        "value": "https://linkify.js.org/docs/",
        "isLink": true,
        "href": "https://linkify.js.org/docs/",
        "start": 65,
        "end": 93
    },
    {
        "type": "url",
        "value": "https://linkify.js.org/docs/",
        "isLink": true,
        "href": "https://linkify.js.org/docs/",
        "start": 97,
        "end": 125
    }
]


"SafeBox technology" under investigation :)

Paper V2 does not really explain how the "account data" is protected from alteration.
So far source code inspection has shown that account data like account.balance is not "hashed" in accountsegment hash. Only blockchain block header's of some sort seem to be hashed as described in the paper.
safebox hash = sha256( hash1+hash2+hash3...n );
Loader and some save code experiments have shown that it is possible to change account.balance data in checkpoints/safeboxes and pascalcoin application will happily load it up and perform no checks and no hashing what so ever on account.balances.
So what is pascalcoin supposed to make safe ? So far very hard to tell.
Original idea of bitcoin was to use leading zeros and hashes per transaction block in such a way that modifieing and recomputing all of these leading zero hashes would be infeasible.
PascalCoin's safebox does not seem to imploy the same idea and simply calculates a hash over a number of hashes, without even including account data like balances.
This means account balance can:

Very easily be modified since no hashing over them is done at all.
The hash computation is very easily reproduceable and offers no safe guard what so ever against modifieing values.

So far I hope blockchain itself provides some protection against modified safeboxes. A quick/sloppy/dirty test has shown that this may not provide any safe guard against modifieing blockchain as well as safebox.
So far the paper fails to explain the security of PascalCoin and PascalCoin itself may be totally insecure.
At the very least the network with most hashing power can easily modifieing the entire safebox !

A Hacked version of PascalCoin has been created to demonstrate the problem at the following repository:
https://github.com/SkybuckFlying/PascalCoinHacked
All source code available and 64 bit PascalCoin(Hacked) executable available.
This version could be used by big miners to hack pascalcoin, use this hacked version in subsequent testing see what it does and verify if it's a problem or not... and try and defend against it.
Not exactly sure if this is going to work but so far seemed like it.

Please stop your mentally ill spamming on github and take your questions to Discord. Your comments are mostly utter nonsense.
Sent from my iPhone

On 15 Jul 2018, at 12:20 am, Skybuck Flying<EMAIL_ADDRESS>wrote:
Paper V2 does not really explain how the "account data" is protected from alteration.
So far source code inspection has shown that account data like account.balance is not "hashed" in accountsegment hash. Only blockchain block header's of some sort seem to be hashed as described in the paper.
safebox hash = sha256( hash1+hash2+hash3...n );
Loader and some save code experiments have shown that it is possible to change account.balance data in checkpoints/safeboxes and pascalcoin application will happily load it up and perform no checks and no hashing what so ever on account.balances.
So what is pascalcoin supposed to make safe ? So far very hard to tell.
Original idea of bitcoin was to use leading zeros and hashes per transaction block in such a way that modifieing and recomputing all of these leading zero hashes would be infeasible.
PascalCoin's safebox does not seem to imploy the same idea and simply calculates a hash over a number of hashes, without even including account data like balances.
This means account balance can:
Very easily be modified since no hashing over them is done at all.
The hash computation is very easily reproduceable and offers no safe guard what so ever against modifieing values.
So far I hope blockchain itself provides some protection against modified safeboxes. A quick/sloppy/dirty test has shown that this may not provide any safe guard against modifieing blockchain as well as safebox.
So far the paper fails to explain the security of PascalCoin and PascalCoin itself may be totally insecure.
At the very least the network with most hashing power can easily modifieing the entire safebox !
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

This potential hack is currently being investigated to see if it can actually work, first tries/initial results in past were somewhat confusing/mudded. Currently more precise examination is under way.

For now I was not able to hack PascalCoin successfully. For now it will be considered secure until further notice ! ;) :)


Add Playwright tests

Playwright tests have been added to e2e test login, shopping cart performance, product listings, and more.
README

@MarcusFelling Is this PR in the right repo? I don't see anything related to Redis in the code

@MarcusFelling Is this PR in the right repo? I don't see anything related to Redis in the code

@philon-msft - yes, this was requested by @CawaMS. These are UI tests that exercise the web app. I'll also be adding load tests. PR coming soon...

@MarcusFelling Is this PR in the right repo? I don't see anything related to Redis in the code

@philon-msft - yes, this was requested by @CawaMS. These are UI tests that exercise the web app. I'll also be adding load tests. PR coming soon...

Great - thanks for your contribution!

Are we merging this pull request?

Are we merging this pull request? @philon-msft @MarcusFelling

Good to go on my end. @philon-msft, who do we need to sign off?

@CawaMS I've added you as a maintainer on the repo. Feel free to merge when you're satisfied with quality


chore: changes to make code consistent

Description of the change:
Code Formatting
Converted stateful components to Functional components.
Reason for the change:
React 16.6 was just released, introducing React.memo. Quoting from the Motivation section of the RFC:

Today in React, function components and PureComponent provide two different kinds of optimizations that can't be unified.
Function components let us avoid constructing a class instance. This benefits the initial render. Function components also tend to minify better than classes, which helps reduce the bundle size.
⋮
By having memo as a first-class API in React itself, we can remove the need to make a choice between these optimizations. It makes it easy to memoize the output of function components without introducing other extra costs.

Now by using React.memo(), functional components can be optimized.

Hi @justinwhall,
Fixed some of the lint errors. They are some more errors that are not introduced by me. I'll try to fix them in another PR. Thanks !

CC: @ksigler7

Hello @KirankumarAmbati,Thanks again for the PR! It's HACKTOBERFEST! We want to show our appreciation by sending                                              you some special Hacktoberfest swag. If you have not already, could you please fill out                                              this form so we can send it to you? Thanks!                                             Team SendGrid DX

Hi Team, are we good with this PR ? Or any more changes are required ?

@KirankumarAmbati - we got a ton of PRs that need review with the final Hacktoberfest push and we are still reviewing! Will let you know soon - thanks for touching base

Ya. I understand ! @ksigler7
Take your time. No worries ! I just thought I could help you in some way. 🙂

Hi @KirankumarAmbati - We are still seeing some linting errors. One example is here.
Be sure you have eslint enabled. Thanks!


Improve error messages in pyimpl.rs

Just noticed these and thought I'd tweak them. Not sure if CHANGELOG entry is necessary.

Thanks!


(question) Breaking changes

Hey guys, as the repo do not have a changelog file, I need to ask if the upgrade to v2 have some breaking changes that I need to care about when migrating from v1.
Thanks

Hi @gabrielrtakeda
The library has changed dramatically on v2.0. There is no CHANGELOG file because it is almost as a new library.
If you wish to use a JavaScript API without React, you can use universal-cookie. The migration should be painless just by reading the doc.
If you care about React and async server-rendering (doing multiple at the same time), I highly recommend you check out the new react-cookie. However, the change is dramatic.

I just noticed this, the library looks completely revamped, you should lock your old apps using the older version of this react-cookies and not update it to v2.

Also, came here for the same question.
@eXon Can we add this to the README and/or start a Changelog (since I noticed that even with v2, the library has gone to 2.1)?
Grateful for your work on this, so just a suggestion to improve the DX. Thank you!

It really leaves your users in the dark if you don’t offer some kind of documentation around migrating or even a README mention that the library is so different that an actual migration isn’t possible. Something they can locate outside of a Github issue.


double scrollbar quirk

I have the odd situation that the first time I view a div with double scrollbars, I see both scrollbars.  The second time I go back to the same div, I only see the bottom scrollbar,  The top scrollbar is missing.  This happens with IE 11, Chrome & FF.  Have you heard of this?

Hi, could you please create some example (e.g. http://jsfiddle.net) or describe your issue bit more?

I will try to get a jsfiddle shortly, but let me  say more precisely that the top scrollbar disappears after the initial appearance but the scrollbar track is still visible.  Also, clicking into the content area between the scrollbars causes the top scrollbar to reappear.   The bottom scrollbar is visible at all times

I am having trouble reproducing the issue with simple components.  Attached is is a screen shot of the top scrollbar, where you can you see the missing scrollbar (or rather empty scrollbar track).  the content area has a table directive using the angular-table directive.  http://samu.github.io/angular-table/examples/examples.html.  This directive might have a role in this behavior.  As I mentioned clicking on the content area, causes the top scrollbar to reappear.


lxd init: ask for images.auto_update_cached

On lxd init, ask the user whether he wants lxd to automatically refresh stale
images. Defaults to true.
Signed-off-by: Christian Brauner<EMAIL_ADDRESS>Closes #2167.

So, changing auto_update_cached isn't actually the right thing to do here.
Changing that boolean controls whether further image imports will have the auto_update property set to true. It doesn't control whether existing images will be updated and more importantly, it's painful to the re-enable.
What this option should be doing is set images.auto_update_interval to 0 which simply disables the auto-update goroutine in a way that can then be easily re-enabled by changing it to whatever value you want.

There is still one problem left with this branch. If I run "lxd init" twice, the first time I turn off image auto update and the second I don't, then it'll still be off.
So we need to be a bit more clever here, most likely:

Ask the question
If yes, set to 0
If no and, read the current value. If it's 0, then unset the key, if not, leave the current value alone.

Looks like there is another issue. If used in auto mode (--auto), then the image update feature will always be turned off as the question won't be asked and the boolean defaults to false.

Sorry, will take care of this.

Looks good to me. Running "lxd init --auto" will now effectively re-enable image auto-updates if it was previously disabled, but that's actually consistent with everything else that we do in "lxd init" so that's fine.
Will merge once Jenkins is happy.
Thanks!

Thanks for the patience. :)


Once turned on,not turning off

You mean the sensor?

Yes.

On it

Fixed (temporarily)
https://github.com/CovenantJunior/motion-sensor/issues/12

Fixed completely. @jona4life  played a great role


Gamescope & Pipewire

Is there any plan on switching from steamos-compositor-plus to gamescope session? As well as pipewire for audio?

The problem with Gamescope is that it won't work on Nvidia cards, no matter what we or Valve do, unless Nvidia supports some vulkan extensions that currently doesn't.
As for pipewire, all is there, just need to pull the trigger on pipewire-pulse package and drop pulseaudio. As far as I've tested it works flawlessly.

I have tried switching to pipewire and it resulted in broken audio. Maybe I will try again at some point.

I have tried switching to pipewire and it resulted in broken audio. Maybe I will try again at some point.

Would you consider perhaps switching to booster from mkinitcpio and linux-zen?

The problem with Gamescope is that it won't work on Nvidia cards, no matter what we or Valve do, unless Nvidia supports some vulkan extensions that currently doesn't.
As for pipewire, all is there, just need to pull the trigger on pipewire-pulse package and drop pulseaudio. As far as I've tested it works flawlessly.

Could there perhaps be a Gamescope version of ISO for ChimeraOS, or in the installer for people to choose?

Could there perhaps be a Gamescope version of ISO for ChimeraOS, or in the installer for people to choose?

The default ChimeraOS image ships Gamescope session already but is not turned on by default. You can switch with these commands:
$ sudo systemctl disable lightdm.service
$ sudo syatemctl enable<EMAIL_ADDRESS>
Then reboot. The change will persist updates of the distribution.


[bug] Module evaluated twice.

I'm submitting a bug report
Webpack version:
1.10.x
Please tell us about your environment:
OSX 10.x
Current behavior:
A module is evaluated twice.
Expected/desired behavior:
This should not happen by default. It really goes against the ES6 module contract.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem along with a gist/jsbin of your webpack configuration.
Using the DedupePlugin does not solve the issue (I tried and verified). No repro yet, but I have a file that starts with the following, and as you can see it has a console.log at the top level:

// infamous/motor/Node.js
import 'geometry-interfaces'
import Motor from './Motor'
import MotorHTMLNode from '../motor-html/node'

console.log(' -- Node module ?????!')

Multiple modules in the app import that file, and the console.log statement is fired twice, as seen in the output:

What is the expected behavior?
The  -- Node module ?????! output should only appear once.

What is the motivation / use case for changing the behavior?
If this isn't a bug, then to follow the spec, making modules easier to reason about and less error-prone. Problems can happen when data structures are expected to be singletons.

Browser: not applicable

Language: ES6/7 via Babel

@bebraw This is happening with the same code base as I have in #2735. When I import Node from my app's entry point, I get this problem. But, when I import Scene, that's when I get #2735. Seems like depending on which module I import first dictates the order of module evaluation. In my case, the Node module has a dependency loop that eventually imports Scene, while Scene imports Node directly, and uses it during module evaluation at which point it is undefined (live binding or not).

I was trying to make a reproduction, but apparently the results are different when getting the infamous dependency from GitHub (including built files normally build on prepublish). I am only able to reproduce by npm linking infamous from the local file system (which is how I'm doing my development).
Reproduction script (I verified that it reproduces the problem each time):
# folder to contain everything
mkdir webpack-issue-2740
cd webpack-issue-2740

# set up infamous dependency
git clone git@github.com:trusktr/webpack.git infamous
cd infamous
git checkout issue-2740-infamous # infamous dependency stored in this branch
npm install
npm link
cd ..

# set up reproduction example
git clone git@github.com:trusktr/webpack.git app
cd app
git checkout issue-2740 # sample app is in this branch
npm install
npm link infamous # this step is required, otherwise we get errors relating to issue #2735
npm run local

Then open localhost:8080/welcome in your browser to see the duplicate output in the console.
Note, I npm shrinkwrapped the infamous dependencies, but was not able to do so for the example app because the npm link step seems to get in the way of that. It should be fine though.

I know the reproduction is a little complicated, but the app is as minimal as possible, importing only a single thing from the infamous dependency. I you guys could check it out, it would be highly appreciated; I put some time into making that repro. :]

To see the original code where the console.log line originates, just open up webpack-issue-2740/infamous/src/motor/Node. Note, that file is compiled, and the app is actually using the transpiled version: webpack-issue-2740/infamous/motor/Node (omit the src folder in the path to access the build equivalents).

Here's a dependency graph with other dependencies removed for simplicity, so I'm just showing the relevant circular dependencies. The arrows point to the importing module (f.e. you can see that motor-html/web-component is imported by motor-html/base). All are .js files.

I can repo this.
webpack 1 resolves loaders configured in webpack.config.js relative to the file which contains the require/import. This means for infamous/motor/Node in app/index.js the babel-loader from app/node_modules is used. For ../motor/Node in infamous/motor-html/node.js the babel-loader from infamous/node_modules is used.
Each module gets an identifier containing loaders and resource. This makes both modules different and the same module is emitted twice (and therefore executed twice).
webpack 2 changes this behavior as configurated loaders are resolved relative to the configuration file. You can simulate the same behavior with resolveLoader.root = "...node_modules"

@sokra Thanks for the explanation. Did you mean resolveLoader.root = "../node_modules" or resolveLoader.root = "./node_modules" instead of resolveLoader.root = "...node_modules"?

Ah, nvm, you just were typing shortcut for absolute path I think.

yep, something like path.join(__dirname, "node_modules")

@sokra Seems to have worked. Do you think it would be worth changing this in v1 so that it follows ES6 Module expectations out-of-the-box?

The change is a breaking change, so I don't change it in v1.


[CodeCompletion] Fix call arguments completion in overloaded case

In <expr> '(' <code-completion-token> case, we usually complete call arguments. However, if <expr> isn't typechecked, for example because of overloading, we used to give up arguments completions.
Now, use possible callee informations from CodeCompletionTypeContextAnalyzer. This increases the chance to provide arguments completions.
rdar://problem/43703157
(#20703 is a groundwork for this PR)

@swift-ci Please smoke test

Will this work for individual label completions (i.e. what you get in overload(x: 1, <complete>)?

That's still TODO. (OVERLOAD1 and OVERLOAD2).
For example, given:
func foo(arg1: Int, bar: Double) {}
func foo(arg1: Int, baz: Int){}
func foo(arg1: String, qux: Int) {}

func _test(x:C ) {
  foo(arg1: 1, #^COMPLETE^#
}

bar:, baz:, and qux: are all suggested. But qux:  is not relevant here because arg1 is Int.

@swift-ci Please smoke test


Develop to master (readme changes only)

Coverage remained the same at 96.212% when pulling b4396fea5badc185262b241b8eba5ec7078e3ade on develop into 96e6bae6e16363f8d6130b7092d324c0c7495dd0 on master.


yt-dlp warnings like [youtube] TLS over QUIC did not succeed. Chain certificate verification failed or client cert validation failed.

Subject
When I use yt-dlp with urllib3.future (or urllib3-future - is there a difference?) and without setting --no-check-certificates I get a lot of these warnings.
With --extractor-args "youtube:formats=dashy" videos still download but the warnings show up while downloading as [download] Got error: TLS over QUIC did not succeed. Chain certificate verification failed or client cert validation failed. It seems like the first try always fails and then the 2nd try succeeds, though I'm not 100% sure of that.
Without the extractor-args, it seems to just retry 10 times and then fail.
Environment
OS Windows-11-10.0.22631-SP0
Python 3.12.3
OpenSSL 3.0.13 30 Jan 2024
urllib3 2.7.906

Steps to Reproduce

Install the latest version of yt-dlp
Download any video from YouTube, e.g. https://www.youtube.com/watch?v=1f6uVIK7Uko

Expected Behavior
No warnings / errors.
Actual Behavior

Warnings like [youtube] TLS over QUIC did not succeed. Chain certificate verification failed or client cert validation failed. before the download starts.
Errors like [download] Got error: TLS over QUIC did not succeed. Chain certificate verification failed or client cert validation failed. during the download.
Without --extractor-args "youtube:formats=dashy" the errors pile up until the download fails. With that argument, the download seems to work after 1 retry, but the errors keep occurring.

OK. yt-dlp constructed a custom ssl context with a loaded list of CA roots and passed it down to urllib3.
As HTTP/3 don't support native SSLContext, this issue appeared.
We fixed this issue in PR 114.
A release will be made soon.
regards,

The fix is live.
Try it with pip install urllib3-future qh3 -U
And report back.
Regards,

Thanks! I've tried a few different videos without --no-check-certificates and so far the warnings/errors seem to be gone!

Perfect! If you would share this testimony in the yt-dlp original issue, it would be great.


Inline breakpoint: combine current step marker and breakpoint?

I find that this takes a lot of space:

Why can the breakpoint not somehow indicate that it is the currently stepped thing?
Indicator in Chrome Dev Tools: seems to select the token

//cc @misolori

Dup of https://github.com/microsoft/vscode/issues/81718


File format facet

Do we still want the file format facet?  Sufia 7 has removed that facet, but we could put it back.

This is fixed now.


CI pre-commit failure

https://github.com/praw-dev/praw/runs/5028100257?check_suite_focus=true#step:6:8

@CAM-Gerlach Would you mind taking a look at this?

Sure, standby

As far as I can tell, it just looks like a random transient failure. Can you rerun I just retriggered a pre-commit lint job I have set up similarly to this one on python/peps and I don't the the error; the only thing I can think of is a conflict with the pre-commit installed by the previous install deps action, or the dependency versions installed therein, and the one installed by the pre-commit action. If the failure persists, I suggest just moving the install deps step to after the run pre-commit step, since the latter doesn't need the former and it works just fine without it as you can see on python/peps (I just upgraded my pre-commit infra there yesterday).

That, or something changed in the Windows image with the latest deployed version. You could try rolling back to windows-2019 and seeing if things change; IIRC they upgraded the windows-latest image to Windows Server 2022 very recently.

I bet it was the upgrade made to the windows image. I removed the windows step to get passing CI. You want to open a PR and have CI use windows-2019 and see if that fixes it?

Yeah, I can. If that's the case, its going to be a problem for other repos I maintain, so I'll report it upstream and hope it can be fixed.


280 characters via REST API only works for full_text and tweet_mode=extended

With Twitter's recent change to 280 characters, fetching tweets via the Search REST API endpoints only returns 280 characters when fetched via the tweet_mode=extended option. The default compatibility mode truncates the tweet text at 140 characters.
Here's the documentation:
https://developer.twitter.com/en/docs/tweets/tweet-updates
And here's is Andy Piper's confirmation of this:
https://twittercommunity.com/t/280-characters/94200/6
Note: that the full_text attribute replaces the text attribute in extended mode.
I have many features in my application that fetch tweets via the Search API and now that people are tweeting with 280 characters, a large number of them are being truncated.
Also, with the way Twitter no longer counts @replies in the character limit, people are often replying to many people in their tweets. But since the gem doesn't support full_text mode, it's not possible to parse out those replies and display only the actual text of the tweet. When there are many @replies, my application doesn't display any of the tweet text, which is really annoying to my users.
Can you please add support for the full_text attribute via tweet_mode=extended so that applications built with this gem can keep pace with Twitter's changes to the API?

Update: after doing some testing and experimenting, it appears that the gem is in fact pulling down the right data when fetching tweets from the Twitter Search API in tweet_mode=extended.
https://github.com/twitterdev/tweet-updates/blob/master/samples/initial/compatibility_extended_13996.json
After fetching a tweet via tweet_mode=extended, I'm able to access the various attributes via the .attrs method. Here are some examples of tweet attributes I've tested (note: they all work properly):
tweet.attrs[:full_text]
tweet.attrs[:user][:screen_name]
tweet.attrs[:in_reply_to_screen_name]
tweet.attrs[:entities][:user_mentions]
tweet.attrs[:display_text_range]
This means that we can properly render 280 character tweets.
It also means that we can at least access all the "components" of a tweet. But it's still a lot of work to parse the full_text of each tweet and somehow remove the user_mentions from the text and display them in a "Replying to:" div, similar to the way Twitter does it in their apps.
It would be super awesome if the gem did that for us! 💯

Hi! Has anyone made this work for Retweets? I still get RTs truncated while using tweet_mode: "extended". Original and Replies look fine.
Thanks.

Hi! Has anyone made this work for Retweets? I still get RTs truncated while using tweet_mode: "extended". Original and Replies look fine.
Thanks.
Nevermind, I found that the solution was to get the full_text from raw_tweet.attrs[:retweeted_status][:full_text] instead of raw_tweet.attrs[:full_text]

Hi @dtabares,  can you please let me know where to do the changes which you have mentioned.
Thank you.

Hello @dtabares you solve the problem?

Hi, I'm asking for advice. In two words;
if
@arr = Set.new
client.search("@#{params[:twitter_acc]}", result_type: "recent", tweet_mode: "extended")
            .take(params[:number_of_tweets].to_i)
            .collect do |tweet|
	@arr << tweet
                .full_text
                .gsub("@#{params[:twitter_acc]}", "")
                .gsub("RT :", "")
                .gsub("RT", "")
                puts tweet.full_text
end

, I get:
Started GET "/tweet_parser/index?number_of_tweets=10&twitter_acc=SkyNews" for <IP_ADDRESS> at 2018-01-26 18:51:24 +0300
Processing by TweetParserController#index as HTML
  Parameters: {"number_of_tweets"=>"10", "twitter_acc"=>"SkyNews"}

  Rendering tweet_parser/index.html.erb within layouts/application
  Rendered tweet_parser/index.html.erb within layouts/application (3.0ms)
  Rendered layouts/_navigation.html.erb (4.2ms)
Completed 200 OK in 2161ms (Views: 345.0ms | ActiveRecord: 0.0ms)

elsif:
@arr = Set.new
client.search("@#{params[:twitter_acc]}", result_type: "recent")
            .take(params[:number_of_tweets].to_i)
            .collect do |tweet|
	@arr << tweet
                .text
                .gsub("@#{params[:twitter_acc]}", "")
                .gsub("RT :", "")
                .gsub("RT", "")
                puts tweet.text
end

, I get:
Started GET "/tweet_parser/index?number_of_tweets=10&twitter_acc=SkyNews" for <IP_ADDRESS> at 2018-01-26 18:52:52 +0300
Processing by TweetParserController#index as HTML
  Parameters: {"number_of_tweets"=>"10", "twitter_acc"=>"SkyNews"}
@SkyNews Most media are a pile of biased shite anyway.
RT @jbwhitesnake: #FlagGate @SkyNews @BBCNews https://t.co/wF8ZG8TwKj
@SkyNews Not doing the Nutella brand any harm is it?

@Pardus_UK @SkyNews The show business world is full of them...Just waiting for a couple of rock bands to hit the he… https://t.co/KfQIS4WI22
RT @jbwhitesnake: #FlagGate @SkyNews @BBCNews https://t.co/wF8ZG8TwKj
@IsraelMFA @francediplo_EN @foreignoffice @KremlinRussia_E @markrutte @MinPres @DutchMFA @KatiPiri @KenRoth… https://t.co/9QdcRX6WSy
  Rendering tweet_parser/index.html.erb within layouts/application
  Rendered tweet_parser/index.html.erb within layouts/application (3.2ms)
  Rendered layouts/_navigation.html.erb (3.7ms)
Completed 200 OK in 2664ms (Views: 379.6ms | ActiveRecord: 0.0ms)

How to solve this problem?

@cmirnow  If you use tweet_mode: "extended", you should use tweet.attrs[:full_text] instead of tweet.full_text


add method to calculate power of a number

Related Issue
Closes: #50
Describe the changes you've made

Added a method doPower which accepts two arguments: base and exponent and then returns the value of base ^ exponent

Type of change
What sort of change have you made:

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] This change requires a documentation update

How Has This Been Tested?

By running a few test cases on local

Checklist

[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented on my code, particularly wherever it was hard to understand.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] Any dependent changes have been merged and published in downstream modules.

@ays14 There's some merge conflicts. Kindly fix it then I'll merge it.

Hi @Susmita-Dey , resolved the conflicts, please check.


Adding workflow automation for spark-rapids-jni [skip ci]

Signed-off-by: Matt Ahrens<EMAIL_ADDRESS>Automatically adds new issues into global spark-rapids Github Project

build


Hot reload refreshes multiple times when passing websockets through IIS reverse proxy

Which @angular/* package(s) are the source of the bug?
platform-server
Is this a regression?
No
Description
I need to replace a url sub-directory in my application with a new Angular app.  I want requests from /foo to be forwarded to localhost:4200.  I tried half a dozen ways to do this, and now I nearly have it working with IIS reverse proxy.  The application loads.  It thinks it's on the same domain as the rest of the application, websockets finally connect, but for some reason it refreshes many times after a saving an edit.  I can get away mostly, right now, without it, because I only need proof of concept that this scheme works to replace the sub-directory while keeping the tokens needed to make backend requests.
I know this isn't priority or probably really a bug from Angular's point of view, but maybe someone has that crucial piece of knowledge that will help.
Here are my IIS rules.  One thing I did find weird is how I have to Rewrite to http.  Dev Tools says it's connecting to ws, but if I set the rewrite to ws://localhost:4200/ws, I get 404'd.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <clear />
                <rule name="AngularWebsockets" stopProcessing="true">
                    <match url="^ws$" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                    </conditions>
                    <action type="Rewrite" url="http://localhost:4200/ws" appendQueryString="false" />
                </rule>
                <rule name="Angular" stopProcessing="true">
                    <match url="^Angular(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{CACHE_URL}" pattern="http://" />
                    </conditions>
                    <action type="Rewrite" url="http://localhost:4200{R:1}" />
                </rule>
                <rule name="EazeeApp" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
                        <add input="{CACHE_URL}" pattern="^(http?)://" />
                    </conditions>
                    <action type="Rewrite" url="http://localhost:2319/{R:1}" logRewrittenUrl="true" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

To reproduce this bug, you'll need to install ARR and Websocket support for IIS.
Please provide a link to a minimal reproduction of the bug
No response
Please provide the exception or error you saw
No error.  It just reloads about 15 times.  The server compiles instantly, but the page just keeps refreshing over and over again.

Please provide the environment you discovered this bug in (run ng version)
Angular CLI: 13.0.2
Node: 14.15.4
Package Manager: npm 6.14.10
OS: win32 x64

Angular: 13.0.1
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1300.2
@angular-devkit/build-angular   13.0.2
@angular-devkit/core            13.0.2
@angular-devkit/schematics      13.0.2
@angular/cli                    13.0.2
@angular/localize               13.0.3
@schematics/angular             13.0.2
rxjs                            7.4.0
typescript                      4.4.4

Anything else?
No response

Hi @bluebaroncanada,
Unfortunately, I don't have IIS to try this, but this doesn't seem to be reproducible using a different proxy service. I think this might be better suited on StackOverflow using tag angular-cli.
One thing that you might try is to set the dev-server public-host option. See https://angular.io/cli/serve for more information about the dev-server options.
I also tried to look for issues in webpack-dev-server but I couldn't find anything related to what you are experiencing.


⚠ Bofrost.lu has degraded performance

In 7228676, Bofrost.lu (https://www.bofrost.lu) experienced degraded performance:

HTTP code: 200
Response time: 1105 ms

Resolved: Bofrost.lu performance has improved in 59c93ba.


Issue with JSON value conversion

When running the sample Program.cs I'm getting:
Unhandled exception. System.Text.Json.JsonException: The JSON value could not be converted to System.Boolean. Path: $.info.leds.wv | LineNumber: 0 | BytePositionInLine: 521.
---> System.InvalidOperationException: Cannot get the value of a token type 'Number' as a boolean.
I believe this is due to a change in the MS System.Text.Json handling but I'm unsure how to get around this.
Appologies if this is not an issue but just me not knowing what I'm doing.

Hey @an-da-liu,
Not sure what's going off here as the value leds.wv should be a boolean value, but from the description, your device is returning a number within the JSON. (See JSON Spec - https://kno.wled.ge/interfaces/json-api/)
Is there any chance you can do a raw CURL request to the device to look at what values are getting returned and send the JSON response?
Thanks

Here is the JSON that came from WLED. Looks like it is sending a 0 instead of False. I'm running Version 0.13.1 on my module, I'll upgrade to 0.13.3 and see if its just a bug in that particular version of WLED.
WLED.txt

0.13.3.txt
Appears to have the same value after upgrading to 0.13.3

@an-da-liu ah I think I see what they've done, they've deprecated it and now says to use leds.lc instead and that's a byte instead so I guess they've just put the same value in leds.wv.
I think the best solution for this is to just remove the property.
I'll update the code and release a new version with the change.

@an-da-liu can you please try using the latest NuGet Package https://www.nuget.org/packages/WLED/2.0.46 and see if that now fixes the problem? If not feel free to re-open the issue.


ARM template to assign StorageBlobDataContributor Permissions not working

[Enter feedback here]
Upon deployment via ARM template, the StorageBlobDataContributor assignment on storage to the Syanpse Managed Identity isn't working. This RBAC associated is part of the provided quick start ARM template, it succeeds to deploy but upon checking checking for permissions, we can see that the permissions have not been granted.
Can someone please look into this?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 714c8b22-d7ab-11e5-8d84-27ef2262c270
Version Independent ID: 7b5c986f-7725-179c-c77f-26e255c482a7
Content: Quickstart: Create an Azure Synapse workspace Azure Resource Manager template - Azure Synapse Analytics
Content Source: articles/synapse-analytics/quickstart-deployment-template-workspaces.md
Service: synapse-analytics
Sub-service: workspace
GitHub Login: @julieMSFT
Microsoft Alias: jrasnick

@rahg-bmake
Thank you for reaching out. At this time we are reviewing the ask and will provide an update as appropriate

@rahg-bmake I have reached out to the respective owners of the ARM template sample. Will update you back once I have a response from the team.
Thank you for your patience

Hi @julieMSFT this is related to this template from Azure-samples and it looks like a fix is required. Could you please escalate this this relevant folks to have a look - https://github.com/Azure-Samples/Synapse/blob/main/Manage/DeployWorkspace/workspace/azuredeploy.json
Thank you

Hi @matt1883 can you help direct this to the right person who can take a look at this?

#assign:liudan66

#assign:RonyMSFT

@rahg-bmake this quickstart template references another template to create the storage account. You are correct that the StorageBlobDataContributor RBAC role assignment is not done by the quickstart templates. You can copy the quickstart template contents and create your own custom template and modify the template code given [here](https://docs.microsoft.com/en-us/azure/role-based-access-control/role-assignments-template#assign-an-azure-role to grant the RBAC role. You would need to ensure that the role is granted after the workspace is created.
You can find the 2 templates referenced in the quickstart template here:
Storage account: https://github.com/Azure-Samples/Synapse/blob/main/Manage/DeployWorkspace/storage/azuredeploy.json
Workspace: https://github.com/Azure-Samples/Synapse/blob/main/Manage/DeployWorkspace/workspace/azuredeploy.json

@julieMSFT please assign this to Matt Basile

#assign:mabasile-MSFT

@rahg-bmake I hope the information provide by @RonyMSFT helped resolve your issue. I will go ahead with closing this issue. The @notification mechanism continues to work even after an item is closed, in case further communication is needed. We hope to hear from you again.

#please-close


Be able to set elements in dynamic forms as readonly for certain users

It would be interesting to have for FormElements a ReadOnlyRule property similar to VisibilityRule that allow to decide dynamically using Rules if an element can be editable or not.

Done in XKProject repo.
Here you have differences with https://github.com/OrchardCMS/Orchard/issues/6816 issue (Ajax support for taxonomy element to have a chain of select lists each showing different levels of a hierarchy) https://github.com/xkproject/Orchard/compare/%236816_TaxonomyElementWithAjax...xkproject:%236835_ReadonlyRuleFormElements
I cannot send https://github.com/OrchardCMS/Orchard/issues/6816 issue as PR cause that other Issue is not clear if it is ok as it is for merging it in core. So, this ReadOnlyRule issue till previous one is not clear cannot be submitted as PR.

Added also in this branch support for tokens in VisibilityRule and in ReadOnlyRule
Added Token Element.GetContentToEdit that provides access to contentitem that is going to be edited
Finally also added conditions CompareCondition and IsNullOrWhiteSpaceCondition.
This allows to evaluate data of the edited content in Visibility Rule and ReadOnly Element. An example is this exppression I use in a Row Element within a Form to decide Visibility:
compare('{Element.ContentToEdit.Fields.BoatPart.PublishingState}','Rejected')))

Not sure it's easily doable as each form element would need to support this, contrary to VisibleRule. I will wait for other users to comment on the necessity.

Instead of implementing it similar to the VisibilityRule, you could implement it as an additional property for all elements that derive from FormElement so that the property only applies to Dynamic Form elements.

@sfmskywalker yes I did it as you comment: xkproject@ #6816_TaxonomyElementWithAjax...xkproject:#6835_ReadonlyRuleFormElements
Concretly this is the FormElement class with the ReadOnlyRule added

@sebastienros the necessity depends directly on this other issue https://github.com/OrchardCMS/Orchard/issues/6163 . If you implement the dynamic forms for edit content feature then after a while you start to need this other feature.
Related to dynamic forms for edit content feature currently when I have time I'm improving its code to make it more readable. I wiil ping you when it is ready, in order to hear your opinion and evaluate if a PR could be interesting.


Timesheet - 23/04/2021 - Bojan Ilijevski

Task 1
Managing social media
Answering private messages on Instagram and Facebook
Following/Unfollowing people on social media
Time Spent
1 hour

Total Time Spent
1 hour
Account Number
b1b1e90107d804e5317c8527129ceaededdcb162a6737112b88712742a08bb72

Approved


Terraform 0.12 update

Description of Issue
Terraform reached it's 0.12 release.  Would be great to make libvirt provider compatible with it.

System Information
./terraform-provider-libvirt f02e17b6216975e343690e34c73f375b5022da92
Compiled against library: libvirt 5.3.0
Using library: libvirt 5.3.0
Running hypervisor: QEMU 4.0.0
Running against daemon: 5.3.0

Terraform v0.12.0

Additional information:
At the moment an attempt to run plan fails with API incompatibility error:
~/dev/virt> tf plan
Error: Failed to instantiate provider "libvirt" to obtain schema: Incompatible API version with plugin. Plugin version: 4, Client versions: [5]

@alkersan  thanks for this issue. I was creating myself an ISSUE for this as reminder.
The release of 0.12 was yesterday announced yesterday, so we heard about that.
IT will be on our radar to migrate to 0.12 version.
Currently we will need to investigate what the new version can break in term of backward compatibility (if any breakage), etc..
But yes definitely it something we will do soonish :rocket: :balloon:

@MalloZup Is there any ETA on this? Compatibility with Terraform 0.12 is quite important, as other projects required the upgrade what rendered KVM infrastructure unmanageable for the time being.

@BartoszMilewski we want to release a version in short term with the actual master. After this the terraform v12 should be the fist item of our stack. @dmacvicar cc

In the meantime, it's a workaround to use the latest previous 0.11 version (0.11.14) from here: https://releases.hashicorp.com/terraform/0.11.14/
This may be a solutions for beginners like me who just want to play around with Vagrant and libvrt. I can understand that this doesn't solve the problem for users with conflicting other plugins, here you'll need to wait for the announced update.

I'm closing this issue since we plan to do real work and update in this issue https://github.com/dmacvicar/terraform-provider-libvirt/issues/605.
As an update, we have already a PR for doing the updat thx to  @tripledes, the main work will be to see if we have any regression, pkging. Not other feature will be merged into next release.
Thx to everybody :cupid:


Add Visit.days_observed and re-handle Observation.days_observed & Observation.severity

Replacement for #213

@vkluzner are we talking about the fact that severity and days_observed don't necessarily apply to all observable categories, e.g., test, bloodwork, patient_info etc?

BTW, the PI said that we can nuke Observation.severity, however, they would like to keep Observation.days_observed for future use.
So maybe do just that, but perhaps tweaking the verbose name and help text for days_observed will mitigate @vkluzner 's concerns?

@vkluzner I've added two more commits to:

nuke Observation.severity
remove "symptoms" from Observation.days_observed verbiage.

BTW, the PI said that we can nuke Observation.severity, however, they would like to keep Observation.days_observed for future use.
So maybe do just that, but perhaps tweaking the verbose name and help text for days_observed will mitigate @vkluzner 's concerns?

It's OK per Observation. My concern was about the Visit, which (as far as I remember) can include multiple Observations.

@vkluzner I've added two more commits to:

nuke Observation.severity
remove "symptoms" from Observation.days_observed verbiage.

What do you think? I really don't want to have to special case Observables and Observations such that their fields differ as a function of Observable.Category - I feel like it would be defeating the point.

Sounds good. I was mostly concerned about Visit (see my comment below).

My concern was about the Visit, which (as far as I remember) can include multiple Observations.

So this was the main point - the PI doesn't think that the clinicians will add "days observed" for each and every observation so it needs to go somewhere more global - the only suitable model being Visit. Additionally, the bulk data upload contains only a single value for dyas_observed which, before this PR, we auto-populated each observation with, however, it would be better to associate this only with the visit.
That being said, the PI also wanted to keep Observation.days_observed as they will want to create their own trial in the future and they requested that it stay. @glemson then came up with the idea for us to add it to Visit instead of auto-populating all observations so that we can semantically keep both options rather than nuking Observation.days_observed.

My concern was about the Visit, which (as far as I remember) can include multiple Observations.

So this was the main point - the PI doesn't think that the clinicians will add "days observed" for each and every observation so it needs to go somewhere more global - the only suitable model being Visit. Additionally, the bulk data upload contains only a single value for dyas_observed which, before this PR, we auto-populated each observation with, however, it would be better to associate this only with the visit.
That being said, the PI also wanted to keep Observation.days_observed as they will want to create their own trial in the future and they requested that it stay. @glemson then came up with the idea for us to add it to Visit instead of auto-populating all observations so that we can semantically keep both options rather than nuking Observation.days_observed.

I believe it's OK once PI is happy with it.


Add twitter to socials in footer

Maybe we can also add Slack, Discord (but discord would be the Scientific Python one) and discuss? WDYT?

Ok yes I will think about adding a section on the community page.


FIX 403 Error

Removed proxy support, as they make more complexity. Fixed token generator.
I am still testing, I haven't get any 403 error yet
Closes #7

As you can see I labelled it as WIP, later I will do code reformating, I am
waiting for confirmation from others.
On Mon, Jul 22, 2019, 14:35 Vasyl Zuzyak<EMAIL_ADDRESS>wrote:

@ZuBB commented on this pull request.
In src/tokenGenerator.js
https://github.com/k3rn31p4nic/google-translate-api/pull/10#discussion_r305754647
:

     }

   // if (code) {

   //   eval(code[0]);

   //   /* eslint-disable no-undef */

   //   if (typeof TKK !== 'undefined') {

   //     window.TKK = TKK;

   //     config.set('TKK', TKK);

   //   }

   //   /* eslint-enable no-undef */

   // }

there is no point in keeping commented old code. either remove it or as
much as possible from ol approach
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/k3rn31p4nic/google-translate-api/pull/10?email_source=notifications&email_token=ACOHNHSEN4SMYCXG43JANODQAV5PFA5CNFSM4IFWPTX2YY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOB7DQJPA#pullrequestreview-264701116,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACOHNHSS2V42PTMDUDAZNMLQAV5PFANCNFSM4IFWPTXQ
.

I think I've finished, just check both GET and POST requests. should work as intended.

hey @k3rn31p4nic how about releasing new version with this change?

Gonna do that after I test it with the application where I use it regularly to see if I need to do any changes before releasing.

Some new issue
Error while translating
{ HTTPError
    at translate (/opt/translator/node_modules/@k3rn31p4nic/google-translate-api/src/index.js:143:19)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:182:7)
  name: 'HTTPError',
  statusCode: 429,
  statusMessage: 'Too Many Requests' }

Hi @k3rn31p4nic!
do you have any news on your testing?
a bit offtop: just noticed that this package does not have minimum required version of node to run. I made a quick walk through code and found conts/let and async/await which gived us 'v7.10.1'  but probably you know better this kind of stuff. Would be nice to have it in package.json

do you have any news on your testing?

Yeah, it works.

just noticed that this package does not have minimum required version of node to run.

I'll set the node engine version and make a release soon.

Released in v1.1.0 :tada:

Some new issue
Error while translating
{ HTTPError
    at translate (/opt/translator/node_modules/@k3rn31p4nic/google-translate-api/src/index.js:143:19)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:182:7)
  name: 'HTTPError',
  statusCode: 429,
  statusMessage: 'Too Many Requests' }

Same here, anyone fixed this ?


OS and OS Type are null

Hello
On Docker Version attribute, I have OS and OS Type with null values.

When I type docker info on Home Assistant Bash, I have these infos

It's possible to fic it ?
Thanks for advance

It's OK with pull request


How should we translate these contents?

The user manual is organized in locales subfolders, which allows translating it in GitHub. Loomio School, however, is not organized in the same way.
Is there a plan for Loomio School translations? Should we move the current content to an en folder and create other locales folders for translation? How can we manage redirections from the current URIs to the /en/ new ones?

Actually, we'd really like to merge the user-manual with loomio-school, so it becomes a section within it. It's quite confusing that we have two help/support sites.
Redirections are pretty easy to handle we do it in one place, just need to make it generalised.
Yes, we should move it to an en folder, if you have the energy that would be amazing.

to be clear, Loomio-school would be the main help site, and the user-manual would be a section within it.

Ok, that makes sense. I'll focus on updating the user-manual for a start, and will try to PR this if I find enough time.