FTPS Connection

I can not login ftps (ftp with ssl) server. How can i make TLS acceptence?

I think even I am facing the same issue. I am getting this error,
nil, error: Optional(Error Domain=kCFErrorDomainCFNetwork Code=200 "(null)" UserInfo={kCFFTPStatusCodeKey=534})
Can you please suggest on how to deal with this?

Upload not working in Xcode8. Could you please fix that?

could you fix it? i have the same problem

Hi,
It doesn't work for FTPS.
Regards,
Shorabh Dhandharia
+1-312-678-9422
On Mon, May 29, 2017 at 11:36 AM, juanjoserodrigolazaro <
<EMAIL_ADDRESS>wrote:

could you fix it? i have the same problem
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Constantine-Fry/rebekka/issues/2#issuecomment-304698064,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANSqr6zmxGt_HnYi4ZNG7bLyqiqF71ybks5r-vQqgaJpZM4FqB8f
.


iOS NullPointerException

I'm currently running RoboVM version 1.1.0 and gdx-pay version 0.4.0.
Please let me know if you'd like more information.
2015-05-18 18:48:29.771 IOSLauncher[431:40159] [debug] IOSApplication: iOS version: 8.3
2015-05-18 18:48:29.773 IOSLauncher[431:40159] [debug] IOSApplication: Running in 32-bit mode
2015-05-18 18:48:29.786 IOSLauncher[431:40159] [debug] IOSApplication: scale: 2.0
2015-05-18 18:48:29.872 IOSLauncher[431:40159] [debug] IOSApplication: Unscaled View: LandscapeRight 568x320
2015-05-18 18:48:29.873 IOSLauncher[431:40159] [debug] IOSApplication: View: LandscapeRight 1136x640
2015-05-18 18:48:29.873 IOSLauncher[431:40159] [debug] IOSGraphics: 1136.0x640.0, 2.0
2015-05-18 18:48:30.197 IOSLauncher[431:40159] [debug] IOSGraphics: Display: ppi=326, density=2.0375
2015-05-18 18:48:30.607 IOSLauncher[431:40159] [debug] IOSApplication: created
2015-05-18 18:48:30.919 IOSLauncher[431:40159] [debug] didBecomeActive: Returning from: fb
2015-05-18 18:48:30.920 IOSLauncher[431:40159] [debug] IOSApplication: resumed
Loading class 'java.util.logging.ConsoleHandler' failed
java.lang.ClassNotFoundException: java.util.logging.ConsoleHandler
2015-05-18 18:48:32.988 IOSLauncher[431:40159] [info] IAP: IAP: gdx-pay successfully instantiated.
[GdxPay/AppleIOS] Installing purchase observer...
[GdxPay/AppleIOS] Requesting products...
[GdxPay/AppleIOS] Products successfully received!
[GdxPay/AppleIOS] Purchase observer successfully installed!
java.lang.NullPointerException
	at com.badlogic.gdx.pay.ios.apple.PurchaseManageriOSApple$AppleTransactionObserver.updatedTransactions(PurchaseManageriOSApple.java)
	at org.robovm.apple.storekit.SKPaymentTransactionObserver$ObjCProxy.$cb$paymentQueue$updatedTransactions$(Unknown Source)
	at org.robovm.apple.uikit.UIApplication.main(Native Method)
	at org.robovm.apple.uikit.UIApplication.main(UIApplication.java)
	at com.company.game.IOSLauncher.main(IOSLauncher.java)

The error object here is null:
https://github.com/libgdx/gdx-pay/blob/master/gdx-pay-iosrobovm-apple/src/com/badlogic/gdx/pay/ios/apple/PurchaseManageriOSApple.java#L364

That's odd that the error object is "null". I uploaded a new SNAPSHOT-release which check if the error object is null, i.e. it shouldn't crash anymore if that is the case.
In any case, there might be something more to it than just the error object being null? Let me know how it goes.

So, upon doing a little more testing (and working around), this issue may be more of an edge case than I originally thought. I can only reproduce it when I am testing an unreviewed app on my device while logged in using an Apple ID that is not designated as a Sandbox Tester in iTunes Connect.
If I am not logged in, this doesn't happen. If I am logged in as a Sandbox Tester, this doesn't happen. Your change does fix it for me and is probably worth keeping. I haven't come across any other NPE's.
Nonetheless, this issue is now resolved for me, so I'll go ahead and close this.


ftrace: Support trace-cmd record mode

The current implementation of the FtraceCollector only supports using ftrace in its start-stop mode which keeps the traces in memory and then writes to file at the end. Trace-cmd also supports a different mode - record which writes to file periodically meaning that it allows recording traces that would exceed the 'start' mode buffer size in exchange for added noise.
This commit adds support for selecting which mode trace-cmd should be run in. It adds a new collector parameter - 'trace_cmd_mode' which is used to distinguish between the two approaches.
While at it, it also cleans up the collector in some places, e.g. the teardown() method.

I pushed an update to make the entire collector just use a tempdir inside the working
directory from the start for both modes. If nothing else it'll make it more
self contained.

Updated to wait until the background command actually exits after sending
SIGINT - otherwise there's a race condition with removing the temp directory in
the teardown() method.

Pending on: https://github.com/ARM-software/devlib/issues/645


Honour SCARB_UI_VERBOSITY in cairo-run extension

Originally posted by @maciektr in https://github.com/software-mansion/scarb/pull/587#discussion_r1301461844

fixed in #1245


✨ Output details of invocation for consumption

JIRA: https://issues.jboss.org/browse/RAINCATCH-583

@david-martin @paolobueno @wojta would you like to take a look at this? The first commit is just a bunch of eslint warnings that emacs fixed on saving the file. The second commit is the important one: my hope is that I can then more easily have a script to pull this information from the summary.json file that gets created, so that it can easily be put into a spreadsheet or wherever.

I've added a new commit that adds the start and end times as distinct fields. These are the values that the existing duration field is calculated from. The duration field is left in place for compatibility.

Published as 1.0.2.

@paolobueno yeah, if there's an eslint config in the project, it will try to fix as many warnings and errors that it can automatically. I guess eslint --fix might be able to fix some or all of them. It's possible that emacs can fix more, I'm not sure! :)


Fix for #453 (windows os.path)

Description
Fix signature of os.path
GitHub Issues
Fix for https://github.com/Miserlou/Zappa/issues/453

Coverage remained the same at 78.733% when pulling f0eb67efd7625ffe5de47fe73d2fedd44cecd001 on Benoss:patch-1 into 02a440d8f06bcf6978141777f6eb72893879295e on Miserlou:master.


nrfutil 6 is not compatible with aarch64

Building the container on aarch64 results in nrfutil 5.2.0 being installed, which cannot run under python3 and fails.
sudo docker run --rm nrfconnect-sdk nrfutil version
nrfutil version 5.2.0

Doing the same under amd64 results in nrfutil 6.1.7.

Can you try the change in #27 and see if that works for you?
Right GitHub Actions only supports x86_64 architecture, so I cannot test this automatically.

That seems to break the build.
upgrading shared libraries...
installing nrfutil from spec 'nrfutil>=6.0.0'...
Fatal error from pip prevented installation. Full pip output in file:
    /opt/pipx/logs/cmd_2022-10-10_08.25.27_pip_errors.log

pip seemed to fail to build package:
    nrfutil>=6.0.0

Some possibly relevant errors from pip install:
    ERROR: Cannot install nrfutil==6.0.1, nrfutil==6.1.0, nrfutil==6.1.1, nrfutil==6.1.2, nrfutil==6.1.3, nrfutil==6.1.4, nrfutil==6.1.5, nrfutil==6.1.6 and nrfutil==6.1.7 because these package versions have conflicting dependencies.
    ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts
Error installing nrfutil from spec 'nrfutil>=6.0.0'.

Ran the pipx command outside of a container build to get the log:
----------
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Collecting nrfutil>=6.0.0
  Using cached https://www.piwheels.org/simple/nrfutil/nrfutil-6.1.7-py3-none-any.whl (898 kB)
  Downloading https://www.piwheels.org/simple/nrfutil/nrfutil-6.1.6-py3-none-any.whl (898 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 898.0/898.0 kB 1.1 MB/s eta 0:00:00
  Downloading https://www.piwheels.org/simple/nrfutil/nrfutil-6.1.5-py3-none-any.whl (898 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 898.0/898.0 kB 2.7 MB/s eta 0:00:00
  Downloading https://www.piwheels.org/simple/nrfutil/nrfutil-6.1.4-py3-none-any.whl (897 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 897.9/897.9 kB 2.7 MB/s eta 0:00:00
  Downloading https://www.piwheels.org/simple/nrfutil/nrfutil-6.1.3-py3-none-any.whl (896 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 896.7/896.7 kB 3.0 MB/s eta 0:00:00
Collecting pyyaml
  Using cached PyYAML-6.0-cp39-cp39-manylinux_2_17_aarch64.manylinux2014_aarch64.whl (731 kB)
Collecting pyspinel>=1.0.0a3
  Using cached https://www.piwheels.org/simple/pyspinel/pyspinel-1.0.3-py3-none-any.whl (65 kB)
Collecting intelhex
  Using cached https://www.piwheels.org/simple/intelhex/intelhex-2.3.0-py2.py3-none-any.whl (50 kB)
Collecting ecdsa
  Using cached https://www.piwheels.org/simple/ecdsa/ecdsa-0.18.0-py2.py3-none-any.whl (142 kB)
Collecting crcmod
  Using cached crcmod-1.7-cp39-cp39-linux_aarch64.whl
Collecting tqdm
  Using cached https://www.piwheels.org/simple/tqdm/tqdm-4.64.1-py2.py3-none-any.whl (78 kB)
Collecting protobuf
  Using cached protobuf-4.21.7-cp37-abi3-manylinux2014_aarch64.whl (403 kB)
Collecting piccata
  Using cached https://www.piwheels.org/simple/piccata/piccata-2.0.1-py3-none-any.whl (21 kB)
Collecting libusb1==1.9.3
  Using cached https://www.piwheels.org/simple/libusb1/libusb1-1.9.3-py3-none-any.whl (60 kB)
Collecting click
  Using cached https://www.piwheels.org/simple/click/click-8.1.3-py3-none-any.whl (96 kB)
Collecting pyserial
  Using cached https://www.piwheels.org/simple/pyserial/pyserial-3.5-py2.py3-none-any.whl (90 kB)
Collecting nrfutil>=6.0.0
  Downloading https://www.piwheels.org/simple/nrfutil/nrfutil-6.1.2-py3-none-any.whl (896 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 896.7/896.7 kB 1.1 MB/s eta 0:00:00
  Downloading https://www.piwheels.org/simple/nrfutil/nrfutil-6.1.1-py3-none-any.whl (896 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 896.7/896.7 kB 2.3 MB/s eta 0:00:00
