Publish nodejs packages under hyperledger

Signed-off-by: Patrik Stas<EMAIL_ADDRESS>

Codecov Report

Merging #142 into master will decrease coverage by 0.03%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #142      +/-   ##
==========================================
- Coverage   50.78%   50.75%   -0.04%
==========================================
  Files         151      151
  Lines       22798    22798
  Branches     6028     6028
==========================================
- Hits        11577    11570       -7
- Misses       7651     7661      +10
+ Partials     3570     3567       -3

Flag
Coverage Δ

#unittests
50.75% <ø> (-0.04%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

libvcx/src/api/utils.rs
37.24% <0.00%> (-1.35%)
:arrow_down:

libvcx/src/lib.rs
33.39% <0.00%> (-0.10%)
:arrow_down:

libvcx/src/utils/libindy/payments.rs
42.98% <0.00%> (ø)

Continue to review full report at Codecov.

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


Improve shard resync

Scope & Purpose
We have observed that shards getting in sync (follower with leader)
quite often is very slow if there is significant write load on the
cluster. This PR strives to improve this by raising the priority of
requests needed for resync. Specifically, this is in the
RestReplicationHandler and the RestWalHandler for WAL tailing.
I have done some tests. I think this PR is good, but it will not be enough to let a follower catch up in good time, if we continue to write to the leader with multiple threads. This is due to the fact that catchup is inherently single-threaded. But this PR will already help a bit: For example, a collection can resync, even if we still write to a different collection, which was not the case before.
(Please describe the changes in this PR for reviewers, motivation, rationale - mandatory)

[*] :hankey: Bugfix
[*] :fire: Performance improvement

Checklist

[*] :book: CHANGELOG entry made
[*] Backports

[*] Backport for 3.8: This is the 3.8 backport

Link to original PR for devel: https://github.com/arangodb/arangodb/pull/16092/

We have decided to merge this backport only when no problems have been seen in devel for some time.


Reduce big-O of the conflict check to O(c)

The current conflict check needs to iterate through all hosts that are already in use and then also through those that are supposed to be used by the new ingress. No bueno and scales badly.
Instead, this keeps a set (lookup complexity O(1)) of all hosts already in use, which it updates on the usual add/delete events for a quicker (and more scalable) conflict check.

/lgtm


CASMCMS-8896 - changes for remote IMS jobs.

Summary and Scope
For IMS remote jobs, when the inventory container is complete, the ssh connection in the ansible container still does not work. I don't know what is still happening, but adding a 60 sec pause makes everything work.
I am NOT expecting this to be the 'final' fix. A better fix would be for the inventory container to do a full ssh test and wait for the connection to work. In the remote case there are really 2 ssh servers - one in the k8s job pod, and another on the remote node. They both need to be up and functioning before the complete ssh command work.
This PR is more a placeholder to talk about it, as well as documenting A way to make it work currently...
Issues and Related PRs

Resolves CASMCMS-8896

Testing
Tested on:

Mug

Test description:
Deployed the test image on Mug and changed the cfs-operator config map to use it. I then ran cfs image customizations with this ansible image and traced through the workflow - manually checking the results.

Were the install/upgrade-based validation checks/tests run (goss tests/install-validation doc)? N
Were continuous integration tests run? If not, why? N
Was upgrade tested? If not, why? N
Was downgrade tested? If not, why? N
Were new tests (or test issues/Jiras) created for this change? N

Risks and Mitigations
Very risky - need discussion with the friendly CFS folks.
Pull Request Checklist

[X] Version number(s) incremented, if applicable
[X] Copyrights updated
[X] License file intact
[X] Target branch correct
[ ] CHANGELOG.md updated
[ ] Testing is appropriate and complete, if applicable

Better solution in cfs-operator to check in the inventory container. Closing this PR.


Update to latest version of llvm/circt firtool

Hi,
There have been some bug fixes since the last version of firtool that was released on the Anaconda repo, which I need for Chipyard. Can you update firtool on Anaconda to 1.45.0? Or, better yet, is there a way to migrate the Anaconda publishing logic (which I assume is what this repo is for) to https://github.com/llvm/circt, so that they can automatically update the published package whenever they release a new version of firtool?
Thanks!

Sorry, I didn't get the notification for this. Next time feel free to ping me or create a pull request with the bump.

I just pushed a bump to 1.58.0 onto the master branch. It should be ready by EOD


JPL regression, possibly caused by cmake related changes

$ swipl
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.19-181-g0bab0134e-DIRTY)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.

For online help and background, visit http://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).

?- use_module(library(jpl)).
true.

?- jpl_terms_to_array([x, [1, a, 7, [y,z]], k, [], 3.14, foo(bar)], Array).
ERROR: Java exception: java.lang.UnsatisfiedLinkError: no jpl in java.library.path: [/Users/pmoura/lib/swipl/lib/x86_64-darwin, /Users/pmoura/Library/Java/Extensions, /Library/Java/Extensions, /Network/Library/Java/Extensions, /System/Library/Java/Extensions, /usr/lib/java, .]
^  Exception: (12) catch(jpl:jpl_set_instance(array(class([org, jpl7], ['Term'])), array(class([org, jpl7], ['Term'])), <jref>(0x7f8463c44fe0), 0, {x}), error(type_error(acyclic, _2354), context(jpl_datum_to_type/2, _2360)), jpl:throw(error(type_error(acyclic, _2354), context(jpl_set/3, _2360)))) ? abort
% Execution Aborted

Something to keep in mind :(  as is, how it is linked is very much in flux.  Works for me if I add the directory with libjpl.so to LD_LIBRARY_PATH (I think DYLD_LIBRARY_PATH on MacOS).

I'm unable to get it to work (tried both LD_LIBRARY_PATH and DYLD_LIBRARY_PATH). The odd thing is that, of the 11 Logtalk tests that require JPL, a single one fails. I have reduced the failed test to the queries above.

Link logic in MacOS is completely different from Linux ...  It is weird that this specific test fails though.  Let us first settle the rest.

I agree would be good to close the other issues, and then move to the new ones like this one.
Just for your info, I have a Linux box and I needed to add the paths to libjava.so and jvm.so to LD_LIBRARY_PATH  but even to load the library.
I also needed to have this LD_PRELOAD=libswipl.so but that is not your issue, it is complaining in not finding libjpl.so.

Just to confirm that with today's update to JPL, and with:
$ echo $LD_LIBRARY_PATH
/Users/pmoura/lib/swipl/lib/x86_64-darwin

$ echo $DYLD_LIBRARY_PATH
/Users/pmoura/lib/swipl/lib/x86_64-darwin

$ otool -L /Users/pmoura/lib/swipl/lib/x86_64-darwin/libjpl.so
/Users/pmoura/lib/swipl/lib/x86_64-darwin/libjpl.so:
	/Library/Java/JavaVirtualMachines/jdk-10.0.2.jdk/Contents/Home/lib/server/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0)
	@rpath/libswipl.7.dylib (compatibility version 7.0.0, current version 7.7.19)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)

I still get:
$ swipl
Welcome to SWI-Prolog (threaded, 64 bits, version 7.7.19-193-g2a9e328f2-DIRTY)
SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software.
Please run ?- license. for legal details.

For online help and background, visit http://www.swi-prolog.org
For built-in help, use ?- help(Topic). or ?- apropos(Word).

?- use_module(library(jpl)).
true.

?- jpl_terms_to_array([x, [1, a, 7, [y,z]], k, [], 3.14, foo(bar)], Array).
ERROR: Java exception: java.lang.UnsatisfiedLinkError: no jpl in java.library.path: [/Users/pmoura/lib/swipl/lib/x86_64-darwin, /Users/pmoura/Library/Java/Extensions, /Library/Java/Extensions, /Network/Library/Java/Extensions, /System/Library/Java/Extensions, /usr/lib/java, .]
^  Exception: (12) catch(jpl:jpl_set_instance(array(class([org, jpl7], ['Term'])), array(class([org, jpl7], ['Term'])), <jref>(0x7fd70053bed0), 0, {x}), error(type_error(acyclic, _2348), context(jpl_datum_to_type/2, _2354)), jpl:throw(error(type_error(acyclic, _2348), context(jpl_set/3, _2354)))) ?

I think it is fixed now.  The issue was caused by different ways in which cmake sets up search for dependent libraries that caused the JVM not to find libjpl.so/dll/...  There was an edit of LD_LIBRARY_PATH (Mac DYLD_LIBRARY_PATH) in jpl.pl claiming this would be used, but that is most likely only correct on Windows.  I now changed that to use the -Djava.library.path= JVM init option.  That fixed the issue on Linux.
On MacOS this appeared more complex because, although one is supposed to use .bundle or .so for native plugins, Oracle JVM doesn't seem to be looking for these.   So I changed the name back to libjpl.dylib and than added some magic to make Prolog look for both .so and .dylib on MacOS ...
Apple should compensate developers for torturing them ...
Please test and close if it works.

All the failures, both the regression I described above and the Logtalk Java unit test error, are now fixed. The only thing remaining to clean seems to be the deprecated item is not annotated with @Deprecated warnings at build time. Good work.

Incredible job Jan... @pmoura I will look at those missing deprecated items, we want zero warnings.


Update term import

Solve issues related to term imported from external resources
https://github.com/obi-ontology/obi/issues/1141 deprecated GO term
https://github.com/obi-ontology/obi/issues/1135 not registered REO terms

Thanks @zhengj2007. I noticed that REO:0000280 was still in obi-edit.owl, so I replaced it with OBI:0002744. I also added REO:0000171 and REO:0000280 to obsolete.tsv with their replacements noted, since OBI users may have used those terms.
Can you please double-check this for me?

Thanks @zhengj2007. I noticed that REO:0000280 was still in obi-edit.owl, so I replaced it with OBI:0002744. I also added REO:0000171 and REO:0000280 to obsolete.tsv with their replacements noted, since OBI users may have used those terms.
Can you please double-check this for me?

Looks good to me. Thanks!


Russian loc updates

Don't know why old fix was included too

New changes look good, merging now!


Changed the 1 invocation of pthread_setcancelstate() to pthread_se…

…tcanceltype().

This is to fix the issue of invalid arg to pthread_setcancelstate().

@josalem Can you help review this as well? I'm just being careful since I wasn't there when this was first implemented.

Also, who is going to merge this? I'm not authorized to do it.

This PR still has two pending reviewers which is why you cannot merge this.


Case classes / Records encoding

The curent implementation choose to encode case classes (records) as pure maps :

case class Address(street:String, cp:Int)
case class Person (name:String, age:Int, addr:Address)

Person("toto", 34, Address("chboing", 75009))  =>
    {"name" "toto", "age" 34, "addr" {"street" "chboing", "cp" 75009 }}

But a more classic way would be to use tagged map and to use keywords as keys  :
Person("toto", 34, Address("chboing", 75009))  =>
    #org.myns/Person {:name "toto", :age 34,
                      :addr #org.myns/Address {:street "chboing", :cp 75009 }}

