catalogue.md Interaction 4 of Scenario B and C, Post: create a customer article

"id" exists in the response example but is missing in the schema.
"id": "fd345ee7-ba9a-4856-8fcb-a912b10ea971",
"otherIdentifier": { "value": "SAP12345", "assignedBy": "Customer" },
"sellerProductOtherIdentifier": {
"value": "galerie-brite",
"assignedBy": "Seller"
Schema
CreateCustomerArticle:
type: object
required:
- name
properties:
otherIdentifier:
type: object
required:
- value
properties:
value:
PUT /customer-articles/{customerArticleId}
PATCH /customer-articles/{customerArticleId}
The "id" is also missing in the schema for  responses to PUT and PATCH, but this might be OK because customerArticleId (uuid) exists in the request. Information in the request doesn't need to be included in the reponse.
"id" in the request is in many other papiNet examples included in the response.
Should we do this in a consistent way?

The id property MUST be added to GetLocationById schema and the examples need to be updated accordingly.
As a general rule, I think we can say that the id MUST be included in a response body and MUST not be in a request body (as it is conveyed within the URL).

Done within https://github.com/papinet/papiNet-API/commit/889cc8ea5c91008c7e66415e6e15f0f9470b9ecc.

format: uuid is missing for property id in GetLocationByID:


Completion services should work with an EditorConfig instance

Completion services should work with an EditorConfig instance

What do you mean actually? You mean that the method that returns completion proposals should not call getTokenContext(), and should rather use a org.ec4j.core.model.EditorConfig instance that it gets passed as a parameter?
I thought getTokenContext() was designed to be more resilient than the parser, so that it can work well also on incomplete or otherwise broken .editorconfig files. What is the parser supposed to return in such cases?

What do you mean actually? You mean that the method that returns completion proposals should not call getTokenContext(), and should rather use a org.ec4j.core.model.EditorConfig instance that it gets passed as a parameter?

Exactly!

I thought getTokenContext() was designed to be more resilient than the parser, so that it can work well also on incomplete or otherwise broken .editorconfig files. What is the parser supposed to return in such cases?

Yes sure but EditorConfig instance can be loaded too with broken  .editorconfig files and with location too. My idea is that IDE maintains an EditorConfig instance (with location) and after we can use it to find the completion (like JDT does with their ICompilationUnit).
The problem with using getTokenContext is that we must maintain 2 parsers kind (one for getTokenContext an done for EditorConfig).
More getTokenContext is not perfect, for instance "root" is every time returned in the completion although it should be return only if completion is trigger outside a section.


Fully working example

@mgtitimoli I'm willing to submit a PR with my fully working example, would you like me to do that?
It's a real world use case, easy to understand and I believe could help people get started.
import { Component } from '@angular/core'
import * as AbsintheSocket from "@absinthe/socket"
import {Socket as PhoenixSocket} from "phoenix"

@Component({
  selector: 'page-home',
  templateUrl: 'home.html'
})
export class HomePage {

  order:any
  online:boolean = false
  notifier:any
  absintheSocket:any

  constructor() {
    this.absintheSocket = AbsintheSocket.create(
      new PhoenixSocket("ws://localhost:4000/socket", {params: { authToken: 'my-token' }})
    )
  }

  // <button (click)="startReceivingOrders()">Go online</button>
  startReceivingOrders() {
    const notifier = AbsintheSocket.send(this.absintheSocket, {
      operation: this.subscriptionGraph(),
      variables: {}
    })

    AbsintheSocket.observe(this.absintheSocket, notifier, {
      onAbort: this.onAbort.bind(this),
      onError: this.onError.bind(this),
      onCancel: this.onCancel.bind(this),
      onStart: this.onStart.bind(this),
      onResult: this.onResult.bind(this),
    })
  }

  // <button (click)="stopReceivingOrders()">Go offline</button>
  stopReceivingOrders() {
    this.absintheSocket = AbsintheSocket.cancel(this.absintheSocket, this.notifier)
  }

  private onStart(notifier) {
    console.log(">>> Start", JSON.stringify(notifier))
    this.notifier = notifier
    this.online = true
  }

  private onAbort(data) {
    console.log(">>> Abort", JSON.stringify(data))
    this.online = false
  }

  private onCancel(data) {
    console.log(">>> Cancel", JSON.stringify(data))
    this.online = false
  }

  private onError(data) {
    console.log(">>> Error", JSON.stringify(data))
    this.online = false
  }

  private onResult(res) {
    console.log(">>> Result", JSON.stringify(res))
    this.order = res.data.order
  }

  private subscriptionGraph() {
    return `subscription orders {
      order: orders {
        id
        price
      }
    }`
  }
}

Hi rafbgarcia,
As discussed in the other issue, it would be better for us to nudge people wanting to integrate with Angular / VueJs to use Apollo Client 2.X and our Apollo Link which is documented already.
We should definitely cover that in a guide but it will be hosted in our guides section on Absinthe project.

Btw thanks for helping @mgtitimoli identify some bugs and creating an issue for them.
As far as the documentation goes, give us a little bit more time and we should be able to provide a clear path for people who want to integrate with their js framework or otherwise guidance on how to contribute some guides in that regard.

No problem at all, y'all are the ones helping me here 😸  I can only thank you for helping me get  started :)

@rafbgarcia Thank you so much for your example, it turned out to be a lot more helpful than the documentation!


fix comments

one agent full, one lite: the full agent must take the controlling role, and the lite agent must take the controlled role

Nice catch! Thank you @zhngs


silx open takes very long for multiframe edf stacks

Dear all,
we have multiframe edf files with typically 516x516x20000 pixels.
To my experience, it takes very long to open these files simply with silx.open and using a small script based on silx.third_party.EdfFile is much faster. (also if I use it for conversion to h5)
Is it possible to use the third_party function to speed up silx.open and, this way, also silx view?
This would allow a fast inspection of scans during our measurements.

Hi.
silx.io.open to open EDF was not designed to be efficient, but to be NeXus compatible. Then, if you need efficiency, don't use it. Or use it to convert first your data to an h5 file, it was designed for that.
We maybe can improve small things here and there, but i am quite sure using EdfFile will not change anything to the efficiency.
BTW, if you want to create your own h5 file, i recommend you to read your EDF files using fabio.

Ok, using EdfFile for opening such an edf file takes 50sec on our gpu machine.
In contrast, I interrupted fabio.open after it tried for several hours. (One CPU core loaded and moderate memory usage).
Maybe that is the reason why also silx.open has this problem.
Furthermore, even though I can write my own script using EdfFile, it would be nice to be able to use the silx viewer.

If you have efficiency problem with fabio.open vs EdfFile it can be nice to take a look. Is there a way to access to your data, and to be able to check that?

To me it is worth to be able to load data files (edf, tiff, npy, npz) in silx view as is without converting multi-frames to stack and creating an ESRF-nexus-like structure so that silx view would be as slow as the data format is (but not more).
We've started discussing this with @vallsv, the conversion to the ESRF-nexus structure could be available as a command-line option or as a protocol hdf5://myfile.edf or any other alternative.

Thanks,
there are many data examples. The one I tested is here:
/data/id01/inhouse/UPBLcomm/BLC10810/blc10810/id01/GaN_IHP2/KMAP_2017_09_18_184734/mpx
just pick any of the edf files
For the benchmarking, I added:
%time im = EdfFile.EdfFile("kmap00001.edf.gz", fastedf=True)
%time a = np.stack((im.GetData(i) for i in xrange(im.NumImages)))
where EdfFile is silx.third_party.EdfFile.
I'm not really sure about the implications of fastedf though.
fabio.open did not succeed after few hours, as mentioned before

fastedf has no implications at all. It is ignored and kept for compatibility.

@t20100, @vallsv Fix the problem at the source (fabio) prior to think about dropping silx functionalities.

@sole I was not thinking about dropping silx functionalities but adding one: open image files as they are.

@t20100  In that case the default has to be the current behavior and not the other way around as proposed above.
A word of caution, sooner or later you will need to have to be able to select what to plot against what and you will want that selection to be applied to several "entries". The more uniform the access to the data the better.

This is related to https://github.com/silx-kit/fabio/issues/18
There is quick-fix: recompress your file so that there are no more 144000 gzipped blocks but only one: it heavily disturbs the python's gzip which is doing the loop at the Python level which takes ages.
zcat filename.gz |gzip -c > recompressed.gz
Re-writing helps really a lot !

Any idea why EdfFile does not suffer from the bug and if fabio could be optimized in this respect?

The issue comes from concatenating 144000 gzip blocks and pretend it is a single gzip. The bug affects only such kind of files. Python used to handle this in a very poor way.
FabIO measures the size of the file which causes the issue here.
Shall we put much effort into EDF as optimizing it would probably slow down the migration to HDF5 !

Removing measure_size looks to improve a lot the result on Python 2. Then i will try to patch FabIO in order to get ride of the use of the size of the decompressed buffer.
In [3]: filename = "../data/edf/id01_carsten_richter/kmap00001.edf.gz"

In [7]: %timeit ii = EdfFile(filename, fastedf=True); (ii.GetData(i) for i in range(ii.NumImages))
1 loop, best of 3: 22.5 s per loop

In [10]: %timeit ii = fabio.edfimage2.EdfImage(); ii.read(filename); (ii.getframe(i) for i in range(ii.nframes))
1 loop, best of 3: 22.8 s per loop

It should not. At least we have something as fast as EdfFile.

OK let's close it, please reopen if needed


Inlay hints eventually fail and require lsp server restart

After working on a project for a couple hours I have found on multiple occasions that inlay hints stop appearing. When I check :LspLog I see errors like the following:
[ERROR][2022-08-08 01:08:56] .../vim/lsp/rpc.lua:420  "rpc" "rust-analyzer" "stderr"  "::inlay_hints::inlay_hints
   4: std::panicking::try
   5: ide::Analysis::inlay_hints
   6: rust_analyzer::handlers::handle_inlay_hints
   7: std::panicking::try
   8: <F as threadpool::FnBox>::call_box
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace."

I have been able to resolve this when it occurs by running :LspRestart, though I would expect to not need to do this, ofc.
I have experienced this with the basic setup of the plugin, require('rust-tools').setup({})
Versions I am using:

rustc 1.61.0 (fe5b13d68 2022-05-18)
rust-analyzer 0.0.0 (897a7ec4b 2022-07-17)
rust-tools (11dcd674781ba68a951ab4c7b740553cae8fe671)
NVIM v0.7.2

I reported the same thing here: https://github.com/simrat39/rust-tools.nvim/issues/216
In my case a :LspRestart isn't enough to have them appear, and I have the same backtraces in :LspLog.
I end up in cases like this

Interesting, looks like something is happening over at rust analyser. Is there any other confirmed reproduction other than editing for a long time? Maybe a large amount of files or something like that?

Not sure if it is the same issue, but after updating this morning I'm having this error:
Error executing vim.schedule lua callback: ...acker/opt/rust-tools.nvim/lua/rust-tools/inlay_hints.lua:196: line value outside range
stack traceback:
        [C]: in function 'nvim_buf_set_extmark'
        ...acker/opt/rust-tools.nvim/lua/rust-tools/inlay_hints.lua:196: in function 'render_line'
        ...acker/opt/rust-tools.nvim/lua/rust-tools/inlay_hints.lua:226: in function 'render'
        ...acker/opt/rust-tools.nvim/lua/rust-tools/inlay_hints.lua:140: in function 'handler'
        ...neovim/HEAD-7ebcb9b_1/share/nvim/runtime/lua/vim/lsp.lua:1241: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

Interesting, looks like something is happening over at rust analyser. Is there any other confirmed reproduction other than editing for a long time? Maybe a large amount of files or something like that?

I can reproduce it right away after starting, no need to edit for a long time. The last video I posted shows me restarting nvim and displays the issue.

Interesting, looks like something is happening over at rust analyser. Is there any other confirmed reproduction other than editing for a long time? Maybe a large amount of files or something like that?

For me it was with a very small project in terms of my own source code (I am using a few crates, tho).

Should be fixed with https://github.com/simrat39/rust-tools.nvim/commit/2e9e47372930e66541a70b865fea167947b4d1da

Not sure if it is the same issue, but after updating this morning I'm having this error:
Error executing vim.schedule lua callback: ...acker/opt/rust-tools.nvim/lua/rust-tools/inlay_hints.lua:196: line value outside range
stack traceback:
        [C]: in function 'nvim_buf_set_extmark'
        ...acker/opt/rust-tools.nvim/lua/rust-tools/inlay_hints.lua:196: in function 'render_line'
        ...acker/opt/rust-tools.nvim/lua/rust-tools/inlay_hints.lua:226: in function 'render'
        ...acker/opt/rust-tools.nvim/lua/rust-tools/inlay_hints.lua:140: in function 'handler'
        ...neovim/HEAD-7ebcb9b_1/share/nvim/runtime/lua/vim/lsp.lua:1241: in function ''
        vim/_editor.lua: in function <vim/_editor.lua:0>

This should also be fixed, though its a bandaid fix for now, not sure why ra is sending a line which doesn't exist

Thanks, @simrat39!

Beautiful, it works! :)
thanks!


