Loading (StaticQuery)

Hi, I implemented gatsby-source-twitter in my project, everything worked fine, but suddenly it stopped displaying tweets. Instead, there is: "Loading (StaticQuery)". Do you know what may cause this problem? Thanks for help!

Hi @wojciechnowaczyk
it's difficult to help you without more informations.
First check if tweets are pulled down from twitter api. Check logs during build / dev
Then use GraphiQL interface in Gatsby to browse data
Check also your tweet query to twitter api.
If you haven't chang anything in your code, maybe tweets that you are pulling down are not available anymore.
Let me know
Thanks


Validator for "Other"

When people select Other from an Enum, they need to provide the information in the Notes. Can we have a validator that forces this?

In Pydantic this is easy. The GUI will need investigating.

I haven't done a Validator yet, can someone elaborate on what this is or provide an example? @dyf @saskiad

I haven't made one myself, but they are functions within the schema that create/enforce rules in the schema. There's an example in ephys_rig https://github.com/AllenNeuralDynamics/aind-data-schema/blob/6e23ae05eadddd639baf7913857e6b41c57d7bfd/src/aind_data_schema/ephys/ephys_rig.py#L187
Probably worth looking at some pydantic documentation on validators

Locations I have found that contain reference to enum.OTHER and contain a notes field: procedures.SpecimenProcedure, processing.DataProcess, session.RewardDelivery, behavior_session.RewardDelivery, instrument.Instrument, mri_session.MRIScan,


fixes ci.yml to pass build failures

Signed-off-by: ashiscs<EMAIL_ADDRESS>Due to extra space given at starting of error_check and static_check the yaml file was giving error, this pr addresses the issue !!

Re-running checks...


External Secrets Operator integrates with Alibaba Cloud Key Management Service for secrets and Keys management.

Hi, could you tell me how to configure the "secretstore&externalsecret" files through Access key rather than RRSA authentication. thank you so much!

The following SecretStore assumes you have your credentials stored in a Kind=Secret with the name my-creds.
Hope that helps :pray:
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: secretstore-sample
spec:
  provider:
    alibaba:
      regionID: ap-southeast-1
      auth:
        secretRef:
          accessKeyIDSecretRef:
            name: my-creds
            key: akid
          accessKeySecretSecretRef:
            name: my-creds
            key: secret

You can lookup the yaml spec under API specification, that helps you to explore the fields which are not well documented :sweat_smile:  :wink:

thank you! it helps


Uncaught exception in execution summary

While generating an execution summary, current_task._requires() is called without any exception protection.
In case a pending task fails on a later call to _requires()  (say some external service died while luigi was running), an exception is thrown and is not handled.
These tasks reproduce the issue:
from luigi.target import Target
from luigi.task import ExternalTask, WrapperTask

class MissingExternal(ExternalTask):
    # this task is pending: missing external dependency
    def output(self):
        class DoesNotExist(Target):

            def exists(self):
                return False

        return DoesNotExist()

class MyTask(WrapperTask):
    # This task is left pending due to MissingExternal
    # But it will make execution summary crash later on
    num_calls = 0

    def requires(self):
        if self.num_calls == 2:
            raise Exception('Crash in a later call to requires()')
        self.num_calls += 1
        yield MissingExternal()

Running it yields:
ERROR: Uncaught exception in luigi
Traceback (most recent call last):
  File "luigi/retcodes.py", line 75, in run_with_retcodes
    worker = luigi.interface._run(argv).worker
  File "luigi/interface.py", line 211, in _run
    return _schedule_and_run([cp.get_task_obj()], worker_scheduler_factory)
  File "luigi/interface.py", line 174, in _schedule_and_run
    luigi_run_result = LuigiRunResult(worker, success)
  File "luigi/execution_summary.py", line 78, in __init__
    summary_dict = _summary_dict(worker)
  File "luigi/execution_summary.py", line 393, in _summary_dict
    _populate_unknown_statuses(set_tasks)
  File "luigi/execution_summary.py", line 131, in _populate_unknown_statuses
    _depth_first_search(set_tasks, task, visited)
  File "luigi/execution_summary.py", line 144, in _depth_first_search
    for task in current_task._requires():
  File "luigi/task.py", line 626, in _requires
    return flatten(self.requires())  # base impl
  File "luigi/task.py", line 887, in flatten
    for result in iterator:
  File "fizz.py", line 23, in requires
    raise Exception('Crash in a later call to requires()')
Exception: Crash in a later call to requires()

@orenovadia  We would welcome a PR to resolve this bug :) All are welcome to contribute! Thanks!

This is not a bug. requires() shouldn't have side effects (unlike say complete() which of course may)

Hi @Tarrasch , If by side effect you mean that I am incrementing a counter then of course you are right.
But it's just a simulation: a real scenario is that requires() fails to communicate with an external service for example.

communicate with an external service

That's a side effect as you know. But if you know of a clever way to make the handling of this better that would be great.


Add CHECK_ALL_WARNINGS to force test to fail on any Warning.

Reference Issues/PRs
Local test for scikit-learn issues #5685 and #10158
What does this implement/fix? Explain your changes.
Add CHECK_ALL_WARNINGS option to force test to fail on any Warning.

Thanks @cmarmo ! I think trying to address warnings in the test suite would be very useful, but I'm less sure that failing on them would be a good idea cf https://github.com/scikit-learn/scikit-learn/issues/5685#issuecomment-595710106


finer control over the # of threads used by any given call to OpenBLAS

I need finer control of the # of threads that each call to the BLAS uses. My packages are themselves multithreaded. Each of my threads can make its own calls to the BLAS, in parallel. Some of those calls will be for small matrices, or for other cases where I know I need to use one thread. Other calls will want to use, say, 2 threads and no more (because I'm using threads elsewhere). Sometimes I want to use all the threads available. However, I cannot set a global setting, such as with openblas_set_num_threads, since that would affect all of my calls to the BLAS. My packages themselves are used in other parallel packages. So I need a thread-local way to set the # of threads that OpenBLAS uses, much like this function: https://software.intel.com/en-us/mkl-developer-reference-c-mkl-set-num-threads-local so that I can exactly control how many threads OpenBLAS uses, for each call to the BLAS.
The OpenBLAS cannot always assume it has all the threads available to it, since there are other things going on.
See also this discussion: DrTimothyAldenDavis/SuiteSparse#1
Is this possible with OpenBLAS? Is there an OpenBLAS equivalent to mkl_set_num_threads_local?

If you use OMP then OMP OpenBLAS under the hood (like one available with Debian/Ubuntu) , it falls back to single thread when it detects being in parallel section.
Other way with thread (default from make) build with recent versions is to set global variable, make the call that should be limited, then set another for another (hardly any lock to avoid races in suggested code path though)
Tell the improvement you desire over which case!

I see.  This is a common problem I have with many BLAS packages.  The problem is the assumption that the user package is either parallel, and thus all calls to the BLAS "must" be single-threaded, or that the user package wants to let the BLAS to all the parallelism itself.
That assumption breaks down in many cases.
Consider the case when computing a sparse LU factorization via a multifrontal method.  The method constructs a tree, where each node uses a few calls to the BLAS (like dgemm, and the upper/lower triangular solves) to do a local dense LU factorization.  At the leaves of the tree, the nodes are tiny (2-by-2 can occur) so of course only a single thread should be used inside a call to the BLAS.  There could be thousands or millions of such tiny BLAS calls.  I may want to use parallel BLAS soon, but not for these thousands of BLAS calls.  The BLAS must use one thread, efficiently, and it should spin-wait, waiting for work to do (I have lots of work for the threads to do, in parallel factorizations of entire subtrees, where each of my threads is factorizing all the many nodes in a single subtree).
In the middle of the tree, I have many fronts I can factorize in parallel, and the fronts get bigger.  So if I (say) have 8 threads available, and I'm working on 4 subtrees, I may want to use 4 threads in one front, 2 in another, and 1 each in two other fronts.   Just as an example; the parallelism is very dynamic.
At the top of the tree, there is typically a large front, where all the threads need to work together in a single BLAS call.
Another case occurs in my GraphBLAS package (a sparse matrix library).  The user may have lots of work going on in parallel; they can call GraphBLAS and tell me, per call, how many threads to use in that particular call to GraphBLAS.  Then each of my functions may want to use the dense CBLAS on small submatrices or vectors, using a single thread each (but do so in parallel), or I may want to use all of my threads in a single call to the BLAS.
So there is a mix of parallellism, on at least 3 levels:  the user application, my library, and the BLAS.  I'm in the middle, and I need to be told how many threads to use (at max; I can auto-tune downwards if need be).  And I thus need to tell the BLAS, beneath me, how many threads it can use, per call.

Returning to this, while I cannot offer a short-term solution I note that most of the BLAS functions in OpenBLAS "know" to limit themselves to a single thread if the workload is tiny. The spin-wait issue should be (mostly) adressable by setting a very small value for THREAD_TIMEOUT at compilation.

