Using elevate disables all print outputs in compiled console window

I'm writing this piece of software currently: https://github.com/Zenahr/ALACS
and am using this lib to allow it to work properly.
It does solve the problem I had (monitoring keyboard input while having the program window being not focused), however after implementing elevate the console window remains blank.
Why is that? Am I using the API wrong? Is there an option I don't know of that I could pass to elevate()?
This is my main code for reference:
import pynput
from pynput import keyboard
import lib
from lib import click_random_legend, click_main_legends
import json
from command_runner.elevate import elevate

ACTIVATION_BUTTON = json.load(open('./config.json'))['key']

def main():
    def on_press(key):
                if key == keyboard.Key[ACTIVATION_BUTTON]:
                    if not json.load(open('./config.json'))['select_random_legend']:
                        click_main_legends()
                    else:
                        click_random_legend()

    def on_release(key):
        pass

    print('BOOTING UP ALACS ...')
    print('BOOTED UP ALACS')
    print('MAKE SURE TO CLOSE THIS WINDOW AFTER CLOSING APEX')
    print('TO CHANGE THE ACTIVATION KEY READ THE INSTRUCTIONS FOUND IN instructions.txt')
    print('ACTIVATION KEY IS SET TO:', '>>> ', ACTIVATION_BUTTON, ' <<<')
    print('LISTENING FOR ACTIVATION KEY ...')

    with keyboard.Listener(
            on_press=on_press,
            on_release=on_release) as listener:
        listener.join()

if __name__ == '__main__':
    elevate(main)

Hello,
This comes from the fact that the windows API that reloads the executable with UAC privileges (ShellExecuteEx) does not allow to capture console output.
Unfortunately there's not much I can do about it.
In order to have output, such programs are supposed to output data whether via a GUI or via a log file.

Thanks a lot! I know what to do then. Thanks for the explanation.


Remove links to missing documentation for deprecated components and APIs

Links to BackAndroid, ListView and ListViewDataSource should probably be removed because
• documentation does not exist
• bindings don't exist and
• they are deprecated

@MoOx Do you think it would make sense to add bindings for these deprecated components?
Surely no one would use these for new projects - is it possible that people are using them in old projects they want to migrate?

Maybe we could leave this things so people that would look for those won't ask question?
And only remove them when they are officially removed from RN?

Maybe we could leave this things so people that would look for those won't ask question?
And only remove them when they are officially removed from RN?

Should I simply add one-liners explaining that these are deprecated and BackHandler, FlatList, etc. should be used instead

That can be cool

CameraRoll.md also needed to meet prettier.

(@sgny you can run yarn format at the root of the repo - but with the hook in place, we should need that only when we update the formating tools)

(@sgny you can run yarn format at the root of the repo - but with the hook in place, we should need that only when we update the formating tools)

yarn format does not match .rei files, should they not be?

They should be, that my mistake :)


installCordovaPlugin cleanup

I've found a file installCordovaPlugin that can make problems.

We need to check whether process.cwd() directory look like a cordova project without cordova installed.
If directory looks like cordova project we need to verify it with cordova info.
If directory is definitely not a cordova project we can process.exit(0).
If cordova info failed with unexpected error (example: 'cordova is not found') we should fail too.
Than we can process installation.

Fix at your discretion.

This would be better but right now since the only thing we are worried about are our own devs building this isn't a show stopper.


New model | Yi - Lightning

Seems like a new chinese SOTA MoE model. The successor of yi-large from 01.AI
https://x.com/Senseye_Winning/status/1845777940338143586
Top performance on lmarena.ai ( especially math and coding, besides sonnet 3.5).
Seems to beat Qwen 2.5 72B
Glm-4-plus and Yi lightning-lite are also new and impressive.

Added already to the leaderboard. Thanks for the suggestion.


Only allow --kubeconfig and --context argument on gefyra up

These arguments can be passed on to subsequent actions as well. Yet, this can lead to problems if the values change.
I'd say we persist the "up-config" somewhere and reuse it for other actions.

This will Gefyra users allow changing the global kubeconfig while keeping Gefyra's infrastructure and subsequent actions functioning.


Insert QoS markers setting

Could you please add some clarification as to why the Teams Admin Portal>Meeting settings setting: "Insert QoS markers for real-time traffic" is off by default?
Also, when this setting should not be turned on and reasoning why?
Why is this setting under "Meetings setting" and not Org-wide settings>Teams settings?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 76c2487c-044d-1349-708a-5841fcb21ab8
Version Independent ID: b7033454-1a9c-48d4-8004-78415c5feb89
Content: Implement Quality of Service in Microsoft Teams - Microsoft Teams
Content Source: Teams/QoS-in-Teams.md
Service: msteams
GitHub Login: @LanaChin
Microsoft Alias: v-lanac

Hello @SvenBell How are you? Hope you are doing good. 👍
I am afraid we can not help you on the reason behind design decisions taken by the product team, as to why some settings are under specific menus or why would you disable QoS*, as this issue resource is specifically to report issues in documentation like for example wrong steps or missing parameter descriptions. I recommend in this case you kindly visit Microsoft Teams User Voice to propose an idea to be heard by the Product Team.
About Disabling QoS I can give you my field experience, sometimes I would want this for troubleshooting scenarios or because there are already other devices on the network that prioritize packets and you do not want to redundantly add this markings, however that is just my thoughts
Hope I could help you on your inquiry. Have a great day.

Hello @scanum Manuela please close this thread.

@SvenBell Thank you for submitting feedback. We understand that this issue has been resolved.
Please feel free to re-open this issue if there is a specific area of the docs that we can improve or make better. Thank you.


Cleanup panicking test threads

Depends on #322.
Updates  #321.

There seems to be a race condition in the oneshot_multi_thread_send_close_stress test. In a loop it creates two threads, on one thread it drops the receiver and on the other thread it send a value, which means that sending sometimes succeeds and sometimes fails. @stjepang any ideas on what would be the best way forward?

Looks like that test makes is nonsensical. I'd say let's just pull tx.send(1) out of assert_eq!(tx.send(1), Err(SendError(1))) - so remove the assert but keep the send operation.
And add a comment on top of the file saying "Remove assertion from oneshot_multi_thread_send_close_stress."

Fixed the race condition and added the change to the list.

lgtm, thanks!! :)
bors r+


Referer and Origin headers removal

Is it possible to remove Referer and Origin headers? The phish url get leaked in this way.

add me on @piperberlesimo to help you out on it

**Hi 👽 ! If you are interested in ⚙Advanced Phishing⚙ and the ✨Evilginx3✨ tool then I offer you Google Gmail and Custom Phishlets with a ✅Free Tutorial✅ which arrives if the 📈Telegram reaches 50 Subscribers📈
⏳ GOOGLE GMAIL PHISHLET 2024 WITH PROOF ⏳
->
⛔https://www.youtube.com/watch?v=nA47UknIE6A⛔
🔓 Ask your questions and a free tutorial from 50 subs on telegram !!!
->
📩https://t.me/Noremorse1011📩**


feat(block-producer): re-add batch inputs

This was removed as part of the mempool feature, but should not have been.
I've renamed the function get_batch_inputs and I'm wondering if we shouldn't rename the proto definition and domain object similarly?
I'm assuming there might be more input fields coming in the future so having it be more specific is ok?
Closes #566

Looks good! Thank you! I left a couple of questions inline.

I've renamed the function get_batch_inputs and I'm wondering if we shouldn't rename the proto definition and domain object similarly?
I'm assuming there might be more input fields coming in the future so having it be more specific is ok?

I think this make sense. The only question is whether we'd need to use the same objects (e.g., the note authentication info) in multiple places - e.g., for transactions, batches, blocks.

Okay lets minimize the diff, and revisit this once we know the proof requirements.


bars tooltip are getting stuck

Bars tooltip is getting sticked sometimes, it is related to onMouseLeave which seems not being triggered when user moves cursor fast.

My suggestion here would be to use a library to help us with these interactions, as they can be complex. This PR is a draft to bring in @floating-ui which can help (formerly it was popper JS - which I think the Tippy library uses). This is slightly "lower level" than TippyJS, but actually might be the level we want here, so we have some greater control.

Moving this back to the backlog to be re-prioritized


Good to have the topologySpreadConstraints in the statefullset

Is your feature request related to a problem? Please describe.
A section for topologySpreadConstraints in the neo4j statefullset would be great to have.
{{- if .Values.topologySpreadConstraints }}
      topologySpreadConstraints:
      {{- range .Values.topologySpreadConstraints }}
      {{- if and .maxSkew .topologyKey }}
      - maxSkew: {{ .maxSkew }}
        topologyKey: {{ .topologyKey }}
        {{- if .whenUnsatisfiable }}
        whenUnsatisfiable: {{ .whenUnsatisfiable }}
        {{- end }}
        labelSelector:
          matchLabels:
            {{- include "neo4j.selectorLabels" $ | nindent 12 }}
      {{- end }}
      {{- end }}
{{- end }}

@prasanna-ranga this is implemented in the below PRs
https://github.com/neo4j/helm-charts/pull/294
https://github.com/neo4j/helm-charts/pull/293
Will be part of the upcoming helm charts releases


Tests to reproduce 681

By the way, what do you think about headless chrome instead of nodejs for testing?

I think nodejs is already installed and run by default in GHCJS unit tests.  For non-graphics issues, that seems like the right way to go.  If, in the future, we want to test the accuracy of graphics code, it might be worth looking into a more complete browser implementation.

We need to adapt our codebase to work in different environment.
So we anyway need to adapt codebase, possibility to throw events or access to state during execution is required, but if is possible easy run tests using browser environment - no need to make things like StubCanvas.
More system dependencies for testing, but less #ifdef-s...

Sure, but I don't think running in headless chrome fixes this problem anyway.  You want to capture how often the step function is iterated, and this is just as invisible to headless chrome as it is to node.js.  Drawing code is not relevant here, and stubbing it out is the right thing to do.

Ok.

I want to try rename StubCanvasM back to CanvasM. We already control which version of CanvasM is used by preprocessor commands.

$ cabal test
Preprocessing library for codeworld-api-0.3.1..
Building library for codeworld-api-0.3.1..
Preprocessing test suite 'unit-tests' for codeworld-api-0.3.1..
Building test suite 'unit-tests' for codeworld-api-0.3.1..
Linking dist/build/unit-tests/unit-tests.jsexe (Main,TestDriver)
Running 1 test suites...
Test suite unit-tests: RUNNING...
Test suite unit-tests: PASS
Test suite logged to: dist/test/codeworld-api-0.3.1-unit-tests.log
1 of 1 test suites (1 of 1 test cases) passed.