Make en translations in Android project default

Right now our pull config looks like this:
pull:
    targets:
    - {file: ./app/src/main/res/values-<locale_name>/strings.xml}

Which results in:

Downloaded en to app/src/main/res/values-en/strings.xml
Downloaded de to app/src/main/res/values-de/strings.xml
Downloaded vi to app/src/main/res/values-vi/strings.xml
Downloaded pl to app/src/main/res/values-pl/strings.xml
Downloaded ar to app/src/main/res/values-ar/strings.xml
Downloaded es to app/src/main/res/values-es/strings.xml
Downloaded id to app/src/main/res/values-id/strings.xml
Downloaded pt to app/src/main/res/values-pt/strings.xml
Downloaded ru to app/src/main/res/values-ru/strings.xml
Downloaded tr to app/src/main/res/values-tr/strings.xml
Downloaded zh to app/src/main/res/values-zh/strings.xml
Downloaded sv to app/src/main/res/values-sv/strings.xml

Is there any way to get en into app/src/main/res/values/strings.xml?
The problem is that if a translated string is only present in values-en and you use German for instance it can't find anything and the app will crash during testing.

Hi,
you could use a dedicated download target for the english locale:
  pull:
    targets:
    - file: ./app/src/main/res/values-<locale_name>/strings.xml
    - file: ./app/src/main/res/values/strings.xml
      params:
        locale_id: en

