Crash on iPad Air 2

⚠ Issues not using this template will be systematically closed.
Describe the bug
crash on ipad air2, and happens always.
Is there anyone have solutions?
thanks
Logs
          Crashed: FEngine::loop
0  libsystem_kernel.dylib         0x6bbc __pthread_kill + 8
1  libsystem_pthread.dylib        0xd844 pthread_kill + 208
2  libsystem_c.dylib              0x1f6ac abort + 124
3  SoundCore                      0x3e59964 utils::PostconditionPanic::PostconditionPanic(char const*, char const*, int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>) + 136
4  SoundCore                      0x3d528bc filament::backend::DepthStateCreator::operator()(id<MTLDevice>, filament::backend::DepthStencilState const&) +<PHONE_NUMBER>
5  SoundCore                      0x3d3c60c filament::backend::StateCache<filament::backend::MetalPipelineState, id<MTLRenderPipelineState> __strong, filament::backend::PipelineStateCreator, utils::hash::MurmurHashFn<filament::backend::MetalPipelineState>>::getOrCreateState(filament::backend::MetalPipelineState const&) +<PHONE_NUMBER>
6  SoundCore                      0x3d461b4 filament::backend::ConcreteDispatcher<filament::backend::MetalDriver>::draw(filament::backend::Driver&, filament::backend::CommandBase*, long*) +<PHONE_NUMBER>
7  SoundCore                      0x3d22708 std::__1::__function::__func<filament::backend::CommandStream::execute(void*)::$_0, std::__1::allocator<filament::backend::CommandStream::execute(void*)::$_0>, void ()>::operator()() +<PHONE_NUMBER>
8  SoundCore                      0x3d476a4 filament::backend::MetalDriver::execute(std::__1::function<void ()> const&) +<PHONE_NUMBER>
9  SoundCore                      0x3d22470 filament::backend::CommandStream::execute(void*) +<PHONE_NUMBER>
10 SoundCore                      0x3ded048 filament::FEngine::loop() + 166240

Smartphone (please complete the following information):

Device: ipad air 2
Backend: Metal

Additional context
Add any other context about the problem here.

There should be a postcondition reason printed in the logs. Can you check again and see if there's additional information about the crash?

thans  you for  response
When I use Xcode debug, I get the following crash message
2024-07-10 13:11:27.489492+0800 SoundCore[402:15649] [BLEPeripheral:137-notifyCharacteristicChange(_:)]🐛 notifyCharacteristicChange: <CBCharacteristic: 0x128dbe8f0, UUID = 8888, properties = 0x92, value = <09ff0000 010e070a 0028>, notifying = YES>, value: Optional(10 bytes)
Warning: sample comparison not supported by this GPU
2024-07-10 13:11:30.547020+0800 SoundCore[402:15649] [BoringSSL] nw_protocol_boringssl_get_output_frames(1301) [C18.1:2][0x13bf3d0a0] get output frames failed, state 8196
2024-07-10 13:11:30.548916+0800 SoundCore[402:15649] [BoringSSL] nw_protocol_boringssl_get_output_frames(1301) [C18.1:2][0x13bf3d0a0] get output frames failed, state 8196
2024-07-10 13:11:30.551812+0800 SoundCore[402:15649] TIC Read Status [18:0x0]: 1:57
2024-07-10 13:11:30.552141+0800 SoundCore[402:15649] TIC Read Status [18:0x0]: 1:57
2024-07-10 13:11:31.045106+0800 SoundCore[402:15709] Compiler failed to build request
Could not statically determine the target of a texture
Panic
in operator():97
reason: Could not create Metal pipeline state.
#0	SoundCore                              0x1039a7a7c _ZN5utils6TPanicINS_18PostconditionPanicEEC2EPKcS4_iNSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEE + 100
#1	SoundCore                              0x1039a77dc _ZN5utils18PostconditionPanicCI1NS_6TPanicIS0_EEEPKcS3_iNSt3__112basic_stringIcNS4_11char_traitsIcEENS4_9allocatorIcEEEE + 12
#2	SoundCore                              0x1039a77bc _ZN5utils6TPanicINS_18PostconditionPanicEE5panicEPKcS4_iS4_z + 116
#3	SoundCore                              0x10387fddc _ZN8filament7backend17DepthStateCreatorclEPU19objcproto9MTLDevice11objc_objectRKNS0_17DepthStencilStateE + 0
#4	SoundCore                              0x103869b2c _ZN8filament7backend10StateCacheINS0_18MetalPipelineStateEU8__strongPU33objcproto22MTLRenderPipelineState11objc_objectNS0_20PipelineStateCreatorEN5utils4hash12MurmurHashFnIS2_EEE16getOrCreateStateERKS2_ + 364
#5	SoundCore                              0x1038736d4 _ZN8filament7backend18ConcreteDispatcherINS0_11MetalDriverEE4drawERNS0_6DriverEPNS0_11CommandBaseEPl + 1164
#6	SoundCore                              0x10384fbac _ZNSt3__110__function6__funcIZN8filament7backend13CommandStream7executeEPvE3$_0NS_9allocatorIS6_EEFvvEEclEv + 52
#7	SoundCore                              0x103874bc4 _ZN8filament7backend11MetalDriver7executeERKNSt3__18functionIFvvEEE + 44
#8	SoundCore                              0x10384f914 _ZN8filament7backend13CommandStream7executeEPv + 96
#9	SoundCore                              0x103925f40 _ZN8filament7FEngine4loopEv + 448
#10	SoundCore                              0x103929790 _ZNSt3__114__thread_proxyB7v160006INS_5tupleIJNS_10unique_ptrINS_15__thread_structENS_14default_deleteIS3_EEEEMN8filament7FEngineEFivEPS8_EEEEEPvSD_ + 64
#11	libsystem_pthread.dylib                0x1fe2302c0 <redacted> + 128
#12	libsystem_pthread.dylib                0x1fe230220 _pthread_start + 44

There should be a postcondition reason printed in the logs. Can you check again and see if there's additional information about the crash?

I repeated the question, please see the log I replied above， thanks ！！

We previously worked around an error like this, I wonder why this is no longer working:
https://github.com/google/filament/blob/3728f0660395d04d5735d85831a43480501f1c63/shaders/src/light_indirect.fs#L75-L78
@xiamingwei-sudo are you able to investigate what the GPU's device.name is? Maybe this check isn't sufficient:
https://github.com/google/filament/blob/3728f0660395d04d5735d85831a43480501f1c63/filament/backend/src/metal/MetalDriver.mm#L165-L166

thanks for you respons, and my ipad GPU info :

thanks for you respons, and my ipad GPU info :
FEngine (64 bits) created at 0x120a1d800 (threading is enabled)
FEngine resolved backend: Metal
Selected physical device 'Apple A7 GPU'
Backend feature level: 2
FEngine feature level: 1

how can i solve this issue?

We previously worked around an error like this, I wonder why this is no longer working:
https://github.com/google/filament/blob/3728f0660395d04d5735d85831a43480501f1c63/shaders/src/light_indirect.fs#L75-L78
@xiamingwei-sudo are you able to investigate what the GPU's device.name is? Maybe this check isn't sufficient:
https://github.com/google/filament/blob/3728f0660395d04d5735d85831a43480501f1c63/filament/backend/src/metal/MetalDriver.mm#L165-L166

We previously worked around an error like this, I wonder why this is no longer working:
https://github.com/google/filament/blob/3728f0660395d04d5735d85831a43480501f1c63/shaders/src/light_indirect.fs#L75-L78
@xiamingwei-sudo are you able to investigate what the GPU's device.name is? Maybe this check isn't sufficient:
https://github.com/google/filament/blob/3728f0660395d04d5735d85831a43480501f1c63/filament/backend/src/metal/MetalDriver.mm#L165-L166

thanks for you respons, and my ipad GPU info :
FEngine (64 bits) created at 0x120a1d800 (threading is enabled)
FEngine resolved backend: Metal
Selected physical device 'Apple A7 GPU'
Backend feature level: 2
FEngine feature level: 1

so how can i fix this issue? can you give me some suggestion .

Perhaps we also need to extend that fix to Apple A7 GPUs. @xiamingwei-sudo can you change that check inside MetalDriver.mm to this and then recompile Filament?
    mContext->bugs.a8xStaticTextureTargetError =
            [mContext->device.name containsString:@"Apple A8X GPU"] ||
            [mContext->device.name containsString:@"Apple A7 GPU"];

Perhaps we also need to extend that fix to Apple A7 GPUs. @xiamingwei-sudo can you change that check inside MetalDriver.mm to this and then recompile Filament?
    mContext->bugs.a8xStaticTextureTargetError =
            [mContext->device.name containsString:@"Apple A8X GPU"] ||
            [mContext->device.name containsString:@"Apple A7 GPU"];

Thank you very much for your reply, no more crashes after adding Apple A7 GPUs and recompiling Filament，
but we got crash on Ipad Air2/ Ipad mini 4 & iphone 6 & 6 plus too, i think that is the same problem,
Thanks again for your response！！
and look forward to seeing the issue fixed in the  release Version


implement vector element for cxx wstring

While trying to port input mappings, need to return list of string, but I saw VectorElement was not implmented for it.
Not sure if this is fine to implement or not

I implemented this separately in 00536f3b771c9741bc325b37e7627d52052240a3 and updated the cxx dependency in https://github.com/fish-shell/fish-shell/commit/d728b884ddd16312f4ec53b7670c257584d38135.

FYI Though VectorElement is (correctly, I think?) implemented for CxxWString and autocxx now accepts Vector in a signature, it converts it for some reason to CxxVector<std_basic_string_wchar_t_AutocxxConcrete> so I had to transmute that to CxxVector<CxxWString>.


Convert time column in PlainFieldExtractor

is this diff from master? looks like diff from the previous PR. Can you confirm. This is looking better.

Yes, this is one commit ahead master.

LGTM. Minor comments.

Merged.


OD 2.0 unintentionally ambiguous about whether GPL would be open if considered

OD 2.1 should remove this ambiguity. Brought up at https://lists.okfn.org/pipermail/okfn-discuss/2014-October/010652.html

I'm quite sure the latest draft https://github.com/okfn/opendefinition/blob/master/source/open-definition-2.1-dev.markdown covers this fully and we can close this ticket.

You're right about the ambiguity being removed wrt GPL, but the latest draft language seems impossible to understand without looking up 'corresponding source' and reading its definition in the GPL (or being someone who has already done so many times):
"The license may require for any distribution of the work that corresponding source files be made available in the preferred form for modification."
I don't have a fix in mind, just noting that it isn't ideal at the moment.

I actually do not agree that 'corresponding source' is inadequate. I understand it is confusing in that it is a broad and slightly complex issue. There are various ways to figure this out. It's not GPL-specific language though. It would apply to something like hardware in that it would require the blueprints or something like that to be made available (although I'm not sure the OD applies to hardware in all respects).
If we really want more clarity here, something like:
"The license may require that any distribution of the work include or provide ready means of access to any corresponding source material in the preferred form for modification. Source refers to human-readable source code for executable computer programs, raw data used in the generation of charts or statistics, or other such material necessary for adapting the work."
That's a rough first try. I actually think it may be better to not try to be totally precise here. All we're doing is providing a qualification for licenses, and in this case, broader is probably better, but I worry about onerous issues. We don't want a license that says, "you can only distribute this along with a complete version of a particular operating system on which this runs…" or anything like that…
I dunno, I think we're already improved enough over 2.0 that we should just use the 2.1 draft in this case and consider it better and not fret about imperfection.

