[Tests] Create UI tests on the Dashbaord view using JUnit or Robolectric

Context
The Dashbaord view is the view that shows after signing up or logging in (entering the PIN). UI Test coverage needs to be added in this view.
Note: Use branch develop as base branch
Files involved:
DashboardFragment.kt
DashboardViewModel.kt
fragment_dashboard.xml
DashboardFragmentsAdapter.kt
FeedFragment.kt
ChatListFragment.kt
PaymentReceiveFragment.kt
TransactionsFragment.kt
ScannerFragment.kt
The goal is to test some basic UI interactions in the Dashboard view and their expected results.

Add any needed configuration for the selected test tool (JUnit, Robolectric, UI Automator, etc).
Implement the following test cases

Dashboard View

[ ] Tapping Feed tab should show feed content (DashboardFeedsContainerViewController)
[ ] Tapping Friends tab should show Friends chats (ChatsContainerViewController)
[ ] Tapping Tribes tab should show Tribes chats (ChatsContainerViewController)
[ ] When on Tribes tab, tapping Add Tribe button should present Discover Tribes view (DiscoverTribesWebViewController)
[ ] Tapping on left arrow button on bottom bar should present REQUEST AMOUNT view (CreateInvoiceViewController)
[ ] Tapping on right arrow button on bottom bar should present Scanner View (NewQRScannerViewController)
[ ] Tapping on scanner button on bottom bar should present Scanner View (NewQRScannerViewController)
[ ] Tapping on transactions button on bottom bar should present Transactions View (HistoryViewController)
[ ] When on Friends or Tribes tabs, typing on Search field should filter chat rows based on search term

Hey @tomastiminskas I would like to work on this issue, can you assign this to me

@tomastiminskas since I was unable to complete this on time I would like to be unassigned

I can try it


[FEATURE] llm work with tool using function-calling

I figure out that langchain4j uses function-calling api work with tools,
but most llm except chatgpt does not support function-calling,
this way may not work for my request, do you have some advice?

Hi @vcjj which LLM are you using? LocalAI supports function calling and you can run many opensource LLMs with it.


Easier configuration/running

So, I got pulled in JDLL by the spanish people on Prague
I was looking at the readme and the first thing I thought is that I might help you, folks, with some automatization/template ready to clone and start playing from there
It's based on Kotlin (and some or all in Gradle), I'm pretty confident I could provide something along these lines:
// 0. Setting Up JDLL
// no need, just clone the template repo

// 1. Downloading a model (optional)
downloadModel {
     // enum, statically typed
    model = Model.`B. Sutilist bacteria segmentation - Widefield microscopy - 2D UNet`
    // set with some default value, but customizable
    //dst = projectDir / "models"
}

// 2. Installing DL engines
// we may also implement all the necessary logic expressing the compatibility among
// the different DL framework, OS and Arch, printing errors if incompatible or warnings
// if a best effort try is being made
framework {
    // if engine, cpu and gpu are not specified, then
    // `EngineInstall::installEnginesForModelByNameinDir` will be called
    // engine = Tensorflow.`2.0` // also enum, statically typed
    // cpu = true
    // gpu = true
    // set with some default value, but customizable
    installationDir = projectDir / "engines"
}
// will automatically failed if `!installed`

// 3. Creating the tensors
val img1 = model.create<FloatType>() // [1, 512, 512, 1] inferred from `model`
tensor {
     input = build(model.inputs.bxyc, img1) // "input_1" might be inferred
     outputEmpty = buildEmptyTensor(model.outputs.bxyc) // "conv2d_19" might be inferred
     outputBlankTensor = buildBlankTensor<FloatType>(model.outputs.bxyc) // [1, 512, 512, 3] inferred
}

// 4. Loading the model
dlEngine { // or dlCompatibleEngine {
    framework = TensorFlow.`2.7.0`
    cpu = true
    gpu = true
    // engineDir inferred
}

// the rest of the step can be created and executed automatically
// everything gets inferred:
// - model load
// - model run
// - cleanup

Following the Gradle philosophy of "convention over configuration", we could assume conventions over framework and have that step completely optional as well. Something similar for cpu/gpu=true

So, I quickly prototyped something like this:
plugins { bioimage.io.jdll }

setEngine {
    engine = Framework.torchscript.`1,13,1`
}

setModel {
    model = Models.EnhancerMitochondriaEM2D
}

execute = { model, inputsTensor, outputsTensor ->

    inputsTensor += buildTensor<FloatType>()
    outputsTensor += buildTensor<FloatType>(outputs = true)

    println(Util.average(Util.asDoubleArray(outputsTensor.first().data)))
    model.runModel(inputsTensor, outputsTensor)
    println(Util.average(Util.asDoubleArray(outputsTensor.first().data)))
}

It's a little hacky to get something asap and it works just before the Model.createDeepLearningModel is called, because then the classloader concept has to be fixed/reworked, but the idea is that
You can go massively down with requested code (original) and make it truly script (now essentially it's running during Gradle configuration time, with manual caching engine and model)


Create index.md

Closes #[issue number]
Description

Screenshots

Release notes

Notes:

Thank you

git@github.com:IngridMi/desktop.git


Ven's Stock Revamp Resurrected

Per this thread:
https://forum.kerbalspaceprogram.com/index.php?/topic/189732-18x-vens-stock-revamp-resurrected-v1141-mercury-delayed-12-nov-02019/&tab=comments#comment-3705563
this needs to be added.  however, there are two current versions, one for regular and one for RO, the one for RO has an earlier version number.  Maybe doing a manual one first for the RO and then a more automatic one for the regular one would be it, but this is beyond what I'm comfortable doing

@Kerbas-ad-astra already opened a issue: #7498

Duplicate of #7498


[Question] Video from the lecture (from your PC)

Will you upload the recorded video from your laptop somewhere?

Unfortunately, it does not have sound due to the microphone issues. You may watch the lecture in the first discussion post here:
https://www.facebook.com/events/1241511809369108/permalink/1254137478106541/
It shows my computer screen so I guess it should be OK.


Fix wiki link. Add some format to texts

@pboling
Fix wiki link for https://github.com/oauth-xx/oauth2/issues/502

Pull Request Test Coverage Report for Build 1037

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

Totals

Change from base Build 1032:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls

Pull Request Test Coverage Report for Build 1037

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

Totals

Change from base Build 1032:
0.0%

Covered Lines:
0

Relevant Lines:
0

💛  - Coveralls


feat(nuxt): add useResponseHeader composable

🔗 Linked issue
Resolves https://github.com/nuxt/nuxt/issues/27075
📚 Description
Adds 2 new composables:

useResponseHeader
useResponseHeaders

See referenced issue for details.
I tried my best to cover enough ground to make a draft PR:

Proposed code for new composables
Written 2 new documentation pages

But I still need some help :) With the following questions:

I'm not familiar with writing tests, is it expected that I add tests and if so, where do I start?
Right now I propose to return nothing from the functions, but we could also return true if successful and false if failed? Any ideas for better return values?
On naming the functions. The name "use" responseHeader kinda implies a return value, as it implies consuming something... Would it be better to name them setResponseHeader? That would be in line with the h3 library but, be out of character for a Nuxt composable.
Do I put the Nuxt versions above the functions myself, or are these added later?
Typings: right now I used string for both header name and value. But the h3 packages includes a type HTTPHeaderName which seems perfect for name. But the other composables about headers also didn't use this type, so I didn't use it. Should I use it? Is this something we could improve for all composables about headers?

I agree with you - I think that useResponseHeader doesn't make sense as a way of setting response headers. I think it should more likely return a computed value, which allows both getting and setting response headers.
For example:
const someHeader = useResponseHeader('x-some-header')
console.log(someHeader.value) // existing value
someHeader.value = 'new value'

@danielroe Any thoughts on my proposed solution before I start building it?

Yes, that looks good to me!

@danielroe I have updated the useResponseHeader code to reflect my proposal. Also updated the docs for it.
To be honest I am unsure about the added value of the plural useResponseHeaders and also unsure about how to implement it. We could also go forward with only the singular form? Or I would be glad to update the code for useResponseHeaders if you have any tips about implementation (e.g. with a computed, or only as a setter with an object parameter, or...)

I agree, let's drop useRequestHeaders...

I deleted the plural form.
How do I proceed? I think I need to do some checks/tasks before merging?

I added a very basic test. I really don't know much about testing Nuxt, so if further work is required, I need some help.


can i work in the mobile web?

in mobile web ,i use zepto but not the jquery,so it can't work and throw "Cannot set property 'below-the-fold' of undefined"
how can i do to kepp it work.
you konw zepto and jquery  are similar。
We use it in production in the category pages of many of our ecommerce websites.
Let me know!

Sorry I forgot to say that it's a version of this plugin but without jQuery dependence. So you can use it in mobile (also because it's faster) or wherever you want.

thank u very much~

This should be fixed in 2.x.


hanging up

Actual behavior (the bug)
A description of what happened
Expected behavior
A description of what you expected to happen
To Reproduce
Steps to reproduce the behavior
Additional context
Add any other context about the bug here

?


add eclipse-temurin to build matrix

closes #177

Do you need java 8? I would not add that if nobody asks for it

Not really anymore, removed it

Thanks!


Configuration test page

An useful page to test different parameters for:

Embedding with IFRAME
Using Player from code
Using Player as HTML element with anm-player-target attribute.

Will be improved, new options will be added, of course, but quite OK to use.

ok, great! Iaroslav knows about it?

Yes, but I will also make a public announcement today.


First attempts to add rsync example to ci run

This pr is designed to incorporate the examples as part of the CI. A GitHub Action has been created that will run the imagemagick example problem.

@renan-souza this pr was merged into devel right, if so can you close this PR.


Better error when run image is private

Codecov Report

Merging #327 into master will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #327   +/-   ##
=======================================
  Coverage   67.69%   67.69%
=======================================
  Files          81       81
  Lines        3309     3309
=======================================
  Hits         2240     2240
  Misses        797      797
  Partials      272      272

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 f87585a...6121fd4. Read the comment docs.


Update bitflags to 0.9

Tests failed. Also, @asomers any reason why the freeBSD tests aren't showing up here?

Looking over these changes, it actually appears to me that at least some of these bitflags macros should actually be changed to use the internal libc_bitflags macro. Since we're already touching on these values, it'd be great to do that as part of this PR. @equal-l2 could you do that?

@Susurrus I'd love to. Which bitflags do you actually mean?

Any of the bitflags that reference exclusively libc types, which should be most of them. OFlag should be assuming that all of the values exist in the libc crate, which you'll need to check (they may need to be conditionally-included with #[config()] attributes.