Hope that helps,
Gereon

That's sweet!
Thanks a lot @gfrey
One more question is there anyway to then exclude en from - file: ./app/src/main/res/values-<locale_name>/strings.xml?

No, sorry. You could of course manually give all the locales to download (like the en locale), but there is no possibility to exclude locales from a pull with placeholder target.

Hmm okay fair enough. Is there anything like this planned in the future?

I'll add a feature request to our backlog.

@gfrey thank you! Also another awesome feature would be a hook where you can just execute a script after the pull has been finished. In that script you could literally do everything.

It actually doesn't work with
- file: ./app/src/main/res/values/strings.xml
      params:
        locale_id: en

You have to use the locale_id you get from the locale preferences (which is some hexadecimal value).

@joernahrens well en worked for the OP as en was the name (not code!) of the locale he was pushing into. The locale_id parameter takes both PhraseApp's id (the hex string) or the name of the locale to push to.

Hi @gfrey
in my case enwas also the default locale, it was the exact same case. But with the configuration above the file values/strings.xml was not touched by phraseapp pull (didn't test push yet). It only worked as I changed it to the ID from the web configuration.

Hi @joernahrens
each locale has two "properties":

a name: Must be unique over all the project's locales, but can be an arbitrary string like English.
a code: A valid RFC5646 string like en-US. There could be more than one locale in PhraseApp with the same code!

In the above example name and code were equal, and therefore pulling with locale_id worked. Please make sure you're using the name of the locale!
If it still doesn't work make sure your client is up to date (phraseapp info with the latest version being 1.1.11).
Kind regards,
Gereon


[move-prover] use ghost types for uninstantiated global invariants

Not all type parameters in a generic global invariant can be instantiated when
instrumenting the invariant to a function. in #9545, we give warning on those
invariants but that is not enough, as these invariants are still silently considered
as verified. But in reality, these invariants may or may not hold. As shown in the
test case uninst_global_invariant.move.
Following is an illustration of the problem:
// function
fun incr_counter(account: &signer): u64 acquires BallotCounter {
  let addr = Signer::address_of(account);
  let counter = &mut borrow_global_mut<BallotCounter>(addr).counter;
  let count = *counter;
  *counter = *counter + 1;
  ^^^^^^^^^^^^^^^^^^^^^^^^
                          -- invariant is applicable here, but we
                          -- can’t find a proper instantiation for
                          -- the `Proposal` type parameter.
  count
}

// invariant
invariant<Proposal> forall ballot_address: address
  where exists<Ballots<Proposal>>(ballot_address):
    exists<BallotCounter>(ballot_address);

The solution is to automatically add a ghost type parameter to the
list of function type parameters. And the ghost type parameter is only
used to instantiate the invariant and is not used in the Move code.
fun incr_counter<T>(account: &signer): u64 acquires BallotCounter {
                ^^^
                   -- this is a ghost type parameter and is not used
                   -- in the body of `incr_counter` in the Move code.

  // instrumented entry-point assumption
  assume forall ballot_address: address
    where exists<Ballots<T>>(ballot_address):
      exists<BallotCounter>(ballot_address);

  let addr = Signer::address_of(account);
  let counter = &mut borrow_global_mut<BallotCounter>(addr).counter;
  let count = *counter;
  *counter = *counter + 1;
  ^^^^^^^^^^^^^^^^^^^^^^^^
                          -- the invariant can be instrumented here by
                          -- instantiation invariant<Proposal = T>

  // instrumented check
  assert forall ballot_address: address
    where exists<Ballots<T>>(ballot_address):
      exists<BallotCounter>(ballot_address);
  count
}

This solution is implemented in this PR.
Motivation
Fix a hole in the generic invariant implementation
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan

CI
The whole diem framework still verifies despite there are uninstantiated invariants in them.
Test cases are updated

/land


[Do not merge] [test] Modify bind9 (for DNS64) for K-D-C operation in a DinD environment

Verifying that #185 passes IPv6 tests

success :) closing.


