Add more options

Thank you for the PR.  The errors in the tests here look to be related to the default values without being specified as undef in common.yaml.


CLA assistant asking me to sign when I've already signed

I tried to sign CLA in my MR https://github.com/zio/zio/pull/8150
I successfully signed it after clicking on link, but nothing happen than.
Also I could not see any signed CLAs, just empty page:
https://cla-assistant.io/my-cla
Could you please help me with this issue?

I tried almost everything - adding and deleting to account all my emails, changing account settings, manually authorizing to CLA assistant - nothing helped.. Could you at least suggest how and where see logs of this check if it possible for me?

Everything seems to be ok:

correct email and name in commit patch https://github.com/zio/zio/commit/342ff36428de4049590f9568158beb60eeda8b5b.patch
this email is my primary email
email is public and available via github api

No ideas at all...

The two commits you created are done from the email<EMAIL_ADDRESS>including the quotes and the quotes are the problem. This is not a valid email.

https://github.com/zio/zio/commit/7e4ee0d5cf2f7a3e9b2bfa29b3323a4e46e22c21.patch
https://github.com/zio/zio/commit/342ff36428de4049590f9568158beb60eeda8b5b.patch

You need to rewrite the two commits to use your proper email (I assume<EMAIL_ADDRESS>then following commands should fix it locally:

git config --show-scope user.email determine where it is set (e.g. global/local/system)
git config --global user.email<EMAIL_ADDRESS>set the email, make sure to use the same flag as you saw previously
git config --show-scope user.email should now show your email without quotes

After fixing the email in your local setup, you need to redo the last two commits and force push the branch.

thank you so much!


The current Node.js LTS 18 is incompatible

When running with the current Node.js LTS 18, the following error is encountered.

<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version " ^14.0.0 || ^16.0.0 ". Got "18.12.1"

Thank you for your report.
Unfortunally, the upstream libsquoosh library does not support Node 18 yet.
I am tracking following issue and support Node 18 when libsquoosh supports it.
https://github.com/GoogleChromeLabs/squoosh/issues/1242

@pekeq
Many thanks for your quick reply.
I see.


another key_mask minor bug

https://github.com/kang205/SASRec/blob/d0b823a1b2845ea90b090eaf6d3386810005b83a/modules.py#L185
tf.abs has no axis parameter, should be tf.reduce_sum(tf.abs(keys), axis=-1)

Thx for pointing it out! Sorry I didn't do the necessary testing before sending the PR, would get it updated soon!

Thanks for pointing out!


26 - Implement support for network performance filtering during recommendations

implemented mechanism for translating provider specific network performance into "internal" categories (the solution abstracts the logic from the providers)
implemented the initial mapping for ec2 (this can be easily modified by adding new internal categories or supporting all the categories from ec2)
unit tests for the new components (more to come)
updated swagger doc

thx @lpuskas


Support (or enforce) event callback keys

I got bitten by https://github.com/OvermindDL1/bucklescript-tea/issues/97 a while ago, looks like event callback keys are a crucial feature that needs to be supported in this PPX.
Reading this discussion, it seems like passing ~key to handlers such as onInput should almost be mandatory.  Two ideas off the top off my head:
<input onChange={value => Msg} onChangeKey="foo" />

to make it optional, or
<input onChange={(value => Msg, "foo")} />

to make it mandatory by always expecting a tuple (breaking and maybe not obvious?).
@OvermindDL1 what would be your recommendation to solve this? If I'm remembering correctly, in my particular case it was before I passed key anywhere in the UI. Even without key or unique, the UI was getting re-rendered correctly, but the onClick handlers were referring to the initial value.
I remember fixing the issue by passing unique values to the parent container, but I was confused as to why everything seemed to work as expected without unique except the event handlers, if it's that crucial. Tea.Html.onClick doesn't even take a ~key argument, is that intentional?
In React, we pretty much only have to pass key when rendering a dynamic list of components or when we want to force a re-mounting of a stateful component, and this PPX allows making incorrect assumptions that could cause problems out of React habits.

Reading this discussion, it seems like passing ~key to handlers such as onInput should almost be mandatory.

They really really should have been, but Elm did not require them and I was trying to follow its API to ease porting (and Elm programs had similar issues as well), but I'm really leaning to making them mandatory...

Even without key or unique, the UI was getting re-rendered correctly, but the onClick handlers were referring to the initial value.

What 'should' be done is the key should somehow be some representation of the closed over data, even if it's just a simple counter that increments on every change of the closed over data, it just needs to be changed.  It's hard to mandate that at a language level as you only know at runtime if they change.  I've yet to come up with a good idea to 'bind' those together better since function closures in OCaml (and most languages, javascript as well) are always 'unequal'.  I could go the all-out method and always update event handlers that don't have a key set but updating event handler in the DOM is quite slow, but even then that wouldn't catch it when someone forgets to update the key when the closed over data changes, or I could go nuclear and just always update the event handlers always, but that would be horrifying for performance.

if it's that crucial. Tea.Html.onClick doesn't even take a ~key argument, is that intentional?

That's because onClick takes a message, which is able to be compared at runtime so it should always work.  The issue is purely surrounding closures/callbacks.

In React, we pretty much only have to pass key when rendering a dynamic list of components or when we want to force a re-mounting of a stateful component, and this PPX allows making incorrect assumptions that could cause problems out of React habits.

I've not really used React (I didn't come from the web world, rather the backend world, OCaml/C++/erlang/etc...) so input like this is very valuable to me.  :-)
But from what I've debugged in to React doesn't register callbacks directly in the DOM to perform the action but rather just calls back to the instanced React view object (there are no such objects in Tea) and it itself is what handles the updating all wrapped around this so it is containerized.  Essentially a Tea app conceptually runs like a single React Component, it's not a multi-tiered component (consequently you can actually mount a Tea app 'inside' a React component with the react component managing the lifetime of the Tea component).
If OCaml had metaprogramming ala Lisp or so then it would be trivial to make a singular unique message for every possible used message type and link that back directly in then there would be no issues, but without it the programmer needs to do a little bit more work.
Optimally all events would only be messages, not callback/closures.  The only time a callback is really needed is to do some parsing of the event structure or to modify it in some way, and even then rarely is a closure needed then unless needing to, say, stopPropogation based on some program state (but then in that case the callback could be swapped out) then only a pure function callback without a closure would be needed and that would work again (as long as the key is changed when the function is changed, which is much easier to remember).
Maybe it would be better in this PPX to only allow Messages or a message constructor that accepts a value but with no closure at all, along with optional arguments to handle parsing and handling of the event structure?  Any actual 'work' should only be done in update anyway so that would help to enforce that...  Hmm...  I really want to come up with a better idea for linking these...  If only OCaml/javascript allowed for closure comparisons like a couple other languages do...

