add a complexity check

Add this for checking the programmer's code complexity
https://www.npmjs.com/package/complexity-report

Is that much different from http://eslint.org/docs/rules/complexity?

I think it's the same thing under the hood

Do we have that already?

Yes, we would just need to turn on the rule.

Oh, cool. Is it facing the code of sane, or the code that the dev writes within the stack?

Code of SANE. ESLint runs as part of the mocha suite through mocha-eslint.

I see, what I mean here is to add the tool for the dev to tell them if their app's code is clean and testable or getting out of control. Would be a good feature of the stack. Seems like the escomplex does a pretty robust report. We can play with it and see how it goes. I think on the ember site it may have to become a ember-cli-plugin

I see.  Seems to me like it would be best as an addon, is that what you were thinking?

addon is probably best

Yep there is https://github.com/ember-cli/ember-cli/issues/3091 that I have looked into recently. I would actually prefer to have eslint over jshint on the ember-cli side, so having that as an addon would be great. And for sails we would just need a sails-hook-eslint which shouldn't be too hard to write.
Afterwards it would be equally easy to wrap this into a sane-addon.
Also @IanVS I think we should activate that for sane itself as well. Seems like a good measure.

Looks like ember-cli itself is using a tool called code climate for this if you look at their badges.

@mgenev Yep I was looking at that as well a couple of weeks ago. Unfortunately they don't support ES2015/ES7 properly yet. So delivers bogus results for at least the sane codebase.

@Globegitter, it looks like linting is now pluggable since https://github.com/ember-cli/ember-cli/pull/3122. I haven't looked into how to swap out JSHint yet, but I agree it would be nice to use ESLint throughout.

Just found one piece of the puzzle: https://github.com/jonathanKingston/ember-cli-eslint


NMDC documents should refer to NMDC schema terms by their names or their titles

Shared documentation and even informal communication between NMDC team members should refer to NMDC schema terms by their names or their titles
When team members have been referring to terms by something else (because the something else may be memorable or informative), that something else could be added to the term's aliases, or to the descriptive annotations on that term.
Consider the MIxS term below, from https://github.com/microbiomedata/nmdc-schema/blob/main/src/schema/mixs.yaml. It has name = 'abs_air_humidity' and title = 'absolute air humidity'. If it has been helpful to call that 'dankness', we could add that as an alias. There should never be a case when team members refer to a term by soemthign that can't be found verbatim in the schema. @cmungall , @sujaypatil96 and @turbomam can help with this.
slots:
  abs_air_humidity:
    name: abs_air_humidity
    aliases:
    - absolute air humidity
    annotations:
      expected_value:
        tag: expected_value
        value: measurement value
      preferred_unit:
        tag: preferred_unit
        value: gram per gram, kilogram per kilogram, kilogram, pound
      occurrence:
        tag: occurrence
        value: '1'
    description: Actual mass of water vapor - mh20 - present in the air water vapor
      mixture
    title: absolute air humidity
    examples:
    - value: 9 gram per gram
    from_schema: http://w3id.org/mixs/terms
    source: http://w3id.org/mixs/terms
    see_also:
    - https://github.com/microbiomedata/nmdc-schema/blob/issue-291-mixs-submod/util/rebuild_mixs_yaml.py
    is_a: attribute
    slot_uri: MIXS:0000122
    multivalued: false
    range: quantity value

see also

#1170
#1119


The python package includes the tests directory

The line:
https://github.com/E3SM-Project/e3sm_diags/blob/14d7c969305098f0a3ea582ad6a3395c864ae558/setup.py#L118
seems designed to exclude tests but it doesn't actually have the tests directory in its excludes.  As a result, it ends up in the conda package and it conflicts with other packages that make the same mistake (e.g. zppy and zstash).
Instead, it would be much cleaner and safer to do:
packages=find_packages(include=['acme_diags', 'acme_diags.*'])

Hey @tomvothecoder would you please also help fixing this?

Sure thing, I'm helping out Ryan on the same issue on zstash so I'm familiar with it.


vocals repeating at the end of a song

Describe your problem here.
So I'm having an issue where some of the song's vocals start repeating at the end of the song for a little bit and then the i get sent to the menu how do I stop the song from repeating in both Lua and Source
https://github.com/ShadowMario/FNF-PsychEngine/assets/95887947/a96e4625-eea6-4056-9b0a-169bf6315284
Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows x64
Did you edit anything in this build? If so, mention or summarize your changes.
no i just added a song and finished charting it

add some empty thing to ur voices that makes same duration with inst

add some empty thing to ur voices that makes same duration with inst

oh ok. ill bring it up to our song writer and see if that fixes it

add some empty thing to ur voices that makes same duration with inst

Thank you so much! it worked!

Doesn't work anymore :/


Issue when installing clickhouse on spesific namespace