Collecting libusb1
  Using cached https://www.piwheels.org/simple/libusb1/libusb1-3.0.0-py3-none-any.whl (62 kB)

The conflict is caused by:
    nrfutil 6.1.7 depends on pc-ble-driver-py>=0.16.4
    nrfutil 6.1.6 depends on pc-ble-driver-py>=0.16.4
    nrfutil 6.1.5 depends on pc-ble-driver-py>=0.16.4
    nrfutil 6.1.4 depends on pc-ble-driver-py>=0.16.4
    nrfutil 6.1.3 depends on pc-ble-driver-py>=0.16.1
    nrfutil 6.1.2 depends on pc-ble-driver-py==0.16.2
    nrfutil 6.1.1 depends on pc-ble-driver-py>=0.16.1

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

PIP STDERR
----------
ERROR: Cannot install nrfutil==6.1.1, nrfutil==6.1.2, nrfutil==6.1.3, nrfutil==6.1.4, nrfutil==6.1.5, nrfutil==6.1.6 and nrfutil==6.1.7 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/topics/dependency-resolution/#dealing-with-dependency-conflicts

And this is basically https://github.com/NordicSemiconductor/pc-ble-driver-py/issues/193 and https://github.com/NordicSemiconductor/pc-ble-driver-py/issues/227.