Thanks for the very informative reply! I do rely on event.target in some places, but setting unique on the element itself does what I want (more I think about it, I was actually missing those and it makes sense). I'll follow what bucklescript-tea does about this, and maybe document it.


[Errno 95] Operation not supported

Thanks for your error report and we appreciate it a lot.
Checklist

I have searched related issues but cannot get the expected help.
The bug has not been fixed in the latest version.

Describe the bug
While running train.py, the epoch runs, but when the time to save checkpoint is reached, I get:

OSError                                   Traceback (most recent call last)
 in ()
----> 1 train_detector(model, datasets, cfg, distributed=distributed, validate=validate, timestamp=timestamp, meta=meta)
7 frames
/content/packages/mmcv/utils/path.py in symlink(src, dst, overwrite, **kwargs)
36     if os.path.lexists(dst) and overwrite:
37         os.remove(dst)
---> 38     os.symlink(src, dst, **kwargs)
39
40
OSError: [Errno 95] Operation not supported: 'epoch_1.pth' -> '/content/gdrive/My Drive/Developer/Project_1/checkpoints/resnet_retina/epoch_1.pth'

Checking the issues, I find that I have to set create_symlink=False in runner.py in mmcv.runner.
I set create_symlink=False and rerun the code. Then the epoch does not run and I get the error:

RuntimeError: cuda runtime error (209) : no kernel image is available for execution on the device at mmdet/ops/sigmoid_focal_loss/src/cuda/sigmoid_focal_loss_cuda.cu:128

I don't understand what am I doing wrong.
Reproduction

Did you make any modifications on the code or config? Did you understand what you have modified?
What dataset did you use?

Environment

Please run python mmdet/utils/collect_env.py to collect necessary environment infomation and paste it here.
You may add addition that may be helpful for locating the problem, such as

How you installed PyTorch [e.g., pip, conda, source]
Other environment variables that may be related (such as $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc.)

Error traceback
If applicable, paste the error trackback here.
A placeholder for trackback.

Bug fix
If you have already identified the reason, you can provide the information here. If you are willing to create a PR to fix it, please also leave a comment here and that would be much appreciated!

Well it seems that I cannot use symlink twice, and as I was using it earlier in the script, the second time usage gave an error. I found a workaround to avoid the usage in the first instance which led to error-free running.
However, it is still strange that why does setting create_symlink = False leads to cuda error.
If that's a bug, it might be fixed, else the issue maybe closed.
Thanks.

Thanks for reporting and we will check it.

https://github.com/open-mmlab/mmdetection/issues/2642#issuecomment-625637089
how did you solve the problem? I have the same in colab

I found a solution to the problem. there it says: replace with create_symlink = False. strange that no one has yet answered this question. / usr / ... /mmcv/runner.epoch_based_runner.py


Don't override clang-format default formatting

Currently this extension hardcodes LLVM formatting as the fallback default:
https://github.com/xaverh/vscode-clang-format-provider/blob/a9b149ab3d3b7b615ed7d1fbbd80b0aaa56e9f14/package.json#L48
It's not clear why the extension includes this.  Why not leave it empty?

Actually, "LLVM" is the default fallback in clang-format (cf. https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/ClangFormat.cpp). If you left this empty, you would get an error message. If you chose "none" as default, you would get non-standard behaviour.

Ah, the Google-internal version of clang-format apparently modified the default setting.


libssh2 exit_status effectively never errors

/*
 * libssh2_channel_get_exit_status
 *
 * Return the channel's program exit status. Note that the actual protocol
 * provides the full 32bit this function returns.  We cannot abuse it to
 * return error values in case of errors so we return a zero if channel is
 * NULL.
 */