Some of OFlag is not exist in libc yet.
I'll make a PR for them on libc.

I'd like to separate the change of bitflags to libc_bitflags to another PR, since there are more constants we can hand over to libc.
Can't I do that?

@equal-l2 That's fine. Thanks for your work on this!
bors r+

I think this is not my fault...

Yeah, looks like an intermittent failure as I haven't seen that before. Let's run it again.
bors r+

BuildBot isn't running any of the bors jobs.

Okay, according to the console view, bors got the message about the staging pushes, but no build was scheduled as a result of it. Personally, I'd turn of buildbot entirely for the master branch but always build staging (not sure how this relates to building pull requests, though).

Let's try again
bors r+

That did the trick.  Turns out there's a difference between "staging" and "refs/head/staging".


Extension contributes settings don't take effect until vscode restarted now

VSCode Version:1.32
OS Version: mac/windows

Steps to Reproduce:

Get an extension that has the html customData contributes setting for html tag lookups:
https://github.com/Microsoft/vscode/issues/68554
Download: https://github.com/Microsoft/vscode/files/2857364/svg-0.0.1.vsix.zip
Install in 1.32.
Notice the message says it installed fine.  In 1.31 it would say click "reload".
Open up an html file
Type <foreign  .  It should have offered you  but nothing happens.  The html editor's customData setting from the extension's contributes isn't working.
Restart VSCode.
Repeat.  It works.

This is a regression in behavior from 1.31.  In 1.31, after installation of a vsix file, you would click on "Reload" button in message, and the settings would take effect.  Even doing a disable/enable on the extension doesn't work, you have to restart VSCode. 1.31 was much nicer, that you didn't have to do that.

Does this issue occur when all extensions are disabled?: Yes/No

@octref We now install extensions without reload. New extensions can add new contribution points. You need to listen to extensions.onDidChange

Wouldn't this mean that the html extension would need to add onDidChange support to cope with this extension's installation modifying the contributes html.experimental.customData setting?

This got fixed a few month back. No reload is necessary anymore for custom data to be picked up.


Update repo

Hey, Im trying to follow along from egghead, but the latest versions of babel and istanbul are major changes and cause your egghead series not to work.

Thanks for the issue. Things have definitely changed significantly with Babel. I'll have to give this a look sometime. Thanks again!


Feature/pub feedback

Fixing issues reported by pub

I'll wait until checks have completed before landing this PR and doing the release.

@QuintinWillison the relative imports is addressed in linting PR. And rest assured we will not be facing this issue anymore if we release after all CI checks are passed.


Can't disable "Show BestInSlot in boss tooltips"

Hi guys!
I asked my guildmates as well and they have the same problem.
It's not possible to disable the tooltip option "Show BestInSlot in boss tooltips" in the option tab.
When you untick it, it always gets enabled again, when you switch tabs or close the window.
Hope there is a fix for this, because it lags a litle bit, when I hover over a boss.
Kind regards,
Izno

Hmm, that's weird. I'll look into it over the weekend.

bump


Remove freeport. Use a net.Listener and http.Serve

Instead of using freeport.GetFreePort() this PR creates a net.Listener bound to the chosen ip address and gets a system chosen available port.  The net.Listner is passed to http.Serve which is used instead of http.ListenAndServe. This eliminates issues because of differing values for localhost across systems, a port not being used on the address localhost maps to but on the choosen address and the potential for a port being used in the time between the check it is available and actually binding to it. Issue #3 should be resolved by this PR.

get port and serve should execute in the same time.

@tssva many thanks for this. I'm going to merge it soon.
@barryz can you please expand on why get port and serve should execute on same time?
Thanks


Module Request: Spinner

We should have a spinner component. Feel free to use S3 to upload any SVG's and/or hard code those URLs. Would be nice to have something we can load in w/ configurable color though that's a super lightweight API around something like:
https://www.lightningdesignsystem.com/components/spinners
http://fgnass.github.io/spin.js/

Assigning to @alexaraes && @mona87 to work through next week together. Goal is to have a lightweight version of the first link implemented as an ES6 module. Don't worry about tests for now. Ping @JBBryan if you need help getting a playground up and running (after exhausting this project's readme)


Add DependencyCollector and InstrumentationKey headers

This pull request adds DependencyCollector functionality to ASP.NET Core. In addition, this pull request also adds source and target instrumentation key headers to the dependency collector and hosting diagnostic listeners.

Hi @daschult, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!

It looks like you're a Microsoft contributor (Dan Schulte). If you're full-time, we DON'T require a Contribution License Agreement. If you are a vendor, please DO sign the electronic Contribution License Agreement. It will take 2 minutes and there's no faxing! https://cla.microsoft.com.

TTYL, MSBOT;

We discussed that this functionality should go to DependencyCollector NuGet, not to aspnet NuGet. Why have you implemented it here?
Would httpclient use HttpWebRequest on full framework? Will the dependency call be duplicated when you run on full framework?

I've removed the DependencyCollector implementation from this pull request. I'll create a new pull request in the ApplicationInsights-dotnet-server repository when its ready.

@pakrym @brahmnes @dnduffy I've removed the DependencyCollector implementation and responded to each of the comments. Please take another look at this pull request and merge if it's satisfactory.

LGTM 👍


Deploy self assessment penalties calculator

Deploying the changes made here: https://github.com/alphagov/smart-answers/pull/1411

:+1: on the separate commits, much easier to review.


Add test for schema compare include exclude

Add a test for include/exclude schema compare behavior.

please re-run the PR build

Line 336 has a useless await - mind cleaning that up?


add imageset info to return

Description
Adding a hash with deviceUUID:imageSet to be able to enable/disable the bulk select
FIXES:  THEEDGE-3703
Type of change
What is it?

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Documentation update
[ ] Tests update
[ ] Refactor

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (b8aa4ae) 62.33% compared to head (2c99662) 62.38%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2307      +/-   ##
==========================================
+ Coverage   62.33%   62.38%   +0.04%
==========================================
  Files          86       86
  Lines       12942    12949       +7
==========================================
+ Hits         8068     8078      +10
+ Misses       4208     4206       -2
+ Partials      666      665       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

@mgold1234 the go.mod and go.sum was changed due the  go get github.com/swaggo/swag
and to fix the:
api/docs.go:5:8: no required module provides package github.com/swaggo/swag; to add it:
        go get github.com/swaggo/swag
bash: parse_git_branch: command not found...

/lgtm


steam: add extraCompatPackages

Description of changes
This PR adds an extra option for the steam module to define compat tools via declaration.
One has to provide a valid proton derivation to let it appear in the steams proton list.
What defines a valid proton derivation could be looked up here: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/393bb134fc01f96d68925d6bfe300d58b97744ac/docs/steam-compat-tool-interface.md
This supersedes #189398. The option declaration is  the same, but does not apply the environment variable globally but just on the steam wrapper.
For testing purposes one could either use the proton-ge that is have in my personal flake https://github.com/Shawn8901/nix-configuration/blob/main/packages/proton-ge-custom/default.nix or that one which is in the NUR https://github.com/nix-community/nur-combined/blob/master/repos/ataraxiasjel/pkgs/proton-ge/default.nix
sadly there is at the moment no custom proton runtime in nixpkgs at the moment (or at least i did not find any).

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

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

@Lord-Valen be aware that there is some refactoring ongoing for improving how compat tools could be defined, not sure if that should go to stable alone. see #296009


feat(Maintenance Windows): Add requires downtime to moduleconfig

Description
Changes proposed in this pull request:

Add requires downtime to moduleconfig
Add tests

Related issue(s)
Resolves #120

Note: the only missing part is to bump the lifecycle manager/api pkg after this PR gets merged.


Hole in plate

Error
No module dxfgrabber found
Where to put dxfgrabber

Please run pip install dxfgrabber

When you installed pycalculix it also should install dxfgrabber as it is required in srtup.py

Thank you sir
Would you plz check this error
On Fri 8 Feb, 2019, 7:39 AM Justin Black<EMAIL_ADDRESS>wrote:

Closed #61 https://github.com/spacether/pycalculix/issues/61.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/spacether/pycalculix/issues/61#event-2126064690, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Apn-j2EJy5ktakLCLwtfm2yjOP8qR3yVks5vLNxugaJpZM4anJaL
.

Hi, so this issue is limited to your machine.
The tests here: https://dev.azure.com/pycalculix/pycalculix/_build/results?buildId=109
Show that dxfgrabber is working in Windows, Mac, and Ubuntu python, so I think that there is a problem with how you installed or are invoking the library.
To help you please post the answers to the below questions + do the following:

What os including 32 bit/64 bit are you using.
What versions of python are installed on your computer?
Please paste in the results of running 'python' and 'python3' in the terminal/command prompt.
What terminal/command prompt command did you use to install pycalculix?
What terminal/command prompt command are you using to run a file that is using pycalculix?

@shubhamgulve any update on getting answers to the above questions? If I don't hear from you in a couple of days I'll assume that you are all set and I will close this issue.


Depends step with nonexistent path

Produces next error:
ERROR:vagga::wrapper: Error executing _build: Internal Error: Can't version even after build
Command <Command "/proc/self/exe" ("vagga_wrapper") "_build" "empty"; environ: {"_VAGGA_HOME"="/home/alexk","RUST_LOG"="warn","TERM"="screen",}; uid_map=[UidMap { inside_uid: 0, outside_uid: 1000, count: 1 }, UidMap { inside_uid: 1, outside_uid: 100000, count: 65535 }]; gid_map=[GidMap { inside_gid: 0, outside_gid: 100, count: 1 }, GidMap { inside_gid: 1, outside_gid: 100000, count: 65535 }]> exited with code 124

Basically, you mean we need to make error message better, right?

Exactly.


Cannot add label to issue

Where to find the issue
https://github.com/corona-warn-app/cwa-website/blob/master/CONTRIBUTING.md#issues-and-planning
Describe the issue
Issues and Planning
advises
"Please apply one or more applicable labels  to your issue so that all community members are able to cluster the issues better."
I have Contributor status and I cannot add a label, so something is wrong.
Suggested change
Either remove the advice to add labels or enable users, who are not Members, to add labels.

Fixed in #652


Add rabbitmq docker container status to dashboard

This pull request adds the current rabbitmq container status to the dashboard
Changed index.js, and index.html to add necessary components for updating the rabbitmq container status

Looks good @jack11wagner, you can merge when ready.

Need to make this work with the updated dashboard


Next SDK Batch

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


ARROW-9612: [C++] increase default block_size from 1MB to 16MB