Seems like the only viable path would be to either run the old version under python2, or ignore that dependency and declare that some functionality will be missing, or try to automate a from-source build process (maybe inspired by https://github.com/NordicSemiconductor/pc-ble-driver/pull/271#issuecomment-1043869606).

I guess the solution for now would be to provide nrfutil v5 for arm64 and v6+ for amd64. Building v6 from source for arm64 which we cannot test here is not a thing I would want to do right now.
Let's hear what @gregersrygg has to say as well, he is working on a Mac.

I guess™ btw. that the way forward is not a PyPi release of nrfutil for arm64, because today you can use the Toolchain manager to install all the necessary tools. However this does not help today, in case you need nrfutil for CI/CD.

Closed PR #28, because nrfutil 5 does not work with Python 3.

I guess™ btw. that the way forward is not a PyPi release of nrfutil for arm64, because today you can use the Toolchain manager to install all the necessary tools. However this does not help today, in case you need nrfutil for CI/CD.

A Docker container is very useful, not just for CI/CD, but also for quickly getting a workstation working. It's also a pure command line solution for headless VMs and systems.
As another note, on Macs Rosetta provides good support for x84_64 binaries, but on aarch64 / arm64 Linux devices there isn't a good solution. There are tons of arm Chromebooks out there, and beefy workstations are coming from Ampere Computing, Nvidia, and other vendors.

Fully agree, that it is useful beyond CI/CD. However this project is not intended for bootstrapping developer machines. For that we have nRF Connect for Desktop.

Should be solved via the new nrfutil: https://github.com/NordicPlayground/nrf-docker/commit/980ea412449c61ef1727857cf8751c5c57cd3529


AttributeError: module 'hcaptcha' has no attribute 'Challenge'

When doing
ch = hcaptcha.Challenge(
stuff
)
it gives this

Please check the instructions on how to use this library. It will solve your problem.


[labs/ssr] Add ServerController interface allowing async work during SSR

Part of issue: https://github.com/lit/lit/issues/2469
Change split out of and adapted from https://github.com/lit/lit/pull/1690
Context
Add a new interface ServerController:
interface ServerController {
  serverUpdateComplete: Promise<unknown>;
}

Any ReactiveController that implements this interface will cause SSR to yield and await serverUpdateComplete.
This unlocks some new async SSR patterns.
Design
LitElementRenderer now pulls the list of ReactiveControllers of the LitElement it is about to SSR, and then awaits all controllers implementing ServerController before rendering the contents of the element.
In order to access the ReactiveControllers on a LitElement a new getControllers function has been exposed via _$LE. A LitElement's private set of controllers is now bound to the stable minified identifier W.
Unlocks the following new SSR use cases:

@lit/task can be extended to run during SSR. Allowing the SSR'd content to contain the completed Task data.

/**
  * Example of a Task which runs on the server, SSR'ing the resulting value.
  */
class ServerLoadedTask extends Task implements ServerController {
  get serverUpdateComplete() {
    this.run();
    return this.taskComplete;
  }
}

Server reactive controllers can be implemented which do server specific work during SSR (read files, database queries, fetch, ...). These controllers have access to their components properties.

Although this doesn't implement the async directives, it is now possible to write custom controllers which vend directives that can depend on async work being done. It is also possible to do async work which directives then synchronously use in the render.
Demo
The demo has been updated to show an integration of @lit/task with SSR, which can be tested with npm run demo:global from the /labs/ssr directory.
Test plan
Added SSR tests that highlight ReactiveController and ServerController basic cases. I've also added a test which shows how to implement this use case.
Risks
There is an issue with SSR that this PR can also demonstrate. And that is server render / hydration data mismatch.
The simple case of the issue can be reproduced by rendering from a element:
  render() {
    return isServer ? "some server rendered stuff" : "some client rendered stuff";
  }

This can result in a rendered mismatch between server / client. This becomes even more apparent if you have a situation where a server only controller renders something on the server, and then tries to render something else on the client.
User's must currently be aware of this until we resolve https://github.com/lit/lit/issues/1434

Before committing to this direction, I think it's probably a good idea to have a plan for how to address async directives and server only templates.
Also, pushing this logic into controllers feels slightly odd since controllers may or may not have anything to do with being async or affecting server rendering.
It seems more natural to let an element itself make this decision. Random idea: await the result of update on the server.
async update(changed) {
  if (isServer) {
    await this.task.taskComplete;
    await this.otherAsyncThingComplete;
  }
  super.update(changed);
}

The intention for this feature is to provide a low level utility which can later be used by controllers (such as Task) to do async work during SSR (without the user needing to modify their element).
The multiple highlighted async use-cases that this specific PR unlocks is mostly because Controllers will initially be the one place where async work can happen. We're starting there because we want to start proving async work out starting with Task. We suspect that there will be some subtlety in doing async work well, and so we'll want to package that up into reusable pieces, and controllers seem like a good way of doing that.
Is there concern that adding this capability in ReactiveControllers may block server directives or awaiting on the element?

The concern is about exposing the API at the right level where knowledge exists about what to do on the server. It seems like this makes more sense at the element level than the controller.

The intention for this feature is to provide a low level utility which can later be used by controllers (such as Task) to do async work during SSR (without the user needing to modify their element).

Some tasks should be awaited for server rendering, others should not. Although this might be determined by a specialized task itself, it's more likely this depends on the setup in the consuming element... unless I'm missing something about the intended automation.
By analogy, you wouldn't add a feature to a self-driving car that allowed a wheel to automatically stop the car, instead you'd let it report speed and tire pressure so the system could decide what makes sense to do...

@sorvell Yeah, not all Tasks will want to run on the server, that'll be a config. And agreed that elements should be able to do async work on the server too, but currently what does async work look like in an element? Because the server should be doing fundamentally the same thing as the client, just optionally it'll await it before first render. And right now our best pattern for async work on an element is the Task controller, so it makes sense to target that as the first API, IMO.

I could easily see this becoming deprecated or just unnecessary once we have a  more comprehensive pattern for elements. IMO, this need means we need to design a way for elements to have an async trap before an update.
Towards that end...
Elements can schedule updates using scheduleUpdate and potentially do async work there, but it's not a convenient override point because it's not part of the controller lifecycle.
This is why I suggested update as the spot. If we go that way, we'd want to change performUpdate to:

await the result of update if there is one.
return that result so the update itself can wait

Or something like that.
Given that some design work seems warranted, I'm just a bit uncertain about pushing this through as is.

I don't think we want to make performUpdate() async. That brings all kinds of questions of what to do with concurrent updates (namely, continue and enqueue new update vs abort), and we're actively trying to move away from async performUpdate() by adding scheduleUpdate() and deprecating returning a Promise from performUpdate().

The concern is about exposing the API at the right level where knowledge exists about what to do on the server. It seems like this makes more sense at the element level than the controller.

I think both need to be involved, because we want the system to work correctly when an element uses a controller that must do async work for initial render. Task may be configurable, but there are other abstractions that might say fetch initial data asynchronously and always want to force a wait.
I share the concern about this API being ready to commit to though. Even on a bike-shedding axis, I'm wary of adding too many "server" specific names. Is there some more general concept we're really getting at there, like "initial"*?
So I think we should hold off on merging this a bit. I'd like to review (sorry, been very busy lately!) and I think we should include in the same branch real usage of the API, like updating the real Task implementation to use it, to prove that it suits at least the current needs we have. (and maybe we could make this a private API that only Task has access to initial to gather feedback?)
I'd also like to think through if there's a version of this API where the element is more in charge (but we don't make performUpdate() async). This might look like having a new method on ReactiveControllerHost to wait for initial render until a Promise resolves. It's not a hugely different, API really, it just puts the additional responsibility on the host and reduces how much SSR needs to know about controllers.

Great discussion here! To mark that this PR is not ready to merge I'm downgrading this PR back to a draft.
Thank you Justin and Steve for your reviews!
One option that Peter suggested was to add a labs/server-task package which adds the SSR functionality to Task (without impacting the stable Task package). I'll branch off this branch to make the server-task easier to review.

I don't think we want to make performUpdate() async. That brings all kinds of questions of what to do with concurrent updates (namely, continue and enqueue new update vs abort)

IMO, we've already taken this on directly by having scheduleUpdate support asynchrony. There's already code to handle concurrent updates (that scheduleUpdate's response participates in): the next update is blocked on the current update completing.
AFAIR, we deprecated performUpdate's asynchrony specifically because we added scheduleUpdate.

To respect autoRun and the args function, I think ServerLoadedTask would need to do something like:
class ServerLoadedTask extends Task implements ServerController {
  get serverUpdateComplete() {
    this.hostUpdate();
    if (this.status === TaskStatus.PENDING) {
      return this.taskComplete;
    }
  }
}

This is maybe more about Task than the ServerController interface, but one thing that bugs me is that the easy way to use Task typically results in a 2x update even when the task really shouldn't run. Consider this slight modification of the playground example.
Here the package displayer is a separate element that takes the packageName as a property. It should only run the task if there's a packageName given. The code avoids the expensive fetch but does run the task and return the initial state, which provokes an additional update. While cheap, this isn't ideal and is probably worth avoiding, and if we do it on the server, that'll make the element render async, which again I think worth avoiding.
it's possible to finagle autoRun (commented in the example) to avoid this, but this requires involving the element, which would mean that it couldn't naively just use ServerLoadedTask.

@sorvell

I don't think we want to make performUpdate() async. That brings all kinds of questions of what to do with concurrent updates (namely, continue and enqueue new update vs abort)

IMO, we've already taken this on directly by having scheduleUpdate support asynchrony. There's already code to handle concurrent updates (that scheduleUpdate's response participates in): the next update is blocked on the current update completing.
AFAIR, we deprecated performUpdate's asynchrony specifically because we added scheduleUpdate.

Yeah, async scheduleUpdate() is fine, but sync performUpdate() is very useful, and we've had custom discussions even this week around using that for some niche cases.

This is maybe more about Task than the ServerController interface, but one thing that bugs me is that the easy way to use Task typically results in a 2x update even when the task really shouldn't run.

This is a side effect of the whole task function-calling call tree being async functions. We could rewrite things a bit so that _performTask(), run(), and the user's task function are optionally async. That would allow returning initialState or any data, or throwing synchronously, which would play slightly nicer with SSR.
It's a small optimization though, saving one microtask per task that has the next state synchronously available.
I think Task that works with the element being in control of waiting would look something like this, btw:
  async run(args?: T) {
    //...
    this.status = TaskStatus.PENDING;
    let result!: R | typeof initialState;
    let error: unknown;

    // Request an update to report pending state.
    if (this.autoRun === 'afterUpdate') {
      // Avoids a change-in-update warning
      queueMicrotask(() => this._host.requestUpdate());

      // afterUpdate tasks don't make sense in SSR, right?
      if (isServer) {
        console.log('skipping afterUpdate task in SSR');
      }
    } else {
      // get the host to report current task status like PENDING
      this._host.requestUpdate();
      // Tell the host to update after the task is complete?
      this._host.requestDeferredUpdate(this.taskComplete);
      // note, accessing this.taskComplete unconditionally like this defeats the lazy Promise creation we added
    }
  }


Fix CopyWebpackPlugin config for both dev and production

Solves the new bug in #198 (static assets not appearing in development).
CopyWebpackPlugin needs to be present both in development and production for this structure to work.
I tested with a new project with several static assets and it works in both development and production.
Thanks Greg!

@Oriol-GG
Thanks for the catch, but there's no need to add copy-webpack-plugin into development. When making the changes yesterday I forgot to change the contentBase of the dev server (whoops). This is fixed in https://github.com/SimulatedGREG/electron-vue/commit/8f87230a8b178e083a7bf410067023b2c3354641.

Oh, I see! I'm still wrapping my head around Webpack and I'm actually learning thanks to your repo. Your approach makes much more sense. Thank you!

No worries. Glad you are learning.


Front button fails to light up blue

overview
Previously, the front button would light up blue during the robot software's boot process and remain lit up blue as long as the robot was powered on. Since 3.11.0, the button will randomly fail to light up blue and remain off, though the robot can resume all normal functionality otherwise.

current behavior
Front button LED is off sometimes after the robot has been powered on and connected to the app

steps to reproduce
N/A - needs repro, seems random

expected behavior
Front button lights up blue within 1 minute of powering on the robot as long as software is properly booting

This should be fixed in 3.12 (by https://github.com/Opentrons/buildroot/commit/63988564ca2d9c3ebd09eac541bcda2328ce2e6a)


custom-server example build script not working with next.js 14

Link to reproduction
No response
Describe the Bug
When cloning the custom-server example and upgrading the next.js version to 14, the build fails. It looks as if it is trying to find _error files from the pages directory. But as I am using the app router, this is a blocking issue.
ERROR (payload): Export encountered errors on following paths:
        /_error: /404
        /_error: /500
        /_not-found
        /page: /

My current workaround is changing the NEXT_BUILD step in the server.ts to the following:
if (process.env.NEXT_BUILD) {
  app.listen(PORT, async () => {
    payload.logger.info(`Next.js is now building...`);
    const nextBuildConfig = {
      dir: path.join(__dirname, ".."),
      reactProductionProfiling: undefined,
      debugOutput: undefined,
      runLint: undefined,
      noMangling: undefined,
      appDirOnly: undefined,
      turboNextBuild: undefined,
      turboNextBuildRoot: undefined,
      buildMode: "experimental-compile",
    };
    try {
      // @ts-expect-error
      await nextBuild(...Object.values(nextBuildConfig));
    } catch (error) {
      payload.logger.error(error);
    }
    process.exit();
  });

  return;
}

The only thing I am actually changing is using the "experimental-compile". Is this a viable option or is there a better solution?
To Reproduce
Clone the custom-server example. Upgrade to next.js 14. Run the build script. Error happens at await nextBuild(...).
Payload Version
2.1.0
Adapters and Plugins
db-postgres

Hey @jeremiasjutz - I just went ahead and upgraded to next.js 14 in the custom-server example as well and was able to build successfully. What steps did you take to upgrading to next.js 14?
I went ahead and followed the steps in the next docs here.
Which involved also updating a couple other dependencies / devDependencies to latest - e.g. react, react-dom, eslint-config-next, @types/react and @types/react-dom.

Hi @PatrikKozak Thanks for your response. Yes I updated the project according to the docs. Unfortunately I still get weird errors at build which causes it to fail (unless I add the described function args above)
Here is a snippet of the errors I get:
Generating static pages (0/4)  [    ]Error: <Html> should not be imported outside of pages/_document.
...
Error occurred prerendering page "/404". Read more: https://nextjs.org/docs/messages/prerender-error
Error: <Html> should not be imported outside of pages/_document.
Read more: https://nextjs.org/docs/messages/no-document-import-in-page
...
Error: <Html> should not be imported outside of pages/_document.
Read more: https://nextjs.org/docs/messages/no-document-import-in-page
...
Error occurred prerendering page "/500". Read more: https://nextjs.org/docs/messages/prerender-error
Error: <Html> should not be imported outside of pages/_document.
Read more: https://nextjs.org/docs/messages/no-document-import-in-page
...
[10:40:07] ERROR (payload): Export encountered errors on following paths:
        /_error: /404
        /_error: /500
        /_not-found
        /page: /
    err: {
      "type": "ExportError",
      "message": "Export encountered errors on following paths:\n\t/_error: /404\n\t/_error: /500\n\t/_not-found\n\t/page: /",
      "stack":
          Error: Export encountered errors on following paths:
                /_error: /404
                /_error: /500
                /_not-found
                /page: /
...
        "code": "NEXT_EXPORT_ERROR"
...

Update! The error seems to be related to @payloadcms/bundler-vite. When using bundler-webpack, the build works as expected. Is it required to use bundler-webpack in this case?

@jeremiasjutz Yup, I was able to reproduce this as well using @payloadcms/bundler-vite.
On initial glance, these errors seem to be issues with Next. My suspicions come from these issues that I just came across:

https://github.com/vercel/next.js/issues/58576
https://github.com/vercel/next.js/issues/52158

I will continue looking into this and get back to you asap!

Hey @jeremiasjutz - so the issue stems from the fact that NextJS uses webpack under the hood so in this case the webpack bundler is required.
Going to close this issue for now but if there is anything else I can assist with, let me know.

Hey @PatrikKozak  - I created a new Next app using the create-next-app command and tried building it using npm run build and still got the same issue.
Steps to reproduce:

create a new next app using npx create-next-app@latest
2.npm run build

I'm on node version v19.9.0

In case anyone else has a similar issue, I had modified the /app/(pages)/[...slug]/page.tsx file and the Pages collection so that you can use an empty slug for the home page.  The payload template defaults the slug to 'home', but then nothing comes up at the root of your site... not sure if there is a better way to solve that issue.  Anyway, because the slug is just an empty string, my generateStaticParams() function was returning { slug: [''] }, which caused next.js to report the prerender / "code": "NEXT_EXPORT_ERROR" error.  Changing generateStaticParams() to return { slug: ['/'] } fixed the problem for me.


test/calogica_version_update

PR Overview
This PR will address the following Issue/Feature:
This PR will result in the following new package version:

Please detail what change(s) this PR introduces and any additional information that should be known during the review of this PR:
PR Checklist
Basic Validation
Please acknowledge that you have successfully performed the following commands locally:

[ ] dbt compile
[ ] dbt run –full-refresh
[ ] dbt run
[ ] dbt test
[ ] dbt run –vars (if applicable)

Before marking this PR as "ready for review" the following have been applied:

[ ] The appropriate issue has been linked and tagged
[ ] You are assigned to the corresponding issue and this PR
[ ] BuildKite integration tests are passing

Detailed Validation
Please acknowledge that the following validation checks have been performed prior to marking this PR as "ready for review":

[ ] You have validated these changes and assure this PR will address the respective Issue/Feature.
[ ] You are reasonably confident these changes will not impact any other components of this package or any dependent packages.
[ ] You have provided details below around the validation steps performed to gain confidence in these changes.

Standard Updates
Please acknowledge that your PR contains the following standard updates:

Package versioning has been appropriately indexed in the following locations:

[ ] indexed within dbt_project.yml
[ ] indexed within integration_tests/dbt_project.yml

[ ] CHANGELOG has individual entries for each respective change in this PR

[ ] README updates have been applied (if applicable)

[ ] DECISIONLOG updates have been updated (if applicable)
[ ] Appropriate yml documentation has been added (if applicable)

dbt Docs
Please acknowledge that after the above were all completed the below were applied to your branch:

[ ] docs were regenerated (unless this PR does not include any code or yml updates)

If you had to summarize this PR in an emoji, which would it be?

:dancer:

This is being addressed within PR #36


 The TV only comes through the existing Samsung integration and then stops working all together 20 seconds later
Any help would be appreciate, again apologies if i'm missing something obvious

Also, to add another point, it is constantly asking me on my tv is Allow the device - every 2 minutes or so


Enable Repo Discussions

Can you enable the repo "Discussions" tab? I noticed this repo has no tests yet and I think that would be a better place to discuss this than in "Issues" (along with other things like roadmap etc.). You just have to go to settings, then under Options / Features, there's a checkbox to enable "Discussions".

Discussions have been enabled!  Regarding tests, feel free to add them as you see fit.  As the scope of the project grows, it certainly makes sense to build out a test suite.
Feel free to start a roadmap discussion with any ideas and we can start prioritizing future enhancements.


AWS amplify not rendering image while local build render image correctly

Please describe which feature you have a question about?
I'm currently using AWS amplify to run one of my react app. I added one image in my react public folder so I can use that as a background. When I test it in my local, the image shows correctly. However, after I push my code to git and use AWS amplify to build it, I found the image is missing. Based on the build log, seems the image is never copy to the build directory. Is there anything I need to do to make sure the image is correct uploaded?
Provide additional details
My git branch: https://github.com/andreling01/mltd-ranking
My app id: d3azsbdqn01xd0
What AWS Services are you utilizing?
AWS amplify
Provide additional details e.g. code snippets
I also make sure the manifest file is changed and added with my new image information.

Hi @andreling01 👋🏽 thanks for raising this question. I was able to reproduce and find a solution for you. 🙂 We have a rewrite rule for SPA applications that routes all files to index.html. We use regular expressions to identify the different file extensions that we rewrite:

Your background image is a jpeg which we did not add to the regex. If you add |jpeg| like so ,  then you should be able to see your background image.
Workaround:

In the console, navigate to your app and select Rewrites and redirects
Select Edit and replace the source address with </^[^.]+$|\.(?!(css|gif|ico|jpg|jpeg|js|png|txt|svg|woff|ttf|map|json)$)([^.]+$)/>
Save and refresh your hosted page.

Please let us know that this works for you.

Thanks! That solved my problem!


[RFC] Pull-based indexing

This is a very rough initial-draft RFC based on my talk (rant?) at the Unconference at OpenSearchCon 2023. Big thanks to @huyaboo and @mansu for their Unconference talks and subsequent discussion.
Problem
OpenSearch currently has a push-based indexing model. Clients push updates to OpenSearch and they are immediately routed to the appropriate primary shards.
The current push-based indexing model has several problems:

Coordinators must be able to push updates to specific primary shards and receive acknowledgement. If a primary shard is temporarily unavailable (node failure, stop-the-world GC, network partition, primary under duress, etc.) the update fails, leading to a drop in availability for indexing APIs.
Coordinators must be able to locate every possible primary shard to route documents appropriately, which is shared state that must be agreed upon by all possible coordinators, which relies on propagation from cluster managers.
It's essentially impossible to reshard without downtime (which is why the split operation requires a read-only index). Do you ever feel frustrated when you try to log into your online bank on a Sunday morning and they're "down for maintenance"? This isn't the 1990s. We have known how to scale without downtime for a couple of decades. I was on a team of 6 people who built a Lucene-based distributed search service that could do live resharding in 2012 (as in we started and finished building it in 2012).

Proposal
In my dreams, I'd like to just build a modern version of the system that I helped build in 2012, but that's very different from where OpenSearch is now. We need a step-by-step migration path, and I believe pull-based indexing would be a first step.
This proposal assumes the existence of an external event stream (not to be confused with the still push-based Streaming Indexing API). Possible event stream implementations could include Apache Kafka, Amazon Kinesis, or others. (Back in early 2012, we built an event stream on top of S3, because Kinesis and Kafka didn't exist yet.) A callout is that the event stream is not a message queue (where receivers "dequeue" messages, removing them from the queue such that they can't be processed by others) -- it's more of an indexable buffer where multiple clients should be able to read past events (probably with some limits as to how far back they could go). Ideally, the event stream should support sharding (and live resharding), since we would like to be able to scale up the event queue too, but that's not a hard requirement for smaller installations.
Puller API
On the short term, I would like to add a new puller service running on every indexing-capable node that pulls updates for any primary shards that they may be hosting. Since OpenSearch should operate independent of any particular event stream implementation, I propose that we define a generic API like:
class ShardRange {
  final int shardStart;
  final int shardEnd;
}

class Updates {
  final List<IndexRequest> indexUpdates;
  final byte[] newCheckpoint;
}

Updates pullUpdates(ShardRange shardRange, byte[] checkpoint, int maxUpdates);

The above is rough, but probably a decent starting point.
The key ideas are:

The shard (or the in-process puller service acting on behalf of the shard) should know which range of documents it should accept. This is based on the current sharding strategy. (If we split/merge shards, these ranges will be different on the new shards. The section below on live resharding goes into detail.) If we want to support pulling from event streams that don't support sharding, the shard should assume this is merely a suggestion and should still check the IndexRequests to see if they fit the current shard. (Currently, that means computing the doc ID hash or looking at an explicit _routing parameter.) Anything outside the shard's range can be discarded -- it's excess I/O, but we don't do the heavy indexing work. Alternatively, the event stream API implementation (discussed in the next section) could discard them (still probably involves pulling updates onto the node just to discard them, but you may be able to skip some serialization steps).
There is a generic "checkpoint" that is essentially a pointer into the event stream. The shard asks the event stream for updates starting from one pointer, and the event stream returns a pointer that will get the next set of updates. The meaning of the checkpoint is opaque to OpenSearch. (I went with byte[] to represent this, but it's not a hard requirement.)
The shard should be able to set a limit on the number of updates that it can accept in each iteration. This means that we don't need to worry about overwhelming the shard with updates, since it will only pull at a rate that it can handle.

Essentially, the puller service would fetch updates and invoke the existing in-process indexing APIs to apply the updates. Document and segment replication would do their thing to propagate the updates out to replicas.
How to implement the event stream API
My initial thought was that we could do something plugin-based, kind of like repositories. Then I realized this could be a shining beacon of a use-case for extensions. Essentially, users could configure an extension for whatever event stream they want to pull from and the extension could take care of fetching (either synchronously or concurrently buffering) updates from the event stream. In practice, we specifically want the event stream API to be independent of the OpenSearch version, since this model gives us a cleaner path toward zero-downtime upgrades (see below). So, extensions feel like a great fit. (Plugins wouldn't be terrible, but would still have the messy "recompile with every release" nonsense.)
Snapshots
A key piece of this is that snapshots should record the latest checkpoint associated with the indexed data for a shard. This allows us to recover from a total outage without loss of data (and if the event stream supports sufficient buffering, without an availability drop on the clients pushing to the event stream). A shard can recover from snapshot and then start processing updates from the checkpoint encoded in the snapshot to get caught up.
This would be amazing for cross-cluster replication. You could enable replication for an index on another cluster, that new cluster could restore the latest snapshot from the original cluster, then process updates from the event stream to get caught up and stay up-to-date. Essentially, cross-cluster replication would put zero load on the original cluster.
You could also scale your cluster under that model. Bring up a new, larger cluster, have all the shards restore from snapshots written by the underscaled cluster, get caught up, then you flip search traffic over to the new cluster.
You could do the same thing to upgrade your cluster (or update your opensearch.yml) with zero downtime and no shard-copying load. Bring up a new cluster, restore from snapshot, get caught up, flip traffic, shut down the old cluster.
tl;dr: host-to-host copying of shards is sooooo early 2000s. The cool kids restore from snapshot and get caught up.
Live resharding
I promised live resharding up top, but I see that as a longer-term effort. Essentially, we need a way to bring up an additional set of primary shards for an existing index, such that the shard ranges for the new shards are different from the original shards, but cover the full range. The new shards will restore from snapshot from any overlapping original shards, delete any documents outside the range (using a Lucene deleteByQuery), and use addIndexes to merge the shards.
This may be easiest to explain with some examples.
Suppose you have 1 shard and want to split it into 2. We'll bring up 2 new shards. Each will restore from snapshot from the original shard. The first shard will delete the second half of the total shard range (i.e. [0, Integer.MAX_VALUE]), while the second shard will delete the first half (i.e. [Integer.MIN_VALUE, -1]). Now each shard has half of the documents from the original shard (assuming a statistically even distribution over the range). Both shards have the original shard's snapshot checkpoint, and they resuming indexing from that point. Once they're caught up, we can flip search traffic over to the new shards and shut down the old shard.
The trickier scenario is when you have overlapping shards. Say you want to go from 2 shards to 3 shards. The first and third shard each restore from a single snapshot from the previous shards (since 0 < 1/3 < 1/2, and 1/2 < 2/3 < 1), but the middle shard needs to restore from both. This can be a slow operation, where it restores the first snapshot (which is 1/2 of the index), deletes the first 1/3 of the index (leaving 1/6 of the index), then it restores the second snapshot (which is also 1/2 of the index, for a total of 2/3 of the index), deletes the last 1/3 of the index, and then merges the two 1/6 of the index into the middle 1/3. Phew... Only now the hard part comes: we have two checkpoints possibly representing different points in the event stream. We should probably start from the earlier checkpoint (and need the event stream API to tell us which is the earliest), but we may go back and reprocess updates that are already in the index. In theory, they should always be the latest updates, so once we're caught up we don't go back in time, but we may introduce unnecessary updates (i.e. adds+deletes) that make log-based optimizations (i.e. if there are no deletes you can take some shortcuts) disappear.
The solution I helped build back in made this 2012 easy -- we had mandatory external versioning. So, if we reprocessed old updates for existing documents, we would simply discard them. OpenSearch currently processes updates without external versioning in a "last one to get in wins, things are always sequential, what are distributed systems?" model.
All may not be lost, though. We can a) allow resharding for arbitrary indices as long as the new shard count is a multiple of the old shard count, since that's analogous to the 1 -> 2 scenario described above. b) if the user can tell us that the index is inherently append-only (like logs), we don't care about versions. If we already have a matching doc, we skip the current one. (Of course, this assumes that we can compute unique doc IDs based on an IndexRequest.)

This sounds "easy" :) Replace a push-based model where central control needs to have all the info by a pull-based one where pullers update central state as they pull work to do.

This is interesting perspective, it looks a lot like connectors model (at least to me) where we just configure the source and connector starts polling / pulling the data in. There are three main questions that bother me:

the fact that the pulling has to be collocated with the primary shard it pulls data for, it has to be the part of the OpenSearch core (and follow all relocation / recovery / etc), correct?
you mentioned that extenstions could implement all this different pulling sources (essentially, being connector) but those are inherently out of the process, how does it play with shard placement awareness?
why you think Streaming Indexing won't be an acceptable alternative here since we would have a natural back-pressure and also could open direct connections (ideally, streaming ones with gRPC) to the nodes that have relevant primary shards?

Thanks @reta!

the fact that the pulling has to be collocated with the primary shard it pulls data for, it has to be the part of the OpenSearch core (and follow all relocation / recovery / etc), correct?

The sneaky thing in the proposal (and what makes it probably much more complicated than it initially sounds) is that my real goal is to kill off the whole concept of primary shards and especially host-to-host shard relocation. Instead, you just have "writer" shards that pull updates from the event stream and write them to a Lucene index (where among other things, you should be able to have more than one writer for the same shard at the same time). (But that's a bigger topic, IMO.)
This hypothetical UpdatePullerService or whatever we want to call it would be part of OpenSearch Core. The UpdatePullerService would check to see what primary shards are on the current node and pull updates for those shards (by calling out to the registered connector). If a primary shard is added to a node, the UpdatePullerService starts pulling updates for that shard. If a primary shard is removed from a node, the UpdatePullerService stops pulling updates for that shard.

you mentioned that extenstions could implement all this different pulling sources (essentially, being connector) but those are inherently out of the process, how does it play with shard placement awareness?

Related to the above answer, the in-process UpdatePullerService knows what shards are on the current node and calls into the extension to retrieve updates from the event stream. The extension just fetches the updates it has been asked to fetch and returns them to the UpdatePullerService.

why you think Streaming Indexing won't be an acceptable alternative here since we would have a natural back-pressure and also could open direct connections (ideally, streaming ones with gRPC) to the nodes that have relevant primary shards?

That's still a push model, where the client needs to route the documents to one specific primary node. Yes -- we get backpressure. We still can't bring up a copy of the primary shard on a different box, have that get caught up, and flip over with zero downtime, though.
I might try drawing a picture of the architecture, since it is very different from what OpenSearch does now.

My $0.02.

This proposal assumes the existence of an external event stream (not to be confused with the still push-based Streaming Indexing API)

The in-flight Streaming Index API implementation is just the first step to the original RFC. The goal of the Streaming Index API RFC is to do away with the _bulk push model altogether and move to a stream model (hence the name "Streaming Index API") such that the index/search service "picks" the documents off the stream. This also removes the need for a translog which is a massive achilles heel to Elasticsearch / OpenSearch.

Then I realized this could be a shining beacon of a use-case for extensions.

I think this is more a shining beacon for #5910 and the need to move OpenSearch from a monolithic server implementation into a distributed lucene API such that your proposal could be easily implemented using the OpenSearch core artifacts as a dependency and not depend on the superfluous CORBA-like marshall/unmarshall logic of protobuf.


Add Error associated type to BlockExecutor

Describe the feature
The trait in https://github.com/paradigmxyz/reth/pull/6461 will ideally replace the ExecutorFactory trait, and the associated type is:
type Executor: BlockExecutor

The reth-provider crate already depends on node-api, and it also contains BlockExecutor, BundleStateWithReceipts, BlockExecutorError, and more types.
We should not have to pull all these types into node-api. Instead, to avoid circular dependencies, we should create a new crate that includes the traits that we're sharing between node-api and reth-provider.
ref https://github.com/paradigmxyz/reth/pull/6461#discussion_r1486520871
Additional context
No response

closing this for now. This was motivated by wanting to replace ExecutorFactory with a trait that has an associated type for the executor. This can be revisited once we have a good solution for doing that


Added messages to JSON test file

I am a little uncomfortable with the consistency of the JSON files and generators. I've added these messages and kept the structure the same, but feel as though some JSON refactoring across all the tests and generators may be required?

I wouldn't worry about the consistency between json files yet. We don't really have enough information at the moment to see whether we've come across all the complexities or not. Until we have more information, I'm comfortable treating each individual JSON file as its own thing.
In the generators we've abstracted out the part that actually reads JSON files and creates test cases, both in Ruby and Go.

This looks good. In the future, please include the name of the exercise that is affected in the subject line of the commit. In these repositories we look at history a lot, and having the context about which problems are affected is very helpful when we do.


fix: If a parent was removed that did not have a Parent, removal was …

…not seen

bors r+

bors r-

bors r+


Add two methods to tell if type is an enum

We don't need to merge this as-is, but I need something similar to indicate if a returned value is an enum.

Closing as PgTypeKind is now public and accessible via PgTypeInfo::kind(self)


Orientation

Updated ScreenOrientation to include additional items such as ReverseLandscape, SensorLandscape, ReversePortrait, SensorPortrait, FullSensor

The way it is now, only the common orientations appear in the designer dropdown.   You can specify other ones with the [set orientation] block.   But  don't list these other ones in our documentation, and refer people to the Google Android docs for a full list and explanation.   I think that's an OK way to handle it.
Closing this issue.


Helm chart defaults to cluster.local.

It should not always default to the *cluster.local dns name.

Would these be configured to something besides the hostname internal to Kubernetes?
Thus the command to run the container is using get from hostname -f.  This is setup inside the /etc/hosts:
<IP_ADDRESS>	dgraph-1589489873-dgraph-alpha-0.dgraph-1589489873-dgraph-alpha-headless.default.svc.cluster.local	dgraph-1589489873-dgraph-alpha-0

Is the name generated outside of Kubernetes, something we'd could or want to change?

Are you suggesting we use dgraph-1589489873-dgraph-alpha-0 instead of the FQDN of the service dgraph-1589489873-dgraph-alpha-0.dgraph-1589489873-dgraph-alpha-headless.default.svc.cluster.local?


Instrument EF Tools wizard for usage data

We would like to have more information about how much customers use each of the different options, e.g. code first from existing database, designer from new database, etc. to be able to make better decision on where we invest.

@bricelam does this still need work before we close?

It's not merged, and there was mention of possibly adding more details.

Clearing up milestone to decide what to do in triage.

@divega and @ajcvickers to decide what to do here.

Closing this for now as the value to complete this is not high enough to trump any other work. We can also come back to it in the future.


how to implement action in html.form

i see you docs . no guide about html.form . action
in html like this
<form method="post" action="/post">
</form>

how to implement in you frameworks
html.form(
html.input_(type="text", name="item", placeholder="Add new item", required=True),
html.input_(type="submit", value="Add"),
),
thx

Hi,
As with almost all tags, html.form can have both children (positional arguments) and properties (keyword arguments). So you can add form action and method like this:
from htmy import form

html.form(
    html.input_(type="text", name="item", placeholder="Add new item", required=True),
    html.input_(type="submit", value="Add"),
    action="/item",
    method="post",
)

It would be nice to have IDE auto-completion for property names, but unfortunately Python's typing utilities don't really allow that in a flexible-enough way just yet.

As described in the docs, htmy is a rendering library, it (intentionally) does not have built-in client-server state synchronization like reflex or nicegui. This means you can not write your event handlers in Python. Actually I strongly recommend using this library with htmx and alpinejs for example, so you don't need to write much JavaScript, event handlers, and the like.
I'm not sure about your C.Text(Visible=false, text="tess") example. htmy does not have a built-in text component, there's also no Visible property. htmy gives you all the elements you have available in HTML. You can use those to build your own higher order components.
Regarding styling, there's a fairly detailed example application in the docs that uses FastAPI, TailwindCSS, DaisyUI and HTMX for styling and interactivity. Please explore that example. Also, on top of CSS classnames, you can of course set the style attribute on HTML elements, they'll work as you'd expect in HTML.


Booking background color needs to be 100% of the height

When you are on a booking and open FAQ detail, FAQ detail is bigger then the Booking container. so background of the current booking doesnt cover the whole area

There should be 2 scrolls, one for faqs and the other for booking, if there is more content in one of them, the scroll will show up just for this part of the content, I think this is solved by this issue https://github.com/kiwicom/smart-faq/issues/296, that's the one you are solving here https://github.com/kiwicom/smart-faq/pull/301 and once resolved this shouldn't happen.

Oh, thats true @jalbertsr


add option to return bytes object

this allows pdf to stay in memory and allow caller to handle writing of the data vs writing to a temp file, dumping from memory and then re-loading to memory for certain scenarios

@luisza
Can you take a look? I am open to other options. The writing to temp file and re-loading pattern is rather resource intensive and unnecessary if like my instance, you are writing to a web endpoint like [insert cloud provider] storage.


Add peak only and XCMS to sequence manager

Once we have the peak only (Simon) and XCMS (Ronan) peak picking methods set up to work within the ViMMS / Python framework, it would be good to add them (Vinny) to the sequence manager

how's the peak picking results from peakonly? is it good?

it's fast, and looks ok
Really easy to run (their latest release has a GUI). Open an .mzML, click "pick peaks", wait a minute or so...

Not having a good peak picking method is the main thing that prevented us from creating a decent xcms-alternative in Python, right? So now it's all there.

Yes, possibly. Good point.
Probably needs someone who knows that they’re on about to look at the output though...
Simon Rogers
<EMAIL_ADDRESS>
On 17 Jul 2020, at 14:08, Joe Wandy<EMAIL_ADDRESS>wrote:
Not having a good peak picking method is the main thing that prevented us from creating a decent xcms-alternative in Python, right? So now it's all there.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub https://github.com/sdrogers/vimms/issues/34#issuecomment-660097100, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEVKY3WDYYBH2H24NAO2BLR4BEMVANCNFSM4O6HBBLA.

Another question that came up in meeting: if we pass peakonly a partial chromatogram, could it still identify that it's a peak or not?

To be discussed in issue #39


Fix some typos in documentation!

Hi @bhaveshgohel,
Thanks for taking the time to submit this PR. I've purposely styled it this way to indicate the parameter(s) were optional. Is the way you've changed it to a more standard way of doing this?

Pardon me, I didn't correctly understand : "Is the way you've changed it to a more standard way of doing this?"
The main intention of the PR was that other person can simply copy paste the code and use it by simply removing callback with there functions. I should have also remove the "["  "]" in that case.
With the comma it looks like typo. But I totally get your point of purposely styling to indicate it as optional. It was just a suggestion from my side. :)

For example, looking at the Node.js Buffer docs: https://nodejs.org/dist/latest-v4.x/docs/api/buffer.html#buffer_new_buffer_str_encoding
They use the style:

new Buffer(str[, encoding])

To indicate encoding is an optional parameter.
Let's stick with the current approach, as it's a similar style to what Node.js is use for the official docs. I understand your concern about copying and pasting, thanks for clarifying.


Add url path for custom location

Hi there.
I'm trying to add a few custom locations for a specific proxy host. However, I'm unable to get this working with the web interface. It's not possible to add an URL path for the forward host name.
For example: This is the generated proxy pass:
proxy_pass http://<IP_ADDRESS>:9005;
However, I need to add a trailing slash:
proxy_pass http://<IP_ADDRESS>:9005/;
It works fine when I manually edit the nginx config. But it would be more useful if this can be done from the web UI.

It should work. In the Forward Hostname / IP field, set the following value (see the ending slash):
<IP_ADDRESS>/

@jlesage
That only works when no port is given. Otherwise it will be set to <IP_ADDRESS>/:9005

Make sure to use the latest image version.  This has been fixed.

That solved the issue. I pulled the latest version a weeks ago, and was running the image created on 2019-03-05.
It works as expecting in the 2019-04-11 version.


Date Picker - input field placeholder text position wrong on mobile device

Detailed description

Describe in detail the issue you're having.

I am observing an issue in placement of text in the Date Picker input field. First I realized it in my own application, but I can see that behavior on official site is the same if accessed on a mobile device (seen on Android and iPhone, tested only on Android):

The placeholder text is not vertically aligned, but sticks to the top of the input field.
A dropdown caret is show on the right side of calendar icon.

Is this a feature request (new component, new icon), a bug, or a general issue?

Bug (presentation)

Is this issue related to a specific component?

Datepicker

What did you expect to happen? What happened instead? What would you like to see changed?

Same look and alignment on desktop and mobile device.

What browser are you working in?

Google Chrome

What version of the Carbon Design System are you using?

Browsing https://angular.carbondesignsystem.com itself.
Steps to reproduce the issue

Open Date Picker component story
Fine with desktop browser
Presentation issues with mobile browser

Additional information
Actual (Chrome on Android):

Expected (Chrome Desktop, narrowed):

Hey @caratage, what version of carbon-components are you using?

Hi @Akshat55. Using carbon-components: ^10.41.0 and carbon-components-angular: ^4.55.0.  The screenshots above are taken directly from the Date Picker component story.

@caratage, Could you try updating to<EMAIL_ADDRESS>This is the current version of carbon-components we are using. I can't seem to duplicate this via changing screen size... or maybe just haven't found the right one yet.
Could you please provide your phones screen size? This issue doesn't seem to appear on mine.
This one will be a tricky one to solve. 😅

@Akshat55 Ok, I have updated my project to @angular/core: 14.2.7, carbon-components: 10.58.3 and carbon-components-angular: 4.62.1 and this issue still persists.
It is true that changing screen size on a desktop browser will not reproduce the issue. Only browsing on the mobile device will show it.
Android 12, Chrome Moto Egde 30:

iOS 16, Safari iPhone SE:


Confluence add-on

https://developer.atlassian.com/confdev/confluence-plugin-guide/writing-confluence-plugins

Do you know if there was ever any work done on this?

Seems like this addon can process WaveDrom diagrams on Confluence page
https://atlasauthority.atlassian.net/wiki/spaces/MARKDOWNCLOUD/pages/2946826241/Diagram+Macro

Only for cloud installs...


Enable driver jar publish

Enable driver jar publish
Added missing gradle config post-upgrade

With this change, the gradle task to publish the jar changes from
./gradlew publishPostgresqlPublicationToRemoteRepository -x test -Prelease

to
./gradlew publishJdbc-yugabytedbPublicationToRemoteRepository -x test -Prelease


Refactor EVM chain ID to refer to constant map instead of config

Describe your changes and provide context
This modifies the EVM chain ID to be served from a map between cosmos chain IDs to evm chain IDs, with a default for all other chains.
Testing performed to validate your change
Updated tests

Codecov Report
Attention: Patch coverage is 73.33333% with 4 lines in your changes are missing coverage. Please review.

Project coverage is 60.97%. Comparing base (a42726e) to head (536a5a9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1589      +/-   ##
==========================================
- Coverage   61.13%   60.97%   -0.17%
==========================================
  Files         366      366
  Lines       26076    26073       -3
==========================================
- Hits        15941    15897      -44
- Misses       9129     9171      +42
+ Partials     1006     1005       -1

Files
Coverage Δ

app/app.go
65.64% <100.00%> (+0.08%)
:arrow_up:

evmrpc/info.go
73.57% <100.00%> (ø)

evmrpc/simulate.go
70.83% <100.00%> (+0.12%)
:arrow_up:

evmrpc/txpool.go
73.17% <100.00%> (ø)

x/evm/ante/fee.go
66.19% <100.00%> (ø)

x/evm/keeper/evm.go
48.52% <100.00%> (ø)

x/evm/keeper/keeper.go
50.13% <100.00%> (-0.14%)
:arrow_down:

x/evm/keeper/msg_server.go
78.08% <100.00%> (ø)

x/evm/keeper/params.go
81.81% <100.00%> (ø)

evmrpc/net.go
33.33% <0.00%> (ø)

... and 3 more

... and 4 files with indirect coverage changes


increased protein level in MMS

increased protein level during cellular response to methyl methanesulfonate
PMID:16407242

increased protein level during cellular response to methyl methanesulfonate FYPO:00055333
edit file: b6f863a875ac7c9704d2ffe278d196a9a4e8b7de
release: 9154d65b31275615b2675821e618d59e667f3b83


[Frontend] Forward intent to launch REPL to new driver

Now that the new driver no longer runs the REPL by default
when there are no arguments, the frontend needs to update
its assumption as it is still used to launch the new driver.
rdar://88595293

@swift-ci Please smoke test

@swift-ci Build Toolchain macOS Platform

@swift-ci Build Toolchain macOS Platform


Unregistering participant fails to pop loading dialogue due to outdated context

Probably some kind of race condition as this is where integration tests sometimes fail, and now it occurred on my simulator too:
E/flutter (20752): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: Looking up a deactivated widget's ancestor is unsafe.
E/flutter (20752): At this point the state of the widget's element tree is no longer stable.
E/flutter (20752): To safely refer to a widget's ancestor in its dispose() method, save a reference to the ancestor by calling dependOnInheritedWidgetOfExactType() in the widget's didChangeDependencies() method.
E/flutter (20752): #0      Element._debugCheckStateIsActiveForAncestorLookup.<anonymous closure> (package:flutter/src/widgets/framework.dart:4558:9)
E/flutter (20752): #1      Element._debugCheckStateIsActiveForAncestorLookup (package:flutter/src/widgets/framework.dart:4572:6)
E/flutter (20752): #2      Element.findAncestorStateOfType (package:flutter/src/widgets/framework.dart:4643:12)
E/flutter (20752): #3      Navigator.of (package:flutter/src/widgets/navigator.dart:2623:40)
E/flutter (20752): #4      Navigator.pop (package:flutter/src/widgets/navigator.dart:2507:15)
E/flutter (20752): #5      UnregisteredLinkButton.build.<anonymous closure> (package:encointer_wallet/page-encointer/ceremony_box/components/unregister_link_button.dart:30:21)
E/flutter (20752): <asynchronous suspension>

Haha, wow this seems to occur consistently after the change in send txs in dart because of more reliable timings.


Error page of kubernetes ingress default route not showing

Do you want to request a feature or report a bug?
Bug
What did you do?
apiVersion: v1
kind: Service
metadata:
  name: default-route
  namespace: my-namespace
  annotations:
    traefik.backend.circuitbreaker: "NetworkErrorRatio() > 0.5"
spec:
  ports:
  - name: http
    targetPort: 5000
    port: 5000
  selector:
    app: default-route

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: default-route
  namespace: my-namespace
  annotations:
    kubernetes.io/ingress.class: "traefik"
    traefik.ingress.kubernetes.io/error-pages: |-
        foo:
          status:
          - "400-600"
          backend: default-route
          query: "/{status}.html"
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: default-route
          servicePort: 5000

I've also tried setting with priority no luck.
What did you expect to see?
If I have an ingress route and service  defined.. and I  remove all pods.  I would expect to see my default route error page instead of service unavailable
What did you see instead?
service unavailable
Output of traefik version: (What version of Traefik are you using?)
docker image: traefik:v1.6.5
What is your environment & configuration (arguments, toml, provider, platform, ...)?
Running as kubernetes ingress provider
defaultEntryPoints = ["http","https"]
    [entryPoints]
      [entryPoints.http]
      address = ":80"
        [entryPoints.http.redirect]
          entryPoint = "https"
      [entryPoints.https]
      address = ":443"
        [entryPoints.https.tls]
          [[entryPoints.https.tls.certificates]]
          CertFile = "/ssl/wildcard.crt"
          KeyFile = "/ssl/wildcard.key"
      [entryPoints.api]
      address = ":8080"
      [entryPoints.ping]
      address = ":8082"

    [kubernetes]

    [api]
    entryPoint = "api"
    dashboard = true

      [api.statistics]

    [metrics]
      [metrics.prometheus]
        entryPoint = "api"

    [ping]
    entryPoint = "ping"

@dduportal since you are planning to look at this (which is great), how hard would it be to also implement https://github.com/containous/traefik/issues/3420 while your brain is in the realm of error pages? 🙂

#3678 looks like trying to achieve same thing.
Basically my setup is a default-route service.   That service responds to any request to *.mydomain.com that doesn't have an ingress route defined for it.
With the addition of error pages I intended to make the default-route service handle the cases where an ingress route has been added but the service wasn't ready yet: service unavailable or bad gateway.
So my thought is.. can't reach the service... I should be able to make it hit the default-route and show an error page.  That way at least I can communicate something friendly.
Otherwise I would have to add the exact same error page annotation to 2k some different ingress routes.
Maybe i'm trying to do something that isn't supported?  If so I guess I need to convert this to a feature request :)

@geekgonecrazy You have a couple things rolled into one with this issue:

You are trying to create a global default backend ingress. This is already supported in 1.7: (https://docs.traefik.io/v1.7/configuration/backends/kubernetes/#global-default-backend-ingresses). Trying to implement it in 1.6 will most likely not work (hence why the code changes were required).
The error page configuration tells traefik what to render when your ingress has issues. Right now you have your default backend using your default backend to render its own error pages. I don't think that is what you intend to do.
You can achieve what you want to do, but yes, you require your ingresses to each specify their own error page configuration. You can modify templates to reduce your coding time, but there is no global "override" for per-ingress configuration.

Ah... Then yes I guess what i'm attempting to do would be considered global error pages.
By templates do you mean traefik's? From the documentation: https://docs.traefik.io/configuration/commons/#override-default-configuration-template looks like I can only do so if I know ahead of time the frontends?  Though seems a bit vague beyond that like more might be possible.
Being able to define a template that would be applied to all frontends would definitely be a cleaner solution

ah... https://github.com/containous/traefik/blob/master/templates/kubernetes.tmpl looks like this basically will allow me to overwrite this file right?  :thinking:

Hello @geekgonecrazy ,
Many thanks for your feedback.
Indeed, there was a bug with the error pages management.
This bug has been fixed in 1.7 but, your workaround is the best solution to solved it in older versions.
The question seems to be answred.
I close the issue.

@nmengin I'm not sure if error pages work at all in 1.7, see https://github.com/containous/traefik/issues/3643#issuecomment-411922387. Or has this got fixed already? The last version I tested was 1.7.0-rc.3 and I can't recall any related PRs since then.

@kachkaev the bug in v1.7 is not fixed, I'm working on it.


Reduce target duplication in Realm.xcodeproj

Remaining work:

[x] Get the multiprocess tests working
[x] Get tests passing in CI

We got a tag "wip" to use instead of the prefix in subject :-)

OMG, the tests passed and everything!

@kishikawakatsumi, it should be relatively easy for you to resolve the conflicts this will cause with #2721. You should just need to revert your changes to Realm.xcodeproj, and make similar changes to the new .xcconfig files as you made for RealmSwift.

A couple of things to be aware of:

The iOS static framework is now the special one, with its build directory having a -static suffix. I made this change because the dynamic frameworks are common across all platforms. The existing approach also lead to an odd situation where build/ios contained a mix of static and dynamic frameworks (for Swift). Now ios contains only dynamic frameworks, and ios-static contains only static frameworks.
TestHost.app is now used for tests on all platforms, rather than OS X and iOS Simulator tests being run directly by xctest. xctest is now used only as the child process for multiprocess tests.
RLMPlatform.h is now generated dynamically as it was difficult to ensure that Xcode picked the right one for each platform. This probably isn't necessary, but I got bored with fighting Xcode and went with a solution that I knew I could make work. I'll revisit this at some point and simplify it.
There's a lot of redundancy between the Realm and RealmSwift .xcconfig files. I'll clean that up in a later pass.

/cc @jpsim @tgoyne

RLMPlatform.h is now generated dynamically as it was difficult to ensure that Xcode picked the right one for each platform. This probably isn't necessary, but I got bored with fighting Xcode and went with a solution that I knew I could make work. I'll revisit this at some point and simplify it.

external_commit_helper.{hpp,cpp} will run into the same issue as the tvos version would ideally be in a different file from the ios/osx one as they have basically no code in common, so it would be good to find a good solution for platform-specific files. Doesn't need to happen in this PR, though.

Changes all looks reasonable to me. Have you tested the release package stuff?

Nope. What's the recommended way to do that locally?

build.sh test-package-release attempts to mimic the Jenkins packaging pipeline.

Ugh, iPhoneSimulator: Timed out waiting 120 seconds for simulator to boot, current state is 1 is back because the tests are taking > 120 seconds to build. In 60b14f5 I worked around this by having the test targets be built along with their frameworks in their scheme's build action, but that caused failures related to code signing when I tested with build.sh test-package-release on OS X 10.10.
I have two ideas for workarounds:

Use xctool build-tests to ensure the test targets are built prior to invoking xcodebuild test. I'm not sure how people feel about introducing a dependency on xctool.
Invoke xcodebuild test twice, with the first invocation triggering a script phase that intentionally errors out before running the tests. Very ugly, but doesn't introduce extra dependencies.

I'm going to take a crack at the second approach for now.

Ok, now things are working in CI, and passing build.sh test-package-release locally as well!

Testing the dynamic framework on-device gives me:
2015-10-30 09:58:29.931 TestHost[2105:5111660] The bundle  “Tests.xctest” couldn’t be loaded because it is damaged or missing necessary resources. Try reinstalling the bundle.
2015-10-30 09:58:29.934 TestHost[2105:5111660] (dlopen_preflight(/var/mobile/Containers/Data/Application/D54995B6-3119-4948-AF96-0B57F1D79108/tmp/Tests.xctest/Tests): Library not loaded: @rpath/Realm.framework/Realm
  Referenced from: /var/mobile/Containers/Data/Application/D54995B6-3119-4948-AF96-0B57F1D79108/tmp/Tests.xctest/Tests
  Reason: image not found)

The static framework works.

Thanks for catching that, @tgoyne. That should be fixed by the latest commits. I'm surprised CI doesn't test the dynamic framework on-device at all.

The dynamic framework is indirectly tested on device via the Swift tests, so it's just testing infrastructure that isn't and not anything user-effecting.

Ah, I see.

An entry in the changelog detailing the changes to the release zip packages would be useful here I think.
That could be considered a breaking change, even.
Otherwise, OMG OMG OMG, this is such a welcomed change! Thanks @bdash

@jpsim, what changes to the release zip packages are you referring to?

what changes to the release zip packages are you referring to?

Ah never mind, I think we used to have ios/Realm.framework and ios/dynamic/Realm.framework, but now we're already keeping those in ios/static and ios/dynamic, so there's nothing to change.
This is good to go then :+1:


Add Procivis One Core implementation

Adds the Procivis One Core implementation.
If I understand correctly the configurations relevant to the VC-API issuer / verifier tests, as well as the did:key interop  should be included in this repository as opposed to the w3c test suite implementations. If this is correct I can open a follow-up pull request to the w3c implementations repository and remove the vc-api tags included there.
Thank you!

@BigBlueHat - could you please take a look? Thank you!


PR For Issue #5 | Modified frontend

I have modified the frontend of the project.

Changes suggested, please take a look.

Sir, can you kindly clarify on the changes suggested?

Just add rel="noreferrer" beside target="_blank" in the line with my GitHub URL. React gives a warning during compilation otherwise.

Actually, nvm, I'll add it. I'm merging this PR! Thanks for your contribution.


Hack in rudimentary string support

One more thing. It's of course up to you, but you may want to add your name in the comment section in the top of basic.hpp

I've updated the pull request to include your feedback

Added a common type_mismatch function
Updated example to use a string (append dots to DEPTH)
Updated README to remove message that strings aren't supported

Done. Thanks!


Home page content

Home page content needs to be improved. Noah mentioned that the word "hackathon" appears nowhere on the current homepage (https://revolutionuc.com). The home page should contain more information, talk to marketing about this.

yeah Home page content is definitely an issue, @domfarolino should look into it ASAP

As of 156416c the homepage content has been refined (and includes the word 'hackathon'!).
Closing.
🎉 🎉


docs(samples): Fix function name typo

instertingDataTypes -> insertingDataTypes
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

[ ] Make sure to open an issue as a bug/issue before writing your code!  That way we can discuss the change, evaluate designs, and agree on the general idea
[ ] Ensure the tests and linter pass
[ ] Code coverage does not decrease (if any source code was changed)
[ ] Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

@maxnis thanks for the PR. I an merge after you sign the CLA


Odata service#90

Closes #90

This change is

Review status: 0 of 13 files reviewed at latest revision, 1 unresolved discussion.

a discussion (no related file):
I'm confused about why you removed EventService and Sessions from ServiceRoot.  Don't they
also belong there?

Comments from Reviewable

Review status: 0 of 13 files reviewed at latest revision, 1 unresolved discussion.

a discussion (no related file):
Previously, danielreed (Daniel Reed) wrote…
I'm confused about why you removed EventService and Sessions from ServiceRoot.  Don't they
also belong there?

They do, but they are not implemented. So in order to the tool not fail I changed it to what is implemented only. When and if we add EventService we add it there and in the Odata. Does it make sense to you? And is it ok?

Comments from Reviewable

Review status: 0 of 13 files reviewed at latest revision, 1 unresolved discussion.

a discussion (no related file):
Previously, ffdarkpenguin wrote…
They do, but they are not implemented. So in order to the tool not fail I changed it to what is implemented only. When and if we add EventService we add it there and in the Odata. Does it make sense to you? And is it ok?

Makes sense, thanks.

Comments from Reviewable

Reviewed 13 of 13 files at r1.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

oneview_redfish_toolkit/blueprints/odata.py, line 52 at r1 (raw file):

@odata.errorhandler(status.HTTP_404_NOT_FOUND)
def not_found(error):

This method it's not used, I think you can remove it, okay?

oneview_redfish_toolkit/tests/blueprints/test_odata.py, line 28 at r1 (raw file):

class TestOdata(unittest.TestCase):

Don't need to test Blueprint when it raise an exception?

Comments from Reviewable

Review status: all files reviewed at latest revision, 3 unresolved discussions.

run.py, line 28 at r1 (raw file):
Previously, llvieira (Lucas Lima Vieira) wrote…
Use 'print' is good here?

this is from the previous patch and you commented and I replied and we are still waiting on PO decision

oneview_redfish_toolkit/blueprints/odata.py, line 52 at r1 (raw file):
Previously, llvieira (Lucas Lima Vieira) wrote…
This method it's not used, I think you can remove it, okay?

Done.

oneview_redfish_toolkit/tests/blueprints/test_odata.py, line 28 at r1 (raw file):
Previously, llvieira (Lucas Lima Vieira) wrote…
Don't need to test Blueprint when it raise an exception?

the only possible way for this to fail is if the class instantiation fails and this was tested on API tests.

Comments from Reviewable

Reviewed 2 of 2 files at r2.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable


prisma deploy yields to "request to http://localhost:4466/management failed, reason: socket hang up"

Describe the bug
Following the tutorial of doc 1.24 on setting up prisma with an existing mongodb on ubuntu 16.04
To Reproduce
Steps to reproduce the behavior:

prisma init prisma
enter mongodb connection string with admin credentials
select existing database and enter name
cd prisma & docker-compose up -d
prisma deploy

Expected behavior
Expected to run successfully
Versions (please complete the following information):

Connector: MongoDB
Prisma Server: 1.24.0
prisma CLI<EMAIL_ADDRESS>node-v11.6.0]
OS: [Ubuntu 16.04]

prisma deploy debug log:
config CWD /home/prismaUser/prisma +0ms
config HOME /home/prismaUser +3ms
config definitionDir /home/prismaUser/prisma +0ms
config definitionPath /home/prismaUser/prisma/prisma.yml +0ms
cli { isGlobal: true } +0ms
StatusChecker setting status checker +0ms
cli command id deploy +6ms
cli:plugincache Got plugin from cache +0ms
cli:plugincache /home/prismaUser/.cache/prisma/plugins.json +0ms
cli:plugincache Got plugin from cache +2ms
cli:plugincache /home/prismaUser/.cache/prisma/plugins.json +0ms
plugins findCommand prisma-cli-core +0ms
plugin requiring command +0ms
cli-engine:plugins:manager requiring /home/prismaUser/.nvm/versions/node/v11.6.0/lib/node_modules/prisma/node_modules/prisma-cli-core +0ms
cli-engine:plugins:manager required +1s
plugin required command +1s
StatusChecker setting status checker +1s
prisma definition making cluster here +0ms
client Initializing cluster client +0ms
deploy checking if project exists +0ms
client Sending query to cluster local +6ms
client http://localhost:4466/management +1ms
client
client       query($name: String! $stage: String!) {
client         project(name: $name stage: $stage) {
client           name
client           stage
client         }
client       }
client      +0ms
client { name: 'default', stage: 'default' } +1ms
deploy adding project +17s

Creating stage default for service default...  client Sending query to cluster local +17s
  client http://localhost:4466/management +0ms
  client       mutation addProject($name: String! $stage: String! $secrets: [String!]) {
  client         addProject(input: {
  client           name: $name,
  client           stage: $stage
  client           secrets: $secrets
  client         }) {
  client           project {
  client             name
  client           }
  client         }
  client       }
  client        +1ms
  client { name: 'default', stage: 'default', secrets: null } +0ms
 !
FetchError: request to http://localhost:4466/management failed, reason: read ECONNRESET
    at ClientRequest.<anonymous> (/home/prismaUser/.nvm/versions/node/v11.6.0/lib/node_modules/prisma/node_modules/node-fetch/lib/index.js:1393:11)
    at ClientRequest.emit (events.js:188:13)
    at ClientRequest.EventEmitter.emit (domain.js:441:20)
    at Socket.socketErrorListener (_http_client.js:399:9)
    at Socket.emit (events.js:188:13)
    at Socket.EventEmitter.emit (domain.js:441:20)
    at emitErrorNT (internal/streams/destroy.js:82:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:50:3)
    at process.internalTickCallback (internal/process/next_tick.js:72:19)
  util timed out +0ms
Exiting with code: 0

docker-compose.yml
version: '3'
services:
  prisma:
    image: prismagraphql/prisma:1.24
    restart: always
    ports:
    - "4466:4466"
    environment:
      PRISMA_CONFIG: |
        port: 4466
        # uncomment the next line and provide the env var PRISMA_MANAGEMENT_API_SECRET=my-secret to activate cluster security
        # managementApiSecret: my-secret
        databases:
          default:
            connector: mongo
            database: myDB
            uri: 'mongodb://admin:supersecret@<IP_ADDRESS>:27017/admin'

docker ps
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                    NAMES
9104e6b30ae0        prismagraphql/prisma:1.24   "/bin/sh -c /app/sta…"   27 minutes ago      Up 32 seconds       <IP_ADDRESS>:4466->4466/tcp   prisma_prisma_1

It successfully extracted the schema from myDB when I run prisma init and created a correct datamodel file.
Do you have a way to debug this further?

I guess dockerhost is broken somehow. I tested out some workarounds a Linux machine and you can use host networking for the time being till docker supports host.docker.internal for Linux. Host network will allow you to use localhost with docker that will point to your own machine
version: '3'
services:
  prisma:
    image: prismagraphql/prisma:1.24
    restart: always
    network_mode: host
    ports:
      - "4466:4466"
    environment:
      PRISMA_CONFIG: |
        port: 4466
        # uncomment the next line and provide the env var PRISMA_MANAGEMENT_API_SECRET=my-secret to activate cluster security
        # managementApiSecret: my-secret
        databases:
          default:
            connector: mongo
            uri: 'mongodb://localhost:27017/admin'

When i added network_mode: host, it worked for me also. Thanks a lot for saving my hours.


[C++][FS][Azure] Prevent reading or writing directory marker blobs

Describe the enhancement requested
Child of https://github.com/apache/arrow/issues/18014
Blob storage doesn't really have directories. Instead we use directory marker blobs to implement directories. Even hierarchical namespace storage accounts, that do have built in directories, implement it using directory markers.
Its possible that a user of the AzureFileSystem might accidentally try to read or write a directory marker which could cause confusion. This scenario should return a clear error message.
Hierarchical namespace storage accounts will add hdi_isFolder=true https://github.com/Azure/azure-sdk-for-cpp/blob/12407e8bfcb9bc1aa43b253c1d0ec93bf795ae3b/sdk/storage/azure-storage-files-datalake/src/datalake_utilities.cpp#L86-L90 and on flat namespace accounts the the AzureFileSystem sets is_directory=true. This would make a cheap check so that we can fail fast.
Component(s)
C++

take

A couple of discoveries after starting work on this:

On hierarchical namespace accounts Azure will block this and return [OperationNotSupportedOnDirectory] 400 The requested operation is not supported on a directory.. This is good apart from it tends to happen during the Flush call in the destructor and the error is not handled gracefully.
On flat namespace accounts we ensure that directory marker blobs always have a trailing / and files never have a trailing /. This prevents accidentally reading or writing a directory marker blob but it also allows creating a file and a directory with exactly the same name, which seems to cause significant problems for GetFileInfo. @felipecrv do you have any thoughts on this?

To be more concrete the new tests that fail are https://github.com/Tom-Newton/arrow/pull/5/files#diff-7d2cbf9c6abf1ee980b8cf5a79e222543c17b3d93b12c4c0c9fa123b1bb200b6

Maybe we should just call GetFileInfo prior to reading or writing instead of just calling GetProperties directly. My only concern is if that reduces performance. I will need to look at the code in more detail.

Its possible that a user of the AzureFileSystem might accidentally try to read or write a directory marker which could cause confusion.

Can you clarify the sequence that leads to the confusion? I think we should aim for having no confusion if the user writes to Azure Storage only via the arrow::FileSystem API and fail-fast on confusion created by other writers.
For example, I agree we shouldn't allow creation of files that get the same name as a directory (including implied directories [when a marker doesn't exist, but some blob exists with that directory as a path-prefix]).

On flat namespace accounts we ensure that directory marker blobs always have a trailing / and files never have a trailing /. This prevents accidentally reading or writing a directory marker blob but it also allows creating a file and a directory with exactly the same name, which seems to cause significant problems for GetFileInfo. @felipecrv do you have any thoughts on this?

I think we can figure cheap ways (with at most one extra request) to check against this. Preventing file open with paths containing trailing slashes is a good start because it will catch most of the times this would happen in practice.

Maybe we should just call GetFileInfo prior to reading or writing instead of just calling GetProperties directly. My only concern is if that reduces performance. I will need to read the code in more detail.

We might need a lower-level helper: we can get information about the existence of both path and path/ with a single list-blobs with / delimiter -- that would cover implied directories as well.

Its possible that a user of the AzureFileSystem might accidentally try to read or write a directory marker which could cause confusion.

Can you clarify the sequence that leads to the confusion? I think we should aim for having no confusion if the user writes to Azure Storage only via the arrow::FileSystem API and fail-fast on confusion created by other writers.

Imagine the user does this
fs->CreateDir("container/directory");
fs->OpenAppendStream("container/directory");

Currently on flat namespace this will create the case of file and directory with the same path. On hierarchical namespace it fails with an un-recoverable error when the ObjectAppendStream gets destructed. This is because the destructor attempts to Flush and subsequently runs into Azure Error: [OperationNotSupportedOnDirectory] 400 The requested operation is not supported on a directory.


api.counterparty.io SSL support

Using SSL with api.counterparty.io fails on CORS errors. Need to update proxy settings to pass correct headers in response to pass OPTIONS preflight checks.

Switched on 1d2b78c622670dcafbce8987ea30f363f36078e6


OAM external renderer interface writes goa_element_id always as 0

The external renderer interface for OAM writes goa_element_id always 0. This has to be mapped to element id appropriately.
The issue was found during code inspection by @dfisc.

Fix available on main branch!


page.node.body.slice is not a function

Hi there,
in your "Getting started" guide on step 6 you suggest using <meta name="description" content={ page.node.body.slice(0, 150) } /> but I think this line is outdated, as page.node.body returns an object and slice doesn't work with object.
What is your suggested way to deal with that? How can I transform content from markdown to string? Do you provide any helper for that?
Cheers
Marc

Indeed, this is outdated. Let me think and get back with an intuitive solution.

<meta name="description" content={ !isLoading && page.node.body.slice(0, 150) } /> or if not works <meta name="description" content={ page && page.node && page.node.body.slice(0, 150) } />

body is a JSON tree. I will make an helper to convert it as text so the slice can be used :)

Nice then I can use my Truncate component and ReadingTime component 🥇

A textRenderer function will be exposed in alpha 6. step 6 of the getting started will be updated accordingly. It will convert react tree or html to raw text :)


[fix][ws] Remove unnecessary ping/pong implementation

Motivation
This PR removes an incorrect implementation of the websocket proxy ping/pong feature.
The feature was requested here https://github.com/apache/pulsar/issues/10014. When it was implemented in https://github.com/apache/pulsar/pull/10035, it was added as an endpoint instead of as support for every endpoint, like our /producer, /consumer, and /reader endpoints. Notably, these endpoint already have support through the framework, so there is no reason for the /pingpong endpoint. I propose we remove it.
Note: since this endpoint should not be used by anyone, I propose we cherry pick this to all active branches.
Modifications

Remove the /ws/pingpong and the /ws/v2/pingpong endpoints and all associated code

Verifying this change
A test is modified to prove that the framework gives us the ping/pong support out of the box.
Does this pull request potentially affect one of the following parts:
Removes an unnecessary endpoint.
Documentation

[x] doc-not-needed

Ping/pong support is not documented here https://pulsar.apache.org/docs/3.0.x/client-libraries-websocket/, so I think we are good to skip docs.
Matching PR in forked repository
PR in forked repository: https://github.com/michaeljmarshall/pulsar/pull/52

/pulsarbot rerun-failure-checks

Good work @michaeljmarshall .


LSD renew and return should capture potential server errors

https://github.com/readium/readium-desktop/blob/42a6ab3efa20879db9f8f4b6503e15551b93df19/src/main/services/lcp.ts#L187
https://github.com/readium/readium-desktop/blob/42a6ab3efa20879db9f8f4b6503e15551b93df19/src/main/services/lcp.ts#L214
=> use try/catch to capture a rejected promise.
See the LCP/LSD API usage documentation (scroll to the very bottom):
https://github.com/readium/r2-navigator-js/blob/develop/README.md#lcp
Copy:
// Both LSD "renew" and "return" interactions can return errors (i.e. Promise.reject => try/catch with async/await)
// when the server responds with HTTP statusCode < 200 || >= 300.
// The err object in the above code snippet can be a number (HTTP status code) when no response body is available.
// Otherwise, it can be an object with the httpStatusCode property (number) and httpResponseBody (string)
// when the response body cannot be parsed to JSON.
// Otherwise, it can be an object with the httpStatusCode property (number) and other arbitrary JSON properties,
// depending on the server response. Typically, compliant LCP/LSD servers are expected to return Problem Details JSON (RFC7807),
// which provides title type and details JSON properties.
// See https://readium.org/technical/readium-lsd-specification/#31-handling-errors

Same with register:
https://github.com/readium/readium-desktop/blob/42a6ab3efa20879db9f8f4b6503e15551b93df19/src/main/services/lcp.ts#L161

Related issue: https://github.com/readium/readium-desktop/issues/540

Was duplicated: https://github.com/readium/readium-desktop/issues/540


Rename .destroy to .destroyData

This should help make it less confusing since .destroy() is used in place of .close() in a lot of places.
Deprecated .destroy for now since there's some code using it already. 😅

ping @mafintosh @andrewosh


Update DeltaMergeBuilder documentation

Delta Python API docs tells that "Using this builder, you can specify 1, 2 or 3 when clauses of which there can be at most 2 whenMatched clauses and at most 1 whenNotMatched clause." (Python Docs and also JavaDocs)
Delta Docs tells that "There can be any number of whenMatched and whenNotMatched clauses." (source)
The API Docs conflict with the 0.8.0 release notes (link)

Good catch. We forgot to update them. Feel free to raise a PR to fix them.

Fixed by https://github.com/delta-io/delta/commit/a71cc67f640418f82195aef98a6e7ba0c7a647ff

Fixed by https://github.com/delta-io/delta/commit/a71cc67f640418f82195aef98a6e7ba0c7a647ff