LIBSSH2_API int
libssh2_channel_get_exit_status(LIBSSH2_CHANNEL *channel)
{
    if(!channel)
        return 0;

    return channel->exit_status;
}

Not a big implementation.
The problem with the previous code was that it was picking up unrelated errors from previous failures. This is particularly annoying when using async, since EAGAIN was sitting in the 'last error' location.
The comment describes a suggested 'ideal' way to fix this, but I think it's pretty unlikely that implementation is ever going to change.

I'll write a test.

Tests written. The first is pretty ugly.
Reason it's ugly is:
int _libssh2_wait_socket(LIBSSH2_SESSION *session, time_t start_time)
{
[...]
    /* since libssh2 often sets EAGAIN internally before this function is
       called, we can decrease some amount of confusion in user programs by
       resetting the error code in this function to reduce the risk of EAGAIN
       being stored as error when a blocking function has returned */
    session->err_code = LIBSSH2_ERROR_NONE;

So if a blocking function waits for data on a socket, it will clear the libssh2 error status, so if you remove the thread::sleep the error will be cleared and exit_status will be fine. But, if the last thing you call before exit_status() is an async function (demonstrated by swapping the following two lines around
    sess.set_blocking(true);
    assert!(channel.read_to_string(&mut output).is_ok());

) or a blocking function that doesn't need to block (which is what the test does), the libssh2 error will remain as-is and break your exit_status() call.
A simpler test is to demonstrate that any function which sets the session error will break exit_status. This is what the second test does.

Awesome, thanks for the fix!


Should we have a INF status that identifies obj application is pending?

While I was testing, I wanted to wait until application of INF is completed by the daemons, but I noticed there is no "Pending" state for SyncStatus.  Is this a gap?

It’s currently two state why not considering not synced as pending and wait till it go to sync successfully?

but thats my point, we cannot detect its in pending state cause theres no state for this. It currently, if all is good, goes from "Synchronized" -> "Synchronized".

Id like it to go from "Synchronized" -> "Pending" -> "Synchronized".

Within our test code we could watch for these transition states.

/remove-lifecycle stale


[DOC] fixed path of image

Fixed an image path for the deep learning notebook.

for the other folders, I have created an img directory in the sub dir and moved pictures there, so that img/H-Inception.png would work. Might be better to duplicate this structure for networks

for the other folders, I have created an img directory in the sub dir and moved pictures there, so that img/H-Inception.png would work. Might be better to duplicate this structure for networks

Oh okay will do that then thanks ! do you use the H-Inception image in some notebooks in root ? if not i can move it instead of duplicate the image.

for the other folders, I have created an img directory in the sub dir and moved pictures there, so that img/H-Inception.png would work. Might be better to duplicate this structure for networks

Oh okay will do that then thanks ! do you use the H-Inception image in some notebooks in root ? if not i can move it instead of duplicate the image.

move it rather than copy, dont think its used elsewhere, will check after

for the other folders, I have created an img directory in the sub dir and moved pictures there, so that img/H-Inception.png would work. Might be better to duplicate this structure for networks

Oh okay will do that then thanks ! do you use the H-Inception image in some notebooks in root ? if not i can move it instead of duplicate the image.

move it rather than copy, dont think its used elsewhere, will check after

Should be good now, let me know. I checked and its not used in other notebooks.

Should i wait till we fix the kalman stuff and other packages that were updated @TonyBagnall @MatthewMiddlehurst ? because the fails are because of that.


io: document that ReadAtLeast and ReadFull can drop errors

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
1.8.2
What operating system and processor architecture are you using (go env)?
darwin amd64
What did you do?
When passing an io.Reader to io.ReadAtLeast or io.ReadFull, if the conditions of the function are fulfilled (i.e., enough bytes are returned) but it also returns an error, I would expect that error to be propagated. Instead, it is dropped. Example:
https://play.golang.org/p/3XvnMqGYMr
The behavior of these functions can't be changed because of backwards compatibility. I would argue that the function comment should call this case out specifically, since it's quite surprising (and even led to a bug in encoding/base32), and it seems that callers do want the error-propagating behavior most of the time.
Split off from https://github.com/golang/go/issues/20044 .

io ReadAtLeast doc
// It returns the number of bytes copied and an error if fewer bytes were read.

That part doesn't say anything about the error returned if enough bytes are read, but later in the comment:

On return, n >= min if and only if err == nil.

I think this could be clarified to:

On return, n >= min if and only if err == nil. In particular, if r.Read() returns an error but fills up buf, that error will get dropped.

The persistence of an error in a io.Reader is not specified in the documentation and it is reasonable that there is a class of errors that are transient and do not cause an issue if Read were called again. Furthermore, there's nothing that you can do in ReadAtLeast since it is a stateless function and cannot affect the stickiness of an error on the io.Reader passed in.
This is only relevant to documentation; documentation fixes are okay for Go1.9, but leaving in Go1.10 milestone.

You're right about persistence of errors in io.Reader, but that's not what I'm referring to here. The loop in ReadAtLeast stops as soon as r returns an error, but as long as enough bytes are read, that error is dropped. That's the behavior that I'm making a case for being documented.


Instant Replay feature

This is an iTerm2 feature, where one can slide a "time bar" and replay all they typed in the current opened session. Quite useful for when you wanna show others how exactly you got to the current point (in an installation)

:+1: but I think it's better suited for a plugin

Since all data go trough redux, it should be pretty easy using

https://github.com/zalmoxisus/redux-devtools-extension
http://electron.atom.io/docs/tutorial/devtools-extension


首次运行出现如下错误，请帮忙看看。

You Python Requests Library version is to lower than 1.
You can run 'pip install requests' to upgrade it.
Traceback (most recent call last):
File "/usr/bin/bypy.py", line 249, in
raise
TypeError: exceptions must be old-style classes or derived from BaseException, not NoneType
运行了pip install requests 后的输出是：
Requirement already satisfied (use --upgrade to upgrade): requests in /usr/lib/python2.7/dist-packages
Cleaning up...
运行环境：
python -V
Python 2.7.3
pip --version
pip 1.1 from /usr/lib/python2.7/dist-packages (python 2.7)
uname -a
Linux HomeServer 3.2.0-4-686-pae #1 SMP Debian 3.2.63-2+deb7u2 i686 GNU/Linux

执行sudo apt-get remove python-requests  删掉旧版本的requests然后sudo pip install request 来安装新版本的

可以了。谢谢！


CON-2785: Removed the box shadow from the navigation bar

Coverage increased (+0.0005%) to 1.685% when pulling 3a1259fe85bca09ea7c008ed101014b2694ebd07 on CON-2785-remove-shadow-underneath-header into 9741886ebe98b38e7819f0fd99d7c143e14a5542 on master.

I think you can also get rid of the setTop action call inside the View component. Its only needed for that Navigator shadow you just removed ;)