libffi:x86-windows crashes since update to version 3.3 on february 7th

Describe the bug
I install gtkmm:x86-windows for use in an application. everything worked fine. But with commit 7d4227f02e445b0a29f8c1ce3258b57d60b71cfe libffi was upgraded to version 3.3. Since then my application crashes on every mouse click when returning from libffi assembler code (see debugger screenshot under "Failure Logs" below).
I assume, it has to do with the target x86-windows. The libffi src folder does not contain a  "win32.S" file any more, only a "win64.S"!
Environment

OS: Windows 10 Enterprise
Compiler: Visual Studio Professional 2019 16.4.5

To Reproduce
Steps to reproduce the behavior:

./vcpkg install gtkmm:x86-windows
build an application using gtkmm
click with mouse

I think it does not depend on gtkmm. I'm sure, a GTK3-application would also crash.
Expected behavior
I would expect no crash. This was the behaviour with libffi 3.1
Failure logs
Debugger screenshot

Additional context
The contents of the file vcpkg\installed\status:
installed-status.txt

I'm also having a similar issue but with GTK:
OS: Windows 10 x64
GTK: 3.22.2-2
Everything works fine in a release build, but when running a debug build I get a runtime error as soon as the application starts up.
The error is in function ffi_call_win64 which is called from ffi_call_int.
Screenshot:

Having the same issue here when using Gtk

Any updates on this? This is a complete blocker for debugging my application

Hi all,
Sorry for the late reply. I will check this issue later.
Could you please help confirm if this can work well before libffi updaed to 3.3?

@NancyLi1013 how can i install the older library version?

You can use git checkout commit id to checkout a new branch to the commit that the older library version was updated.

Any updates on this? This is a complete blocker for debugging my application

If you don't need to debug libffi then you can use the release build of it. That's what I did for now, just copied the release version and overwrote it in my app's output directory

This may be helpful in your actual painful situation. But it will not help to fix the general problem.
So please - in addition to this work around - follow Nancy's advice. If your application does not depend on newly added or modified packages it is not too hard. I myself did the following:

clone a new copy of vcpkg
create a new local branch from a commit before the commit commented "[libffi] Update to v3.3 release (#6119)". I decided to use the commit 7aebb481085de7387f8a9975652c26f9053f66df labeled "2020.01".
switch to the newly created branch
vcpkg install gtkmm (and libxmlpp because I need it for my application). Maybe you only need to install gtk.
rebuild the application (debug version) using the newly created packages.
try running it.
In my case, the difference ist obvious.

Here are two minimal example applications to reproduce the behavior. One is for gtk, the other one is for gtkmm. The msvs vcxproj... and props files provided with the two examples allow you to test debug and release builds  for 32 and 64 bit windows. You should unpack the two zip files to the directory where your vcpkg directory resides. this will lead to a directory layout like that:

GtkmmSampleForVcpkg
GtkSampleForVcpkg
vcpkg

The GtkmmSample presupposes, that you vcpkg install gtkmm for the target platforms you want to build and test. To build and test the GtkSample only vcpkg install gtk is needed.
I've tested all variants with both libffi 3.3 (commit 7d4227f02e445b0a29f8c1ce3258b57d60b71cfe) and libffi 3.1 (the commit immediately before 8eaa597bba70728c70feb4674566abcbe6feeb5c).
Both example apps crash in the debug builds with libffi 3.3 on both target platforms.
Hope this helps solving the issue.
GtkmmSampleForVcpkg.zip
GtkSampleForVcpkg.zip

@rglbssw
Thanks for your update and detail information about this issue.
I will try to reproduce according to the projects you provided above.