I try to run this command and got error
curl -s https://raw.githubusercontent.com/Altinity/clickhouse-operator/master/deploy/operator-web-installer/clickhouse-operator-install.sh | OPERATOR_NAMESPACE=test-clickhouse-operator sh
errors :
Setup ClickHouse Operator into 'test-clickhouse-operator' namespace
No 'test-clickhouse-operator' namespace found. Going to create
namespace "test-clickhouse-operator" created
sh: line 117: syntax error near unexpected token `('
sh: line 117: `kubectl apply --namespace="${OPERATOR_NAMESPACE}" -f <( \'

please help

@rizkyekoputra, try it (bash instead of sh)
curl -s https://raw.githubusercontent.com/Altinity/clickhouse-operator/master/deploy/operator-web-installer/clickhouse-operator-install.sh | OPERATOR_NAMESPACE=test-clickhouse-operator bash

got another errors after I run this:
➜  clickhouse curl -s https://raw.githubusercontent.com/Altinity/clickhouse-operator/master/deploy/operator-web-installer/clickhouse-operator-install.sh | OPERATOR_NAMESPACE=test-clickhouse-operator bash
Setup ClickHouse Operator into 'test-clickhouse-operator' namespace
Namespace 'test-clickhouse-operator' already exists
Looks like clickhouse-operator is not installed in 'test-clickhouse-operator' namespace. Going to install
error: SchemaError(io.k8s.api.core.v1.PersistentVolumeClaimStatus): invalid object doesn't have additional properties

this is my kubectl version
➜  ~ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:38:32Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.10-gke.36", GitCommit:"34a615f32e9a0c9e97cdb9f749adb392758349a6", GitTreeState:"clean", BuildDate:"2020-04-06T16:33:17Z", GoVersion:"go1.12.12b4", Compiler:"gc", Platform:"linux/amd64"}

nvm, it's solved by updating kubectl client version


Add remote address to connect exception

Today when timing out a connection the exception message is not populated. This is not helpful for end users. This commit adds an exception message that indicates the cause of the connect exception is a timeout to the remote address.

Sounds reasonable to me. @ok2c ?

@jasontedor @garydgregory Works for me.

I committed this PR with some minor changes to the branch 4.4.x. Please verify and close.


Simple shapes are sharing the same properties [XSSF]

I'm trying to create multiple shapes on my sheet, but they seem to share the same properties (the last set).
XSSFClientAnchor a = new XSSFClientAnchor(100000, 20000, 450000, 240000, 3, 8, 3, 8);
XSSFSimpleShape shape1 = pat.CreateSimpleShape(a);
shape1.SetFillColor(100, 100, 255);
shape1.SetLineStyleColor(0, 0, 0);
shape1.SetText("A");
shape1.LineWidth = 1;
// ...
XSSFClientAnchor a2 = new XSSFClientAnchor(100000, 20000, 450000, 240000, 5, 8, 5, 8);
XSSFSimpleShape shape2 = pat2.CreateSimpleShape(a2);
shape2.SetFillColor(255, 100, 100);
shape2.SetLineStyleColor(0, 0, 0);
shape2.SetText("B");
shape2.LineWidth = 1;

Result:

Both shapes were set with the text "B" and the color red, although the text for the first one clearly should be "A" and its color should be blue.
I've tried using the same Drawing Patriarch for both shapes and I've tried using separated Drawing Patriarchs for each shape, but I get the same result in both cases.

This issue has been fixed by @antony-liu
https://github.com/nissl-lab/npoi/blob/60176aa5915a026c2db49b97825555be2561e2e7/ooxml/XSSF/UserModel/XSSFSimpleShape.cs#L80


Complete exercise for day 9

error: pathspec 'feature/day-9' did not match any file(s) known to git

error: pathspec 'feature/day-9' did not match any file(s) known to git

I may have created the branch after you pulled the project the first time, try doing git pull and then checkout again, and let me know if it works then.

Welcome to the secret auction program.
What is your name?: w
What's your bid?: $-1  ## allowing a negative bid number, free & making $ HAHA
Are there any other bidders? Type 'yes' or 'no'.
no
The winner is  with a bid of $-1.      ## winner name is empty for this particular one


the /etc/broker.xml is not merged with /etc-override/broker-00.xml

Dear Developers,
I'm using vromero/activemq-artemis:2.3.0-alpine (and tested also vromero/activemq-artemis:2.6.0-alpine)
minikube version: v0.27.0 (and tested also 0.26.1 and 0.25.2)
A few weeks ago the minikube yaml works correctly and the artemis pod was created with the queues were deployed when starting up the pod.
If I  now log into the artemis-0 pod and navigate to /var/lib/artemis/etc-override the broker-00.xml is present.
and if I navigate to /var/lib/artemis/etc/broker.xml I see that the broker-00.xml was not merged with this file. This used to be the case. So when deploying the pod the queue were also deployed and then can be used.
the top part of the broker-00.xml is:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configuration xmlns="urn:activemq" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:activemq /schema/artemis-configuration.xsd">

<core xmlns="urn:activemq:core" xsi:schemaLocation="urn:activemq:core ">
    <security-settings>
       <security-setting match="#">
          <permission type="createNonDurableQueue" roles="amq"/>
          <permission type="deleteNonDurableQueue" roles="amq"/>
          <permission type="createDurableQueue" roles="amq"/>
          <permission type="deleteDurableQueue" roles="amq"/>
          <permission type="consume" roles="guest"/>
          <permission type="send" roles="guest"/>
          <!-- we need this otherwise ./artemis data imp wouldn't work -->
          <permission type="manage" roles="amq"/>
          <!-- the indexer must be able to browse the queue -->
          <permission type="browse" roles="amq"/>
       </security-setting>
    </security-settings>

    <addresses>
        <address name="DLQ">
          <anycast>
             <queue name="DLQ"/>
          </anycast>
        </address>
        <address name="ExpiryQueue">
          <anycast>
             <queue name="ExpiryQueue"/>
          </anycast>
        </address>

        <address name="accessQueue">
          <anycast>
            <queue name="accessQueue">
               <durable>true</durable>
            </queue>
          </anycast>
        </address>

Do you need more information, then please contact me?
I hope you can provide a solution for this problem.
Kind regards,
Egbert

Umm, that is ackward. Can you reproduce just using docker?
Also could you cat /var/lib/artemis/etc/broker.xml and share here?

/var/lib/artemis/etc $ more broker.xml

<IP_ADDRESS>
true

ASYNCIO
./data/paging
./data/bindings
./data/journal
./data/large-messages
true
2
-1

                         list>http://www.apache.org --More-- (24% of 8452 bytes)

-1
10
PAGE
true
true
true
true

DLQ
ExpiryQueue
0

-1

                      tory-day-limit>10</message-counter-history-day-limit--More-- (92% of 8452 bytes)

    <address-full-policy>PAGE</address-full-policy>
    <auto-create-queues>true</auto-create-queues>
    <auto-create-addresses>true</auto-create-addresses>
    <auto-create-jms-queues>true</auto-create-jms-queues>
    <auto-create-jms-topics>true</auto-create-jms-topics>
  </address-setting>
</address-settings>
<addresses>
  <address name="DLQ">
    <anycast>
      <queue name="DLQ"/>
    </anycast>
  </address>
  <address name="ExpiryQueue">
    <anycast>
      <queue name="ExpiryQueue"/>
    </anycast>
  </address>
</addresses>

/var/lib/artemis/etc $

please click edit to view the correct cat the presentation is incorrect of the cat of the broker.xml

This should work (there is even a test for it). Can I ask you one more thing:
please execute: docker system prune --all -f and then write here step by step how to reproduce with just docker.

I tested this manually and seems to work, I'm closing this. Please reopen if you can reproduce as requested.

A collegae fixed it for me.
The problem was that kubernetes now uses symbolic links for config maps, he fixed it in the kubectl yaml by making volume mounts.
I'm not sure whether you understand this explanation but you are correct the problem was not in artemis code.

I do, thanks, that is helpful.


Branch with hardhat on the side of foundry for integration testing

It would be great to have branch that integrates hardhat into this foundry template, to leverage strengths of both tools.
Hardhat for example helps on integration testing or deployment management.

I agree that this would be nice.
I'm not familiar with Hardhat anymore, and I don't have the bandwidth to work on this in the near future, but PRs are welcome.


Package facades and client apps

This PR:

Hides entity types under package façades.
Gathers client apps under the client directory.

Codecov Report

Merging #115 into master will increase coverage by 6.82%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #115      +/-   ##
============================================
+ Coverage     85.53%   92.36%   +6.82%
============================================
  Files           109       35      -74
  Lines          2365      563    -1802
  Branches         77        9      -68
============================================
- Hits           2023      520    -1503
+ Misses          322       36     -286
+ Partials         20        7      -13


Question about budget closure rule

The documentation says this:

Which model specification parameter do I use to switch from option 1 to option 2?

@martinholmer. We don't currently have the functionality to do option 2 or 3 for a closure rule. The only stabilization policy (closure rule) right now in OG-Core or any of its country calibrations is to change G_t to hit a long-run debt-to-GDP ratio. I will update the documentation to reflect the "in-process" nature of options 2 and 3. Thanks for catching that.
However, you can flexibly change the date at which the closure rule begins tG1, the date at which the closure rule is forced to exactly hit the long-run debt-to-GDP ratio tG2, and the rate of convergence rho_G to the long-run debt-to-GDP ratio between dates tG1 and tG2.

@rickecon said:

We don't currently have the functionality to do option 2 or 3 for a closure rule. The only stabilization policy (closure rule) right now in OG-Core or any of its country calibrations is to change G_t to hit a long-run debt-to-GDP ratio. I will update the documentation to reflect the "in-process" nature of options 2 and 3. Thanks for catching that.

OK, thanks for the clarification.

@rickecon said:

However, you can flexibly change the date at which the closure rule begins tG1, the date at which the closure rule is forced to exactly hit the long-run debt-to-GDP ratio tG2, and the rate of convergence rho_G to the long-run debt-to-GDP ratio between dates tG1 and tG2.

But none of these three parameters will change the steady-state equilibrium, right?
If I'm wrong about that, please explain.

@martinholmer. You are right that the parameters tG1, tG2, and rho_G do not influence whether or not the steady state solves. However, the long-run assumption about the debt-to-GDP ratio alpha_D in the documentation (debt_ratio_ss in the model) does matter for the steady state.

This issue is resolved by PR #784. Closing.


test Helm chart refactor + document as needed

A community member has refactored the Helm charts to add various improvements.
https://github.com/helm/charts/pull/18993/files
This may impact our documented guidance and/or examples when using Helm:

--set commands will no longer work, as parameters have changed to conform to the Helm standard. Instead, we should instruct users to create a custom .yaml and use the --values flag to override the defaults.

Relates to #5931
Note: The chart version has been updated to 3.0.0 but this is not related to the Helm 3.0 update.

The helm instructions on the secure install appear to be incorrect now.
https://github.com/cockroachdb/docs/blob/master/_includes/v20.1/orchestration/start-cockroachdb-helm-secure.md
At a minimum the helm instructions now leave you with an insecure instance.  It appears tls.enabled needs to be set to true.  Still doing an initial eval of cockroach so I am unsure of other settings.

@randmark, this is the issue we were talking about. @taroface, we should prioritize this over the next few weeks given our secure instructions result in an insecure cluster.

This is addressed in https://github.com/cockroachdb/docs/pull/6121


fix login in non-array branch of conditional for parsing

additional fix for https://github.com/alex94puchades/superagent-jsonapify/pull/8

logic, not login ... sorry

Hi @winglian! Thank you for your PR, I'm sorry it took me so long to see this :sweat_smile:


rework null handling in FromProtoValueCodecs

improve handling of null (unset) values returned from gRPC API in SGv2 REST API service.

Looks good, makes sense.


Release 2.1.2

Noticed that the fix for #296 #312 hasn't been released since it was landed in December. Any chance of cutting a new release and deploying it to the jenkins plugin repo?

Yeeeah, that would be great.
The #296 is really annoying.

New release: yes please :)