My complaint is not that the language is theoretically GPL-specific in application, rather it requires reading the GPL to understand.
One of the goals with 2.0 was to make it possible to understand without embedded explanatory comments and without having background knowledge about the OSD and its predecessors. I think 2.0 met that goal pretty well. I view this wording as a bit of a regression on that front, though the terminology of the GPL is the background knowledge required.
Embedding a definition of source doesn't help, as "corresponding" is the word that one needs to know the GPL to understand what is really meant.
But I don't have a bright idea for how to rewrite, so I'm going to close anyway. Anyone should feel free to reopen if they do have such an idea.

I didn't write "corresponding" in reference to GPL, fwiw. I just wrote it as a seemingly straightforward English word.
But I didn't understand the concern originally. I understand your point better now.
I think we could indeed go back toward the simpler 2.0 wording but still fix the issue at hand:
"The license may require that anyone distributing the work provide recipients with access to the preferred form for making modifications."
I'm tempted to add "…the work (whether modified or not)" or "…distributing any version of the work…" but don't like excessive words in that case.
Anyway, I now very much like my more generalized update here in this post and suggest we switch to that instead of my earlier GPL-sounding "corresponding" wording.

I misunderstood the role of "corresponding" perhaps. I thought you added it in order to clarify that the GPL's partiuclar requirement is OK wrt the OD. I agree that is not necessary as clearly what the GPL requires is just clarifying what the preferred form for making modifications actually entails, not a different requirement that needs an additional carve out in the OD.
So I like your more generalized update. Pull request?


Enhances entra m365group get with additional properties

Added additional properties to entra m365group get command.
Closes #6148

Thank you, we'll try to review it ASAP!

Ready to merge 🚀

Merged manually. Thank you for your awesome work! You Rock !🤩


Indian Districts for COVID19

Import for Indian Districts and States from covid19india.org.
Each state has its own API.
Place names are resolved by wikidataId.

Ready for re-review!

Added 3 unit tests, instead of API calls, it reads JSON from the file.
Minor modifications to code to allow testing.
Modifications to README.md.
I no longer use the State name, only State isoCode and district name.

Ready for re-review!

I added the script that checks against wikidata to ensure that the wikidataIds are correct, contains README.md
Removed default parameters.
Tests will use StringIO.
Minor changes to code and documentation.

Thanks


Make zebra-state compile successfully by itself

Motivation
The zebra-state integration test compiles successfully during workspace builds.
But it couldn't find the init_test function when the crate was built by itself.
This happens because the function is only active for test and proptest-impl builds.
Solution

remove the dependency on the init_test function

This is a workaround for bug #1364, but it doesn't close that ticket.
Review
Anyone can review this PR.
It's not urgent, because we don't do this check in CI.
Reviewer Checklist

[ ] zebra-state compiles by itself
[ ] Existing tests pass

Follow Up Work
Add a CI job which compiles each Zebra crate individually #1364

This change is

Add a CI job which compiles each Zebra crate individually #1364

I think once upon a time we had this but yeah we should bring it back in parallel

Add a CI job which compiles each Zebra crate individually #1364

I think once upon a time we had this but yeah we should bring it back in parallel

We only have one for zebra-chain right now


How to search in this working directory only

how to ovvereide this plugin to find file only for this working directory?
extensions = {
       frecency = {
          db_root = "~/dotfiles/telescope-frency",
          show_scores = true,
          show_unindexed = true,
          ignore_patterns = {
            "*.git/*",
            "*/tmp/*",
            "*/lua-language-server/*",
          },
          disable_devicons = false,
          },
      }

It's on the docs:
extensions = {
       frecency = {
          default_workspace='CWD'
          db_root = "~/dotfiles/telescope-frency",
          show_scores = true,
          show_unindexed = true,
          ignore_patterns = {
            "*.git/*",
            "*/tmp/*",
            "*/lua-language-server/*",
          },
          disable_devicons = false,
          },
      }

Specifically this (and don't forget the comma)
default_workspace='CWD',


Transform/translate property with old tailwind (1.9.6)

What version of prettier-plugin-tailwindcss are you using?
v0.1.10
What version of Tailwind CSS are you using?
v1.9.6
What version of Node.js are you using?
v17.9.0
What package manager are you using?
Yarn
What operating system are you using?
macOS
Describe your issue
Our team is using the old version of tailwind 1.9.6.
I ran into a problem that in the old version the translate property declaration should be paired with transform, but the sort plugin doesn't take this into account and overwrites the property. Is there a way to fix this? Thank you!

Hey! As mentioned in the readme, the Prettier plugin is only compatible with v3 and up. It’s “working” in v1 because installing the Prettier plugin will install v3 as a dependency but you’ll get problems like you’re seeing because apply behaved differently in v1 so it’s not safe to sort those classes.
Nothing we can really do here I’m afraid as we have no plans to support older versions. Would encourage you to upgrade your project instead 👍🏻

To anyone having this issue, here's how I solved it:
Separate the transform onto a line before any other modifiers, like this:


foreman service models for automate

Adding the service models for foreman
/cc @gmcculloug

One missing association otherwise this looks good.

Thanks @gmcculloug - good eye


Bug: Trackpad gestures are disabled

Environment
Host

item
version

OS
Amazon Linux 2

GROWI
4.5.15

node.js
14.19.0

npm
6.14.16

Using Docker
yes

Using [growi-docker-compose][growi-docker-compose]
yes

Client

item
version

OS
macOS Catalina

browser
Chrome 98.0.4758.109（Official Build） （x86_64）

How to reproduce? (再現手順)

Swipe the trackpad with two fingers left or right

What happens? (症状)

Nothing happens

What is the expected result? (期待される動作)

Goes back to the previous page if swiped left
Goes forward to the next page if swiped right

Note

This is because of overscroll-behavior-x: none in CSS
Is this intended behavior? If so, is there a way to enable trackpad gestures?

I've ended up with setting custom CSS.
body {
  overscroll-behavior: auto;
}

This issue was fixed in GROWI version 5.x. Please wait until we to fix it in version 4.5.15 as well.


The units in AngularSpectrumSolver

Dear Farhadnkm,
What are the units used in AngularSpectrumSolver? I see you have used the wavenumber

k=2 * np.pi/500e-3

the pixel size

dr=1

and the axial coordinate

z=-1000

in the example https://github.com/farhadnkm/Fringe.Py/blob/master/examples/diffraction.ipynb. I think the units would be μm,  am I right?
Thank you for your support!

That's correct.
But you can use any value/unit for these parameters.


System fails if the main laravel app does not implement the PhpEngine renderer.

See topic.
$ php artisan ide-helper:meta

  [InvalidArgumentException]
  View [meta] not found.

Issued PR #475 that fixed the issue locally, it's hastily put together, but I think it's overall an improvement.

@barryvdh above PR was merged, issue can be closed :}


use seperate gorouinte to run blocking method: http1/http2 stream.doS…

…end, which would  cause dead-lock if there were more than 1 listener working.; use global counter to generate http streamId

Codecov Report

Merging #137 into master will increase coverage by 0.02%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #137      +/-   ##
==========================================
+ Coverage   21.44%   21.46%   +0.02%
==========================================
  Files          41       41
  Lines        3624     3620       -4
==========================================
  Hits          777      777
+ Misses       2809     2805       -4
  Partials       38       38

Impacted Files
Coverage Δ

pkg/config/parser.go
2.62% <0%> (ø)
:arrow_up:

pkg/upstream/cluster/clustermanager.go
0% <0%> (ø)
:arrow_up:

pkg/config/callback.go
0% <0%> (ø)
:arrow_up:

pkg/upstream/cluster/clusteradapter.go
0% <0%> (ø)
:arrow_up:

pkg/network/buffer/slabbufferpool.go
0% <0%> (ø)
: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 51505a0...e902c36. Read the comment docs.


Mid Sprint Update 2019-02-11

What Was Investigated?
How do we enforce AMP's UX no-content-jumping invariant in amp-script?
Option A
If page receives mutation > X seconds after a gesture, terminate worker. Network responses triggered during gesture window will extend it, max 1 extension (e.g. to support amp-list use cases).

Provides a clear performance budget for publishers.
Early termination is a clear signal for application developers, allowing more clear resolution to issues.
Prevents a cascade of updates when a gesture allows for mutation.
Avoids troubling DOM scenarios when the main thread and the worker thread have a different source of truth regarding structure. (ie Element.classList.add('a') is outside the mutation window how would the worker get a signal that the mutation was denied? The DOM APIs do not support negation or rollback semantics)

Option B
If page receives mutation > X seconds after a gesture, store it in a queue. Dequeue on next user gesture. "Curtain" amp-script if queue gets old, terminate worker if queue gets too large.

Far more forgiving for accidental changes outside mutation window.
Simpler mental modal for document developers, a mutation requested will quite likely be made.
Device performance isn't a factor in success of applying mutation.
Allows for "pause and resume" semantics similar to light ads UX.

Statically Sized amp-script Elements
Should we disable gesture constraint if amp-script is statically sized (similar to amp-iframe)?

I like the idea of Option B.
User using AMP Document
Personally, I would rather have a page not jump, then jump after I've already given up on the action. There have been plenty of times when I realize, "welp, I guess thats broken", or I'll try to do something right before the jump, and then all of a sudden, it literally jumps under my finger. I think queuing them up will make the page feel broken / unresponsive, but not laggy and lead to mis-clicks.
I guess I'm in the UX perspective of, I'd rather it respond, or not respond at all.
Publisher
I think this is much easier to understand, then to try to wrestle with this fetch request model of how much time you have to respond and things like that. Also, I feel like there is less room for abuse than option A. As the developer could just send of analytics pings on every gesture from within the worker to extend every single gesture if they would like. And for the idea of: "* Early termination is a clear signal for application developers, allowing more clear resolution to issues.", this could also be done with an error in the console for option B.
AMP Developers
I feel like keeping track of the this timeout and monitoring what amp-script is doing is going to slow down the page (at least a little bit), and will be much harder to do / properly maintain. Also, I think a mutation queue is a good idea in general, the case of something rapidly mutating (like a game or animation), we can offer options in the future to drop mutations if another comes in.

I guess I'm in the UX perspective of, I'd rather it respond, or not respond at all.

I'm confused if this means you'd prefer future interactions to change more about the DOM in an amp-script or terminate the worker.

"Early termination is a clear signal for application developers, allowing more clear resolution to issues.", this could also be done with an error in the console for option B.

A console error is pretty easy to miss unfortunately given the stream of errors in production documents. However, perhaps in development mode the Worker could terminate when exceeding the threshold... this might give some of the intended value.

I feel like keeping track of the this timeout and monitoring what amp-script is doing is going to slow down the page (at least a little bit), and will be much harder to do / properly maintain.

The idea here is to mutate the prototype for fetch and xhr attaching additional data that is detectable by the mutation lifecycle in WorkerDOM. It's possible it will add some complexity, but I believe this approach should work without impacting performance significantly.

Also, I think a mutation queue is a good idea in general, the case of something rapidly mutating (like a game or animation), we can offer options in the future to drop mutations if another comes in.

I'd really like to avoid deduping mutations in runtime. This complexity would increase time for applying mutations and cause the code to be more complex to build and maintain.