After i've removed the feature, i've figured out, that it's also used by the SortComponent and the NavigatorComponent. So i'll keep it inside. But i found an additional shadow within the FilterBarComponent which is now removed.


SemVer encoding [Front-end]

Front-end needs to append ":semver" at the end of the SemVer values defined in a segment to differentiate SemVer from normal string values.
e.g: a SemVer string that looks like → "1.2.3" is going to look like → "1.2.3:semver".
PS: the other method considered was to parse the string to see if it's a valid SemVer or not, but that operation turned out to be a little expensive, hence we decided to fall back to this.

As discussed we may end up adjusting the way this works by treating semver as new segment operators. Either way, a lot of the frontend is done for this as it's all via remote config I just need to know what to send for these once it's been agreed.

I think it has been agreed that it will have a ":semver" suffix, right/ @matthewelwell @dabeeeenster

so it would look like:
2.1.41-beta:semver
?

so it would look like:
2.1.41-beta:semver
?

yes

Fine here


Bump hackage and fix some issues

Somewhat non-obvious, ultimately caused by recent revisions to turtle. I had to put some constraints in the project file, but nothing that affects our publishing to CHaP, fortunately.

I restarted the failing jobs and they are in fact green.


Support for index route with history?

This is a:

[ ] bug
[x] enhancement
[ ] feature-discussion (RFC)

I am using Swiper with the history option as the main way to navigate through my site.  The first slide should be the index page and the rest of the slides have unique id.  I could not get history working correctly with this setup.  I ended up modifying the library to get the desired solution.  I was wondering if there was any planned support for this use case?

