allow undoing autoexpand

it should somehow be possible to undo autoexpand if a snippet autoexpanded when it shouldn't have
I see two options for this
either start a new undo sequence so you can just <c-o>u from insert mode or provide an api to do it which can be mapped to

This is similar to #797, a description for achieving this via api is in there, but I haven't considered just using undo for this. Is it possible to register a new undo-point (?) via lua?

yes looks like this could work for me
regarding your question

I can confirm it works with this hack
local auto_expand = require("luasnip").expand_auto
require("luasnip").expand_auto = function(...)
    vim.opt.undolevels = vim.o.undolevels
    auto_expand(...)
end

I think in the long run an api would be the better solution
for now I just use this (for anyone searching for a solution):
local auto_expand = require("luasnip").expand_auto
require("luasnip").expand_auto = function(...)
    vim.o.undolevels = vim.o.undolevels
    auto_expand(...)
end

Slightly better: set the new undo-point in (/around?) snip_expand, that's the function which actually expands the snippets

I tried both snip_expand and expand_auto,
adding undo point in expand_auto will lead to neovim recording every character you type in an expansion trigger.
local auto_expand = require("luasnip").expand_auto
require("luasnip").expand_auto = function(...)
    vim.o.undolevels = vim.o.undolevels
    auto_expand(...)
end

however, adding undo in snip_expand seems just doesn't work. neovim still undoes everything in a single period of insert.
local auto_expand = require("luasnip").snip_expand
require("luasnip").snip_expand = function(...)
    vim.o.undolevels = vim.o.undolevels
    auto_expand(...)
end

Did I set it wrong? or is there a better alternative?

strange, just doesn't work for me. Are you using an auto-trigger or expand by enter?

autoexpand snippets
I see no reason why you'd want to undo manually expanding snippets
if you do you could just put the vim.o.ul=vim.o.ul inside your mapping to expand

I'm also using autoexpand snippets. Then there might be something wrong in my configs somewhere.

you should be able to just do <c-o>u in insert mode

oh yes, and that worked, but it's a bit not that automatic.

well you could just map that to something

I think in the long run an api would be the better solution for now I just use this (for anyone searching for a solution):
local auto_expand = require("luasnip").expand_auto
require("luasnip").expand_auto = function(...)
    vim.o.undolevels = vim.o.undolevels
    auto_expand(...)
end

this isn't a nice solution though because it sets new undo everytime the function is called

How do you actually implement this solution? like do i just plop this into an init.lua?

How do you actually implement this solution? like do i just plop this into an init.lua?

yes

Hi,
I recently stumbled upon this issue. For me the solution of @max397574 didn't work. On investigating further, I realized that the issue can be resolved by applying the following simple patch:
@@ -363,7 +363,7 @@ local function expand_auto()
 				},
 				to = cursor,
 			}