new release, yes please :), #296 is definitely annoying.

Any chance for a new release?

Actually, it seems v2.1.2 was already released! So this issue can be closed.


Unable to override defaults with az postgres down

Used az postgres up overriding default group and location but az postgres down doesn't accept these arguments and uses default group

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

ID: e5fd0414-755e-459e-85bc-ef3fcd31432b
Version Independent ID: ad239037-3b15-1acf-d08d-fe20d31110c6
Content: az postgres
Content Source: latest/docs-ref-autogen/ext/db-up/postgres.yml
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

Thank you for your feedback @duncanjw.
Adding @yugangw-msft @achandmsft to review.

@achandmsft and Lomis for follow up

add to S173

I believe this is still on-track for yonzhan's team's s173

Hi @duncanjw, we are fixing the issue you raised.
@rachel-msft Here is our new design for az postgres down.

If customers specify --resource-group or --server-name, we will crash the specified server.
If none of them, we will try to find server name in cache , clear cache and delete specified server.
In addition, if users specify --delete-group, all resources in resource group will be deleted

Thanks @Juliehzl. And by "we will crash the specified server", I'm guessing you mean delete.

@rachel-msft yes, you are correct.


A double quote in a filter value causes crash

Because the filter verification attempts to CSV parse the value (even if it is not a legal CSV string) it crashes upon being supplied a double quote.
The problem has been added as an integration test case in a PR https://github.com/cerebris/jsonapi-resources/pull/629/files
... which can be run using...
bundle exec rake test TEST=test/integration/requests/request_test.rb TESTOPTS="--name=test_filter_with_value_containing_double_quote -v"

A potential solution has also been supplied in that PR - rescuing the resulting "Malformed CSV" error. Rescuing is less desirable than checking for the validity of the CSV string upfront but AFAIK the latter is not possible. If the added code fails to parse the CSV then it simply treats it as a scalar value.
One thing this workaround does not handle is presence of multiple comma delimited double quotes in the filter value, eg.
filter_value = '",","'

I don't have a full understanding of the requirements for comma delimited arguments supplied to jsonapi-resources in a filter - do they need to be valid CSV or is this just how jsonapi-resources implements a comma delimited filter value?  I may have completely misunderstood the rules on jsonapi filter values.
Also the added test case only asserts that the server does not blow up when supplied a double quote as an argument. A better test case to actually retrieve a resource with a double quote in the filtered attribute would be required if this approach is in the right direction.

The spec leaves it up to the implementation as to how to process the filters.
I'd like to consider some alternatives instead of handling the exception and then reverting to treating it as a string. We could have a setting for how to treat id based filters and other filters. By default the ids would use CSV and regular filters would be strings or hashes. We could allow this to be set per filter as well. I'll try to get something together soon.

Sounds good. I agree with your initial thinking about treating id based filters and regular filters differently.

Was progress ever made on this, or is there a known workaround?  This is really frustrating our fulltext search, since users love to use double quotes in searches...

@NuckChorris Could you please try out  #937. It's against master, but there aren't too many differences with beta.


Typo in repo name

This repo is called "phasereditor2d-scrips-audio" - where "scrips" was probably supposed to be "scripts".

God! Thanks!


Recognition using ensemble learning

Is your feature request related to a problem? Please describe.
Adding facial recognition using ensemble learning
Describe the solution you'd like
Ensemble learning uses OpenFace, DeepFace, FaceNet and VGG-Face to recognize faces more effectively.
Approach to be followed (optional)
The image will be trained using the four combined models and Cosine, Euclidean, Euclidean L.2 will be taken to accurately predict 2 faces. It can also predict if a given face is in a folder.
Please attach SWOC label in this issue. Thanks in advance.

hi thankyou for generating the issue!
Are you a dwoc participant?

hi thankyou for generating the issue!
Are you a dwoc participant?


chore(backend): allow sdk overriding

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#387  👈
#386
#385
#384
#383
#382
#381
#379
#378
#377
#376
#375
#349
#374
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @NathanFlurry and the rest of your teammates on  Graphite