If you are using python, threadpoolctl might be useful to dynamically change the number of threads libraries (including BLAS' implementations) use.
You might be able to translate its implementation into other languages.

At the leaves of the tree, the nodes are tiny (2-by-2 can occur) so of course only a single thread should be used inside a call to the BLAS. There could be thousands or millions of such tiny BLAS calls.

Out of curiosity,  for these very small base cases, could it be beneficial to have optimized "hand coded" routines that could e.g. be inlined and unrolled to avoid all the overhead of calling into BLAS.

Out of curiosity, for these very small base cases, could it be beneficial to have optimized "hand coded" routines that could e.g. be inlined and unrolled to avoid all the overhead of calling into BLAS.

Perhaps, but the threshold would be delicate, and I spend very little total time in those "small BLAS" when they are done properly (in a single thread).  I just need them not to be done with too many threads, which really slows things down.

If you are using python, threadpoolctl might be useful to dynamically change the number of threads libraries (including BLAS' implementations) use.
You might be able to translate its implementation into other languages.

I took a look but I don't think this would work.  I would need to be able to check at link-time which BLAS library is being linked in.  That's something python can do, I suppose, but my SuiteSparse libraries are just simple libwhatever.so and I don't control the loading and linking of dynamic libraries.  Someone else handles that when using SuiteSparse in some application.
I do know how to write a library that dynamically loads and links in another library (I do that in GraphBLAS, which has its own JIT where it compiles new code at run time).  So in theory, I could find library-dependent functions at link time, like openmp_get_numthreads and so on.  But that would require me to control the loading and linking of the BLAS.  I don't have that flexibility.  The end user application links in the BLAS itself, well before any call to any method in SuiteSparse.

should no longer be necessary for OpenBLAS starting from the upcoming 0.3.27 (#4441 being the relevant PR) - at least in all my tests with big files from your matrix collection it was always spurious multithreading in GEMV that made OpenBLAS slower than MKL (although I never saw the kind of horrendous slowdown that had been reported back in 2019)

Sure!  It would be ideal if we could replicate a before-and-after triage of the problem, but I'm OK with considering this fixed unless it flares up again.


 This is game-breaking on servers because now others with scale boxes can go to other people's scale boxes with elytra and fireworks and break into their houses.
You could solve this by teleporting them to spawn or not allowing beds in the scale box dimension.

I see. Will fix.

MiniScaled already allows placing a scale box inside itself. Escaping can even be done without using bed.
I am going to make that when the scale box has no entrance, the inner portals point to the default spawnpoint in overworld. And when the player is far from any scale box in mini_scaled:void dimension, the player get teleported back to the scale box

Should be fixed in 2.1.1

what did you do to fix it?


feat: Added -o flag to ls command for package kind in CLI

Ref #928
📑 Description
Have added support for for -o , --output flag for kind package. Earlier this was only functional for kind clusterpackage.
Preview

Okay thanks @kosmoz for the review, will make the required changes.


Provide detailed availability values at /bibliographic/:id/holding/:id/availability endpoint

child of #573; follow-up to #1179
Implementation
For this endpoint, we need to send item-level availability statuses. The status and status_label should be taken from:

work_order_type if it exists
else process_type if it exists
else base_status

status field should return "value"; status_label field should return "desc"
Note: An item will never have more than one work_order_type at once.
An example "at preservation" item:
MMS Id:<PHONE_NUMBER>3506421
Holding ID:<PHONE_NUMBER>0006421
Item ID:<PHONE_NUMBER>0006421
"base_status":
  {
    "value": "0",
    "desc": "Item not in place"
  },
“process_type”:
  {
    “value”: “WORK_ORDER_DEPARTMENT”,
    “desc”: “In Process”
  },
“work_order_type”:
  {
    “value”: “Pres”,
    “desc”: “At Preservation”
  },
 “work_order_at”:
  {
    “value”: “DEFAULT_CIRC_DESK-Pres”,
    “desc”: “Default Circulation Desk”
  },

Background / Discussion
Previously we computed a wide variety of labels based on statuses that came out of voyager. We won't do that any longer. Below is discussion we had on the way to figuring out the new procedure.
Status labels currently in marc liberation:

[ ] 'All Items Available' (Now more_items == true && status.start_with?('on-site'))
[ ] 'Available' (Now ['Not Charged', 'On Shelf'])
[ ] 'Long overdue' (Now ['Lost--system applied', 'On-site - lost--system applied'])
[ ] 'Lost' (Now ['Lost--library applied', 'On-site - lost--library applied'])
[ ] Returned (Now ['Discharged'])
[ ] In transit (Now ['In transit discharged'])
[ ] In process (Now ['In process', 'On-site - in process'])
[ ] Checked out (Now ['Charged', 'Renewed', 'Overdue', 'On hold', 'In transit', 'In transit on hold', 'In transit discharged', 'At bindery',  'Remote storage request', 'Hold request', 'Recall request'])
[ ] Missing (Now ['Missing', 'Claims returned', 'Withdrawn', 'On-site - missing', 'On-site - claims returned', 'On-site - withdrawn'])
[ ] See front desk (Starts with 'on site - ')
[ ] On-site access ('on-site')
[ ] Pending order ('Pending Order')
[ ] Order received ('order received')
[ ] On-order ('on-order') - see #630 for alma details
[ ] ? (There's a fallback to whatever Voyager has if the above doesn't fit)

Alma implementation
There is a list of process types at https://developers.exlibrisgroup.com/alma/apis/docs/xsd/rest_item.xsd/. The list shows demo process types but is supposed to show your institution's actual process types if you log in. The only type of process_type our records currently have is "technical". Everything with one of those statuses will have availability "not available".
The records are migrated with process_type "technical - migration" and the voyager data in local_notes_3. pul staff will manually move them into the various other process types in batches. This means they will create a "work order" for each process type and then create statuses for that work order.
We should be able to find fixtures for items with the checked out status. These will have a process_type "loan".
We can also create a fixture for an item with a process type of "technical - migration". The next step will be converting a handful of these to use real work orders / process types.
Impact on Requests app
3 Broad categories of status values (not status label values!), as far as Requests is concerned. Behavior culminates in the requestable form.

Charged or missing (borrow_direct?)

user is prompted to check borrow direct

On-order or Pending (request?)

In-process and on-order items are sent through an email workflow so catalogers can bump up its priority.

Available (requests logic is that it's available if it's not in the other categories) (pick_up?)

user can schedule a pickup.

related migration ticket in requests: https://github.com/pulibrary/requests/issues/891

This really cannot be done until January. Statuses in Alma are completely different from statuses in Voyager, and it will take a while to get examples of them. This will have to be done in early January.

Thanks @mzelesky! Marking this issue as blocked.

Some documentation on work orders in Alma (which lead to process types):
https://knowledge.exlibrisgroup.com/Alma/Training/Alma_Essentials/Alma_Essentials_-_English/E_Resource_Management/05_Work_Orders
https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/030Fulfillment/Resource_Requests/020Managing_Requests_and_Work_Orders
https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/050Administration/050Configuring_General_Alma_Functions/040Work_Orders_and_Departments#Adding_a_Work_Order_Type_Status

This item is in a Preservation process:
MMS Id:<PHONE_NUMBER>3506421
Holding ID:<PHONE_NUMBER>0006421
Item ID:<PHONE_NUMBER>0006421
Process type: Pres

Closed via PR #1275. Individual issues can now be traced via separate tickets.


Make upscaling images opt-in

Description
We should be discouraging users from upscaling images, which causes increased memory usage. This problem arises because users typically do not know the intrinsic dimensions of the compressed image data, and may be providing cache width/height values that exceed the dimensions of the image.
Once this lands, we can default the parameter to false in the engine as well.
/cc @zanderso @chinmaygarde FYI
Related Issues
Part of https://github.com/flutter/flutter/issues/59578
Engine side PR was https://github.com/flutter/engine/pull/19067
Tests
Test that upscaling still works when the parameter is set to true
Test that downscaling works (previously untested)
Test that upscaling is not applied when the parameter is set to false.
Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.

I'll do a FROB run to make sure this breaks nothing internally.

Cirrus failure are presumably resolved when the engine roll lands?

Analysis issues are places in the code where I failed to fix up signatures. Will take  a look and add the doc comment.

My FROB run had lots of failures, but none of them seem related to this change. That's the best I can make of that :\


Speed up ts data sampler

Description

Motivation and Context

How Has This Been Tested?

[ ] Pass the test by running: pytest qlib/tests/test_all_pipeline.py under upper directory of qlib.
[ ] If you are adding a new feature, test on your own test scripts.

Screenshots of Test Results (if appropriate):

Pipeline test:
Your own tests:

Types of changes

[ ] Fix bugs
[ ] Add new feature
[ ] Update documentation

merged on local


[SEDONA-411] Add RS_Rotation

Did you read the Contributor Guide?

Yes, I have read Contributor Rules and Contributor Development Guide

Is this PR related to a JIRA ticket?

Yes, the URL of the associated JIRA ticket is https://issues.apache.org/jira/browse/SEDONA-411. The PR name follows the format [SEDONA-XXX] my subject.

What changes were proposed in this PR?

Add RS_Rotation
Add GeoTransform (Java code only, didn't port to spark)

How was this patch tested?

Passed new tests

Did this PR include necessary documentation updates?

Yes, I have updated the documentation update.

@furqaankhan Is the result identical to PostGIS?

Yes it is.

@jiayuasu I want to get Kristin's opinion before merging, so don't merge yet.


Chaining hints

Combinator functions make_chain_mt() and make_chain_tt() need an additional argument for a hint function from the framework paper. This function chooses an intermediate distance so that relations can be chained.

[x] Specify APIs
[x] Implement chaining logic
[x] Add forward/backward map functionality
[x] Add convenience constructors using stability constant
[x] Update existing operations to generate relations with maps
[ ] Write unit tests

Closing this manually.


moving website to main branch?

FYI it is currently in a separate branch
https://github.com/AIRCentre/JuliaEO/tree/website

If we wanted to go further, I might suggest
https://github.com/tlienart/PkgPage.jl

This is on purpose.

On 18 Jan 2023, at 05:10, Gael Forget @.***> wrote:
FYI it is currently in a separate branch
https://github.com/AIRCentre/JuliaEO/tree/website
—
Reply to this email directly, view it on GitHub https://github.com/AIRCentre/JuliaEO/issues/38, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPZ7WPZ4M5EKUKA6QDKJMDWS6CNFANCNFSM6AAAAAAT6VYH4A.
You are receiving this because you are subscribed to this thread.

This is on purpose.

I don't recall the reasoning behind this.
Using a separate branch seems

kind of complicated to handle; easy to overlook that there is a website branch too
harder to acknowledge contribs, archive, and maintain via standard GitHub actions

No?


Integrate wasm-utils into nitro-protocol

I propose that we tackle converting our entire stack to use this wasm stuff in a separate PR. That should

make it much easier to avoid accidentally using some slower utils
share the speed advantages with other applications (e.g. browser wallet)
cut down on thisTypeToThatType gymnastics

and my rationale for separate PR is that there are some questions:

will there be a circular dependency relationship between native-utils and nitro-protocol?
should native-utils actually just be part of nitro-protocol?
will it seamlessly run in the browser?

Originally posted by @geoknee in https://github.com/statechannels/statechannels/pull/2591#issuecomment-698328195

should native-utils actually just be part of nitro-protocol?

I don't think so. There is real overhead in the native-utils package: you must have an appropriate version of rust installed, and when you run yarn install you will compile a crate, for which you probably want a beefy computer to execute quickly, etc...

will it seamlessly run in the browser?

I'd bet (small) money on it!


Update documentation

@mriccell the SECURITY.md file has been updated. Could you please review it? Thank you

Closed due to a large number of conflicts


Farming station not accepting wooden axe.

The farming station doesn't accept wooden axes anymore since I updated to 1.7.10-<IP_ADDRESS>7. It does accept wooden hoes and every axe better than wood.

If you have a mod which modifies the vanilla tools so that they can't mine
trees it won't work.
On Fri, Jan 2, 2015 at 5:15 PM, kokono2<EMAIL_ADDRESS>wrote:

The farming station doesn't accept wooden axes anymore since I updated to
1.7.10-<IP_ADDRESS>7.
—
Reply to this email directly or view it on GitHub
https://github.com/CrazyPants/EnderIO/issues/1561.

I haven't added new mods since I updated to the version of EnderIO in previous post. Mining wood with the wooden axe works perfectly fine.


[SPARK-29203][TESTS][Minor][Follow Up] Add access modifier for sparkConf in SQLQueryTestSuite

What changes were proposed in this pull request?
Add access modifier protected for sparkConf in SQLQueryTestSuite, because in the parent trait SharedSparkSession, it is protected.
Why are the changes needed?
Code consistency.
Does this PR introduce any user-facing change?
No
How was this patch tested?
Existing UT.

Test build #111764 has started for PR 26019 at commit f863334.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/16748/
Test PASSed.

Test build #111764 has finished for PR 26019 at commit f863334.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/111764/
Test PASSed.

Merged to master and branch-2.4.

Thanks, will pay attention next time.


[End-to-End test] Verify properties (disk-format, capacity, attached-to-vm) of a volume at vm and esx. Issue #847, #848 and #824.

This is an extension to an already existing PR -
https://github.com/vmware/docker-volume-vsphere/pull/825#pullrequestreview-13834963
====
This PR covers three issues : #847, #848 and #824
So please review this latest change.
I have tested this latest change by running tests locally on setup consisting of one Esx and two VMs.

The test LGTM. Do we still need #825 ??

@msterin No, we do not need #825 after this PR #831 . I wasn't sure if I can close it hence I left it open for the time being.

@msterin No, we do not need #825 after this PR #831 . I wasn't sure if I can close it hence I left it open for the time being.

Just mention it's replaced by #831 and close it.

need to extend verification highlighted at #835

this is quite old .... any updates ?

spoke to Anup, he is currently working on the change and will update the PR soon.

@ashahi1 seeing some unrelated commits to your PR. You may want to refresh the commit by squashing correctly.

@ashahi1 - if the PR is stil worked on, please close it for now and reopen when it's ready.
If it is ready, then please squash commits properly , as  @shuklanirdesh82  requested (no unrelated stuff please) and ping us to review.

@msterin  Yes, I will squash the commits and ping for review.

@msterin @shuklanirdesh82 @kerneltime  - Please review the changes
Test tries to ssh to photon vm and esx and verifies the capacity, disk format, attached-to-vm fields are same for volume at the vm as well as at the esx.
We do the same steps across both the vms.

@ashahi1  .. The PR description should be refreshed and git hub issues should be linked with this PR.

Also - please squash the commits manually to assure reasonable commit message. or, if you prefer to squash on merge, please make sure the commit message does not have all the leftover from multiple checkpoint commits.


Major fix to subset_to_blocks

Turns out I wasn't actually subsetting in many cases so we were just repeatedly computing over the entire array for every cohort (!)
Incredibly bad regression!

 -          155086             7009     0.05  cohorts.ERA5.track_num_tasks

!!!

       before           after         ratio
     [681cf74b]       [5b4ac42a]
     <v0.5.9>         <fix-subset>
+            2473             3015     1.22  cohorts.Era5MonthHour.track_num_tasks
-        619±80ms         462±50ms     0.75  cohorts.ERA5DayOfYear.time_graph_construct
-           11874             5808     0.49  cohorts.NWMMidwest.track_num_tasks
-       2.67±0.2s         660±40ms     0.25  cohorts.NWMMidwest.time_find_group_cohorts
-      8.33±0.07s         997±90ms     0.12  cohorts.NWMMidwest.time_graph_construct

So small-ish regression for timeseries type cohorts. I should add rechunked versions of these

       before           after         ratio
     [91b6e193]       [b0dfdb04]
     <v0.5.10>        <fix-subset>
+            3208             4208     1.31  cohorts.ERA5MonthHourRechunked.track_num_tasks_optimized
+             765              939     1.23  cohorts.PerfectMonthly.track_num_tasks
+            2473             3015     1.22  cohorts.ERA5MonthHour.track_num_tasks
+            3645             4232     1.16  cohorts.ERA5MonthHourRechunked.track_num_tasks
-              89               80     0.90  cohorts.ERA5MonthHourRechunked.track_num_layers
-              87               78     0.90  cohorts.ERA5MonthHour.track_num_layers
-              24               21     0.88  cohorts.PerfectMonthly.track_num_layers
-             759              585     0.77  cohorts.PerfectMonthly.track_num_tasks_optimized
-            6858             4896     0.71  cohorts.NWMMidwest.track_num_tasks_optimized
-            1104              741     0.67  cohorts.ERA5DayOfYearRechunked.track_num_layers
-             842              509     0.60  cohorts.NWMMidwest.track_num_layers
-            1828             1101     0.60  cohorts.ERA5DayOfYear.track_num_layers
-           11874             5184     0.44  cohorts.NWMMidwest.track_num_tasks
-      11.1±0.02s       1.31±0.03s     0.12  cohorts.NWMMidwest.time_graph_construct

I think these increased number of tasks are reindex_intermediates. I think I could avoid this but that would take some extra graph construction time, note that for PerfectMonthly tasks after optimization is smaller... and number of layers is always smaller.

Looks like the distributed constant memory scheduling negates the need for cohorts in the NWM model case
Still may be of some benefit for downstream pipelines.


Automator: update<EMAIL_ADDRESS>dependency in<EMAIL_ADDRESS>

Generated by Automator - 2022-03-03T18:43:50+00:00

@istio-testing: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio_release-1.13
7f8c7af79e50c3edce06146079ddcd655cd55b84
link
true
/test unit-tests_istio_release-1.13

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test unit-tests_istio_release-1.13

@istio-testing: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.


fix whitespace in refresh bar

Summary
Change whitespace in refresh bar to be an   instead of a ' '.
Ticket Link
https://mattermost.atlassian.net/browse/MM-37426
Related Pull Requests
Screenshots
before:

after:

Release Note
Change whitespace in refresh bar so that it always displays to user.

Hello @neallred,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

After converting to margin based, looks like this on my machine in local:

Deferring QA testing to post merge when we have an actual upgrade to test against. The setup to try to force an upgrade banner to display is too high relative to the smallness of the change.


diffoscope: building suggests to adding "tools" to allowUnfreePredicate

Describe the bug
diffoscope now depends on an unfree package named tools -- a too generic name to be used meaningfully in allowUnfreePredicate.
(Related: the fact that using diffoscope now requires accepting an unfree license is a regression since NixOS 22.11.)
Steps To Reproduce
$ nix-build -A diffoscope
error: Package ‘androidsdk’ in /home/bf/nixpkgs/pkgs/development/mobile/androidenv/deploy-androidpackages.nix:64 has an unfree license (‘unfree’), refusing to evaluate.

       a) To temporarily allow unfree packages, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNFREE=1

        Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+
        (Flake) command, `--impure` must be passed in order to read this
        environment variable.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnfree = true; }
       in configuration.nix to override this.

       Alternatively you can configure a predicate to allow specific packages:
         { nixpkgs.config.allowUnfreePredicate = pkg: builtins.elem (lib.getName pkg) [
             "tools"
           ];
         }

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnfree = true; }
       to ~/.config/nixpkgs/config.nix.
(use '--show-trace' to show detailed location information)

Expected behavior
Packages having somewhat unique names, allowing allowUnfreePredicate to be used meaningfully.
Notify maintainers
@dezgeg @danielfullmer

Bisecting diffoscope eval leads to 9c4e43ab70c506875684619f30d6d16f093e87d5 being the first bad commit (CC @hadilq).

@bjornfor there are different answers on different levels:

tools is the name of that package in the Android SDK, however, I can change the derivation's name to something like androidenv-tools, and if it doesn't break anything I'll create the PR, but first you need to confirm this is what you are asking here.

as far as I remember, androidenv required allowUnfree before I applied any changes, so I don't understand why you found my commit!

I have no clue what's  allowUnfreePredicate!

If none of the above answers are useful, please explain more.

tools is the name of that package in the Android SDK, however, I can change the derivation's name to something like androidenv-tools, and if it doesn't break anything I'll create the PR, but first you need to confirm this is what you are asking here.

Yes, that sounds perfect.

tools is the name of that package in the Android SDK, however, I can change the derivation's name to something like androidenv-tools, and if it doesn't break anything I'll create the PR, but first you need to confirm this is what you are asking here.

If some code relies on the pname, you might want to add meta.mainProgram = "tools" or something, to keep lib.getExe androidDerivationThingy working after changing pname.

I had #221861 for this, but really I had no time with all the work. :/

Please review https://github.com/NixOS/nixpkgs/pull/233461

Should be fixed by https://github.com/NixOS/nixpkgs/pull/233461 (and https://github.com/NixOS/nixpkgs/pull/221861). Closing.


Method split not described in documentation

The method split is missing in the documentation.

Why would it be documented? Jinja lets you call any method an object has by default. Only Jinja-specifics like |... filters and is ... tests are documented.


Avoid errors when the process does not have enough permissions

Sometimes there is not enough permissions to change attributes by fix-permissions. It was for example reported in sclorg/mariadb-container#32. This change should make these warnings disappeared.

I wonder, is there a chance we might mask some future issues when suppressing warnings and errors while running fix-permissions? Nothing comes to my mind right now but in general it seems like a bad idea.
There is also https://github.com/sclorg/s2i-base-container/issues/112 that might get influenced by this change.
How about making fix-permissions take the GID via an argument (would default to 0 so we do not have to change all existing calls) instead? That would get rid of the warnings while additionally making sure the process has the correct access permissions for the files.

I wonder, is there a chance we might mask some future issues when suppressing warnings and errors while running fix-permissions? Nothing comes to my mind right now but in general it seems like a bad idea.

I share the general worry, but thinking more about it it looks to me like the only real issue that we might mask is when some directory we pass to the script does not exist. That's why there is a check if ! [ -e "$1" ] ; then.. But I agree that we never can be sure.

How about making fix-permissions take the GID via an argument (would default to 0 so we do not have to change all existing calls) instead? That would get rid of the warnings while additionally making sure the process has the correct access permissions for the files.

I don't think it would make all errors disappeared, because symlinks mentioned in #112 that point to root-owned files (correctly read-only) would still produce warnings/errors IMO.. the reason of not having enough permissions is different there.

Problem is that the user is not in root group. So it is not possible to chgrp to such group.
@hhorak For example for mongodb-container - adding usermod -a -G root mongodb in Dockerfile solves this issue.

For example for mongodb-container - adding usermod -a -G root mongodb in Dockerfile solves this issue.

Is this something that we want to have/is expected of containers running in Openshift?

How about making fix-permissions take the GID via an argument (would default to 0 so we do not have to change all existing calls) instead? That would get rid of the warnings while additionally making sure the process has the correct access permissions for the files.

Copies of fix-permissins scripts in mongodb-container [1] and postgresql-container [2] also change owner to default image user. This is needed for running using "pure" docker where default group isn't root.
On the other hand changing owner makes sense only in Dockerfile running under root. So +1 taking arguments to fix-permissions.
[1] https://github.com/sclorg/mongodb-container/blob/master/3.2/root/usr/libexec/fix-permissions
[2] https://github.com/sclorg/postgresql-container/blob/master/9.5/root/usr/libexec/fix-permissions

I don't think it would make all errors disappeared, because symlinks mentioned in #112 that point to root-owned files (correctly read-only) would still produce warnings/errors IMO.. the reason of not having enough permissions is different there.

We should not change file attributes of similar files. Warning makes sense in this case IMPOV.

Is this something that we want to have/is expected of containers running in Openshift?

In OpenShift all containers are running under root GID and random UID. That is why all files should be accessible by root group. @bparees Is it right?

In OpenShift all containers are running under root GID and random UID. That is why all files should be accessible by root group. @bparees Is it right?

sort of.  The assemble script actually runs as the default user for the image, and if the default user for the image has specifically assigned groups, then those are the groups they will have, not necessarily the root group.
But if the user is not listed in /etc/groups, then yes they get the root group.

But if the user is not listed in /etc/groups, then yes they get the root group.

@bparees So when running container in OpenShift with "random" UID gets always root GID, or not? Is it possible that "random" UIG will be already listed in /etc/passwd?
Is it problem to add default user to root group from OpenShift POV ?

@bparees So when running container in OpenShift with "random" UID gets always root GID, or not? Is it possible that "random" UIG will be already listed in /etc/passwd?

it's theoretically possible the user could be listed (and thus not have root group permissions) but pretty unlikely.  the assigned/random uid range starts at like 10000 or something.  i've never seen an image that defines user 10000 in their /etc/passwd and /etc/groups files.

Is it problem to add default user to root group from OpenShift POV ?

no i don't think that should be a problem (but again you don't need to add the default user explicitly as long as the default user isn't otherwise already listed.  for most of our images we use the default user 1001, which is why this works ok for us).

no i don't think that should be a problem (but again you don't need to add the default user explicitly as long as the default user isn't otherwise already listed. for most of our images we use the default user 1001, which is why this works ok for us).

In database images default user is different. So without random UID it causes problems.
So solution it to also use 1001 user in database images or to add current default users to root group. @hhorak What to choose?

I prefer to add the default users to the root group, since this issue does not seem worth changing the default user. So, it should remove the need to hide errors in case of chgrp calls, but there is still the issue with files owned by root (https://github.com/sclorg/s2i-python-container/issues/178#issue-203747032) where we see error messages when symlinks point to them, which we still should mitigate somehow.

A fixed solution with suggestions from  https://github.com/sclorg/s2i-base-container/issues/112#issuecomment-293217175 is available.

[test]

Operation not permitted warnings still present in RHEL7 CI as it seems to be testing s2i-* images built upon the wrong version of s2i-base (the PR version is tagged as centos/s2i-base-rhel7 instead of the expected rhscl/s2i-base-rhel7).
Would like to get this fixed and run through the RHEL CI properly before merging.

Operation not permitted warnings still present in RHEL7 CI as it seems to be testing s2i-* images built upon the wrong version of s2i-base (the PR version is tagged as centos/s2i-base-rhel7 instead of the expected rhscl/s2i-base-rhel7).
Would like to get this fixed and run through the RHEL CI properly before merging.

 Build scripts for this image does not support centos/ vs rhscl/ tagging... It used openshift/ namespace for both versions, but after https://github.com/sclorg/s2i-base-container/pull/114 namespace is always centos/ instead of openshift/
I suggest to fix this by using https://github.com/sclorg/container-common-scripts (for example by accepting https://github.com/sclorg/s2i-base-container/pull/121)

@hhorak Please rebase to be able run tests including https://github.com/sclorg/s2i-base-container/pull/122


Update copyright year for alpha17 release

Urgent since this is for todays release

OT: Is this the last alpha before beta1?

Pushed.

Is this the last alpha before beta1?

Yes


Build a module instead of a shared library.

Fix #202.
This commit switches the default type in CMake from SHARED to MODULE.
Two issues have been found.
First issue
I ran into an issue while testing this commit on macOS. Here is the error I got from clang:
clang: error: invalid argument '-compatibility_version 1.0.0' only allowed with '-dynamiclib'

After some investigation, I found out that the SOVERSION and VERSION properties should not be used when building a shared library. This doesn't seem to lead to an error on Linux, but on macOS, it happens to set the following two flags:

-compatibility_version (given by SOVERSION)
-current_version (given by VERSION)

However, CMake uses the -bundle flag when linking, instead of the -dynamiclib flag.
I found a fix by reading the documentation:

For shared libraries, the MACHO_COMPATIBILITY_VERSION and MACHO_CURRENT_VERSION
properties can be used to override the compatibility version and current
version respectively.

Setting these two flags to OFF removes -compatibility_version and -current_version.
Perhaps we should simply remove SOVERSION and VERSION, as they're only meant to be used for shared libraries?
Second issue
OpenSSL has an API to load dynamic objects and libraries called DSO. When loading a provider, a call to dlfcn_name_converter is made to compute the name of the file:
https://github.com/openssl/openssl/blob/79fa5873a9c2f2df392bc4b39146d8db37640118/crypto/dso/dso_dlfcn.c#L253-L280
Reader may notice that OpenSSL appends the macro DSO_EXTENSION to the end of the provider's name.
DSO_EXTENSION is platform-specific: its value is .so on Unix, and .dylib on macOS.
Because we're building a MODULE library here instead of a SHARED library, the output file's extension is .so instead of .dylib. Thus, OpenSSL fails to find the oqs-provider to load.
To solve this issue, I used the SUFFIX property of CMake targets to explicitely specify the extension when building for a XNU-based platform (macOS, iOS, watchOS, etc.).

Thanks for digging so deep to unearth these pretty specific linking options. For MacOS it seems you nailed it! Windows seems to have similar "peculiarities", though (see CI run).

Perhaps we should simply remove SOVERSION and VERSION, as they're only meant to be used for shared libraries?

Conceptually a pretty desirable idea (as the filename will stay fixed) -- just wondering whether there'd then be a (some other) convenient way to see (by looking at the file) which version of oqsprovider it contains? Or would one simply have to load it and query it? Certainly doable. But whichever way it's done, would some form of documentation be advisable in "USAGE.md"? Or would it be preposterous to assume users just getting their hands on an oqsprovider.dylib/so/dll and wanting to know which version it is?

@thb-sb FYI, I just did a trial adapting your "APPLE" code to "MSVC and CYGWIN" (plus some CI changes) and "got lucky": All CI seems to pass now: Could you please check whether this is OK from your side? If so, I'm inclined to merge given the good CI results (in https://github.com/open-quantum-safe/oqs-provider/tree/module). If you'd have an idea why they don't show up in this PR, please let me know.

Merged: Thanks for the contribution, @thb-sb!


RFC: Run decreasing_by tactic on all goals, not each goal

Problem: Interactive termination proofs
Consider the (of course non-terminating) definition:
def foo (n : Nat) : Nat :=  foo (n - 1) + foo n + foo (n + 1)
decreasing_by …

The tactic passed to decreasing_by is currently executed on each recursive call separately, with one goal present. This makes it harder to write these termination tactics individually, for example when different recursive calls need widely different approaches, because whatever you write has to work with all goals at the same time.
As a user I would have expected to be able to focus individual calls with \., like so
def foo (n : Nat) : Nat := foo (n - 1) + foo n + foo (n + 1)
decreasing_by
  · trace_state; sorry
  · trace_state; sorry
  · trace_state; sorry

but here the second \. says “no goals to be solved”.
Solution: One subgoal for each recursive goal
To solve this, the proof following decreasing_by should have the proof obligations for each recursive call as a separate subgoal.
This has a few knock-on effects:
Problem: Mutual recursion and SCCs
If we have a mutual block (or local where, letrec), then Lean will look at all involved definitions, build strongly connected components (SCCs), and derecursify each SCC individually.
It seems technically hard to get all subgoals from these independent definitions into a single TacticM state. Furthremore, the user experience would be bad if the order of subgoals would change, and sorting the subgoals afterwards is tricky.
Solution: Per-function decreasing_by.
A good solution to this problem seems to be to attach the decreasing_by to each function definition, e.g.
mutual
def even : Nat → Nat := …
decreasing_by …

def odd : Nat → Nat := …
decreasing_by …
end

This naturally associates the proofs with the subgoals of that function. It is arguably also more intuitive in cases of letrec or where.
Problem: What happens to terminating_by?
Now that decreasing_by is attached to each function, it would be strange to not do the same for terminating_by.
Solution: Per-function terminating_by
So let’s also move it to per-function. This has the additional effect that we can simplify the syntax and not require the function name as part of the termination hint.
So instead of
mutual
def even : Nat → Nat := …

def odd : Nat → Nat := …
end
terminating_by
  even n => n
  odd n => n

we would write
mutual
def even : Nat → Nat := …
terminating_by n => n

def odd : Nat → Nat := …
terminating_by n => n
end

Problem: Changing the default tactic
At the moment, decreasing_by is used for two similar, but distinct use-cases:

Interactive long termination proofs
Using a tactic for automatic proofs that’s different than decreasing_tactic.

For example, if there is no termination_by clause, and Lean wants to guess the right measure. It’d be silly to apply the interactive proof when Lean is trying out various measures. But if the user has configured a different automatic tactic, then guessing the measure is sensible.
Also, for interactive proofs, red squiggly lines should be placed in the interactive proof, while for automatic proofs, the recursive call that cannot be proven should be highlighted.
Solution: Command to change default decrasing_tactic tactic
This calls for different command/syntax for the two use cases. The proposal is to use decreasing_by for interactive proofs. This means

Applied once to all goals
Error highlighted in the proof
Requires a terminating_by clause, as we cannot guess the order. (Maybe allow to omit if there is exactly one changing parameter).

For temporarily using a different automatic tactic, introduce a command
default_decreasing_by <tac>

that effectively works like termination_by now:

Applied to each goal separately
Errors highlight the recursive call
If not specified, default_decreasing_by is used.

Typical use might be
default_decreasing_by <tac> in
def ackerman …

or
default_decreasing_by <tac> in
mutual
def even …
def odd
end

which should feel familiar to the users (similar to set_option).
This seems to be a serious papercut: Users should have a nice environment to write these proofs interactively. So ideally, the following should hold

When writing decreasing_by proofs interactively, there should be recursive calls for each subgoal.
The grouping-by-SCC done internally by lean should not affect the user (predictable order of subgoals etc.)
When using the default termination tactic.

Open questions

This is a breaking change: Some terminating_by need to be moved, some decreasing_by may become default_decreasing_by … in. Is this worth it? Should we try to find a backward compat way of achieving the goals (at the expense of a possibly worse UX)?

Is there a good way to name each recursive call, either automatically or manually, so that case <name> => can be used? Such names will also come in handy when deriving an induction principle from a recursive definition.
We could say that whenever the recursive call is let-bound, we use the name as case name:
def foo (n : Nat) : Nat :=
  let n1 := foo (n - 1)
  let n2 := foo (n - 2)
  n1 + n2

Too ad-hoc?

Community Feedback
Initial discussion on Zulip (but not much activity).
Impact
Add :+1: to issues you consider important. If others benefit from the changes in this proposal being added, please ask them to add :+1: to it.

Like the idea, but what about mutual recursion? The actual order may not be clear to users. Recall that we compute SCCs.

Hmm, yes, the order may be surprising.
We could sort the MVars by the syntax ref maybe to put them back into source code order? (If MVars remember the ref they were created at or if we pass it separately.)
I'll experiment with multiple SCCs and see.

Hmm, indeed, I didn’t have it on the radar that the termination_by and decreasing_by annotations need to work in cases where they apply to independent recursions. I’ll have to think about that a bit more, also related to the idea of termination_by? etc.
This already causes corner case issues like: If some recursions in the block should be done structurally, and others require a decreasing_by annotation, then you can’t have both, as the presence of decreasing_by makes it always try well-founded recursion:

mutual
def foo : Nat → Nat
 | 0 => 0
 | .succ n => foo n

def bar : Nat → Nat
  | n => if  n = 0 then 0 else bar (n - 1)

end
decreasing_by sorry

Not a problem per se, just an example of the complications to keep in mind here.

Together with Leo I we had an idea for a nice way that solves

the problem of ordering the goals,
the problem that not all functions in a mutual block end up being in the same SCC (and setting up the goal state so that all those unrelated goals are visible) and
the problem of guessing whether the user wants to do interactive proof, or just specify a different default tactic.

We allow the user to specify the tactic/proof keyed by the function it should be used in; like we already do with terminating_by. This way, the internal order of functions does not leak, and it doesn't matter if only some functions are mutually recursive with some others etc.
What would be a good syntax?
One idea is to use | to indicate that we have multiple cases:
mutual
def foo : Nat → Nat
 | 0 => 0
 | .succ n => bar n + bar (n - 1)

def bar : Nat → Nat
  | n => if  n = 0 then 0 else foo (n - 1)
end
decreasing_by
 | foo =>
   · -- first recursive call in foo
   · -- second recursive call in foo
 | bar =>
   · -- first recursive call in bar

It’s a bit verbose and silly if there is only one recursive function, which is a common case. But at least it’s consistent with recursing_by.

By the way, this relates to a syntax nit that I have been meaning to bring up: Why does decreasing_by / termination_by have to handle all the declarations at once? Couldn't these be placed after the respective definition? And then you wouldn't need the foo => part. Like this:
mutual
def foo : Nat → Nat
 | 0 => 0
 | .succ n => bar n + bar (n - 1)
decreasing_by
 · -- first recursive call in foo
 · -- second recursive call in foo

def bar : Nat → Nat
  | n => if  n = 0 then 0 else foo (n - 1)
decreasing_by
 · -- first recursive call in bar
end

They would still be processed together in the same way as is currently, this is just a syntactic change.

That’s a good idea as well. Makes it also much more natural where to place thigns in case of where or letrec. I wonder what the downsides are.

Perhaps both could be supported

I tend to lean towards less options, as having to decide between options itself is a UX cost, so preferrably only if there are strong reasons to have both.
Maybe decreasing_by … should be used for interactive use, and there ought to be another syntax, like a command (possibly scoped with in)
default_decreasing_tactic <tac> in
to locally change the default termination tactic. That could then be used before mutual.
Do we have precedence for “tactic-valued options”?

Ah, one possible reason to have a common decreasing_by is that you probably start many proofs, even interactive ones, with all_goals simp_wf and similar preparation steps. They would have to repeated if we invoke the tactic on each function separately. (But my intuition is that that’s not too bad, and the syntactic clarity and simplicity of per-function decreasing_by still looks good.)

I rewrote the proposal to include some of the ideas from this discussion, in particular

Per-function termination_by and decreasing_by.
Separate `default_decreasing_by for non-interactive proofs.

Is there a concrete syntax proposal in the case of let rec and where yet?

I didn't spell it out yet, but my hope is that both termination_by and decreasing_by will just be attached to the individual function definitions, even if they are in a letrec or where. Do you expect problems with that?

I suppose it would have to be indentation sensitive at least. Indentation would determine whether a clause belongs to the last where or to the top-level function

Ah, I see. I sometimes forget that Lean is less indentation sensitive than it looks like :-)
Do you think that’s feasible and reasonable?

Yes to both I think. At least it's where I, probably, would have tried to put them as a user.

I think it would also be okay to have the termination_by before where for clauses associated to the main declaration.

I made good progress here in #3040, and would like to have some feedback regarding the parsing of termination_by and decreasing_by, in particular after where.
I am currently experimenting with checkColGE before the keyword, see
https://github.com/leanprover/lean4/blob/1bf34f13cc/tests/lean/termination_by_where.lean
for the effect. As long as the user indents either the where or the function definition therein, this works fine: By choosing the right indentation, the use can make sure the termination_by is picked up by the right function.
The corner case that doesn't work if there is no indentation, like in
def Ex9.foo (n : Nat) : Nat := foo (dec1 n) + bar n
where
bar (m : Nat) : Nat := m
decreasing_by apply dec1_lt

Not sure how relevant that is in practice; if the rule otherwise works well and simple, maybe this is ok?
Or is there a better solution for this problem?

My suggestion would be to have the decreasing_by come before the where when applying it directly to the main function. That is:
def Ex9.foo (n : Nat) : Nat := foo (dec1 n) + bar n
decreasing_by apply dec1_lt -- this applies to foo
where
bar (m : Nat) : Nat := m
decreasing_by apply dec1_lt -- this applies to bar

I thought about putting it before the where as well, but it's also a bit odd in the sense that where is a term-level thing and can be attached to arbitrary terms, not just complete function RHSs.
As for migration: the current plan is to move fast and break things, knowing that this is an approach we can only do for so much longer, but can for now. It's basically impossible to support both syntaxes at the same time, because they unfortunately overlap and it's hard to know whether termination_by f g = f is old syntax (applicable to function f) or new syntax (binary fiction). Leo says that some time in the future we'll have to spend the effort here, but not yet.
What would make the migration easier without too much overhead is, I believe, if the keyword termination_by would change, because then at least there would be a clear parse error. So if there is a better keyword that we'll be happy to have switched to, now is a great time for that. Any hidden desires in that direction?
decreasing_on comes to mind; it's a bit more explicit, reads rather nicely as prose (“This function is decreasing on x, and decreasing by omega”), more obviously connected to decreasing_by and it means that stuff ending on by is more consistently a tactic.

I thought about putting it before the where as well, but it's also a bit odd in the sense that where is a term-level thing and can be attached to arbitrary terms, not just complete function RHSs.

It's not though? That would be nice, but that's not the current situation.

As for migration: the current plan is to move fast and break things, knowing that this is an approach we can only do for so much longer, but can for now. It's basically impossible to support both syntaxes at the same time, because they unfortunately overlap

I think it would be okay to have a simpler backup syntax like termination_by* for being able to get to the old syntax. Then it would be possible to do the migration by simply find/replacing termination_by to termination_by* and then use a code action to do the more involved syntax transformation.
I would really like us to start thinking about how to do these things sooner rather than later, because the need for it is not ever going to go away and at least for this change it's worth putting in the effort to automate this to some degree just for the mathlib bump.

It's not though? That would be nice, but that's not the current situation.

Ah, I got confused by the namespace of the Term.whereDecls parser. It seems that I’d have to insert it into various places; at least bothBut I guess you say that we can insert the termination hints into this parser
def declValSimple    := leading_parser
  " :=" >> ppHardLineUnlessUngrouped >> termParser >> optional Term.whereDecls

and
def declValEqns      := leading_parser
  Term.matchAltsWhereDecls
…
@[run_builtin_parser_attribute_hooks]
def matchAltsWhereDecls := leading_parser
  matchAlts >> optional whereDecls

But that’s worth a try! Avoiding the ambiguities with where is certainly desirable; I just wrote an even longr test file for the various indentation combinations, and it would be nice to not have to think about it.

I think it would be okay to have a simpler backup syntax like termination_by* (or even old_termination_by if you want to make it obviously placeholder-looking) for being able to get to the old syntax.

Do you propose that we keep the old (renamed) syntax, so that we don’t have an unhelpful parse error, but rather a helpful elaboration error, but still an error? Or do you want the old syntax to also to still work, which means the internal data strutures and logic have to support both variant at the same time?
Mathlib has 121 occurrences of termination_by, of which only one is a mutual block, and the rest should be fixable with a single sed script. For std I see 34 occurrences; there I sense more where blocks where the declaration has to be moved (if I end up implementing the suggestion above).
Yes, it’s more convenient if you can migrate parsing (or even fully working) code, but I’m not surprised it’s worth the detour at this point.

Do you propose that we keep the old (renamed) syntax, so that we don’t have an unhelpful parse error, but rather a helpful elaboration error, but still an error? Or do you want the old syntax to also to still work, which means the internal data strutures and logic have to support both variant at the same time?

I'd prefer if it still works. It should be relatively straightforward to normalize both syntaxes into one data structure and process them with the new code. My understanding is that this kind of syntactic normalization is a major reason for the DefView et al types in the first place.

Mathlib has 121 occurrences of termination_by, of which only one is a mutual block, and the rest should be fixable with a single sed script. For std I see 34 occurrences; there I sense more where blocks where the declaration has to be moved (if I end up implementing the suggestion above).

I'm also concerned about more than just std + mathlib here: Big CS projects doing formal verification tend to involve complex inductive types and termination measures, so I anticipate a fair amount of breakage in code we don't have much visibility into.

It's certainly doable (although it'd be nicer if the syntaxes wouldn't overlap, and one would not have to rename to _old and then start migrate, e.g. with a different keyword. And it's not just syntax because of the changed semantics of decreasing_by running on all or each goal). It's just a question where to spend resources.

But that’s worth a try!

Trying, in https://github.com/leanprover/lean4/pull/3053, but now stuck with a problem with syntax quotations that it’s too close to bedtime here to understand. If someone wants to have a look and teach me something, that’d be helpful! I’ll comment over there.

I'm also concerned about more than just std + mathlib here: Big CS projects doing formal verification tend to involve complex inductive types and termination measures, so I anticipate a fair amount of breakage in code we don't have much visibility into.

For what it's worth, we're working on a fairly large CS verification project in Lean, and we'd be okay with adopting the new syntax:  https://github.com/cedar-policy/cedar-spec/tree/main/cedar-lean
We do indeed have complex inductive types, but so far, Lean hasn't needed much help proving termination.  We have just 5 occurrences of termination_by and no occurrences of decreasing_by.
If it helps, this is the entry point to our most complex proof so far:  https://github.com/cedar-policy/cedar-spec/blob/main/cedar-lean/Cedar/Thm/Validation/Typechecker.lean

While working on this, I noticed that there is another bit of termination_by syntax polishing that might be worth doing in one go. I’ve opened https://github.com/leanprover/lean4/issues/3081 for that discussion, comments welcome.


Append to body

It would be helpful if there were a prop that would allow the date panel to be placed above all elements instead of inline. This would alleviate a case as such that the datepicker might be hidden/cut off if placed in a fixed/sticky container with a height that is lesser than the size of the date panel and cannot overlap other sibling containers in the whole of the layout. Example of an issue I ran into attached.

.

It would be helpful if there were a prop that would allow the date panel to be placed above all elements instead of inline. This would alleviate a case as such that the datepicker might be hidden/cut off if placed in a fixed/sticky container with a height that is lesser than the size of the date panel and cannot overlap other sibling containers in the whole of the layout. Example of an issue I ran into attached.

.

Hi, i try to made a sample to check it. but it's good work like this. Maybe you can share your template for me to make check that.

StyleSheet:
.main-container{border:solid 10px green; height: 500px;}
.main-header{background:#aaa;  height: 50px;}
.main-header{position:-webkit-sticky; position:sticky; top:0;}
.main-content{background:rgb(129, 60, 60);  color:white; height: 400px;}
.main-footer{background:rgb(98, 75, 230);  color:white; height: 50px;}

HTML:

      <datepicker-lite
      ......
      ></datepicker-lite>

CONTENT

    FOOTER

I am closing this issue. If you still have problem, reopen the issue.


python3.9 support?

failed installing with python3.9 using pip3 install torch-baidu-ctc

兄啊，早就过时了吧这个库。
Bro, this repository is already outdated.


WorkflowMgr: Read exec data with > 1000 steps goes into infinite loop!

check stop condition....

API weirdness: workflowmotitor API does not support _range (it always return ALL steps)


[Provider] Add support for AI21 models

Docs: https://docs.ai21.com/reference/j2-complete-api-ref

Hi @vrushankportkey, can I please work on this issue if its available?

Thank you, @kritikash18  - assigned to you.
Cheers!

Hey. You can start with the complete API. Structure for adding a new provider can be seen under https://github.com/Portkey-AI/Rubeus/tree/main/src/providers. Please let me know if you have any doubts once you go through the code.

Raised #21

Thanks @kritikash18 . Will take a look into this

Hi, joined now...the username is bytecode_bc


Dist-upgrade Ubuntu

https://petervibert.com/wp/upgrading-ubuntu-13-10-to-16-04-lts/

Useless https://github.com/jclaveau/docker-swarm-cluster-kimsufi/issues/16


Fix requirement.txt paths in Makefile

Codecov Report

Merging #7 (261539c) into main (bcd3c5e) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main        #7   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            6         6
  Lines          339       339
  Branches        56        56
=========================================
  Hits           339       339

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 bcd3c5e...261539c. Read the comment docs.

Thanks so much.
Should just be requirements/all.txt.

Thanks so much.


$WELLKNOWN / challenge-response for nginx

The config example for nginx in the README.md doesn't work for me
location /.well-known/acme-challenge {
  alias /var/www/letsencrypt;
}

I just get 403 forbidden errors when i try to access one of the challenge files via a browser and also letsencrypt.sh can't access the challenge files.
But the following config for nginx works for me:
location ^~ /.well-known/acme-challenge {
  alias /var/www/letsencrypt;
}

Not sure if that should be changed or if there could be an other issue preventing the example config for nginx work correctly in my setup.

I'm personally using location /.well-known/acme-challenge { alias /var/www/letsencrypt; }, and I don't have any problems with that. Seems to be a problem with your configuration.


pose export

Hello,
do you plan to create export to TensorRT for yolov8 pose?

Hello,
do you plan to create export to TensorRT for yolov8 pose?

I have no idea to do this.
Is it detection base？

Is it detection base？

Yes.

I have no idea to do this.

I understand, thank you.

@enhany  Good news!
Now support yolov8 pose!
https://github.com/triple-Mu/YOLOv8-TensorRT/tree/main/csrc/pose/normal
Welcome to have a taste and raise some issues.

Very cool. Thank you.
If you can include NMS in tensorrt engine (like in detection engine), it will be wonderful :)


_matchedRoute isn't correct when multiple matches are found

For this test:
const Koa = require("koa");
const Router = require("koa-router");

const app = new Koa();
const router = new Router();

const subRouter = new Router();
// the order these are added doesn't matter
subRouter.get("/:id", (ctx, next) => {
    ctx.body = { path: ctx.path, matchedRoute: ctx._matchedRoute, desc: "sub and id" };
});
subRouter.get("/", (ctx, next) => {
    ctx.body = { path: ctx.path, matchedRoute: ctx._matchedRoute, desc: "sub root" };
});

router.use("/sub", subRouter.routes(), subRouter.allowedMethods());

router.get("/", (ctx, next) => {
    ctx.body = { path: ctx.path, matchedRoute: ctx._matchedRoute, desc: "root" };
});

app.use(router.routes());
app.use(router.allowedMethods());
app.listen(2345, "<IP_ADDRESS>");

I get the following behavior
$ curl localhost:2345/
{"path":"/","matchedRoute":"/","desc":"root"}
$ curl localhost:2345/sub
{"path":"/sub","matchedRoute":"/sub","desc":"sub root"}
$ curl localhost:2345/sub/id
{"path":"/sub/id","matchedRoute":"/sub","desc":"sub and id"}

I'd expect the last test sub/id to return the matched route that's actually generating content.
$ curl localhost:2345/
{"path":"/","matchedRoute":"/","desc":"root"}
$ curl localhost:2345/sub
{"path":"/sub","matchedRoute":"/sub","desc":"sub root"}
$ curl localhost:2345/sub/id
{"path":"/sub/id","matchedRoute":"/sub/:id","desc":"sub and id"}

It looks like https://github.com/alexmingoia/koa-router/blob/master/lib/router.js#L335 isn't correct. It could be as simple as changing it to var mostSpecificLayer = matchedLayers[0], but I'm not familiar enough with the code to know for sure.

This is interesting.
If you add a console log to the subRouter.get("/", line, does it also get called during curl localhost:2345/sub/id? If I recall correctly multiple route handlers can get executed in versions 5 and 7. That may or may not have something to do with it.

The console log doesn't get called. This is koa-router v7.4.0, btw.
Since I'm not calling next in any of my routes that set a body, I wouldn't expect them to chain, I think.

@gregbacchus' solution seems to work well


[Not actually a pull request] Implementation of "for" node

Hi!
Do you plan to work further on this project? I find it interesting to have such a nice templating language as dtl (I'm very used to it) in low-level language like Rust, but it was very difficult for me to implement such a basic node as "for".
What is your opinion on "Value" trait? The only way I could come up with is clone everything even if I don't need to change it. I couldn't design "Value" trait using references, like fn children(&self) -> Box<Iterator<&Value>> instead of fn get_children(&self) -> Vec<Box<Value>>. Is it even possible?
Once again, do you plan to develop this project further? I want to use it in rust server-side experiments but this projects needs to answer lots of questions before it can be really used.

Btw, I'm Russian you can talk to me in Russian if you want to: slnpacifist at gmail dot com

Bad merge request (on changing branch)


MDScreenManager doc: check_tranistion.

Description of the Feature
Newcomer request :-) In the documentation of MDScreenManager [1] please list possible value for check_transition property. This is in detail explained in Kivy docs and transition property does not propagate to MDScreenManager object from ScreenManager (i.e NoTransition set to ScreenManager works as intended but still there is an animation I cannot control in MDScreenManager). So far I will stick to ScreenManager :-)
By the way is there a single PDF documentation for KivyMD just as there is for Kivy? Based on the code itself? That would be awsome to have :-)
Thanks :-)
[1] https://kivymd.readthedocs.io/en/latest/components/screenmanager/#kivymd.uix.screenmanager.MDScreenManager.check_transition
Versions

OS: FreeBSD 13-STABLE.
Python: 3.9.13.
Kivy: 2.1.0.
KivyMD: 1.0.2.

@cederom Unfortunately, I don't quite understand the essence of your question...


hctester40 does not have "create a group" option

[x] Add to an appropriate Epic.

Tester (if different from issue creator):
Site: hcommons-dev.org
URL: https://hcommons-dev.org/groups
Test Account: hctester40
Area (CORE, sites, profiles, groups, general): groups
If issue discovered on dev, does it also exist on prod? no, user has ability to create groups
Describe the issue
I think we've seen this before. User does not have link to create groups on dev.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Optional details, if they seem relevant
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

This is fixed.


Feature Request: Include a linkcard in the final post when using bluesky_cli

Proposal
Please consider including a linkcard in the final post when using bluesky_cli. As an alternative, an additional argument in the bluesky_cli to accept a json file or text so a post will display a link card.

Hi @guidomz
Of course this is possible! Bluesky's link card metadata is returned by https://cardyb.bsky.app, so I just would add an option like --link-card-url.

Wow, thanks so much. You're doing wonderful work.


[Special] Specfun translation into C++

This PR is the first part of translating all of the specfun library in special into the C++ header-only library that can be used with CUDA and other devices. Here I've moved specfun from a C library to a C++ library, which was already substantial work. A follow-up PR will then turn that C++ library into headers in the special namespace.
I set out to only do this for the legendre and spherical harmonic functions. Found it was easiest to just do it for everything at once.
cc @steppi

Amazing! What a delightful surprise. Thanks @izaid. I'll try to get started reviewing this today.

Cheers! I've tried to follow our strategy of leaving the original code as untouched as possible.
I do think this will take several PRs before it's totally finished, as there are various aspects we'll need to deal with. For instance, there is dynamic memory allocation in some of these functions (malloc and calloc), not sure how needed that really is. A lot of it appears to be dynamically allocating for a static (constant) size...

Blank lines added @steppi! If you are happy, feel free to merge. If not, let me know what needs to be done. Once merged, I will do the next bit (moving this into special/special).

Thanks. I'll merge it once CI settles.

Regarding the dynamic allocation, either it can be replaced by a static fixed array or not. CUDA actually can do dynamic malloc, but I think we should avoid. If we truly need dynamic allocation, I think it should be up to the caller to allocate and pass in (in this case, SciPy).

OK, we'll cross the bridge when we come to it.

Haha this is great @izaid ! Thanks a lot.
Regarding the dynamic allocation, that's all on me. I had two issues, i) in F77 everything is on stack, ii) and hence everything is allocated all the time even though they are not used. If this is going to be called in parallel or whatever, you will quickly get to stack overflow for each invocation. Hence I took the least resisting way and converted everything to dynamic memory allocation.
Otherwise 1000 entry arrays to stack is a bit unfair for everything else running on the machine. But I know next to nothing about those functions so please feel free to get rid of them.

Something else I've learned is that some compilers (clang on Mac) really don't like using _Complex and its functions in C++ files.

There is also a discussion going on on the LAPACK repo for possibility of accepting C++ code. In the last months after dealing with many issues, I am of the opinion C++ is really not a good language for future-proofing numerical code especially there is complex numbers involved.
I would be much happier if we can jump directly to something else from C, avoiding C++ completely. But the CUDA point is very hard to object hence I guess I am just ranting here 😅


Support user provided annotations

From @TamalSaha on May 19, 2017 1:39
Users can apply annotations to TPR. Operators will apply these to the underlying Kubernetes objects. For example,
k8sdb.com/annotations.pod: '{"k1": "v1"}'
k8sdb.com/annotations.service: '{"k1": "v1"}'

Copied from original issue: k8sdb/apimachinery#82

This issue was moved to kubedb/project#85


Feature Request: add X-Original-To header to messages

In certain cases like group emails or BCC (Blind Carbon Copy), the destination address may not appear in the email headers visible to the recipient. In the case of BCC, the email server removes the BCC addresses before delivering the email, so recipients can't see them. For group emails, a single email may be sent to a group address, and the individual members of the group may not be listed in the headers.
The actual delivery addresses for these emails are communicated during the SMTP transaction between email servers, and they don't appear in the headers of the individual email messages stored in the recipients' inboxes.
It would be nice to have mox get the delivery address at the SMTP level and add it as X-Original-To header.
Proton Mail has these 3 headers alway present on top:
Return-Path<EMAIL_ADDRESS>X-Original-To<EMAIL_ADDRESS>Delivered-To<EMAIL_ADDRESS>This feature is invaluable, especially when using catchall addresses. With other solutions, I've had to painstakingly sift through all headers, sometimes finding no clues at all.

Return-Path<EMAIL_ADDRESS>X-Original-To<EMAIL_ADDRESS>Delivered-To<EMAIL_ADDRESS>
Would the X-Original-To different from the Delivered-To address in some circumstances?
The Delivered-To header has recently been added with the SMTP "RCPT TO" address during delivery. That's this commit: https://github.com/mjl-/mox/commit/0fc59af9a82dd5f240032934ac7522efe0328a5a.

If I understand correctly, Delivered-To is a valid address configured for an account.
X-Original-To would be the address the message was sent to.
Example:

<EMAIL_ADDRESS>send a message to<EMAIL_ADDRESS>domain.com has catchall enabled and delivered to<EMAIL_ADDRESS>
Return-Path<EMAIL_ADDRESS>X-Original-To<EMAIL_ADDRESS>Delivered-To<EMAIL_ADDRESS>
This also happens for example if someone has a a gmail account and set up forwarding to an email address hosted by mox.

I looked into X-Original-To a bit more just now. I couldn't find any place that specifies its behaviour. I did find a mention in the postfix documentation about how they treat it, although it is light on details, see https://www.postfix.org/local.8.html:

prepends  an  X-Original-To: header with the recipient address as given
to Postfix, prepends an optional Delivered-To: header  with  the  final
envelope  recipient  address

I'm interpreting that as if X-Original-To is the SMTP MAIL TO, and Delivered-To is the address found after resolving internal rewrites/forwards (so Delivered-To would be the same as X-Original-To if there are no rewrites).
Then we have relatively new experimental RFC 9228, https://datatracker.ietf.org/doc/html/rfc9228. It seems to say local/internal rewrites should also be give their own Delivered-To header for recording, see point 2 in https://datatracker.ietf.org/doc/html/rfc9228#section-4.
In mox, we don't do internal rewrites. And the Delivered-To field must be a valid address, so we cannot have the mox-internal catchall address there. Mox always sets it to the SMTP RCPT TO address.
I don't think the<EMAIL_ADDRESS>from your example exists for a mox account. Accounts can have multiple addresses, but there is no primary address for an account. Hypothetically, there could also be one specific address in domainA.example, and a catchall in domainB.example, so it would be weird if an smtp transaction to<EMAIL_ADDRESS>would result in a header "Delivered-To<EMAIL_ADDRESS>Currently, mox will add just one "Delivered-To<EMAIL_ADDRESS>So that's the address from the SMTP RCPT TO. If mox were to add an X-Original-To, it would currently be the same as Delivered-To.
So unless X-Original-To is required by someone/something (e.g. software that cannot be configured to look at Delivered-To), I currently think it would be better to not add an X-Original-To, especially since there is no specification for its behaviour.


Add support for building a snap

I recently discovered onefetch, and as a command-line nerd and fan of neofetch, I love it :D Thanks for making it. I’m keen to to help you reach more developers building software on Linux.
So I created a snap package of onefetch so it can be featured in the Snap Store, which is a cross-distribution app-store for Linux. Once in the store, it can be easily installed via ‘snap install’ or via GNOME Software or KDE Discover on most distros.
The single snap built from this yaml, once published in the Snap Store will be installable on numerous popular Linux distributions without change. It’ll also be discoverable via the Snap Store, where releases are under your control.
If you're willing to publish this under the onefetch project name, you just need to create an account and then register the onefetch name.
A snap file created by snapcraft (our free software tool for building snaps) can then be released in the Snap Store with snap push --release stable *.snap. You'll want to install snapcraft (brew install snapcraft, snap install snapcraft, or apt install snapcraft) and login (snapcraft login) first, though.
You may also want to consider using https://build.snapcraft.io/ which is a free build service, that can create armhf, amd64, i386, arm64 and other builds of onefetch, and push them to the store automatically. Alternatively it’s possible to integrate publishing the snap via your existing travis CI / release process.
I appreciate you may not be aware of snaps and snapcraft, and I’d of course be happy to answer any questions you may have.

What a mess !
Impossible to build a snap on Manjaro. So I tried with an Ubuntu VM but turns out you cant launch a VM inside a VM...
My last attempt was to use a live USB with Ubuntu burned on it, but my 8GB usb stick wasn't sufficient to install all the packages required.
I guess, you must have an ubuntu machine for this to work properly.
Thanks @popey, I don't want to give up but the frustration is getting too high.


Automatic show/hide team widget

Hello,
Is there a way to automatically hide/show the team widget?
Specifically when I'm hunting solo or not in combat.
Thanks for any information you can give me.

Mmmmm I don't think so, but maybe it can be added as a future update. So you want a specifc widget to hide by pressing a key? Or just hide when you are alone?

Just hide when I'm alone,
Thanks for the responde

@Deigox I've pushed a new update that adds also this feature. I recommend you to do a clean install (just delete all and reinstall). Just modify "DontShowIfAlone": false to true :D

Wow, thanks for the update!!
El lun., 17 de feb. de 2020 20:13, Gabriele Filipponi <
<EMAIL_ADDRESS>escribió:

@Deigox https://github.com/Deigox I've pushed a new update that adds
also this feature. I recommend you to do a clean install (just delete all
and reinstall). Just modify "DontShowIfAlone": false to true :D
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gabrielefilipp/SmartHunter/issues/34?email_source=notifications&email_token=AOQ7ZKLZMMS4DZKYQC3C7V3RDMK3DA5CNFSM4KTMAAW2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL74FZA#issuecomment-587186916,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOQ7ZKL2QPBQ7H4DZPYUO33RDMK3DANCNFSM4KTMAAWQ
.


Forgo resolving pointer addresses

Description

The first 3 commits are a reorganization of TestChain in cardano-ledger-shelley-test.
TestChain is large module that defines and aggregates chain properties pertaining to different rules, as well as defining
functions for working with the trace generation.
This PR splits the module into several cohesive ones, leaving TestChain to contain utilities used by the others.
It also renames and simplifies some functions for testing incremental state (in the newly extracted module IncrementalStake),
in preparation for making the incremental stake computation dependent on PParams.
The next 3 commits are the actual point of this PR: introducing a Hardfork switch that turns off the pointer addresses starting with version 10, for both:  Utxo (IncrementalStake.updateStakeDistribution) and Snap (IncrementalStake.incrementalStakeDistr
The remaining commits deal with making the tests pass with the new switch. For this, a new constant maxMajorPV is controlling the protocol version generated in the trace, which in our case we set to 9, corresponding to the Hardfork switch.
Without this, the tests fail with an Assertion Violation error  in Ledger Rule:

AssertionViolation (ShelleyLEDGER (ShelleyEra C_Crypto))
   Deposit pot must equal obligation (ShelleyLedger)

Checklist

[ x] Commit sequence broadly makes sense
[ x] Commits have useful messages
[ x] New tests are added if needed and existing tests are updated
[ ] Any changes are noted in the changelog
[ x] Code is formatted with fourmolu (which can be run with scripts/fourmolize.sh
[ x] Self-reviewed the diff

Twice in one week?!

:raised_hands:


Remove unused dependencies, add deptry to make sure the dependencies stay up-to-date

Running deptry on the codebase with this configuration

[tool.deptry]
extend_exclude = ["examples", "benchmarks", "outlines/integrations", "outlines/models"]
pep621_dev_dependency_groups = ["test"]

gives:
outlines/fsm/types.py:5:1: DEP003 'typing_extensions' imported but it is a transitive dependency
outlines/generate/api.py:161:16: DEP004 'torch' imported but declared as a dev dependency
outlines/generate/api.py:279:16: DEP004 'torch' imported but declared as a dev dependency
outlines/generate/generator.py:65:12: DEP004 'torch' imported but declared as a dev dependency
outlines/generate/generator.py:205:12: DEP004 'torch' imported but declared as a dev dependency
outlines/generate/generator.py:228:12: DEP004 'torch' imported but declared as a dev dependency
outlines/generate/generator.py:269:12: DEP004 'torch' imported but declared as a dev dependency
outlines/generate/generator.py:304:12: DEP004 'torch' imported but declared as a dev dependency
outlines/samplers.py:67:16: DEP004 'torch' imported but declared as a dev dependency
outlines/samplers.py:147:16: DEP004 'torch' imported but declared as a dev dependency
outlines/samplers.py:177:12: DEP004 'torch' imported but declared as a dev dependency
outlines/samplers.py:202:12: DEP004 'torch' imported but declared as a dev dependency
outlines/samplers.py:287:16: DEP004 'torch' imported but declared as a dev dependency
outlines/types/email.py:3:1: DEP003 'typing_extensions' imported but it is a transitive dependency
outlines/types/isbn.py:3:1: DEP003 'typing_extensions' imported but it is a transitive dependency
outlines/types/phone_numbers.py:8:1: DEP003 'typing_extensions' imported but it is a transitive dependency
outlines/types/zip_codes.py:7:1: DEP003 'typing_extensions' imported but it is a transitive dependency
pyproject.toml: DEP002 'datasets' defined as a dependency but not used in the codebase
pyproject.toml: DEP002 'ray' defined as a dependency but not used in the codebase
Found 19 dependency issues.

For more information, see the documentation: https://deptry.com/

This PR proposes to fix these issues. In addition, it proposes to remove pyairports and pycountry, since their imports are wrapped in a try-except block:
try:
    from pyairports.airports import AIRPORT_LIST
except ImportError:
    raise ImportError(
        'The `airports` module requires "pyairports" to be installed. You can install it with "pip install pyairports"'
    )

This PR also proposes to add deptry to the CI/CD pipeline to make sure the list of dependencies stays up to date.
Feel free to let me now your thoughts on this PR, or to close the PR if you think it is not a useful addition.
Disclaimer: I am the author of deptry.

I like this idea.
We should fix the errors before adding this to the pipeline though. Additionally, would be good to have documentation in docs/community/contribute.md referencing how to run this command. Currently I need to run deptry ./outlines to avoid errors from .myenv/ and build/.
Do these errors mean we would need to explicitly depend on outlines in pyproject.toml?
outlines/__init__.py:2:8: DEP003 'outlines' imported but it is a transitive dependency
[...]
outlines/types/locales.py:4:1: DEP003 'outlines' imported but it is a transitive dependency
Found 61 dependency issues.

The reason for this, is that when deptry is run within the outlines directory, it cannot find the outlines directory itself. The correct way to solve this would be to update the extend-exclude configuration to not look for imports in the .myenv and build directories. I have updated the PR accordingly.

Thank you for contributing! We are not willing to add additional checks in CI just now, but will re-open should this change.


Issue of INVALID_TOKEN after one hour in samples/ZohoCRM.gs (Refer #197)

Added
// Set prompt to "consent" to ensure a refresh token is retrieved.
.setParam('prompt', 'consent')
Still getting same error after one hour
Please look at this, urgently needed.

Did you reset the service and reauthorize it? You can call Logger.log(service.getToken()); to see if you have a refresh token.

Thanks for responses.
I have reset the service and reauthorize.
authorizationUrl containing both access_type=offline and prompt=consent at the end.
Added Logger.log(service.getToken());
Both access_token and refresh_token returns with other values.
After one hour, message logged
[19-08-24 11:47:48:741 IST] {
"code": "INVALID_TOKEN",
"details": {},
"message": "invalid oauth token",
"status": "error"
}
Again after one hour Logger.log(service.getToken());  returns same values as that was one hour before.
What does that mean?
Ideally  a new access_token should be returned. Right?

Please look at this issue.

I got a solution for this.
I have copied code from "dist" folder to my code.
Changed
var expiresIn = token.expires_in || token.expires ;
to
var expiresIn = token.expires_in_sec || token.expires_in || token.expires ;
at line 720 because Zoho CRM return access token expiration time as expires_in_sec=3600
After this generated token again.
It is now two days, token is not expired.
Thanks for your suggest to include .setParam('prompt', 'consent') while creating service.

Thanks for the catch! Very strange that they use a milliseconds for expires_in. I've applied your fix to the library.


"Circuit Breaker" threshold

In similar spirit to https://github.com/github/saml-ldap-team-sync/issues/6, having some safety precautions around adding/removing large groups of individuals would be very valuable for larger organizations.
For example, after initially syncing a team then setting up this tool to run every 15min in order to continuously sync incremental changes to memberships, I wouldn't expect more than 100 people to ever be added or removed in a single execution.  If so, it's probably a mistake and I'd prefer an exception to be thrown so a human can investigate why such a large change in membership is occurring before it actually occurs.
A possible solution that comes to mind is a "circuit breaker" or some kind of configurable threshold that can be set to say "never add/remove any more than N members at a time".

@timhirsh this is implemented in the new version of the script, which is now a GitHub App. We'll do some additional testing, but the code is available in #33 if you'd like to test it out yourself


chore: Update dependencies to latest versions

Proposed changes

Checklist

[x] Pull request is created against the dev branch
[x] All checks passed (lint, unit, build tests etc.) with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)

Pull Request Test Coverage Report for Build<PHONE_NUMBER>2
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 18.666%

Totals

Change from base Build<PHONE_NUMBER>6:
0.0%

Covered Lines:
375

Relevant Lines:
2009

💛  - Coveralls


Optimize mod_compress.

Codecov Report

Merging #221 into develop will increase coverage by <.01%.
The diff coverage is 54.54%.

@@             Coverage Diff             @@
##           develop     #221      +/-   ##
===========================================
+ Coverage    53.01%   53.02%   +<.01%
===========================================
  Files          219      219
  Lines        21724    21715       -9
===========================================
- Hits         11518    11514       -4
+ Misses        8899     8897       -2
+ Partials      1307     1304       -3

Impacted Files
Coverage Δ

bfe_modules/mod_compress/mod_compress.go
62.06% <54.54%> (+1.65%)
:arrow_up:

bfe_websocket/server_conn.go
76.51% <0%> (-1.52%)
:arrow_down:

bfe_spdy/server_conn.go
78.53% <0%> (-0.45%)
:arrow_down:

bfe_spdy/frame_write.go
50.5% <0%> (ø)
:arrow_up:

bfe_http2/server.go
71.5% <0%> (+0.16%)
:arrow_up:

bfe_util/fixed_pool.go
100% <0%> (+16.66%)
:arrow_up:

Continue to review full report at Codecov.

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


Update +page.svelte

Very minor punctiation error in the second paragraph of the page.
Current state- line 10 has a sentence ending with "!" and ".", i flipped a coin and made the decision to cut the period.

correct choice. Thank you!


Updated to follow Hyper-V branch instead of VMWare Branch

This branch doesn't follow down the Hyper-V branch it is in.

@JustinDevine : Thanks for your contribution to the Azure documentation! The author, @rayne-wiselman, has been notified to review your proposed change.

Hi @rayne-wiselman, please add an appropriate comment so automation can take action. Thanks.

#please-close


Allow overriding extension-based syntax highlighting, and specifying syntax used in unsaved files

My apologies if this issue (or feature) already exists, but I looked through all search results for "syntax" and combed through the command palette before opening a new issue.
Basically, there are lots of times when I use my IDE of choice (VS Code these days, previously ST3) as a quick'n'dirty scratchpad.  Whether I'm copying a code snippet, a JSON payload, or a full script, I typically just double-click in the tab bar to open a new blank document, paste in the code, and then want to parse through it.  Using Sublime Text, it was easy to simply open the command palette, type "js", pick "set syntax: JavaScript", and I was good to go.  Once I was done perusing the contents, I could just close the tab, choose to leave the file unsaved, and I was back to a squeaky-clean workspace.
But with VS Code, it seems like there's no way to specify a syntax other than saving a file with a specific extension.  This means that my previously smooth workflow now has the added requirements of saving the file (that I have no intention of keeping) to disk somewhere, then remembering to go and delete it after I'm done looking through it.
I don't think there's any need to get fancy, like trying to remember syntax overrides on specific files - I'd say that the current behavior of applying the associated syntax highlighting whenever the file is opened is fine. I'd just like to be able to override the automatically-applied syntax after opening, and to be able to apply a syntax to a "new file" without having to save it.

You can use Change Language Mode from the Command Palette (or click on the language in the lower right in the status bar) to do this.

Just as a note, I find that terminology somewhat confusing, as there's
another, unrelated setting for "language." If you don't want to change it,
perhaps you could add a "syntax" alias that opens the same window? Just a
suggestion, it's only that it's been called a "syntax" setting in most of
the editors I've personally. An alias would please both camps, I think.
Thanks for the help!
On Thu, Apr 6, 2017 at 6:45 PM chrmarti<EMAIL_ADDRESS>wrote:

Closed #24135 https://github.com/Microsoft/vscode/issues/24135.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/24135#event-1033140109, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAvR0RlhjQ-jYiEnQOWnIfkjjAOz4aInks5rtWsdgaJpZM4M2F1z
.


⚠ Bofrost.de has degraded performance

In 1fdfea2, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1262 ms

Resolved: Bofrost.de performance has improved in d9cf544 after 7 minutes.