-		snip = snip_expand(snip, {
+		snip = ls.snip_expand(snip, {
 			expand_params = expand_params,
 			-- clear trigger-text.
 			clear_region = clear_region,

to lua/luasnip/init.lua. If you are interested in changing this, I could submit this as a pull request.
Cheers,
project-repo


Rewrite Connection.Supervisor instead of customized supervisor

Ranch uses a custom supervisor for managing connections. This supervisor keeps track of the number of connections and handles connection limits directly. While it is heavily optimized to perform the task of creating connection processes for accepted connections, it is still following the OTP principles and the usual sys and supervisor calls will work on it as expected.

I'd like to use Supervisor to reach it.
A possible Solution

Use a Conn.Manager to manage the number of connection and sleepers.
regard connection handlers as tasks, and use Task.Supervisor to supervise them. One problem is that the created task process is the handler, handler code don't have tiny control about the process.

A better solution
I can use a gen_server worker to replace connection.supervisor and from the worker start another supervisor to handler socket connection.


"biolink" labels on nodes

We have nodes that have labels "biolink" and "molecularly interacts with".  This is clearly an error of some kind.

can you narrow it down to a specific dataset?

Not obvious, because they don't seem to have any edges

i did not find this occurring in any of the data services datasets.

this is complete for data services datasets. PR is #35


Update Gateway condition types.

Update the condition types and reasons for the Gateway condition type.
Gateways should now expose their state using the Scheduled and Ready
conditions, providing additional information in the reason.
See conditions vocabulary doc: https://docs.google.com/document/d/17WGAL5jjjGHsmDCeMstZ3L5fFp6QGPHrIplQ9LPZ91k
/cc @robscott @danehans @hbagdi

/ok-to-test

/lgtm

Thanks!
/approve


throw e; // process.nextTick error, or 'error' event on first tick

[root@sccups home]# nvm use v0.6.6
Now using node v0.6.6
[root@sccups home]# cd /var/www/vhosts/sccups.com/httpdocs/library/nodejs
[root@sccups nodejs]# node server.js
info  - socket.io started
node.js:201
throw e; // process.nextTick error, or 'error' event on first tick
^
Error: No such module
at Object. (/root/node_modules/cluster/lib/worker.js:14:23)
at Module._compile (module.js:432:26)
at Object..js (module.js:450:10)
at Module.load (module.js:351:31)
at Function._load (module.js:310:12)
at Module.require (module.js:357:17)
at require (module.js:368:17)
at Object. (/root/node_modules/cluster/lib/master.js:12:14)
at Module._compile (module.js:432:26)
at Object..js (module.js:450:10)

I am using node v0.6.6 as well and have exactly the same error:

$ node cluster/examples/single.js

gives exactly the same for me.

Currently cluster doesn't support node > 0.4.

Right, did not check that.
Just saw that since version 0.6, node supports multiple process on its own: http://nodejs.org/docs/v0.6.6/api/cluster.html
On 20.12.2011, at 07:20, Tomasz Elendt wrote:

Currently cluster doesn't support node > 0.4.

Reply to this email directly or view it on GitHub:
https://github.com/LearnBoost/cluster/issues/176#issuecomment-3215129


Fix relative links in kube-prometheus readme

This fixes two relative links, probably made invalid by the repo move.

Thanks!


Support fallback rules

Problem: https://github.com/paritytech/polkadot/blob/3dd9741e77e2ff121990208f6ee1e115adb7e5bf/.github/pr-custom-review.yml#L23 is awkward because it means "all files except ones managed by other rules" and this is achieved by manually excluding conditions from other rules; there should be an automatic and simpler way of achieving the same.
Solution: Allow for a fallback-rule
rules:
  - name: Foo files
    check_type: changed_files
    condition: ^foo/.*
    all_distinct:
      - min_approvals: 1
        teams:
          - foo-team

# The fallback rule matches every file by default and is only attempted if no
# rule is matched for a given file; as it matches every file, it cannot have a
# condition.
fallback-rule:
  min_approvals: 2
  teams:
    - bar-team

Or, more flexibly, allow for a sequence of fallback rules in which the rules are processed in order and stop at the first matched one.
rules:
  - name: Foo files
    check_type: changed_files
    condition: ^foo/.*
    all_distinct:
      - min_approvals: 1
        teams:
          - foo-team

# The fallback rules are processed in order and stop at the first match.
# Fallback rules can't have "exclude" since the processing automatically
# falls through to the next one.
fallback-rules:
  - name: Bar files
    check_type: changed_files
    condition: ^bar/.*
    min_approvals: 2
    teams:
      - bar-team
  # The last rule can't have a condition since it matches everything by
  # default.
  - name: Baz files
    check_type: changed_files
    min_approvals: 2
    teams:
      - baz-team

We don't have a use-case for that


fix: CE-917 enable autoscaling for test

Description
enable autoscaling for test and bump NATS replicas
Fixes # (CE-917)
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

[ ] Successful infra deploy

Checklist

[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Further comments

This PR requires a quota increase for the test namespace before it's merged

@barrfalk


Add a filter to the list of devices to integrate

Filter down the list of devices to just what we want integrated into Home Assistant.

Completes #13


cibuildwheel

hi @mattandahalfew ,
we’ve been using pypa’s cibuildwheel project to make it a lot easier to build binary wheel s for all the variations of operating systems and machine platforms.
would you like a pull request that added this?

Yes, that is fine. Thank you

great! would you also consider changing the license back to something that's MIT compatible? unfortunately,  dedupe can't use the current versions of your library because the GPL license is not compatible with dedupe's MIT license.

I don't think that's something I want to do. I'm willing to make licensing arrangements with individual parties, but I don't think I would change the license to MIT.

totally understand! thanks for considering it and your great work!

as dedupe can


Add multilingual support

A few users were asking if Say supported more languages than English.
Here is a demo of a version that now supports this: https://675f3f8fe1536c187feb1851--speakez.netlify.app/
I've tentatively updated the AudioManager UI to include a model selection dropdown with the following features:

A dropdown menu showing all available Whisper models
Clear descriptions for each model explaining their capabilities and use cases
Visual indicators for English-only vs multilingual models
Clear labeling of beta/experimental models
Automatic handling of multilingual settings based on model selection
Integration with the existing transcriber functionality
Maintained the default model as Xenova/whisper-tiny

Help testing the different options with actual language input is appreciated. I'll otherwise probably try to bring this into Say properly soon.

Updated https://675f6dec3159922e477b54b2--speakez.netlify.app
I've fixed the issue that was preventing the use of models beyond the base size. The problem was in worker.js where it was incorrectly modifying model names by appending ".en" even when the full model name was already properly specified in ModelSelector.tsx.


[BUG] bf16 w/ ZeRO Stage 0 assert

Describe the bug
We need to be able to turn zero off, but it breaks:
assert not (self.bfloat16_enabled and (self.zero_optimization_stage not in {1, 2, 3})), f'bfloat16 mode is only enabled for Zero 1,2,3 currently. got {self.zero_optimization_stage}

So I think that assert should be removed altogether now, which I think will solve this issue.
Thanks.
@jeffra

@jeffra, is this now fixed?


Remove question mark

This removes an item of punctuation (a question mark) that after review I determined was causing an unnecessary double-question-mark situation. Note that formatting, overall layout, and document structure remain unchanged. Punctuation is largely left as-is.
I've not yet updated tests for this change but it works on my machine. Please let me know if you have any questions.

Thank you @fifthposition


[Editor] Add other supported project types to nic

[x] Preferences
[x]  Frameworks
[x] Applications
[ ] Regular bundles (?)
[ ] Others  (?)

Resolved in aa7dd2b which added the rest of the major project types, along with other minor improvements and bugfixes to it.


Change hugepages to be 4 * number of MMIO (PCIe) connected boards

We need to do this for CI and developer machines.
@abhullar-tt @TT-billteng @davorchap

duplicate of #4211


Clean up Directory structure

Is your feature request related to a problem? Please describe.

The Directory Structure really does need to be improved to enhance developer experience on the repository.
Describe the solution you'd like
Something like the Daily dev docs, seems to be a fine layout that can be followed
https://docs.daily.dev/
Describe alternatives you've considered
No response
Additional context
No response

You still working on this @FrancescoXX

Fixed by #355


Nearby map does not show new pins when moving map a little, especially noticeable when zoomed in

There are many nearby items in the forest shown bv this screencast, but Nearby shown none until I move the map far enough.
Similarly, the railroad followed in the screencast has nearby items everywhere all along the way, but Nearby only shows pins in a few areas along the railroad.
https://github.com/user-attachments/assets/e67894c8-c978-4f00-b5c8-ceef50254f75
Maybe the algorithm only checks distance from current "center" when moving. It should load misping pins even when moving just a little (ideally without reloading the pins that were already visible).

@nicolas-raoul
2000 metres from current location has been hardcoded, it is hardcoded in the explore screen as well but in that case it displays the 'search this area' button instead of automatically initiating a search. It's interesting that the Nearby and Explore screens don't share a codebase. I'm not an Android dev so I don't know if that is common, seems like it would be better if it was just the same codebase running in two different modes.
Nearby

Explore

Thanks for checking!
We would need to:

Reduce the 2km to something like 100 meters or even remove it if that makes sense.
Verify that panning the map is rdasonably smooth and loads the missing pins.

Thanks for noticing the duplication! Would you mind filing a new issue about it?
Thanks a lot! 🙂

potentially it would need to be proportional to the zoom level rather than a fixed number, reducing the threshold number too low will have the inverse effect of making small movements trigger too many refreshes/searches at zoomed out levels.

Indeed!

I could have time to look at this over the course of this week, including #5836

@tristan81 Fantastic, thanks a lot! I assign to you for now, if that's OK with you. :-)

My initial testing is that there are deeper changes required here, potentially introducing on device caching of data points or other changes like managing the successive firing of onscroll events that meet the distance threshold. Decreasing the distance threshold or introducing a ratio using zoom level both result in HTTP 500 errors when scrolling more than once within a few seconds. It seems like the server API either can't handle successive search requests within a short time span or there is some kind of throttling where it is refusing successive get requests. This is probably why the distance has been set to 2000m
A user can cause multiple onscroll events to fire faster than the API can return search results

I think we already cache data points.
For the error 500, how about introducing a wait time if the previous request was less than N seconds ago, so that we do not perform more than 1 query per N seconds? We can experiment with various values of N to see what the server supports and what the UX feels like.
Thanks! :-)

what is the significance of the marker/pin colours? Starting off grey and then changing to either red or green

@tristan81 That's good feedback that the meaning is not obvious, I just created https://github.com/commons-app/apps-android-commons/issues/5841 :-)

@nicolas-raoul what do you think about the change?


Don't work in sublime text 2

Hello,
Thanks for best job with this plugin.
The XML have 491800 characters.
The error is this:
Traceback (most recent call last):
File ".\sublime_plugin.py", line 362, in run_
File ".\indentxml.py", line 49, in run
File ".\indentxml.py", line 96, in indent
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 491786
Regards and @goto thanks

Same...
Traceback (most recent call last):
  File "C:\Program Files\Sublime Text 3\sublime_plugin.py", line 549, in run_
    return self.run(edit)
  File "indentxml in C:\Users\tim.clifford\AppData\Roaming\Sublime Text 3\Installed Packages\Indent XML.sublime-package", line 44, in run
  File "indentxml in C:\Users\tim.clifford\AppData\Roaming\Sublime Text 3\Installed Packages\Indent XML.sublime-package", line 77, in indent
  File "indentxml in C:\Users\tim.clifford\AppData\Roaming\Sublime Text 3\Installed Packages\Indent XML.sublime-package", line 96, in indent
  File "indentxml in C:\Users\tim.clifford\AppData\Roaming\Sublime Text 3\Installed Packages\Indent XML.sublime-package", line 93, in indent
  File "./xml/dom/minidom.py", line 1970, in parseString
  File "./xml/dom/expatbuilder.py", line 926, in parseString
  File "./xml/dom/expatbuilder.py", line 221, in parseString
xml.parsers.expat.ExpatError: undefined entity: line 1, column 77

Same
Traceback (most recent call last):
  File "/Applications/Sublime Text.app/Contents/MacOS/sublime_plugin.py", line 556, in run_
    return self.run(edit)
  File "indentxml in /Users/Bobik/Library/Application Support/Sublime Text 3/Installed Packages/Indent XML.sublime-package", line 49, in run
  File "indentxml in /Users/Bobik/Library/Application Support/Sublime Text 3/Installed Packages/Indent XML.sublime-package", line 77, in indent
  File "indentxml in /Users/Bobik/Library/Application Support/Sublime Text 3/Installed Packages/Indent XML.sublime-package", line 96, in indent
  File "indentxml in /Users/Bobik/Library/Application Support/Sublime Text 3/Installed Packages/Indent XML.sublime-package", line 93, in indent
  File "./xml/dom/minidom.py", line 1970, in parseString
  File "./xml/dom/expatbuilder.py", line 926, in parseString
  File "./xml/dom/expatbuilder.py", line 221, in parseString
xml.parsers.expat.ExpatError: mismatched tag: line 1, column 285

on HTML snippet:

Possible workaround:
File -> Reopen with Encoding -> UTF-8
Ctrl+Shift+P -> Indent XML

Hi all,
Cannot comment the original question because there is no sample file attached.
Regarding HTML snippet - the given example is not a valid XML (img tags are not closed), please use XHTML to be able to use this plugin.
Thanks, Alexey.


[stable/grafana] feat: grafana add sa annotations

What this PR does / why we need it:
With the advent of Workload identity it is really important to be able to annotate service accounts. This adds the ability to annotate the Grafana service account.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/chart])

/assign @zanhsieh

/ok-to-test
/lgtm


(FLK-E111) Indentation is not a multiple of four

Description
PEP8 recommends that Python code indentation be a multiple of four.
Occurrences
There are 44 occurrences of this issue in the repository.
See all occurrences on DeepSource → deepsource.io/gh/clement-pages/SunBot/issue/FLK-E111/occurrences/

No more occurrence of FLK-E111


Error while balancing

Hi Anton & Nezar,
I am keep on running into this balancing error while balancing step where it says,
ValueError:  operands could not be broadcast together with shapes (52876,) (52877,)
Sergey has explained me about this error where it is due to one off reporting in cooler file.  Please let me know if this can be fixed. Following is the complete error I get:
`INFO:cooler:Writing indexes
INFO:cooler:Writing info
INFO:cooler:Done
INFO:cooler:Balancing "test-HiC-R1.10000.cool"
multiprocess.pool.RemoteTraceback:
"""
Traceback (most recent call last):
File "/home/lib/miniconda3/lib/python3.6/site-packages/multiprocess/pool.py", line 119, in worker
result = (True, func(*args, **kwds))
File "/home/lib/miniconda3/lib/python3.6/site-packages/cooler/tools.py", line 51, in apply_pipeline
data = func(chunk, data)
File "/home/lib/miniconda3/lib/python3.6/site-packages/cooler/ice.py", line 59, in _marginalize
+ np.bincount(pixels['bin2_id'], weights=data, minlength=n)
ValueError: operands could not be broadcast together with shapes (52876,) (52877,)
"""
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/lib/miniconda3/bin/cooler", line 11, in
sys.exit(cli())
File "/home/lib/miniconda3/lib/python3.6/site-packages/click/core.py", line 722, in call
return self.main(*args, **kwargs)
File "/home/lib/miniconda3/lib/python3.6/site-packages/click/core.py", line 697, in main
rv = self.invoke(ctx)
File "/home/lib/miniconda3/lib/python3.6/site-packages/click/core.py", line 1066, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/home/lib/miniconda3/lib/python3.6/site-packages/click/core.py", line 895, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/home/lib/miniconda3/lib/python3.6/site-packages/click/core.py", line 535, in invoke
return callback(*args, **kwargs)
File "/home/lib/miniconda3/lib/python3.6/site-packages/cooler/cli/balance.py", line 184, in balance
map=pool.imap_unordered)
File "/home/lib/miniconda3/lib/python3.6/site-packages/cooler/ice.py", line 257, in iterative_correction
.reduce(add, np.zeros(n_bins))
File "/home/lib/miniconda3/lib/python3.6/site-packages/cooler/tools.py", line 241, in reduce
return reduce(binop, iter(self.run()), init)
File "/home/lib/miniconda3/lib/python3.6/site-packages/multiprocess/pool.py", line 695, in next
raise value
ValueError: operands could not be broadcast together with shapes (52876,) (52877,) `

this might be related to the two issues discovered by @sergpolly: (a) 1-based indexing in .pairs vs 0-based indexing in .cool and (b) semi-open vs closed intervals in .pairs. (b) is fixed, but wasn't pushed to distiller yet. @nvictus, do you know if (a) is fixed?

By looking at cooler commits, it doesn't seem like (a) is solved on the cooler side.. @nvictus ?
(b) has been pushed to the latest pairsamtools, but the docker-image is not up to date with it ... @golobor ?
PS not need to change anything in distiller-script itself to accommodate this +/-1 bug fix - only dependencies needs updates

@sergpolly , I've lost track of this one, is it solved?

Based on #115 in mirnylab/cooler that should be the case .
Even so, since we are not using pairix by default anymore...
@nandankita ? Have had any problems like this ever since?

Yes, this bug was fixed and I did not encounter this issue ever since.

@nandankita close ?


Links are not enabled - PDFJS undefined

I have a pdf file that contains some links, which point to some specific page within the same pdf document. They are not enabled/clickable when viewing the pdf file. How can it be enabled?
I tried to search and found that it could be enabled by "enabling annotation layer". But all examples I found are using PDFJS object, which I believe is not available in versions 2+.
For example a part of the code I'm trying uses:
 PDFJS.Annotation.fromData(data);
and it breaks, as PDFJS doesn't exist.

To sum it up, I'm trying to enable the links, making them clickable. How can I do this? any help/guideline will be appreciated.
Configuration:

Web browser and its version: Chrome
Operating system and its version: windows 10
PDF.js version: 2.6.347'

Web browser and its version: Chrome

For future reference: Please remember to always specify the version number as well.

PDF.js version: 2.6.347

That version is no longer supported, please find the latest releases at https://mozilla.github.io/pdf.js/getting_started/#download

I'd suggest taking a look at the viewer component examples, see https://github.com/mozilla/pdf.js/tree/master/examples/components, since the contain the necessary components for building a (basic) viewer. Among other things they support text-selection, annotation rendering, and form filling by default.


Mapbox outdoors locked?

I select a new project and Mapbox Outdoors style.
Then go to Layers to add a data source
at the top, it says: "Source locked (custom layer order)" and I cannot change source.
It works with at least with Basic and OSM Bright 2 styles...
Thanks.
Pat.

@yhahn - looking for the link you reference but its broken.

@gagecarto moved to https://www.mapbox.com/guides/style-manual/#custom-layer-order /cc @amyleew

@yhahn I followed your steps and was able to add new layers and apply styles. However, Source is still locked. Is this normal? So if I want to add new layers I add it in my own tileset, upload and then style?


Add pipeline

[WIP]

@vinx13 would be great to add a simple xval cookbook where we use a CPruneVarSubMean transformer before doing PCA and applying k-means on a toy data :D

adding unit test would be great

aaaah and another thing: getter methods for the pipeline elements would be desirable. i.e. get the trained transformer etc.

@lisitsyn @karlnapf so as trying to add pipeline to the swig interface it came out that with is a reserved keyword in python. see the design from 2017 ws: https://github.com/shogun-toolbox/shogun/wiki/Hackathon-2017-base-api#pipeline
how about changing Pipeline.with(Transformer) to Pipeline.over(Transformer), since add and as are kind of taken by SGObject, imo as could still fly but add would be matched. i'm wondering whether then would be a reserved keyword in any languages we support?
and another idea here: imo we should have a Pipeline that is inherited from CMachine, but the builder should be a separate base class, PipelineBuilder.
@vinx13 i would still like to have a builder that supports adding a list of elements. something like: add_stages([transf1, transf1, machine])

@karlnapf we are getting travis problems here as well..... this branch is rebased over HEAD od develop, but octave is throwing this error
error: in method 'Evaluation_evaluate', argument 2 of type 'shogun::CLabels *' (SWIG_TypeError)

error: called from

    /opt/shogun/build/examples/meta/octave/multiclass/cartree.m at line 39 column 10

error: in method 'Evaluation_evaluate', argument 2 of type 'shogun::CLabels *' (SWIG_TypeError)

error: called from

    /opt/shogun/build/examples/meta/octave/binary/linear_support_vector_machine.m at line 42 column 10

the error also happens on python
  4/297 Test #238: generated_python-binary-linear_support_vector_machine ...................................***Failed    0.24 sec

Traceback (most recent call last):

  File "/opt/shogun/build/examples/meta/python/binary/linear_support_vector_machine.py", line 50, in <module>

    accuracy = eval.evaluate(labels_predict, labels_test)

TypeError: in method 'Evaluation_evaluate', argument 2 of type 'shogun::CLabels *'

swig/python detected a memory leak of type 'CBinaryLabels *', no destructor found.


debouce function 'eats' events

First of all; thanks for this great toolkit/component!
Just recently however I found out there seems to be a pretty big issue/bug at the very core.
The implementation of the debounce system bases himself on one single 'timer', if a timer is already running the next debounce call is just ending in doing nothing at all. So the first call is executed after X waittime, and all the next calls are just thrown away. In a typical 'debounce' you would expect the reverse; only the last one should be fired. But that's not the biggest problem...
Once you have 2 and the same events being triggered for multiple purposes the current implementation of 'debounce' will throw away one of the 2 since there is only one timer variable.
Example on how I noticed this behavior and how to simulate it:
Just use the parentIFrame.getPageInfo callback system from without iframe content. That results in 2 'resize' listeners on window on the main page. Now resize your main page; you'll most likely not going to get any 'pageInfo' in the iframe as the 'debounce' method on the main page just threw away that message as there was already a timer running.
Hope my explanation is clear enough.
I think the easiest solution (without too many refactoring) is introduce a 3rd parameter to the current existing debounce method. 3rd parameter should be an ID towards a timer. The timer variable itself should then be an object with a timer per ID and access/test on it by doing timer[ID]. => using this workaround/solution as for now in my local copy of iframeResizer.js and that's looking good
Another possibility is to replace the rebounce method as a whole by for example https://davidwalsh.name/javascript-debounce-function, but that requires quite some refactoring as the result of the that new debounce is a function on itself which should be passed to the listeners.

Hmm the debounce was added long before getPageInfo, so only cared about the frame being resized. Agree getPageInfo should not run through debounce.

Thanks for agreeing on a 'bug' and sorry to bother you again...
Problem can indeed be 'fixed' by removing the rebounce on getPageInfo... But that seems more like an ugly workaround to me, because I believe the rebounce is useful for the getPageInfo callback system. Without it it will fire a lot of events and post message api calls during resizing of the main page/window for nothing. I guess that is also the reason why it is there in the current version.
The only future proof fix imo is to fix the 'rebouce' function/system 'once and for all' (and not limit the use of it).
Greetz

Any updates?
getPageInfo()'s callback not firing when window resized

I'd welcome a PR if anyone wants to fix this.
On Wed, Jul 26, 2017 at 9:33 AM, Jun-ho, Song<EMAIL_ADDRESS>wrote:

Any updates?
getPageInfo()'s callback not firing when window resized
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/davidjbradshaw/iframe-resizer/issues/405#issuecomment-317973276,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkHEkcDmIc4cReS9wUDQKCvlEOP8lxrks5sRuvYgaJpZM4J8gHH
.

--
David J. Bradshaw )'<EMAIL_ADDRESS>

Fixed in v3.6.0


The bottoms of some lines are cut off for some unknown reason

Environment
Windows build number: 10.0.18990.1
Windows Terminal version 0.5.2681.0
Windows Snip & Sketch

Steps to reproduce
When I open a Terminal window, and start writing some commands, some lines doesn't show properly and are truncated. I think the problem might be my current Windows resolution, which I set on 125%
Expected behavior

The most weird thing is that when taking a screenshot with the Windows Tool, everything appears normal on the screenshot like above.
Actual behavior
Here's below what I really see on my screen (when taking a photo of it). For eg., first line is truncated.

Sorry for the image Github doesn't want to turn it anyway but clicking on it shows the photo correctly :)

I also suffer from this and it's very annoying. this has been a persistent issue for me since testing the original release but i only now got around to reporting it (sorry!).  I think it mostly (only?) happens with WSL terminal.

You can see that there is no prompt at the bottom and the scroll bar is all the way down. after reading this issue I realize now that I can ctrl+- to decrease the font size and then it shows up. but eventually you run out of usuable zoom out range.
in case it's important here are my windows display settings:

clear takes to back to the top of the screen.
WT 0.9.433.0
Win10 Pro 1903

Thanks for the tip. The issue doesn’t seems to be present on my system
anymore (since latest update I noticed), but I think it was because my
scale is at 125% and when at 100%, I hadn’t this problem on the Terminal.
But your problem seems a little bit different that mine, and more
embarrassing anyway (!)
Le lun. 17 févr. 2020 à 17:23, Dominik Schneider<EMAIL_ADDRESS>a écrit :

I also suffer from this and it's very annoying. this has been a persistent
issue for me since testing the original release but i only now got around
to reporting it (sorry!). I think it mostly (only?) happens with WSL
terminal.
[image: image]
https://user-images.githubusercontent.com/7461221/74670273-ab8a5700-515d-11ea-845e-64d263d0f2a8.png
You can see that there is no prompt at the bottom and the scroll bar is
all the way down. after reading this issue I realize now that I can ctrl+-
to decrease the font size and then it shows up. but eventually you run out
of usuable zoom out range.
in case it's important here are my windows display settings:
[image: image]
https://user-images.githubusercontent.com/7461221/74670418-ff953b80-515d-11ea-9fdb-6c3247be5a37.png
clear takes to back to the top of the screen.
WT 0.9.433.0
Win10 Pro 1903
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/2968?email_source=notifications&email_token=AKYJWZ3DSTOWKAQS5R7ILZDRDK2XFA5CNFSM4I3SBCQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL67U2Q#issuecomment-587070058,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKYJWZ7YK4JIPWQWEMS72MTRDK2XFANCNFSM4I3SBCQA
.

Hey I must have missed this in my inbox 2 months ago. @verifix-repos Thanks for following-up that your problem went away! It's a shame that we don't know exactly when it was resolved, but there have been a lot of renderer changes since 0.5 that have fixed a bunch of different bugs. This was probably just another artifact of one of the resolved ones.


Add support for Block Explorer URI templates

Different block explorers might have different ways of addressing an address or tx_hash or any other addressable entity.
Given the current scope of the block explorers that we currently support, we assume that most of this addressable entities can be set on the path of the url.
Therefore we propose the following change:
GET /v1/chains/<chain_id>/

{
  ...
  blockExplorerUriTemplates: {
    "address": <string>, // eg.: https://etherscan.io/address/{{address}}
    "txHash": <string> // eg.: https://etherscan.io/tx/{{txHash}}
  }
}

The clients would then replace the agreed pattern with its correct value.
Open Questions
1. What would be the pattern?
I thought about having {{address}}, or {{txHash}} but this needs to be aligned with the client teams.
2. What should be initial level of support for the different templates?
I'm under the assumption that the clients use a block explorer for both the address and txHash. Is there any other entity that can and should be added to the payload? (eg.: block number: https://etherscan.io/block/{{blockNumber}})
@gnosis/safe-android @gnosis/safe-ios @gnosis/safe-web @gnosis/safe-services

LGTM.
Should we use the plural form for blockExplorerUriTemplates?

LGTM.
Should we use the plural form for blockExplorerUriTemplates?

Isn't it already that way? blockExplorerUriTemplates
Or maybe I misunderstood your question 😅

Yes, I mean why not blockExplorerUriTemplate

I agree. Updated:
GET /v1/chains/<chain_id>/

{
  ...
  blockExplorerUriTemplate: {
    "address": <string>, // eg.: https://etherscan.io/address/{{address}}
    "txHash": <string> // eg.: https://etherscan.io/tx/{{txHash}}
  }
}


Fix response on committing cursor

Wrong status code was being checked

Codecov Report

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

@@            Coverage Diff             @@
##           master      #58      +/-   ##
==========================================
+ Coverage   74.15%   74.35%   +0.19%
==========================================
  Files          22       22
  Lines         503      503
  Branches        8        8
==========================================
+ Hits          373      374       +1
+ Misses        130      129       -1

Impacted Files
Coverage Δ

...n/scala/org/zalando/kanadi/api/Subscriptions.scala
69.26% <ø> (+0.43%)
: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 4815170...a69b570. Read the comment docs.


[DNM] test parquet complex datatype

What changes were proposed in this pull request?
(Please fill in changes proposed in this fix)
(Fixes: #ISSUE-ID)
How was this patch tested?
(Please explain how this patch was tested. E.g. unit tests, integration tests, manual tests)
(If this patch involves UI changes, please attach a screenshot; otherwise, remove this)

note 4 unit tests failed
char type values should be padded: nested in map value *** FAILED ***
char type values should be padded: nested in both map key and value *** FAILED ***
char type values should be padded: nested in map key *** FAILED ***
 SPARK-18053: ARRAY equality is broken *** FAILED ***

@yma11 Can you report the issue to Velox thread?

@yma11 Can you report the issue to Velox thread?

Sure. Let me take a look at the root cause first.

@yma11 if all spark UT of complex parquet scan passed, let's remove the flag: spark.gluten.sql.complexType.scan.fallback.enabled
From customer side, we already verified the complex type works

The previous issue is valid and I proposed a fix in upstream. I will remove the flag once the fix accepted.


Add check-latest flag

Description:
In scope of this pull request we add support for check-latest flag.
Related issue: https://github.com/actions/virtual-environments-internal/issues/1942
Check list:

[ ] Mark if documentation changes are required.
[x] Mark if tests were added or updated to cover the changes.

The default should be true, not false. If someone wants to avoid checking for latest update, that may be ok. But defaulting to that behavior is problematic for many common use cases of setup-java.

Hello. Thank you for your participation and help with improving setup-java. We prefer to keep check-latest flag as false for default cases, because we want to reduce task duration that is why we prefer to use our  image cache as much as possible. Related comment.

Is there some other place or forum where these discussions and decisions are being made? Who is the team making the decisions? Can I join that team?
Given the dramatic impact proposed with this change, and in a few related changes that seem to be taking shape, a more transparent process that would allow significantly more user input prior to making final choices would be beneficial.

@giltene

The default should be true, not false. If someone wants to avoid checking for latest update, that may be ok (although I don't see why anyone would choose to do that, ever)

It's important to keep in mind the use-case we're trying to optimize here for. Since late last year our hosted-images come with a few versions of Java from adopt. There are no versions of Java from Zulu that are cached for a while now (there used to be versions of Zulu that were cached but we switched over): https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md#java
How often are these versions of adopt that are cached updated? Since October of last year, they've been updated 3 times and on average it takes ~4 days for our images to get updated with the latest versions and roll-out to everyone. Sometimes this update process takes more, sometimes it takes less.
If a cached version of adopt is used vs downloaded from scratch, the time benefit is ~0s vs ~20s. If check-latest is set to true during these update times then the setup-java step would all of a sudden take a longer period of time (not ideal experience for users). Also the time benefit of this cannot be understated from a compute perspective for hosted runners that Github manages. 20 seconds doesn't sound like much, but if you factor in the millions of runs, and VMs in hosted that we have to spin up, re-image etc. 20 seconds each on a common setup action is a pretty big deal. By setting check-latest to true there would be no benefit for us.
So for hosted runners that use setup-java, the benefit for check-latest being false is pretty clear to me. If you're using another vendor then it makes no difference if check-latest is false or true on hosted since the distribution will have to be downloaded from scratch every single time since nothing else is cached.
For self-hosted runners there is a slightly different use case and I would argue that it makes sense to have check-latest set to true if you want the latest and greatest. However, we don't have a flag or env variable or anything that denotes something like isSelfHosted. The discussion has come up in a few other first party actions if we should have different behaviors for actions that are on hosted vs self-hosted and the answer that came up was no. This could be problematic for matrix builds for example that have some self-hosted runners and some hosted. So for consistency we just said no difference in behavior vs self-hosted and hosted across the board.
That being said, check-latest being false for self-hosted isn't all that bad and I think the pros still outweighs the cons (some might say this doesn't, and that's fair, but for us optimizing for hosted is orders of magnitude more important). Why?

Currently setup-java V1 behaves as if check-latest is set to false. No breaking changes with V2 here. This just gives users more flexibility
I like to see it almost as an auto-update flag. Having your builds start failing all of a sudden because a java distribution auto-updated could prove problematic, so pinning to a cached version always is a more "stable" CI environment. If someone does want the latest version then that is something they should opt-in to.
In setup-node there is also a check-latest option that has been around for a while, and it's worked great. It's set to false so for consistency and we with other first-party actions we should do the same: https://github.com/actions/setup-node/blob/main/action.yml#L12-L14 This allows us for

Is there some other place or forum where these discussions and decisions are being made?

The core specs for setup-java V2 are documented in this PR and for the most part that what we're following and implementing: https://github.com/actions/setup-java/pull/97
https://github.com/actions/setup-java/blob/main/docs/adrs/0000-v2-setup-java.md
This check-latest flag was something we figured, why not? Let's add this option in for v2 since it has valid use cases and there has been an ask for this feature for a while, we can squeeze it in and it will be a nice "cherry-on-top".

Given the dramatic impact proposed with this change

For hosted this would have no change and it would clearly benefit us while for self-hosted it behaves just like V1 so IMO characterizing this change as dramatic is a bit of an overstatement

@konradpabjan I'm confused. Since when has (or had) the pre-installed Java version of the runner anything to do with this action? Does (or did) the action take advantage of the pre-installed Java version, i.e. something like if (version == 11 && distribution == 'adopt' && arch == 'x64') return;?
If the pre-installed version has nothing to do with what setup-java does (which I sincerely hope), then the entire reply is meaningless.

This seems like a strange,, distro-specific, image-dependent, and always-stale (by default) way to address the 20 second startup-due-to-no-caching problem. And it does so by overriding [by default] the specified version spec, and providing a stale (multi-months-old)  version even when the requested version spec says to use the latest update available. Setup-java has one main role: to set up the java version spelled out in SemVer format in the java-version property. It should not have an "and I really mean it" flag that defaults to "off".
Instead, the actual core concern of a 20 second start can be addressed just as well (or to within fraction of a second of) by addressing https://github.com/actions/setup-java/issues/84 directly. I would be happy to do the work to address that one, and to commit to build it such that it will support caching for all distros to avoid distro favoritism arguments.
Since this is definitely a breaking change being proposed in v2 preview, and a dramatic modification to the common use cases and how OpenJDK updates will flow through to testing. The opportunity to "fix it" with a followup breaking change (that will restore semantics to v1 behavior but provide caching benefits to all distros) will not come up again until v3 [if it is allowed to go into v2 in the current, defaul-is-false proposed behavior]. I therefore strongly object to adding this new property and choosing it's initial default behavior to contradict current v1 behavior. The number of [detectable only during certain days in a year] errors and lapses this will likely cause in the existing ~70K workflows that use the existing semantics will be huge if the default is not set yo be compatible with current behavior....

Since when has (or had) the pre-installed Java version of the runner anything to do with this action? Does (or did) the action take advantage of the pre-installed Java version, i.e. something like if (version == 11 && distribution == 'adopt' && arch == 'x64') return;?

Currently it doesn't take advantage of any cached distributions because our images only cache some adopt distributions while V1 only is structured to pull Zulu distributions: https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md#java
There was a time though when our hosted images cached Zulu distributions but we've switched over, see: https://github.com/actions/virtual-environments/issues/1057
Even when Zulu distributions were cached, our tool/directory structure wasn't set up to easily consume and switch between different cached versions so we didn't fully take advantage of this. Part of V2 involves actually using cached distributions on our images when possible to speed up setup and the work has already been done for that.

If the pre-installed version has nothing to do with what setup-java does (which I sincerely hope)

They do. I wholeheartedly disagree with notion that setup actions should avoid anything with pre-installed versions. There are overwhelming benefits. A good example is the work we did with setup-python v2 that we're now trying to bring over to setup-java. There are 6 versions of CPython that are cached on a hosted Image and 3 versions of PyPy (you can think of these as two different "distributions"): https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md#python
There are WAY more versions available than the 9 that are cached on each image and you can download those on the fly, the disadvantage though is that downloading and setting up a version dynamically can take a long time (over a minute on Windows for example!). The setup-python action has thus been optimized to use cached distributions when possible for the most possible versions. The cached versions have a slightly slower update cadence but for the majority of users this is fine and there are ways to get the latest and greatest if you're insistent on using the most up-to-date releases. You can read up how setup-java handles using pre-cached versions here: https://github.com/actions/setup-python#available-versions-of-python
With setup-java you can imagine someone in V2 using version == 11 && distribution == 'adopt and our images have 11.0.10 cached. Now let's assume 11.0.20 comes out. Now, realistically it will take some time to update and test our images with 11.0.20 and we update it eventually, but before that the actions shouldn't differ to download 11.0.20 and effectively disregard whatever is in the cache. When possible we want to use it to make setup as fast as possible. From some of our other actions, users are very vocal about prioritizing faster runs as their biggest requests. If someone really wants 11.0.20 before it's on our image then they can specify check-latest as true with the option in this issue or just specify version == 11.0.20

Instead, the actual core concern of a 20 second start can be addressed just as well (or to within fraction of a second of) by addressing #84 directly. I would be happy to do the work to address that one, and to commit to build it such that it will support caching for all distros to avoid distro favoritism arguments.

Solutions such as those outlined in https://github.com/actions/setup-java/issues/84 aren't optimal because actions/cache still involve a step that downloads from somewhere (although this in theory should be a little bit faster). The absolute fastest solution is to cache the most used distributions on the images directly and use those when possible reducing the most common setup time to ~0s. The 20 second improvement was just one example that I mentioned. With Python there are 9 cached versions while with Java we have 2 that we aren't even using now. The more we add the benefits will increase significantly. We can't cache everything because there is a limited amount of storage on our runners and there is a host of other software that users want cached. So fundamentally the problem we're trying to solve is optimizing for the most common use cases across the board

It should not have an "and I really mean it" flag that defaults to "off".

The most common asks that we've overwhelmingly seen are people wanting faster builds which is why the default is off. If you're an open source repo or organization that really needs the latest updates of Java as soon as possible always, then you an easily opt-in, but most users that we've seen don't fall into that bucket. There will be documentation added for this like in setup-python that should clear any confusion about how we determine what is used.

Since this is definitely a breaking change being proposed in v2 preview, and a dramatic modification to the common use cases and how OpenJDK updates will flow through to testing

I would like to reiterate that characterizing this change as dramatic is a bit of an overstatement. It's a new release, so it's acceptable to make any breaking changes. If you follow our migration guide and you're currently using v1 with zulu, this change has no impact on hosted runners because there are no zulu distributions that are cached. So checks-latest being either true or false makes no difference whatsoever since a fresh VM will always require a download to take place. Our other actions like setup-node also have a checks-latest flag that defaults to false so this is a pattern we are implementing across the board as it best help optimize the action for the majority of users: https://github.com/actions/setup-node/blob/5c355be17065acf11598c7a9bb47112fbcf2bbdc/action.yml#L12-L14

Since when has (or had) the pre-installed Java version of the runner anything to do with this action? Does (or did) the action take advantage of the pre-installed Java version, i.e. something like if (version == 11 && distribution == 'adopt' && arch == 'x64') return;?

Currently it doesn't take advantage of any cached distributions because our images only cache some adopt distributions while V1 only is structured to pull Zulu distributions: https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md#java

That just states that two random Java versions are installed in the image and that I could run java or javac without installing anything. If I wanted to do that, I wouldn't use setup-java.

There was a time though when our hosted images cached Zulu distributions but we've switched over, see: actions/virtual-environments#1057
Even when Zulu distributions were cached, our tool/directory structure wasn't set up to easily consume and switch between different cached versions so we didn't fully take advantage of this. Part of V2 involves actually using cached distributions on our images when possible to speed up setup and the work has already been done for that.

A cache is something you populate and reuse as long as it isn't outdated, based on a constraint (time, memory, ...). A pre-installed tool on a VM image is NOT a cache. At best you can pre-populate a cache in a VM image.

If the pre-installed version has nothing to do with what setup-java does (which I sincerely hope)

They do. I wholeheartedly disagree with notion that setup actions should avoid anything with pre-installed versions. There are overwhelming benefits. A good example is the work we did with setup-python v2 that we're now trying to bring over to setup-java. There are 6 versions of CPython that are cached on a hosted Image and 3 versions of PyPy (you can think of these as two different "distributions"): https://github.com/actions/virtual-environments/blob/main/images/linux/Ubuntu2004-README.md#python

Python is broken. It needs to be installed and cannot simply be downloaded into a directory and added to $PATH. Please don't use such a broken toolchain as an example.
And again: cache != preinstalled. But it seems that Actions abuses the word cache und thus causes my confusion.

There are WAY more versions available than the 9 that are cached on each image and you can download those on the fly, the disadvantage though is that downloading and setting up a version dynamically can take a long time (over a minute on Windows for example!). The setup-python action has thus been optimized to use cached distributions when possible for the most possible versions. The cached versions have a slightly slower update cadence but for the majority of users this is fine and there are ways to get the latest and greatest if you're insistent on using the most up-to-date releases. You can read up how setup-java handles using pre-cached versions here: https://github.com/actions/setup-python#available-versions-of-python

So is python-versions an indication that there is soon going to be GitHub OpenJDK for Actions? If not, then the point is again that Python is broken.

With setup-java you can imagine someone in V2 using version == 11 && distribution == 'adopt and our images have 11.0.10 cached preinstalled.

Now let's assume 11.0.20 comes out. Now, realistically it will take some time to update and test our images with 11.0.20 and we update it eventually, but before that the actions shouldn't differ to download 11.0.20 and effectively disregard whatever is in the cache. When possible we want to use it to make setup as fast as possible.

Of course it should be fast, but then 11.0.20 needs to be available as soon as api.adoptopenjdk.net gives it back. Days later is too late. Not even apt-get update && apt-get upgrade would be so slow.

From some of our other actions, users are very vocal about prioritizing faster runs as their biggest requests. If someone really wants 11.0.20 before it's on our image then they can specify check-latest as true with the option in this issue or just specify version == 11.0.20

Yes, hurray, I want faster runs too, especially on Macs! But a) not at the cost of having an arbitrary preinstalled version vs. what comes back from api.adoptopenjdk.net. and b) the time for a run is mostly spent in slow builds, probably due to random disk access, not in setup-java. In dnsjava/dnsjava, the JDK setup takes anywhere between 3 to 8s on Ubuntu, and it includes an (unnecessary) download. That is often faster than restoring the Maven cache. On Windows it's 7 to 12s and it's always faster than restoring the Maven cache.
I will definitely always set check-latest: true.

Instead, the actual core concern of a 20 second start can be addressed just as well (or to within fraction of a second of) by addressing #84 directly. I would be happy to do the work to address that one, and to commit to build it such that it will support caching for all distros to avoid distro favoritism arguments.

Solutions such as those outlined in #84 aren't optimal because actions/cache still involve a step that downloads from somewhere (although this in theory should be a little bit faster). The absolute fastest solution is to cache the most used distributions on the images directly and use those when possible reducing the most common setup time to ~0s. The 20 second improvement was just one example that I mentioned. With Python there are 9 cached versions while with Java we have 2 that we aren't even using now. The more we add the benefits will increase significantly. We can't cache everything because there is a limited amount of storage on our runners and there is a host of other software that users want cached. So fundamentally the problem we're trying to solve is optimizing for the most common use cases across the board

And there's again the profound confusion between preinstalled and cache. I don't know what you're basing those 20s on, but with #84 that would come down to probably < 1s. At the benefit of doing what you expect and having smaller, easier maintainable VM images.

It should not have an "and I really mean it" flag that defaults to "off".

The most common asks that we've overwhelmingly seen are people wanting faster builds which is why the default is off. If you're an open source repo or organization that really needs the latest updates of Java as soon as possible always, then you an easily opt-in, but most users that we've seen don't fall into that bucket. There will be documentation added for this like in setup-python that should clear any confusion about how we determine what is used.

Since this is definitely a breaking change being proposed in v2 preview, and a dramatic modification to the common use cases and how OpenJDK updates will flow through to testing

I would like to reiterate that characterizing this change as dramatic is a bit of an overstatement. It's a new release, so it's acceptable to make any breaking changes. If you follow our migration guide and you're currently using v1 with zulu, this change has no impact on hosted runners because there are no zulu distributions that are cached. So checks-latest being either true or false makes no difference whatsoever since a fresh VM will always require a download to take place. Our other actions like setup-node also have a checks-latest flag that defaults to false so this is a pattern we are implementing across the board as it best help optimize the action for the majority of users: https://github.com/actions/setup-node/blob/5c355be17065acf11598c7a9bb47112fbcf2bbdc/action.yml#L12-L14

That just states that two random Java versions are installed in the image and that I could run java or javac without installing anything. If I wanted to do that, I wouldn't use setup-java

One version is certainly there so that something is in PATH by default, but why then would we have to 2 (we can always add more in the future and we probably will)? Same goes for other software that are pre-installed on our images. Why do we have 4 versions of Ruby and 3 versions of Node, the answer is the to speed up the time it takes users to use these tools and to optimize for the most common use cases.

cache != preinstalled. But it seems that Actions abuses the word cache und thus causes my confusion.

The most basic definition of caching that i could find online is store away in hiding or for future use, and that's exactly what we're doing here. There are different ways of caching lets be clear, but we wouldn't have an NPM module called @actions/tool-cache and an env variable and directory on all our runners called RUNNER_TOOL_CACHE if there wasn't some caching of common tools going on behind the scenes.

So is python-versions an indication that there is soon going to be GitHub OpenJDK for Actions? If not, then the point is again that Python is broken.

Please no 😄 There are enough Java distributions out there and the reason why Python is more complex is because for most platforms you can only download the source code (I'm talking officially from Python.org, you can find a host of ready to install versions but we don't want to use that) and it's up to you to actually compile it (which we do with optimizations)

I will definitely always set check-latest: true

That's the thing, it's an option and you can customize it to your needs and as long as it's documented then there shouldn't be an issue. Regarding a sensible default, that's when things get very opinionated depending on how you use Java and Actions. We're making the deliberate decision here to optimize and favor certain use cases over others by our choice


custom .ojs is not standardized, why not use markdown with extensions instead

at first, i love your great work.

but writing .ojs is not so happy.

the drawbacks of ojs:

current ide won't highlight the syntax. writing experience is not happy 🙃
a custom format. put js first. the syntax needs guessing.
look at your examples in .ojs. most contents are already in md. so why not put markdown first, instead of js first?

the benefits of markdown

yes, most ide already support syntax highlighting. 😋
markdown extensions are so common that many users are already familiar with.

especially the popular mdx.
mdx is much easier to both read and write than js.

markdown has popular front matter convention for defining meta data like FileAttachment that can provide extra info but won't be rendered

with the large ecosystem of mdx, we can push this editor even better.

for example, to solve one problem of observablehq.com, that we cannot hide the cell name.

start = new Date("2020-10-01");

the start =  is often unnecessay.

with mdx, u just need to use export const start = new Date("2020-10-01");

in mdx, all import and export won't be rendered by default.
if u want to use the variable, just use it <div>{myVariable}</div>

this is just an example, i haven't considered the implementation details.

another example, for ui views, may be we can write the popular jsx

// instead of

viewof pagesSource = Inputs.textarea({
  rows: 6,
  width: 220,
  label: md`<b>Pages"`,
  value: `Donald_Trump
Mike_Pence
Joe_Biden
Kamala_Harris`,
});

// maybe we can write the popular jsx

<Inputs.textarea rows='6' width='220' {...restProps} />

one more thing, there are so many ui components and other plugins wo can use directly in mdx.

@asg017 do u feel excited 🤗

another option is to write a converter to tranfrom mdx ast to ojs, seems doable 🤔

ya I agree, .ojs right now isn't that great, mostly because it's brand new. There are small things you can do to make it a better experience while developing, like, associating .ojs files with JavaScript in your editor. For example, in VS Code, I have:
"files.associations": {
    "*.ojs": "javascript"
  }

Which associates my .ojs files with VS Code's builtin JavaScript features, like syntax highlighting and autocompletion.
But, .ojs isn't perfectly JavaScript (see Observable’s not JavaScript), so viewof, mutable, and block cells (x = {return 4;}) will erroneously show syntax errors. Autocompletion is based off static analysis on generic JS libraries and not 100% perfect. And prettier/most formatting libraries won't work.
There are other issues on this repo that are tackling some of these problems (mainly #18 for a Dataflow autocomplete features + language server), and I hope to scope out more work for how syntax highlighting, a .ojs prettier plugin, and other ways to make .ojs nicer to work with.
I do like the ideas you bring up here, but there are reasons I want to stick with .ojs. Other people can definitely build things that compile to .ojs (for example, a tool that compiles your jsx example to .ojs, or a custom mdx format that compiles to .ojs). But staying with .ojs makes the Dataflow compiling process very straightforward, any other format would require pre-processing which would add complexity. Also, I want to make it as easy as possible to copy+paste examples on observablehq.com into Dataflow Observable notebooks, so .ojs makes that straightforward.


Index out of bounds exception if you have sql code with just one char in one line.

INSERT INTO [WS].[ProductChannelProperty] (
ProductIntegrationKey,
ChannelIntegrationKey
VALUES(
@ProductIntegrationKey,
@ChannelIntegrationKey
)

This sql code will give a "index out of bounds" exception in Query.Load when you read the last line with ")" and try to check if it's a comment looking for "--" (looking at line[1] which don't exists)

Thanks for the bug report. I pushed this fix and a few other enhancements I've made into another nuget release.

Now I get an System.Data.SqlClient.SqlException : Incorrect syntax instead. The row with ")" is missing from the query.

Sorry about that, fixed.


[BUG] eth_newBlockFilter returns "unknown encoding: 16" error

Describe the bug
Calling eth_newBlockFilter is returning the "unknown encoding: 16" error.
To Reproduce
Steps to reproduce the behavior, e.g.:

Start the relayer following the guide in README.md
Call the rpc method eth_newBlockFilter of relayer endpoint: curl http://localhost:8545 -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":273}'
Check the log of relayer endpoint
See error { "level": 50, "time":<PHONE_NUMBER>243, "pid": 8, "hostname": "af07b2273b3b", "code": "ERR_UNKNOWN_ENCODING", "stack": "TypeError [ERR_UNKNOWN_ENCODING]: Unknown encoding: 16\n at new NodeError (node:internal/errors:371:5)\n at Buffer.toString (node:buffer:809:11)\n at intToHex (file:///srv/aurora/relayer/node_modules/@aurora-is-near/engine/lib/utils.js:29:23)\n at DatabaseServer.eth_newBlockFilter (file:///srv/aurora/relayer/lib/servers/database.js:368:16)\n at processTicksAndRejections (node:internal/process/task_queues:96:5)", "type": "Error", "msg": "Unknown encoding: 16" }

Expected behavior
Call the rpc method eth_newBlockFilter should work

Hi @duongthienduc. We released a fix. Can you please check again.


data['icon'] does not exist for PostType in WP 5.9 / 6.0

https://github.com/craftcms/wp-import/blob/6a776dd5963c0e1c33c00ac0341bfb1c0e4161fa/src/importers/PostType.php#L196
Not sure which version of WP starts exposing the icon via the icon field, but this line seems to be throwing an error at least on WP versions 5.9 and 6.0. Adding a fallback fixes this:
$entryType->icon = $this->command->normalizeIcon($this->data['icon'] ?? 'default') ?? 'pen-nib';

Update: may have been added to the API in 6.2 as per the docs.

Fixed, thanks for reporting!


Visualizations: Move x-axis labels on RxC and 2x2 plots

Move X-axis labels below the axis and don’t show the % on bottom. Also, remove the % and count from the end of the labels.

What's the reason for removing the raw counts and percentages from the x-axis values at the bottom? To me it seems like useful information that can't be gotten anywhere else from the plot or table view (no percentages). I know that's not how the original Shiny plot is or probably how contingency tables are generally. Maybe we could make it an option to turn them on via the plot controls at the bottom of the page (visible on other visualizations)? I have the same feeling about the 0-100% x-axis scale. Thoughts?

Part of the reason to remove the scale from the x-axis is just so it doesn't get in the way of the value labels. I would be ok with an option to turn it on via plot controls at the bottom.
For the x-axis value labels themselves, I think it's a little confusing to have those counts and percentages for that variable when we don't do the same for y-axis values. It also makes the labels longer and harder to read. In theory, we could add that information to the y-axis labels as well, but I think it might be overkill.
@d-callan can add her thoughts

to me, keeping the treatment of the axes as consistent with each other as possible, and with the general expectations for a mosaic plot is important. mosaic plots usually have categorical axes labels, and not a scale representing the percentage. a user familiar w mosaic plots will potentially be confused by this, and one who isnt shouldnt be bothered either way. i tend to think we shouldnt offer it, even as an option. as for the % in the labels, i agree w sheena they feel a bit like theyre cluttering the space, but would be fine w offering those as an option.

Thanks for your comments both! Since there doesn't seem to be consensus or a big drive to keep these extra elements, I'll just go ahead and remove them both as requested at first for now.

Looks good thanks. Going to open a second ticket to add the variable name as an axis label


Another LiveData Error

I am getting an error when using fast-renderer the error seems to happen after server restart. I traced the error to the following Exception from Meteor:
Error
Expected not to find a document already present for an add

packeges/mongo-livedata/collection.js - line 127
        } else if (msg.msg === 'added') {
          if (doc) {
            console.log()
            throw new Error("Expected not to find a document already present for an add");
          }
          self._collection.insert(_.extend({_id: mongoId}, msg.fields));

After removing fast renderer it worked as it should. It seems that this error was caused on login. And maybe because of logintokens that where saved locally or something similar.
I was using meteor <IP_ADDRESS> - please advice me with more information to support you finding the bug.

any updates here? this issue completely prevents me from using fast-render for my app.

Related issue: #80

I'm getting Publish handler for null sent no ready signal error on startup, but my app seems to work fine.
I'm using fast-render as a dependency in a package, which calls FastRender.onAllRoutes.
If user is logged in and refreshes, the error doesn't occur. If use is not logged in I get the above error printed in the server console 4 times each time the client refreshes.

Actually, you've created a publication(probably null) and it didn't call this.ready() within 500 millis.
May be it could be a normal publication as well.
Generally, This happens when a publication takes more than 500 ms to complete.

Thanks @arunoda, I found the problem. I do think the warning is a giving false positive though.
Old version, casing warning:
Meteor.publish null, -> if Roles.userIsInRole @userId, ['admin'] then collections.Posts.find()

New version, warning doesn't occur:
Meteor.publish null, -> if Roles.userIsInRole @userId, ['admin'] then collections.Posts.find() else null

Thanks!

Actually from a publication you must return a cursor. Otherwise sub is
waiting for the this.ready()
So, if there is no cursor, you need to send an empty array or call
this.ready()
We check for null as well. But you should not send null.
On 2015 පෙබ 6, සිකු at ප.ව. 3.50 Chris Hitchcott<EMAIL_ADDRESS>wrote:

Thanks @arunoda https://github.com/arunoda, I found the problem. I do
think the warning is a giving false positive though.
Old version, casing warning:
Meteor.publish null, -> if Roles.userIsInRole @userId, ['admin'] then collections.Posts.find()
New version, warning doesn't occur:
Meteor.publish null, -> if Roles.userIsInRole @userId, ['admin'] then collections.Posts.find() else null
Thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/meteorhacks/fast-render/issues/12#issuecomment-73215773
.

Okay, thanks for the info!

I recently upgraded to Meteor 1.1 and this issue has started happening again. Is it just me?

Same for me!

Getting this too with 1.1 - need to start digging into my publications and find out where I'm not properly returning a cursor.

I nailed down the problem to a null publication (Meteor.publish(null.....). Adding this.ready() in it fixed it.

I found my bad publication as well -- the issue was with Andrew Mao aka Mizzao's userstatus plugin. I changed the publication JS to publish a dedicated name and updated one of my client javascript files to subscribe to that publication.

Same problem here

My problem was with the okgrow:analytics package. It had a null publication that wasn't calling this.ready() when there was no user logged in.

I'm having this issue in production only, but all of my publications return cursors.  I am using the okgrow:analytics package as well @elie222.  Is it possible to keep that package, but still use fast-render?   I removed fast-render for now, but my app runs smoother with it.

It should work with okgrow:analytics now. I think I made a pull request to fix the null publication problem. I do use both packages together

Faced this issue too, in particular in very fast networks (intranet) and very fast computers.
I solved it by simply catching the exception, assuming that if the exception occurred the subscription got ready before fast-render got to load the payload, and therefore fast-render procedures are redundant for that page load.
https://github.com/kadirahq/fast-render/pull/189


Ajax search not returning expected results

As part of the bs5 work, I converted the top-right-corner document search box to be select2-based, i.e., AJAX/JSON-based. I just realized that not all expected results are being shown.
For example, entering rfc900 into the box shows only "RFC900" as a result, but not RFC9000, RFC9001 or any other document containing that string.
Similarly, entering 8312 as a search term finds two I-Ds, but not RFC8312.

This seems to be because this code
https://github.com/ietf-tools/datatracker/blob/main/ietf/doc/views_search.py#L581-L582
doesn't seem to match as I would expect it to. But my database-fu isn't good enough to have opinions on how to fix it.

The difference is in whether you're asking the endpoint to look at Document or DocAlias objects.
In [3]: Document.objects.filter(name__icontains='8312')
Out[3]: <QuerySet [<Document: draft-eggert-tcpm-rfc8312bis>, <Document: slides-110-tcpm-draft-eggert-tcpm-rfc8312bis>, <Document: draft-ietf-tcpm-rfc8312bis>]>

In [4]: DocAlias.objects.filter(name__icontains='8312')
Out[4]: <QuerySet [<DocAlias: draft-eggert-tcpm-rfc8312bis-->draft-eggert-tcpm-rfc8312bis>, <DocAlias: draft-ietf-tcpm-rfc8312bis-->draft-ietf-tcpm-rfc8312bis>, <DocAlias: rfc8312-->draft-ietf-tcpm-cubic>, <DocAlias: slides-110-tcpm-draft-eggert-tcpm-rfc8312bis-->slides-110-tcpm-draft-eggert-tcpm-rfc8312bis>]>

When you are making your call, which model are you specifying? For the search page you're working on, this should always be DocAlias, no?
ps: this will change when we refactor rfcs to be their own document type, and DocAlias will become much less important.
pps : reading this bit of code again, I see we're relying heavily on django to sanitize the user input. Probably reasonable in this case, but we might want to leave a note that we've looked and think it's ok.

I copied the AJAX URL from the milestone edit form, which has the same behavior. I'll check next week if it uses DocAlias.

milestone edit is operation on charters, and it wouldn't make a difference which model it's using, because at the moment we don't have any alias for charters other than their document names.


Detect and report close pairs of records.

When creating star charts for the constellations, it's often necessary to consider close pairs of stars.
The human eye may see a close pair as a single object. In that case, you may want to have the chart reflect what is perceived by the eye, and amalgamate two objects into one.
It's likely useful to generate a list of close pairs present in the catalog, to help people with this task. The limiting distance to use is not well defined.
Ref: https://en.wikipedia.org/wiki/Apparent_magnitude#Magnitude_addition

Strictly speaking, separations are functions of time, because of proper motions.
For the moment, I'm going to ignore that, and calculate separations for the proper motion epoch of Hipparcos, J1991.25.

I've added a new output for the catalog, a secondary file called close-pairs.utf8.


Transfer ownership of FOLIO (project 994) from MWinkler (1353) to PMurray (3316)

@winkler4 has retired from the Open Library Foundation.  Please transfer ownership of https://bestpractices.coreinfrastructure.org/en/projects/994 to me to continue the process.

Done. Thanks!


fix: retry executeStreamingSql when error code is retryable

The streaming call executeStreamingSql is not automatically retried by gax, as the gapic configuration for the call does not specify any error codes that should automatically be retried. Instead, the PartialResultStream is responsible for retrying these calls with the appropriate resume token. Until now, the call was only retried when a valid resume token had been seen for the stream, meaning that if the initial call failed with a retryable error code (e.g. UNAVAILABLE), the
stream would fail with this error. This fix ensures that the call is also retried when the error occurs for the initial call or before the stream has returned a valid resume token.
See also https://github.com/googleapis/nodejs-spanner/blob/09b5c56ed7844514283754235f7203364f01d6ab/test/spanner.ts#L199 for additional tests for retrying streaming errors.
Fixes #620.

Just one question: since

as the gapic configuration for the call does not specify any error codes that should automatically be retried

should we talk to API team to reconsider this?

Just one question: since

as the gapic configuration for the call does not specify any error codes that should automatically be retried

should we talk to API team to reconsider this?

That is certainly an option, but it is something that we in that case should do in sync with all client libraries. I know that the Java and Go client libraries also have custom implementations that retry UNAVAILABLE errors for the executeStreamingSql RPC, and I assume that it is also the case of other languages.


Swagger v2 converter does not use specialized Schema subclasses

The swagger converter just does new Schema, then setType and setFormat manually afterwards.
This prevents consumers from being able to isInstanceOf[StringSchema], requiring isInstanceOf[StringSchema] && schema.getType() == "string" everywhere, defeating the purpose of having those specialized schemas in the first place.

I'm going to take a stab at this, just opening an issue to track the work.

This turned out to be much more straightforward than I anticipated that it would be, due to the structure of PrimitiveType.


Game camera override crashes when closing a running scene.

Godot version:
0edcb8e
OS/device including version:
Win10 64-bit
Issue description:
When running a 2D scene from the editor, and enabling camera override.  If I close the game, it will crash.  Same result as closing 😄,  but maybe there are potential other side-effects and ways to cause the crash.  Haven't tested 3D.

https://github.com/godotengine/godot/blob/d410f5fc80d4149a7e895391a4c42d88b00d1439/core/math/vector2.h#L228-L231

It seems like the transform here is in some unknown state.
https://github.com/godotengine/godot/blob/ce75a2f33d4000e3ecba0fe8281ca335f5528c86/scene/main/viewport.cpp#L821-L830

This is the trace.
 	godot.windows.tools.64.exe!Vector2::operator!=(const Vector2 & p_vec2) Line 230	C++
 	godot.windows.tools.64.exe!Transform2D::operator==(const Transform2D & p_transform) Line 166	C++
>	godot.windows.tools.64.exe!Viewport::set_canvas_transform_override(const Transform2D & p_transform) Line 822	C++
 	godot.windows.tools.64.exe!ScriptDebuggerRemote::_poll_events() Line 827	C++
 	godot.windows.tools.64.exe!ScriptDebuggerRemote::idle_poll() Line 1020	C++
 	godot.windows.tools.64.exe!Main::cleanup() Line 2147	C++
 	godot.windows.tools.64.exe!widechar_main(int argc, wchar_t * * argv) Line 164	C++
 	godot.windows.tools.64.exe!_main() Line 184	C++
 	godot.windows.tools.64.exe!main(int _argc, char * * _argv) Line 196	C++

@rxlecky Maybe you might know what might be going on here.
Steps to reproduce:
Difficult to reproduce outside of my project.
It involves just running a scene, turning on the Camera2D override and then closing the game window.
Minimal reproduction project:
Unable to reproduce this in minimal project.  It may have something to do with the state of the project's current Camera2D, perhaps even it's position in the tree.

@avencherus in the first place, excuse my late response.
On Main::cleanup(), debugger messages are polled one last time before deinitializing the engine. It seems that in your case, somehow, the memory occupied by the root Viewport has already been free'd, but the camera override system is still trying to access it from remote debugger when messages are polled. Can you try placing a breakpoint in the Viewport destructor, as well as in the Main::cleanup()and verify that indeed the ~Viewport() is called before the cleanup?

Sure, no problem.  The ~Viewport() is hit first, then Main::cleanup().

Same vector exception appears.

Still happening in 4.0 after #36244 ?

@faless Nice PR.  I'll try a build from this commit, but I haven't been able to run much in the master so far.  My first experience was a windows related crash, and my second was that my dev PC's video card is too old for Vulkan and also crashes.

Nope.  :(
Won't be able to do anything with 4.0 for probably a while.

I can't reproduce in 4.0 but then again, it might be related to your project. For me, the ~Viewport() is hit after cleanup. Can you post stack traces for both ~Viewport() and Main::clenup()?

Yes, seems like I may have stumbled upon some sort of edge case.  It's not easily reproduced out of context.  When I try to dissect the project, no obvious points of change have been found yet.
Here are the stacks.
>	godot.windows.tools.64.exe!Viewport::~Viewport() Line 3416	C++
 	[External Code]
 	godot.windows.tools.64.exe!memdelete<Viewport>(Viewport * p_class) Line 119	C++
 	godot.windows.tools.64.exe!SceneTree::finish() Line 622	C++
 	godot.windows.tools.64.exe!OS_Windows::run() Line 3164	C++
 	godot.windows.tools.64.exe!widechar_main(int argc, wchar_t * * argv) Line 162	C++
 	godot.windows.tools.64.exe!_main() Line 184	C++
 	godot.windows.tools.64.exe!main(int _argc, char * * _argv) Line 196	C++
 	[External Code]

>	godot.windows.tools.64.exe!Main::cleanup() Line 2140	C++
 	godot.windows.tools.64.exe!widechar_main(int argc, wchar_t * * argv) Line 164	C++
 	godot.windows.tools.64.exe!_main() Line 184	C++
 	godot.windows.tools.64.exe!main(int _argc, char * * _argv) Line 196	C++
 	[External Code]

The same happens to me, this is my log.
Godot Engine v3.2.1.stable.mono.official - https://godotengine.org
OpenGL ES 2.0 Renderer: AMD Radeon(TM) Vega 8 Graphics
Mono: Logfile is: C:\Users\pablo\AppData\Roaming/Godot/mono/mono_logs/2020_03_21 11.08.25 (2760).txt
WARNING: EditorSettings::_get - Property not found: mono/editor/editor_path_optional
At: editor/editor_settings.cpp:151:_get() - EditorSettings::_get - Property not found: mono/editor/editor_path_optional
ERROR: An EditorPlugin build callback failed.
At: editor/editor_node.cpp:5268:call_build() - An EditorPlugin build callback failed.
WARNING: ObjectDB Instances still exist!
At: core/object.cpp:2071:cleanup() - ObjectDB Instances still exist!

@Faless It doesn't appear to affect the master.  Was able to run it, and there are lots of errors in the console just generally, but no crash messages.  This probably only a 3.2 issues.

Have encountered it again, seems as though the viewport is being cleared before this polling function happens. Maybe the fix is to check if scene_tree->get_root() is still valid inside ScriptDebuggerRemote::_poll_events().

That would indeed fix this specific issue but the root cause of the prematurely destroyed root (no pun intended) would still persist and could exhibit elsewhere. I'll try to track down why the cleanup phase is not happening in the correct order.

I'm currently working from 19802f7dc0c6e28c96c58c499a3dcfbee008b0b5

Version: 9adf6d3
I did some debugging this weekend but I couldn't reproduce this issue. I'm pretty sure the original issue - accessing SceneTree after it was deleted - has gone away after @Faless's debugger refactor since the debugger is now checking for whether the SceneTree (now accessible as a singleton) is valid before parsing the incoming debugger messages. Unless message parsing is not happening on the main thread I don't see a way how deleted SceneTree could be accessed from the scene debugger. Can you confirm the debugger messages are always handled on the main thread @Faless?
On top of that, the camera override is currently not working in master so it should not be causing issues. If you come across this behaviour again @avencherus, can you try getting stack trace as you did in the first post? Otherwise, I will consider this issue solved - and perhaps it should be closed until it resurfaces. Since the original issue was posted from the 3.2., though, I'd say this should be fixed in 3.2. - unless @Faless's debugger overhaul was backported to 3.2 as well.

@rxlecky receiving/sending messages can be multi-threaded, but parsing it and taking actions should always be in the main thread.

On top of that, the camera override is currently not working in master so it should not be causing issues.

Weird, it used to work for what I recall. No feature was removed when refactoring it.

unless @Faless's debugger overhaul was backported to 3.2 as well.

No, the changes were not backported.

@rxlecky receiving/sending messages can be multi-threaded, but parsing it and taking actions should always be in the main thread.

Yeah, just what I thought. So I don't see a way this error can be triggered anymore - at least not from the debugger.

Weird, it used to work for what I recall. No feature was removed when refactoring it.

I looked briefly over the code and it seems the problem is that the EditorDebuggerNode::set_camera_override function was not updated to call ScriptEditorDebuger::set_camera_override internally. This seems like an easy fix.

No, the changes were not backported.

Cool, thanks for confirmation

Is this still reproducible in alpha6?

Closing due to lack of response. Please comment if you can still reproduce this bug.
PS: If no minimal reproduction project was included in the original bug report, please upload one as well to ease troubleshooting.


fix no_std

futures-core depends on std by default, but this crate appears to work fine without its default features.
This is preventing futures-concurrency from being no_std and is fixed by the PR.

Thanks!

Deployed in v0.2.9


CI failure：Misspelling of words【./README.md:92: creat ==> create】

The CI failed and the following log was obtained：
Run make lint-code-spell
##[debug]/usr/bin/bash -e /home/runner/work/_temp/51ca66a3-a78a-47bc-84f4-b6f8b74685f6.sh
if ! which codespell &> /dev/null ; then \
  				echo "try to install codespell" ; \
  				if ! pip3 install codespell ; then \
  					echo "error, miss tool codespell, install it: pip3 install codespell" ; \
  					exit 1 ; \
  				fi \
  			fi ;\
  			codespell --config .github/codespell-config
try to install codespell
Collecting codespell
  Downloading codespell-2.1.0-py3-none-any.whl (177 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 177.5/177.5 kB 5.6 MB/s eta 0:00:00
Installing collected packages: codespell
Successfully installed codespell-2.1.0

Notice:  A new release of pip available: [22](https://github.com/spidernet-io/spiderpool/runs/7717752082?check_suite_focus=true#step:5:23).2.1 -> 22.2.2
Notice:  To update, run: pip install --upgrade pip
:
> * By CidrManager, it could automatically creat new ippool for application who needs fixed IP address, and retrieve the ippool when application is deleted. That could reduce the administrator workload.
:
./README.md:92: creat ==> create
make: *** [Makefile:1[24](https://github.com/spidernet-io/spiderpool/runs/7717752082?check_suite_focus=true#step:5:25): lint-code-spell] Error 65
Error: Process completed with exit code 2.
##[debug]Finishing: Run Code Lint

log links
https://github.com/spidernet-io/spiderpool/runs/7717752082?check_suite_focus=true

Screenshots

#515


DEV-14200 Deprecate aws-emr-s3 submodule and use refactored S3 module.

tore out aws-emr-s3 submodule and invocations in root module
removed service role-bound iam policy for logs bucket from aws-emr-iam submodule
incorporated refactored s3 module, terraform-aws-s3, into minimal example

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Issue #442

Renamed the entity services to entity provider (to match the interface name) and unified calls (all end now with semicolons - if available).

Thanks. I am currently on the master branch and am going to sync to the devel branch. Is it stable, or should I hold off until devel is merged into master?

It is stable in the sense that devel is always building, but API-wise it is not stable. Also since in the upcoming version (v.10.0) CSS is dropped (and I think you care about CSS a lot) you should wait until it is fully released (with the next release also AngleSharp.Css will be published - which gives at least the functionality as it is right now).

(But you could theoretically do a git-cherry-pick to get the specific changes.)

Thanks - I will hold off in that case. Are you separating out the CSS assembly? Will it be a separate nuget?

Yes!


pull request for e2e test at 12/29/2016 18:45:06

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


Why scale B1 in this method?

The following code snippet was adopted from function DoB1Scaling:
`function rfGain=DoB1Scaling(PulSeg,dt,ActFA)
global VObj;
flag=zeros(size(PulSeg));
ind=diff(abs(PulSeg));
flag(find(ind<0)+1)=1;
flag(ind>=0)=1;
rfGain=((ActFA/180)pi)/(VObj.Gyrosum(PulSeg.*flag)*dt);`
What's the reason for these operations?

The main purpose of this scaling is to ensure the prescribed flip angle is achieved for some excitation pulses.

Can we make ULF images from this simulator?


merge package from arlac77/npm-package-template

package.json

chore(package<EMAIL_ADDRESS>chore(scripts): cover@#overwrite c8 --temp-directory build/coverage ava && c8 report -r lcov --temp-directory build/coverage
chore(package): add nyc from template
docs(package): remove keyword null
chore(package): set $.ava.require='esm' as in template
chore(package): set $.ava.files='tests/-test.js,tests/-test.mjs' as in template
chore(package): set $.ava.extensions='js,mjs' as in template

Coverage remained the same at 89.502% when pulling 3f771a877e1bb4d480696e51323c9fe2ff94eae6 on template-sync-1 into c68db15c1376e8b53e4f56bb4701b3e2c0561522 on master.

:tada: This PR is included in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


KIP-1071: Broker-side automatic creation of internal topics

First implementation of auto-topic creation of internal topics for KIP-1071. It’s only a sketch, there are some parts missing, unit tests are insufficient, etc. But the draft works end-to-end, automatically creating all required internal topics for a streams application upon initialization, with smoke test integration test passing.

When initializing the topology, the client sends information about the internal topics required for the application. The key concept is that the topology description being sent to the broker is parametric in the number of partitions -- that is, the broker checks the number of partitions for the input partition, and derives the number of partitions for the internal topic. This logic is ported from the existing streams partition assignor.

The basic flow is that, upon receiving the initialize RPC, the group coordinator checks for the right ACL permissions, validates if the request is valid, then updates the topology record in the consumer offset topic, determines the right number of partitions for all internal topics and finally triggers a corresponding CreateTopic request.

Code for generating and validating internal topic configuration lives inside the group coordinator, but the actual creation of the topics is performed from within KafkaApis.

Compared to the schema in KIP-1071, I had to add copartition groups to the initialization call. Copartititon groups are not necessarily the same as subtopologies. For example, if we merge two topics, the two topics are in separate copartition groups but the same subtopology. If we join, they are in the same copartition group. So we need to model copartition groups separately in the RPC, otherwise the broker cannot derive the right topic configurations.

There is a dependency between updating the topology record in the consumer offset topic and creating the internal topics. In case of failures, one could be executed without the other. In this implementation, we update the topology record first, and then create internal topics. The topology record will be the single source of truth. If internal topic creation fails, we need to detect this inside the client. Right now, the heartbeat will respond with error if internal topics are missing. Once we merge the heartbeat and the initialization RPC, we should get the behavior that any attempt to join the group (with a topology description) will also be an attempt to create any missing internal topics.

Surprising, existing RPCs (TopicMetadata and FindCoordinator) auto-create topics asynchronously — so a create topic request is started, but the result is never checked. I followed the same route for this first version, but I intend to change this. You’d have to check the broker logs if internal topics cannot be created. We can do some validation up-front, but the final confirmation that internal topics were created comes from the response of the internal CreateTopics request, so I would like to only respond to the StreamsGroupInitialize once I have received the result of the CreateTopic RPCs.

We need some extra logic for revalidating internal topics. With this change, the set of tasks is defined by the TopicsImage in the group coordinator and the partition-parametric topology description. The group epoch needs to be bumped when either changes, we need to make sure to cache the result of validating and instantiating a topology against a current set of input topics, so that we don’t have to redo it on every heartbeat. After fail-over, we need to reconstruct this cache from the topology and subscription records in the offset topic. This is not fully implemented yet.

@lucasbru FYI we just merged a change where draft PRs will not run the full CI. If you need the junit tests run here, you'll need to mark it ready for review.


Facing test issues for oreintdb:3.2.27 on PPC64LE architecture.

OrientDB Version: 3.2.27
Java Version: ibm-semeru-certified-jdk_ppc64le_linux_<IP_ADDRESS>
OS: NAME="Red Hat Enterprise Linux"
VERSION="8.7 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.7"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.7 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/8/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.7
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.7"
Expected behavior
Test cases should pass.
Actual behavior
[INFO]
[INFO] Results:
[INFO]
[ERROR] Errors:
[ERROR]   ETLJobTest.shouldLoadWithHandler:85 » IllegalArgument Class 'null' not found in database
[INFO]
[ERROR] Tests run: 81, Failures: 0, Errors: 1, Skipped: 1
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for OrientDB 3.2.27:
[INFO]
[INFO] OrientDB ........................................... SUCCESS [  8.740 s]
[INFO] OrientDB Test Commons .............................. SUCCESS [ 25.028 s]
[INFO] OrientDB Core ...................................... SUCCESS [20:24 min]
[INFO] OrientDB Client .................................... SUCCESS [  9.048 s]
[INFO] OrientDB Object .................................... SUCCESS [ 53.731 s]
[INFO] OrientDB Tools ..................................... SUCCESS [ 32.697 s]
[INFO] OrientDB Server .................................... SUCCESS [27:02 min]
[INFO] OrientDB Security Plugin ........................... SUCCESS [  0.490 s]
[INFO] OrientDB GraphDB ................................... SUCCESS [05:48 min]
[INFO] OrientDB Tests ..................................... SUCCESS [07:01 min]
[INFO] OrientDB Distributed Server ........................ SUCCESS [06:47 min]
[INFO] OrientDB Lucene full text index .................... SUCCESS [10:35 min]
[INFO] OrientDB JDBC Driver ............................... SUCCESS [01:32 min]
[INFO] OrientDB ETL ....................................... FAILURE [02:08 min]
[INFO] OrientDB Community Distribution .................... SKIPPED
[INFO] OrientDB Community Distribution Tinker Pop 2 ....... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:23 h
[INFO] Finished at: 2024-01-29T06:41:31Z
[INFO] ------------------------------------------------------------------------

Hi.
Could you provide the output of the test without even having a stack trace of exception? It is really hard to fix such an issue ?

Attaching test failures entire log:
OrientDB_Test_failure.txt

I see. I suppose I understood the reason.
I will fix it in a couple of days. That is a concurrency issue that can be reproduced only on nonx86 architecture.  I do appreciate that you reported it.

I see. I suppose I understood the reason.
I will fix it in a couple of days. That is a concurrency issue that can be reproduced only on nonx86 architecture. I do appreciate that you reported it.

Thanks @laa

@vinodk99 I fixed the issue. Please try again, but be aware of the 3.2.x version is branched off.


Check for hashed version of manifest file

I'm having trouble getting this working on production - locally everything is fine.
The problems seem to stem because of my usage of Whitenoise and CompressedManifestStaticFilesStorage.
If my understanding is correct, I should be able to use this alongside django_vite if I ensure the file names of any Vite generated files stay the same?
This is fine to achieve - but what I can't work out is how I'd find the vite manifest file with the hashed name? If I hard code a manifest path in settings.py it won't have the hash, and it won't use staticfiles.json to locate it.
Could this package introduce some setting that, if enabled, looks for manifest.json via the hashed staticfile name?

I've managed to fix this by ensuring that files hashed by Vite are not hashed again by Whitenoise. I also do not hash the Vite manifest file, meaning the defined path is static.

/cc @emab - q.v this PR https://github.com/MrBin99/django-vite/pull/31 - the Vite files need to be identified by WN as immutable in order to have it set the correct cache-control header.

/cc @emab - q.v this PR https://github.com/MrBin99/django-vite/pull/31 - the Vite files need to be identified by WN as immutable in order to have it set the correct cache-control header.

Ah so without that test was it not caching then properly at all? I was hoping that might have been done at the CDN level. Sorry about that!

np - I know where to send the AWS bill ;-)