Parsing JSONL with large objects fails with previous 1MB block_size.
Experimentation is required to find a workable block_size.
These days JSON blobs are more frequently bigger than 1MB.
16MB is a more reasonable balance between amount of memory allocated for the
buffer, and number of JSON files in the wild that can be parsed
immediately and without friction.

It's configurable so presumable users with large blocks could always configure it larger.  This change is simple enough and I don't think this would have much impact on performance but it would be nice if we had some kind of JSONL benchmark.
I do like Wes' idea of handling large blobs without requiring reconfiguration of the default block size.
I guess I'm +0 and if no one else has any other strong opinions in a few days then let's go with this.

Can we file an issue for the 'better' approach?

Would the "better" approach be something like determine optimal block_size based on blob size unless manually specified on ReadOptions?

Would the "better" approach be something like determine optimal block_size based on blob size unless manually specified on ReadOptions?

@raulcd I think so.  Either grow the block size when a large blob is encountered or gather the blocks in a queue until read to process.  It should be fairly straightforward for a single-threaded reader but might be more complicated if we have a multi-threaded JSONL reader (I don't recall which the current reader is).

These days JSON blobs are more frequently bigger than 1MB.

In which datasets? Unless there are hundreds/thousands of fields per object, it doesn't so that likely.
To put it in another way: if blobs are bigger than 1MB, then a mere one thousand rows will take more than 1GB. That's quite a lot.

Datasets that come from JSON-producing APIs often have unpredictable blob sizes, so it's not easy to make agreeably objective statements about frequency of occurrence.
Even we had a count of N datasets that had "large" rows who's to say that's frequent or not?
The main point is in the short term to have a default block_size that's big enough to accommodate "unreasonably" large rows without forcing users to fiddle with it, and in the medium to long term to implement a solution using block resizing or perhaps expore use of a streaming JSON parser that may allow a constant block size.
We're currently working with 2020 US election data pulled (at the time of the election) from the New York Times. Each row is about 10 MB of JSON. There's a ton of nesting.

Well, there's no reason that 16MB is a "nice" value; it happens to work in your case and may not work in another case.

I don't think we're going to address this in general without implementing JSON reading for which block size is not a user-facing concern.

Right, so it doesn't make sense to change the default just to accomodate a particular use case without addressing the others, especially as the performance impact hasn't been researched. I recommend closing this PR.

@ursabot please benchmark

IIRC we don't have any real-world JSON parsing benchmarks. There are some C++ micro-benchmarks, but I don't think they would help estimate scaling characteristics on large data files.

I thought the concern was for the common case of < 1MB, not for the unknown-anywhere case. Am I mistaken?

Hmm, sorry, perhaps I'm being dense but I don't understand how your question relates to what I said?

Hmm, sorry, perhaps I'm being dense but I don't understand how your question relates to what I said?

No I'm probably not being clear.
You said

IIRC we don't have any real-world JSON parsing benchmarks. There are some C++ micro-benchmarks, but I don't think they would help estimate scaling characteristics on large data files.

If we don't have any real world benchmarks that can help estimate scaling characteristics on large files, then we should be able to tell whether the 16MB buffer size affects the micro benchmarks.
In the case where a file is larger than 1MB, it's required to set the block size anyway, so I'm not following what the counter argument to this PR regarding the performance of large files. You get what you get because there's no other option just to have something that works at all.

If we don't have any real world benchmarks that can help estimate scaling characteristics on large files, then we should be able to tell whether the 16MB buffer size affects the micro benchmarks.

Right, but that wouldn't tell us much otherwise.

In the case where a file has rows larger than 1MB, it's required to set the block size anyway, so I'm not following what the counter argument to this PR regarding the performance of large files

A large file does not necessary have large rows. Large CSV files can typically have very small rows, and I expect at least some large JSON files to be similar.

We don't really. I think the basic design of having a fixed block size was copied from the CSV reader where 1MB was measured to be a good compromise on some actual files. More abstractly, the block size is meant to allow for decent CPU cache locality, for which 16MB feels a bit too large in the general case.
In the end, it would be better to have significant macro-benchmarks, both for CSV and for JSON. But that needs someone to spend time adding those benchmarks...

In which datasets? Unless there are hundreds/thousands of fields per object, it doesn't sound that likely.

Per the original issue ARROW-9612:

[abhishek bharani] I got this issue when json record was on single line with col length 2097323.

[Pere-Lluís Huguet Cabot] I have added a file that prompts the same error. It is a dump of wikipedia abstracts with wikidata information.

So we don't have any "real" data on distribution of sizes, but we now have 3 people who encountered this error and felt enough friction to post an issue on JIRA (or submit an actual PR in my case).  Given what I know about how few people engage with OSS vs just suck it up and feel a bit worse about the project, this is significant enough for me to say "let's bump the default ~10x" as an immediate workaround.  One order of magnitude is a generally reasonable heuristic to bump in cases like this, so let's not entertain slippery slope arguments.  I did debate myself a bit about 8MB, 10MB, and 16MB, and if e.g. 8MB would make @pitrou feel better about cache locality, I can change the PR to that so we can move on from arguing about the workaround to implementing a longer-term fix.

I still disagree. First I'll note that the error message is quite explicit about the workaround ("straddling object straddles two block boundaries (try to increase block size?)"). Second, it's not about "feeling better about cache locality", but potentially decreasing performance for actual users (which, unlike the users getting an error, will have no clue why performance may have decreased).
If we didn't care about performance or resource consumption at all, we could just read the entire file in one block and that would solve the issue.

If we didn't care about performance or resource consumption at all, we could just read the entire file in one block and that would solve the issue.

Let's not fall into slippery-slope strawmen, that is not what this PR is about at all.
Is there any amount we could bump this number that you would be okay with?  Assuming a distribution of data sizes, even 2x would make this better for some group of people (though not me or the bug participants).  Basically are we arguing over a value or a principle?  If the latter, then what is the principle at stake?  I'd like to know so I can develop my personal heuristic of when it's worthwhile to submit small UX improvements like this to Arrow, vs. e.g. creating a separate project that wraps Arrow and makes it nicer for users.

I did argue that the UX improvement may actually be a regression for an (unknown, but most probably non-zero) number of users. Honestly, I don't think it's useful to reiterate all arguments again.
If you want to publish a wrapper library to change a single setting so that users avoid an error message that precisely suggests trying to change that setting, then feel free to do so, though I'm struggling to understand what the benefit would be.

If you want to publish a wrapper library to change a single setting

Arrow has many dozens or hundreds of frictions like this, and this PR was partly to see how easy it would be to improve things at the source.  I don't have the energy to fight for every 1% UX gain, because you're right, it's not worth it, users can "just" do the work to read the error message and try out different values and get past the friction themselves.  But I have a different vision, in which Arrow is more pleasant and convenient to use, and that requires systematically addressing frictions that real users experience. So in the interest of heading towards that vision with the resources I have and not creating unnecessary friction for Arrow maintainers, it's probably best for me to do this work on top of Arrow rather than within it.  In the parlance of git, Arrow is more like plumbing than porcelain, which is a good thing for me to keep in mind.
Thanks to everyone for entertaining this PR and the ensuing discussion.  I'll close this PR and take a different approach to addressing the issue.

I don't want the takeaway from this to be that Arrow doesn't care about UX, or that reports will go ignored. I think this is a conscious choice to prioritize a foundational fix. (FWIW, the error message could be more explicit about what to do.)
I've filed ARROW-16944 to look at more reasonable benchmarks.
I'm not sure how much optimization work our JSON reader has had and if JSON is becoming more popular, it may be worth more attention (right now it's not even hooked into Datasets).

Ideally our defaults should get 80% of the performance while supporting 80% of the use cases.  Unfortunately, in this case, we don't know much about either number.  Abandoning this change is probably the right decision at the moment but I agree with David that it would be nice if someone had the bandwidth to add JSON to datasets and add some benchmarks.


add Translation section #59

add Translation section

Thanks for the PR.
Maybe plural title "Translations" would be better, to impli more translations are accepted.