but
$ cat dist/test/codeworld-api-0.3.1-unit-tests.log
Test suite unit-tests: RUNNING...
### Failure in: 0:Time step elision
test/TestDriver.hs:15
Is time step ellision ok
Cases: 1  Tried: 1  Errors: 0  Failures: 1
Test suite unit-tests: PASS
Test suite logged to: dist/test/codeworld-api-0.3.1-unit-tests.log

What is reason for this?

I'm looking at this now.  main = exitFailure as a test definitely succeeds, so it's not ignoring the exit code.  I have no idea what you're seeing.

Okay, I don't see the same thing:
$ ./test.sh
===== IN codeworld-api, RUNNING: cabal_install --ghcjs --enable-tests --only-dependencies
Warning: the --global flag is deprecated -- it is generally considered a bad
idea to install packages into the global store
Resolving dependencies...
All the requested packages are already installed:
Use --reinstall if you want to reinstall anyway.
===== IN codeworld-api, RUNNING: cabal_configure --ghcjs --enable-tests
Warning: the --global flag is deprecated -- it is generally considered a bad
idea to install packages into the global store
Resolving dependencies...
Warning: The following packages are likely to be broken by the reinstalls:
codeworld-base-<IP_ADDRESS>
Continuing even though the plan contains dangerous reinstalls.
Configuring codeworld-api-0.3.1...
Building codeworld-api-0.3.1...
Installed codeworld-api-0.3.1
===== IN codeworld-api, RUNNING: cabal test
Preprocessing library for codeworld-api-0.3.1..
Building library for codeworld-api-0.3.1..
Preprocessing test suite 'unit-tests' for codeworld-api-0.3.1..
Building test suite 'unit-tests' for codeworld-api-0.3.1..
Linking dist/build/unit-tests/unit-tests.jsexe (Driver,Main)
Running 1 test suites...
Test suite unit-tests: RUNNING...
Driver:
  time step ellision: [Failed]
expected: 0
 but got: 1

         Test Cases  Total
 Passed  0           0
 Failed  1           1
 Total   1           1
Test suite unit-tests: FAIL
Test suite logged to: dist/test/codeworld-api-0.3.1-unit-tests.log
0 of 1 test suites (0 of 1 test cases) passed.

========== Aborting: Command failed. ==========
DIRECTORY: codeworld-api
COMMAND  : cabal test
EXIT CODE: 1
===============================================

This was with the test suite, but not with your new flag or changes to CodeWorld.Driver, but these really shouldn't matter in this case.

By the way, I understand why you needed to add the flag to codeworld-api, but we can't leave it there.  With that flag in place, running tests on the production server breaks the server, because it reinstalls a codeworld-api version that doesn't work.
Instead, I guess we need to duplicate the configuration from the library into the test suite, so that the same source files are rebuilt as part of the test suite itself.

previous problem with success tests resolved in https://github.com/google/codeworld/commit/0a30df5e510825e715a0200f42ca988ed7fd025c
"Instead, I guess we need to duplicate the configuration from the library into the test suite, so that the same source files are rebuilt as part of the test suite itself."
How to do this? Duplicate codeworld-api sources as other-modules?

Right, you'd want to add both test and src in Cabal's Hs-source-dirs property, and merge the rest of the config over, as well.  So essentially, you're rebuilding the source code from codeworld-apias part of the unit test.  That's actually what we want, since we want to build it with different preprocessor flags.
The unfortunate part of that the config sections have to be duplicated in the cabal file.  This could probably be avoided with something like hpack, maybe?  But I think it's okay to just copy.

Ok. I'll copy, thanks.

previous problem with success tests resolved in 0a30df5

Okay, yes, I see.  You were calling runTestTT which returns counts of test failures, but then ignoring them and letting main succeed either way.  The simplest answer would have been to throw an exception if a test failed, but I like the solution of using test-framework instead.

@cdsmith I trying to mock browser, and it seems to going too deep.
for example some DOM-around functions here https://github.com/google/codeworld/pull/894/commits/ec2c7c0bf17bcfff9ccfe81abdfb319bece3035e#diff-3e471af93b2d4fa44b0cedd866cecbb8R872 . It is not all. Need to patch canvas.getWidth, things like setAttribute etc. It is going to become boilerplate explosion.
Either I following wrong way or there is better way to do this.
I think need to separate data and view. Functions which working with state (stepHandler and eventHandler) and drawing function, then pick state functions to tests.

Yeah, that strikes me as the wrong way to do it.  Instead of trying to mock out the browser, I think what's wanted here is to move that stuff below an abstraction layer that hides the browser bits.
I don't know how to help you here.  This is a pretty sticky problem.  I think you've made good progress, but maybe it's time to shift gears again and look for more low-hanging fruit.

@cdsmith  I got it! I'm happy! :smile: https://github.com/google/codeworld/pull/894/files#diff-58d5580dae82e9a33e1a6745683014cbR22

At least part of problem.

btw modifyMVarIfDifferent mv id makes test pass.

Sorry, I'm confused.
The last test you wrote should fail.  modifyMVarIfDifferent is intended to compare for pointer equality, because in general states cannot be compared for equality.  Your expression \n -> n + 1 - 1 is semantically the identity function, but it doesn't preserve sharing, and your test proves that.  But this is all intended.  (Technically, you could argue it should be called unsafeModifyMVarIfDifferent instead, I guess)
The bug is that the event loop in run isn't preserving sharing.  We can't reproduce this without running the event loop.

Ok, place where we looking if next loop turn need time is https://github.com/google/codeworld/blob/master/codeworld-api/src/CodeWorld/Driver.hs#L1546
this https://github.com/google/codeworld/blob/master/codeworld-api/src/CodeWorld/Driver.hs#L1548 line is forever True, because we modify state variable here https://github.com/google/codeworld/blob/master/codeworld-api/src/CodeWorld/Driver.hs#L1540 (loop starts with nextNeedsTime == True)
In runInspect we wrap eventHandler and stepHandler into DebugState, so originally (const id) becomes something else(i guess), fullStepHandler forever modify value and nextStateName is forever /= nextStateName

I reproduced this by just commenting and rebuilding.

Other place is probably isUniversallyConstant as you noticed before. https://github.com/google/codeworld/blob/master/codeworld-api/src/CodeWorld/Driver.hs#L1124 f undefined old where 'f' ('fullStepHandler') will try to evaluate first argument will raise exception -> will become False

So I guess root of problem in wrapping of original state into debug state in runInspect, which turns each pointer-equality invariant into true equality. Maybe need replace wrapping by something like DebugMonad... I'm not sure.

Okay, if I were you, I'd start writing some unit tests that test the pieces.  For example, you may want to check that wrappedStep preserves identity precisely when its argument function does.  You can write that test as follows:
identical :: a -> a -> Bool
identical !x !y = case reallyUnsafePtrEquality# x y of
    0# -> False
    _  -> True

wrappedStepKeepsUnderlyingSharing :: Assertion
wrappedStepKeepsUnderlyingSharing = do
    let wrapped = wrappedInitial 42
    assertBool "wrapping shared identity is shared" $
        identical wrapped (wrappedStep (const id) 1 wrapped)

    let unsharedId x = (x + 1) - 1
    assertBool "wrapping unshared identity is unshared" $ not $
        identical wrapped (wrappedStep (const unsharedId) 1 wrapped)

If you work your way down layers, your tests may fail at some point, and you'll know that's the point where the problem lies.

Thanks. I'm not figured out with reallyUnsafePtrEquality#. Just done with makeStableName. It is good. So now I can try to fix #681

Thanks. I'm not figured out with reallyUnsafePtrEquality#. Just done with makeStableName. It is good. So now I can try to fix #681

Sure, makeStableName and reallyUnsafePtrEquality# ultimately do the same thing: they observe reference equality.  So you can implement identical just as well like this:
identical :: a -> a -> Bool
identical !x !y = unsafePerformIO $ do
    nx <- makeStableName x
    ny <- makeStableName y
    return (nx == ny)

Does this test fail?  If so, then yes, let's fix it.  Otherwise, you probably want to add tests at different layers.  I definitely want to have a failing test case.  This has broken before, and I'd like to get a test in place that can detect when it happens so I don't have to reopen this bug every few months.

wrappedStep did not respect identity. Now it does :smile: But it freezes updating of lastInteractionTime. I'm not sure if this breaks something.
Pointer equality works well in pure functions even if we update the value,  but if we use modifyMVar + readMVar updating value to semantically same will change pointer. There are other places where happens update instead of identity return. I'm looking further.

eventHandlerWrapper from runInspect is first candidate.

I'm stuck with current situation.
samePointer function checks stable name equality. I inserted this function into both wrappedStep and wrappedEvent. With wrappedStep working as expected, but with wrappedEvent going on something weird.
Running 1 test suites...
Test suite unit-tests: RUNNING...
Driver:
True
  wrapping of shared identity is shared (steps): [OK]
True # debug print in wrappedEvent confirms names equality before and after applying handler to state
False # but same debug print in test says the opposite
  wrapping of shared identity is shared (events): [Failed]

How is possible than pattern-matched wrapped state lose identity here https://github.com/google/codeworld/commit/95ea898267aa9e6d55e969446ddcb84dfabf8510#diff-3e471af93b2d4fa44b0cedd866cecbb8R1998 ?

I'm merging this partial work, since you're planning to switch gears and look at UI stuff again.


runway:generate-migrations creates migration filenames ending with _tables not _table

Bug Description
As title. Migration gets created, but when you actually migrate the table an error "Cannot declare class CreateOrdersTable, because the name is already in use" is generated because the filename is tables not table.
Steps to reproduce

Add resource like

        \App\Models\Order::class => [
            'name' => 'Orders',
            'blueprint' => 'orders',
        ],

Run php please runway:generate-migrations order
See order migration correctly created, but not the ending of the filename.
Run the migration.
See the error PHP Fatal error:  Cannot declare class CreateOrdersTable, because the name is already in use in /var/www/html/database/migrations/2021_10_30_201449_create_orders_tables.php on line 7
Discover the reason for the mysterious error on SO: https://stackoverflow.com/a/67595347/1281101
Make PR to fix

Environment
Statamic 3.2.19 Pro
Laravel 8.68.1
PHP 8.0.7
doublethreedigital/runway 2.1.31
spatie/statamic-responsive-images 2.8.5

Thanks - released your fix as part of v2.1.32


Automatically delete temp files after they've been extracted and copied, just like the batch script.

Reduces how much data is left over when it's done.