Disable multiprocess build (work around #874)

It's not entirely clear why yet, but when MSBuild tries to spawn another
node, it emits
The specified deps.json [O:\msbuild\bin\Bootstrap\MSBuild.deps.json] does
not exist

And hangs. Disabling to get clean CI builds while debugging.

LGTM, can't wait to find out what caused the issue...


Add tests for loop unrolling

Some tests for #154.

Thanks a bunch! I assume you haven't actually added any tests that run, since these both fail?

test_loop_5 and the loop compiled C examples fail. I forgot to add a skip to test_loop_5. Will do that now.

All right!


Make duns_number nullable

Description of change
This makes the field duns_number nullable so that the deployment can happen without any issue.
It will be made not nullable in the next release.
Checklist

[ ] Has a new newsfragment been created? Check changelog/README.rst for instructions
[ ] Have any relevant search models been updated?
[ ] Have any relevant fixtures (fixtures/test_data.yaml) been updated?
[ ] Have any relevant select-/prefetch-related field lists in the views and search apps been updated?
[ ] Has the admin site been updated (for new models, fields etc.)?
[ ] Has the README been updated (if needed)?

@elcct @marcuspp @reupen ready to be reviewed


should there be an average time length for a sessionID to exist?

Will Long Running Session Pose Security Challenges To the system?

Whether or not to create a new session after a certain period of time, such as 24 hours, depends on the specific requirements and limitations of the trading system being used, as well as the needs of the parties involved in the trading activity.
In general, FIX sessions can last for as long as necessary to support the trading activity. However, there may be practical reasons for creating a new session after a certain period of time, such as to maintain system performance or to manage risk.
For example, some trading systems may require periodic session resets to ensure that both parties have up-to-date information about each other's state and to prevent potential issues with message sequencing. Additionally, creating a new session after a certain period of time may help to manage risk by reducing the impact of any potential security vulnerabilities or errors that may arise during the course of a long-running session.
Ultimately, the decision of whether or not to create a new session after a certain period of time depends on a variety of factors, and should be based on the specific requirements and limitations of the trading system being used, as well as the needs of the parties involved in the trading activity.

comments are welcome here


Not Able to Reproduce WikiEvents EE Performance

Hi, I downloaded WikiEvents dataset from here: https://github.com/raspberryice/gen-arg and processed it using your data generation code and config.
Then, I ran your evaluation pipeline with the config below (basically the same as original GoLLIE-7B eval config reduced to only one task + changes in max_seq_length and batch size):
#Training args
model_name_or_path: HiTZ/GoLLIE-7B
torch_dtype: bfloat16
use_lora: false
quantization: 4
quantization_inference: null
gradient_checkpointing: true
force_auto_device_map: false
use_flash_attention: true

# dataset arguments
dataset_dir:
  /iliad/u/tommy01/multi-news/GoLLIE/data/processed_w_examples
train_tasks:
  - wikievents.eae
  - wikievents.ee
validation_tasks:
  # - wikievents.eae
  - wikievents.ee
test_tasks:
  # - wikievents.eae
  - wikievents.ee
max_examples_per_task_train: 30000
max_examples_per_task_val: 5000
max_examples_per_task_test: null
max_seq_length: 8192
generation_max_length: 8192
ignore_pad_token_for_loss: true
prompt_loss_weight: 0.0

# checkpoint settings
output_dir: /iliad/u/tommy01/multi-news/GoLLIE/GoLLIE+-7b_CodeLLaMA
overwrite_output_dir: true
load_best_model_at_end: false
save_strategy: "epoch"
save_steps: 1000
save_total_limit: 999

# evaluation
do_train: false
do_eval: false
do_predict: true
evaluation_strategy: "steps"
eval_steps: 500
eval_delay: 0
predict_with_generate: true
evaluate_all_checkpoints: false

# batch size
per_device_train_batch_size: 2
per_device_eval_batch_size: 1
gradient_accumulation_steps: 1
generation_num_beams: 1

# optimizer settings
optim: adamw_torch_fused
learning_rate: 0.0003
weight_decay: 0.0
num_train_epochs: 3
lr_scheduler_type: cosine
warmup_ratio: 0.03
adam_epsilon: 1e-7

# lora settings
lora_r: 8
lora_alpha: 16
lora_dropout: 0.05
lora_target_modules:
  - all

# reporting
logging_strategy: steps
logging_first_step: true
logging_steps: 25
report_to: wandb
run_name: "GoLLIE+-7b_CodeLLaMA"
disable_tqdm: false

# hub settings
push_to_hub: false
resume_from_checkpoint: false

# performance
bf16: true
fp16: false
torch_compile: false
ddp_find_unused_parameters: false

I ran it on the WikiEvents EE dev set (20 examples) but get a poor result:
"events": {
            "precision": 0.4,
            "recall": 0.11014492753623188,
            "f1-score": 0.17272727272727273
        },
        "arguments": {
            "precision": 0.0,
            "recall": 0.0,
            "f1-score": 0.0
        },

I also noticed in your paper's appendix that you used a total of 573 examples when evaluating on WikiEvents EE. Could you please confirm which portion of the data you are using? And why is the performance here on the dev set low? Thanks!

Hi @tommypolikj !
The WikiEvents dataset is evaluated with 2 different strategies, standard event argument extraction and "informative" event argument extraction. In the case of the first, most (around 99.5%) of the arguments are in the same sentence as the trigger; for the second, informative arguments are defined as "We define name mentions to be more informative
than nominal mentions, and pronouns to be the least informative", and they usually are outside the range of the sentence.
We focus on the first scenario and split the dataset into sentences. The 573 examples refers to the amount of sentences in the test set. You can obtain this sentence level wikievents dataset by running our pre-processing script.


Optimization terminates earlier than max_iter

I often see that optimization terminates earlier than max_iter.
I set the option of  'de_duplication' to "False" and eps to zero (or a negative value), so I do not think the consecutive occurrence of the same values of x is the reason.
I would appreciate it if someone could tell me what is causing this problem and how to solve it.

Reading the code, there're two conditions can lead to the end of optimization procedure:

one of them are self._distance_last_evaluations() <= self.eps(what you mentioned)
and another is np.linalg.linalg.LinAlgError. In my opinion, the error occurs due to "matrix is irreversible", $k^{-1}$ is a computational part of GP(gaussian process, surrogate model of BO).

I think maybe your program terminates for the second reason, if so, you should check you problem setup or kernel design.


Loading spinner for markings

Let's have a loading spinner that shows up when we are making a call for generating the markings of a given text.
There's already some commented out code indicating this wanted behavior, perhaps use that as a starting point.

Addressed in #69


Vsphere provider is trying to delete a non-existing PV

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):

Deploy persistent volumes with the Vsphere Cloud Provider
Attach the volume to a deployment.
force some pod movements (node drain etc).
delete deployment.

Result:
We're seeing repeating errors on "delete virtual disk" tasks, initiated by the kubernetes user for vmdk's of a PV that no longer exist. the vmdk does not exist on the datastore and the corresponding PV does not exist in the kubernetes cluster.

We've seen this behaviour before in a small test cluster and it stopped once the cluster was removed. This is obviously not workable for clusters with running workloads.
Other details that may be helpful:

ESXi: 6.5.0 build 8294253
Vcenter: 6.5.0 build 8307201

Environment information

Rancher version: v2.3.4
Installation option (single install/HA): HA

Cluster information

Cluster type (Hosted/Infrastructure Provider/Custom/Imported): Custom
Machine type (cloud/VM/metal) and specifications (CPU/memory): Centos VM's 4C/8G
Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"d647ddbd755faf07169599a625faf302ffc34458", GitTreeState:"clean", BuildDate:"2019-10-02T17:01:15Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.4", GitCommit:"224be7bdce5a9dd0c2fd0d46b83865648e2fe0ba", GitTreeState:"clean", BuildDate:"2019-12-11T12:37:43Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

Docker version (use docker version):

Client:
 Debug Mode: false

Server:
 Containers: 32
  Running: 20
  Paused: 0
  Stopped: 12
 Images: 14
 Server Version: 19.03.5
 Storage Driver: devicemapper
  Pool Name: docker-253:3-98566272-pool
  Pool Blocksize: 65.54kB
  Base Device Size: 10.74GB
  Backing Filesystem: xfs
  Udev Sync Supported: true
  Data file: /dev/loop0
  Metadata file: /dev/loop1
  Data loop file: /var/lib/docker/devicemapper/devicemapper/data
  Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata
  Data Space Used: 5.114GB
  Data Space Total: 107.4GB
  Data Space Available: 24.33GB
  Metadata Space Used: 24.3MB
  Metadata Space Total: 2.147GB
  Metadata Space Available: 2.123GB
  Thin Pool Minimum Free Space: 10.74GB
  Deferred Removal Enabled: true
  Deferred Deletion Enabled: true
  Deferred Deleted Device Count: 1
  Library Version: 1.02.158-RHEL7 (2019-05-13)
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: b34a5c8af56e510852c35414db4c1f4fa6172339
 runc version: 3e425f80a8c931f88e6d94a8c831b9d5aa481657
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 3.10.0-957.5.1.el7.x86_64
 Operating System: CentOS Linux 7 (Core)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 7.62GiB
 Name: nxtrancher1.sofico.be
 ID: SA44:GW7C:ET56:TWGQ:S2FF:7SSB:J3TA:4NVA:XGXJ:RSR7:VGDY:VYXI
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  <IP_ADDRESS>/8
 Live Restore Enabled: false

WARNING: the devicemapper storage-driver is deprecated, and will be removed in a future release.
WARNING: devicemapper: usage of loopback devices is strongly discouraged for production use.
         Use `--storage-opt dm.thinpooldev` to specify a custom block storage device.

I'll test it in the coming weeks once I have my setup on 6.7U3p1.