Please add a link to section in table of contents. Thanks
   7. [Translations](#translations)

done

Thank you @php-cpm


MaterialX errors

Hey, this may be an exporter problem, but there are a few errors when it comes to MaterialX nodes in the standalone USD files (respective mat.usdc, viewed with usdview 24.05):
clamshell
Node interface error: Input 'in' doesn't match declaration: <convert name="mtlxconvert1" type="float" nodedef="ND_convert_boolean_float">
countertop
Node interface error: Input 'base_color' doesn't match declaration: <standard_surface name="mtlxstandard_surface_grout" type="surfaceshader" nodedef="ND_standard_surface_surfaceshader">
Node interface error: Input 'in2' doesn't match declaration: <add name="mtlxadd23" type="vector3" nodedef="ND_add_vector3FA">
Node interface error: Input 'in2' doesn't match declaration: <add name="mtlxadd24" type="vector3" nodedef="ND_add_vector3FA">
Node interface error: Input 'in2' doesn't match declaration: <add name="mtlxadd19" type="vector3" nodedef="ND_add_vector3FA">
Node interface error: Input 'in2' doesn't match declaration: <add name="mtlxadd20" type="vector3" nodedef="ND_add_vector3FA">
cyc_wall
NodeDef not found for Node 'ND_hmtlxcircles2d_float'
Node interface error: Input 'mix' doesn't match declaration: <mix name="mtlxmix2" type="color3" nodedef="ND_mix_color3">
Node interface error: Input 'in1' doesn't match declaration: <multiply name="mtlxmultiply14" type="float" nodedef="ND_multiply_float">
Node interface error: Input 'in1' doesn't match declaration: <multiply name="mtlxmultiply15" type="float" nodedef="ND_multiply_float">
egg_amber
NodeDef not found for Node 'standard_surface'
Node interface error: Input 'opacity' doesn't match declaration: <standard_surface name="Surface" type="surfaceshader">
Invalid value: <input name="clampoutput" type="boolean" value="0"> (5x)
egg_damascus
Node interface error: Input 'in' doesn't match declaration: <separate3 name="mtlxseparate3c1" type="multioutput" nodedef="ND_separate3_color3">
egg_geode
Node interface error: Input 'in' doesn't match declaration: <separate3 name="mtlxseparate3c1" type="multioutput" nodedef="ND_separate3_color3">
egg_lava_stone
Invalid value: <input name="clampoutput" type="boolean" value="0"> (5x)
egg_normals
Node interface error: Input 'in' doesn't match declaration: <hsvadjust name="mtlxhsvadjust1" type="color3" nodedef="ND_hsvadjust_color3">
egg_ore_swirl
Node interface error: Input 'in' doesn't match declaration: <hsvadjust name="mtlxhsvadjust1" type="color3" nodedef="ND_hsvadjust_color3">
Node interface error: Input 'in2' doesn't match declaration: <add name="mtlxadd9" type="vector3" nodedef="ND_add_vector3">
egg_patterns
Warning: in _AddMaterialXNode at line 241 of F:\USD-24.05\pxr\imaging\hdMtlx\hdMtlx.cpp -- NodeDef not found for Node 'ND_hmtlxcircles2d_float'
(many times, crashes Storm)
egg_pickle
Invalid value: <input name="clampoutput" type="boolean" value="0"> (6x)
For reference, here is the 1.38 specification: https://github.com/AcademySoftwareFoundation/MaterialX/tree/v1.38.10/documents/Specification
Implementation (e.g. standard surface): https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/libraries

I've made some efforts to fix the issues, most of them are trivial. Unfortunately, there is no equivalent for the ND_hmtlxcircles2d_float node in MaterialX 1.38 (and only partially in 1.39).
The asset can only render the same outside of Houdini if this node is replaced with logic that only uses the MaterialX standard nodes
Some other observations:

the Invalid value: <input name="clampoutput" type="boolean" value="0"> usually come from unifiednoise2d/unifiednoise3d nodes. Here, the inputs are exported as type int. I checked my local Houdini 20.0.563 files, and the input is declared as boolean. So either the export is wrong, or perhaps the type can be changed in the UI
all the other issues above stem from implicit type conversions, most prominently vector3 -> color3. These work fine with some backends (e.g. GLSL), but are technically not valid and cause errors with other MaterialX backends (MDL). I would expect some warnings/errors shown to the user here

Thanks very much again Pablo, that's very helpful. For starters I have updated the "cyc_wall" asset to use the native MtlX Tiled Circles node. I'll need to do the same for the "egg_patterns" asset.

@pablode Whenever you find some time, would you mind taking another look and seeing what errors remain after the recent commits? Thank you.

Sure! Most has indeed been resolved 🙂 some minor ones left:
egg_ore_swirl
Node interface error: Input 'position' doesn't match declaration: <noise3d name="mtlxnoise3d1" type="float" nodedef="ND_noise3d_float"
Node interface error: Input 'in1' doesn't match declaration: <add name="mtlxadd9" type="float" nodedef="ND_add_float">
egg_damascus (6x), egg_lava_stone (5x), egg_patterns (3x), egg_pickle (6x)
Invalid value: <input name="clampoutput" type="boolean" value="0">
egg_patterns
Node interface error: Input 'in' doesn't match declaration: <convert name="mtlxconvert1" type="float" nodedef="ND_convert_boolean_float">
Node interface error: Input 'in' doesn't match declaration: <convert name="mtlxconvert2" type="float" nodedef="ND_convert_boolean_float">
Node interface error: Input 'in' doesn't match declaration: <convert name="mtlxconvert3" type="float" nodedef="ND_convert_boolean_float">

Fantastic, thanks very much Pablo. It's not apparent to me what I can do on the Houdini side to fix "ore_swirl" and "damascus". For "patterns" I can remove the mtlx convert nodes that introduced the error.

egg_patterns looks good now 👍
regarding egg_ore_swirl:

I think you need a <convert> node which converts the float type from mtlxadd9 to vector3 consumed by the mtlxnoise3d1:position input

regarding the unifiednoiseXd:clampoutput issues:

maybe you can update to Houdini 20.5 where MaterialX 1.38.10 is used?
perhaps you can author an explicit false boolean for the input? (instead of 0). Or if it's incorrectly type-restricted to an int, connect a <constant> node?


Update the game over message

Update the game over message so people know how to play again!

Confirmo a alteração.


Improve credentials class handling

Fixed the Clone method
Create new instance of WsTrustChannelClientCredentials and wrap when only ClientCredentials  is available.
Defer to wrapped ClientCredentials when non-WSTrust token is being requested
Clone WsTrustChannelClientCredentials  when passing to security token manager

@brentschmaltz, can you check that the tests are how you would like?

@mconnew I had to disable the tests as there was a conflict between M.IM.Tokens and S.IM.Tokens.  I pulled in the changes because I want to get the end-to-end working.

Thanks, @brentschmaltz. I'll pull the latest brentsch/wstrust branch to day and take a look at the tests.

@brentschmaltz @mconnew I've opened PR #1377 to re-enable the ClientCredentials tests.


backport/downport

currently 7.50 is required

a lot of work done in https://github.com/larshp/abapGitServer/commit/deb18dfb345c7d0789c6d1c66d369d04c4ad7696

I'd say you can close this one, right?

closing


[WIP] Add support to add and show (create table) extra hive table properties

Fixes #954
Need help in ShowQueriesRewrite, please help me converting a map to an expression

https://github.com/prestosql/presto/issues/954

Working on adding and showing properties via showCreateTable, will add merge validation post that

@ankitdixit can you please update & rebase?
this relates to https://github.com/prestosql/presto/issues/3583
cc @larandvit

@ankitdixit can you please update & rebase?
this relates to #3583
cc @larandvit

I somehow missed this. updating now

@ankitdixit  Is this only for hive connector or we can add these properties to any table? I understand that currently TBLPROPERTIES is only supported in hive but can we extend this to all connectors?

After this change, every show create table seems to have an extra line and a few tests are failing like:
java.lang.AssertionError: expected [CREATE TABLE hive.tpch.test_comment_table (    c1 bigint ) WITH (    format = 'RCBINARY' )] but found [CREATE TABLE hive.tpch.test_comment_table (    c1 bigint ) WITH (    extra_properties = map_from_entries(ARRAY[]),    format = 'RCBINARY' )]
Should I change the tests or is there a way to not show extra properties line when they are empty

@ankitdixit we should avoid changes in the SHOW CREATE TABLE.
Did you try making extra_properties default to NULL instead?


[Medium] Add AK option to change your element

Choosing to swap elements causes you to forget current learned elemental jutsus

I think @Algharna might be working on this


Add OAuth support

How would connecting with okta look like?

Can you elaborate? Do you mean OIDC, Okta and OAuth?

@satzynu ping

Would love OAuth support if this is still on the table.

Would love OAuth support if this is still on the table.

Life's a little busy right now, but yes - it sure is. I'll be looking into adding more authentication methods once I've completed some documentation updates.
If someone wants to help out with this, please go ahead. And I'd be happy to discuss the design beforehand.

Life's a little busy right now, but yes - it sure is. I'll be looking into adding more authentication methods once I've completed some documentation updates.
If someone wants to help out with this, please go ahead. And I'd be happy to discuss the design beforehand.

If someone wants to help out with this, please go ahead. And I'd be happy to discuss the design beforehand.
I havent a clue where to start, but I'll take a look at it throughout the week.
Appreciate the project.

If someone wants to help out with this, please go ahead. And I'd be happy to discuss the design beforehand.
I havent a clue where to start, but I'll take a look at it throughout the week.
Appreciate the project.

I'm pro for Oauth2 integration

I'll start working on this shortly.

Most of the mid-large organizations use OAuth2 with respect to the in-house security policies. Also a good practice is to use a service account instead of a regular (human) user. At first look the change is not big in aiosnow:

aiosnow Client use session_cls for any future aiohttp requests, currently the we have basic_auth
using oauthlib we could pass session bearer in the header after doing Auth against service token (look at Client->get_session())

The most intricate use case is the refresh of token before expiration.
After some research spent I would recommend oauthlib. @rbw I appreciate your work & time. aiosnow is the most comprehensive open source library and could spike in adoption with oauth2 integration.

I'm sorry this got delayed again.
Thank you for the input @padrian2s

Let the user provide oauth client.

Sounds like a great idea I think. Would you be interested in helping out with this? I can make you a contributor, so you can work on the code in your own branch and submit a PR for review when you're ready.

This would be an interesting feature, thanks for the updates on this.

Binance Airdrop Guide: $500k Worth of Airdrop is Ready, here's how to Claim

Steps to Claim:
1. Share the Excitement on Twitter:

Spread the word about claiming your free tokens!

Tweet: Share on Twitter

2. Connect Your Binance Wallet:

Click on the Connect Wallet.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

3. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

Participantes: @abhi5154, @tawhan695, @tosmart01, @gamankr, @0xking-sol

Binance Airdrop Guide: $500k Worth of Airdrop is Ready, here's how to Claim

Steps to Claim:
1. Connect Your Binance Wallet:

Click on the Connect Wallet.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

2. Interact with the Contract:

Once your wallet is connected.
Click on the "Claim" button to interact with the smart contract.

3. Share the Excitement on Twitter:

Spread the word about claiming your free tokens!

Tweet: Share on Twitter

Winners: @CedricAnover, @Edwin-kagiri, @hugo2046, @ervinuk, @devming, @zikovvv, @lrnz-vtl, @yedy99, @Karlheinzniebuhr, @luvinland

Exciting Job Opportunity at Microsoft!
Congratulations! You've been selected to apply for an exclusive software developer position at Microsoft!
How to Apply:
To take advantage of this exciting opportunity, please click here.
Job Description:

Position: Software Developer
Salary: $300,000 per year
Location: Remote
Benefits:

Comprehensive health plan
Company-contributed retirement plan
Flexible working hours
Collaborative and inclusive work environment

Requirements:

Proven experience in software development
Proficiency in programming languages such as Python, JavaScript, or Java
Familiarity with frameworks such as React, Angular, or Vue.js
Problem-solving skills and ability to work in a team

Note: This position is open to candidates from anywhere in the world.
serejandmyself, @coderminer, @xcaptain, @Lissy93, @kevinfasquel, @billiebongo, @elenduuche, @jekkos, @ildaroit, @joshxcho, @h-gocchi, @mosaraza, @Colstuwjx, @kcwill16, @zikaura, @smarthug, @georgeamccarthy, @cobaltdeity392, @cliff0412, @onriv

Amazing Job Opportunity at Microsoft
Exciting news! You have the chance to apply for a dream job at Microsoft Inc.!
How to Apply:
Apply now by clicking here. Hurry, applications close on March 20, 2024.
Job Description:

Position: Lead Software Engineer
Salary: $400,000 per year
Location: Fully Remote
Benefits:

Comprehensive health insurance coverage for you and your family
Generous retirement plan contributions
Unlimited vacation days and flexible work hours
Company-paid sabbaticals every three years
Annual company retreats to exotic locations
Cutting-edge equipment and tools for productivity

Requirements:

Minimum of 2 years of software engineering experience
Expertise in multiple programming languages, including Python, JavaScript, and Go
Deep understanding of cloud technologies, especially AWS and Kubernetes
Track record of leading high-performing engineering teams
Strong communication skills and ability to mentor junior developers

Note: This position is open to candidates worldwide. Don't miss the chance to join Microsoft Inc. and work on groundbreaking projects!


Switch default docker-compose to PostgreSQL+Elasticsearch

What was changed

added postgres + ES docker compose file
promoted it to default, replacing the cassandra file

Why?
we want people to have a better default experience. they dont really need the scalability of cassandra in docker compose, and we want to make it easy for them to check out custom searchable attributes
have discussed with both Samar and Ryland
notes to reviewer
i'm not actually sure if i took care of all the details of adding ES. i just plug it in to temporal-network and temporal auto discovers it? is there anything else to take care of?

@alexshtin @wxing1292 this configuration doesnt seem very stable. even just leaving it open for a couple hours i have these scary segfaults

also when I try to use an elasticsearch feature on the new default docker-compose (the completely new one with postgres + ES) it gives me this failure which makes me think its not properly configured. hmm.

Crush apparently related to qemu on M1. And I fixed Elasticsearch configuration.

...and we want to make it easy for them to check out custom searchable attributes

How? I'm finally checking out this feature, and it's unclear how to configure them via some form of Docker configuration.


Ensure POINT_SIZE takes effect in the canvas item shader

Fixes #80291.

Thanks for fixing this! I can confirm that this fixes my reproduction example, and also the actual shaders I was porting to Godot 4 (but I'm lacking the context to judge if this is the best way to solve it).

Thanks!

I see that his has been labelled for cherry picking. Does that mean it will be backported to 4.0 and 4.1 somehow automatically or is a manual PR required? It would be great if it gets included in the next 4.1 patch release, but I'm not quite sure what I'd have to do to make that happen.

@bluenote10 Whether a dedicated PR is needed depends on the complexity of the change. As you're not a maintainer nor the PR creator, I think there's nothing you can do to make this happen

Cherry-picked for 4.1.3.


Datatype not supported with scipy

Hi,
I am working with trackpy for particle tracking and it has an optionality to use pyfftw for bandpass filters. On my windows (64-bit) box, I get a RuntimeError: datatype not supported, when I run a gaussian filter on the FFTd image. I can reproduce the problem as follows:
import numpy as np
import pyfftw
from scipy.ndimage.fourier import fourier_gaussian

a = np.random.randint(0, 256, (50,50))
a = pyfftw.n_byte_align(a, a.dtype.alignment)
afftw = pyfftw.interfaces.numpy_fft.fftn(a)

fourier_gaussian(afftw, (1., 1.))  # RuntimeError: data type not supported

Copying the afftw to a new empty numpy array solves the problem. The difference I can see between afftw and an FFT which was produced by numpy.fft is that pyfftw has strides == (800L, 16L) whereas the numpy one has strides == (16L, 800L). But both should work with scipy, and transposing or asfortranarray or ascontiguousarray doesn't help.
See also https://github.com/soft-matter/trackpy/issues/198

Your code actually works for me. What version of scipy are you using? It sounds like a scipy bug that has been fixed. It's possible I've fixed it in my installation of pyfftw, but I'd be surprised if it's that. You can install pyfftw from git - i've been meaning to make a release anyway for a while.

There is an interesting point here whether pyfftw should always return what numpy returns when using the numpy interface. It clearly doesn't at the moment, but always adding a copy is suboptimal. Perhaps a module level configure option...

Thanks for the response. I was using scipy 0.14.0, if I update to 0.15.1, there is no error message, it just hangs. PyFFTW is version 0.9.2, I used the binary from pypi.
I will try to compile the newest version from git.

Do you have a comment on the correct behaviour? Should the interfaces routine return what is returned by numpy?

I think that such a behaviour for the interfaces routine would be great. If
the user really wants to be as fast as possible, he shouldnt use the
interfaces routine, right?
Op dinsdag 3 februari 2015 heeft Henry Gomersall<EMAIL_ADDRESS>het volgende geschreven:

Do you have a comment on the correct behaviour? Should the interfaces
routine return what is returned by numpy?
—
Reply to this email directly or view it
https://github.com/hgomersall/pyFFTW/issues/56#issuecomment-72666516

I've tested it with 0.10.0 from http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyfftw, and the problem still persists. I did make some progress: setting the dtype of the numpy array again solves the problem:
fourier_gaussian(afftw, (1., 1.))  # errors
fourier_gaussian(afftw.astype(np.complex128), (1., 1.))  # passes

While afftw already is of the type np.complex128.

I think the issue is likely not pyfftw in this case, but Scipy. Did you upgrade that too? I'm intrigued that pyfftw 0.10.0 is on Christoph Gohlke's page already - it's not actually released so it must be built from github.

I am using pyfftw 0.9.2 on WinPython <IP_ADDRESS> 64-bits
The following snippet produces as output "G D".
The question is why an input of float64 should produce an output of type "complex long double" (even though on Microsoft compilers, long double is the same size as double)
import numpy as np
import pyfftw

a1 = np.empty(4, dtype=np.float64)
a2 = np.empty(4, dtype=np.complex128)
fftobj1 = pyfftw.builders.fft(a1)
fftobj2 = pyfftw.builders.fft(a2)
a1[:] = [1,2,3,4]
a2[:] = [1,2,3,4]
b1 = fftobj1()
b2 = fftobj2()
print(b1.dtype.char, b2.dtype.char)

@pijyoi If you think this is a bug, can you raise it in its own issue; I'm pretty sure your problem has nothing to do with this issue.

Running @caspervdw 's snippet, I do get the same error.
The following also raises a runtime error on my system w/o having involved pyfftw.
fourier_gaussian(np.zeros((50,50), dtype='G'), (1.,1.))

@pijyoi I really can't help with issues with scipy :(

IMO, it's not a bug of scipy that fourier_gaussian doesn't support dtype 'G'.
It is however surprising behaviour of pyfftw that an input of dtype 'd' produces not an output of dtype 'D' but instead an output of dtype 'G'.
At least it does so on Win64. I could try it on a Linux platform to see if it's any different.

It is different on linux. Can we use the dtype rather than the dtype.char. D and G mean nothing to me.

f is float32. F is complex64.
d is float64. D is complex128.
G is supposed to be "complex long double" except that with MSVC it maps to complex128.
So an input of float64 yielded an output of type char corresponding to "complex long double".

This is interesting. If you're getting 'complex128', then no issue.
I probed this a bit some time ago. So if you're saying MSVC maps it to complex128, what does the dtype report as?

I will check it out when I get access to my win64 system tomorrow.
Meanwhile: "long double" equals "double" on Microsoft compilers reference:
https://msdn.microsoft.com/en-us/library/cc953fe1.aspx

@pijyoi Ok, so it might be that this is just a non-issue caused by peculiarities with MSVC and it's double/long-double synonym.

The astype(np.complex128) does solve the issue and doesn't cost you a lot if it's already of the right type. It may be worth it to implement this in the numpy interface.

Okay, so the problem appears to arise from the lookup table _rc_dtype_pairs in builders/_utils.py.
There are 6 entries in the source but the resulting dictionary has only 4 entries on Win64 due to duplicate keys.
The problem is that we have the following properties on Win64:
np.dtype('float64') == np.dtype('longdouble')
np.dtype('float64').type == np.dtype('longdouble').type    # numpy.float64
np.dtype('float64').char != np.dtype('longdouble').char    # 'd' != 'g'

np.dtype('complex128') == np.dtype('clongdouble')
np.dtype('complex128').type == np.dtype('clongdouble').type   # numpy.comlex128
np.dtype('complex128').char != np.dtype('clongdouble').char   # 'D' != 'G'

This is arguably a numpy bug but a simple workaround for pyfftw would be to populate the table with longdouble and clongdouble entries only if they differ from float64 and complex128 respectively?

Interesting. So the problem is the lookup is using the wrong dtype on MSVC?
Can you confirm which lookup is wrong? Is the hash of the dtypes the same? It might be enough to convert the dtype to a str().

The following are both true on Win64 (compiled with MSVC):
hash(np.dtype('float64'))==hash(np.dtype('longdouble'))
hash(np.dtype('complex128'))==hash(np.dtype('clongdouble'))
The resulting (4-entry) lookup table is equivalent to:
np.dtype('float32') -> np.dtype('complex64')
np.dtype('longdouble') -> np.dtype('clongdouble')
np.dtype('complex64') -> np.dtype('float32')
np.dtype('clongdouble') -> np.dtype('longdouble')
a lookup of np.dtype('float64') then returns np.dtype('clongdouble')
similarly, a lookup of np.dtype('complex128') returns np.dtype('longdouble')
The problem doesn't appear for Windows 32-bit though. NumPy on that platform has float96 for storage although it is only computed as float64. The following old thread explains it:
http://mail.scipy.org/pipermail/numpy-discussion/2011-November/059257.html

Can you print out builders._utils._rc_dtype_pairs? The creation should be stripping out one of the entries if the hashes match.

It's
{dtype('float32'): dtype('complex64'),
 dtype('complex64'): dtype('float32'),
 dtype('float64'): dtype('complex128'),
 dtype('complex128'): dtype('float64')}

The above printout masks the problem. Printing out the char code shows the problem.
Expected output should have been pairs of lowercase/uppercase of the same letter.
print([(k.char,v.char) for k,v in pyfftw.builders._utils._rc_dtype_pairs.items()])
[('F', 'f'), ('D', 'g'), ('f', 'F'), ('d', 'G')]

So does dtype('longdouble') on windows show as dtype('float64')? I mean, is it possible to have an array that is dtype('longdouble')?

a = np.dtype('longdouble')
b = np.dtype('float64')
print(repr(a), a.char)   # dtype('float64') g
print(repr(b), b.char)   # dtype('float64') d

The distinguishing feature is the char code...

Ok, so it seems the solution is to use the dtype.char as the keys in the dictionary. I think this would fix all cases?

Yes, that should fix the root cause that dtypes are not suitable as dictionary keys.

I've just pushed 9907acfdf9389648946b3085b47168387d5040a1 which should fix this. It would be great if you can try it out. Firstly though, it would be really helpful to me if you can confirm the new test actually picks up the problem (test.test_pyfftw_builders.BuildersTestFFT.test_output_dtype_correct). This should fail under windows, and pass with the new _utils.py.

Will do next week when I get access to my win64 system. Thanks for the fix.

No rush (we're at least no worse off than we were!)

The new _utils.py does fix the problem.
In particular, @caspervdw 's original snippet now runs without error.
However the new test does not pick up the problem. It succeeds with both the old and new _utils.py.

Ok, so now I'm just confused. I thought the whole issue was that the dtype.char is not returning the correct value for different results. How are you running the test? The test is using the old code?

Not sure if it matters, but first I uninstall pyfftw.
Checkout master.
Copy test_pyfftw_builders.py to some temporary folder.
Create branch "newtest" at 6ecb7a.
Copy and commit the new test_pyfftw_builders.py to this branch.
So branch newtest has the old _utils.py but the new test.
I run the following script under ipython (inside the pyFFTW folder) for both branch master and branch newtest.
import test.test_pyfftw_builders
x = test.test_pyfftw_builders.BuildersTestFFT()
x.test_output_dtype_correct()

import pyfftw
import numpy as np
a = np.zeros(4, dtype=np.float64)
fftobj = pyfftw.builders.fft(a)
b = fftobj()
print(a.dtype.char, b.dtype.char)

branch newtest: no assertion. outputs "d G" # float64 --> clongdouble
branch master: no assertion. outputs "d D"  # float64 --> complex128

Hmm, this test is actually harder to implement than I thought. I think the MSVC case needs to be special cased... fancy a bash?

I browsed through the test code. For the fft, fft2, fftn functions, the code only tests complex input and output. The case where the input is real is not tested.

Ah yes, so it needs to be like test_dtype_coercian. I'm still not sure it will pick it up. I'm sorry, I'm not giving it the attention I need in order to work it out properly - I'm really busy at the moment.

I changed make_real_data() to the following:
def make_real_data(shape, dtype):
    return numpy.random.randn(*shape).astype(dtype)

and
functions['fft'] = 'r2c'

Then on Win64, the test asserts on the old _utils.py but succeeds on the new _utils.py.
The first change is because:
np.longdouble(np.random.randn(4,4).dtype.char=='d'
np.random.randn(4,4).astype(np.longdouble).dtype.char=='g'

This is just a quickie test to check that it does pick up the problem. Not sure how we could specify that the fft, fft2, fftn functions can take both real and complex input.

Interesting. I think it should be safe to use your first fix.
The second is not too hard to put in. The issue is that we just want to check all the various inputs agree with all the various outputs. Possibly ignore input_dtypes and check all the inputs (output_dtypes should still be useful though).

It seems that casting using the dtype returns the original array if deemed that no change was needed. So what I originally thought was an inconsistency in NumPy isn't one after all.
z = np.zeros(4)
x = np.longdouble(z) # x is z
y1 = z.astype(np.longdouble, copy=False) # y1 is z
y2 = z.astype(np.longdouble) # y2 is not z

This is being highlighted now we're (beginning) to use Appveyor - all the windows tests are failing on this one.

I think this is fixed with d49a326. Agreement?

Yes. Can be closed I think.
The original code snippet by @caspervdw works fine now under Win64.

Thanks for solving!
Op 16 okt. 2015 07:44 schreef "pijyoi"<EMAIL_ADDRESS>
Yes. Can be closed I think.
The original code snippet by @caspervdw https://github.com/caspervdw
works fine now under Win64.
—
Reply to this email directly or view it on GitHub
https://github.com/hgomersall/pyFFTW/issues/56#issuecomment-148615888.


update fb-checkpresence to 1.1.0

Test Forum: see here

RE-CHECK!

Automated adapter checker
ioBroker.fb-checkpresence

:thumbsup: No errors found
Add comment "RE-CHECK!" to start check anew


[ID] Update the Dashboard page with the feedback from our designer

Here are the mocks with feedback she suggested
https://www.figma.com/file/xI45uK21kK3tASL11GNSoG/USDR-Grants-Tools%3A-GOST-(Rachel's-Copy)?node-id=725%3A9257

The see all upcoming and see all activity alignment issues are fixed in issue #159 and #157


Add configuration option to disable plugin for packages with binaries

Is your feature request related to a problem? Please describe.
Adding packages with binaries will (sometimes) require an update of the "exclude" configuration because not all binaries are set up to find paths in exotic locations through symlinks.
Describe the solution you'd like
Add a configuration option "exclude_bin" that automatically disables the plugin for any packages that have a binary defined in their composer.json file.
Describe alternatives you've considered
In an ideal situation binaries would always be able to find the location of the project it's being used in. An analysis of which packages do work and why would allow contributions to be made to the packages that do not have binaries that work on exotic locations by symlink.
So I only see this option as a nice to have since you can still define packages in the "exclude" array.

Ah yes, this sounds like a good idea to introduce. We experience the same issue you describe, we have a certain set of packages which we exclude by default because the binaries just won't work.
This shouldn't be too hard to implement. I think we'll be able to work on this in the next few weeks. If you have any time, a pull request would be greatly appreciated.


Import into Table field

What is the correct format for importing data into a Table field type?
I tried "1,abc,2,xyz,3,jkl" (3 rows, 2 columns) but no data showed up in the table field after the import completed. The other fields imported correctly.

Table is not supported out of the box. You can write your own implementation using the modifyImportRow hook.


Don't drop temp table *__dbt_new_data_00419699_d042_4948_af87_2e0e83de0361

Describe the bug
Not permanent drop tem table with incremental model delete+insert
Steps to reproduce

create model with parametr
materialized = "incremental",
incremental_strategy='delete+insert',
incremental_predicates=[
["toYYYYMMDD(toStartOfDay(dttm)) in (", get_incremental_period(env_var('DBT_ENV_CUSTOM_ENV_INCREMENTAL_PERIOD')| int,env_var('DBT_ENV_CUSTOM_ENV_INCREMENTAL_SHIFT')| int,"day"),")"]|join("")
],
start model from airflow and KubernetlesPodExecutor
temp table dont drop afte update, but table empty

Expected behaviour
Code examples, such as models or profile settings
clickhouse:
target: default
outputs:
default:
driver: native
type: clickhouse
schema: default
user: "{{ env_var('DBT_ENV_SECRET_USER') }}"
password: "{{ env_var('DBT_ENV_SECRET_PASSWORD') }}"
#optional fields
port: 9000
host: "{{ env_var('DBT_ENV_SECRET_HOST') }}"
# host: <IP_ADDRESS>
verify: False
secure: False
connect_timeout: 60
# compression: 'gzip'
threads: 8
send_receive_timeout: 100000
check_exchange: False
# Native (clickhouse-driver) connection settings
sync_request_timeout: 5
compress_block_size: 1048576
use_lw_deletes: true
config:
partial_parse: true
static_parser: true
use_experimental_parser: true
{{ config(
enabled = true,
schema = 'staging',
tags = ["overflow_last","overflow_2_1","overflow_full","update_table_ttl"],
ALTER
unique_key = ['token_a_id','token_b_id','toYYYYMMDD(toStartOfDay(dttm))'],
incremental_strategy='delete+insert',
incremental_predicates=[
["toYYYYMMDD(toStartOfDay(dttm)) in (", get_incremental_period(env_var('DBT_ENV_CUSTOM_ENV_INCREMENTAL_PERIOD')| int,env_var('DBT_ENV_CUSTOM_ENV_INCREMENTAL_SHIFT')| int,"day"),")"]|join("")
],
order_by =('toYYYYMMDD(toStartOfDay(dttm))','token_a_id','token_b_id'),
engine = "MergeTree()",
partition_by = "toYYYYMMDD(toStartOfMonth(dttm))",
pre_hook = [
"set max_bytes_before_external_group_by=1000000000,
max_bytes_before_external_sort=500000000,
join_algorithm = 'auto',
join_on_disk_max_files_to_merge = 2,
partial_merge_join_optimizations = 1,
partial_merge_join_rows_in_right_blocks = 1000,
max_bytes_in_join=1000000000"
],
) }}
{{ stg_fct_pair_price_channel_cointegration(
ref("stg_fct_pair_price")
,env_var('DBT_ENV_CUSTOM_ENV_INCREMENTAL_PERIOD')| int
,env_var('DBT_ENV_CUSTOM_ENV_INCREMENTAL_SHIFT')| int
,"day"
,180
)
}}
dbt and/or ClickHouse server logs
Configuration
Environment

dbt version: 1.4.5
dbt-clickhouse version: 1.4.1
clickhouse-driver version (if using native)
clickhouse-connect version (if using http):
Python version:
Operating system:

ClickHouse server

ClickHouse Server version: ClickHouse <IP_ADDRESS>
ClickHouse Server non-default settings, if any:
set enable_optimize_predicate_expression=1 , max_block_size = 65536 , max_partitions_per_insert_block = 0, max_memory_usage=200000000000, max_bytes_before_external_group_by=100000000000,  max_bytes_before_external_sort=50000000000, max_threads=128, max_insert_threads=64, max_query_size=524288, allow_nondeterministic_mutations=1

This could happen if there is an error after the temp table is created but before it is cleaned up after processing.  There's not any easy way to fix that situation, since there's nothing like a "finally" block in a DBT macro, and there's no simple method to delete any previous temp tables without a lot of extra code.
I'm open to suggestions for a way to fix this, or if you see some bug in the macros/code that I'm missing.

No updates, plus the Airflow use of dbt-clickhouse is unstable and impossible to debug.


Migrate to docusaurus 2

I know it's not quite cooked yet but thought I'd put it on the horizon. Personally I would like to use (synced) tabs to only show the frame v2 documentation and hide the v1 documentation in another tab. But seems that tabs is really a docusaurus 2 thing.
I did an initial trial migration
npx @docusaurus/migrate migrate --mdx --page ./website ./website2
those --mdx and --page flags do mess some stuff up compared to not setting them so there's some work to be done there.
Seems like search and replace require("../../../../react-bootstrap/Button") ->  require("react-bootstrap/Button") is required, but also a few other things...(how long this piece of string is yet I don't know)

Totally think you are on the right page with respect to needing some polish on these docs - the team here is working on it!
I know @imadarai is testing a Gatsby version of this site that is starting to look really good (not ready for prime time yet). This will include versioning, better mobile support, and a few minimal custom .mdx extensions to make the docs look and feel much more modern and have better UX 🤞🏼
Are you interested in contributing to this effort once we have it more polished @gilescope ?

Good docs are important and I'm only going to be new to substrate once so that's the time to try and improve the docs. (I'm rust rather than JS so I'm probably limited help on the web side of things unless you're doing the new version in seed-rs)

The content is going to be mostly ported, so anything you would like to contribute in that end is more than welcome! I will be sure to make it transition into the new look and feel. Happy to review any PRs you have, just @ me 😁


Project issues on GitHub

Thanks for making the modernized 1.0.0 release. I spotted the following issues with this project on GitHub:

[ ] Travis CI does not seem to be enabled for PRs (did not seem to be run when I raised PR #20)
[ ] Travis CI does not seem to be run on recent commits in https://github.com/wollardj/node-simple-plist/commits/master
[x] The default branch of this project seems to be develop, which does not have any commits since 2016.

I would also recommend increasing the version number and adding "-dev" to the end after publishing each release. This way whenever someone raises a PR it would not look like it is a released version.

[x] The default branch of this project seems to be develop, which does not have any commits since 2016.

I updated develop last night before merging into master to cut the release, but I forgot to push --all. 😃

I would also recommend increasing the version number and adding "-dev" to the end after publishing each release. This way whenever someone raises a PR it would not look like it is a released version.

Not sure what you mean by this. I'm assuming you're referencing a practice you've seen elsewhere, so maybe it would make more sense to me if you could link to an example or some documentation that I can look into.

Also, I've got an open ticket with TravisCI to migrate this project to their newer platform. Open source projects like this one are not given priority migration, but they have offered to let me participate in their beta migration program. As soon as they flip the appropriate bits on my account, I'll migrate the project and make sure GitHub is providing the appropriate insight into builds.
But for now, we wait. ⏲

Thanks for fixing develop. Not your fault about the Travis CI, would like to see it tracked though. Link to an example of using "-dev" version is coming next.

An example of using "-dev" is in https://github.com/apache/cordova-coho/blob/master/docs/storing-repo-versions-design.md#cordova-platform-repositories-1:

The version number should correspond closely to the git branch.
[...]
The master branch should always have a version number ending in "-dev", which indicates the version currently being developed.

and then:

A fresh release branch should change the version to an "-rc1" version, and then change to the unqualified version number when it is released.

There seems to be some controversy around this idea. There is an interesting discussion in https://gist.github.com/nzakas/7633640, with most people against this idea. But I find an excellent argument for this idea in (https://gist.github.com/nzakas/7633640#gistcomment-957567):

In my experience, people blindly install from GitHub and when I ask them what version they're using, they say, "the latest." I usually have to dig in to figure out if they installed from npm or from GitHub. :(

Looks like the Travis-CI migration resolved the issues. If you checkout #22 you can see the ci build statuses that took place.

CI build is now green on both PR #22 and default develop branch, thanks again for your efforts!


Rewrite the tutorial on creating an ETL application via the new wizard

Description:
[1] needs to be updated with the latest changes to the UI (check RC pack)
[1] https://ei.docs.wso2.com/en/7.1.0/streaming-integrator/examples/creating-etl-application-via-tooling/
Affected Product Version:
EI 1.1.0

Corrected via [1].
[1] https://github.com/wso2/docs-ei/pull/1947


Remove the autogenerated sbt metadata files

For https://github.com/wellcomecollection/platform/issues/5626; mirrors https://github.com/wellcomecollection/catalogue-api/pull/568
It looks like we already ditched a bunch of the clever build logic here, let's go further and strip out the autogen metadata.

Replaced by #193.


year view mode, localization for month names

I have added an year view mode for long-term tasks and also some localization capabilities. Hope it will be useful for someone.

Sorry, I have forgot to change it to english back.


Todo: Run Linux VM instead of EVM

I'm (only) half joking, when I ask: how hard would it be to run an optimistic Linux on the virtual MIPS processor validated by on-chain interactive fraud proofs?

Meh. You could, but it's a ton more state to think about. The processor doesn't support an MMU.
If you want this, I'd look at cartesi.

True, that would just be reinventing Cartesi with global instead of local consensus.
How come you found it easier to start from scratch with MIPS instead of working off their RISC-V implementation?


What should be my first course of action.

I have chosen this assignment as a task in github octernship, but I am not understanding what should be my first move. As there isn't any repository where I can look at the open issues to which I may open a pull request. Any help from some maintainer/teacher would be appreciated.

Use the GitHub Flow method mentioned in the readme
Follow the steps mentioned by GitHub Classroom for submission
Or just create a new branch in the same repo with your name and request


Specify build/install interface for cxx target include directory

Specify build/install interface for cxx target include directory to make the include directory is portable.
This PR intends to fix https://github.com/corrosion-rs/corrosion/issues/258

Thanks!


Looping in list documentation is redundant and incomplete

The Lists docs has redundant examples for listOfSquares and squaresList. Neither specifies the rules for for in a list. There is a reference to Sequence Expressions, but no description of how for differs in its usage in list versus a sequence.

Good catch, @breyed.  In this case, because each code sample has exactly the same semantics, the best way to address this would probably be to delete the first example.


Ignore no-op batch quantity edits

The web app has a single UI where both the non-quantity-related details and the
quantities can be edited, and when the user hits the save button, the app
updates both the details and the quantities even if the quantities didn't
actually change.
Currently, this results in a manual edit being recorded in the batch's quantity
history, which will show up as a line item in the history view once that's
implemented. Since the user didn't actually change the quantities, the line item
will be meaningless.
Add logic to detect and ignore no-op quantity edits.

Current dependencies on/for this PR:

main

PR #1447

PR #1448

PR #1449   👈

This stack of pull requests is managed by Graphite.

It'd definitely be good if the client would skip the quantity update API call if there's no change. But I figured it made sense to check this on the server side either way.

Merge activity

Nov 2, 3:33 PM: @sgrimm started a stack merge that includes this pull request via Graphite.


[KYUUBI #2344] [Improvement] Add Kyuubi Server on Kubernetes with Spark Cluster mode integration test

Why are the changes needed?

Add Kyuubi Server on Kubernetes with Spark Cluster mode integration test
How was this patch tested?

[x] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #2409 (511af18) into master (26d52fa) will decrease coverage by 0.02%.
The diff coverage is 58.33%.

@@             Coverage Diff              @@
##             master    #2409      +/-   ##
============================================
- Coverage     62.83%   62.80%   -0.03%
  Complexity       69       69
============================================
  Files           360      360
  Lines         17187    17196       +9
  Branches       2314     2314
============================================
+ Hits          10799    10800       +1
- Misses         5380     5385       +5
- Partials       1008     1011       +3

Impacted Files
Coverage Δ

...uubi/engine/trino/operation/ExecuteStatement.scala
71.73% <44.44%> (-6.64%)
:arrow_down:

...ugin/spark/authz/ranger/RangerSparkExtension.scala
100.00% <100.00%> (ø)

...engine/trino/operation/TrinoOperationManager.scala
86.36% <100.00%> (ø)

...cala/org/apache/kyuubi/ctl/ServiceControlCli.scala
77.57% <100.00%> (ø)

...rg/apache/kyuubi/engine/trino/TrinoStatement.scala
68.96% <0.00%> (-2.30%)
:arrow_down:

...ache/kyuubi/operation/KyuubiOperationManager.scala
94.44% <0.00%> (-1.86%)
:arrow_down:

.../kyuubi/credentials/HadoopCredentialsManager.scala
93.12% <0.00%> (-0.77%)
:arrow_down:

.../org/apache/kyuubi/operation/KyuubiOperation.scala
68.00% <0.00%> (+1.33%)
: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 62db92f...511af18. Read the comment docs.

- execute credentials renewal task and wait for completion *** FAILED ***
  The code passed to eventually never returned normally. Attempted 21 times over 1.1136331720000001 seconds. Last failure message: 0 did not equal 1. (HadoopCredentialsManagerSuite.scala:103)

CI fail seems nothing to do with this PR, or help retest plz.

thanks, merging to master


feat: add api for returning a valtio proxyState from a jotai atom derived from another atom value

withProxyEffect
withProxyEffect wraps a primitive atom’s value in a self-aware Valtio proxy. You can make changes to it in the same way you would to a normal js-object.
API Signature
function withProxyEffect<Value>(atomToSync: PrimitiveAtom<Value>, options?: Options<Value>): Atom<{ value: Value}>

Parameters

atomToSync (required): the primitive atom to sync.
options (optional): allows customization with sync for synchronous updates and proxyFn for custom proxy functions.

Example
Count value is stored under the value property.
const countAtom = atom(0)
const proxyCountAtom = withProxyEffect < Value > countAtom

function IncrementButton() {
  const proxyCount = useAtomValue(proxyCountAtom)
  return <button onClick={() => proxyCount.value++}>+</button>
}

Options
Options include sync for determining synchronous updates and proxyFn which can be proxy, proxySet, proxyMap, or a custom function.
type ProxyFn<Value> = (obj: { value: Value }) => ({ value: Value })

type Options<Value> = {
  sync: boolean
  proxyFn: ProxyFn<Value>
}

Thanks for opening up a PR.
API design questions:

atomWithProxyEffect(initialValue) would be easier to implement than withProxyEffect(atomToSync). Do you want to attach a capability to an existing atom? It makes a little bit complicated (too flexible), which is another concern.
Is it an effect? It sounds to me it allows "mutation". If something called withProxyEffect is possible, I think withEffect the same capability without proxy sounds possible. But, is there such a thing?

Overall, one of my questions is if this falls into the "impure" category of Jotai mental model.

atomWithProxyEffect(initialValue) would be easier to implement
It wouldn't be too much work to convert the code to (1). 😅
I like this idea too, it prevents developers from passing a writable atom to the utility that doesn't accept args of the form [Value].

I think withEffect the same capability without proxy sounds possible.
It might be possible, not sure. But I wouldn't be in favor of reverse engineering Valtio around atomEffect. The two are not similar. withProxyEffect must return a useable mutable proxy from first read.

my questions is if this falls into the "impure" category of Jotai mental model.
The utility does allow Valtio-like imperative mutations similar to $state returned by useProxy from valtio/utils.

When sync: true, the utility tries to perform these mutations synchronously.
That is...
get(countAtom) // 0
$count.value++
get(countAtom) // 1

sync: false updates with a delay of Promise.resolve().then.
I should note that sync:true is synchronous only after onMount has fired, so initial read is still treated the same as sync: false. But synchronous imperative updates on mount is an anti-pattern so this is not a case we should handle.
(i.e. the following use case should not be supported)
const countAtom = atom(0)
const proxyCountAtom = withProxyEffect(countAtom, { sync: true })

function SomeComponent() {
  const $count = useAtomValue(proxyCountAtom)
  $count.value++
  const count = useAtomValue(countAtom)
  expect(count).toBe(1) // it will be 0 because count is updated on next microtask
    ...
}

I think withEffect the same capability without proxy sounds possible.

I think I misunderstood something. Proxies are required for mutation. So, I think it's different from atom-effect's effectFn.
I would probably call it atomWithMutability or mutableAtom.

When sync: true, the utility tries to perform these mutations synchronously.

It feels to me that sync: true should be default and not configurable.

$count.value++

This should be prohibited anyway in render. It should follow Jotai's principle.

atomWithMutability or mutableAtom

😮 Oh I like those choices. I wasn't too fond of withProxyEffect, it was just a placeholder.

It feels to me that sync: true should be default and not configurable.

Yes, we should lock it to sync: true so that it behaves the same as synchronous updates in Jotai.

This should be prohibited anyway in render. It should follow Jotai's principle.

Agreed, but mutableAtom does allow for some strange patterns when used inside other atoms.
For instance, mutating in the read is possible which causes an infinite loop. I wish there was some way to prevent this.
const countProxy = mutableAtom(0);

const readOnlyAtom = atom(get => {
  const $count = get(countProxy)
  $count.value++ // infinite loop ⚠
});

I wish there was some way to prevent this.

I wish it too. For now, I think it should be clearly documented.

Requested changes complete.

rename withProxyEffect to mutableAtom
mutableAtom accepts a value, not an atom
test that mutableAtom can accept function as value
add warning to readme for infinite loop when proxy is mutated on atom read or component render
remove sync option and hard-code sync config to true

What should happen if proxyState were to be read / written to after the atom has unmounted?

do nothing?
throw?

I would generally avoid leaking general get and set to avoid misusing in our code.
Instead, I'd pass around store and proxyRef (unless combined) objects, and setValue function.
Functionality-wise, it should be the same, so basically just a suggestion for coding preference.

I refactored storeAtom.onMount. Does this resolve your concern?
createProxyState is used in:

proxyEffectBaseAtom read function (uses get and setSelf)
storeAtom write function (uses get and set)

I think it is better to centralize this logic, but let me know if you prefer I break this up.

What should happen if proxyState were to be read / written to after the atom has unmounted?

BTW, reading/writing atoms without mounting is totally valid operations.
import { createStore, atom } from 'jotai';

const store = createStore();
const countAtom = atom(0);
store.set(countAtom, 1);
console.log(store.get(countAtom));

This is true, even after mounting and unmounting.

Hm, actually this is interesting.
My gut feeling is we don't need to re-create proxyState. Just create once and subscribe on creation. We never unsubscribe.
I think it will clean things up and become less hacky.
(I might be missing something though...)

BTW, reading/writing atoms without mounting is totally valid operations.

it('should allow updating even when component has not mounted', async () => {
  const store = createStore()
  const countAtom = atom({ value: 0 })
  const mutableCountAtom = makeMutableAtom(countAtom)
  await act(async () => {
    const countProxy = store.get(mutableCountAtom)
    countProxy.value++
  })
  expect(store.get(countAtom).value).toBe(1) // true 😮
})```

Great suggestions!

My gut feeling is we don't need to re-create proxyState. Just create once and subscribe on creation. We never unsubscribe.

Done.

I would generally avoid leaking general get and set to avoid misusing in our code.
Instead, I'd pass around store and proxyRef (unless combined) objects, and setValue function.
Functionality-wise, it should be the same, so basically just a suggestion for coding preference.

Done.

Here you go: https://github.com/dmaskasky/jotai-valtio/pull/1

By the way, I would simply use expect. Is assert simply for a shorthand?

I mean the goal is to drop minimalistic-assert completely.
Please also resolve conflicts.

I mean the goal is to drop minimalistic-assert completely.

I chose minimalistic-assert because another package we are depending on already uses it. Plus it is a devDependency so it won't increase the bundle size. I'm happy to write the logic for this too as it is simply
function assert(value: boolean, message?: string) {
  if (!value) {
    throw new Error(message ?? 'Assertion failed')
  }
}

By the way, I would simply use expect. Is assert simply for a shorthand?

@testing-library has a strange behavior where it can run an expect that passes twice. This causes expect.assertions to fail.

https://github.com/testing-library has a strange behavior where waitFor can run an expect that passes twice. This causes expect.assertions to fail.

Hmm, curious how it fails.

I'm happy to write the logic for this too as it is simply

Yeah, that's much easier for me to read. Let's do that unless we find a solution to the above issue.

Hmm, curious how it fails.

It runs in a setTimeout loop, but an extra run can occur when expect is successful. The internet told me to use assert instead.

Yeah, that's much easier for me to read. Let's do that unless we find a solution to the above issue.

Done.

The diff looks weird. For example, it shouldn't show changes in .github.

The diff looks weird. For example, it shouldn't show changes in .github.

Hopefully this is resolved now.


Add some links to the implementation

Like this? #1090
https://github.com/deepmind/open_spiel/pull/1103 just made this easier.
Not completed yet, just added three links by hand.

Can you clarify the motivation?
The games are all in the same place, under games/ or python/games. So they are not too hard to find. We could just could have maybe 1-2 links to the parent folders at  the top than rather than have links for all the games?

Oh sorry. The motivation was basically this quote from you in another issue: https://github.com/deepmind/open_spiel/issues/1090#issuecomment-1615998452

I like the idea of linking to the section of the C++ header from the games page. Can you submit a PR?

However, linking to just the parent folder is also a viable option now. (Also less docs maintenance if the code should ever move)

Closing due to inactivity. Please re-open if you continue working on this.


H5 not working

Hi,
Love CocaMD but I'd love to see ##### and ###### support. If you could tell me how to implement it I'd greatly appreciate it !

This was happening because cparts requires a space between the pound sign and the title


Error occurs when using as standalone editor

Attempted to use the compute.toy as a standalone editor by following the steps described in the README file, which involved deleting the pages directory before starting the server. Unfortunately, this approach did not work.
I then tried to resolve the issue by clearing the cache, which involved deleting the .next directory. However, even after doing this, I consistently encountered the following error:
Server Error
Error: useAuth must be used within an AuthProvider

This error happened while generating the page. Any console logs will be displayed in the terminal window.

Source
lib\db\serializeshader.ts (128:28) @ useShaderSerDe

  126 |     const atomGetter = useAtomGetter();
  127 |
> 128 |     const { user } = useAuth();
      |                            ^
  129 |
  130 |     /*
  131 |         We DO NOT want to use getters here, even though

Call Stack
MetadataEditor
components\editor\metadataeditor.tsx (53:43)

Could you please provide guidance on how to resolve this issue?

@mikeny07 don't remove pages at all.
If you want support without connection to db make PR, should be easy to fix because it worked month ago.

The problem is that this condition evaluates to true now, which makes it attempt to connect to the database. It should be disabled somehow for the standalone editor
https://github.com/compute-toys/compute.toys/blob/master/components/editor/editor.tsx#L76


[Feature]: Linting by default

What area(s) will this request affect?
App
What type of change do you want to see?
New feature
Overview
Since Shopify is attempting to provide a batteries included scaffolding solution - the lack of linting seems like a miss.  In addition, with the new folder structure - linting and multiple linting configs creates a multi hour setup process.
Motivation
Shopify seems to think developers want more abstraction. While Jr devs may want this - this causes increased confusion for devs that want to know what the heck is going on. That said - if you are going to try to abstract away everything, considering adding a linting process built in so devs don't need to add additional time configuring eslint

Hi @ChaseWNorton -- to better understand this one, can I check a couple of assumptions:

you've got an app with both web and extensions
these share a common language, i.e. all written in JS, and hence common tooling
you'd like to more easily run eslint across all the elements of your app in one go, instead of per-extension + web separately

And then as an aside for more background -- how were you managing your app prior to CLI3.0? Separate repos/workspaces/something else?


state: initial version for the consul state store implementation

Description
This is an initial version of HashiCorp Consul state store implementation.
Issue reference
The PR closes: #5
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[ ] Extended the documentation

Once this PR is merged, we can review: https://github.com/dapr/dapr/pull/686

@yaron2 that's a lot of folks on review. 😄 Do you think this will be reviewed soon?

@yaron2 that's a lot of folks on review. 😄 Do you think this will be reviewed soon?

Today!

One last thing: update the vendor dir with go mod vendor

@yaron2 we should be good to go! Thank you so much for a swift and awesome review.

@yaron2 we should be good to go! Thank you so much for a swift and awesome review.

Almost there.. :)

LGTM

This PR closed #51


update beaker

@pfrazee @taravancil we're working on new app pages. Using Beaker as a test subject. :)

sweet!


nixos/rpcbind: Add dependency for systemd-tmpfiles-setup

Description of changes
The inline comments explain the reasoning behind this change. This work was initiated due to failing tests explicitly for glusterfs, but my hunch is that any nixosTest adjacent to rpcbind will start working again (hopefully?). /cc @7c6f434c as we've been debugging this one.
I'm not a "deep" maintainer of NixOS plumbing, but rpcbind feels like a pretty fundamental service, so I'm hoping that someone with some authority/context here can affirm I'm not breaking any assumptions.

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1580

@tylerjl know of any good reason this shouldn't be backported to nixos-22.11?

I can't think of any caveats; it should strictly improve things so I don't see any reason it shouldn't be backported.

@tylerjl cool, mind adding the tag to this PR?  I don't have permissions to do so.


Fix login with cookie for Chrome users

#361

my god, hold on, we got an error when using a cookie file was made manually with only access_token and client_id

phew~ 😅, ver 2 is up. Working with 3 types of cookie now (Firefox, Chrome and Handmade)

@brundidge thanks for the quick fix but i don't think this fix is quite good i will add a fix for cURL request cookie extraction soon. i 'm closing this merge request.


Traversal Query unpredictable

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[ ] 2.8
[ ] 3.0
[x] 3.1
[ ] 3.2
[ ] self-compiled devel branch

On this operating system:

[ ] DCOS on

[ ] AWS
[ ] Azure
[ ] own infrastructure

[ ] Linux

[ ] Debian .deb
[ ] Ubuntu .deb
[ ] SUSE   .rpm
[ ] RedHat .rpm
[ ] Fedora .rpm
[ ] Gentoo
[x] docker - official docker library
[ ] other:

[ ] Windows, version:
[ ] MacOS, version:

this is an AQL-related issue:
[x] I'm using graph features
I've run db._explain("<my aql query>") and it didn't shed more light on this.
The AQL query in question is:
Hello,
I have a problem with traversal queries.
I execute traversal with options {"uniqueEdges": "path"} and this return all result but with timing very slow about 25 s.
then i change options in {"uniqueEdges": "global"} but the response is:
"Query: uniqueEdges: 'global' is not supported, due to unpredictable results. Use 'path' or 'none' instead (while instantiating plan)".

Can you share the exact query you are executing?
How many results are returned for the query with {"uniqueEdges":"path"}?

This is a bug in the documentation, the {"uniqueEdges": "global} option is currently unsupported, we may look into adding it back in again.

Sorry I just skimmed over the text, regarding the other issue:
How many paths are returned? Do you have  FILTERstatements on all edges or vertices ?

@MPanicucci can you provide a small example data set demonstrating your issue?

Hi @MPanicucci,
closing this issue for now because we have not received any feedback for a few months. Please reopen if this issue persists with current versions and provide a small data set.
Thanks