Another idea is to restructure this constraint around this idea:

Should we disable gesture constraint if amp-script is statically sized (similar to amp-iframe)?

Always allow mutations from worker-dom but constrain resizing of amp-script. I.e. don't support layout=container and only supported fixed layout size, but automatically trigger resizes for amp-script after every mutation until X seconds after a user gesture.

Aside: Should we migrate this to ampproject organization? Either use an existing WG or create wg-performance. /cc @mrjoro

We have an outstanding request to the TSC to move this repo over to @ampproject under a new WG (wg-performance). See https://github.com/ampproject/meta/pull/23.

@dvoytenko - for consideration in the implementation you're working on taking over.


Update Composer dependencies (2022-07-30-00-07)

Visual regression test passed!
View the visual regression test report


bumps eks-d releases

Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/cherrypick release-0.16


File upload

@gintaresaali Because of HUGE differences between main- and this branch I had to merge in indirectly and I hope you are ok with this.
I created new branch 'mergeUploadAvatar' and added your code to it, everything works just fine. user can upload avatar during profile creation and can update it later. only thing I'am not sure of is the asset files, lets' get back to this tomorrow.  Amazing job!   and yes I could not leave the computer 😄
PS. The only issue I can see is for some weird reason profile image size on profileView can't be changed.


typdef Buffer in the header makes forward declaration fail.