highlight.js considers closing single quote as part of URL

see:
https://deno.land/x/install/install.ps1#L54
https://deno.land/x/install/install.ps1#L58
https://deno.land/x/install/install.ps1#L70
vs
https://github.com/denoland/deno_install/blob/master/install.ps1#L54-L70
this messes up highlighting for the rest of the file, making it harder to read than a plain text

cc @j-f1


Error: Install the canvas from the Master branch

Description
I'm getting an error when I try to install the canvas from the Master branch (the latest released helm image does work).
I'm trying a
helm install canvas .\canvas-oda\ -n canvas --create-namespace

And getting an error:
Error: INSTALLATION FAILED: failed post-install: unable to build kubernetes object for deleting hook canvas-oda/charts/cert-manager-init/templates/issuer.yaml: resource mapping not found for name: "canvas-cert-manager-init-selfsigned" namespace: "canvas" from "": no matches for kind "Issuer" in version "cert-manager.io/v1"
ensure CRDs are installed first

It appears that it is not trying to install cert manager (It doesn't install the CRD's nor pods for cert manager).

Just to verify, did you go recursively into the dependent charts?
cd charts/cert-manager-init
helm dependency update
helm dependency build
cd ../../charts/controller
helm dependency update
helm dependency build
cd ../../charts/canvas-vault
helm dependency update
helm dependency build
cd ../../charts/secretsmanagement-operator
helm dependency update
helm dependency build
cd ../../charts/canvas-oda
helm dependency update
helm dependency build
cd ../..

And then install the oda-canvas chart:
helm upgrade --install canvas charts/canvas-oda -n canvas --create-namespace

Just tried it to deploy from master branch without any issues.

My issue was something to do with the dependency building. I have fixed this issue using the approach suggested by @ferenc-hechler above.


Mark all ancestor parts lists dirty when an endpoint's enabled state changes.

If an endpoint is present on a parts list other than that of endpoint
0, we were not correctly marking that parts list dirty when the
endpoint was added/removed.
Problem
See above.
Change overview
Walk the parent chain, mark parts lists dirty.
Testing
Not sure how to test this easily so far.... Ideas very welcome.  @leorozendaal

For the testing part: we were already working on the bridge-test-app to facilitate testing TC-BR-2 in the bridge test plan, which involves adding and removing bridged devices (and this EPs) - and then checking the PartsList on EP 0 and the EP for the Aggregator device type get updated accordingly. Stay tuned...


Use pino-abstract-transport synchronously

Hi, I have a custom transport that sends error reports over a webhook.
However, when I have a fatal error, the transport is not even triggered, which I assume is due to the fact that it is asynchronous.
I've seen you can use sync: true in pino.destination() but from what I understand, it only supports writing to a file, and not to an abstract transport.
How can I make it a synchronous transport, or at least, how do I make sure it is properly flushed before exiting ?

Thanks for reporting!
Can you provide steps to reproduce? We often need a reproducible example, e.g. some code that allows someone else to recreate your problem by just copying and pasting it. If it involves more than a couple of different file, create a new repository on GitHub and add a link to that.
If you are using the transport option of pino it should automatically send all the logs before everything is shut down.

logger.ts

import { pino, LoggerOptions } from "pino";

// Development transport: prints logs to console, ~~doesn't report errors to the webhook~~
const devOptions: LoggerOptions = {
	transport: {
		targets: [
			{
				// Console output
				target: "pino-pretty",
				level: "trace",
				options: {
					translateTime: true,
					ignore: "pid,hostname",
					sync: false,
				},
			},
			{
				// Webhook
				target: "./test_webhook.js",
				level: "error",
				options: {},
			},
		],
	},
};

// Set up the logger with the correct transports
export const logger = pino(devOptions);

logger.fatal("Test error");

test_webhook.ts

import build from "pino-abstract-transport";

export default async function (opts) {
	return build(async function (source) {
		for await (let obj of source) {
			console.log("Webhhok transport:", obj);
		}
	});
}

/* Expected:
[2022-08-07 10:01:35.720 +0000] FATAL: Test error
Webhhok transport: {
	level: 60,
	time:<PHONE_NUMBER>720,
	pid: 11849,
	hostname: 'pop-os',
	msg: 'Test error'
}
*/

/* Actual:
[2022-08-07 10:01:35.720 +0000] FATAL: Test error
*/

Node v18.7.0
pino v8.3.0
pino-abstract-transport v1.0.0

You can't use console.log in workers after the main process event loop shut down :(. Use sonic-boom.

I use console.log() for the example, but in the application I send a POST request using the fetch API. I removed it because I thought this wouldn't be the issue. How can I get around that ?


Translatable forms

Hi, how to achieve to have same form with multiple languages?
If i create
<form-builder type="gui"  :form="fields"   v-model="language.en"   ref="FormGUIEn" ></form-builder>
<form-builder type="gui"  :form="fields"   v-model="language.de"   ref="FormGUIDe" ></form-builder>
If i write in EN it updates DE model and vice versa.
I need translatable fields but dont know how to do it.

Hi @bajki ,
How about :
<form-builder type="gui" :form="fields" v-model="language.en" ref="FormGUIEn" v-if="currentLanguage == 'en'" ></form-builder>

The translatable field/form is one of my biggest plans at the moment, including update again a whole project. Since I've already made a simple translatable field in my previous project here: https://github.com/sethsandaru/laravel-multilingual

Hi friend,
<EMAIL_ADDRESS>has been released. Check it out.
P/s: I closed this issue because it's not related to<EMAIL_ADDRESS>Thanks.


TeslaMate integration, Teslamate id field can't be set

Hi,
first thx a ton for integrating TeslaMate, that was a feature I was long hoping for :-)
I got some issues getting it configured though, more specifically I can't set the Teslamate id field. I have it enabled but whenever I change "unknown" to the actual car id (1 in my case), it switches back to unknown a few seconds later.
Tried directly in the integration config and via the developer tools.
Any idea what the cause is?
Thx

Thanks, restarting another time fixed it. It doesn't seem the Tesla integration is pulling any metrics via MQTT from Teslamate from looking at the logs though :(

Nevermind, just after posting this msg the frist MQTT logs showed up.


Auto-complete component

From @forkmind on November 19, 2015 16:30
The current ionic search component in ionic 2 allow you to search through a list in the current tab (visible to the user). It would be great to be able to search from a collection or a javascript array as well. This option would be particularly useful for API requests or for a quick search through your whole application.
I think what does this plugin should be a native component in ionic 2.
Copied from original issue: driftyco/ionic2#594

The search bar should meet a lot of these requirements, but we can continue to improve this. I'm going to close this for now and we'll reevaluate it later.


[SPARK-LLAP-176] Update the answers for testing results

What changes were proposed in this pull request?
Update the ranger answer files.
How was this patch tested?
Manually test.

Sorry, this seems to be partial and old for now.


HTTP 403 Forbidden - CORS Issue

Running the laravel backend against any of the front-ends results in a 403 Error:
No 'Access-Control-Allow-Origin' header is present on the requested resource
Origin 'http://localhost:4100' is therefore not allowed access.
The response had HTTP status code 403.

Seems like the CORS config was looking for origins data in the global environment.
Got this to work by updating config/cors.php
    'allowedOrigins' => env('CORS_ALLOWED_ORIGINS') ? explode(',', env('CORS_ALLOWED_ORIGINS')) : ['*'],

with
    'allowedOrigins' => ['*'],


Improve documentation

@hculea Hope you don't mind but I changed the order of some of the documentation here. Mind looking over my changes?


Question on "Obligatory" table naming