I also needed this.
Change:
var value = this.slugify(slide.attr('data-history'))
to:
`var value = this.slugify(slide.attr('data-history')) || '/';
in the setHistory method.

Issue is closed because of outdated/irrelevant/not actual/needed more information/inactivity.
If this issue is still actual and reproducible for latest version of Swiper, please create new issue and fill the issue template correctly:

Clearly describe the issue including steps to reproduce when it is a bug.
Make sure you fill in the earliest version that you know has the issue.
Provide live link or JSFiddle/Codepen or website with issue


Missing Error Highlighting in Erroneous Code

Describe the bug**

The code in the attached gist is erroneous , yet Ionide-fsharp is unable to highlight the errors before running the code.
There is both an issue in the pattern match expression and when calling the custom option map function with a regular string.
Steps to reproduce

Open an F# interactive script in VSCode
Copy code from gist
Select and run code in F# Interactive mode (alt + enter)

Link to sample reproduction

https://gist.github.com/sebastto/dc11b5cffc90625cccdd054017ab47f2
Expected behaviour

Expected the errors to be highlighted before running the code.
When writing the same script in Visual Studio, the error is detected before running,
see attached screenshot.
Screenshots

Screenshot from Visual Studio

Machine info

OS: Windows
.NET SDK version: 5.0.401
Ionide version: 5.7.3

Also seeing this in latest Ionide with .NET 6 for even trivial scripts. The following invalid F# shows no errors in the code editor.
let x = 123jfdsj

.NET 6.0 on Windows 11, v5.10.2.

Everything seems to be working fine for me:


GH-35709: [R][Documentation] Document passing data to duckdb for windowed aggregates

Rationale for this change
#35702 documents how to use joins for computing windowed aggregates. This documents an alternative solution by passing data to duckdb. This use case was also mentioned on the duckdb blog.
What changes are included in this PR?
Changes to vignette.

Closes: #35709

I rebased and I think I cleaned up this PR. Let me know if there are any other changes needed


--seek-file breaks help and list commands (possibly others)

Hi,
It is mentioned in the following URL that the --seek-file argument can be used in an alias, to make doit search for the dodo.py file in parent directories:
https://groups.google.com/d/msg/python-doit/eKI0uu02ZeY/R7XdRaXoUvgJ
However, if I create such an alias, the doit help and doit list commands no longer work (possibly others too):
  $ alias doit='doit --seek-file'

  $ doit help
ERROR: Invalid parameter: "help". Must be a command, task, or a target.
Type "doit help" to see available commands.
Type "doit list" to see available tasks.

  $ doit list
ERROR: Invalid parameter: "list". Must be a command, task, or a target.
Type "doit help" to see available commands.
Type "doit list" to see available tasks.

hummm. i see the problem... while the list command supports the --seek-file it expects something like doit list --seek-file.
Maybe this alias is not a good advice... do you have any idea how to solve that?

Why not parse command-line options with the built-in argparse module instead of getopt?
This would probably simplify option parsing code and would certainly (and extremely easily) allow you to add the --seek-file / -k option to all subcommands.
Python's documentation suggests to use argparse over getopt (see the note at the top or the much shorter argparse translation at the bottom):
https://docs.python.org/3/library/getopt.html

argparse is not flexible/powerful enough.
I guess we could add --seek-file to be a doit parameter and then passing it to sub-commands.
This would fix the problem... also might apply this to other params.
This should not be hard. Do you want to give a try implementing that? :grimacing:

I was thinking about this lately. I guess the best way would be to have this controlled by a shell Environment variable.

@schettino72 Sounds good to me!

Hi, I have created a pull request for the environment variable idea. Please take a look.
#186
Thanks,
Bala


feat: adds 3DS and keys endpoints

Description

adds 3DS and keys endpoints

Testing required outside of automated testing?

[x] Not Applicable

Screenshots (if appropriate):

[x] Not Applicable

Rollback / Rollforward Procedure

[x] Roll Forward
[ ] Roll Back

Reviewer Checklist

[ ] Description of Change
[ ] Description of outside testing if applicable.
[ ] Description of Roll Forward / Backward Procedure
[ ] Documentation updated for Change

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


Bumping the uamqp library to last version

Using<EMAIL_ADDRESS>to publish on pypi seems like is complaining about the uampq library saying:
Note: This error originates from the build backend, and is likely not a problem with poetry but with uamqp (1.5.2) not supporting PEP 517 builds. You can verify this by running 'pip wheel --use-pep517 "uamqp (==1.5.2) ; python_version >= "3.6""'.
Probably is worth to bump it to the last version if tests are ok

Implemented here: https://github.com/qweeze/rstream/pull/41


fix(#9): cannot start wdio tests

Fix #9

@christian-bromann, to further improve this PR:

I think we won't need this anymore : L164-L174 ? (and it was not even conditioned to isUsingTypeScript)

We would need to add a default tsconfigFile value in angular.json L196:
tsconfigFile: /test/tsconfig.e2e.json
But I'm sure on how to get the /test here...

Any idea on how to elegantly get the parsedAnswers in here L188 ?
I need to do something like :
const relative = path.relative(process.cwd(), parsedAnswers.destSpecRootPath);
const tsconfigDir = relative.split(path.sep)[0];

const wdioConf = {
  builder: '@wdio/schematics:wdio',
  options: {
    devServerTarget: `${project}:serve`,
    tsconfigFile: `${tsconfigDir}/tsconfig.e2e.json`,
  },
  configurations: {
    production: {
      devServerTarget: `${project}:serve:production`
    }
  }
}

Shouldn't it be possible to store data in the SchematicContext object?

I don't think so...
And anyway runWizard and modifyAngularJson are running in a chain (L34) so we cannot make sure they both run in sequence. I will have to find a better way.

I won't be able to solve it without making many changes.
Running the wizard is optional so I cannot rely on the parsed answers that it returns.
The tsconfig file path has to be determined from within modifyAngularJson().
But this file could have been renamed or moved from a previous wizard installation, and so did the wdio configuration file.
So I'm kind of stuck here...
I guess the wizard shouldn't be optional (why would it be after all ?)
The schematics should decide itself whether wdio is already installed and install it if it's not or do nothing otherwise.
That way everything would be more predictable and easier to automate.

Unfortunately I'm acting blindely on this one because I was not able to mount this project locally to make the proper modifications.
I followed the development section in the README and it simply doesn't work.
$ npx ng add @wdio/schematics
> An unhandled exception occurred: Cannot find module '/Users/badisi/webdriverio-schematics-main/src/schematics/webdriverio/index'


Exception while simulating the effect of invoking 'submitPost' TypeError: Cannot read property 'clientAddress' of undefined

I am having this problem with submitPost method.
Running Windows 8.1 and Telescope 25.7 master
methods.js:
187: post.userIP = this.connection.clientAddress;
188: post.userAgent = this.connection.httpHeaders["user-agent"];

Exception while simulating the effect of invoking 'submitPost' TypeError: Cannot read property 'clientAddress' of undefined     at Meteor.methods.submitPost (http://localhost:3000/packages/telescope_posts.js?1669b07ebc5bde5e4e7d3997406b7df923d1d855:1226:34)     at http://localhost:3000/packages/ddp-client.js?250b63e6c919c5383a0511ee4efbf42bb70a650f:3911:25     at _.extend.withValue (http://localhost:3000/packages/meteor.js?9730f4ff059088b3f7f14c0672d155218a1802d4:971:17)     at _.extend.apply (http://localhost:3000/packages/ddp-client.js?250b63e6c919c5383a0511ee4efbf42bb70a650f:3902:54)     at _.extend.call (http://localhost:3000/packages/ddp-client.js?250b63e6c919c5383a0511ee4efbf42bb70a650f:3780:17)     at http://localhost:3000/packages/aldeed_autoform.js?b3aa1a45a8c57d1da1124520538d2cb9fa458509:3292:13     at runHook (http://localhost:3000/packages/aldeed_autoform.js?b3aa1a45a8c57d1da1124520538d2cb9fa458509:7734:11)     at Object.cb (http://localhost:3000/packages/aldeed_autoform.js?b3aa1a45a8c57d1da1124520538d2cb9fa458509:7746:13)     at Object.result (http://localhost:3000/packages/underscore.js?46eaedbdeb6e71c82af1b16f51c7da4127d6f285:794:19)     at runHook (http://localhost:3000/packages/aldeed_autoform.js?b3aa1a45a8c57d1da1124520538d2cb9fa458509:7760:15)

Sometimes submitting new post causes this as well:
\AppData\Local\.meteor\packages\meteor-tool\1.1.10\mt-os.windows.x86_32\tools\utils\fiber-helpers.js:168
    }).run();
       ^
FATAL ERROR: JS Allocation failed - process out of memory

Not sure if related.

I'm getting the same error. Did you get around it?

I'm getting the same error too :(, windows 10

just comment those lines for a quick fix for now

@capensisma I'm having a hard time finding these lines in the Telescope package code so I can comment them out, since they're compiled. Could you point me to the exact file?

@nicholasalanbrown check the last pull I did, it shows you where tom comment it out

This also got fixed on Nova by wrapping it with if (Meteor.isServer && this.connection) 👍


triton does not seem to work on WSL (windows sub linux system)

The tl.load(address) (to read data to SM unit) command in the "interpreter" mode returns all wrong value of the original tensor. The normal running mode (on real gpu) seem fine, but of course, we care about interpreter mode.
i thought I might need to rebuild triton from scratch on this wsl system, but it is failing:

cmake /home/manh/loi_major_build/triton -G Ninja -DCMAKE_MAKE_PROGRAM=/usr/bin/ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DLLVM_ENABLE_WERROR=ON -DCMAKE_LIBRARY_OUTPUT_DIRECTORY=/home/manh/loi_major_build/triton/python/build/lib.linux-x86_64-3.10/triton/_C -DTRITON_BUILD_TUTORIALS=OFF -DTRITON_BUILD_PYTHON_MODULE=ON -DPython3_EXECUTABLE:FILEPATH=/usr/bin/python3 -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DPYTHON_INCLUDE_DIRS=/usr/include/python3.10 -DTRITON_CODEGEN_BACKENDS=nvidia;amd -DTRITON_PLUGIN_DIRS= -DPYBIND11_INCLUDE_DIR=/home/manh/.triton/pybind11/pybind11-2.11.1/include -DLLVM_INCLUDE_DIRS=/home/manh/.triton/llvm/llvm-657ec732-ubuntu-x64/include -DLLVM_LIBRARY_DIR=/home/manh/.triton/llvm/llvm-657ec732-ubuntu-x64/lib -DCMAKE_BUILD_TYPE=TritonRelBuildWithAsserts -DJSON_INCLUDE_DIR=/home/manh/.triton/json//include -DPYBIND11_INCLUDE_DIR=/home/manh/.triton/pybind11/pybind11-2.11.1/include -DCUPTI_INCLUDE_DIR=/home/manh/loi_major_build/triton/third_party/nvidia/backend/include -DROCTRACER_INCLUDE_DIR=/home/manh/loi_major_build/triton/third_party/amd/backend/include

The only error message is "c++: fatal error: Killed signal terminated program cc1plus"
Not sure how to debug with that.
The way that the setup.py is written, or cmake is run make it pretty hard to debug why the build process was failing.

You are facing an OOM issue. Buy more RAM or increase your allowed memory usage of WSL, or limit the number of threads for compiling triton should help.

yeah, but what about the quesiton about the interpret not working on WSL. i guess it is lower priority

The tl.load(address) (to read data to SM unit) command in the "interpreter" mode returns all wrong value of the original tensor. The normal running mode (on real gpu) seem fine, but of course, we care about interpreter mode.

Can you share your code and your command?

I'm running into the same problem. I'm glad I found this issue indicating it was a problem with the WSL because I was at a loss. Here's a reproduction:
import os

os.environ["TRITON_INTERPRET"] = "1"

import torch
import triton
import triton.language as tl

@triton.jit
def demo_wsl_failure_kernel(input_ptr):
    input = tl.load(input_ptr)
    print(input)

def demo_wsl_failure():
    input = torch.full((1,), 42)
    demo_wsl_failure_kernel[(1,)](input)

demo_wsl_failure()

You'd expect this to print [42] but on the WSL it prints [0]

On my WSL it prints [42]. Please make sure triton/main is installed and used

This repros for me on the latest from PyPi (3.0.0) and the latest nightly (triton-nightly-3.0.0.post20240716052845). Took a few tries to build from source, but when I was able to, it now works correctly. I was surprised that this was an issue since July, but happened to be fixed between the last nightly and tip of tree, but then I read the nightly version string, and it looks like it hasn't been updated since July 16th? And I guess that's because the Wheels action has been failing with an auth error since then 😕 https://github.com/triton-lang/triton/actions/workflows/wheels.yml
So I guess this is fixed in the repo, but hasn't been released yet. Would be nice to do the latter, at least to nightly


Unicode maturity

Would it be a good idea to add a note about Text/String coexistence ?
As you said yourself, this might be the biggest Haskell annoyance ever ;-)

Yep, that is really important to note!


Rebranding

This should go through first.

Then publish snapshot to sonatype (without relocation POM, so we don't run into the KLIB bug.)
Then publish snapshots of EU PID and MDL credentials to sonatype, because we require them here for testing
Then publish this rebranded library with relocation POM to sonatype
Then update all credentials (refactor initWithVcLib to initWithVck or whatever is preferred
Update credentials collection and a-sit-plus.github.io
Update everything else that depends on this work

After we know all this went well, we should do another round, using the repranded kmp-crypto and its verifier and the rebranded jsonpath library.

same procedure as with 4.0.0: includes dependencies and publishes them to mavenLocal, to work around kotlin build bugs, the last one of which will be gone for good with the next serializationr release end of august/beginning of september, once kotlin 2.0.20 is out.
Porposed course of action:

@nodh review this
@JesusMcCloud publish signum and jsonPath to maven central
@JesusMcCloud remove all the included stuff
@JesusMcCloud publish this one here to maven central
@JesusMcCloud republish all credentials
@JesusMcCloud update all services and apps to use the new coordinates


Stop the sync service downloading duplicate blocks

Avoid downloading duplicate blocks with the sync service.
Also

use the current state tip in the block locator
add diagnostic info to the duplicate block verify warnings.

TODO:
Diagnosis:

[x] why does the sync service send duplicate block requests?

keep a list of pending hashes and use them to filter new requests

[x] why are we downloading blocks at the start of the chain?

the locator goes back to genesis
some peers are sending us low-height, off-chain blocks

[x] why does the sync service hang after removing duplicates?

the service was relying on duplicates to compensate for failed block downloads
the retry limit was too low
the backpressure and checkpoint verifier were deadlocked
(the block verifier works fine)

ObtainTips:

[x] should we add the tip (rather than just tip - 1) to the block locator?

adding the tip makes sure we don't re-download the tip

[x] should the block locator be limited to the reorg interval?

yes, we should only ask for blocks that we'd accept

[x] fix first_unknown when all hashes are known

we were downloading all the known hashes, rather than skipping them

Verifiers:

[x] info (or debug) on duplicate blocks

Refactor:

[ ] abstract the pending hashes and futures into a struct

make sure each added future has a pending hash, and each removed future removes its pending hash

[ ] abstract the failed hashes into a struct?

@teor2345 do we know why the syncer gets stuck and starts downloading blocks incorrectly?

Before we make changes to the sync logic, I think it would be good to have an analysis of why it currently gets confused and breaks down sometimes.

@teor2345 do we know why the syncer gets stuck and starts downloading blocks incorrectly?

I've discovered these issues:
Duplicate requests:

the block locator goes back to genesis, but we'll only use blocks within the reorg interval
the block locator starts at tip-1, leading to duplicate tip downloads
the sync service doesn't track hashes that it has submitted to the download queue, so it can request the same block twice

Failed retries:

when a block fails to download, sometimes the retry doesn't work (it looks like we were relying on duplicate downloads to make progress)
I wonder if backpressure stops us downloading missing blocks

Bad peers:

on mainnet, when we send ExtendTips, a few peers send us low-difficulty hashes, which aren't on the mainnet or testnet chains
for some reason, we get low-height blocks in response to download requests

I don't know if these blocks match the low-difficulty hashes

it looks like we download these low-height blocks faster than the best chain

I haven't looked at the missing blocks and bad peers in detail, I can do more analysis tomorrow.
But this issue is pretty complex, so it might help to make incremental progress. In particular, I think tweaking the block locator is pretty safe, and independent of the other changes.

Before we make changes to the sync logic, I think it would be good to have an analysis of why it currently gets confused and breaks down sometimes.

The details of what I was actually able to fix are in each commit message in this PR. (I also did some analysis above, in the description and the comments. It's a decent summary, but the commit messages have the full details.)
This PR includes a temporary fix for a block download failure deadlock, the details of that issue are in PR #835, along with my attempt at a fix.

abstract the pending hashes and futures into a struct

F. I think I implemented this early in the syncer write, I hand wrote a future that would wrap the block download feature and the hash that is associated with that block download future. Let me do some spelunking to see if theres any old commits reachable still that have this code in it.

Obsoleted by #851, #852, #853, and #854.


Add PARQUET_1_0 and non-repeated data performance tests to parquet-benchmarks

The current parquet-benchmarks module run some performance tests between different block & page sizes for PARQUET_2_0 version only. We should run some tests with PARQUET_1_0 version as well in order to get a view about new parquet version enhancements, and be able to catch possible overheads early by comparing with the old file format.
Also, this module uses repeated data to benchmark the settings. We should also use random data to get different results about how current and new encodings work with real world data.
Reporter: Sergio Peña / @spena
Assignee: Sergio Peña / @spena
PRs and other links:

PR-224

Note: This issue was originally created as PARQUET-315. Please see the migration documentation for further details.

Sergio Peña / @spena:
Add link to pull request
https://github.com/apache/parquet-mr/pull/224


ktlint_standard_function-expression-body = disabled not honored

Expected Behavior
Given .editorconfig:
ktlint_standard_function-expression-body = disabled

And this source file, hello.kt
fun hello(): String {
  return "hello"
}

Applying ktlint should not apply the expression body transformation to the hello() function.
Observed Behavior
fun hello(): String = "hello"

Steps to Reproduce
I’m using com.pinterest.ktlint:ktlint-cli:1.4.1 via Spotless. (I assume Spotless isn’t to blame here.)

This is not a problem caused by Ktlint. I expect that Spotless provides an editorConfigOverride to the KtLintRuleEngine that actually overrides what you have specified in your .editorconfig.

Please address issue with Spotless team, and add a link to their issue if possible. Closing the issue for now.


Flag --incompatible_config_setting_private_default_visibility will break Bazelisk in Bazel 7.0

Incompatible flag --incompatible_config_setting_private_default_visibility will be enabled by default in the next major release (Bazel 7.0), thus breaking Bazelisk. Please migrate to fix this and unblock the flip of this flag.
The flag is documented here: https://github.com/bazelbuild/bazel/issues/12933.
Please check the following CI builds for build and test results:

MacOS, OpenJDK 11
Ubuntu 18.04, OpenJDK 11
Ubuntu 20.04, OpenJDK 11
Windows, OpenJDK 11

Never heard of incompatible flags before? We have documentation that explains everything.
If you have any questions, please file an issue in https://github.com/bazelbuild/continuous-integration.

No longer seeing these issues.


Cross-Platform AF_XDP API or Not?

Currently, the FAQ makes the following statement:

It is not directly source-compatible with the Linux API, though it is possible to build a thin shim layer to abstract any differences.

This begs the following questions:
How important is cross-platform AF_XDP API usage?
Do we expect that a single application, built for multiple platforms, would want to support XDP on both? My personal take is Yes, applications that support XDP on one platform will most likely want to leverage it on another if possible.
If cross-platform support is important, should XDP for Windows have exactly the same API as on Linux?
Assuming cross-platform support is an eventual goal, should XDP for Windows be constrained to what Linux has/does or should we instead propose a shim on top of both? I'm not sure.
Should XDP for Windows have the sole responsibility for driving this cross-platform support?
Whether it is decided to match APIs exactly (or perhaps close enough that only minimal differences exist) or a separate shim layer is written, I believe more input will be needed from the community. If the shim approach is taken, it doesn't really make sense for either platform to explicitly own the shim, but should be a combined ownership, or completely separate.

Thanks for sharing and open source this project!
I've been thinking about using AF_XDP for both Windows and Linux on OvS (Open vSwitch).
My 2 cents are:
AF_XDP is socket interface, so it should be OK to expect people writing Windows-specific code to create/send/receive packets from XSK. So the AF_XDP part is platform-specific.
I'm hoping the XDP API in Windows kernel could be as compatible as Linux, so that when we offload XDP program into Linux/WIndows kernel, we don't need to recompile the eBPF binary or introduce feature detections on version and OSes.
Thank you

The BSD sockets API is cross-plat and so a key sockets scenario is cross-plat.
Hence this should not be a question, it should simply be a feature request.


About the coordinate system

Hi, thanks for your work!
I wonder what's the groud truth voxelized scenes' coordinate system, if I want to crop those voxels in the cam field of view, how can I do it? Thanks.

I can't remember anymore. By checking the ground truth data, it seems like the coordinate system follows OpenGL or Unity.

It's likely Unity since I probably only inverted the Y-axis.

I can't remember anymore. By checking the ground truth data, it seems like the coordinate system follows OpenGL or Unity.
It's likely Unity since I probably only inverted the Y-axis.

I got it. But I'm still confused about how I can transform the ScanNet pose to align with this complete voxelized scene. And is this voxelized scene in world coordinate?

yes, it's world coordinate.
Check ScanNet loader or the data generation code. There should be a transformation somewhere.


Autocomplete with limitTags, the dropdown disappears weirdly

Steps to reproduce
Link to live example: (required)
https://mui.com/material-ui/react-autocomplete/#:~:text=You can use the,Forrest Gump
Steps:

Place your cursor over the "favourites" placeholder
Hold down click
After a second release

Current behavior
The drop down disappears when on mouse up. Resulting in a sudden flash of the dropdown if navigating normally. If you keep the mouse down, then place the cursor back over the input box (or outside of the autocomplete comp), the drop down box doesn't disappear.
This issue only occurs if the input text has to move down a row due to the occupying chips.
Expected behavior
One click should prompt the drop down menu to appear.
Context
No response
Your environment
No response
Search keywords: Autocomplete, limitTags

Duplicate of #42432