I notice that some type like Buffer is a typedef in h. This makes forward declearation in other header files not possible (https://stackoverflow.com/questions/18501993/struct-forward-declaration-error-typedef-redefinition-with-different-types).
Is that a special feature in tiny_gltf to avoid user directly define functions to use these types? Or should we just makes all typedef to struct?
Thank you.

I see. Simply I was just lazy for definitions.
Now its good time to make definitions well-organized(i.e. use struct Buffer)

No problem just to double check. On my side I can always use gltfModel as parameter and by pass the forward declaration of buffer for now.

Rewrite struct definition in this commit: https://github.com/syoyo/tinygltf/commit/2d17a31d3bf507c1005af5cd26f39bde79f2dad3
I think this should fit to your usage.


Extra blank line when extracting a P7M file

Hello! I'm on Windows and I use openssl.exe for extracting some text files from a .p7m file.
With openssl 1.0.2s it works nice.
With openssl 1.1.1g, I discovered an extra blank line within my textfile.
I'm using the openssl.exe shipped with apache from apachelounge.
I use the same command for both the openssl.exe executables.
```
c:\Program Files\Apache\bin\openssl.exe" smime -verify -noverify -in PATH-TO-FILE\myfile.p7m -inform DER -out PATH-TO-FILE\myfile.txt

```

Is it a bug or something new with 1.1.1g?Or something within the config file?

Has this been resolved yet?

Marking as inactive, to be closed at the end of 3.4  dev, barring further input


State to county FIPS code map

we need the ability to know what county fip codes are associated with a state code for all states in the NSI.
please use the census' table from 2017
https://www2.census.gov/programs-surveys/popest/geographies/2017/all-geocodes-v2017.xlsx
We want to use the state fip code from column b as the key in a map, the values will be a slice of 5 character county fips. To create a county fips use the state fips codde as the first two characters, and the county fips as the third through fifth charaters
There is an entry in the table for the entire us with a fipcode of 00, ignore it.
For each state there is an entry for the state fip with a county of 000, ignore those lines also.
m := make(map[string][]string)
m["01"] = {01001,01003,...}
m["02"] = {...}

this code will get input into a package - i will create the package and the basic function entry point and link it to this issue

please add the information here.
https://github.com/USACE/go-consequences/blob/master/census/fips.go

this was completed a few weeks ago.


Scheduler tries to re-create failed job with same job ID

Scheduler calls AddJob against host.
AddJob takes longer than the scheduler timeout, and the job ends up being created
The scheduler, thinking the job create failed, tries to place the exact same job with the same ID on the same host. This fails, but the scheduler keeps on trying.

When a AddJob call fails, a new job ID should be generated and we should probably re-run the placement logic. Also, we should confirm that flynn-host does not allow creation of a job with an existing ID.

This shouldn't happen in practice, much since #2503, however it should be fixed.

@titanous

AddJob takes longer than the scheduler timeout, and the job ends up being created

I assume we are talking about the 5s HTTP request timeout?

The scheduler, thinking the job create failed, tries to place the exact same job with the same ID on the same host. This fails, but the scheduler keeps on trying.

In what way does it fail? Ideally it would be a 409 Conflict that the scheduler can catch to indicate the job already exists and stops retrying.

When a AddJob call fails, a new job ID should be generated

This does make things a little more involved for the scheduler, there are quite a few code paths which assume a job's ID is immutable (well, the UUID part).

and we should probably re-run the placement logic

This is currently the case (see this loop), however most of the time it just picks the same host again.

I assume we are talking about the 5s HTTP request timeout?

Yes.

In what way does it fail? Ideally it would be a 409 Conflict that the scheduler can catch to indicate the job already exists and stops retrying.

Not certain, I wrote this issue based on notes from a few days ago. We should be able to replicate by adding a >5s delay to the AddJob HTTP request handler.


Optimizers memory usage

There's been few comments about memory consumption in the R-package. With large models, the memory footprint can rapidly burst the available memory unless a manual gc() is added in the training loop.
The problematic appears to be the weights update performed by the optimizers: https://github.com/apache/incubator-mxnet/blob/master/R-package/R/model.R#L221
Memory behaves as if the temporary nd.arrays were kept in memory.
Looked at how the python optimizers were designed and took a first attempt at using the mx.nd.sgd.update type of operators.
It seemed to help, but looking at https://github.com/apache/incubator-mxnet/blob/master/python/mxnet/optimizer.py#L434, I confused at how the state of optimizers such as momentum or adam and cie is updated. I can't see where the staste is updated other than for the initialization.
Also, tried to do a direct mutation of the weight using the out parameters of the mx.nd.sgd.update to point to the executor ref.arg.arrays, but it got the following message after a first update:
 Error in mx.nd.sgd.update(weight = weight, out = out, grad = grad, lr = learning.rate,  :
  ./ndarray.h:87: RCheck failed: ptr_->writable && !ptr_->moved Passing a read only NDArray to mutate function

I'm still missing some pieces to figure out a proper way of fixing the memory consumtion of the optimizers. Any help would be much welcome!
@thirdwing

@sandeep-krishnamurthy : Could you please tag this as "question", "R"
@jeremiedb : You could also post this on "discuss.mxnet.io". You would get a wider audience.

As an additional pointer, the issue seems tied to R's NDArray being set to read only after an initial mutation. https://github.com/apache/incubator-mxnet/blob/master/R-package/src/ndarray.h#L86 @tqchen ?
Basic comparative example between R and Python:
R:
> state <- mx.nd.array(c(1,2,3,3))
> grad <- mx.nd.array(1:4)
> weight <- mx.nd.array(1:4)
> mx.nd.sgd.mom.update(weight, grad, state, lr = 0.1, momentum = 0.5, out = weight)
[1] 1.4 2.8 4.2 5.1
> mx.nd.sgd.mom.update(weight, grad, state, lr = 0.1, momentum = 0.5, out = weight)
Error in mx.nd.sgd.mom.update(weight, grad, state, lr = 0.1, momentum = 0.5,  :
  ./ndarray.h:87: RCheck failed: ptr_->writable && !ptr_->moved Passing a read only NDArray to mutate function

Python:
state  = mx.nd.array([1, 2, 3, 3])
grad  = mx.nd.array([1,2,3,4])
weight = mx.nd.array([1,2,3,4])
print(nd.sgd_mom_update(weight, grad, state, momentum = 0.5, lr=0.1, out=weight))
print(nd.sgd_mom_update(weight, grad, state, momentum = 0.5, lr=0.1, out=weight))

[1.4 2.8 4.2 5.1]
<NDArray 4 @cpu(0)>

[1.5  3.   4.5  5.25]
<NDArray 4 @cpu(0)>

closing issue as the referenced PR seems to be resolving it, feel free to open a new issue if you still find problems.


[Bug]: Some download links are down for v5.8.1

Checks before filing an issue

[X] This issue doesn't reproduce on web browsers (such as in Chrome). If it does, issue reports go to the Mattermost Server repository.
[X] I have checked the issue tracker and have not found an issue that matches the one I'm filing.
[X] This issue is not a troubleshooting question. Troubleshooting questions go here: https://forum.mattermost.com/c/trouble-shoot/16.
[X] This issue is not a feature request. You can request features and make product suggestions here: https://mattermost.com/suggestions/.
[X] This issue reproduces on the most recent stable version, or the most recent prerelease version of the Mattermost Desktop App.
[X] I have read the contribution guidelines.

Mattermost Desktop Version
5.8.1
Operating System
Windows 10 x64
Mattermost Server Version
No response
Steps to reproduce
N/A
Expected behavior
N/A
Observed behavior
N/A
Log Output
N/A

Additional Information
Hello!
This is not a bug per se, but the following links for the v5.8.1 windows zip files are down:

https://releases.mattermost.com/desktop/5.8.1/mattermost-desktop-5.8.1-win32.zip
https://releases.mattermost.com/desktop/5.8.1/mattermost-desktop-5.8.1-win64.zip
https://releases.mattermost.com/desktop/5.8.1/mattermost-desktop-5.8.1-arm64.zip

This hinders installations and updates via, e.g., scoop installer, which currently uses these links as sources for Mattermost desktop.
Thank you for your time!

Source for the download links: https://github.com/mattermost/desktop/releases/tag/v5.8.1

Looks like correct links are
https://releases.mattermost.com/desktop/5.8.1/mattermost-desktop-5.8.1-win-x64.zip
https://releases.mattermost.com/desktop/5.8.1/mattermost-desktop-5.8.1-win-ia32.zip
https://releases.mattermost.com/desktop/5.8.1/mattermost-desktop-5.8.1-win-arm64.zip
as files from release assets named.

Yes, these are the new links. I will update the GitHub release and make a fix for the script that generates that.
Thanks for pointing that out for us :)


Archive the project as it's dead

Hi, given the project is basically unmaintained (as in https://github.com/miki725/django-rest-framework-bulk/issues/71), couldn't you explicitly archive the project to make it clear to everyone? Or at least writing it in the README would be good.

Hello @hnykda ! I agree with you, but are there any fork where we can continue to develop this package?
I found this one pretty helpful and wanna use it in my projects.

I am unfortunately not aware of any :-/ . Anyone can fork it of course, but it should be clear that it's not maintained anymore here, e.g. to know that recent versions may not work or that there may be security flaws.

@miki725 Do you have free time for maintaining this package? Otherwise it would be great if anyone will continue this work.

https://github.com/jazzband exists exactly for this. All @miki725 has to do is transfer the repository's ownership


NET_TESTS improvements

Added random generated MAC in NET_TESTS
VLAN Tagging testing changed from External to Private

 Network tests improvements


Topological Sort in graphs c++

I would like to add topological sort in the graphs folder in c++.
May you please assign me?

Hi @ronsemel,
How is going on with this issue?

Hey @ming-tsai, can I work on this issue?

Hello, due to injury I was unavailable for a long time, may u please take me off the assignment?
Get Outlook for iOShttps://aka.ms/o0ukef

From: DEVSI SINGH @.>
Sent: Friday, July 9, 2021 4:22:13 PM
To: MakeContributions/DSA @.>
Cc: Ran Semel @.>; Mention @.>
Subject: Re: [MakeContributions/DSA] Topological Sort in graphs c++ (#326)
Hey @ming-tsaihttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fming-tsai&data=04|01|ran.semel%40campus.technion.ac.il|29546cae8c214d1f327808d942dc90fc|f1502c4cee2e411c9715c855f6753b84|1|0|637614337358333531|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=UB2xwR0NF7EOJOfYPzXGxPIwrT6H%2BPCnBAqP4bHwgE4%3D&reserved=0, can I work on this issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMakeContributions%2FDSA%2Fissues%2F326%23issuecomment-877183734&data=04|01|ran.semel%40campus.technion.ac.il|29546cae8c214d1f327808d942dc90fc|f1502c4cee2e411c9715c855f6753b84|1|0|637614337358343528|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=jhIWoUO7I7veFlSPc2D2OGIMzKGGhBgbUAVc6EGTh%2FY%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAN4O5IXLU3J2LYECA6GWKJLTW3ZYLANCNFSM45WLXKNQ&data=04|01|ran.semel%40campus.technion.ac.il|29546cae8c214d1f327808d942dc90fc|f1502c4cee2e411c9715c855f6753b84|1|0|637614337358343528|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=DAhsbnheawqlcjBXn21uuEbU%2B6VyU0IiUX6VSOIJUwA%3D&reserved=0.
External e-mail, be judicious when opening attachments or links

Hey @ming-tsai, can I work on this issue?

There is a change on #381


BI-1933 - Erroneous message: No germplasm are currently defined for this program

Description
Story: BI-1933
A common pattern in bi-web is to have a get{Entities} method for the data in a table view that is called within the mounted() method of the component, while also having a paginationChanged method with a @Watch annotation reference an PaginationController that can also call get{Entities}. In some (but not all) cases, the PaginationController instance is mutated in the mounted() method. This resulted in the get{Entities} method being called twice on initial page load, and (maybe) because of the way Vue handles reactivity, the "empty" table message would sometimes flash on screen. The larger issue though was that the duplicate calls were unnecessary, and since paginationChanged already has short-circuiting logic built in to ensure get{Entities} is called only when the request parameters are changed, a good solution was to remove the call to get{Entities} in mounted() and directly call paginationChanged instead.
Additionally, some components were calling updatePagination() from mounted(), which is also called when needed by paginationChanged(), so I removed those calls from mounted().
Testing

Import a large germplasm file (1000+ records) and ensure the "No germplasm are currently defined for this program." message does not flash on screen while the germplasm are loading into the table view. Note that this is hard to reproduce even when present, I recommend focusing on steps 2. and 3. instead.
Ensure all tables load data.
In the dev tools network tab, ensure duplicate (identical) calls are not being made on initial page load.
These are the affected table components and URL paths where they can be tested:

File
Route

AdminProgramsTable.vue
/admin/programs

AdminUsersTable.vue
/admin/users

ExperimentsObservationsTable.vue
/programs/{programId}/experiments-observations

GermplasmListsTable.vue
/programs/{programId}/germplasm/germplasm-lists

GermplasmTable.vue
/programs/{programId}/germplasm/germplasm-all

OntologyTable.vue
/programs/{programId}/ontology/[active | archived]-terms

ProgramLocationsTable.vue
/programs/{programId}/program-administration/locations

ProgramUsersTable.vue
/programs/{programId}/program-administration/users

TraitsImportTable.vue*
/programs/{programId}/import/ontology

*To test the TraitsImportTable component, import ontology and make sure the preview displays correctly.
Checklist:

[x] I have performed a self-review of my own code
[x] I have tested my code and ensured it meets the acceptance criteria of the story
[ ] I have create/modified unit tests to cover this change
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to documentation
[ ] I have run TAF: <link to TAF run>

I'll need to create a new feature branch to merge these changes into release/1.0, this branch was based off of develop after some v1.1 stories were already merged.


Create Builder for SequencePaxos and BLE from configs

Have a build() function in SequencePaxosConfig that does some basic asserts e.g. pid != 0 and returns SequencePaxos. Same for BLE.

Added build() functions for SequencePaxos & BLE configs in this commit https://github.com/haraldng/omnipaxos/pull/48/commits/ade26017557aa6bec27d13b404174262ad265ab0


[bug] Error when using connectorsForWallets to create connectors object in cookieToInitialState  by wagmi

Is there an existing issue for this?

[X] I have searched the existing issues

RainbowKit Version
2.1.0
wagmi Version
2.9.2
Current Behavior
I encountered an error when using connectorsForWallets to create connectors object while passing wagmiConfig in cookieToInitialState.
When trying to use connectorsForWallets to create the connectors object, I receive an error indicating that connectorsForWallets is not a function.
I'm sure it's at the stage const initialState = cookieToInitialState(wagmiConfig, cookie);  error occurred
Expected Behavior
The connectors object should be correctly created using connectorsForWallets without any errors.
Steps To Reproduce

Use the web3-nextjs-template
Configure wagmiConfig as shown above.
Try to use cookieToInitialState with wagmiConfig.

import { cookieToInitialState } from 'wagmi';
const initialState = cookieToInitialState(wagmiConfig, cookie);

import { connectorsForWallets } from '@rainbow-me/rainbowkit';

const connectors = (connectorsForWallets as CreateConnectorFn[0] | undefined)(
  [
    {
      groupName: 'Recommended',
      wallets: [rainbowWallet, walletConnectWallet],
    },
    {
      groupName: 'Suggested',
      wallets: [
        metaMaskWallet,
      ],
    },
  ],
  { appName: 'App', projectId: '......' },
);

const wagmiConfig = createConfig({
  connectors,
  chains: [mainnet],
  transports: {
    [mainnet.id]: http(),
  },
  storage: createStorage({
    storage: cookieStorage,
  }),
  ssr: true,
});

Link to Minimal Reproducible Example (CodeSandbox, StackBlitz, etc.)
No response
Anything else?

"@rainbow-me/rainbowkit": "^2.1.0",
    "@rainbow-me/rainbowkit-siwe-next-auth": "^0.4.1",
<EMAIL_ADDRESS>"^1.91.8",
    "@tanstack/react-query": "^5.36.2",
    "@tanstack/react-query-devtools": "^5.37.1",
    "@web3modal/wagmi": "^4.2.1",
    "class-variance-authority": "^0.7.0",
    "clsx": "^2.0.0",
    "ethers": "^6.12.1",
    "iron-session": "^8.0.1",
    "lucide-react": "^0.274.0",
    "next": "latest",
    "next-auth": "5.0.0-beta.18",
    "phantom-wagmi-connector": "^1.0.7",
    "prisma": "^5.14.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "siwe": "^2.3.2",
    "tailwind-merge": "^1.14.0",
    "tailwindcss-animate": "^1.0.7",
    "viem": "2.x",
    "wagmi": "^2.9.2"

@CS6 It seems like you're trying to use wagmiConfig in a server component. Remember next js app router uses both server and client components which means you'd have to make sure that Provider.tsx file is used as a client component. This can be achieved by adding 'use client' on top of your Provider.tsx file.
Here is an example: https://github.com/rainbow-me/rainbowkit/blob/main/examples/with-next-app/app/providers.tsx#L1
Let me know if this works 👍

@magiziz
I have resolved the issue by adjusting the order of the providers and adding 'use client'; at the top of the relevant file.
Thanks for your support!


Tidy platform integration test scripts

Here: https://github.com/googleapis/gax-dotnet/tree/master/test/Google.Api.Gax.PlatformIntegrationTests
Either combine the two run_tests scripts into a single bash script, or split into separate tests, one for each supported platform (GAE, GCE, GKE; and none).

Fixed in #150.


AllianzTiriac- The current careers link does not send you to the correct url

ENVIROMENT: production
URL: https://scrapers.peviitor.ro/src/allianztiriac/index.html
Browser: Chrome
Device: laptop
OS: Windows 10
STEPS TO REPRODUCE:

Open URL in browser
Click on 'Run scraper' button
Go and click on 'Careers' link
Compare the jobs uploaded by the "Run scraper" button with the jobs found in the careers section

EXPECTED RESULTS:
The 'Careers' link should be https://www.allianztiriac.ro/ro_RO/cariere/cariere-posturi-disponibile.html#TabVerticalNegative11694447096 , where are found all open jobs
ACTUAL RESULTS:
The current 'Careers' link is https://www.allianztiriac.ro/en_RO/individuals/careers/open-positions.html
Not all open jobs can be found at the current link

Fixed


MayaInterval unable to parse from ISO 8601

When trying to initialise a MayaInterval object from an ISO 8601 string it always fails with a TypeError:
TypeError: unorderable types: MayaDT() == str()

I've included the full stack trace below, it seems to be a problem with how Pendulum is parsing the string.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/code/lib/python2.7/site-packages/maya/core.py", line 395, in from_iso8601
    end = parse(start)
  File "/code/lib/python2.7/site-packages/maya/core.py", line 646, in parse
    dt = pendulum.parse(string, **options)
  File "/code/lib/python2.7/site-packages/pendulum/parser.py", line 75, in parse
    return Parser(**options).parse(text)
  File "/code/lib/python2.7/site-packages/pendulum/parser.py", line 28, in parse
    if text == 'now':
  File "/code/lib/python2.7/site-packages/maya/core.py", line 38, in wrapper
    type(self).__name__, operator, type(arg).__name__))
TypeError: unorderable types: MayaDT() == str()

I also just realised that I am playing with a function that by default raises a NotImplementedError so I'm going to close this for now.


F*: the mechanism that opens implicitly referenced modules is broken

On MLKem, this mechanism doesn't always work.
For instance, here it kicks in: https://github.com/cryspen/libcrux/blob/d755e44c477f31266c3000f47feb69e99b7d0017/libcrux-ml-kem/proofs/fstar/extraction/Libcrux_ml_kem.Sampling.fsti#L6-L11.
But it doesn't here: https://github.com/cryspen/libcrux/blob/ml-kem-lax-check/libcrux-ml-kem/proofs/fstar/extraction/Libcrux_ml_kem.Mlkem768.Portable.fsti (it requires Libcrux_ml_kem.Vector.Portable)
We need a reproducer here

I think this is still relevant.

@maximebuyse, do you think this is all about automatic derives we skip?
Can you link this issue to the relevant other issues/PRs?

Ah, ok. Then that's probably a separate issue, let's investigate.
Yeah, the issue was not very understandable, I added more context :)
There are too many opens, in this case!

Ah, ok. Then that's probably a separate issue, let's investigate. Yeah, the issue was not very understandable, I added more context :) There are too many opens, in this case!

The opens seem reasonable in this case. If it creates a cycle then maybe bundling would kick in and solve this with a recent version of hax


feat(Object): add AV.Object.fetchAll

close #277

[Current coverage][cc-pull] is 65.44%