@rglbssw
I have tested and this issue can be reproduced on my local now.
It seems that this issue is only happened in debug type.
We will go further investigation about this.

@NancyLi1013 yes it only happens in debug builds as @itayzafrir mentioned. Great you can reproduce this now!

@NancyLi1013 it seems that in x86-windows debug mode, in function ffi_call_int, call to _alloca leads to a failure in _RTC_CheckStackVars2, because %rsp is recovered when the ffi_call_int function return, which is after call to _RTC_CheckStackVars2. avoid using _alloca can help.

@764994703
Thanks for your deep investigation about this.
We will try to look into it.

I think that's a Visual Studio bug.

Following the suggestions of  @rglbssw  and @NancyLi1013 I checkout to the commit tagged 2020.01 where libffi:x64-windows 3.1-7 is installed.  I do confirm that the .exe executes normally in debug mode with this version of the library.  In the older version libbffi was installed as a static library only (and so there is no export of the dll into the application's directory),  whereas in the newer version 3.3-2 libffi is installed as a both static and dynamic one also.  May be a workaround would be to compile libffi 3.3-2 as a static lib only ?

Following the suggestions of @rglbssw and @NancyLi1013 I checkout to the commit tagged 2020.01 where libffi:x64-windows 3.1-7 is installed. I do confirm that the .exe executes normally in debug mode with this version of the library. In the older version libbffi was installed as a static library only (and so there is no export of the dll into the application's directory), whereas in the newer version 3.3-2 libffi is installed as both static and dynamic. May be a workaround would be to compile libffi 3.3-2 as a static lib only ?

Allowing shared DLL is needed because vcpkg only supports dynamic DLL on Windows ARM. (insane, I know) We should be able to let it build only static lib on x86/x64.

I have the same issue when using gtkmm

Yep, experiencing the same issue. Had to run my College Project in release mode to avoid this. The libffi call is optimized away in release mode (resulting in a lot less assembly code) and also does not corrupt the stack. Maybe a memory allocation / re-allocation issue as @764994703 said.. I gave up trying to figure out the root cause... glad I found this thread !!

hello
I've got the same problem
Windows 7 pro
Visual Studio 2019 Community
x64
debug mode
soo sad ... I really hope a fix

hello
I'm surprized: dependency walker seems to find that the vcruntime is ... 140 Oo' (for both, release [who is working] and debug)
Is that normal ? I expected something like 142 to be honest for vs2019 ... [sorry if I say something stupid]
Is that related for the crash or nothing at all ?

Hi all,
Could you please rebuild this based on the PR #12498 from @Mixaill ?
After disabling runtime stack check for libffi, I cannot reproduce this issue on my local now.

@NancyLi1013 just checked on my own project - all works fine!

Works fine for x64-windows. I tried to extend the solution for x86-windows (see https://github.com/microsoft/vcpkg/pull/12498#issuecomment-662498095).

[Newbie Question]: Shouldn't we find out what caused the Stack Corruption instead of disabling the Runtime Check? I don't mean to offend / belittle the work done by @Mixaill and @rglbssw , but I would like to know what caused the Stack to be corrupted in the first place.
According to Microsoft Docs, one of the reasons /RTC fails is due to a calling convention mismatch. I have tried setting different calling conventions like _stdcall or _cdecl , but the crash persists. The other reasons include overruns / under-runs of memory; Padding issues with Struct Member Alignment ( /Zp ), which I am currently looking into..

@Ajax-Light It's a Visual Studio bug.

Shouldn't we find out what caused the Stack Corruption instead of disabling the Runtime Check?

It is the intended behavior for libffi, it modfies stack of the caller function which results in RTC trigger. No actual error here.

Ah! I understand now. Thanks for your time. 👍

Thanks to all at any place!
Especially I'd like to praise:
@Mixaill who broke the Gordian knot
and @NancyLi1013  who tamed the wild blue bot
in its azure pipeline maze.
(... e grazie a la @strega-nil)

It is still happening for me, do I need to do something to apply the fix?

Seems as if the patch was not applied already. The code would look a bit different, if it was.
Did you do a "vcpkg upgrade" after pulling?
If you tried the pull request before it was merged, especially if you did that before it contained the x86-windows patch, it is possible, that vcpk doesn't recognize the package as outdated. In this case you should vcpkg remove the package and vcpkg install it again. If vcpkg decides to restore it from a cached version, delete the cached version and try it again.

Have installed with gtkmm as root package. Same issue. x64-windows.


Create da.json

Added Danish local.
No idea how to translate this part:
        "waxingCrescentMoon": "Waxing crescent",
        "waxingGibbousMoon": "Waxing gibbous",
        "waningCrescentMoon": "Waning crescent",
        "waningGibbousMoon": "Waning gibbous"

@ngocjohn Looks good 👍


Android Basics: Navigation backstack

[URL of codelab]
https://developer.android.com/codelabs/basic-android-kotlin-training-navigation-backstack?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-kotlin-unit-3-pathway-4%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-training-navigation-backstack#5
In which task and step of the codelab can this issue be found?
kotlin.UninitializedPropertyAccessException: lateinit property navController has not been initialized
Step 3: Implement the Up button behavior
Describe the problem
going back to the previous activity gives out the error
Steps to reproduce?

Run the app
Click on any button
Click on the back button
It goes to crash

Versions
Android Studio version: Android Studio Electric Eel | 2022.1.1
API version of the emulator: 33
Additional information
Include screenshots if they would be useful in clarifying the problem.

Issue is solved... I managed to fixed it


literalMidWordUnderscores causes full sentences to be bolded

I would expect the behavior of literalMidWordUnderscores to only affect underscores attached to non-space characters.
Example:
some text with__underscores__in middle where __ is used without spaces between words.
Actual Behavior:
If literalMidWordUnderscores is true then all text between two separate bolded words gets bolded.
__Once upon a time__, there was a little girl named __Goldilocks__.
Expected: Once upon a time, there was a little girl named Goldilocks.

bug introduced in 1.6.4
Once upon a time, there was a little girl named Goldilocks.


Update the NVM module

This PR updates the NVM module:

Update the code to use standard methods like .position(), .get, or .fold().
Update the comments and naming conventions
Modify some return values to Option and Result to avoid panicing at runtime as much as possible :)

cc @kingofpayne


Only publish to latest on tags

I also mentioned this in discord, but it seemed like a small enough PR that I could just submit it and start a discussion here.
Woodpecker currently publishes to :latest on every push to master and new tags, however the general consensus around the Docker community seems to be that :latest should usually refer to the latest stable version. This PR removes publishing to latest on pushes to master (because :next still exists).
I personally prefer this behavior in this PR, but is there a reason to stick with the current behavior?

Can be merged when v0.15.0 is in feature freeze (not jet here)

Suggested edit:
diff --git a/docs/docs/80-downloads.md b/docs/docs/80-downloads.md
--- docs/docs/80-downloads.md
+++ docs/docs/80-downloads.md
@@ -6,11 +6,11 @@

 ## Docker images

 Image variants:
-* The `next` images are based on the current master branch
-* The `latest` is same as next (will change after v0.15.0 release to be latest stable release)
+* The `latest` image is the latest stable release
 * The `x.x.x` version images are stable releases
+* The `next` images are based on the current master branch and should not be used for production environments

 ``` bash
 # server
 docker pull woodpeckerci/woodpecker-server:latest

@belak :point_up:

Good call - I've pushed a commit with the updated docs


Adjust Cycle Count App Logic for Damaged Item Quantities

What is the motivation for adding/enhancing this feature?
Currently, the logic in the cycle count app adds quantities to inventory when store associates input the quantity of damaged items during the variance process. However, this behavior is counterintuitive and may lead to incorrect inventory adjustments. To improve usability and accuracy, we need to adjust the logic so that when associates input the quantity of damaged items, it deducts the specified quantity from inventory rather than adding it.
What are the acceptance criteria?

[ ] ...

Can you complete this feature request by yourself?

[ ] YES
[ ] NO

Additional information

Client quote:
As a store associate, if I scan an item through the cycle count app> toggle to “variance” > variance reason = damaged> if i input the qty of “1”, in the backend it should remove 1 from my inventory, not add one.

It is more intuitive for the associates to put the damaged qty/they will assume the qty they input will be damaged out, and likely will not remember to indicate -1 when using the app to damage out.

Closing as the app has been revamped and the whole process has been changes, and we will be updating the app soon.


espanso-alpha: Add version v2.1.3-alpha

Adds alpha version of espanso

[x] I have read the Contributing Guide.

Use the portable version

Use the portable version

@tech189 can you open a new superseding PR with your suggestions?


Fix typo liveliness -> liveness

Add mdspell dependency to gem installations

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: linsun
Assign the PR to them by writing /assign @linsun in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @sanketjpatel. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

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

/assign @linsun


Resource Error with a learnt model.

Hi, thank for developing very useful user-friendly library. I have tried to run STT with the following code. However, I wasn't able to finish the code due to Resource error. I found that usage of memory increased to 200GB with htop command.
Environment

CentOS-7
python 3.7.9
pytorch 1.7.1
cudatoolkit 10.2
espnet 0.9.6
espnet-model-zoo 0.0.0a20
4 gpus
80 cpus
300GB RAM

#!/usr/env/python
import soundfile as sf
from espnet_model_zoo.downloader import ModelDownloader
from espnet2.bin.asr_inference import Speech2Text

d = ModelDownloader()
info = d.download_and_unpack(task='asr', corpus='csj')
speech2text = Speech2Text(
    **info)

wav, fs = sf.read("./A02F0116.wav") # csj wav file
text, token, *_ = speech2text(wav)[0]
print(text)

This is because your input wav is too long.
Please consider the split of the input wav file.


ActionView::Template::Error in admin/university/organizations#edit

Error in Osuny
ActionView::Template::Error in admin/university/organizations#edit
Missing partial admin/application/shared_image/_edit with {:locale=>[:fr], :formats=>[:html], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :axlsx, :jbuilder]}.
Searched in:

"/app/app/views"
"/app/vendor/bundle/ruby/3.3.0/bundler/gems/two_factor_authentication-a3505e961baf/app/views"
"/app/vendor/bundle/ruby/3.3.0/gems/pghero-3.6.1/app/views"
"/app/vendor/bundle/ruby/3.3.0/gems/kaminari-core-1.2.2/app/views"
"/app/vendor/bundle/ruby/3.3.0/gems/kamifusen-1.12.0/app/views"
"/app/vendor/bundle/ruby/3.3.0/gems/good_job-4.5.0/app/views"
"/app/vendor/bundle/ruby/3.3.0/gems/faceted_search-3.6.2/app/views"
"/app/vendor/bundle/ruby/3.3.0/gems/devise-i18n-1.12.1/app/views"
"/app/vendor/bundle/ruby/3.3.0/gems/devise-4.9.4/app/views"
"/app/vendor/bundle/ruby/3.3.0/gems/bootstrap5-kaminari-views-0.0.1/app/views"

View on Bugsnag
Stacktrace
app/views/admin/university/organizations/_form.html.erb:25 - block (2 levels) in _app_views_admin_university_organizations__form_html_erb___560535767391450489_719100
app/views/admin/university/organizations/_form.html.erb:2 - block in _app_views_admin_university_organizations__form_html_erb___560535767391450489_719100
app/views/admin/university/organizations/_form.html.erb:1 - _app_views_admin_university_organizations__form_html_erb___560535767391450489_719100
app/views/admin/university/organizations/edit.html.erb:2 - _app_views_admin_university_organizations_edit_html_erb__3393346440705803535_719080
app/controllers/application_controller/with_locale.rb:19 - switch_locale

View full stacktrace
Created automatically via Bugsnag

An error linked to this issue has been reopened in Bugsnag
ActionView::Template::Error in admin/university/organizations#edit


Run CI on a regular basis

Refs: https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onschedule

bors r+


Merge next to lwaftr

This replaces our "headroom" mechanism with a sliding struct packet.  We
also update our virtq changes appropriately, which have not yet landed
upstream.

LGTM


memory: Add safe_host_allocator and deprecate safe_pinned_host_allocator

The host memory allocator class called safe_pinned_host_allocator suggests that memory will always be pinned. Since there is an OpenMP backend now, this does not hold anymore and is more of an implementation detail anyways. Furthermore, this is inconsistent with the device (safe_device_allocator) and managed (safe_managed_allocator) variants. Rename it to safe_host_allocator and keep the old version (marked as deprecated) to maintain compatibility.

Build failure is unrelated to the changes. Thus, ready to merge.


New version: BrettMayson.HEMTT version 1.7.1

Pull request has been created with WinGet Releaser v2 :rocket:
Microsoft Reviewers: codeflow:open?pullrequest=https://github.com/microsoft/winget-pkgs/pull/112745&drop=dogfoodAlpha

@microsoft-github-policy-service agree

@wingetbot waivers Add Validation-Executable-Error

@wingetbot run


Page changed from static to dynamic at runtime /dashboard, reason: unstable_noStore()

Context: Just Finished Chapter 15
After logging in successfully, I am redirected to the dashboard route as expected.
However, when the app is deployed to my Vercel instance I receive the following error messages in logs.

[GET] /dashboard status=500

Page changed from static to dynamic at runtime /dashboard, reason: unstable_noStore()
see more here https://nextjs.org/docs/messages/app-static-to-dynamic-error
   at s (/var/task/.next/server/chunks/943.js:2:48780)
   at i (/var/task/.next/server/chunks/217.js:1:6641)
   at i (/var/task/.next/server/chunks/158.js:1:2291)
   at w (/var/task/.next/server/app/dashboard/(overview)/page.js:2:2519)
   at eh (/var/task/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:134786)
   at e (/var/task/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:137671)
   at ek (/var/task/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:138145)
   at Object.toJSON (/var/task/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:135755)
   at stringify (<anonymous>)
   at eR (/var/task/node_modules/next/dist/compiled/next-server/app-page.runtime.prod.js:12:142219) {
 page: '/dashboard'
}

Error: Runtime exited with error: exit status 1

Note: Functionality doesn't appear to be impacted. I'm mostly just curious if there's a reason this happens or a way to fix it.
The potential fix I found was export const dynamic = 'force-dynamic'. Unfortunately, I have not been able to confirm it works yet.
Though, to me, that feels more like a workaround than an actual fix and of course I could be wrong about that.
I have yet to see these errors when running in my local environment and it doesn't seem to impact performance of the app. Everything continues to work as far as I can tell.
I did a rollback to (Chapter 14) before I added the login functionality, and the errors don't appear in logs anymore when visiting the dashboard page.
The previous deployment I rolled back to was using Next v14.2.2 and the new one is 14.2.3.  and node 18.x instead of node 20.x
Not sure if that's totally relevant but figured it would be worth mentioning.
Edit: I just noticed another 500 error logged on sign out.
Unhandled Rejection: TypeError [ERR_INVALID_STATE]: Invalid state: Controller is already closed
at ReadableStreamDefaultController.enqueue (node:internal/webstreams/readablestream:1073:13)
at fetchParams.controller.resume (node:internal/deps/undici/undici:10897:45)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
code: 'ERR_INVALID_STATE'
}
Node.js process exited with exit status: 128. The logs above can help with debugging the issue.
Unknown application error occurred.

Fixed here: https://github.com/vercel/next-learn/pull/764


Test Add test cases for external table statistics (#26511)

Test for close and open auto collection for external catalog.
Test for analyze table table_name (column) and whole table.

Proposed changes
Issue Number: close #xxx

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall


feat(LiveServer): add .wasm support

Code derived from https://github.com/tapio/live-server/pull/316/files

No longer applicable.


fix: bug 2382 expected entity and reprompt are mutually exclusive

What's the messaging for these features?
I thought it was advised to use "reprompt" for actions representing question? So they could automatically reprompt.
And yet we also say to use expected entity for these actions representing questions where the user input is likely an answer.
It seems there guidance that both these features should be used in this sutation and yet they are not compatible.

Agree that it's potentially confusing and hopefully when we get context from LUIS this issue will go away.  The problem with the current implementation is that the behavior of Expected Entity is: "if nothing is labelled by LUIS, assume the result is the Expected Entity", whereas reprompt shows a reprompt action when the result is out of domain.   If Expected Entity is set nothing is out of domain.

Yes, I know why they are mutually exclusive. I believe I was one who opened the bug. I'm saying we should make it distinct when to use expected entity and when to use reprompt.

Where would you propose to add that messaging?   (If things align with LUIS we'll resolve this issue before launch.)

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

npm package (@next dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

I'm not sure I understand why the location of the messaging matters more than the contents of the messaging, I would put it in the UI with the rest of the messaging.

What would you propose for the messaging?  I don't think there's a clear explanation we can give at the moment.

What's the messaging for these features?

That's what I asked you originally and then you ask me the same thing.  It sounds like "We don't have clear explanation of when to use each feature." and that is the answer. They're both recommended for the same scenario and yet not compatible. It's confusing and complex. Hopefully we use the new LUIS features soon to fix it.

I'm asking you because I don't think think there is a clear explanation we can give.  If you have one, let's add it, otherwise let's hold off until we have a better solution


A11y_Target size minimum (24*24) for the controls "Delete Connection" is failed.

"Check out Accessibility Insights! - Identify accessibility bugs before check-in and make bug fixing faster and easier.”
Please do not close this bug. This bug should only be closed by TCS, C+AI Accessibility tester after bug verification.
GitHub Tags:
#A11yMAS; #A11yTCS; #A11ySev2; #DesktopApp; #BM-AzureDataStudio-Win32-Feb2022; #Azure Data Studio; #Win32; #Win11; #WCAG2.5.8; #FTP; #A11yWCAG2.2; #TargetSize;
Environment and OS details:
Azure Data Studio Version: 1.48.0 (user setup)
Windows 11 pro Version 23H2
OS build 22631.3296
Repro Steps:

Launch Azure Data Studio.
Tab to the Connections icon and press enter to select (if not already selected) from left bar.
Tab to any server from the Servers view let and tab to "Delete connection" button.
Run AI4D tool and Inspect "Delete connection" button.
Observe "Bounding rectangle" size is less than 24 * 24.

Actual Result:
Target size minimum (24*24) for the controls "Delete Connection" is failed. For the control "Delete Connection" button here l=250, t=299, r=272, b=322 now using formula (b-t) * (r-l): (322-299) * (272-250) = 23 * 22 which is less than 24 * 24.
Expected Result:
Target size minimum (2424) for the controls "Delete Connection" should not failed. For control minimum target size should be 2424 CSS Pixels. as the items are very next to each other the boundaries of each item's 24*24px should not intersect with the other one.
User Impact:
Users with mobility or fine motor control impairments will not be able to accessible or select the button properly.
Attachment:

Primary bug: https://github.com/microsoft/azuredatastudio-mysql/issues/235


Translate performance-and-scalability/synthetic-benchmarks into Chinese

original code
original page

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: xiaosuiba
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: gyliu513
Assign the PR to them by writing /assign @gyliu513 in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

content_zh/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Hi @xiaosuiba. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
I understand the commands that are listed here.

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

Deploy preview for preliminary-istio failed.
Built with commit cc49d31f00c74da23858f30bde16a326f07f47af
https://app.netlify.com/sites/preliminary-istio/deploys/5b3c2eb53813f024b6f16e3a

This file has been merged to content_zh/docs/concepts/performance-and-scalability/index.md, I'll just close it.


Widget font size too high as a function of the Android font size

Checklist

[X] I have used the search function to see if someone else has already submitted the same feature request.
[X] I will describe the problem with as much detail as possible.
[X] This issue only contains a request for one single feature, not multiple (related) features.

App version
6.802
Problem you are trying to solve
If we choose a font size a little bit higher than the default in the Android parameters, the font size used in the widget is too high for the title and for the emails. The Samsung Email widget is more correct on this point.
Suggested solution
The font size used in the widget should be smaller.
Screenshots / Drawings / Technical details
No response

Can you provide a screenshot for this?

Current widget:

Proposal:


No callback for transaction with state purchased.

Version of react-native-iap
2.4.7
Version of react-native
0.57.8
Platforms you faced the error (IOS or Android or both?)
iOS
Actual behavior
its my first IAP test and i need help.
When I purchase the product i still purchased (Sandbox) I get "You allready buyed this product. The product will be restored." But i get no callback or return. How can i handle this restoring process so i can save the purchased state and the User can use the Product?
Or does'nt it work this way?
My Code
   const purchase = await RNIap.buyProduct(identifier);
    this.setState({
      receipt: purchase.transactionReceipt
    });
this._saveProductIsBuyed()

Tested environment (Emulator? Real Device?)
Real device (iPad)
Thanks for help

@Finneah You are not understanding the iap feature correctly.  Restore purchase is to get products you've already purchased in other device when you reinstalled the app. To re-buy the item you should create product as consumable.

Hello @hyochan
thank you for answering so fast.
I don't think i missunderstood it. I think i did'nt explain it exactly:
Use-Case:
user can buy a product (one-time purchase for example 'Premium')

user buys this product.
user install the App on another device (same Apple ID)

Now, i have seen it on other Apps:
Product is not showed as buyed (because i don't want to ask for already buyed products at App-Start, as i said, i have seen it on other Apps)
3. user clicks on "buy product"
4. Alert "alredy buyed" is viewed and the Message that the purchase will be restored is showed.
But nothing happens.
For this i need a return that the Product is restored but i do not get anything  and the next console.log is not showed.
const purchase = await RNIap.buyProduct(productIdentifier);
console.log('TEST', purchase); <= will not be shown


[Feature Request] Bert Model support / encoder

🚀 Feature

Support inference of Bert Architecture models.
I am aware of this potentially heavy request. It would be great to have inference of Bert/Roberta/.. Encoder models, for the use in embeddings and frameworks such as michaelfeil/infinity.
Motivation

Alternatives

Additional context

@michaelfeil I would like to ask if there is any new progress in this, I also have such a need.