;; `org.myns` is the package name of the class Person

see record clojure doc : https://clojuredocs.org/clojure.core/defrecord#example_5494d322e4b04e93c519ffaa

In : https://gist.github.com/ahoy-jon/dd555e133228c5037287#file-main-scala
obj, serialise to by default :
{"name" "yo", "addr" {"lat" 0.0, "lon" 0.0}}

Which might not be good enough compare to :
#yo.HelloEDN/Person {:name "yo", :addr #yo.HelloEDN/Address {:lat 0.0, :lon 0.0}}

Would it be possible to implement some strategies ? Like : TaggedRecords, UntaggedSomething ...

Interesting idea.
I think it is possible with a few more implicits... Let's study that!
What would be the default strategy BTW? I chose the dumbest approach with
maps & strings but maybe it's not the best one... a map with keywords could
also be nice for example.
On Fri, Jan 2, 2015 at 4:55 AM, Jonathan Winandy<EMAIL_ADDRESS>wrote:

In : https://gist.github.com/ahoy-jon/dd555e133228c5037287#file-main-scala
obj, serialise to by default :
{"name" "yo", "addr" {"lat" 0.0, "lon" 0.0}}
Which might not be good enough compare to :
#yo.HelloEDN/Person {:name "yo", :addr #yo.HelloEDN/Address {:lat 0.0, :lon 0.0}}
Would it be possible to implement some strategies ? Like : TaggedRecords,
UntaggedSomething ...
—
Reply to this email directly or view it on GitHub
https://github.com/mandubian/scaledn/issues/2#issuecomment-68507680.

For sure, Keywords should be used instead of Strings :