Should probably have this be on by default since people probably would prefer to have temp files be deleted automatically once they're done being used.


Setup for project deployment

Create an account for the project on infinityfree.com

Account created, ready for deployment


5.9.0 not sending data to Home Assistant

Version
Checklist:

[x ] I am not using Home Assistant. Or: a developer has told me to come here.
[ x] I have checked the troubleshooting section and my problem is not described there.
[ x] I have read the changelog and my problem is not mentioned there.

Build/Run method

[ x] Docker
[ ] PKG
[ ] Snap package
[ ] Manually built (git clone - yarn install - yarn run build )

Zwavejs2Mqtt version: 5.9.0
Z-Wave JS version: not obvious where this is in control panel
Describe the bug
5.9.0 not sending data to home assistant, rolling back to 5.8.0 immediately solves issue. No obvious errors in the log.
Sensors in HA appear frozen in their state, if I restart mosquitto or HA they report no data at all.
To Reproduce
Move from 5.8.0 to 5.9.0
Expected behavior
5.9.0 should work as 5.8.0
Additional context
None
Please let me know what else I can attach for debugging purposes

let's wait for new zwavejs update to see if it's still broken or not

I haven't dared upgrade beyond 5.8.0 yet as upgrading this image is always potluck.
Whilst I appreciate your efforts on making zwavejs2mqtt available for free ( :-) ), there needs to be a beta channel for testing before you push things out to latest.  I run around 20 docker containers and this one is by far the most unreliable with quite frequent breakages.
I should be able to test the latest latest version on Monday but can't right now so am pinned to 5.8.0.

@Altycoder I'm sorry for this, there is some things BTW that doesn't depend on me, most of this is caused by changes on the underlying zwave-js

@robertsLando I understand that, that's why moving to a beta release, with a corresponding stable release after 1-2 weeks of testing would be beneficial?
I've tried 5.10.1 this morning and it seems to work so far (2 min of testing)

I understand that, that's why moving to a beta release, with a corresponding stable release after 1-2 weeks of testing would be beneficial?

Could make sense, yes :) I need to understand how I could manage this on docker as now tags point to releases

@robertsLando could you not tag each new release as "beta" and move the previous release from "beta" to "stable" rather than "latest" once you know that there aren't any issues?  That way most users can track "stable" rather than "latest" which can be a bit too bumpy.  I now pin my zwavejs2mqtt container to a specific release (e.g. 5.10.1 now) and then check on here for issues before I move up a release.  By moving to beta/stable you'd effectively be doing the same which would give most users a much smoother ride.
However you would need a number of users to be willing to track "beta" and provide feedback otherwise this wouldn't work.

Hi, I think I spoke too soon, 5.10.1 still isn't sending data to home assistant correctly.  I've just moved to the new HA stable image and all my zwave sensors are unavailable after 10 min.  Moving back to 5.8.0 fixes immediately.

@Altycoder JTK are you using mqtt discovery or hass integration?

mqtt discovery (Mosquitto broker)

Is store flag enabled under mqtt settings?

Yes