The table naming the FP formats in https://github.com/riscv/riscv-bfloat16/blob/main/doc/riscv-bfloat16-format.adoc is named "Obligatory Floating Point Format Table" and list some formats specified in IEEE-754 but also some formats which are not (e.g. BF16 and TF32). Is the term "obligatory" appropriate in that context ?

It is funny ...


Figure out the methodology for native benchmarks

At the moment, the benchmarking infrastructure for RscNativeTypecheck is very minimal. We should bring it on par with the robustness that JMH provides (at the very minimum, add support for score errors) or replace it with a more advanced tool.

From the point of view of run-to-run variance, I think that existing methodology has proven to be quite useful. Here's a summary of 10 cold and 10 hot native typecheck runs (showing that variance seems to be on par with JMH: https://github.com/twitter/reasonable-scala/issues/33):
ColdRscNativeTypecheck.run   cli  100  299.179  ms/op
ColdRscNativeTypecheck.run   cli  100  297.612  ms/op
ColdRscNativeTypecheck.run   cli  100  298.294  ms/op
ColdRscNativeTypecheck.run   cli  100  297.597  ms/op
ColdRscNativeTypecheck.run   cli  100  297.936  ms/op
ColdRscNativeTypecheck.run   cli  100  297.955  ms/op
ColdRscNativeTypecheck.run   cli  100  298.402  ms/op
ColdRscNativeTypecheck.run   cli  100  298.633  ms/op
ColdRscNativeTypecheck.run   cli  100  300.401  ms/op
ColdRscNativeTypecheck.run   cli  100  300.134  ms/op
HotRscNativeTypecheck.run   cli    1  245.171  ms/op
HotRscNativeTypecheck.run   cli    1  241.071  ms/op
HotRscNativeTypecheck.run   cli    1  240.934  ms/op
HotRscNativeTypecheck.run   cli    1  242.211  ms/op
HotRscNativeTypecheck.run   cli    1  243.172  ms/op
HotRscNativeTypecheck.run   cli    1  241.510  ms/op
HotRscNativeTypecheck.run   cli    1  241.346  ms/op
HotRscNativeTypecheck.run   cli    1  246.583  ms/op
HotRscNativeTypecheck.run   cli    1  241.673  ms/op
HotRscNativeTypecheck.run   cli    1  241.312  ms/op

In order to not spend time on splitting hairs, I'll be considering this issue completed, unless there are better suggestions that are similarly fast and easy to implement. Everyone, please feel free to chime in.


USB error -1: My error message : Other Error

Environment:

OS: macOS Mojave version 10.14.6

openjdk version "12.0.2" 2019-07-16

OpenJDK Runtime Environment (build 12.0.2+10)

OpenJDK 64-Bit Server VM (build 12.0.2+10, mixed mode, sharing)
Macintoshs-MacBook-Air:HegFrontSite macintoshhd$

usb4java version 1.3.0

Bug description
Error when i tried to call LibUsb.getDeviceList(null, myList);
I get error from compiler
Caused by: org.usb4java.LibUsbException: USB error -1: Unable to find usb devices: Other error

Reproduction
DeviceList deviceList = new DeviceList();
        int result = LibUsb.getDeviceList(null, deviceList);

        if(result != LibUsb.SUCCESS) throw new LibUsbException("Unable to find usb devices", result);

Expected behavior
It should return me with device list.

I can confirm this behavior on Fedora 33 (stock kernel 5.14.18-100.fc33.x86_64), OpenJDK Runtime Environment (build 1.8.0_312-b07), libusb version <IP_ADDRESS>84, usb4java version 1.3.0 from Maven central. Even tried to compile the libusb4java.so from sources (successfully) and replace it within the classpath, but to no success. The error code returned by LibUSB.getDeviceList is -14 and the debugging output is
[ 0.004276] [001d0eff] libusb: debug [libusb_get_device_list]
[ 0.004286] [001d0eff] libusb: debug [discovered_devs_append] need to increase capacity
Exception in thread "main" org.usb4java.LibUsbException: USB error -14: Other error

I succeeded to get the device list using the same libusb in a simple C program.


How can I add every single tf2 item to the bot without having to go through each one individually

I want my bot to bank every item in existence. It would take hours to enter each item individually, so why isn't there a way to add all items like there is one to remove all items?

Make a python script to create a pricelist, albeit I'd highly suggest against banking every item in existence as you probably don't have the listing slots to do so.

Make a script that builds an !addbulk command, from SKU 1, to whatever the last SKU is now. Look at TF2's item schema for details.
I disagree with adding such a feature. A lack of listing slots, the size of the pricelist file and the slow-down that will come with it, and the horror of maintaining a pricelist like that.
This enhancement request is vague, so I'm closing this. Feel free to reopen with more details.


[BUG REPORT]

An error occurred
WORKER:ERROR [2021-12-19T09:50:53.639Z]     Error: connect ETIMEDOUT <IP_ADDRESS>:443
  - METHOD_NAME: verifyUser
  - STATUS_CODE: 500
  - STATUS_MESSAGE: Internal Server Error
  - STACK_TRACE RequestError: Error: connect ETIMEDOUT <IP_ADDRESS>:443
    at new RequestError (C:/Users/camc4/Downloads/BitfinexReport-3.6.2-x64-win/resources/app/bfx-reports-framework/node_modules/request-promise-core/lib/errors.js:14:15)
    at Request.plumbing.callback (C:/Users/camc4/Downloads/BitfinexReport-3.6.2-x64-win/resources/app/bfx-reports-framework/node_modules/request-promise-core/lib/plumbing.js:87:29)
    at Request.RP$callback [as _callback] (C:/Users/camc4/Downloads/BitfinexReport-3.6.2-x64-win/resources/app/bfx-reports-framework/node_modules/request-promise-core/lib/plumbing.js:46:31)
    at self.callback (C:/Users/camc4/Downloads/BitfinexReport-3.6.2-x64-win/resources/app/bfx-reports-framework/node_modules/bfx-api-node-rest/node_modules/request/request.js:198:22)
    at Request.onRequestError (C:/Users/camc4/Downloads/BitfinexReport-3.6.2-x64-win/resources/app/bfx-reports-framework/node_modules/bfx-api-node-rest/node_modules/request/request.js:820:8)
    at processTicksAndRejections (internal/process/task_queues.js:80:21)

Debug info

Version
3.6.2

Commit Hash
2f22ef99ea09ab920ec241423232a2bae7b0d722

Commit Date
2021-12-16T09:29:31Z

Electron
13.6.3

Chrome
91.0.4472.164

Node.js
14.16.0

V8
9.1.269.39-electron.0

OS version
Windows 10 Home

OS release
Windows_NT x64 10.0.19042

CPUs
AMD Ryzen 3 3300U with Radeon Vega Mobile Gfx   x 4

RAM
5.92GB (0.97GB free)

App RAM limit
2072Mb (8.7MB used)

Main log

Worker errors

Worker exceptions

The issue was opened from the electron app

Thanks for reporting, would investigate and come back.

Thanks for reporting
I try to understand what here was caught and it looks like something does not allow to connect via HTTPS port (not related to the bfx-report tool), so can I ask you the following:

try to turn off the firewall and reopen the bfx-report app
if you are using any network proxy try to use the app without proxy

@tiptop100 has this solve the issue?

Sorry for not getting back, yes it did thank you
Regards,
Cam Chippendale
0480 129 179
On Thu, 13 Jan 2022 at 16:30, ezequiel wernicke @.***>
wrote:

@tiptop100 https://github.com/tiptop100 has this solve the issue?
—
Reply to this email directly, view it on GitHub
https://github.com/bitfinexcom/bfx-report-electron/issues/129#issuecomment-1011836213,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AW7IQNOM5SP6GTWTPHTIKDDUVZWQVANCNFSM5KLWFYTQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>