for the performance (you don't create a new keyword instance ideally when you parse, but use the interned value)
and for the semantic (keys are not just names as Strings, but a way to 'lookup' and extract part of the information).

As for tags, in Clojure, they are the default for records :
(ns yo.helloedn)

(defrecord Person [name addr])
(defrecord Address [lat lon])

(pr-str (Person. "yo" (Address. 0.0 0.0)))
;=> "#yo.helloedn.Person {:name \"yo\", :addr #yo.helloedn.Address {:lat 0.0, :lon 0.0}}"

Even if they are not supported by the included EDN reader !

;; Using the standard Clojure reader
(type (read-string  "#yo.helloedn.Person{:name \"yo\", :addr #yo.helloedn.Address{:lat 0.0, :lon 0.0}}"))
;=> yo.helloedn.Person

(require '[clojure.edn :as edn])

(edn/read-string "#yo.helloedn.Person{:name \"yo\", :addr #yo.helloedn.Address{:lat 0.0, :lon 0.0}}")
;=> java.lang.RuntimeException: No reader function for tag yo.helloedn.Address
;=>            EdnReader.java:729 clojure.lang.EdnReader$TaggedReader.readTagged

And they don't use slashes (#yo.helloedn/Person).
I think [1] the default strategy should be to have a default writer / reader supporting tagged records as Data encoded in this way can be easily decoded (and dispatched) after.
For writing, some advanced strategies could be to :

drop tags
tag transformation (val f: Named => Named =  _.copy(namespace = NS("yo")))

For reading, default should be to throw an exception (or equivalent mechanism) on unregistered tags.
Some other strategies cloud be to :

manage unknown tags with TaggedElement,
transform tag and dispatch to existing registred tag (val f: Named => Named =  .... )

[1] how can we check it's a good idea ?

Are softwares dealing with JSON using "tpe" mecanism (type information inlined (because preserving the existing JSON structure)) to encode the type  ?
package greet

case class Yo(greet:String)

toJson(Yo("yo"))

{"tpe": "greet.Yo",
 "greet":"yo"}

When you say:

for the performance (you don't create a new keyword instance ideally when you parse, but use the interned value)

For now, we do not manage an internal dictionary of known keywords while parsing. I think this is one feature to be added in the future.
Nothing prevents us from managing in the EDN reader:
(type (read-string  "#yo.helloedn.Person{:name \"yo\" :addr #yo.helloedn.Address{:lat 0.0, :lon 0.0}}"))

For Json type encoding, some do it, I'm sure (for RPC for ex) and actually when you want to encode ADT, I believe this is always better to have a type discriminator in your Json.

Nothing prevents us from managing in the EDN reader:

(type (read-string  "#yo.helloedn.Person{:name "yo" :addr #yo.helloedn.Address{:lat 0.0, :lon 0.0

Sure. I have to write more examples. The idea behind is : If you have ~20 case classes to map/read, it should be relatively easy to do.

So I managed to parse + validate this kind of struct  :
package yo

import scaledn._
import scaledn.parser._

import macros._
import shapeless._

import play.api.data.mapping._

import validate._

object walk {
   //TODO : Walk in shapeless  ??
   // Post-Order traversal
   def apply (f:Any=> Any, e:Any) : Any = {
   	val p = this.apply(f, (_:Any))
   	e match {
   	   	case l:List[_]   =>  f(l.map(p))
   	   	case l:Vector[_] => f(l.map(p))
   	   	case l:Map[_,_]  => f(l.map(t => (p(t._1),p(t._2))))
   	   	case _ => f(e)
   	   }
   }
}

object HelloEDN  extends App {
  case class Address(lat:Double, lon:Double)
  case class Person (name:String, addr:Address)

  val data = """#yo.helloedn/Person {:name "yo",
     :addr #yo.helloedn/Address {:lat 0.0, :lon 0.0}}"""

  def removetags(e:Any):Any = walk(x => x match {
  	case t:EDNTagged[_]  => removetags(t.value)
  	case _ => x
  }, e)

  def kwToStr(e:Any):Any = walk(x => x match {case EDNKeyword(value) => value.toString
  	                                          case _ => x}, e)

  println(parseEDN(data).map(removetags).map(kwToStr).map(validateEDN[Person]))
  // Success(Success(Person(yo,Address(0.0,0.0))))

}

One utility function could be tagwalk :
def tagwalk (f:EDNTagged[_]=> Any, e:Any):Any = walk( x => x match {
   case t:EDNTagged[_] => f(t.copy(value = tagwalk(f,t.value)))
   case _ => x
}, e)

val removetags = tagwalk(_.value, (_:Any))


Explore AppMaps page displays more than 5 SQL queries to explore

IntelliJ IDEA 2022.1.4 (Community Edition)
Build #IC-221.6008.13, built on July 19, 2022
Runtime version: 11.0.15+10-b2043.56 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 12.5.1
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 10
Non-Bundled Plugins:
appland.appmap (0.8.0-6)
Kotlin: 221-1.6.21-release-337-IJ6008.13
0.8.0-6 of the plugin
To recreate - clone the sample_app_6th_ed
Checkout the codespaces-devcontainer branch.
Related to https://github.com/applandinc/appmap-intellij-plugin/issues/108
After i manually index the appmaps and generate the selected code objects the explore appmaps page shows more than the top 5 sql queries.
VS Code:

Intellij: https://www.loom.com/share/cf06a4dd66ac4df69bd562f50036d74d

Should be fixed with 0.11.0-2, please reopen if it's still a bug on your machine.
https://github.com/applandinc/appmap-intellij-plugin/releases/tag/install-guide-preview


How to add negative samples for training

Thanks for sharing，
I want to add some negative samples as background training, how should I do it? Could you give me a detailed introduction?
I try to add some empty tag data to the training set and then train, is that ok？
Looking forward to your reply，Thank you

I do not know how to add neg when using default coco api, so I assume you are using the xml one. You can just add some data with a category of 'NegSample', which does not present in the class name list. When the the dataloader load a sample, whose category does not present in the class list, the dataloader will give a result with zero as its label ID(neg sample).

I do not know how to add neg when using default coco api, so I assume you are using the xml one. You can just add some data with a category of 'NegSample', which does not present in the class name list. When the the dataloader load a sample, whose category does not present in the class list, the dataloader will give a result with zero as its label ID(neg sample).

Thank you very much for your reply.
I used the coco format data made by myself. According to your suggestion, when I make coco format data, I can  add some data with a category of 'NegSample', which does not present in the class name list. will the data loader give a result with tag ID 0?Will it be trained as a negative sample?
Looking forward to your reply，Thank you!

Yes, I think it works. I am using my own json dataloader, but I made it following the xml dataloader.
In the following two pieces of code, you pass a sample with category of 'negsample'(the name could be anyone you want), the data processor returns an array of zero which means there is no target object in this frame, in other word this sample is an negative sample.
#  xml_dataset

for idx, xml_name in enumerate(ann_file_names):
            tree = ET.parse(os.path.join(ann_path, xml_name))
            root = tree.getroot()
            file_name = root.find('filename').text
            width = int(root.find('size').find('width').text)
            height = int(root.find('size').find('height').text)
            info = {'file_name': file_name,
                    'height': height,
                    'width': width,
                    'id': idx + 1}
            image_info.append(info)
            for _object in root.findall('object'):
                category = _object.find('name').text
                if category not in self.class_names:
                    logging.warning("WARNING! {} is not in class_names! Pass this box annotation.".format(category))
                    continue
                for cat in categories:
                    if category == cat['name']:
                        cat_id = cat['id']
                xmin = int(_object.find('bndbox').find('xmin').text)
                ymin = int(_object.find('bndbox').find('ymin').text)
                xmax = int(_object.find('bndbox').find('xmax').text)
                ymax = int(_object.find('bndbox').find('ymax').text)
                w = xmax - xmin
                h = ymax - ymin
                if w < 0 or h < 0:
                    logging.warning("WARNING! Find error data in file {}! Box w and h should > 0. Pass this box "
                                    "annotation.".format(xml_name))
                    continue
                coco_box = [max(xmin, 0), max(ymin, 0), min(w, width), min(h, height)]
                ann = {'image_id': idx + 1,
                       'bbox': coco_box,
                       'category_id': cat_id,
                       'iscrowd': 0,
                       'id': ann_id,
                       'area': coco_box[2] * coco_box[3]
                       }
                annotations.append(ann)
                ann_id += 1

# coco.py

if gt_bboxes:
            gt_bboxes = np.array(gt_bboxes, dtype=np.float32)
            gt_labels = np.array(gt_labels, dtype=np.int64)
        else:
            gt_bboxes = np.zeros((0, 4), dtype=np.float32)
            gt_labels = np.array([], dtype=np.int64)

Thank you again for your reply.
One more question: can the empty label mentioned on the Internet be regarded as a negative sample? That is, if there is the position of the target object, but the label is empty, Can we also think of it as a negative sample of training?

I think the answer is yes, if the label is "" in the annotation file. I don't know whether a file without a category is valid in the coco processor.  The data processor would treat is as negative sample, because "" doesn't present in the class list.

I think the answer is yes, if the label is "" in the annotation file. I don't know whether a file without a category is valid in the coco processor. The data processor would treat is as negative sample, because "" doesn't present in the class list.

Thank you for your reply and wish you all the best!


In addition to the specify by 'mapStateToProps', others actions will re-render component

For performance reasons, i use reselect.
There is a very serious problem for me.

The highlight log info is trigger by my component render is invoked.
When page initial work done, the component re-render 19 times...
And there are my code:
let mapToState = createSelector(
  [ (state, props)=> state.get(props.storeKey),
    (state, props)=> state.getIn([props.storeKey, 'meta']),
    (state, props)=> state.get(props.loadingKey || 'isLoading'),
    (state,props)=> props
  ],

  (source, meta, isLoading,props)=> {
    let res = {
      source: props.data(source.toJS()),
      meta: meta.toJS(),
      isLoading
    }
    return res
  }
)

export default connect(mapToState)(ReduxListView)

In addition to reducer handle user or guestModeInfo data, others reducer handle will re-render component...
For example,
There are 5 action,
UPDATE_USER
UDATE_GUESTMODEINFO
UPDATE_PROJECT
CREATE_MESSAGE
DO_SOMETHINGELSE

When reducer UPDATE_PROJECT CREATE_MESSAGE DO_SOMETHINGELSE be fired, the component will re-render.
But UPDATE_USER UDATE_GUESTMODEINFO reducer will be cached by reselect...

@jimbolla Thanks your answer!! In this component , your way is worked! But the most serious problem is on ReduxListView component, i change this issue , the example code is the selector of ReduxListView component.

This is a usage question, not a bug report. Please ask this on Stack Overflow. You'll have more people viewing the problem and will get better answers as a result.


0.60 release breaks groq/llama-3.1-70b-versatile due to max_completion_tokens

Describe the bug
Run pytest for test_agent.py or anything else that uses llama-3.1-70b-versatile through openai_gpt.py and it fails with:
unexpected keyword argument 'max_completion_tokens'
bug introduced by change in openai_gpt.py with version 0.60
To Reproduce
pytest -s tests/main/test_agent.py --nc --show --m groq/llama-3.1-70b-versatile
Expected behavior
Expected test to pass (with 1 warning), which it did with version 0.52
Desktop (please complete the following information):
OS: Debian 12 VM on Mac mini m2 pro
Additional context
If changing from max_tokens to max_completion_tokens is required for adding support to o1, then need to special case it for o1 and leave it alone for other models.

need to special case it for o1

ouch -- yes, they really made a mess with this o1 model, I had to tweak my code in a few places.
I'll patch it.

awaiting tests in PR #564

fixed in PR #564


A simple video would be more useful than the screenshots.

[Enter feedback here]

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

ID: 2d4a33b0-87d0-f60c-1b52-aeafa889e657
Version Independent ID: c281bdb7-c98c-6853-5077-41b3dd44d3a2
Content: Configure Azure Active Directory authentication - Azure SQL Database & SQL Managed Instance & Azure Synapse Analytics
Content Source: articles/azure-sql/database/authentication-aad-configure.md
Service: sql-db-mi
Sub-service: security
GitHub Login: @GithubMirek
Microsoft Alias: mireks

@cybersai29 Thanks for the feedback. This is being assigned to the content author to evaluate and update as appropriate.


why can't add Header to global env?

Describe the feature
I don't think I need a global variable setting, I just need a global header setting, and it is independent for each user. eolinker is easy to use because of this function.
Environment

版本: 0.5.1
Electron: 22.1.0
Chromium: 108.0.5359.179
Node.js: 16.17.1
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.22621
平台: Electron

同求，希望可以加一个全局header


Support badges and badge styling

https://twitter.com/ThePracticalDev/status/1297551421903077377?s=20
Saw this npm package and thought it's concept would be a great addition to this library. Is it doable? Appropriate? In scope?

@el2iot2 It would absolutely be doable and I have nothing against adding a "widget" that does this to the library.

This sounds fun. Do I understand correctly that this already could be done by using existing building blocks? We could make something more specific to draw badges. Could you please guide me, what is a good place to tackle this issue?


Compilation failure with NumPy 2.0.1

Trying to compile latest main (fb0caf6) with NumPy 2.0.1 fails when trying to compile numba/_helperlib.c:
numba/_helperlib.c: In function ‘numba_cpowf’:
numba/_helperlib.c:22:44: error: ‘I’ undeclared (first use in this function)
   22 |     #define _complex_float_ctor(r, i) (r + I * i)
      |                                            ^
numba/_helperlib.c:147:12: note: in expansion of macro ‘_complex_float_ctor’
  147 |     *out = _complex_float_ctor((float) _out.real, (float) _out.imag);
      |            ^~~~~~~~~~~~~~~~~~~
numba/_helperlib.c:22:44: note: each undeclared identifier is reported only once for each function it appears in
   22 |     #define _complex_float_ctor(r, i) (r + I * i)
      |                                            ^
numba/_helperlib.c:147:12: note: in expansion of macro ‘_complex_float_ctor’
  147 |     *out = _complex_float_ctor((float) _out.real, (float) _out.imag);

This is due to a change in NumPy 2.0.1 to #undef I to avoid causing problems with other libraries, such as SymPy which generates code from user input which may contain the variable I. See the following discussions:

Original bug report: numpy/numpy#26787
Pull request with the change: numpy/numpy#26789
A resulting bug report about compilation failure with some discussion about how to proceed: numpy/numpy#27083

To get numba to compile, changing
https://github.com/numba/numba/blob/fb0caf6b5a0ab00d0585cdc4aea25a0b35e3da22/numba/_helperlib.c#L22
to
    #define _complex_float_ctor(r, i) (r + _Complex_I * i)
(i.e., the original constant that glibc #defines I to) allows compilation. I am not sure if this is a globally safe change or if it would need to exist within an #if block to select the appropriate constant for an environment. For reference, I am using Arch Linux,  GCC 14.2.1, glibc 2.40.

I think #9683 is addressing this.


Unlock drive letter lock properly in dokan test

Otherwise, if we get a driver install error,
we will hang the test executable.

fyi @taruti


Fix non-HiDPI mode on HiDPI displays on macOS Catalina.

Fixes #32805
On macOS 10.15 HiDPI support is on by default, we need to directly specify we do not need scaling if HiDPI is not allowed by project settings.

Tested on MacBook Pro (Retina, Mid 2012) and it works perfectly. Thanks!

I recommend this patch to be put into the 3.2 milestone.

Thanks!

Cherry-picked for 3.1.2.

Cherry-picked for 3.0.7.

@bruvzg For the 2.1 branch only half of the patch applies properly (the added else branch). Do you think it's sufficient or are more changes needed there?

Do you think it's sufficient or are more changes needed there?

First part is to change scale on moving from one screen to another (having retina MacBook with non-retina secondary display is pretty common).

It's better to add whole if-else for the first part os_osx.mm#L340-L344 and the change in this line os_osx.mm#L348.

Second part is for the new window creation and should apply as is.

Thanks for the details! I wouldn't be able to test the changes myself beyond ensuring that it compiles, so if you're able to do and test the relevant cherry-picks for 2.1, that would be very helpful.
We don't necessarily need to backport full blown HiDPI support if it was lacking in the 2.1 branch, as long as we keep the current state working (so satisfying Catalina's new requirements).


Update regarding the url of downloading the pile dataset

The previous url of the pile dataset was not working , if the same happens with this url also , then just copy and paste this url in the website bar on google and a zip file will download of the dataset in your local machine , then we can work with it like any other dataset which is downloaded in json format in zip , using data files and load_dataset().

@lewtun please see to it.

@0xr4plh can you update and fix this please?
error during build:
ParseError: Cannot have an {:else} block outside an {#if ...} or {#each ...} block

@lunarflu , can you give the code , that produce the error?


Defer loading JS

We use this theme as the base for our custom Sphinx theme in the Dask project. We've noticed some render flicker when we load the page and form looking at the profiler this seems to be due to JavaScript resources being fetched and executed before the style sheets.
This PR adds the defer attribute to the script resources which will fetch them asynchronously and execute them once the rest of the page has finished loading. Alternatively the script tags could be moved to below other DOM resources.

Is your issue solved by #756?

That would help with the symptoms, but doesn't resolve the underlying issue.
Removing modernizr will make this issue less noticeable, but it will still exist on poor network connections and if child themes decide to include other large JavaScript resources through the script_files template variable.
Loading and executing JavaScript in the head, especially before CSS, is going to give users a worse experience generally.

I'll mark as needing some replication. I know this is an issue already however it might help to test this locally, with a RTD instance, where we might be introducing JS that could be incompatible with this change.

Yeah the only issue I can think of would be introducing other JS which depends on a script that has been deferred. It should also be deferred to ensure the correct loading order.
Let me know if there is anything I can do to help.

Unfortunately I don't think we can add defer to everything, some JS is not suitable for deferred loading.
The theme code can be deferredm but that bundles jQuery and we have had issues before when we moved jQuery out of the <head>, see #328. We had discussions on performance in #545.
Instead I think we should match what Sphinx does; when custom JS is added, it supports setting attributes (like defer) that end up in the HTML.
Docs: https://www.sphinx-doc.org/en/master/extdev/appapi.html#sphinx.application.Sphinx.add_js_file
Code: https://github.com/sphinx-doc/sphinx/blob/76e9f57c2e4457dec11d258435b7a6c6ec5de005/sphinx/themes/basic/layout.html#L92
Together with #756, that could solve most of the scripts in head. If not, then we may need a "put theme code + jQuery in head or not" config switch.

Yeah this was the issue I was talking about, if inline JavaScript depends on a library like jQuery then it can't be deferred like this.
Given the discussions in #545, which seem to roughly be "putting the JS in the head will be slow but more stable", it would be good to allow finer control with a config switch. That was a user can sacrifice the ability to use jQuery inline to get good performance.

The flicker issue seems mostly solved in my experiments in Firefox by just moving the CSS link tags above the JavaScript link tags.

Replaced by #853


Absolute paths in html field

Refs:
https://github.com/TryGhost/Ghost/issues/10466
https://github.com/TryGhost/Ghost/issues/1354
https://forum.ghost.org/t/json-file-from-ghost-1-to-ghost-2-help/5580
Introduced via https://github.com/TryGhost/Ghost/commit/a463a56971c5d39673e8b4f58502cf3fdeb2a46f.
Need to figure out if this behaviour is really broken or it was wishful from the beginning.
But the commit definitely changed a behaviour, which breaks an import/export flow.
This either needs to be handled differently for import/export, fix the html or documented correctly.

Previously:

you uploaded an image in the editor
it was returned relative and stored relative in the html field in the db
you served the post and the API automatically transforms asset paths to absolute
you export a JSON and import the JSON into a different domain, everything is fine, because paths are stored relative and served absolute

Now:

you uploaded an image in the editor
it is returned absolute and stored absolute in the html field in the db
you served the post and the asset paths are already absolute
you export the JSON and import the JSON into a different domain, everything is "broken", because paths are stored absolute, but domain might/has changed

Ghost: master/latest

Need to figure out if this behaviour is really broken or it was wishful from the beginning.
e.g. see https://github.com/TryGhost/Ghost/issues/9832

As summed up in https://github.com/TryGhost/Ghost/issues/10477, current behavior (returning absolute URL for /images endpoint) is correct. The transform needs to be applied to any asset in mobiledoc field (consequently html) containing absolute URLs to be changed into relative ones :+1:


Adding the french support

I have reflected it in the version of 2.0.5.
Thank you, have a good day!


Can't import pygrib

Whenever I attempt to import pygrib I get the error:
dlopen(/Users/usrname/anaconda/lib/python2.7/site-packages/pygrib.so, 2): Library not loaded: @rpath/./libgrib_api.1.dylib   Referenced from: /Users/usrname/anaconda/lib/python2.7/site-packages/pygrib.so   Reason: image not found
I was using it fine yesterday with zero issues. I'm on a Mac running OSX 10.10.5 and using Python 2.7.

Can't import pygrib:
ImportError: dlopen(/anaconda3/lib/python3.6/site-packages/pygrib.cpython-36m-darwin.so, 2): Library not loaded: @rpath/libjpeg.9.dylib
Referenced from: /anaconda3/lib/libeccodes.dylib
Reason: Incompatible library version: libeccodes.dylib requires version 13.0.0 or later, but libjpeg.9.dylib provides version 12.0.0
Mac OSX Mojave with Python 3.7
And anaconda:
active environment : base
active env location : /anaconda3
shell level : 1
user config file : /Users/deborahkhider/.condarc
populated config files : /Users/deborahkhider/.condarc
conda version : 4.5.11
conda-build version : 3.16.2
python version : 3.6.6.final.0
base environment : /anaconda3  (writable)
channel URLs : https://repo.anaconda.com/pkgs/main/osx-64
https://repo.anaconda.com/pkgs/main/noarch
https://repo.anaconda.com/pkgs/free/osx-64
https://repo.anaconda.com/pkgs/free/noarch
https://repo.anaconda.com/pkgs/r/osx-64
https://repo.anaconda.com/pkgs/r/noarch
https://repo.anaconda.com/pkgs/pro/osx-64
https://repo.anaconda.com/pkgs/pro/noarch
package cache : /anaconda3/pkgs
/Users/deborahkhider/.conda/pkgs
envs directories : /anaconda3/envs
/Users/deborahkhider/.conda/envs
platform : osx-64
user-agent : conda/4.5.11 requests/2.20.0 CPython/3.6.6 Darwin/18.2.0 OSX/10.14.1
UID:GID : 501:20
netrc file : None
offline mode : False


let content = std::fs::read(path).wrap_err!("Failed to read file {path}"))?;

...than:
let content = std::fs::read(path).wrap_err_with(|| format!("Failed to read file {path}"))?;

This might look like a small improvement, but considering how often error handling is required, and how important proper error handling is, I feel something like this would be a huge improvement (and I'm sure, there are other ways how postfix macros could improve error handling ergonomics).
Besides that, I believe, postfix macros would make it easier and nicer to experiment with new features before they are implemented in Rust.
For example, before the ? operator was added, there was the try macro. Wouldn't it have been significantly better to write:
File::create("my_best_friends.txt")
    .try!()
    .write_all(b"This is a list of my best friends.")
    .try!();

...instead of:
let mut file = try!(File::create("my_best_friends.txt"));
try!(file.write_all(b"This is a list of my best friends."));

?
Also, postfix macros would make every macro that depends on state nicer to use (obviously). For example, something like:
let result = db.query!("SELECT * FROM foo where bar = {bar}");

To be fair, nothing of the above is an earth-shattering improvement.
However, similar to how many small paper cuts can kill a person (or make Rust painful to use), I strongly believe that even a handful of applications of postfix macros could result in a disproportional amount of improvements in regard to ergonomics and expressiveness of Rust.
As I wrote above, even the tiny change of adding format argument interpolation was a huge win for me (I can't wait until we can use full expressions! :)).
Besides that, I think, postfix macros, in some cases, could lead to less code being put into macros.
For example, I'm pretty sure that some procedural attribute macros could be replaced with postfix macros.
So instead of e.g. the whole function being processed by a procedural macro, only a few selected expressions would be targeted by a postfix macro.
Sure, you then also could replace the procedural macro with a function-like macro, but I think many people don't want to do that, because function-like macros disrupt the flow of the code too much. Chainable postfix macros, however, often would be good enough for that.

Also, postfix macros would make every macro that depends on state nicer to use (obviously). For example, something like:
let result = db.query!("SELECT * FROM foo where bar = {bar}");

I have that exact problem in the hardware description language I've been building:
https://salsa.debian.org/Kazan-team/rust-hdl/-/blob/326abb7b71a3caf6e9181364598b5ea79daa0d66/examples/blinky.rs#L17
everywhere I want a HDL expression, currently I have to write:
val!(m, if overflowed { 0 } else { counter + 1 })

it'd be much nicer if I could write:
m.val!(if overflowed { 0 } else { counter + 1 })

another example of something that would become significantly nicer to use if we had postfix macro is write!
f.write!(...)

instead of
write!(f, ...)

which we have currently.
In general it makes to code more readable for any macro that has a main thing it operates on and then some arguments.

one potential downside I can see though is cluttering of autocompletion suggestions. But I guess we could just not include those in the suggestions.

Didn't see anyone else point this example out but just wanted to pile on another possible use case:
I want to log the variants of an error enum at different log levels (some errors are expected and fine, others are more serious). This has lead me to implement a fn log_level(&self) -> log::Level method on my errors so I can log them like this:
let request = { ... };
if let Err(e) = some_fallible_function(&request) {
    log!(e.log_level(), "An error occurred for {request}: {e}");
}

I would love to just be able to do e.log() and call it a day, but unfortunately I can't get the surrounding context or add any special-case message. However, with post-fix macros I could do it easily:
if let Err(e) = some_fallible_function(&request) {
    e.log!("An error occurred for {request}: {e}");
}

Even better, the log crate (or myself) could implement an extension trait to Result which would allow this:
let value = some_fallible_function(&request).log_err!("An error occurred for {request}: {e}")?;

Which saves me a few lines and some annoying nesting. You can emulate this currently with an identity .map_err which also performs a log but it's a lot more verbose.

So, I'm not a huge fan of macros, and try to avoid them when reasonably possible (both implementing, and using them), but sometimes they are by far the best solution.
I strongly believe postfix macros would increase the problem space where macros are the ideal option.
Some people seem to think, that this is exactly a reason to not implement postfix macros, but I disagree with that. Macros are sometimes the best (or even only) solution, which is the reason, why they were implemented in Rust – so why cripple them?

It might make code a little more elegant, but the difference for programmers overall is going to be tiny and marginal.

I feel expressiveness and ergonomics are a big problem for people that use Rust as a general purpose language (instead of just as a replacement for C). And improving expressiveness and ergonomics seems to be an important goal of the Rust leadership, at the moment.
Even the small addition of format argument interpolation felt like a huge win to me in this regard.
I believe postfix macros could open many opportunities that would result in significant improvements in regard to expressiveness and ergonomics.
For example, let's take eyre::WrapErr (a trait that can be used to add additional information to errors):
I'd much rather use:
let content = std::fs::read(path).wrap_err!("Failed to read file {path}"))?;

...than:
let content = std::fs::read(path).wrap_err_with(|| format!("Failed to read file {path}"))?;

This might look like a small improvement, but considering how often error handling is required, and how important proper error handling is, I feel something like this would be a huge improvement (and I'm sure, there are other ways how postfix macros could improve error handling ergonomics).
Besides that, I believe, postfix macros would make it easier and nicer to experiment with new features before they are implemented in Rust.
For example, before the ? operator was added, there was the try macro. Wouldn't it have been significantly better to write:
File::create("my_best_friends.txt")
    .try!()
    .write_all(b"This is a list of my best friends.")
    .try!();

...instead of:
let mut file = try!(File::create("my_best_friends.txt"));
try!(file.write_all(b"This is a list of my best friends."));

?
Also, postfix macros would make every macro that depends on state nicer to use (obviously). For example, something like:
let result = db.query!("SELECT * FROM foo where bar = {bar}");

To be fair, nothing of the above is an earth-shattering improvement.
However, similar to how many small paper cuts can kill a person (or make Rust painful to use), I strongly believe that even a handful of applications of postfix macros could result in a disproportional amount of improvements in regard to ergonomics and expressiveness of Rust.
As I wrote above, even the tiny change of adding format argument interpolation was a huge win for me (I can't wait until we can use full expressions! :)).
Besides that, I think, postfix macros, in some cases, could lead to less code being put into macros.
For example, I'm pretty sure that some procedural attribute macros could be replaced with postfix macros.
So instead of e.g. the whole function being processed by a procedural macro, only a few selected expressions would be targeted by a postfix macro.
Sure, you then also could replace the procedural macro with a function-like macro, but I think many people don't want to do that, because function-like macros disrupt the flow of the code too much. Chainable postfix macros, however, often would be good enough for that.

Maybe it was a mistake to add '?' to the language, since Postfix Macros (.try!) is arguably more appropriate (certainly more general) solution that doesn't involve additional syntax. Should the question mark operator be depreciated?

I strongly believe postfix macros would increase the problem space where macros are the ideal option.

Bear in mind that Mr. rust-analyzer himself lists macros as one of the big things that make it difficult to provide good IDE support.

Maybe it was a mistake to add '?' to the language, since Postfix Macros (.try!) is arguably more appropriate (certainly more general) solution that doesn't involve additional syntax. Should the question mark operator be depreciated?

It'd still be inappropriately verbose for its prevalence, even if ? didn't play more nicely with rust-analyzer.

Bear in mind that Mr. rust-analyzer himself lists macros as one of the big things that make it difficult to provide good IDE support.

While true, this also implies that the need for great IDE support has a higher priority than improving the ergonomics of using macros. I'm not certain that holds true in the general case; I can write Rust code without an IDE, but I would feel a terrible burden without macros at all. Given these two extremes, I honestly prefer macros.
Postfix macros would objectively improve ergonomics. For instance, postfix await syntax could have been prototyped with it, giving developers a chance to try-before-they-buy. Some very commonly requested features like keyword/named arguments can also be "hacked into the language" with postfix macros. One could even fake method overloading with them if they so desired.
I know the quote I'm responding to is not arguing against the ergonomics of postfix macros. I just want to shift focus back to why this RFC is so compelling.

One could even fake method overloading with them if they so desired.

That wouldn't solve the problem that prevents method overloading from being a core language feature.
The problem being that Rust is consciously designed with a "fearless upgrades" philosophy and method overloading is an API stability footgun because adding a new overload can cause type inference in downstream code to start failing.
No doubt why it typically occurs in languages that began without type inference and now have it being opt-in (eg. C++'s auto), rather than opt-out like Rust.

method overloading is an API stability footgun because adding a new overload can cause type inference in downstream code to start failing

That depends on what you mean by "method overloading".  If all the overloads have different arity, then it doesn't really cause any problems with inference. And in my experience the way macros are used for function overloading is typically for cases where you each "overload" (which in the case of a macro is actually a specific pattern) has a different number of parameters.

Would this allow me to transform something like
schema.object::<Pet>("Pet")
    .field!("name", |p| {
        ...
    })
    .field!("age", |p| {
        ...
    });

into
schema.object::<Pet>("Pet", |t| {
    t.field("name", |p| {
        ...
    };
    t.field("age", |p| {
        ...
    };
});

That is, use a sequential builder pattern to then collect all of those macro arguments into a single closure. I'm not sure if this is possible even with postfix macros, is it?

@satvikpendem: I don't think it would be wise to let postfix macros alter their left-hand expression (and I would be pretty astonished if people who decide if postfix macros are implemented think differently).
I think, the left-hand should have type expr, ident, etc., so that postfix macros can use what is to their left (i.e., no tt), but not alter it (I have never used procedural macros, so I'm not sure, if that would be even possible there).

As @NyxCode mentioned in the postfix match issue:
Would it be possible to add postfix macros on unstable, to be able to experiment with proposals like postfix match?
.await, ?, and the method chain syntax clearly demonstrate that postfix-based syntaxes can be beneficial. Therefore, it would be advantageous if experimentation with such syntax constructs is made easier on unstable.
Even if postfix macros are never stabilized, they would still be highly useful for such experimentation (and help avoid potential mistakes).

Currently working on (yet another) ECS library in Rust that's heavily generic- and macro-based. I would love to be able to do
world.ecs_query!(component_a, component_b, component_c)

instead of
ecs_query!(world, component_a, component_b, component_c)

especially when this query is part of a long chain.

@kevinushey Before I read this, on the contrary I was assuming that chained macros would be members. I come from a place where I need to add methods that can't currently be expressed as functions. The same goes for object.unwrap_or! { ... } which would only exist for Option and Result.
Maybe we can have it both ways, if this is feasible without rewriting the parser: when there are member macros they take precedence over free macros. And they apply only where implemented. With extended 2.0 syntax:
impl X {
    macro x0($self) { todo!() }
    macro x1($self, $x:expr) { todo!() }
    macro xn($self, ..) { // additional params below
        () => { todo!() },
        ($x:expr) => { todo!() },
        ($x1:ident $x2:tt) => { todo!() },
	}
}
trait Y {
    macro y0($self) { todo!() }
    macro y1($self, $y:expr);
    macro yn($self, ..); // additional params in impl
}

I'm suddenly looking forward to this feature, because I find it seems useful for simplifying optional parameters in macros.
In log crate, a full use example of a logging macro looks like this:
info!(target: "telemetry", user, ip, options = login_options; "user login to {}", platform);
//                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ key-values

Some other log crates may provide more optional parameters like the target here. If there is postfix macro support, this will make the code look super clean, and the parameters could be unordered.
info!("user login to {}", platform).target!("telemetry").kv!(user, ip, options = login_options);


added: used by website link

Thanks for the contribution, I appreciate it

unfortunately , we have nothing to do , Israel is committing genocide with the support of the western world, even Aid and our money can't reach out there that easily , all we could do is pray for them .

@Safouene1 I'm also so sad we're not able to do anything. please contribute to this project if you can i need someone to help me
link
Purpose
I'm launching this mission with my class fellows and friends here why we need to support them politically.
i wrote this for my country friends but you can still readit.
Mission: ONE WEEK FOR PALESTINE
Due to the ongoing war in Palestine, every human wants to help the Palestinian people. Everyone can assist them according to their circumstances and abilities. After three weeks of research, I found that supporting them politically, as a Pakistani, will be the most effective. You might argue, but I have reasons why!
There are a few methods through which we can support Palestine. I will attempt to prove that supporting them politically is the most effective approach.

Military Power: There is no doubt that the most effective way to support them is by sending our forces there. However, due to the current situation in Pakistan, we cannot make this possible since we are only a few individuals.

Financial Support: Supporting them financially is also a good approach, but I will place it as the second option. I'm not arguing that you should not provide them financial support. Even if someone donates 10 rupees for the sake of ALLAH, it will be accepted, Insha Allah. However, the reality is that they do not solely depend on our financial support because the UN provides them millions of dollars, which is much higher than what we could support. Again, I'm not saying you should not support them financially, but the point is that financial support is not enough from our side.

Political Support: During the war, every Western media outlet stands with Israel, displaying information that is not true. Even big tech companies like Google, Meta, and others are removing pro-Palestine content. They may not be removing all of it, but there is a threat that they might remove all. This is where we have to support them politically and educate the world about the current situation and history of Palestine.

Also can we we make a group where we can discuss about Palestine Support Projects maybe on discord | whatsapp | other


(change) Export kubernetes interface in kubernetes configmap retriever

Motivation

Currently the kubernetes configmap retriever only support to pass through rest.Config to it and resolve a clientset during retrieve, restConfig in kubernetes is generally hard to debug, and when something went wrong(nil pointer panic etc), seldom could we extract valuable information from it, while in current retriever example, rest.Config is the only exposed field and we need initialize kubernetes clientset during retrieve.
Requirements

update the kubernetesConfigRetriever from
// KubernetesRetriever is a configuration struct for a Kubernetes retriever.
type KubernetesRetriever struct {
	Namespace     string
	ConfigMapName string
	Key           string
	ClientConfig  restclient.Config
	client        kubernetes.Interface
}

into
// KubernetesRetriever is a configuration struct for a Kubernetes retriever.
type KubernetesRetriever struct {
	Namespace     string
	ConfigMapName string
	Key           string
	ClientConfig  restclient.Config
	Client        kubernetes.Interface
}

@ZhiHanZ I don't see the difference between the 2 versions of the KubernetesRetriever.

@ZhiHanZ I don't see the difference between the 2 versions of the KubernetesRetriever.

Oh I found the difference, you want to have the Client public?
Can you explain me what difference it makes for your usecase?

Exactly, actually this issue is quite strange, when I use in cluster rest Config directly in my k3d test cluster, the service crash with nil pointer panic, while I write my custom Retriever which adopt  kubernetes clientset, the panic disappeared, I think the root cause maybe some race condition during the runtime, here is my sample custom retriever snippet.
type DatabendConfigMapRetriever struct {
	Name      string
	Namespace string
	Key       string
	Client    kubernetes.Interface
}

func (s *DatabendConfigMapRetriever) Retrieve(ctx context.Context) ([]byte, error) {
	if s.Client == nil {
		return nil, fmt.Errorf("no such client")
	}
	configMap, err := s.Client.CoreV1().ConfigMaps(s.Namespace).Get(ctx, s.Name, v1.GetOptions{})

	if err != nil {
		return nil, fmt.Errorf(
			"unable to read from config map %s.%s, error: %s", s.Name, s.Namespace, err,
		)
	}
	content, ok := configMap.Data[s.Key]
	if !ok {
		return nil, fmt.Errorf("key %s not existing in config map %s.%s", s.Key, s.Name, s.Namespace)
	}
	return []byte(content), nil
}

Have you tried this example ?
I've done it with minikube and it is working fine on my side. I have no experience with k3s but could it be an issue with this implementation? It would be great if you were able to run the same example with k3s and see if you have the same issue.
By any chance do you have the stack trace of your panic ?
The example works fine, here I tried to replicate the problem but that disappeared. I would close the issue, thanks for your help!


One difference between a function and a lambda

Define a function with a given name.
The function behaves in the same way to the lambda used to define it, except that it “captures” return.
In other words, return will fall through lambdas not defined with fn, and continues until it exits a function defined with fn:

# good
seq 2 | each {|x| echo "x"$x}

# good
var y = {|x| echo "y"$x}
seq 2 | each $y

# not good
fn z {|x| echo "z"$x}
seq 2 | each z
# output
Exception: wrong type for arg #0: wrong type: need !!eval.Callable, got string

# not good
fn z {|x| echo "z"$x}
seq 2 | each $z
# output
compilation error: variable $z not found

Is it possible to reference a function directly in each?
If I'm missing any documentation, please give me a hint, thanks.
% elvish --version
0.18.0-dev.84b72af4ca3ff56233271807237126f4fbb3478c

The behavior of return is documented here and here.
Your seq 2 | each z example needs to be written as seq 2 | each $z~. The bare-word z in your version is syntatically the same as "z"; i.e., seq 2 | each "z". See also https://elv.sh/ref/language.html#variable-suffix.

@s5unty: You responded favorably to my previous comment. Is there anything else the Elvish community can help you with in regard to this issue? Are there still aspects of the current behavior that confuses you? If not you should probably close this issue.


[FeatureRequest] NS: WA (SC/GA) Addition

Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
The ability to view World Assembly Security Council & General Assembly resolutions via the Discord bot.

Initiate the commands !sc or !ga to get the latest current resolution at vote.
a. Or use the command !sc/ga ### to view stats about former resolutions.

Command gets and displays the following data with a nice design:
a. Name of current resolution
b. # of votes for/against
c. voting started and time remaining
d. category
e. person who proposed the resolution and their flag.

Use commands !sc/ga votes to get a quick list of top for/against votes by the delegates & individual nations.

Combine commands such as for example !sc 222 votes

P.S. Also see NationStates cog by Red DiscordBot as an example if possible. Should be open-source. All I've mentioned should be able to be gathered by the NS API.
Additional context
For more info, contact me and I will show an example of an already finished one in another server. Thanks.

@jlap1747 Would you be able to provide screenshots if possible ?

At the time, my request is no longer of the same importance or particularly needed. Other issues should be prioritized and therefore I am closing this issue at the request of @drehtisch.


Add antivirus mention to Failed to connect to Thunderstore. error

This (probably) works
Can double check later at home today if it's functionality is questionable, but as far as my code knowledge goes \n should also work here

I'm gonna close this PR for now until I have a proper solution ^^


Release 0.0.2

Coverage report

This PR does not seem to contain any modification to coverable code.


vuetorrent: 2.18.0 -> 2.19.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for vuetorrent is: Full-featured BitTorrent client written in Vue
meta.homepage for vuetorrent is: https://github.com/VueTorrent/VueTorrent
meta.changelog for vuetorrent is: https://github.com/VueTorrent/VueTorrent/releases/tag/v2.19.0
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.19.0 with grep in /nix/store/xdq48ff6fa6x5av4jwyvrf88ydf9rsql-vuetorrent-2.19.0
found 2.19.0 in filename of file in /nix/store/xdq48ff6fa6x5av4jwyvrf88ydf9rsql-vuetorrent-2.19.0

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

vuetorrent

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/xdq48ff6fa6x5av4jwyvrf88ydf9rsql-vuetorrent-2.19.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

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

Or:
nix build github:r-ryantm/nixpkgs/609295981c297e6dba1c11aa4986ed6a6635c99f#vuetorrent

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

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 1 package built:

vuetorrent

Maintainer pings
cc @redxtech for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


Speed up (w/ numpy)

Can we make SacreBLEU faster, possibly using numpy, multithreading or even GPU? And still keep it reliable and easy to install?
This issue should serve for sharing ideas and coordinating our efforts (PRs).
I am not aware of any particular numpy BLEU implementation. I just know (and I guess @mjpost too) that the chrF implementation in SacreBLEU is taken from Sockeye, but it uses List[float] instead of np.array. I am not sure whether this has any substantial impact on the speed.
I have not done profiling, but I guess most time is spent with the tokenization and maybe n-gram extraction and intersection, which could be substituted with Counter intersection similarly to the chrF implementation, supposing that Python3's Counter is C-optimized and faster.
Numpy can be useful if bootstrap resampling is added (cf. #40, #11).
The international tokenization has been optimized using lru_cache. However, there is still a cycle through all Unicode code points in _property_chars for each execution of sacrebleu, which could be prevented if adding the regex dependency (importing it conditionally, only if --tok intl required).

numpy maybe, I did have somewhere a preliminary stuff with numpy which very easily constructs the n-grams by playing with strides of an object tensor. But afterwards, the counting of n-grams etc. seemed to require going back-and-forth between numpy and python. Multi-processing can be useful for significance testing but I doubt that GPU would help =)

@martinpopel How does regex prevent the cycling through all Unicode codepoints? There's little documentation for regex, is it shipping a cached version of the codepoints?

@ozancaglayan
Currently we use something like (but @functools.lru_cache(maxsize=1) makes it even slower):
%timeit import unicodedata, re;
punct = ''.join([chr(x) for x in range(sys.maxunicode) if unicodedata.category(chr(x)).startswith('P')]);
r = re.compile(r'([^\d])([' + punct + r'])');
238 ms ± 8.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
￼
%timeit re.match(r, 'aa')
2.08 µs ± 99.1 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
￼
%timeit re.match(r, 'a.')
1.89 µs ± 28.3 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

By using regex we could make the initialization much faster at the cost of slightly slower runtime:
%timeit import regex; r = regex.compile(r'([^\d])(\p{P})')
1.54 µs ± 11.3 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

%timeit regex.match(r, 'aa')
5.44 µs ± 47.7 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
￼
%timeit regex.match(r, 'a.')
5.56 µs ± 115 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

We should benchmark both versions on typical file size, but (238ms -1.54µs)/(5.44µs-2.08µs) = 70k, so for use cases with lower number of match calls, regex should be faster.
Maybe we should give up readability (and the possibility of new Unicode versions defining new punctuation code points, but that would not be good for sacrebleu's replicability anyway) and come up with even faster implementation, e.g. something like:
%timeit punct = '!"#%&\'()*,-./:;?@[\\]_{}¡§«¶·»¿;·՚՛՜՝՞՟։֊־׀׃׆׳״؉؊،؍؛؞؟٪٫٬٭۔܀܁܂܃܄܅܆܇܈܉܊܋܌܍߷߸߹࠰࠱࠲࠳࠴࠵࠶࠷࠸࠹࠺࠻࠼࠽࠾࡞।॥॰૰෴๏๚๛༄༅༆༇༈༉༊་༌།༎༏༐༑༒༔༺༻༼༽྅࿐࿑࿒࿓࿔࿙࿚၊။၌၍၎၏჻፠፡።፣፤፥፦፧፨᐀᙭᙮᚛᚜᛫᛬᛭᜵᜶។៕៖៘៙៚᠀᠁᠂᠃᠄᠅᠆᠇᠈᠉᠊᥄᥅᨞᨟᪠᪡᪢᪣᪤᪥᪦᪨᪩᪪᪫᪬᪭᭚᭛᭜᭝᭞᭟᭠᯼᯽᯾᯿᰻᰼᰽᰾᰿᱾᱿᳀᳁᳂᳃᳄᳅᳆᳇᳓‐‑‒–—―‖‗‘’‚‛“”„‟†‡•‣․‥…‧‰‱′″‴‵‶‷‸‹›※‼‽‾‿⁀⁁⁂⁃⁅⁆⁇⁈⁉⁊⁋⁌⁍⁎⁏⁐⁑⁓⁔⁕⁖⁗⁘⁙⁚⁛⁜⁝⁞⁽⁾₍₎⌈⌉⌊⌋〈〉❨❩❪❫❬❭❮❯❰❱❲❳❴❵⟅⟆⟦⟧⟨⟩⟪⟫⟬⟭⟮⟯⦃⦄⦅⦆⦇⦈⦉⦊⦋⦌⦍⦎⦏⦐⦑⦒⦓⦔⦕⦖⦗⦘⧘⧙⧚⧛⧼⧽⳹⳺⳻⳼⳾⳿⵰⸀⸁⸂⸃⸄⸅⸆⸇⸈⸉⸊⸋⸌⸍⸎⸏⸐⸑⸒⸓⸔⸕⸖⸗⸘⸙⸚⸛⸜⸝⸞⸟⸠⸡⸢⸣⸤⸥⸦⸧⸨⸩⸪⸫⸬⸭⸮⸰⸱⸲⸳⸴⸵⸶⸷⸸⸹⸺⸻⸼⸽⸾⸿⹀⹁⹂⹃⹄、。〃〈〉《》「」『』【】〔〕〖〗〘〙〚〛〜〝〞〟〰〽゠・꓾꓿꘍꘎꘏꙳꙾꛲꛳꛴꛵꛶꛷꡴꡵꡶꡷꣎꣏꣸꣹꣺꣼꤮꤯꥟꧁꧂꧃꧄꧅꧆꧇꧈꧉꧊꧋꧌꧍꧞꧟꩜꩝꩞꩟꫞꫟꫰꫱꯫﴾﴿︐︑︒︓︔︕︖︗︘︙︰︱︲︳︴︵︶︷︸︹︺︻︼︽︾︿﹀﹁﹂﹃﹄﹅﹆﹇﹈﹉﹊﹋﹌﹍﹎﹏﹐﹑﹒﹔﹕﹖﹗﹘﹙﹚﹛﹜﹝﹞﹟﹠﹡﹣﹨﹪﹫！＂＃％＆＇（）＊，－．／：；？＠［＼］＿｛｝｟｠｡｢｣､･𐄀𐄁𐄂𐎟𐏐𐕯𐡗𐤟𐤿𐩐𐩑𐩒𐩓𐩔𐩕𐩖𐩗𐩘𐩿𐫰𐫱𐫲𐫳𐫴𐫵𐫶𐬹𐬺𐬻𐬼𐬽𐬾𐬿𐮙𐮚𐮛𐮜𑁇𑁈𑁉𑁊𑁋𑁌𑁍𑂻𑂼𑂾𑂿𑃀𑃁𑅀𑅁𑅂𑅃𑅴𑅵𑇅𑇆𑇇𑇈𑇉𑇍𑇛𑇝𑇞𑇟𑈸𑈹𑈺𑈻𑈼𑈽𑊩𑑋𑑌𑑍𑑎𑑏𑑛𑑝𑓆𑗁𑗂𑗃𑗄𑗅𑗆𑗇𑗈𑗉𑗊𑗋𑗌𑗍𑗎𑗏𑗐𑗑𑗒𑗓𑗔𑗕𑗖𑗗𑙁𑙂';
9.32 ns ± 0.171 ns per loop (mean ± std. dev. of 7 runs, 100000000 loops each)

%timeit '.' in punct
29.7 ns ± 0.351 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

%timeit 'a' in punct
69.9 ns ± 0.567 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

regex.compile(r'([^\d])(\p{P})')
I don't think this covers all punctuation classes but only P.

Puncts is small, symbols is huge, around 8K :) So we can't hardcode it, it'll be too ugly.

I did cache them using pickle in my WIP branch though, gave ~10% speedup after the cache is built.

I don't understand your last set of results where you simply check if something is inside a str. How would that integrate in our case?

I don't think this covers all punctuation classes but only P.

I don't understand which other classes of punctuation you mean. Unicode Category P includes all: connector Pc, dash Pd,
initial quote Pi, final quote Pf, open Ps, close Pe, other Po.
Of course, you may want to tokenize also on some other symbols, but that would not be compatible with mteval-v14.pl --international-tokenization, which is the whole point of sacrebleu --tok intl

Puncts is small, symbols is huge, around 8K :) So we can't hardcode it, it'll be too ugly.

Where do you need 8K symbols? In is_chinese_char? I did not consider that, although it could be perhaps optimized as well.

I did cache them using pickle in my WIP branch though, gave ~10% speedup after the cache is built.

I think using pickle for loading a string of 748 characters is an overkill, though still better than the current solution of iterating through sys.maxunicode (>1M) code-points.

I don't understand your last set of results where you simply check if something is inside a str. How would that integrate in our case?

We need just to check for a digit followed or preceded by a punctuation symbol and separate them with a space. So we could e.g. iterate over the string and when a digit is found, check is the previous or following character is a punctuation. Implementing this in C would be straightforward and faster than regexes (but less readable). In Python, it is more tricky because strings are immutable, but there may be some ways. That said, I think this discussion is an example of premature optimization (the root of all evil): 238 ms init time is surely not the biggest bottleneck in sacrebleu. We can replace UnicodeRegex.punctuation() implementation with punct = '!"#%&\...' and we are done. There is no need to be faster than re.sub.

So the current intl tokenizer, fetches all characters that has a category that startswith P for puncts, and S for symbols.
I initially thought that there is a P class on its own in the specs, but apparently not.
So this means that \p{P} probably encapsulates Pc, Pd, Ps, Pe, Pi, Pf, Po right? Current code gives me a length of 792 for this large string.
If you check the intl tokenizer, the same thing is done for symbols, i.e. S* classes. Now this is huge, around 7292 tokens, with all the emojis and so on. It's probably why computing BLEU with this tokenizer takes around 5.5 seconds for me. By caching that is down to 4.9. (See: $norm_text =~ s/(\p{S})/ $1 /g; # tokenize symbols in mteval)

regex brings a huge improvement to intl tokenizer, goes from ~4 secs to 0.9 on one particular cs-en test. What do you think on adding regex as a dependency to sacrebleu?
But more curiously, I don't seem to get the mteval-v14.pl -c --international-tokenization results exactly. There were no tests for this until I added one a couple of months ago, assuming that the current sacreBLEU at that time was OK. But maybe, since the beginning, the intl tokenizer was never producing same results as the Perl variant?
Looking at the code in Moses repo, I see more tokenization steps instead of the 3 regexps that we do for punctuations and symbols. I'll try to synchronise and see what happens.

If you check the intl tokenizer, the same thing is done for symbols, i.e. S* classes.

Oh, I see (I forgot, despite it was me who wrote the code).

Now this is huge, around 7292 tokens,

Yes. Now I remember, this was the reason, made the comment about regex.

What do you think on adding regex as a dependency to sacrebleu?

I don't see a reason why not. (There was a reason at the time when sacrebleu was a single script with no need to install.)

I prefer regex—the challenge is just to make sure it computes the same results.

Working towards significance tests these days, I noticed that the slowness of TER makes thing quite prohibitive when multiple systems are provided. I added multiprocessing support as well but, I wondered whether there would be a chance to numpy'ize the TER internals @ales-t and whether that would help?

@ozancaglayan Yes, TER is really slow and the main culprit is the edit distance calculation, which needs to be done many times for a single sentence. There are already some optimizations in place (without them, it would be essentially unusable) such as caching or "beam search".
The BeamEditDistance class uses quite inefficient data types (lists of str) so one step would be to represent the sentence as a (numpy?) array of vocab IDs and work with that.
But it would probably not be trivial to express the algorithm in terms of efficient numpy array/matrix transformations. Maybe the easiest way to speed it up would be to write the core routine (including "beam" and caching) in C. But it's just a guess.

Do you think this library would help for BeamEditDistance or is BeamEditDistance quite different than normal Edit/Levenshtein distance?
https://github.com/roy-ht/editdistance

I think it's too different. We need the backtrace (sequence of edit operations) and I believe that without the optimizations (cache+beam), even in C++ the algorithm would be too slow.


Error: [introspection-engine/connectors/sql-introspection-connector/src/introspection_helpers.rs:241:64] called Option::unwrap() on a None value  on cockroachdb

Command: prisma introspect
Version: 3.9.2
Binary Version: bcc2ff906db47790ee902e7bbc76d7ffb1893009
Report: https://prisma-errors.netlify.app/report/13667
OS: x64 linux 5.4.0-1067-azure
JS Stacktrace:
Error: [introspection-engine/connectors/sql-introspection-connector/src/introspection_helpers.rs:241:64] called `Option::unwrap()` on a `None` value
    at ChildProcess.<anonymous> (/<..>/node_modules/prisma/build/index.js:46439:30)
    at ChildProcess.emit (node:events:390:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)

Rust Stacktrace:
   0: user_facing_errors::Error::new_in_panic_hook
   1: user_facing_errors::panic_hook::set_panic_hook::{{closure}}
   2: std::panicking::rust_panic_with_hook
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:610:17
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:500:13
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:139:18
   5: rust_begin_unwind
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:498:5
   6: core::panicking::panic_fmt
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:107:14
   7: core::panicking::panic
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:48:5
   8: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   9: sql_introspection_connector::introspection_helpers::calculate_relation_field
  10: sql_introspection_connector::introspection::introspect
  11: sql_introspection_connector::calculate_datamodel::calculate_datamodel
  12: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  13: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  14: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
  15: <futures_util::future::future::Then<Fut1,Fut2,F> as core::future::future::Future>::poll
  16: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
  17: json_rpc_stdio::handle_stdin_next_line::{{closure}}
  18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  19: introspection_engine::main
  20: std::sys_common::backtrace::__rust_begin_short_backtrace
  21: std::rt::lang_start::{{closure}}
  22: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/ops/function.rs:259:13
      std::panicking::try::do_call
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:406:40
      std::panicking::try
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:370:19
      std::panic::catch_unwind
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panic.rs:133:14
      std::rt::lang_start_internal::{{closure}}
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/rt.rs:128:48
      std::panicking::try::do_call
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:406:40
      std::panicking::try
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:370:19
      std::panic::catch_unwind
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panic.rs:133:14
      std::rt::lang_start_internal
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/rt.rs:128:20
  23: std::rt::lang_start
  24: __libc_start_main
  25: <unknown>

This could in theory be https://github.com/prisma/prisma/issues/11866 - JS stacktrace matches.

Hi there,
As part of our effort to clean up our GitHub repo, we’re closing this issue to help focus on features and improvements that align with our focus areas and those of our community.
This issue was originally created for internal tracking purposes, but if you feel this is important to you, feel free to reopen the issue and get like-minded users to upvote as we will prioritize fixing issues based on community interest.
For more insight into our priorities and how we’re thinking about the future of Prisma, please see our blog post: https://www.prisma.io/blog/prisma-orm-manifesto.
Thank you for your understanding and support!


Directives in v-repeat are resolved into the component child scope with 0.12.5+

With Vue.js 0.12.5+, directives on transcluded content are compiled into the child scope if nested into a v-repeat directive.
Here a sample demonstrating the bug with Vue.js 0.12.6: http://jsfiddle.net/noirbizarre/6yy4zy2s/3/

This is a known issue and has been fixed in dev branch: #1010

Ok Thanks and sorry I didn't find it.


Stuck at "Got object store"

Steps to Reproduce
Recently I've been noticing Hive gets stuck at for example Got object store box in database box_settings.
This doesn't always happen, but enough to be noticed.
No other error messages are shown. After this message, nothing happens anymore, no other logs from the app. Since our app waits for the settings box, the entire app is stuck.
What fixes it is deleting the offending box in the browser's dev tools.
But obviously this is not a solution for non-dev customers using the website.
Is there anything I can do to fix/work around this?
Version

Platform: Web
Flutter version: 3.0.4
Hive version: 2.2.3 (Hive Flutter 1.1.0)

Loading app from service worker.
js_primitives.dart:47 Flutter Web Bootstrap: Auto
js_helper.dart:1852 [Violation] 'setTimeout' handler took 50ms
js_primitives.dart:47 Got object store box in database box_credentials.
js_helper.dart:1852 [Violation] 'requestAnimationFrame' handler took 86ms
js_helper.dart:1852 [Violation] 'requestAnimationFrame' handler took 69ms

same issue

same issue

same issue
@sgehrman @vixez @umaraqueli @daanporon @TitanKing any solution ?

same issue

Found the error! I suppose it means that you have those boxes. I was opening two boxes with one name.

Any solution so far?

same issue

i have flutter app and i use Hive local database but when i try run this app in chrom display this error
Got object store box in database config.
Got object store box in database favorite.
any solution ?

same issue


Android Icon can not be changed

Android Icon can not be changed

ToastAndroid doesn't support an icon unfortunately. https://reactnative.dev/docs/toastandroid

is there a way to style this toast for android. looking at the docs https://reactnative.dev/docs/toastandroid. seems like there is no way to style it


Change calling jsxKeyed bindings

This PR corresponds to the changes rescript-react binding https://github.com/rescript-lang/rescript-react/pull/74/commits/234798b97ecf6b1a979196c97f46a36d97361289 to make cleaner js output.

I've tested v3 and v4 classic and automatic, it works fine!


Research what's new w/Reading List on OS X "Mavericks"

I've no idea what changes are in store for Reading List in the next version of OS X. Please recall that readinglistlib is totally unsupported and works by reading undocumented files and is therefore likely to break with any OS update.
Ideally, "Mavericks" will include a proper [scriptable] read/write/delete Reading List API, dismissing the need for a hack like this altogether.

This suggested workaround didn't fix the problem. I commented out lines 84 & 85 in readinglistlib.py

    if None != dateformat:
       articles = map(self.formatDates, articles, [dateformat for i in range(len(articles))])

and was once again able to export my reading list to send to pinboard.


Build: publish packages using ESM and/or CommonJS

Which scope/s are relevant/related to the feature request?
Don't know / other
Information
Vite is moving towards ESM-only for Vite 5, which will break our usage of Vite node APIs with CommonJS. We also have some workarounds in the Nitro plugin for CommonJS support.
https://github.com/vitejs/vite/discussions/13928
This effort would:

Migrate the packages to be distributed using ESM and possibly CommonJS for Nx generators/executors.
Valid correct usage against publint.dev
Update Nitro plugin to be compliant

Describe any alternatives/workarounds you're currently using
Publishing
I would be willing to submit a PR to fix this issue

[ ] Yes
[ ] No

This is resolved in 1.0.0-beta.0 as we're publishing as ESM


[Discuss] what's the best working process to teach new users?

As someone who's been getting non-Git people into the prototyping kit, I've found the instructions on what to use to get started are a bit dev-heavy. I'd suggest changing them for non-devs:

Github Desktop for managing git. It's visual and does all the authentication stuff. You do need to remember to sync a branch before merging (and it doesn't really work offline, but never mind). My colleagues and I still use the command line for pushing to heroku, but it means it's just one line that they can copy-paste rather than loads.
Atom for code editing. Sublime is cool, but it's not free, and Atom is. As it's also from Github is also shows visually if you've worked on a page. It is a little more laggy than Atom, but I haven't had serious issues with it for prototyping.

My team have managed to pick it up really quickly, so I suspect others could too.

If you are using public Github you can set up Heroku to automatically pull
from a specific git branch whenever you commit. This means you can forget
about pushing to Heroku in your workflow.
Gav
On 6 July 2016 at 15:57, Vicky Teinaki<EMAIL_ADDRESS>wrote:

As someone who's been getting non-Git people into the prototyping kit,
I've found the instructions on what to use to get started are a bit
dev-heavy. I'd suggest changing them for non-devs:

Github Desktop https://desktop.github.com/ for managing git. It's
visual and does all the authentication stuff. You do need to remember to
sync a branch before merging (and it doesn't really work offline, but never
mind). My colleagues and I still use the command line for pushing to
heroku, but it means it's just one line that they can copy-paste rather
than loads.
Atom https://atom.io/ for code editing. Sublime is cool, but it's
not free, and Atom is. As it's also from Github is also shows visually if
you've worked on a page. It is a little more laggy than Atom, but I haven't
had serious issues with it for prototyping.

My team have managed to pick it up really quickly, so I suspect others
could too.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/alphagov/govuk_prototype_kit/issues/222, or mute the
thread
https://github.com/notifications/unsubscribe/AA1BpIJbveylACIw2vgNye_IGWVXN-J6ks5qS8JbgaJpZM4JGK1d
.

--
@gavinwye
07876441836
<goog_1941187581>
https://uk.linkedin.com/in/gavinwye

Would you be able to contribute docs on those? I don't think any of us here use them

I guess one aim of the current guidance is to present a clear and consistent set of docs that users can generally follow. I think it's easier to explain if we just have one main way of doing things. In prototype training, it's also helpful for everyone to be using the same thing.
That's not to say our current choices are correct though! I wonder if this should be split in to two issues: one for github desktop, and one for atom. We can then have discussions on each?

@edwardhorsford I think this would benefit from being separated out into two different subjects.
A thought on the Github desktop client.
This is all a means to an end. People should be concentrating on designing/building prototypes not learning new things.
Learning Git, Terminal, and other things is a daunting task. Using something like the Github desktop client introduces you to Git in a visual way that makes it easy to learn. I learned Git that way it also makes it easy to figure out some of the more advanced Git/Github concepts like branching, merging, and pull requests.
There is a layer of abstraction, but you can always go back and learn some of the complicated things that you can do via the command line once you understand the concepts.
Now I'm more of an advanced user I don't find the Github client that helpful and have progressed on to Git Tower. Unless I'd started there, I wouldn't know how to do the things I do like branching, tagging, pull requests without it.  Come to think of it I'm not sure I know how to branch in from the command line.
A thought on Atom
I've been using Atom since it was in beta, I'm an early adopter and jumped from Sublime Text primarily because it was new shiny and free. I still use Sublime for the things that I can't to in Atom. I think Sublime Text has better text manipulation capabilities.
Atom does require a lot of customisation out of the box. Some people may find that daunting. As a basic setup, I'd recommend just installing Emmet,   Git blame, and Minimap
I think the fact that both of these tools are free is also a good thing.

I was just going to submit a simple pull request to change the docs to suggest atom rather than SublimeText -- the text editor is the only non-free software (in both money and F/LOSS senses) that's linked to or recommended. Given the GDS principles on F/LOSS, I'd suggest that we not point people toward software they have to pay for, which raises another adoption barrier.
I just followed the newbie guide using a newly-downloaded version from atom.io and didn't have any problems -- not sure I'd agree that it needs much in the way of configuration. Let me know if you want the simple PR - it's just a trivial link change.

Would be interested in others' views. FWIW you don't have to pay for it, though it does nag you.
I think the reason we originally chose Sublime is because that's what the majority of people at GDS use and are familiar with. It's helpful when we teach the kit for people to be using the same thing. If most people are moving to Atom though, then we should consider it.

Well, non-free software is non-free, whether there's an extended trial or not. There are certainly a lot of GDS Sublime fans (including me!), but I've been getting more atom recommendations lately, and I don't think that we should push our users toward non-free software unless we clearly think it's technical superior.

I've switched to Atom and I think its better all round - eg much easier package installation interface.
However this bug has been open for ages and is really weird:
https://github.com/atom/atom/issues/5473
on balance though I think Atom is the better recommendation

Closing this for now.
We changed the text editor recommendation to Atom: #430
Still open to looking at other ways of managing Git, or even avoiding Git altogether (deploy from Dropbox for example). If anyone has good experience of alternative tools, feel free to open another issue or PR.


Add move-text

Add module for move-text.
Does not support evil visual. Plans are to fix at the source for evil support rather than make it doom specific.
Adds:

Meta-up move-text-up (line or active region)
Meta-down move-text-down (line or active region)
If evil:
Meta-k move-text-up (line)
Meta-j move-text-down (line)

For lack of evil support see this issue:
https://github.com/emacsfodder/move-text/issues/11

+1 for merging.

@bluesd  I didn't go for drag-stuff because it was another minor mode and I didn't know how to implement that properly with doom.
Try adding your solution to modules/config/default/+bindings.el where I added the others after move-text.

Can't this functionality be replicated using Evil-Exchange? Which is, in my opinion, a superior utility since it can even use text objects.

@nealot  I think you're right that you can replace it with Evil-Exchange. I was going for the meta-j feature similar to org-mode with ctrl-shift-j to move lines up and down quickly and visually. But I'm definitely going to start using evil-exchange!

Great then, how can I use it?
On May 12, 2018 6:20:23 PM GMT+01:00, Edmund Miller<EMAIL_ADDRESS>wrote:

@Dragnucs it actually works better if you don't use evil because moving
the region works.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/hlissner/doom-emacs/pull/562#issuecomment-388570005

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

@Dragnucs  I added a README https://github.com/Emiller88/doom-emacs/blob/develop/modules/tools/move-text/README.org

Sorry for taking so long to get to this. This PR has become a bit messy. In its current state I can't accept it. Please either rebase until only the pertinent commits remain, or recreate it. Alternatively, wait until the 2.1 release and I will incorporate a move-text module with evil support.

@hlissner I agree I'll close it.

@hlissner I agree I'll close it.


Use PaymentDetailCLILocal instead of GetPaymentDetailsLocal for chat listen --wallet notifications

We currently use a call to GetPaymentDetailsLocal to retrieve and format incoming payments when running keybase chat api-listen --wallet. This incoming data is a different shape than the data returned by keybase wallet api's details method, which uses PaymentDetailCLILocal. In the interest of consistency in our API and bots, it seemed to make sense to use PaymentDetailCLILocal for all API output.

Not sure why jenkins is failing, all tests seem to pass locally and even jenkins seems to show all checks

how much does this change the API of, for example, a normal completed payment?

@xgess Signature of PaymentLocal (current output):
  // Summary of a payment.
  record PaymentLocal {
    PaymentID id;
    TransactionID txID;             // For relay payments, the funding tx.
    TimeMs time;
    PaymentStatus statusSimplified;
    string statusDescription;       // "pending", "completed", "error", "claimable", "canceled"
    string statusDetail;
    boolean showCancel;             // true if cancel is an option for this payment
    string amountDescription;       // "1,323.1234567 XLM" - always amount of XLM, even if converted from OutsideCurrency
    BalanceDelta delta;             // NONE/INCREASE/DECREASE (e.g. INCREASE for "+ 1,323.1234567 XLM" amount above)
    string worth;                   // "$123.23 CLP", senders intended amount if this was made as a lumens-worth-currency payment
    string worthAtSendTime;         // "$123.23 CLP", amount in current user's display currency. Set if frontend should show an
                                    // (APPROXIMATELY $X.XX) message i.e. if this is a pure-XLM payment.

    string issuerDescription;       // For non-XLM assets: either "Unknown issuer" or domain name
                                    // ("example.com") if domain is verified by stellard.
    union{ null, AccountID } issuerAccountID;

    // What type to display the sender and recipient as.
    // Either neither or both are OWNACCOUNT.
    ParticipantType fromType; // cannot be SBS
    ParticipantType toType;

    string assetCode; // The code of the destination asset. e.g., "USD", "XLM", etc.

    AccountID fromAccountID;   // Always filled
    string    fromAccountName; // Optional. User's name for the account or Account ID if not named. Filled if fromType = OWNACCOUNT
    string    fromUsername;    // Optional. Filled if KEYBASE.

    union { null, AccountID } toAccountID; // Optional.
    string    toAccountName;               // Optional. Filled if toType = OWNACCOUNT
    string    toUsername;                  // Optional. Filled if KEYBASE.
    string    toAssertion;                 // Optional. Filled if SBS and statusSimplified != 'canceled'
    string    originalToAssertion;         // Optional. Username or SBS. Filled if statusSimplified == 'canceled'

    string note;                    // secret note
    string noteErr;

    // for path payments:
    string sourceAmountMax;
    string sourceAmountActual;
    Asset sourceAsset;
    string sourceConvRate; // The amount of the destination asset worth 1 unit of the source asset at the time of the transaction

    // for non-payment txs, multiple ops:
    boolean isAdvanced;
    string summaryAdvanced;         // if isAdvanced is true, just show this string
    array<string> operations;       // string summary of each operation in the transaction

    boolean unread;                 // true if user hasn't seen the payment yet (sourceType STELLAR only)

    string batchID;                 // if payment sent via batch, will contain the batch id
    boolean fromAirdrop;            // true if payment pertains to a keybase airdrop
    boolean isInflation;            // true if payment from known inflation source
    union { null, string } inflationSource; // name of inflation source

    union { null, PaymentTrustlineLocal } trustline; // this tx is only a trust line change.
  }

  // Details of a payment.
  record PaymentDetailsLocal {
    PaymentLocal summary;
    PaymentDetailsOnlyLocal details;
  }

  record PaymentDetailsOnlyLocal {
    string publicNote;              // public memo for the payment
    string publicNoteType;          // public memo type: "text", "id", "hash", "return"

    @lint("ignore")
    string externalTxURL;           // link to external web page with tx details
    string feeChargedDescription;   // "0.0000100 XLM" the actual fee that was charged for this tx (formatted)
    array<Asset> pathIntermediate;  // for payment paths, the additional hops it took
  }

  record PaymentTrustlineLocal {
    Asset asset;
    boolean remove;
  }

Signature of PaymentCLILocal (what this change does):
  record PaymentCLILocal {
    TransactionID txID; // For relay payments, the funding tx.
    TimeMs time;
    string status;
    string statusDetail;
    string amount;
    Asset asset;
    union { null, string } displayAmount;
    union { null, string } displayCurrency;

    string sourceAmountMax;
    string sourceAmountActual;
    Asset sourceAsset;

    // for non-payment txs, multiple ops:
    boolean isAdvanced;
    string summaryAdvanced;         // if isAdvanced is true, just show this string
    array<string> operations;       // string summary of each operation in the transaction

    AccountID fromStellar;
    union { null, AccountID } toStellar;
    union { null, string } fromUsername;
    union { null, string } toUsername;
    union { null, string } toAssertion;
    string note;
    string noteErr;
    boolean unread;

    // details
    string publicNote;              // public memo for the payment
    string publicNoteType;          // public memo type: "text", "id", "hash", "return"
    string feeChargedDescription;   // "0.0000100 XLM" the actual fee that was charged for this tx (formatted)
  }

So most of the same stuff is there, but it a different enough shape to break anything that currently uses it.

That being said, I think it's important we only have one payment shape in our api

the new format removes some potentially useful info (e.g. the two worth fields). i'm guessing since most of this is reusing the interfaces that currently exist between js and go, versioning just hasn't been necessary. but we should definitely think about a version before breaking this api. i do agree that it's unfortunate we're returning nearly identical data in two completely different formats, but we should try to reduce breaking this thing if it's going to become a real interface. this is probably more work that you want to do here. :/


IdentifierLoad Command throws error on non existing Identifier

When you run identifier:load artisan command with an Identifier name that does not exist, it throws an exception, would be better if it warned the developer about what is happening.

Issue resolved in commit 67f5c00


x/net/context: flaky test TestAllocs

The context.TestAllocs test is flaky on our jenkins continuous build. It seems to fail
more often when the machine is heavily loaded.

=== RUN TestAllocs
--- FAIL: TestAllocs (0.11 seconds)
	context_test.go:349: WithTimeout(bg, 1*time.Nanosecond) allocs = 8.000000 want 7

ribrdb: is this still an issue?  Since this report, there have been changes to TestAllocs to use a longer timeout and changes to AllocsPerRun in the testing package.  Since I don't have a way to reproduce this, I cannot easily determine whether those changes have resolved this.  Please reopen if so, ideally with reproduction steps.


Run Kubernetes workflow on gcp-large

Motivation
On GCP, we can control the machines that run the job better, with better isolation from other processes (e.g. in aio-max-nr).

Proposal
Run the Kubernetes tests on GCP instead of GitHub-provided runners.

Test Plan
CI.

Release Plan
None required: this is a CI-only change.
Links

reviewer checklist

@Twey @jvff Would it make sense to try this one again?