Ok that's the problem. Iin 5.9.0 I swithed from mqtt nedb store to level store because nedb is bugged and the package wasn't maintained anymore, turns out also level store is bugged, in next releases I simply disable persistent storage on backend side until I found a working store (I think I may need to implement my own as there aren't other alternatives right now).

So those of us using home assistant should stay pinned to 5.8.0 or should it work if we disable the store flag?

So those of us using home assistant should stay pinned to 5.8.0 or should it work if we disable the store flag?

Last version should work as I have disabled store

Just moved to 5.11.0 and store is enabled under z-wave settings, does this matter or should I turn it off?
I'll report back later or tomorrow if it works with HA or not as sometimes it takes a little while to fully test.

does this matter or should I turn it off?

Nope, it's disabled at all in MqttClient code, so enabled or not in settings it doesn't change

Seems to be working fine now, thanks


How not to sign out same user on all other machines when a user signs out

When a user signs out from a machine, other users using same username on different machines will also be signed out at the same time. This is the default behavior and I can see that this is done by resetting user's remember token.
However, I need other users to remain signed-in on their machines even after any of the users has signed out. Is there an option for me to override this behavior in config/initializers/clearance.rb or I should just monkey-patch the Clearance::Session#sign_out method? Thank you.
module Clearance
  class Session
    ... (omitted)

    def sign_out
      if signed_in?
        current_user.reset_remember_token!
      end

      @current_user = nil
      cookies.delete REMEMBER_TOKEN_COOKIE
    end

    ... (omitted)
  end
end

I know it's an old one, but I'm also curious about this one, and sadly the link to google groups doesn't work for me.
Is monkey-patching sign_out still the only way to achieve this? Is this something open for discussion / PRs ?

I know it's an old one, but I'm also curious about this one, and sadly the link to google groups doesn't work for me.
Is monkey-patching sign_out still the only way to achieve this? Is this something open for discussion / PRs ?

I'm not an active maintainer of this project anymore so can't speak to library changes but monkey-patching sign_out in the controller where you've mixed in Clearance::Controller or Clearance::Authentication should still work.
def sign_out
  cookies.clear
end

That's heavy-handed but may work. The goal is to skip the current_user.reset_remember_token! portion of https://github.com/thoughtbot/clearance/blob/bff3aeb02a12e8ec9aa5658fee1d8bf9afe98e55/lib/clearance/session.rb#L80

I'm not an active maintainer of this project anymore so can't speak to library changes but monkey-patching sign_out in the controller where you've mixed in Clearance::Controller or Clearance::Authentication should still work.
def sign_out
  cookies.clear
end

That's heavy-handed but may work. The goal is to skip the current_user.reset_remember_token! portion of https://github.com/thoughtbot/clearance/blob/bff3aeb02a12e8ec9aa5658fee1d8bf9afe98e55/lib/clearance/session.rb#L80

Thanks @croaky
From experimenting a bit I’m not sure it’s as simple.
I don’t want to clear all cookies, and deleting one cookie might require passing the options.
More important however, I want to also clear @current_user ?
So I think it does require monkey patching to have a more robust solution?
I’m just a bit surprised that all clearance users are happy with logging out having an effect on all devices (or many are monkey patching?)

Thanks @croaky
From experimenting a bit I’m not sure it’s as simple.
I don’t want to clear all cookies, and deleting one cookie might require passing the options.
More important however, I want to also clear @current_user ?
So I think it does require monkey patching to have a more robust solution?
I’m just a bit surprised that all clearance users are happy with logging out having an effect on all devices (or many are monkey patching?)

Can't speak to the broader questions but a few other ideas to try:
def sign_out
  request.env[:clearance] = Clearance::Session.new(request.env) # @current_user is nil on instantiation
  session[:return_to] = nil
  cookies.delete "remember_token"
end

Can't speak to the broader questions but a few other ideas to try:
def sign_out
  request.env[:clearance] = Clearance::Session.new(request.env) # @current_user is nil on instantiation
  session[:return_to] = nil
  cookies.delete "remember_token"
end

That’s clever! thank you. I’ll give it a try tomorrow 👍

That’s clever! thank you. I’ll give it a try tomorrow 👍


fix typo

Test failure somewhat happens.

This is going to be superseded by other outstanding ViT changes.


dataset download problem

Thank you for your excellent work!
But I met the problem when I try to download dataset form the official website. I have waited for several days, but the result is still the same. Can you help me with that?

The downloading problem has been solved. Please try again.


Add driver instance getters to support elastic apmsql.Open(name, driver)

I have no context or rational to approve this PR. It also seems strange.


install error

Details
When I executed yarn add -D @nuxtjs/seo in VSCode, an exception occurred. The error message is as follows:
yarn add v1.22.21
[1/4] Resolving packages...
[2/4] Fetching packages...
warning<EMAIL_ADDRESS>The engine "vscode" appears to be invalid.
[3/4] Linking dependencies...
warning " ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning " ><EMAIL_ADDRESS>has unmet peer dependency "vite@".
warning "@nuxt/devtools ><EMAIL_ADDRESS>has unmet peer dependency "vite@".
warning "@nuxt/devtools ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^4.0.0 || ^5.0.0-0".
warning "@nuxt/devtools ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^4.0.0-0 || ^5.0.0-0".
warning "@nuxtjs/seo > @nuxtjs/sitemap ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "@nuxtjs/seo > @nuxtjs/sitemap > @nuxt/devtools-ui-kit ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>"@nuxtjs/seo > nuxt-schema-org ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "@nuxtjs/seo > nuxt-schema-org ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "@nuxtjs/seo > @nuxtjs/sitemap > @nuxt/devtools-ui-kit > @unocss/nuxt ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^3.0.0-0 || ^4.0.0 || ^5.0.0-0".
warning "@nuxtjs/seo > @nuxtjs/sitemap > @nuxt/devtools-ui-kit > @unocss/nuxt ><EMAIL_ADDRESS>has unmet peer dependency "webpack@^4 || ^5".
warning "@nuxtjs/seo > @nuxtjs/sitemap > @nuxt/devtools-ui-kit > unocss ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS><--- Last few GCs --->
[81788:00000248C24D3460]   287427 ms: Mark-sweep 4042.0 (4129.2) -> 4034.5 (4138.2) MB, 748.4 / 0.0 ms  (average mu = 0.478, current mu
= 0.511) allocation failure; scavenge might not succeed
[81788:00000248C24D3460]   289371 ms: Mark-sweep 4050.6 (4138.6) -> 4042.0 (4145.3) MB, 1890.8 / 0.0 ms  (average mu = 0.280, current mu = 0.027) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 00007FF79804194F node_api_throw_syntax_error+175855
2: 00007FF797FC6026 SSL_get_quiet_shutdown+59654
3: 00007FF797FC7D10 SSL_get_quiet_shutdown+67056
4: 00007FF798A721F4 v8::Isolate::ReportExternalAllocationLimitReached+116
5: 00007FF798A5D582 v8::Isolate::Exit+674
6: 00007FF7988DF41C v8::internal::EmbedderStackStateScope::ExplicitScopeForTesting+124
7: 00007FF7988DC63B v8::internal::Heap::CollectGarbage+3963
8: 00007FF7988F2873 v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath+2099
9: 00007FF7988F311D v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath+93
10: 00007FF7989028E0 v8::internal::Factory::NewFillerObject+816
11: 00007FF7985F3325 v8::internal::DateCache::Weekday+1349
12: 00007FF798B0F751 v8::internal::SetupIsolateDelegate::SetupHeap+558193
13: 00007FF798B2ACA3 v8::internal::SetupIsolateDelegate::SetupHeap+670147
14: 00007FF7191C71BB

Seems like a yarn issue if it's crashing when installing the dep? Can you try with pnpm?


Add sleep timer feature

The ability to set a timer for when to stop playing is a common audiobook player feature.

The mobile app supports this and I think that's good enough.  Closing for now.


fix: add useConstant hook

Using ref's instead of state is a little bit cheaper https://twitter.com/dan_abramov/status/1149122677879140352?s=20&t=_dVGNnhjWNZ4IKRLcIqg5g I assume it's because React doesn't need to keep track if the state changes etc.
Let me know what you think

Thanks, that looks like a neat little convenience and performance hack that I will probably make use of in some other places, too.


Update required nomad_provider version to the latest

We might need to update it to the latest. https://github.com/hashicorp/terraform-provider-nomad/releases/tag/v1.4.9
Not sure that in current PR. Let's leave as it is, due to PR context
Originally posted by @zhenik in https://github.com/fredrikhgrelland/terraform-nomad-minio/pull/29#discussion_r497504208

vault also

The update needs to be made in these two files:
https://github.com/fredrikhgrelland/terraform-nomad-minio/blob/master/example/vagrant_box_example/main.tf
https://github.com/fredrikhgrelland/terraform-nomad-minio/blob/master/template_example/example/standalone/main.tf


[Groq] Skip name prompt for new chats

Extension
https://www.raycast.com/ilian/groq
Description
When starting a new chat window, the current interface requires me give that chat a name. I think it would be better if this is skipped. Just open the new chat on cmd+n and set a topic after the first message is sent by using the first characters from the message. It's worth considering to set the topic name using an LLM, or adding an action that lets users set the title.
Who will benefit from this feature?
No response
Anything else?
No response

@maximilianzuern could you also add support for 3.2 models in the package.json? If you want I can open a PR for this specifically but wanted to check in with you!

Really like the idea of using an LLM to define a name.
I plan to implement this when I have some spare time.
Duplicate of #15523

@maximilianzuern could you also add support for 3.2 models in the package.json? If you want I can open a PR for this specifically but wanted to check in with you!

I don't think adding the Llama 3.2 90B model is necessary. The only difference between this model and the Llama 3.1 70B model is the 30B vision adapter.
Since this extension currently doesn't support using screenshots, adding this model wouldn't make much sense.
However, adding the updated 3.3 70B model is already in the works!
https://github.com/raycast/extensions/pull/15726


Update cloud-sso-saml.rst

Updated the links and fixed the broken links

Summary

Ticket Link

Hello @Sayanta66,
Thanks for your pull request! A Core Committer will review your pull request soon. For code contributions, you can learn more about the review process here.

@justinegeffen this is available for merging


Small update in 'control flow' chapter

In the commit https://github.com/cairo-book/cairo-book/pull/472/commits/d91cbff8916f0931aeff9e693c9ef40cfb97aeec 'again!'.print(); has been reworked to println!("i = {}", i); to use the new println! macro.
So now, the code snippet in the loop chapter should be updated as i = 0 is printed instead of again!.

This change is

with pleasure ser, thank you for this awesome resource to learn Cairo 👍
Do I still have something to do or I just wait for PR merge ?

All good


masked input / format option

In addition to the placeholder (https://github.com/airbnb/react-dates/issues/79) it could be good to have also a masked input / format option as property of type function so users can only input dates into the text field (see https://github.com/airbnb/react-dates/blob/fa163dffe15fbc93b2eea704b31ad6cc9655b314/src/components/DateInput.jsx#L113-L128) instead of any text to prevent empty / invalid inputs.

I was thinking about this over the break too. I think this would be a good idea and help a lot with our validation code. I was looking into masked inputs libraries over the holiday but didn't land on one with a particularly high level of support. If you have some ideas of ones to explore, I'll look into it.
@ljharb @lencioni @backwardok thoughts on good libraries to accomplish this?

I'm not convinced that restricting input is a great pattern - I feel like allowing the user to type the wrong thing might give us the opportunity to provide a more helpful error message. Fields that only allow numbers, for example, make a bit more sense, but it's really confusing and annoying when credit card fields prohibit spaces, and phone number fields prohibit dashes.
Open to being convinced tho.

Nielsen Norman Group recommends never using placeholders. https://www.nngroup.com/articles/form-design-placeholders/
They do recommend formatting input as it is typed in some situations (e.g. phone numbers):

An even better solution is to format the users’ input as they type —like Uber’s website does during account creation. Once you begin typing, the form adds the spaces, parentheses, and hyphens where they normally go, and also ignores additional nonnumeric characters (which acts as a type of helpful constraint, preventing users from adding unnecessary extra parentheses, for example). This helps the user understand what characters they should type, and does the work of reformatting, making it much easier for users to read and double-check their own work.

https://www.nngroup.com/articles/slips/
I also agree with @ljharb that restricting input is not a great pattern. Personally, when I encounter this I often find it more frustrating than useful.

If we want to reformat input after it is typed, it seems like it should be pretty straightforward to do that without bringing in a new dependency (e.g. parse input with moment, update state with desired format of given input).

Autoformatting (and possibly autovalidating / shoeing if the given input value is correct) could be a good solution.
My idea was not to fully restrict the input or enforce a specific format but give hints if it is correct and can be parsed or not.

Late to the game on commenting on this, but the cases that @lencioni and @ljharb seem to apply a lot less to dates and more so to things like credit cards and phone numbers. This is especially important for dates because switching the order of what you put for month and date will get you an entirely different value, and that's not true for something like credit cards or phone numbers, where the order will always be the same and can just be masked to fit within a desired visual output.
Format could be kind of interesting, but that would then require a specific input method and not be able to accept multiple (like it does today)

Right. Great to still see some activity by Airbnb devs.


chore(main): release 0.5.5

:robot: I have created a release beep boop
0.5.5 (2024-07-24)
Bug Fixes

docker workflow (8ea2bdc)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/socialgene/sgnf/releases/tag/v0.5.5 :sunflower:


syn 2.0 and MSRV

👋
Right now, for pyca/cryptography, we're in an awkward space where half our dependencies use syn 2.0, and half use 1.0 (including pyo3). This is unfortunate from a compilation time perspective. The reason not to upgrade, and presumably why pyo3 hasn't, is that syn 2.0 raises their MSRV to 1.56.
I wanted to start a conversation on at what point it would make sense to raise pyo3's MSRV, and thus be able to use syn 2.0?
For pyca/cryptography, our upcoming release will raise our own MSRV from 1.48 to 1.56. You can see some of the data/reasoning behind this here: https://github.com/pyca/cryptography/issues/7172, https://github.com/pyca/cryptography/pull/8195, and https://github.com/pyca/cryptography/pull/8587

I was expecting us to bump our MSRV to 1.63 when Debian Bookworm becomes stable in "mid 2023" as per https://github.com/PyO3/pyo3/blob/main/Contributing.md#python-and-rust-version-support-policy

Alpine 3.17 has 1.64 but RHEL 9 seems to carry 1.62, so we would actually end up with 1.62 instead of 1.63 following that policy.

Based on our experience with /metrics for pyca/cryptography, I would advocate for a slightly smaller jump.
Based on our metrics, our plan is to do 1.56.0 as MSRV for our next release, and then 1.60 as our expected (subject to change) MSRV.

Out of curiosity and to understand if our policy needs to be amended: Do your metrics include any indication of what users in the 1.56 to 1.61 bracket are running on or how they installed Rust?

Interesting, so mostly outdated Alpine versions. So glad everyone keeps their container image builds fresh as daisies...

It likely reflects that musllinux wheel support requires a newer pip, so those users also have an older pip.

Sorry for the slow reply here on my part.
I think the aging MSRV in PyO3 is probably slowing us down more than continuing to support Python 3.7 is. I also had the impression that Python 3.7 was still a significant proportion of downloads, e.g. about a third of recent cryptography downloads according to https://pypistats.org/packages/cryptography
I was considering if we should propose keeping 3.7 support until the end of the year or even longer, and bumping MSRV sooner (maybe even as part of 0.19). @alex I'd be interested to hear whether you think that would be beneficial for cryptography.

To avoid leaving Debian users behind, I think we should at least wait with any MSRV increase until Debian Bookworm releases, and then we just need a decision whether we want to go straight to 1.62 or have a period of support with 1.56 first.

I think the aging MSRV in PyO3 is probably slowing us down more than continuing to support Python 3.7 is.

Do you have anything specific in mind w.r.t. slowing us do? Keeping our set-minimal-package-versions Nox session working?
Otherwise, I am not sure it is really slowing us down. It does prevent certain simplifications and prevents some API improvements, but we have workarounds for example for the points @mejrs lists in place. Is there some place where lack of language (or standard library) features is really blocking us? Compared to say plain lack of time on our part?
(Having to build both syn 1.0 and 2.0 in a single project is not nice, but it also not the end of the world IMHO.)

Is there something in between 1.56 and 1.62 that we want? The main things that we want are below that, I think:

I also think we should start with 1.56 and only bump to 1.62 if we actually have a situation where we want some later feature.

I do think the 1.48 msrv is slowing/limiting us. We currently use a build script and conditional compilation to work around these, those have a bunch of downsides:

they make the code harder to reason about
require annoying workarounds (by-value array iteration for example)
confusing for users when they read our docs but they're on a really old version

While I mostly agree with the assessment, it is the conclusion I am sceptical about: All of this applies to code bases that are frequently modified or see sweeping changes. I think that is unfortunately not the case for PyO3 at the moment. And I also do not think that removing those costs would change this meaningfully.
Then again, we should not have even potential road blocks for no reason. But in this case, e.g. the Debian-oriented MSRV policy really is a feature in itself which currently costs us very little because the workarounds while ugly have been written and are not frequently modified.

I have written code using manuallydrop and transmutes to get around not being able to iterate by-value over an array. I'd love to delete that code.

Is there something in between 1.56 and 1.62 that we want?

A couple of Rust releases contain some potential improvements:

1.61:

Use of function pointers in const fn (this allows us to drop cases where we've used newtypes purely to wrap ffi function pointer typedefs in macro code).
whole-archive link modifier might let us support static embedding of Python interpreters
generics in const fn might be useful in future feature work

1.58:

Identifiers in format strings would let us simplify documentation and internal code

That said, I think we're all converging on a 1.56 version bump once Debian bookworm releases, and then we can revisit later.

If there's ways we can be helpful on these fronts, we're happy to. The period during which we supported 3.6, but pyo3 didn't, was pretty painful. Going forward we'd rather help out upstream if you're amenable.

The two main drawbacks to supporting older Python versions in my opinion are:

It prevents us from making full use of newer Python features. For example PEP 587 embedded interpreter initialization will give us power to create an API which could significantly improve upon prepare_freethreaded_python(), however we can't realistically use PEP 587 by default on 3.8+ without risking behavioural differences on 3.7.
CI - it's significantly less bad since we switched to bors, so we'll have to see what it's like after #3132

The code in pyo3-ffi is pretty static once support for a Python version is added, so it's not really an issue in that library at all whether to keep or remove Python 3.6 support.
I think for now we're not feeling an immediate need to drop 3.7, however if we did, I think we'd be open to accepting bugfixes to the last PyO3 version which supported 3.7.
@alex are there particular pain points which you hit? I recall the PyPy support, not sure what else you encountered.

During the period where we were pinned to an older pyo3 version there were two pain points:

The PyPy issue where, had y'all not been willing to do the backport, we would have had to choose between 3.6 and PyPy support.
Not being able to benefit from upstream improvements (which probably, at the margin, was a disincentive for us to send PRs upstream)

FYI, I managed to fix our Rust versions infra. Here's the numbers for the last 30 days, for version 40 of cryptography (MSRV of 1.48).
For each version, the % is the % of downloads, with Rust version info, that have a rustc >= to that version.
As of: 2023-05-29 00:03:32.388608
Percent with rustc_version: 5.869%
Total with rustc_version: 49511
1.48.0: 99.4%
1.49.0: 95.0%
1.50.0: 95.0%
1.51.0: 95.0%
1.52.0: 95.0%
1.53.0: 94.9%
1.54.0: 94.9%
1.55.0: 94.9%
1.56.0: 94.9%
1.57.0: 94.4%
1.58.0: 94.4%
1.59.0: 94.1%
1.60.0: 94.0%
1.61.0: 85.3%
1.62.0: 85.1%
1.63.0: 84.1%
1.64.0: 82.5%
1.65.0: 81.6%
1.66.0: 77.1%
1.67.0: 75.3%
1.68.0: 75.0%
1.69.0: 74.3%


Delete transaction endpoint

Pls give me ty

there needs to be a discussion on this ticket i believe...
when removing a trip from the db ... it must recuse to the items referencing it ...
we have to discuss as a team what to do with these references ...

remove all items, meaning they are not used in recommendations for other users
have null trup_id in items table, causing the items to be isolated by their date_time and locatino
simply dereference the user_id from the trip ittself and keep all other data

@jason-nam
@r-yeh
@allanfang1


inp_settings files not included in pypi package

Need to change setup.py (I think) to ensure the inp_settings files are included. Currently, this causes the run_models module to fail.

I needed an MANIFEST.ini pointing to the text data files


Machinery work order / work items aligning with ADAPT/ISObus

Define classes that support land application work orders and work records
These should align with AgGateway's ADAPT Data Model (documentation | GitHub) where possible (recognising that ADAPT has a GeoJSON plug-in which is good for the spatial representations, and that its data model is weighted towards the flat tabular approach of traditional ISOBus)
This is a part of issue #39

Here's a diagram of a potential object model based on the entities from ADAPT but using the spatial features and based on ObservationType

1. WorkOrderResource

Property
Type
Description

items
array of WorkItemResource
Contains the list of work items within the work order.

All other Work Order fields are come from the base classes - ObservationType or ResourceType.
2. WorkItemResource
Defines activities carried out "in a single pass" of the feature.

Property
Type
Description

operation
string
Describes the principle operation to be carried out (or which has been carried out). This could be an enumeration.

status
enumeration
ADAPT or ISO status codes. To document which we choose.

priority
enumeration
ADAPT or ISO priority codes. Document which we choose.

operations
array of WorkItemOperationType
A list of (at least one) operation that is carried out in this pass/activity.

All other Work Item fields come from ObservationType or ResourceType.
3. WorkItemOperationType
Defines details of a single operation within a work item (a single pass).

Property
Type
Description

operation
string
Describes the detailed operation. This could/should be an enumeration.

operationName
string
A human-readable description of the operation.

machines
array of MachineResource
The equipment used/to be used in this operation.

products
array of OperationProductType
The product(s) and their rates used in this operation.

Additional ADAPT details could be added at the WorkItemOperation level - for instance, WorkRecord summary and LoggedData.
4. MachineResource
MachineResource will include all attributes from ResourceType.

Property
Type
Description

manufacturer
string (URI)
Manufacturer URI or identifier.

model
string
Model identifier.

serial
string
Equipment serial number.

implements
array of ImplementResource
Details of zero or more attached implements.

5. ImplementResource
MachineResource will include all attributes from ResourceType.

Property
Type
Description

manufacturer
string (URI)
Manufacturer URI or identifier.

manufacturer
string (URI)
Manufacturer URI or identifier.

model
string
Model identifier.

serial
string
Equipment serial number.

workingWidth
number
Working width in metres.

trackSpacing
number
Track spacing in metres.


Upload Chapter 4 per v0.9-preview, Update UPL Logo, and a few fixes

Add these nodes for chapter 4:

Root node
/options/upl-params
/options/upl-image@
/options/upl-image/image@
pci
isa
serial console decice
framebuffer
chosen
/options/upl-custom

LGTM

I also updated ISA node for better clarification with the eSPI and LPC.


gerrit-331141-2

Current coverage is 62.64% (diff: 94.73%)

No coverage report found for master at a2c4e40.

Powered by Codecov. Last update a2c4e40...cdee032


feat: update gateway for nat traversal

What type of PR is this?
/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Does this PR introduce a user-facing change?

other Note

/lgtm


Issues resetting form data

Hi there!
I'm having an issue resetting / changing the form data values.
My use case is a form and a list, where after you add an item via a HeadlessForm, it is added to the list, the values are cleared, and you can create a new item.

Setting the values of the object passed as @data doesn't reset the values present in the form
setting @data to a new object also doesn't effect values in the form

Ideally either there would be a yielded method to change the data, or mutating the data via another approach would effect the data in the form.

I agree we need to support this, will look into this!

I noticed that resetting the form (using a simple <input type='reset'>Reset</input> also does not reset validation errors.

(This might be worth it's own issue?)

Yup (pun intended): #122

I worked on an elaborate solution for this, until I realized it actually does not serve the use case. 🙈😅
So back to the drawing board, trying to properly design this first before implementing it...
For some additional context: headless-form takes the approach of being strict about DDAU, even though in the case of forms there are some more or less valid cases for allowing two-way bindings maybe. But we don't do this, so the user will only get the new data by receiving it from @onSubmit. That means we have the original (unaltered) data coming from the caller as @data, and we have an internal data object that tracks the "dirty" data (user has filled in some fields, making those diverge from @data). What is displayed in the form is then basically the union of these, with any dirty value overriding the original one. Resetting the form then basically means resetting the internal data to an empty object, so all of @data is visible again (for forms used for "create" operations this is mostly just an empty object).
Im trying to incorporate the different cases of the state of the input (pristine - has never been touched by the user - vs. dirty - user has entered a different value than the initial one) and the action that is happening (already taking into account #122 here in the last two columns). Here is an initial suggestion for further discussion:

@data.foo is updated (@tracked)
@data is reassigned
input[type=reset] clicked
yielded reset action called

input[name=foo] is pristine
input is updated with @data.foo
input is updated with @data.foo
input is updated with @data.foo
input is updated with @data.foo

input[name=foo] is dirty
input is not updated  (keeps filled in value)
?
input is updated with @data.foo
input is updated with @data.foo

I think we don't want the user provided value to be lost when @data.foo changes, right? So that's why we keep the value in col 1, row 2. Cols 3+4 should be uncontroversial, as these are explicit reset actions, so losing the existing values is expected.
I am unsure about col 2, row 2: when reassigning @data, should we keep existing user-entered values, or should we treat this as a "reset". In the latter case, we would have the use case of the original issue here covered. To erase all inputs you would do something like this.data = {};. But I am not sure if and how this is possible to implement, distinguishing this from col 1 (just changing a tracked prop), without resorting to weird observer-like patterns. But that's the second question, more important first is: do we want this? Is this reasonable? Or is it too inconsistent (with col 1), unexpected or too "magical"?
If we don't do this (i.e. keep the dirty value), we would still have no way to programmatically reset the form "from the outside". Another pattern that would allow this, which is not listed in the table above, is "Action down": letting the form call some kind of register callback, that gives the parent a reference to a reset-action that they can call (instead of relying on data to just flow down). PowerSelect uses a similar concept.
Thoughts? /cc @ynotdraw @nicolechung @NullVoxPopuli

Btw, there was an existing test covering some parts of what is mentioned above, but which was skipped for now, as indeed the logic we want here was not quite clear yet. So I think it's good to have this issue raised here, so we can get back to this!

Ideally either there would be a yielded method to change the data, or mutating the data via another approach would effect the data in the form.

This ask above sounds related to this comment below:

If we don't do this (i.e. keep the dirty value), we would still have no way to programmatically reset the form "from the outside". Another pattern that would allow this, which is not listed in the table above, is "Action down": letting the form call some kind of register callback, that gives the parent a reference to a reset-action that they can call (instead of relying on data to just flow down).

Am I reading this correctly?

Looks like Angular has a markAsPristine value where the form can be reset to @data even if @data has changed (been reassigned).
So in the case of input[name=foo] is dirty, markAsPristine would override the dirty value and reassign @data.
If markAsPristine hasn't been set, it's assumed the form is still "dirty" and so the new @data won't override.
Another option seems to be being able to pass the form value to reset. That way a form can be pristine but updated with the new @data in that way.

Am I reading this correctly?

Hm, not sure, I'll try to clarify this...

Ideally either there would be a yielded method to change the data

So I would read this as the last option (column) in my table above: "yielded reset action called", as in:
<HeadlessForm @data={{this.data}} as |form|>
  {{! form stuff }}
  <button type="button" {{on "click" form.reset}}>Reset</button>
</HeadlessForm>

Here we are yielding an action reset, that is called inside of the form block. The example is basically the equivalent of using a native reset button (col 3), as in:
<HeadlessForm @data={{this.data}} as |form|>
  {{! form stuff }}
  <button type="reset">Reset</button>
</HeadlessForm>

This is easy to do, as yielding down something will make it available to the block, and if that's where we want to use it, then that's fine.
A different case is yielding up. Like you want to call reset() inside say your controller (which renders the form). We don't have a natural way to do this. We just let data flow down, but we don't call functions "down". So this case was what I referred to in

Another pattern that would allow this, which is not listed in the table above, is "Action down": letting the form call some kind of register callback, that gives the parent a reference to a reset-action that they can call (instead of relying on data to just flow down).

An example of this would be:
// template.hbs
<HeadlessForm @data={{this.data}} @registerForm={{this.registerForm}} as |form|>
  ...
</HeadlessForm>

// controller.js

export default class FormController extends Controller {
  data = {};

  formApi;

  @action
  registerForm(formApi) {
    this.formApi = formApi;
  }

  someAction() {
    // do something, like saving a record based on the form data, and then resetting the form...

    this.formApi.reset();
  }
}

Here, with this.formApi.reset(), we are calling a function provided by the child form, but from upstream!
Again, I don't really like this very much, and would rather avoid this where possible, but it is an option on the table...
Regarding your references to Angular, I don't know enough about Angular to see how that could translate to Ember 😅

Another option seems to be being able to pass the form value to reset. That way a form can be pristine but updated with the new @data in that way.

Not sure what means exactly. Can you show or link to an example?

Unless we can do something like
<HeadlessForm @data={{this.data}} as |form|>
  {{! form stuff }}
  <button type="button" {{on "click" this.handleReset form.reset}}>Reset</button>
</HeadlessForm>

Where the form.reset is passed as an argument to handleReset...

Yeah, but this works only if the users interaction originated from within the form.
Let's give an example where this does not work: say we have a list of records and a sidebar. when you click a record, it will be highlighted in the list, and a form with the records data will show up in the sidebar, to allow editing it. Now if the user has entered some new data there, but didn't submit it, but instead selected a different record, we'll want to show that record's data in the form. But we also don't want the dirtied fields to preserve their value, as those were related to a totally different record. Se we want to discard all temporary changes in the form, and let the form just show the new @data. But how to tell that to the form? The action that caused the need to reset the form happened outside of the form (clicking the other list item), so we cannot pass form.reset along...

Also, we can look at this problem from two angles. First is how to support the use case of resetting the form. But whatever we come up with, we still have to also answer the question what the form should do in those cases that are contained in that table above: given we have dirtied fields, what should happen with those in case of 1) updating @data.foo and 2) reassigning @data? This needs to be answered anyway, independently of whether that'll be part of supporting the reset use case or not!
So the question there is basically: what would a user (you!) expect?

Maybe we can do something a bit like what ember-headless-table does and mix it with what react-hook-form does.

This got me thinking...

I don't have suggestions for how this would work with the current implementation however - how would the useForm hook know that it's related to ?

Yeah, that is the tricky part, how to make this work with Ember, where we don't have hooks, but we "only" have some data flowing down. We still want to call a reset() function that does something with the form component. This is still basically the "Actions down" approach. But maybe there is a way to support this, without the caveats of the register API that I mentioned above...
Picking up your example, and modifying it a bit to fit how this could work with Ember:
import { useForm } from 'ember-headless-form';

export default class FormController extends Controller {
  formController = useForm();
  data = {};

  someAction() {
    // do something, like saving a record based on the form data, and then resetting the form...
    const values = await save('some-api', formValues);
    this.formController.reset();
  }
}

<HeadlessForm @data={{this.data}} @controller={{this.formController}} as |form|>
  ...
</HeadlessForm>

Ignore the hard part of naming things here (e.g. "controller"), that remains to be seen... but how it basically could work is that useForm() returns an object. The only public API on that object would be .reset() for now (and yeah, we could introduce options here and whatnot, but let's keep the example simple for now). But it could have additional data or methods, that only our component would be eligible to use. When passing this as @controller (or whatever better name we come up), the component would register itself with that object, and upon destruction unregister itself. This is similar to that registerAPI approach mentioned above, but without actually exposing these shenanigans to the user, and also with properly supporting the teardown case (no "dangling pointers"). The .reset() method would then know about the registered form component on that instance of the object, and be able to call "into" our component ("downwards").
It's gotten late over here, and I need to sleep over this, but to me this looks like an pretty interesting approach, that I didn't have on my mind before. Thanks a bunch for bringing this up @nicolechung!

I'm a bit late, but after catching up. I think what you landed on above @simonihmig looks great to me. Also exposing it via the yielded form makes sense to me as well!

A couple of thoughts...
ember-basic-dropdown does a nice job of yielding actions that impact the component as a a hash of actions like:
yield (hash actions=(hash resetData=this.reset))

and you can pass those actions as arguments to other functions like:
<button {{on "click" (fn this.resetData dd.actions.reset)}}>

I like the registerForm approach you mentioned pretty well!
<HeadlessForm @data={{this.data}} @registerForm={{this.registerForm}} as |form|>

I would say though that in my view, here's what i would expect to happen.
<button {{on "click" this.resetData}}/>
<HeadlessForm @data={{this.data}} @registerForm={{this.registerForm}} as |form|>
...
</HeadlessForm

component
...
@action
resetData(){
this.data = {}
}

If that reset button is clicked, the data that's passed into the form has now changed and the form should respect the data that was passed down into it. Thats (to me) how "Data Down" would ideally be reflected here. The form takes whatever data it's given and presents it, then calls an action to do something to act on it.
When that wasn't how it worked, I was pretty surprised and assumed it was a bug.
I think it's totally fine if the new object clobbers the old -- the form wasn't submitted, so the changes are thrown away.

@averydev so what you are saying is that you would expect this to be our behavior, right? (pay attention to cols 1+2, row 2)

@data.foo is updated (@tracked)
@data is reassigned
input[type=reset] clicked
yielded reset action called

input[name=foo] is pristine
input is updated with @data.foo
input is updated with @data.foo
input is updated with @data.foo
input is updated with @data.foo

input[name=foo] is dirty
input is updated with @data.foo)
input is updated with @data.foo
input is updated with @data.foo
input is updated with @data.foo

Means, whenever something changes around @data, the filled in (but not yet submitted) values will get wiped away. Is that what you would expect? Is that what others would also expect?

Nice ideas above. WDYT about the idea of passing the resetForm method as the second argument to the onSubmit action? The consumers will only be able to call resetForm and the reset would be done internally. Something like:
<HeadlessForm @data={{this.formData}} @onSubmit={{this.handleSubmit}}>
</HeadlessForm>

@action
handleSubmit(data, resetForm) {
  // save the data
  resetForm();
}

Right, I missed that. In that case, I guess this example you mentioned, makes even more sense.

There is this option? Always available to the style of api headless form provides (and maintainers don't need to change what is supported):
<HeadlessForm @data={{this.data}} as |form|>
  {{ ( this.assignFormApis form )}}
</HeadlessForm

assignFormApis(form) {
  this.resetForm = form.reset
}

The discussion here fluctuated a bit between supporting the specific use case of resetting (e.g. by calling some kind of reset action down) and the question of what should in general happen when @data changes while the form is displayed (and may have changed fields). But I think before we come up with a good API for the former, we actually have to answer the latter question. So to focus on that one first, I created this separate issue: https://github.com/CrowdStrike/ember-headless-form/issues/130. Please everybody involved here share your thoughts there! 🙏

@simonihmig I assume we can resolve this one based on the latest changes.

Yeah, I think so. I wanted to provide some examples of resetting forms in the docs, and demonstrate the different use cases. But no need you wait if you want to try that. 1.0.0-beta.3 has been released yesterday!


Improve linting configuration

Enabled more static checks
Switched to gomodguard instead of revive for better error message

s

:grey_exclamation: Build Aborted

There is a new build on-going so the previous on-going builds have been aborted.

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

Start Time: 2022-03-21T17:05:57.802+0000

Duration: 7 min 11 sec

Test stats :test_tube:

Test
Results

Failed
0

Passed
496

Skipped
2

Total
498

Pipeline error

  This error is likely related to the pipeline itself. Please go to the traditional console output here"
  You will see the error (either a wrong syntax or configuration)

:robot: GitHub comments
To re-run your PR in the CI, just comment with:

/test : Re-trigger the build.


manual.configuration.userManagement: mkpasswd

Added clarification about mkpasswd in User Management section of the manual

Thanks for the clarification, I would advise nix run (transient) rather than nix-env (permanent).

Sorry I don't know how to use nix run. I addressed your comment in another way but if you're not happy, please let me know and I will find out how nix run is used

The equivalant command for nix run is following:
nix run nixpkgs.mkpasswd -c mkpasswd -m sha-512

Done. Using nix run now


Bug: derive_vars_period() errors unexpectedly when dataset_ref has unused variables

What happened?
When period_ref contains variables that are then not mentioned within the new_vars call, derive_vars_period() errors with the unhelpful error message:
Error in `signal_duplicate_records()`:
! Dataset `dataset_add` contains duplicate records with respect to `STUDYID` and `USUBJID`
Run `get_duplicates_dataset()` to access the duplicate records

when really one would at least expect the error message to flag that thios is occurring because every variable in period_ref must either be a key variable or be mentioned in new_vars. Alternatively the function should just ignore unused variables. See reproducible example for details.
Session Information
Not relevant
Reproducible Example
adsl <- tibble(STUDYID = "xyz", USUBJID = c("1", "2"))

# Add period variables to ADSL
period_ref <- tribble(
  ~USUBJID, ~APERIOD, ~APERSDT,     ~APEREDT,     ~APERSDTM,                ~APEREDTM,
  "1",             1, "2021-01-04", "2021-02-06", "2021-01-04 10:10:00", "2021-02-07 11:20:01",
  "1",             2, "2021-02-07", "2021-03-07", "2021-02-07 11:20:02", "2021-03-07 10:10:00",
  "2",             1, "2021-02-02", "2021-03-02", "2021-02-02 12:20:01", "2021-03-03 13:10:01",
  "2",             2, "2021-03-03", "2021-04-01", "2021-03-03 13:10:02", "2021-04-01 10:10:00"
) %>%
  mutate(
    STUDYID = "xyz",
    APERIOD = as.integer(APERIOD),
    APERSDT = ymd(APERSDT),
    APERSDT = ymd(APEREDT),
    APERSDTM = ymd_hms(APERSDTM),
    APEREDTM = ymd_hms(APEREDTM),
  )

# This errors because we are not mentioning APERSDTM, APEREDTM anywhere
derive_vars_period(
  adsl,
  dataset_ref = period_ref,
  new_vars = exprs(APxxSDT = APERSDT, APxxEDT = APEREDT)
)

# This doesn't error because we are mentioning APERSDTM, APEREDTM
derive_vars_period(
  adsl,
  dataset_ref = period_ref,
  new_vars = exprs(APxxSDT = APERSDT, APxxEDT = APEREDT, APxxSDTM = APERSDTM, APxxEDTM = APEREDTM)
)

# This doesn't error because we are removing APERSDTM, APEREDTM from period_ref
derive_vars_period(
  adsl,
  dataset_ref = period_ref %>% select(-ends_with("M")),
  new_vars = exprs(APxxSDT = APERSDT, APxxEDT = APEREDT)
)

Decision from core meeting: behaviour should be changed so that derive_vars_period doesn't throw an error at all, just ignores variables in period_ref that are not used in the function call


Snippet choice shows "no suggestions"

That setting is true for me. I tested this further, and it looks like it only repros for me when the file is saved (looks like that's not the case for you since you're working with a saved file). I can select any language for an unsaved file and the choices come up, but as soon as I save the file, suggestions no longer populate. Same case with python, typescript, C#, markdown

Originally posted by @amunger in https://github.com/microsoft/vscode/issues/75594#issuecomment-1112501469

@amunger Can you please share you settings here

{
"jupyter.askForKernelRestart": false,
"remote.SSH.remotePlatform": {
"<IP_ADDRESS>": "linux",
"<IP_ADDRESS>": "linux",
"<IP_ADDRESS>": "linux"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"jupyter.widgetScriptSources": [
"jsdelivr.com",
"unpkg.com"
],
"window.newWindowDimensions": "offset",
"jupyter.interactiveWindowMode": "perFile",
"experiments.override.gettingStarted.overrideCategory.ms-python.python.pythonWelcome.when":"false",
"experiments.override.gettingStarted.overrideCategory.ms-python.python.pythonWelcomeWithDS.when": "workspacePlatform != webworker",
"experiments.override.gettingStarted.overrideCategory.ms-toolsai.jupyter.jupyterWelcome.when": "workspacePlatform != webworker",
"jupyter.notebookFileRoot": "${filenameDir}",
"workbench.startupEditor": "none",
"audioCues.debuggerExecutionPaused": "off",
"terminal.integrated.shellIntegration.enabled": true,
"python.createNewFileEnabled": true,
"workbench.editor.languageDetection": false,
"markdown.preview.typographer": true,
"jupyter.pythonExportMethod": "direct",
"gitlens.statusBar.enabled": false,
"gitlens.currentLine.enabled": false,
"gitlens.hovers.currentLine.over": "line",
"gitlens.showWelcomeOnInstall": false,
"extensions.ignoreRecommendations": true,
"terminal.integrated.commandsToSkipShell": [
"language-julia.interrupt"
],
"julia.symbolCacheDownload": true,
"julia.enableTelemetry": true,
"editor.cursorSurroundingLines": 2,
"editor.language.colorizedBracketPairs": true,
"files.hotExit": "onExitAndWindowClose",
"[json]": {
"editor.defaultFormatter": "vscode.json-language-features"
},
"terminal.integrated.tabs.focusMode": "singleClick",
"scm.diffDecorationsGutterPattern": {
"modified": false
},
"editor.minimap.enabled": false,
"jupyter.debugJustMyCode": false,
"jupyter.logging.level": "verbose",
"notebook.outputLineHeight": 20,
"typescript.updateImportsOnFileMove.enabled": "always",
"jupyter.pythonCompletionTriggerCharacters": ".%",
"[css]": {
"editor.defaultFormatter": "vscode.css-language-features"
},
"css.format.braceStyle": "expand",
"explorer.fileNesting.enabled": true,
"explorer.fileNesting.expand": false,
"explorer.experimental.fileNesting.operateAsGroup": false,
"files.autoSave": "afterDelay",
"notebook.cellToolbarLocation": {
"default": "right",
"github-issues": "right"
},
}

no worries. Still repros with all extensions disabled and bisect only makes it one step before stopping.

I'm also seeing the same behavior, it only shows the suggestions when it's unsaved buffer. I'm on Windows if that matters.

Thanks @rebornix - I can reproduce on windows

I (believe) that I now understand: when snippets are active a special completion item provider for that model is registered. From the document that's being edited it uses the scheme, langauge, and path to register a provider (document selector). However, it uses path, not fsPath, for the pattern-part

Same mistake happens with tab completions: https://github.com/microsoft/vscode/blob/6e1e0b1d899b2d262265e8faeadee98c562cfe7b/src/vs/workbench/contrib/snippets/browser/tabCompletion.ts#L150


WIP: Rule keyword

Implements #250

@charlierudolph - you've got better Go fu than me. Could you try to complete this PR for Go please? Just use the same branch.
Thanks!!

Superceded by #416


Add new github action for releases

PR Checklist
(all items must be checked off for a PR to be merged)
This PR:

[n/a] has a changelog entry with a short description of what's changed in CHANGELOG.md
[n/a] adds new tests or updates existing tests (or hasn't, for reasons explained below)
[n/a] strictly follows the design spec (if one exists)
[n/a] adheres to a11y guidelines/WCAG guidelines where applicable; this can be tested using Lighthouse (native in Chrome dev tools or as a plugin for other browsers) and with accessibility reports in Firefox

PR description
This PR adds a currently untested github action for auto-building and publishing of releases anytime a tag of the form x.y.z is pushed to a commit on the main branch.  Currently this action runs the publish command with a --dry-run tag so that we can easily test before publishing to the public repository.  Assumes all relevant version information has already been PR'ed and merged in package.json.

I'm surprised to see that this already ran (and failed): https://github.com/PrefectHQ/miter-design/runs/4071439344?check_suite_focus=true


Only the latest updated certificate is served by Kong (0.4.0)

Summary
After upgrading from 0.3.0 to 0.4.0 only the latest updated certificate seems to be served by Kong, all other SNIs are served the default certificate.
Kong Ingress controller version
0.4.0
Kubernetes version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:45:25Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}

What happened
Using version 0.3.0 everything works as expected:
$ curl -v -k https://foo.localhost
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to foo.localhost (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=foo.localhost; O=foo.com
*  start date: May  4 07:45:29 2019 GMT
*  expire date: May  3 07:45:29 2020 GMT
*  issuer: CN=foo.localhost; O=foo.com
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> Host: foo.localhost
> User-Agent: curl/7.64.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Connection: keep-alive
< Date: Sat, 04 May 2019 07:56:35 GMT
< X-Kong-Upstream-Latency: 2
< X-Kong-Proxy-Latency: 0
< Via: kong/1.0.0
<
* Connection #0 to host foo.localhost left intact
Hello World!* Closing connection 0

$ curl -v -k https://bar.localhost
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to bar.localhost (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=bar.localhost; O=bar.com
*  start date: May  4 07:44:55 2019 GMT
*  expire date: May  3 07:44:55 2020 GMT
*  issuer: CN=bar.localhost; O=bar.com
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
> GET / HTTP/1.1
> Host: bar.localhost
> User-Agent: curl/7.64.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Connection: keep-alive
< Date: Sat, 04 May 2019 07:56:45 GMT
< X-Kong-Upstream-Latency: 1
< X-Kong-Proxy-Latency: 1
< Via: kong/1.0.0
<
* Connection #0 to host bar.localhost left intact
Hello World!* Closing connection 0

Kong:

After upgrading to 0.4.0 only the latest updated certificate is being served, all other SNI's get the default certificate:
$ curl -v -k https://foo.localhost
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to foo.localhost (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=foo.localhost; O=localhost
*  start date: May  4 01:01:57 2019 GMT
*  expire date: May  3 01:01:57 2020 GMT
*  issuer: CN=foo.localhost; O=localhost
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x558f48521f30)
> GET / HTTP/2
> Host: foo.localhost
> User-Agent: curl/7.64.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Sat, 04 May 2019 08:18:25 GMT
< x-kong-upstream-latency: 2
< x-kong-proxy-latency: 1
< via: kong/1.1.2
<
* Connection #0 to host foo.localhost left intact
Hello World!* Closing connection 0

$ curl -v -k https://bar.localhost
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to bar.localhost (<IP_ADDRESS>) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Kong; OU=IT Department; CN=localhost
*  start date: May  4 08:14:05 2019 GMT
*  expire date: May 24 08:14:05 2019 GMT
*  issuer: C=US; ST=California; L=San Francisco; O=Kong; OU=IT Department; CN=localhost
*  SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55597f149f30)
> GET / HTTP/2
> Host: bar.localhost
> User-Agent: curl/7.64.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Sat, 04 May 2019 08:18:42 GMT
< x-kong-upstream-latency: 1
< x-kong-proxy-latency: 0
< via: kong/1.1.2
<
* Connection #0 to host bar.localhost left intact
Hello World!* Closing connection 0

Kong:

Expected behvaior
Same behavior as 0.3.0.
Steps To Reproduce

kubectl apply -f https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/master/deploy/single/all-in-one-postgres.yaml
kubectl apply -f https://gist.githubusercontent.com/simonwahlgren/db169bd9bceca1df0043573eb1cbdeb5/raw/4cb843e442d2b5d1bb6b578b04a3c086693ee29f/foo.yaml
kubectl apply -f https://gist.githubusercontent.com/simonwahlgren/d8b3d981486b0721d92d0611a1947328/raw/9e538a6da8d65161f01e06d2b2c21e17e251a4e6/bar.yaml

# Add to /etc/hosts
<ip-to-kong-proxy-svc> foo.localhost bar.localhost

curl -v -k https://foo.localhost
curl -v -k https://bar.localhost

@simonwahlgren Thank you for opening this issue.
I can confirm this bug.
I've not yet narrowed down the root cause yet but will update this thread as soon as I've any update.

@simonwahlgren Just opened up #287.

@hbagdi Awesome, thanks for the update!

Hi, this problem still open?
I'm having the same problem (with cassandra as DB).
I got two certificates (generated by cert-manager) for two subdomains. only the last edited (ingress) works.

This problem is solved!
I build myself a new image from the master repo and everything is fine now.
Thanks!


6.2.3 not working properly with X_PROXY_*

stat: unrecognized option: format
BusyBox v1.26.2 (2017-10-04 13:37:41 GMT) multi-call binary.
Usage: stat [OPTIONS] FILE...
Display file (default) or filesystem status
-c FMT	Use the specified format
-f	Display filesystem status
-L	Follow links
-t	Terse display

FMT sequences for files:
%a	Access rights in octal
%A	Access rights in human readable form
%b	Number of blocks allocated (see %B)
%B	Size in bytes of each block reported by %b
%d	Device number in decimal
%D	Device number in hex
%f	Raw mode in hex
%F	File type
%g	Group ID
%G	Group name
%h	Number of hard links
%i	Inode number
%n	File name
%N	File name, with -> TARGET if symlink
%o	I/O block size
%s	Total size in bytes
%t	Major device type in hex
%T	Minor device type in hex
%u	User ID
%U	User name
%x	Time of last access
%X	Time of last access as seconds since Epoch
%y	Time of last modification
%Y	Time of last modification as seconds since Epoch
%z	Time of last change
%Z	Time of last change as seconds since Epoch
FMT sequences for file systems:
%a	Free blocks available to non-superuser
%b	Total data blocks
%c	Total file nodes
%d	Free file nodes
%f	Free blocks
%i	File System ID in hex
%l	Maximum length of filenames
%n	File name
%s	Block size (for faster transfer)
%S	Fundamental block size (for block counts)
%t	Type in hex
%T	Type in human readable form
/docker-entrypoint.sh: line 6: [: : integer expression expected

Thank you for this, a fixed version will be up later tonight :-)

It should be fixed now, please reopen if you disagree

Thanks ! Looks better indeed :
doing something
setting proxy name
setting proxyport

Server startup logs are located in /var/atlassian/bamboo/logs/catalina.out

Bamboo Server Edition
   Version : 6.2.3


[bazel] cannot load rules and deps for lowRISC misc-linters in CI

https://github.com/lowRISC/misc-linters/blob/master/rules/deps.bzl provides rules that are incompatible with CI
It's running an instance of pip that isn't supported in CI's Python 3.6, it should be rolled back to avoid quietly pushing an upgrade requirement onto CI.

Since they're currently loaded in the bazel WORKSPACE it makes it incompatible with CI which is a thing

Honestly, I don't really understand why that repo (which contains ONE PYTHON SCRIPT!!!!) has a whole load of Bazel rules. My preference would probably be to:

copy those rules over to OpenTitan
Add an ignore file to the vendored directory to ignore the stuff that was there
Remove from misc-linters and re-vendor

Hi Rupert,
The rules are there because the logic to set up appropriate application of the script are somewhat involved (as it is for any linter). This logic is re-used in other lowRISC repositories, including embargoed repos.
The correct solution here is to make misc-linters pick up the python interpreter from OT. I can look into this next week-- I am already underwater with other Bazel cleanups.

I'll see what I can do to get the python interpreter loading. I think I wrote the commit to take it as-is.

Bazel doesn't support python 3.6 because it's gone EOL https://github.com/lowRISC/opentitan/issues/11984

Fixed: https://github.com/lowRISC/misc-linters/pull/27


Implement audio/realtime thread for vst-bridge host.

The problem with realtime processing in vst-bridge is that although
the host calls process on the plugin from a realtime thread, the
thread which is in the VST host process is not realtime, and hence the
audio thread is stuck waiting for a non-realtime thread. Solving this
comes with some challenges, because we only have one pipe to
communicate through, and this is difficult to synchronize between
multiple threads.
The solution in this patch splits the whole host communication part in
two, by separating out the relevant components into their own struct,
and then providing two instances of the communication pipe instead of
one: One for the realtime thread, and one for the normal thread. Then
we use the process calls as a guide to figure out which thread is the
realtime thread on the plugin side, and any call made using this
thread is forwarded to the VST host process through the realtime pipe
instead of the normal pipe.
We also need to actually set up a realtime thread on the host side,
and this is done by providing a new opcode for setting the thread
scheduler and priority. We just use the same values as the calling
thread uses.
It may be difficult to achieve true realtime performance in wine, for
a variety of reasons, but this patch goes a surprisingly long way, and
I've been able to have hour long sessions with no xruns at all,
whereas before they would occur several times per minute.
A couple of things to look out for if performance is still poor after
applying this patch:

Hosts that create their own threads. This plugin is not able to
apply the realtime scheduler on threads it doesn't own, which means
the host will still be stuck waiting for non-realtime threads. At
the time of writing, Wine does not honor Windows thread priorities
(I've checked the source code), so even if the VST plugin tries to
do the right thing and increase the thread priority, it will fail
to do so. I may try to submit a patch to the Wine project at some
point, if I get the time. However, in many hosts, thread creation
is configurable under "Number of cores" or some similar setting,
and turning it off may give better performance. At least it did for
me.

/tmp/.wine-<UID> should be a on tmpfs. While wine is
communicating with wineserver, it uses some temporary files here,
and these should be on tmpfs, IOW a RAM disk, to make sure the
thread doesn't stall on I/O.

Hi,
Thank you very much for doing this difficult task !
I'm going to check it out today.
Regards,
Alex

So first test with phoscyon, when I close the plugin window for the first time, the left channel goes +500 dB.

Wow! I have mainly been using Renoise host and Kontakt Player plugin, and I haven't experienced that. No immediate ideas come to mind, but I can try to look into it.
Did it work otherwise though?

Did a second test, Phoscyon now works fine, but I found that Fabfilter Pro Q3 gets the audio stuck when invoking a menu from the GUI.

The FF pro q3, could be on my side, I'm doing more checks :)

Yeah, FabFilter is lagging the audio thread.
https://www.fabfilter.com/download/

Nevertheless, thanks a lot for the improvement man! ;-)

Yeah, FabFilter is lagging the audio thread.

Ok, I can try to look into FabFilter. There are now two locks (one for each pipe) where there previously was only one global one, so maybe I did something wrong there.

Nevertheless, thanks a lot for the improvement man! ;-)

My pleasure! Just making an already great plugin even better!

I finally got around to trying FabFilter, but I can't reproduce the lagging you experienced. It's working smoothly for me.


Do we still need the SierraData_Merged table?

I think it's redundant now we have the VHS – but let's check before we delete it!

I don't think so. Let's delete it!

It's deleted!


Error while using streaming mode

Here is my conf of server.py :
DEVICE = os.getenv('DEVICE',"cuda")
OUTPUT_FOLDER = os.getenv('OUTPUT', 'output')
SPEAKER_FOLDER = os.getenv('SPEAKER', 'speakers')
MODEL_FOLDER = os.getenv('MODEL', 'models')
BASE_HOST = os.getenv('BASE_URL', '<IP_ADDRESS>:8020')
BASE_URL = os.getenv('BASE_URL', '<IP_ADDRESS>:8020')
MODEL_SOURCE = os.getenv("MODEL_SOURCE", "local")
MODEL_VERSION = os.getenv("MODEL_VERSION","v2.0.2")
LOWVRAM_MODE = os.getenv("LOWVRAM_MODE") == 'true'
DEEPSPEED = os.getenv("DEEPSPEED") == 'true'
USE_CACHE = os.getenv("USE_CACHE") == 'true'
STREAM_MODE = os.getenv("STREAM_MODE") == 'true'
STREAM_MODE_IMPROVE = os.getenv("STREAM_MODE_IMPROVE") == 'false'
STREAM_PLAY_SYNC = os.getenv("STREAM_PLAY_SYNC") == 'false'
and here's the request.py I make :
import requests
tts_url = 'http://<IP_ADDRESS>:8020/tts_stream/'
tts_response = requests.post(tts_url, json={
"text": " Greetings, traveler. What brings you to Whiterun? I hope you're here for noble reasons, as our Jarl takes great care in ensuring his palace is free from harm.",
"speaker_wav": "D:/Modelisation_IA/xtts-api-server-custom/models/MrHaurrus/test.wav",
"language": "en",
})
here's the result ouput :
(venv) PS D:\Modelisation_IA\xtts-api-server-main\xtts_api_server> python server.py
2024-01-19 12:33:53.248 | INFO     | main::72 - Model: 'v2.0.2' starts to load,wait until it loads
2024-01-19 12:33:59.905 | INFO     | tts_funcs:load_model:190 - Pre-create latents for all current speakers
2024-01-19 12:33:59.906 | INFO     | tts_funcs:create_latents_for_all:270 - Latents created for all 0 speakers.
2024-01-19 12:33:59.907 | INFO     | tts_funcs:load_model:193 - Model successfully loaded
D:\Modelisation_IA\xtts-api-server-main\xtts_api_server\venv\Lib\site-packages\pydantic_internal_fields.py:149: UserWarning: Field "model_name" has conflict with protected namespace "model_".
You may be able to resolve this warning by setting model_config['protected_namespaces'] = ().
warnings.warn(
INFO:     Started server process [47132]
INFO:     Waiting for application startup.
INFO:     Application startup complete.


not working as well as it did a few days ago?

Hey, great wrk on this. looks great. However the changes you've made in the past few days have changed the output quite a lot. A few days ago (commit: https://github.com/awentzonline/image-analogies/commit/c6f35e73bfb35035e195dd5a3bb5a018588bec3e ) I would get this (which looks perfect):

but now I get this (with the same settings):

my mask is this:

(also new version is exactly 2x faster, which is great. but I'm not anywhere near the same results)

Two things have changed that might affect that:

The analogy weight should be set a lot higher than the MRF weight (it's 9:1 by default, now) that should fill up the hole in your sexy sax man.
I added an option for stretch contrast you can turn it off with --contrast=0  I should probably turn it down a little more by default.

Great work on this: https://twitter.com/memotv/status/706817101386936320

Another option I recently added that you might want to check out is --pool-mode. It's set to max pooling by default but average pooling sometimes looks nicer --pool-mode=avg for natural images.

ok, interestingly I need to make analogy weight about 20 to get results similar to the version from 2 days ago (even 16 doesn't cut it). Is it possible that there is a factor of 2x introduced somewhere since that commit? contrast and avg pooling did affect the image a little bit, but doesn't really affect the sexy sax man.
analogy weight: 16 (see little hole in his belly)

analogy weight: 20

Would you send me your source images so I can fool around with them? Also, what do your settings look like?

I've tried contrast=0, --pool-mode=avg, --analogy-w=9, 16, 20 (which are the images above), rest is default. I'm happy with the results I got in the above post with analogy-weight=20, i was just curious why I had to use 20 with this version to get similar results as 9 before.
original and mask below. dim 256x163, i'm now trying at 1024x654 (taking a while!)

Thanks! I'm guessing there's something I'm not normalizing properly, since I usually generate larger images around 2x as big and use 1/2 the analogy loss.

Ok I've tracked down a few bugs and this should all be a little nicer. Now the mrf/analogy-w both start at 1.0. For your sexy sax man I found that lowering mrf to 0.5  reproduced him without the hole. Also, given the size, it looks good with --mrf-w=0 which also allows it to render faster. The gains aren't as evident at this size with one image, but if you're doing a bunch of frames then maybe it adds up.

cool thx, just had a quick look, seems about right.

This is a great tool Indeed! buy Guys, Why I'm having result like this!

I'm running this by contrast=0 --pool-mode=avg, --analogy-w=9 --patch-size=3