Avoid barrel re-exports in auto-imports

Bug Report

🔎 Search Terms

autoImportFileExcludePatterns

Bug
When using the setting typescript.preferences.autoImportFileExcludePatterns, it works, however, in a mono-repo I cannot import from another package's root without using the full path to the file when excluding index.ts files.
{
  "typescript.preferences.autoImportFileExcludePatterns": [
    "./packages/*/src/index.ts"
  ],
}

I have a workspace package.json that looks like this:
{
  "name": "workspaces",
  "version": "1.0.0",
  "workspaces": [
    "packages/core",
    "packages/a"
  ]
}

In the package.json of packages/core I have this:
{
  "name": "@org/core",
  "main": "./src/index"
}

Then in the packages/a, I try to import a file from packages/core, but autoimport imports something like this even though it is exported through the main file:
import { MyClass } from '@org/core/src/classes/my-class';

The package.json for packages/a
{
  "name": "@org/a",
  "main": "./src/index"
}

The tsconfig.json for both:
{
  "extends": "../tsconfig.base.json",
  "files": [
    "./src/index.ts"
  ]
}

Expected Result
This might be a feature request, but I think it would be great if barrel files could be ignored in the auto-import if within the same module/package, as this can often lead to circular dependencies that are hard to track down.

@RyanCavanaugh I have created the repo: https://github.com/TheColorRed/vscode-autoImportFileExcludePatterns
Steps:

Clone the repo
npm i
In packages/helper/src/index.ts type readF and select the one that is in @org/core from the Intellisense popup.

You will then notice the auto import imports the full path to the file:
import { readFile } from '@org/core/src/files';
readFile

Now if you turn off the setting typescript.preferences.autoImportFileExcludePatterns in .vscode/settings.json and use Intellisense, the import works the way I intended:
import { readFile } from '@org/core';
readFile

Having this setting works the way I want when referencing a file in the current mono-repo project (aka when @org/core or @org/helper uses one of its own files). But when @org/helper uses a file from @org/core the wrong import is used.
Here is what I am looking for:
@org/core     -> import { readFile } from './files';
@org/helper   -> import { readFile } from '@org/core';

Here is what is happening:
@org/core     -> import { readFile } from './files';
@org/helper   -> import { readFile } from '@org/core/src/files';

I ran into a similar issue with this. It would be great if there were a way to exclude "index.ts" from being suggested directly while still allowing other specifiers that resolve to a file called "index.ts".

@andrewbranch Any chance this could fit in with some of the ongoing auto-import improvements?
Would make a huge difference to me as currently I either get imports from my main.ts entrypoints within a single package, causing circularities, or cannot get auto imports from other packages in the monorepo.

This is super working-as-intended, and the desired behavior I think clearly doesn’t map onto autoImportFileExcludePatterns, unless you had a multi-root workspace and had different VS Code settings for each TS project, which would let you exclude your own index.ts files in each workspace root without excluding any other package’s index.ts files.
Auto-imports has a preference toward barrel files because they usually indicate the most public export of something and result in the shortest path. I would like to move away from this preference since barrel files often make build tools work poorly, but there needs to be a stronger proposal for how to make this shift, and it needs to be motivated by objective reasons, not code style aesthetics.
In the example project here, if you don’t want to import from '@org/core/src/files', then that package should declare an "exports" that prevents such a path from being resolvable. After that, if we had a setting for “avoid barrel re-exports,” it would do the job, because in the local project, you might have many ways to access some export, including a barrel file, but there would only be one way to access everything from '@org/core'.

I feel instinctively opposed to a setting like “avoid barrel re-exports in my own files but not from my dependencies.” There are many reasons barrels are bad; the circularity problem is just one. If auto-imports is making a circularity that could have been detected, or at least looks suspicious, we should try to fix that universally, not behind a setting. I did some work like that in https://github.com/microsoft/TypeScript/pull/47516. But given all the other barrel problems, it begs two questions:

Why would you want to import from barrels in node_modules? Your bundler and other tools are probably going to work better and faster if you use the deepest / most specific imports the package allows.
Why write them in your own code?

To me, this makes it feel like we kind of don’t need any additional settings. If you want short import paths from node_modules but you don’t want to import from your own barrels, maybe you should stop writing barrels in your code. On the other hand, if we changed settings for everyone to avoid barrels everywhere, and people started complaining about getting unwieldy auto-import paths for their dependencies, then maybe those dependencies should define "exports" that declare what subpaths are allowed.

@andrewbranch Maybe I should have described my use case more clearly but I don't use barrel files. I only have a single main.ts file for each package which constitutes its public API- there are no re-exports.
I have a paths config like this that allows me to avoid having to build to see my runtime or type changes reflected e.g. in tests:
		"paths": {
			"arktype": ["./ark/type/main.ts"],
			"@arktype/util": ["./ark/util/main.ts"],
			"@arktype/fs": ["./ark/fs/main.ts"],
			"@arktype/schema": ["./ark/schema/main.ts"],
			"@arktype/attest": ["./ark/attest/main.ts"]
		}

If you have another suggestion as to how to achieve this that doesn't result in the problematic suggestions I'd definitely be open to it!

@andrewbranch Rereading some of your suggestions, I understand more what you're suggesting now, but top-level discoverability for the API of a library feels valuable.
I would definitely not want to give that up just to avoid some obnoxious auto-imports that worst-case scenario I can manually fix. Granted it is grating given how often these kinds of imports occur, but I don't know if I can recall a library that doesn't provide some top-level export and I think there are good reasons for that.

IMO you should never use paths. Use package manager workspaces and set up project references. That’s enough to not have to build to see type changes in the editor—references to project reference output files get transparently redirected to input files in the IDE so you get instant IntelliSense updates across projects. For fast test/dev runtime workflows, I add conditional "exports" on top of this:
{
  "exports": {
    "ts": "./src/main.ts",
    "default": "./dist/main.js"
  }
}

then set your test runner / whatever to use the ts condition.
paths goes through some pretty different auto-import code paths so I’m not sure how it might be affecting your experience.

@andrewbranch I actually had this kind of setup originally but it felt like a lot of extra ceremony for no extra benefit compared to using paths, at least within my own repo.
I also had the same problem with autoimports with that set up.

@andrewbranch Any new ideas on this one?
I've been talking with @colinhacks about strategies for developing in a TS monorepo with no build step as documented in his blog post here.
This is one of the biggest downsides to either of these approaches. I don't see any way around having at least one "barrel file" for your API entry point that doesn't involve freezing your file structure in order to have a stable release.

I’m open to trying a preferDeepImports preference that applies universally, no carve-outs for local files vs. node_modules.

@andrewbranch I'm sure that could be useful in some situations but I expect it would result in imports resolving to arbitrary source files across packages in a setup like the one I'm describing. Do you...

Agree a config setup that avoids having to build in dev is a big win
Know of a better method than those mentioned by Colin to achieve this (specifically tsconfig paths paralleling your package names or customConditions)
Have any suggestions for how to autoimport from a package entry point when outside the package itself in a setup like this

My first intuition was that perhaps typescript.preferences.autoImportFileExcludePatterns or another setting could support a pattern that would be checked against the import specifier rather than the resolution, but maybe there is a technical reason that is not possible or desirable?

I’ve been using customConditions in the arethetypeswrong monorepo from the beginning to get no-build updates in the Vite dev server. I just don’t agree that configuring that is unreasonably burdensome. The entire JavaScript ecosystem has been given a huge gift in that all major tools adopted conditional package.json "exports" almost to spec. It’s not a perfect system, but it’s pretty good, and this is a perfect application for it.

a pattern that would be checked against the import specifier rather than the resolution, but maybe there is a technical reason that is not possible or desirable