Merging [#327][cc-pull] into [master][cc-base-branch] will increase coverage by 0.18%

@@             master       #327   diff @@
==========================================
  Files            29         29
  Lines          2927       2940    +13
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1910       1924    +14
+ Misses         1017       1016     -1
  Partials          0          0

Powered by Codecov. Last updated by [f951523...c0885a8][cc-compare]
[cc-base-branch]: https://codecov.io/gh/leancloud/javascript-sdk/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/leancloud/javascript-sdk/compare/f9515239e63be1e5a85b489e791dbe87e61fdb1f...c0885a854a1245787c5ebff39a8b563b108e5fde?src=pr
[cc-pull]: https://codecov.io/gh/leancloud/javascript-sdk/pull/327?src=pr


Add ci cd

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Line::fromSpans should be variadic

    public static function fromSpans(array $spans): self

You can assign this issue to me if you want.


GSP602 go111 not supported

In the GSP602 Lab, one of the steps is to deploy cloud function with go111 using the following command:
gcloud functions deploy Gopher --runtime go111 --trigger-http
After executing this command, I get an error:
"ERROR: (gcloud.functions.deploy) argument --runtime: go111 is not a supported runtime. Use gcloud functions runtimes list to get a list of available runtimes"
I tried to use go113 and go120, which successfully deploys the function, but the "Check my progress button results with error: "Please deploy a Gopher HTTP Cloud Function with specific configurations."
Probably the check my progress mechanism checks for the runtime version.
Also tried manually changing it to go 1.11 from the console, and it says:
Runtime validation errors: [error_code: DEPLOYS_NOT_ALLOWED message: "Runtime go111 is no longer allowed.  Please use the latest Go runtime for cloud functions." ]
Go1.11 no longer supported since June 5th 2023.
And From the bottom of the lab it says:
Manual Last Updated October 16, 2022
Lab Last Tested June 3, 2022

Same issue I also facing.. not able to complete the lab
You got any solution?

The lab has been updated to use go120 instead of go111.
Thank you for the detailed issue report!


Use LEDs in a useful way

Did we see the ball? Does team communication work? What is your role? Are you walking to the ball?
Look at rules to see if it is allowed

Are we connected to the game controller
What is the strategy
What is the role


CI: Fix ubuntu-latest apt-get install ... 404 Not Found.

Let's see if it works.

Strange that worked before


[Dude]: How to obtain the information in the body of the report

What happened?
Brother, I need to use your plugin for reports, but I can't find the way to show the data, according to the documentation I must have those two methods/functions fn(?array $filters) => $this->registrationSummary($filters) which is not clear at all, is there any information that you can provide me or at least you could share the source code of the demo to see how to send that information to the body of the report.
How to reproduce the bug
It's not a failure, just a question of how it works
Package Version
3.0.7
PHP Version
8.3
Laravel Version
10.x
Which operating systems does with happen with?
Windows
Notes
In advance I apologize for my request, as well as thanks for your collaboration to the open source world.
Greetings from our beautiful Guatemala

Hello @intelguasoft , You are supposed to create a function to get the data. like in this case fn(?array $filters) => $this->registrationSummary($filters) create registrationSummary that returns data that will be displayed in your table. Hope that helps

You can complete replace this function call:
fn(?array $filters) => $this->registrationSummary($filters)
With something like:
fn(?array $filters) => \App\Models\Post::query()
->where( "status", $filters["status"])
->get()
Or
function ( ?array $filters): \Illuminate\Support\Collection {
$data = [
[ "name"=>"Eighty nine", "age"=>89],
[ "name"=>"Peter Parker", "age"=>21]
];
  return collect($data);

}
The most important thing is that your function must return a normal collection or an eloquent collection. I hope this clears your concern, I will also do my best to update the documentation accordingly.


error: "Please provide a valid authorization header"

Hi,
I am not using any artik cloud SDK's.
I am developing a react native app.
when i make a GET call to https://api.artik.cloud/v1.1/users/self
i am getting the subjected error.
in header i am sending the token that i have successfully generated
ex - Authorization: Bearer my_token
Do i need to send anything else in the request header or as a parameter ?
What am i missing ?
@yujingwu

@jonathanpaek  please handle this. DX-1513. thanks

@sumesh1993 please send this question form below (if not related to SDK):
https://artik.cloud/contact-us/ — will respond there.

request 1146 already open. please revert


incorrect example in documentation

I can't figure out where the error is, but the definitions from the documentation, printer seems to go wrong by continuing to request input when it should have stopped:
{-#LANGUAGE ScopedTypeVariables#-}

import Control.Pipe
import Control.Monad
import Control.Monad.Trans
import Control.Applicative

prompt :: Producer Int IO a
prompt = forever $ do
    lift $ putStrLn "Enter a number: "
    n <- read <$> lift getLine
    yield n

take' :: Int -> Pipe a a IO ()
take' n = do
    replicateM_ n $ do
        x <- await
        yield x
    lift $ putStrLn "You shall not pass!"

fromList :: (Monad m) => [a] -> Pipe Zero a m ()
fromList = mapM_ yield

printer :: (Show a) => Pipe a Zero IO b
printer = forever $ do
    x <- await
    lift $ print x

pipeline :: Pipeline IO ()
pipeline = printer <+< take' 3 <+< fromList [1..]

badpipeline =  printer <+< take' 3 <+< prompt
right = runPipe pipeline
wrong = runPipe badpipeline

--
-- *Main> right
-- 1
-- 2
-- 3
-- You shall not pass!
-- *Main> wrong
-- Enter a number:
-- 1
-- 1
-- Enter a number:
-- 2
-- 2
-- Enter a number:
-- 3
-- 3
-- You shall not pass!
-- Enter a number:
-- 4
-- *Main>

I fixed this but haven't released it yet because I was busy with a deadline
and forgot about releasing the patch.  I'll patch it today.  Long story
short, I changed the ordering of case statements for composition when
making last minute polishes to the code but this broke the category laws by
mistake.  I'm on my cell phone so I can't fix it immediately, but let me
see if I can find the e-mail where I outlined the fix for somebody else and
then completely forgot about it.
On Feb 1, 2012 7:44 AM, "Michael Thompson" <
<EMAIL_ADDRESS>wrote:

I can't figure out where the error is, but the definitions from the
documentation, printer seems to go wrong by continuing to request input
when it should have stopped:
{-#LANGUAGE ScopedTypeVariables#-}
import Control.Pipe
import Control.Monad
import Control.Monad.Trans
import Control.Applicative
prompt :: Producer Int IO a
prompt = forever $ do
lift $ putStrLn "Enter a number: "
n <- read <$> lift getLine
yield n
take' :: Int -> Pipe a a IO ()
take' n = do
replicateM_ n $ do
x <- await
yield x
lift $ putStrLn "You shall not pass!"
fromList :: (Monad m) => [a] -> Pipe Zero a m ()
fromList = mapM_ yield
printer :: (Show a) => Pipe a Zero IO b
printer = forever $ do
x <- await
lift $ print x
pipeline :: Pipeline IO ()
pipeline = printer <+< take' 3 <+< fromList [1..]
badpipeline =  printer <+< take' 3 <+< prompt
right = runPipe pipeline
wrong = runPipe badpipeline
--
-- *Main> right
-- 1
-- 2
-- 3
-- You shall not pass!
-- *Main> wrong
-- Enter a number:
-- 1
-- 1
-- Enter a number:
-- 2
-- 2
-- Enter a number:
-- 3
-- 3
-- You shall not pass!
-- Enter a number:
-- 4
-- *Main>

Reply to this email directly or view it on GitHub:
https://github.com/Gabriel439/Haskell-Pipes-Library/issues/6

Here you go.  Sorry if it is not formatted correctly.  I'll let you know
when I post the fix.
---------- Forwarded message ----------
From: "Gabriel Gonzalez"<EMAIL_ADDRESS>Date: Jan 20, 2012 9:06 AM
Subject: Re: [Haskell-Pipes-Library] Category axioms do not hold (#5)
To: "Paolo Capriotti" <
<EMAIL_ADDRESS>
**
Here is the incorrect case statement:
    (Yield (x1, p1), p2            ) -> yield x1 >>         p1 <+< p2
    (M m1          , p2            ) -> lift m1  >>= \p1 -> p1 <+< p2
    (p1            , Await f2      ) -> await    >>= \x  -> p1 <+< f2 x
    (p1            , M m2          ) -> lift m2  >>= \p2 -> p1 <+< p2
    (Await f1      , Yield (x2, p2)) -> f1 x2 <+< p2
    (Pure r1       , _             ) -> return r1 <-- in the wrong place
    (_             , Pure r2       ) -> return r2

And here is the corrected one:
    (Yield (x1, p1), p2            ) -> yield x1 >>         p1 <+< p2
    (M m1          , p2            ) -> lift m1  >>= \p1 -> p1 <+< p2
    (Pure r1       , _             ) -> return r1 <-- belongs here to

short circuit upstream pipes
(p1            , Await f2      ) -> await    >>= \x  -> p1 <+< f2 x
(p1            , M m2          ) -> lift m2  >>= \p2 -> p1 <+< p2
(Await f1      , Yield (x2, p2)) -> f1 x2 <+< p2
(_             , Pure r2       ) -> return r2
Here's the reasoning behind the case statement order.
First off, several case statements can only resolve one way and are
obvious.  I'll use an arrow in the middle to indicate which one gets
priority.  The one on the left is the downstream pipe:
await -> m
await -> pure
await -> await
yield <- yield
m <- yield
await = yield -- fusion
The identity laws require several more priorities.  From the identity laws
we can deduce that yield must trump everything because:
forever (await >>= yield) <+< (yield x)
On 01/20/2012 07:53 AM, Paolo Capriotti wrote:
The category axioms do not hold for either the Lazy or Strict category
instances, even if we identify observationally equal pipes. In particular,
composition is not associative:
runPipe $ lift (print 1) >+> yield () >+> lift (print 2)

prints 2, while
runPipe $ lift (print 1) >+> (yield () >+> lift (print 2))

prints 2 and 1.
Also, id is not a right identity for terminated pipes. For example, given
feed = yield () >> lift (print 0)
p1 = feed >+> return ()
p2 = feed >+> (idP >+> return ())

the pipe p2 prints 0 while p1 doesn't print anything.
I initially thought it was just a matter of reordering some clauses in the
definition of composition, but now I'm not so sure this could be fixed so
easily. In fact, x >+> Yield should always evaluate to Yield (as it does
currently), otherwise something of the form Yield >+> Await >+> Yield doesn't
associate. But then it seems that my first counterexample is unavoidable.
The issue with identity is less of a concern, since it's always possible to
introduce a formal identity (for example, by adding a Transform (a -> b)
alternative to the Pipe declaration).

Reply to this email directly or view it on
GitHub:https://github.com/Gabriel439/Haskell-Pipes-Library/issues/5

Ah I see. It is working fine with that correction. I was too distracted trying to find something wrong in the definitions of 'printer' etc to consider that the trouble might have arisen in the library.  yours Michael
----- Original Message -----
From: Gabriel439<EMAIL_ADDRESS>To: Michael Thompson<EMAIL_ADDRESS>Cc:
Sent: Wednesday, February 1, 2012 11:33 AM
Subject: Re: [Haskell-Pipes-Library] incorrect example in documentation (#6)
Here you go.  Sorry if it is not formatted correctly.  I'll let you know
when I post the fix.
---------- Forwarded message ----------
From: "Gabriel Gonzalez"<EMAIL_ADDRESS>Date: Jan 20, 2012 9:06 AM
Subject: Re: [Haskell-Pipes-Library] Category axioms do not hold (#5)
To: "Paolo Capriotti" <
<EMAIL_ADDRESS>
**
Here is the incorrect case statement:
(Yield (x1, p1), p2            ) -> yield x1 >>         p1 <+< p2
        (M m1          , p2            ) -> lift m1  >>= \p1 -> p1 <+< p2
        (p1            , Await f2      ) -> await    >>= \x  -> p1 <+< f2 x
        (p1            , M m2          ) -> lift m2  >>= \p2 -> p1 <+< p2
        (Await f1      , Yield (x2, p2)) -> f1 x2 <+< p2
        (Pure r1       , _             ) -> return r1 <-- in the wrong place
        (_             , Pure r2       ) -> return r2
And here is the corrected one:
(Yield (x1, p1), p2            ) -> yield x1 >>         p1 <+< p2
        (M m1          , p2            ) -> lift m1  >>= \p1 -> p1 <+< p2
        (Pure r1       , _             ) -> return r1 <-- belongs here to
short circuit upstream pipes
        (p1            , Await f2      ) -> await    >>= \x  -> p1 <+< f2 x
        (p1            , M m2          ) -> lift m2  >>= \p2 -> p1 <+< p2
        (Await f1      , Yield (x2, p2)) -> f1 x2 <+< p2
        (_             , Pure r2       ) -> return r2
Here's the reasoning behind the case statement order.
First off, several case statements can only resolve one way and are
obvious.  I'll use an arrow in the middle to indicate which one gets
priority.  The one on the left is the downstream pipe:
await -> m
await -> pure
await -> await
yield <- yield
m <- yield
await = yield -- fusion
The identity laws require several more priorities.  From the identity laws
we can deduce that yield must trump everything because:
forever (await >>= yield) <+< (yield x)
On 01/20/2012 07:53 AM, Paolo Capriotti wrote:
The category axioms do not hold for either the Lazy or Strict category
instances, even if we identify observationally equal pipes. In particular,
composition is not associative:
runPipe $ lift (print 1) >+> yield () >+> lift (print 2)
prints 2, while
runPipe $ lift (print 1) >+> (yield () >+> lift (print 2))
prints 2 and 1.
Also, id is not a right identity for terminated pipes. For example, given
feed = yield () >> lift (print 0)
    p1 = feed >+> return ()
    p2 = feed >+> (idP >+> return ())
the pipe p2 prints 0 while p1 doesn't print anything.
I initially thought it was just a matter of reordering some clauses in the
definition of composition, but now I'm not so sure this could be fixed so
easily. In fact, x >+> Yield should always evaluate to Yield (as it does
currently), otherwise something of the form Yield >+> Await >+> Yield doesn't
associate. But then it seems that my first counterexample is unavoidable.
The issue with identity is less of a concern, since it's always possible to
introduce a formal identity (for example, by adding a Transform (a -> b)
alternative to the Pipe declaration).

Reply to this email directly or view it on
GitHub:https://github.com/Gabriel439/Haskell-Pipes-Library/issues/5

Reply to this email directly or view it on GitHub:
https://github.com/Gabriel439/Haskell-Pipes-Library/issues/6#issuecomment-3761860

Ok, I just uploaded the fix as v1.0.1.  It should show up on Hackage
within a few hours.  Thanks again for reminding me about the problem.
On 02/01/2012 08:49 AM, Michael Thompson wrote:

Ah I see. It is working fine with that correction. I was too distracted trying to find something wrong in the definitions of 'printer' etc to consider that the trouble might have arisen in the library.  yours Michael
----- Original Message -----
From<EMAIL_ADDRESS>To: Michael<EMAIL_ADDRESS>Cc:
Sent: Wednesday, February 1, 2012 11:33 AM
Subject: Re: [Haskell-Pipes-Library] incorrect example in documentation (#6)
Here you go.  Sorry if it is not formatted correctly.  I'll let you know
when I post the fix.
---------- Forwarded message ----------
From: "Gabriel<EMAIL_ADDRESS>Date: Jan 20, 2012 9:06 AM
Subject: Re: [Haskell-Pipes-Library] Category axioms do not hold (#5)
To: "Paolo Capriotti"<
<EMAIL_ADDRESS>**
Here is the incorrect case statement:
     (Yield (x1, p1), p2            ) ->  yield x1>>          p1<+<  p2
     (M m1          , p2            ) ->  lift m1>>= \p1 ->  p1<+<  p2
     (p1            , Await f2      ) ->  await>>= \x  ->  p1<+<  f2 x
     (p1            , M m2          ) ->  lift m2>>= \p2 ->  p1<+<  p2
     (Await f1      , Yield (x2, p2)) ->  f1 x2<+<  p2
     (Pure r1       , _             ) ->  return r1<-- in the wrong place
     (_             , Pure r2       ) ->  return r2

And here is the corrected one:
     (Yield (x1, p1), p2            ) ->  yield x1>>          p1<+<  p2
     (M m1          , p2            ) ->  lift m1>>= \p1 ->  p1<+<  p2
     (Pure r1       , _             ) ->  return r1<-- belongs here to

short circuit upstream pipes
(p1            , Await f2      ) ->  await>>= \x  ->  p1<+<  f2 x
(p1            , M m2          ) ->  lift m2>>= \p2 ->  p1<+<  p2
(Await f1      , Yield (x2, p2)) ->  f1 x2<+<  p2
(_             , Pure r2       ) ->  return r2
Here's the reasoning behind the case statement order.
First off, several case statements can only resolve one way and are
obvious.  I'll use an arrow in the middle to indicate which one gets
priority.  The one on the left is the downstream pipe:
await ->  m
await ->  pure
await ->  await
yield<- yield
m<- yield
await = yield -- fusion
The identity laws require several more priorities.  From the identity laws
we can deduce that yield must trump everything because:
forever (await>>= yield)<+<  (yield x)
On 01/20/2012 07:53 AM, Paolo Capriotti wrote:
The category axioms do not hold for either the Lazy or Strict category
instances, even if we identify observationally equal pipes. In particular,
composition is not associative:
 runPipe $ lift (print 1)>+>  yield ()>+>  lift (print 2)

prints 2, while
 runPipe $ lift (print 1)>+>  (yield ()>+>  lift (print 2))

prints 2 and 1.
Also, id is not a right identity for terminated pipes. For example, given
 feed = yield ()>>  lift (print 0)
 p1 = feed>+>  return ()
 p2 = feed>+>  (idP>+>  return ())

the pipe p2 prints 0 while p1 doesn't print anything.
I initially thought it was just a matter of reordering some clauses in the
definition of composition, but now I'm not so sure this could be fixed so
easily. In fact, x>+>  Yield should always evaluate to Yield (as it does
currently), otherwise something of the form Yield>+>  Await>+>  Yield doesn't
associate. But then it seems that my first counterexample is unavoidable.
The issue with identity is less of a concern, since it's always possible to
introduce a formal identity (for example, by adding a Transform (a ->  b)
alternative to the Pipe declaration).

Reply to this email directly or view it on
GitHub:https://github.com/Gabriel439/Haskell-Pipes-Library/issues/5

Reply to this email directly or view it on GitHub:
https://github.com/Gabriel439/Haskell-Pipes-Library/issues/6#issuecomment-3761860

Reply to this email directly or view it on GitHub:
https://github.com/Gabriel439/Haskell-Pipes-Library/issues/6#issuecomment-3762193


Filter applicationTemplate by displayName

/applicationTemplate lists over 2,000 templates. By applying $filter, we can return only the application template that the user needs for this tutorial.

@FaithOmbongi : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@kenwith kindly review this change.

@FaithOmbongi : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Ensure current connection info remains available during ZDT

During Zonal Down Time, the Connector will experience a short period of connection failures. Currently, we force refresh on each connection failure. This feature request is to ensure that if the refresh is rate limited, the current connection info remains available to support fast re-connections.

This is probably just a matter of deleting these lines:
https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/main/src/cloud-sql-instance.ts#L101-L104

I believe this was handled in https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/pull/219, more specifically this line should take care of refreshing automatically and still apply rate limits on connection failures:
https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/290d741b00545bb801431d8711b1de4285da17d0/src/cloud-sql-instance.ts#L161
While current connection info should also remain available to support new connections, given that we only update values in a CloudSQLInstance once a refresh has successfully completed:
https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/290d741b00545bb801431d8711b1de4285da17d0/src/cloud-sql-instance.ts#L141-L143
@jackwotherspoon I know you helped me review some of this logic and I would love to have your input here. Should we close this issue?

What I'm wondering about is the significance of this line:
https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/290d741b00545bb801431d8711b1de4285da17d0/src/cloud-sql-instance.ts#L111

oh, this never really blocks anything (other than in tests) since the only place forceRefresh is called from is this callback handler that doesn't block any other logic:
https://github.com/GoogleCloudPlatform/cloud-sql-nodejs-connector/blob/290d741b00545bb801431d8711b1de4285da17d0/src/connector.ts#L220-L222
Connection attempts from the driver would not be prevented from that. Looking at this particularly part of the code, I believe I should remove the async/await since it server no purpose here in this callback.

Got it. In that case, I agree -- we fixed this in #219.

Sounds good 👍 thanks @enocom!


expose ready as public method

What do you think about making ready a public method?
I'm using Ahoy.server_side_visits = :when_needed so my JS creates the visit. Once the visit is created I want to do more work that's conditional on the visit being present.
ahoy.ready(() => {
  axios.get('/account')
    .then((response) => {
      const account = response.data;
      mixpanel.identify(account.id);
      mixpanel.people.set({
        '$email': account.email,
        '$created': account.created_at,
        '$first_name': account.first_name,
        '$last_name': account.last_name,
        '$name': account.name
      });
    });
});

I've added a test case but was unable to run it because I don't have saucelabs credentials.

Let me know if there is something I need to do to get Travis to run. Happy to kick off a new build.

Hey @hwhelchel, sorry for the long delay. This feature makes sense to me, and the code looks great!


dependency-function

defines Dependency in params.py
Dependency inserts is_dependency=True into field.extra
excludes explicit dependencies from parameter documentation.

Closes #128
Related #136

[x] Implement Dependency function - consider the params that we expose from Field.
[ ] Implement skip declared dependencies for parameter documentation if the dependency not provided.
[ ] Build logic for checking that all declared dependencies are either provided or have a default value.
[ ] Docs for Dependency, include example.

Test cases:

[ ] In/out tests for Dependency function that tests the stuff we rely on in extra is there.
[ ] declared optional type and undefined default, e.g., dep: int | None = Dependency()
[ ] non-optional type and defined default, e.g., dep: int = Dependency(default=30)
[ ] error case, e.g., dep: int = Dependency() and dep not provided
[ ] test that parameters for dependencies reach the docs if the dependency is provided.
[ ] test that the default values reach the dependency if not provided.
[ ] some tests of validation Field parameters.
[ ] test that any validation failures of dependency fields are 500s not 400s - if a dependency fails validation it isn't the client's fault.

Please check sonar - also coverage is below 100%.

Yeh this isn't ready yet.
I pushed up the impl so that I could open a PR to move my checklist from the issue into here.
Working on the tests now.

Yeh this isn't ready yet.
I pushed up the impl so that I could open a PR to move my checklist from the issue into here.
Working on the tests now.

Sorry. Will hold back next time. To avoid confusion, best to use a draft PR

It is draft ;) although I marked it draft a few seconds after I created it. So Sonar should run on drafts?

It is draft ;) although I marked it draft a few seconds after I created it. So Sonar should not run on drafts?

It does. Anyhow, sorry

No problems at all.
Does it make too much noise for you if I work directly in the repo? I can be doing a lot of this in my fork if that's better?

Not at all.
I get a lot of notifications usually - work stuff.

I've cooled on allowing validation arguments to Dependency for now.
For one thing it isn't clear what error should be returned to the client. Probably should be a 500 error by default if an explicit dependency fails validation, however that might need to be configurable, maybe Dependency(lt=13, invalid_status=400).
It would also be possible to have both a client parameter validation failure and a dependency validation failure on the same signature model for a given request. In that case we'd probably have to return the higher status code of 400 or the status for the dependency validation failure.
By excluding the validation kwargs from Dependency altogether for now it means we can add them in later on when someone requests them with a concrete use case and not break anything. It would be much harder to take them away or even worse to have to maintain support with edge cases everywhere forever.
There is also the issue of identifying that the field that raised the ValidationError is a Dependency field in SignatureModel.parse_values_from_connection_kwargs(). I'm sure it is possible, but case where the dependency is buried a few levels below the surface of the dependency tree of the handler might be be tricky.

@Goldziher I still have to do the docs, but code is ready for review.

@Goldziher I still have to do the docs, but code is ready for review.

Ok, will review shortly. Please look in sonar and increase coverage to 100%.

Please look in sonar and increase coverage to 100%.

The one line that has no coverage in sonar is the else block for if sys.version_info >= (3, 10):. Sonar must be running on 3.10. Is it coverage.py under the hood (I.e, # pragma: no cover to exclude the line from coverage)?

Yup

I ran into a chicken and egg scenario where I need the name of all provided dependencies to check for the error condition prior to the signature model being constructed (because I need them to check the signature model themselves). That prevents me from using route_handler.resolve_dependencies() to get the names of the dependencies. So I added to BaseRouteHandler:
    @property
    def dependency_name_set(self) -> Set[str]:
        """
        The set of all dependency names provided in the handler's ownership layers.

        Intended as a fast to compute set of the names of dependencies provided to the handler, and
        available at the time that the handler's signature model is generated. Full resolution of
        dependencies requires that the signature model is already generated and is performed in
        ``BaseRouteHandler.resolve_dependencies()``.
        """
        if self.resolved_dependency_name_set is BaseRouteHandler.empty:
            self.resolved_dependency_name_set = {
                k
                for k in itertools.chain.from_iterable(
                    (layer.dependencies or {}).keys() for layer in self.ownership_layers()
                )
            }
        return cast(Set[str], self.resolved_dependency_name_set)

Also added a section to the bottom of the usage docs in 6-dependency-injection.md.
LMK any changes you'd like and I'll try to close this one out so I can clean up the other couple of PRs that are there.
Would you prefer a squash and merge for a PR like this one?


Bugfix/submod docu Adaptions, formatting and beautifications.

As suggested by @gabryelreyes , that shall be merged back to release/v1.1.x, where it was derived from.

@Karle3 Looks good to me, thank you for the fixes.
Could you please change all ocurrences of GIT to Git? In that way it will be uniform across all documents


Update README.md

What problem does this PR solve?
add key-type description
Release note

No Release note

Codecov Report

Merging #2486 into master will increase coverage by 0.13%.
The diff coverage is 71.18%.

@@            Coverage Diff             @@
##           master    #2486      +/-   ##
==========================================
+ Coverage   77.01%   77.15%   +0.13%
==========================================
  Files         205      205
  Lines       21948    21994      +46
==========================================
+ Hits        16903    16969      +66
+ Misses       3755     3746       -9
+ Partials     1290     1279      -11

Impacted Files
Coverage Δ

server/cluster/coordinator.go
74.07% <7.14%> (-0.45%)
:arrow_down:

server/cluster/cluster.go
80.91% <71.42%> (+0.62%)
:arrow_up:

client/base_client.go
90.60% <100.00%> (+3.70%)
:arrow_up:

client/client.go
71.10% <100.00%> (+1.50%)
:arrow_up:

pkg/cache/ttl.go
90.66% <100.00%> (+4.72%)
:arrow_up:

server/cluster/cluster_worker.go
72.95% <100.00%> (+0.22%)
:arrow_up:

server/grpc_service.go
59.96% <100.00%> (+1.98%)
:arrow_up:

server/schedulers/base_scheduler.go
60.86% <0.00%> (-8.70%)
:arrow_down:

server/tso/tso.go
79.56% <0.00%> (-6.57%)
:arrow_down:

pkg/etcdutil/etcdutil.go
78.26% <0.00%> (-5.80%)
:arrow_down:

... and 14 more

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 06fbee6...ce2a02b. Read the comment docs.

/merge

/merge


groupBy throws inscrutable errors when inferred to be a transducer

    return pipe(
      chain(
        pipe(
          groupBy(interpreter?.group ?? 'unknown'),
          // this reducer can replace the groupBy call:
          /*
          reduce((agg, g) => {
            const lookup = interpreter?.group ?? 'unknown'
            const prev = agg[g[lookup]] ?? []
            agg[g[lookup]] = [...prev, g]
            return agg
          }, {}),
          */
          writeCommentsToFiles({ interpreter, outputDir })
        )
      )
    )(listOfFutureWrappedComments)

I have some code like this, working with a list of Futures. When I try to use groupBy I get an inscrutable error that says keyFn is not a function. I figure that is related to this bit of code: https://github.com/ramda/ramda/blob/fd55a1a0d82eb8e45e2974c2c9a70525d7b6ef42/source/reduceBy.js#L58 but I'm not certain. I have chosen to eschew the groupBy code in the interim, but I would really hope that ramda give me something more helpful to go on.
I can come up with a smaller / reproducible case if valuable, but since the error is nominally related to my code I wanted to raise this as is. I would love if ramda gave me some indication of what I did wrong in the groupBy call.
My assumption is that b/c Futures support transducing, and so this call is magically being delegated incorrectly. But I don't know b/c the error gives me nothing and doesn't even point at the code I wrote.

As I look at this actual function I see the problem 😅 Sorry for the trouble

groupBy(prop('x')) vs. groupBy('x') is the crux. But it'd be nice if ramda helped underline that for me

Sorry for the trouble

No trouble!

But it'd be nice if ramda helped underline that for me

If you aren't using them already, the types are getting better and better, they could have helped you here :)

😬 That might be trading one issue for another bigger one. I think TS is another problem space, well-defined. (ramda + generics involves so much annotation that I find it exhaustingly slow to develop against (at least last time I tried, 2ish years ago), but that's a subjective opinion. I think TS + curried functions is an exhausting endeavor currently) The monorepo I'm working in has plans to add more TS in the coming months, so I may end up eating my words.


Can we auto-convert a tensor into a numpy value when necessary in computing graph executing mode(&tf.function mode)?

Please make sure that this is a feature request. As per our GitHub Policy, we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:feature_template
System information

TensorFlow version (2.1): 2.1
Are you willing to contribute it (Yes/No): Yes

Describe the feature and the current behavior/state.
  def testTensorAndNumpy():
    npArray=np.random.uniform(0, 10000, size=200)
    #npArray=tf.random.uniform((200,), 0, 10000)
    @tf.function
    def myFunc(tensorValue):
      return(npArray[tensorValue])

    #tensorValue=3
    tensorValue=tf.convert_to_tensor(3)
    print(myFunc(tensorValue))
    print(npArray[tensorValue])

The above code works fine if we comment the @tf.function, but when we use @tf.function, it'll reporting the following errors:

....
    NotImplementedError: Cannot convert a symbolic Tensor (tensorValue:0) to a numpy array.
....

The root cause should be that the tensorflow's computing graph executing mode couldn't auto-convert the tensor to numpy value, but when in eager mode, this conversion could happen correctly and automatically. It seems not only my test case could trigger this bug, many other bugs report also relate to this root cause.
Will this change the current api? How?
No, it seems no need change the API spec, but we need change the implementation for tensorflow's tf.function.
Who will benefit with this feature?
Many engineers, it seems not only my test codes could trigger this error, many other tensorflow users also found similar issue. I searched "NotImplementedError: Cannot convert a symbolic Tensor ", about 10 issues exists, I guess the root cause for most them should be same as this test failure's root cause.
https://github.com/tensorflow/tensorflow/issues?q=NotImplementedError%3A+Cannot+convert+a+symbolic+Tensor
Any Other info.
We could change the npArray to a tensor, and then we could use tensor as the index for another tensor, this works fine(by disabling the first line and enable the second line). But because in my usage scenario, I need use numpy data array as the data source, and use tensor variable to access different part of this numpy data array. Because this combination could help me save lots of GPU memory, the GPU memory is much more expensive than CPU memory, and all tensors malloc need consume GPU memory. So I consider this issue as a new feature request instead of a bug report.
After implmenting this feature, engineers could feel more nature when switching between tensorflow's eager mode and graph mode, and most of those old connected bugs should also be fixed automatically.

Do you have any use case that requires the feature you are interested in? Please feel free to submit a PR if you have use cases that supports that feature.Thanks!

@ravikyram yes, I've use case to require this feature. The test codes I've provided could show that our current version tensorflow couldn't support this feature:
  def testTensorAndNumpy():
    npArray=np.random.uniform(0, 10000, size=200)
    #npArray=tf.random.uniform((200,), 0, 10000)
    @tf.function
    def myFunc(tensorValue):
      return(npArray[tensorValue])

    #tensorValue=3
    tensorValue=tf.convert_to_tensor(3)
    print(myFunc(tensorValue))
    print(npArray[tensorValue])

But I've no solution to implement this feature yet, so I couldn't submit a PR(pull request, right?).
My usage scenario is using a huge numpy data array as my tensorflow model's database, my tf model need freequently access data randomly from it, and the numpy data array is very huge, it couldn't be loaded into GPU because GPU's memory space is always much smaller than CPU's memroy space.
And I've found a workaround to this limitation for myself already. I could use tf.convert_to_tensor() to generate a tensor which will be always stored in CPU's memory, so the above test code could be changed to:
....
npArray=np.random.uniform(0, 10000, size=200)
tfArray=tf.convert_to_tensor(npArray)
print(tfArray.device)
# the following codes will handle tfArray
......

You could freely close this issue or use it to trace this new feature request: using tensor data array as slice index to access numpy data array in computing graph mode and tf.function mode (eager mode already suport this feature).
Thanks!

Fundamentally, one cannot convert a graph tensor to numpy array because the graph does not execute in Python - so there is no NumPy at graph execution. The only way to achieve this mix is by using tf.py_function, which is ok assuming you don't want a portable model, but which will negatively affect the performance of your graph. py_function has a number of other shortcomings as well, which is the reason why it's not inserted by default into the graph.
That said, I believe the correct conversion here would be for the NumPy array to be auto-converted to Tensor. That actually happens most of the time:

tesor_array[numpy_index] converts numpy_index to tensor
tensor_x + numpy_y converts numpy_y to tensor

Therefore, the following should also be true:

numpy_array[tensor_index] converts numpy_array to tensor

So from that perspective, we have a bug.
So this FR could generalize as: "any operation involving mixes of numpy and tensors should consistently upcast all non-tensor values to tensor". Unfortunately, that behavior is impossible to obtain in eager mode, which is what will probably make it infeasible.

@mdanatg Thanks for your clear explanation.
"one cannot convert a graph tensor to numpy array because the graph does not execute in Python - so there is no NumPy at graph execution. "
Yes, agree. And your explanation remind me to change the test codes to the following:
  def testTensorAndNumpy():
    npArray=np.random.uniform(0, 10000, size=200)
    @tf.function
    def myFunc(tensorValue, inputNPArray):
      return(inputNPArray[tensorValue])

    #tensorValue=3
    tensorValue=tf.convert_to_tensor(3)
    print(myFunc(tensorValue, npArray))
    print(npArray[tensorValue])

Because I've put the numpy array into the tf.function's parameter, so the tensorflow could auto-convert the numpy array into tensor. then the test could pass. But in my original test, the npArray is a bigger scope variale, the tf.function current mechanism couldn't catch the opportunity to do the auto-coversion from numpy to tensor. If we put it into function's parameter, the numpy-tensor conversion could happen by current tf.function mechanism.

"So this FR could generalize as: "any operation involving mixes of numpy and tensors should consistently upcast all non-tensor values to tensor". Unfortunately, that behavior is impossible to obtain in eager mode, which is what will probably make it infeasible."
Yes, it's infeasible. but I've confirmed that in the eager mode:
numpy_array[tensor_index]
will auto-convert the tensor_index into numpy value, and it works fine so far. So how to define the data type auto-conversion princple in tensorflow is decided by your team, I just report what I've found.

@clockzhong Thank you, I agree that this is an important observation that we should document.
The difference between function arguments and values captured through the function's closure is an important one too, and is related to another known limitation in which the function is not retraced if any of the variable it closes over change.
I think both of these aspects should be mentioned in the docstring of tf.function.

@clockzhong  Closing this issue as it is the Intended Behavior.Please feel free to re-open the issue if you have any concerns.Thanks!

@saikumarchalla  Ok, got it, thanks!


AttributeError: 'module' object has no attribute 'PresortBestSplitter'

>>> from cPickle import dump, load
>>> model_name='/tmp/wym/data/liushi_model.pickle'
>>> Gradclf=load(open(model_name,'rb'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'PresortBestSplitter'

You need to load the pickled model with the same version as you used to create it。


Output upsampling to original resolution

After running the code predict .py,i got the depth image output with resolution 160*128,How can i upsample it into original resolution.

I have the same problem, have you figured it out ?


Crash On change Library View

Hi TT,
When I change the Library View to ULtra Modern
it is crashed
I want to ask how to change it back to normal WITHOUT reset config or re-install theme.
I want to keep my config
Then, next I want to edit display rows infor and orders of metadata in DETAILS tab, what file I can edit?
Thank you!

Hi @PSVLTT,
I don't know which version you are using but there are no issues in version RC-2 and the master DEV version
when changing the Library's design to Ultra-modern and then back to Georgia-ReBORN.

Did you make a theme backup?

To make a theme backup, go to top menu Options > Settings > Theme backup > Make backup.
To restore a theme backup, go to top menu Options > Settings > Theme backup > Restore backup.

Also updating Georgia-ReBORN is pretty easy, even with old user configs:

Please make a theme backup via Options > Settings > Theme backup > Make backup.
Now make a new portable foobar install and install the latest DEV master version from here:
https://github.com/TT-ReBORN/Georgia-ReBORN/archive/refs/heads/master.zip
After you have downloaded and installed the theme, copy from your old foobar your theme backup folder:
foobar2000_old\profile\backup
to your new:
foobar2000\profile\backup
Then copy the new custom config from:
foobar2000\profile\georgia-reborn\configs\georgia-reborn-custom.jsonc
to your backup directory:
foobar2000\profile\backup\profile\georgia-reborn\configs\
Now restore your theme backup via Options > Settings > Theme backup > Restore backup

I don't know if you are stuck with the red screen and can not start Georgia-ReBORN:
You can right click on the red screen > Panel properties... and then click on the Clear button and OK.
This will load all Georgia-ReBORN's default theme settings, you can then load your saved settings from your
config via top menu Options > Settings > Theme configuration > Load settings from config file.

Before you edit the metadata grid, make a backup of your config file if something goes wrong:
foobar2000\profile\georgia-reborn\configs\georgia-reborn-config.jsonc
For only editing the title format patterns, you can right click on the metadata grid > Edit metadata grid.
For re-arranging the orders and also editing the title format patterns, I would recommend to make changes directly in your
foobar2000\profile\georgia-reborn\configs\georgia-reborn-config.jsonc
Open your config and go to the section "metadataGrid".
You should not change the original label names, but you can change the order and the pattern, i.e value.
You can also add new metadata entries with new names and patterns, see placeholders -> Blank 01- 08.
When editing, be careful not miss any apostrophes, brackets and commas.
Also keep in mind to fully display all metadata in Details, you need to have enough metadata grid height,
i.e a large player size.
-TT

Thank you for advanced detailed answer.
I will try it now.

Hello @TT-ReBORN ,
Sorry for long respond cause my PC problems.
Everything is working fine now.
Thank you very much!


CTAForm Component

Summary
Creating a CTAForm component that most commonly will be used to create subscribe CTA blocks for marketing pages. It can be applied for other use cases.
Deployments:
MDX Documentation
Storybook
List of notable changes:

added CTAForm component

What should reviewers focus on?

Making sure the component functions and looks like it is supposed to.

Steps to test:

Open the CTAForm component in CI-deployed preview environment
Go to CTAForm story in Storybook
Verify that the CTAForm behaves as described in the following issue.

Supporting resources (related issues, external links, etc):

Figma Design

Contributor checklist:

[ ] All new and existing CI checks pass
[ ] Tests prove that the feature works and covers both happy and unhappy paths
[ ] Any drop in coverage, breaking changes or regressions have been documented above
[ ] New visual snapshots have been generated / updated for any UI changes
[ ] All developer debugging and non-functional logging has been removed
[ ] Related issues have been referenced in the PR description

Reviewer checklist:

[ ] Check that pull request and proposed changes adhere to our contribution guidelines and code of conduct
[ ] Check that tests prove the feature works and covers both happy and unhappy paths
[ ] Check that there aren't other open Pull Requests for the same update/change

Screenshots:

We are currently working through the API exploration to make sure we don't miss any implementation details.


Apache http-proxy module doesn't load

Trying to setup Elasticsearch+Logstash+Kibana with Apache 2.4.
-- Successfully installed:
brew install elasticsearch logstash httpd24

-- Enabled virtual hosts module in /usr/local/etc/apache2/2.4/httpd.conf:
# Virtual hosts
Include /usr/local/etc/apache2/2.4/extra/httpd-vhosts.conf

and
LoadModule vhost_alias_module libexec/mod_vhost_alias.so

-- Created virtual host in /usr/local/etc/apache2/2.4/extra/httpd-vhosts.conf:
<VirtualHost *:8080>
    ServerName kibana4.serv
    ServerAlias www.kibana4.serv
    DocumentRoot /usr/local/var/www/kibana-4.0.2-darwin-x64/src/public
    <Directory /usr/local/var/www/kibana-4.0.2-darwin-x64/src/public>
        Require all granted
        Allow from all
        Options -MultiViews
    </Directory>
</VirtualHost>

-- Created new config for ELK /usr/local/etc/apache2/2.4/other/elk.conf:
LoadModule proxy_http_module /usr/local/opt/httpd24/libexec/mod_proxy_http.so

<Location /elasticsearch>
    ProxyPass http://localhost:9200/
    ProxyPassReverse /
    SSLRequireSSL
</Location>

<Location /kibana/>
    ProxyPass http://localhost:5601/
    ProxyPassReverse /
    SSLRequireSSL
</Location>

-- Included newly created config elk.conf to /usr/local/etc/apache2/2.4/httpd.conf:
Include /usr/local/etc/apache2/2.4/other/*.conf

BUT when I try to restart apache getting:
$ /usr/local/opt/httpd24/bin/httpd -D FOREGROUND
httpd: Syntax error on line 523 of /usr/local/etc/apache2/2.4/httpd.conf:
Syntax error on line 1 of /usr/local/etc/apache2/2.4/other/elk.conf:
Cannot load /usr/local/opt/httpd24/libexec/mod_proxy_http.so into server:
dlopen(/usr/local/opt/httpd24/libexec/mod_proxy_http.so, 10):
Symbol not found: _ap_proxy_cookie_reverse_map\n
Referenced from: /usr/local/opt/httpd24/libexec/mod_proxy_http.so\n
Expected in: flat namespace\n in /usr/local/opt/httpd24/libexec/mod_proxy_http.so

What's the problem loading mod_proxy_http.so? The path to the module is correct...

Well never mind I've addressed this issue

@Drewshg312 how did you fix it?

uncomment
LoadModule proxy_module libexec/mod_proxy.so
and please let me know if it worked.

apperntly it couldnt find the module... i reverted back using sierra's apache.


Resume from failed step on AWS step functions

I know we can resume a job (that is run by  AWS step function) from a failed step by cli command on local machines. But is there a ways to directly resume a failed step on AWS step functions without going through local machine cli command?

Hi @zexuan-zhou,
Unfortunately, AWS Step Functions doesn't provide any native capability to restart a failed execution. However, theoretically, it's feasible to create a parameterized flow (which takes in run_id and step) and copies over the state from run_id for all steps prior to step and execute the remainder of the flow as usual.

Hi @savingoyal
Thank you. Would you mind explaining a bit more? Are you saying that I should create another Metaflow flow and deploy it to AWS step that simply just copies a failed flow and restart it? I think I can understand the logic but I couldn't image how that flow will look like.

@zexuan-zhou Apologies for the delayed response. It depends on your exact use case, by you can access values from previous executions and assign those to your step using the client API. It will be a bit clunky tbh.

Hi @zexuan-zhou , how to resume a job (that is run by AWS step function) from a failed step using CLI command. Could you share me the command?
Start -> Activity1 -> Activity2 -> Activity3 -> Activity4 -> Stop
When an execution fails during some activity, let's say Activity2, the execution is marked as failure.
Now, is there anyway to resume this failed execution from the activity(Activity2) during which it failed earlier?

you can look at this https://aws.amazon.com/blogs/compute/resume-aws-step-functions-from-any-state/
it will resume from the last successful state.  Note that if you have a activity 2 was a parallel job and 1 failed out of eg 100, then all 100 will still be redone.


[TA] revisit TextAnalyticsActionResult and its child classes

Talked to Jonathan about the hierarchy of TextAnalyticsActionResult and its children classes. The base class TextAnalyticsActionsResult has no result property make this class feel strange. He suggested to rethink about the hierarchy.

https://github.com/Azure/azure-sdk-for-java/pull/20639#issuecomment-824251844


[BUG] Debug Tools do not scroll on macos

Testing with both the 'raylib-sidebar-scrolling-container' C example, and the Odin example. In both, scrolling works as expected, but if I hit D and open the debug tools, that seems to ignore scrolling input entirely. I have a feeling it's got something to do with the way Mac scrolling works where you can let go and it keeps scrolling for a bit (like a phone).
tldr: scroll containers worky, debug tools scroll containers no worky

Oh dear, yes I see. I've reproduced this locally. Thanks for reporting 🙂 Fix incoming.

In case you're wondering what the issue was - https://github.com/nicbarker/clay/pull/66 <- this PR changed the default behaviour of floating elements to capture pointer events like scroll and mouse hover (desirable, usually). However the debug tools use a funky setup to get the particular visual appearance they have, which means the pointer events were getting captured by something other than the scroll container. Oops!

Well, that was fast 😄