No, it’s both possible and desirable, just nitpicky design questions remain: #55092

Yeah customConditions is fine with me. It essentially serves the same purpose in my case and I can see how in other scenarios it would be less likely to cause problems getting out of sync, so I can see why you'd recommend it.
I think for now it would fall victim to the same underlying problem, I will keep an eye on the issue and add some context there.

I think for now it would fall victim to the same underlying problem

If I’m understanding you correctly, it just depends on how you set up the "exports" API. You can choose whether you expose deep imports or not. If you just want to have a single package entrypoint that exports everything, you can do that, and then auto-imports within that package will work normally, importing from local files, and imports outside that package will only ever be able to refer to the top-level package specifier. If you choose to expose deep imports on the package by defining many subpaths or a wildcard subpath, along with "." re-exporting everything, then yes, auto-imports will have to make a decision whether to import from the package’s "." or other subpaths, which would be affected by the preference I’m proposing. But I still assert that if you want “deep imports” in some places, you have reasons to want them everywhere 😄 Am I missing something? I don’t really see what the problem is.

@andrewbranch What you described does explain how preferDeepImports could solve this problem with either setup. That sounds like it could work perfectly as long as it doesn't try to cross package boundaries directly (which I assume it wouldn't since I don't that occurs currently).
What I meant about the same underlying problem though is that given that such a setting doesn't exist currently, both tsconfig paths and package.json exports would be affected by this issue, correct?

One major difference between exports and paths is that exports block the resolution of paths not explicitly listed, whereas paths is purely additive. So already, you can use customConditions and "exports" to limit how a package can be imported externally, whereas paths does not really afford you that ability.

@andrewbranch Sure but I'm already using exports for that reason and I mostly just have one entry point per package so this doesn't really impact me.

Then I don’t understand what problem you’re currently having 😅 The OP complained about auto-imports like '@org/core/src/classes/my-class' which shouldn’t be possible if your equivalent of @org/core/package.json has an "exports" (assuming you’re using a modern moduleResolution setting)

I have a package arktype that depends on @arktype/schema. @arktype/schema has a primary API entrypoint at ark/schema/api.ts.
To avoid importing from the API entrypoint from within @arktype/schema, which would often create cyclic imports, I can add the following config:
	"typescript.preferences.autoImportFileExcludePatterns": [
		"./ark/schema/api.ts"
	]

However, if I do this, I no longer get autoimports from @arktype/schema in arktype as @arktype/schema, but rather from the nested file, even though it is not exported in @arktype/schema's package.json.
Maybe it is because I only have a single root-level tsconfig that is shared by both packages during dev?

If you rename api.ts to index.ts and delete the autoImportFileExcludePatterns you should be good to go 😬

https://github.com/microsoft/TypeScript/blob/4ada2706a76f4e22867c10830ac4add52af34e2c/src/services/codefixes/importFixes.ts#L1344-L1358
It was originally intended primarily to avoid module specifiers like "../.." because they look code smelly, but it was later expanded slightly to deal with circularities in more cases. It might make sense to remove the index filename part of this now.

@andrewbranch I think that works! 🎉 Thank you so much- that has been plaguing me since long before I commented on this a year ago 😅
Would definitely be interested if other file names are supported so I can switch back, but I care 95% less about that than being able to import across packages easily.

It actually might be possible to do this cheaply without heuristics, as long as the file you’re currently editing exports something... the data structure central to auto imports can answer whether an arbitrary symbol exported from your current file can also be imported from the file we’re generating an import to, detecting a circularity. We’re well set up to do that for individual exports, just not whole modules, so we’d do well for export * but could fail to detect cases like export { JustOneThing } from "./foo"...

I'm generally exporting a specific subset of symbols in a package entry point to make the API as explicit as possible.
The index.ts has such marginal downside I'm unlikely to think about this again unless I specifically read somewhere that other files can be handled the same way by autoimports.
I guess the biggest downside is discoverability as I never would have guessed changing the file name would fix this.


CAD-2359 cli:  construct a full cert for annotation in 'byron delegation check-delegation'

bors r+

bors r+

bors r+

bors r+


[Feature] Indicate the resources to be dispatched to which cluster

Is your feature request related to a problem? Please describe.
We are developing custom components and traits to provide the capability to deploy cloud resources with the application. Sometimes we need to control where CRDs are generated. Trait definition has a "controlPlaneOnly" attribute which helps us to achieve what we want. But we can't do it for component definitions.
If the desired resources are optional we provide the resource with a custom trait with the "controlPlaneOnly" attribute. But sometimes resources are mandatory for the component and we can't provide it as a trait.
For example, we developed a web service component. The component deploys the application to the remote clusters but also it generates auxiliary resources to bootstrap the observability configuration for the application. These CRDs are don't need on the remote clusters, we want to dedicate these to the hub cluster.
Describe the solution you'd like
@Somefive :

One of the way that could be possible is to add some specific annotation to the rendered resource, like app.oam.dev/cluster: local and let the controller to be able to recognize that and put it on the hub cluster, as we cannot design only one field to describe multiple resources rendered by the componentdefinition.

I think one of the way is to add special annotation/label to the rendered resources. For example set "app.oam.dev/cluster: local" will force the rendered resource to be dispatched to the hub cluster.


Invalid Image

The Image here appears to be invalid for the LTS however I found swapping it for Ubuntu2204 fixed the problem
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 115cdf49-6a35-aa52-de86-3cd8d0b2e3b9
Version Independent ID: 40a3d5ca-157b-151f-a5e7-66fe71e41104
Content: Get Started - Install Jenkins on an Azure Linux VM
Content Source: articles/jenkins/configure-on-linux-vm.md
Service: jenkins
GitHub Login: @TomArcherMsft
Microsoft Alias: tarcher

@intellispear Thanks for your feedback, but it's been decided that Jenkins on Azure documentation support is limited to security issues only. Therefore, I'm closing this issue.


pull request for e2e test at 01/25/2017 06:56:08

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


math.sans shows bold greek symbols

Description
Using math.sans() makes greek letters very bold.
sans(mu = beta times + a b c d) compiles to

Reproduction URL
https://typst.app/project/p7uxKHHQqFQyH2uzWulr_8
Operating system
Web app, macOS
Typst version

[X] I am using the latest version of Typst

Unfortunately there are only regular, bold and sans-serif bold mathematical Greek letters in unicode, no non-bold sans-serif. There isn't anything typst can do about that.

Thanks for the quick answer. That's very sad...
Fira Math is no option because there are many other problems, like no correct long arrows

I think you should be able to just create a helper function to only use Fira Math on specific letters or even show regex("\\w")


bounding box transition

https://github.com/LACE-Lab/bounding-box/blob/1a1e5a6f923b945d18a372b63b5c14ab79069f0a/src/rl/environments/GoRight.cpp#L331C6-L331C61
Shouldn't this be statpred[1] instead of statpred[0]?

I guess this is more or less equivalent to an else case


修正 LayeredClusterLogAllocation 和 RebalanceAdmin 對 topic 過濾的責任與共識

https://github.com/skiptests/astraea/pull/403#discussion_r913242152

Resolved by https://github.com/skiptests/astraea/pull/712#discussion_r972662291


Added a command to renew a Office 365 group's expiration resolving issue #870

hey @waldekmastykarz / @VelinGeorgiev this is ready for review. thanks :)

Coverage remained the same at 100.0% when pulling b10cf108760492518a9166def84015c50a69c16d on rabwill:issue-870 into a33b7e170ea222bfd3d4a1f04676c47b5def8c60 on pnp:dev.

Excellent! We'll have a look at it shortly! 👏

Merged manually. Thank you! 👏