feat: add support for persisting user preferences using a default configuration in the REPL

Resolves #2510
Description

What is the purpose of this pull request?

This pull request:

adds support for automatic loading and saving of a default configuration for persisting user preferences in a ~/.stdlib/repl.json file.

Related Issues

Does this pull request have any related issues?

This pull request:

resolves #2510

Questions

Any questions for reviewers of this pull request?

These are the options we are currently persisting by default:

'inputPrompt',
'outputPrompt',
'welcome',
'padding',
'themes',
'save',
'log',
'quiet',
'settings'

We are not persisting:
'sandbox',
'timeout',
'isTTY',
'load'

Is this okay?
Other

Any other information relevant to this pull request? This may include screenshots, references, and/or implementation notes.

No.
Checklist

Please ensure the following tasks are completed before submitting this pull request.

[x] Read, understood, and followed the contributing guidelines.

@stdlib-js/reviewers

Regarding hardReset, should it also reset the current REPL session's settings and preferences? To achieve this, we will have to manually change the prompt, padding and all other instantiation options..

I would think that a hard reset would only reset back to the state of the REPL at instantiation. So whatever is passed or used in the constructor, that should be restored.

What about configuration then? What if the user wants to reset back to the very default settings (like deleting the configuration file)

What about configuration then? What if the user wants to reset back to the very default settings (like deleting the configuration file)

Hmm...I am not sure. I'd say let's punt on this. If a user wants to reset back to default settings, they can do as you say: namely, delete the configuration file. I don't think we need a command for doing this.

Currently, if a user loads a custom config, that is saved to the default config upon closing. Should this be expected behavior?

Currently, if a user loads a custom config, that is saved to the default config upon closing. Should this be expected behavior?

I don't think this should be expected behavior. Simply because I load a config into the REPL does not mean that I want it saved as the default. It's fine to save it as the "last session" config, but not the default.

By default I meant the last session config. Just to clear things up, by last session config do you mean <homedir>/.stdlib/repl.json that we auto load each session?

I'm referring to this comment: https://github.com/stdlib-js/stdlib/issues/2510#issuecomment-2210475169.
Although, my mind may not be entirely clear on this, as we've iterated on what configs should be stored and my mental model may be outdated at this point.

In short, it is not clear to me that what is loaded by default equals what state the settings were when the REPL last closed.

...certain things make sense to persist and be the default next time around (e.g., themes?), but other things less so. E.g., if I temporarily disable auto-closing and forget to re-enable before exiting the REPL, I don't want to have to explicitly re-enable the next time I fire up the REPL. That is just a recipe for user confusion, as it forces them to remember what they did in the last session when starting a new session.
"
It's possible that we could give users the option to "restore" the last session on startup.

I get your use case but it's more likely that if the user disabled auto-closing, they just don't want it. And them having to change all settings to their preferences everytime they boot up the REPL seems more annoying/confusing as it's pretty standard (in IDEs or any application) that once they change a setting, they want it that way.
And if they were just experimenting and fiddling around, they can always just use the settings command to see what's enabled/disabled.
In short, it would be more confusing not saving by default as it would force a user to remember what they changed in the last session so they can change it back again to what they wanted everytime they enter the REPL.

Why don't we avoid this discussion altogether and just prompt a user before exiting the REPL as to whether they want to save current REPL settings when the current REPL settings differ from what's on file? In short, punt the decision to the user.

BTW: you'd still need a last_repl_session.json file to allow manual restore if a user's system crashes while the REPL is open and before settings and other session info could be persisted.

In short, here is a possible summary:

On startup, compare the settings from the last REPL session with the "default" settings (i.e., a user's saved configuration). If these differ, ask the user whether they want to restore the previous session's settings. If yes, restore. If no, overwrite the last_repl_session.json file with the default settings.
During REPL usage, allow changing settings without persistence.
On exit, if the current REPL settings different from their default settings, prompt the user whether they want to save the REPL's current settings. It may be useful to show to the user what's changed. If the user says "yes", overwrite a user's default settings. If "no", don't save and exit the REPL. The user should also be able to hit Ctrl+C to return to the REPL (and not exit) to toggle settings, if the current mix of settings contains some changes they want to keep and others they don't and they want the opportunity to clean this up before trying to exit again.

@kgryte I decided to let them just use a key binding while exiting if they want to save preferences. This way we don't add any additional steps that the user probably wouldn't appreciate.

And I think we can figure out restoring a session upon a crash when we work on being able to save the entire REPL state along with variables etc, is that fine?

Yes, that is fine. So long as in the meantime we are saving the current session settings while a REPL session is underway to a file, such as last_repl_session.json. The restoration can happen in a follow-up PR. Would be good to open an RFC to this end on the issue tracker.

use a key binding while exiting if they want to save preferences

Maybe instead, and only when settings have actually changed during the current REPL session,
In [1]: <Ctrl+C>
Would you like to save the current REPL settings? [Y/N]
Settings saved.
To exit, enter ^D or ^C again or enter quit().

When no settings have changed,
In [1]: <Ctrl+C>
To exit, enter ^D or ^C again or enter quit().

When a user opts not to save settings.
In [1]: <Ctrl+C>
Would you like to save the current REPL settings? [Y/N]
To exit, enter ^D or ^C again or enter quit().

I am not a fan of having multiple keybindings for exiting the REPL. Having two is almost two many. Having three just creates confusion.

This way we don't add any additional steps that the user probably wouldn't appreciate.

Being explicitly prompted to save or affirming that one is okay navigating away from some page when changes have not been persisted is a common user interface pattern. Given that users are unlikely to be changing settings during every session, but once in a while, been explicitly prompted, without the additional cognitive overload of a separate keybinding, is a minor inconvenience at worst.
A REPL is not an IDE or a typical application. It's very essence for doing ephemeral things. So we don't always need to treat it as an IDE where a user explicitly navigates to a settings panel or updates a specific configuration file, where it is assumed that changing a setting results in persistence. In a REPL, most user actions assume the very opposite. And I don't think we should assume that simply because a user changed a setting (e.g., a theme), that this automatically means they want to live with this change forever more (i.e., to persist). So having a separate explicit prompt, independent of exiting keybindings, seems a reasonable compromise and a minor speed bump.

When the user is inside a "profile" meaning they have a custom configuration in any of their parent directories, and then the user saves when exiting, do we update their custom configuration or update the default ~/.stdlib/repl.json?

a custom configuration in any of their parent directories

Good question. I think we need to remember the configuration file path of whatever configuration file was resolved and loaded on REPL startup. E.g., if we resolve a config in the current working directory, we should save to that file on exit.
But oof. That is tricky and could potentially lead to some unexpected behavior if people move around directories with local configs, but, similar to package.json, I think people can get used to the idea that settings changes are propagated to whatever config was loaded on startup.

But what if the configuration was loaded from a .js export, where do we save it then?

what if the configuration was loaded from a .js export

Ugh. 🐉 's everywhere. Sure, *.json for now is fine. We can always revisit later wrt *.js support.

and also, should we prompt them to save after the second confirmation?
To exit, enter ^D or ^C again or enter quit().
// and then after that
Would you like to save the current REPL settings? [Y/N]

Because there is a possibility they might not want to actually quit so it's better to confirm if they are before prompting them if they want to save..?

Because there is a possibility they might not want to actually quit so it's better to confirm if they are, before prompting them if they want to save..?

If they don't want to exit, they can also just hit N and then resume operation in the REPL. Or they can hit Y and it saves. Either way, I think it should be fine to do after the first prompt.

I don't know, I think it would make things confusing and the user might think ^C is for saving and not exiting?
Because if we first show the prompt "do you want to save", and then they might think this is how you save. and might not know if it also exits after that. I think the confirmation to exit first would make things clear that "ok I am exiting the REPL, oh do I want to save? Yeah..". WDYT?

Okay. This is something we can always change later.

https://github.com/user-attachments/assets/093873b7-7507-4131-a93c-fecc9e63603f

@Snehil-Shah Is it possible to avoid the second In [3]: input prompt?

That is there for a reason, as it's not confirmed yet if the user wants to quit or stay. The prompt is there if they want to type again, or they can use ctrl+c again to quit (and if applicable save)

@Planeshifter Agreed, the user should be prompted the same way when using the quit() command


Allow scopes to be added to the authz request: e.g. facebook email

We want to be able to request scopes, e.g. email, in addition to the default, public information.  This is required to get email from facebook.

This has been discussed in #137
I do not remember atm, why it was not merged, but will into it more later.

I am closing this. I will add the part that handles NAMEID_FORMAT_EMAILADDRESS along with a cleanup on #137


Pass in the fee option into makeSpend

Looks good. Waiting on Travis build. If so then feel free to merge.


Feature Request: Support BaseModel inside complex types

Sparkdantic can't parse pydantic models with BaseModel inside array or dict.
PR: https://github.com/mitchelllisle/sparkdantic/pull/349

Released as part of v0.23.0

@mitchelllisle Thanks for the quick review and release!


addenda98: add ParseCorrectedData helper for change codes

This helper should let users bypass the code-specific parsing and give a better interface.
Fixes: https://github.com/moov-io/ach/issues/641

Codecov Report

Merging #643 into master will increase coverage by <.01%.
The diff coverage is 94.11%.

@@            Coverage Diff             @@
##           master     #643      +/-   ##
==========================================
+ Coverage   93.11%   93.11%   +<.01%
==========================================
  Files          64       64
  Lines        5603     5654      +51
==========================================
+ Hits         5217     5265      +48
- Misses        230      232       +2
- Partials      156      157       +1


Put artifact files into root of archive, rather than inside tmp directory

The invexp archives have the executable contained inside the tmp directory, rather than in the ZIP root.

Resolved in 43f5b47


Fix broken lint target

Turns out ALL_PKGS was evaluating to empty string :-(
Resolves #2234

This was supposed to work via make lint-otel target.

With this PR the otel modules are also linted, so make lint-otel can go away.
However, the build discovered lack of tests:
*** directories without *_test.go files:
./cmd/opentelemetry-collector/app/
./cmd/opentelemetry-collector/app/exporter/jaegerexporter/
error: at least one *_test.go file must be in all directories with go files so that they are counted for code coverage
       if no tests are possible for a package (e.g. it only defines types), create empty_test.go
m


Fix wrong type hinting in dump method

Coverage increased (+0.3%) to 57.059% when pulling 8bca2c801af7932e3519a8b40e830c2f3f354fe6 on MJ111:master into c9b4dc68bbadb7e69436aa5da92d7f684075c31c on what-studio:master.


Cache added for the make upgrade command

Coverage remained the same at 100.0% when pulling 9a69c52de093a027f7aae77e38c2f2375e3f4352 on aehsan/cache_added_for_make_upgrade_command into b4eb7ff7b3f3fe23f34ea8015e626be4ee07c937 on master.


Make dedicated projects section for bridges

which projects should go under bridges rather than AS'es? The "other" section already covers stuff like bots and random smaller scripts etc

I think better is to create whole storage of projects grouped by type (as, bot, etc), and separate project pages grouped via tags, for example - all projects related to Hangouts will go to separate page /projects/tag/hangouts, all bridges on /projects/tag/hangouts. And maybe better name will be "Matrix extensions" or addons, instead of "Matrix Projects".


RPC calls to non-localhosts are slow

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (6c1eee9 2023-03-27T11:13:24.314347Z)
What command(s) is the bug in?
forge create
Operating System
macOS (Intel)
Describe the bug
I have anvil running on <IP_ADDRESS>.
I benchmark forge create
time forge create --offline --rpc-url=http://<IP_ADDRESS>:8545 --private-key=…
1.958u 0.247s 0:00.79 277.2% 1+0k 0+0io 0pf+0w

time forge create --offline --rpc-url=http://<IP_ADDRESS>:8545 --private-key=…
1.931u 0.246s 0:06.69 32.4% 1+0k 0+0io 0pf+0w

Why the second invocation takes about 7 seconds to execute, providing <IP_ADDRESS> points to the same anvil service?
Same story with --rpc-url=http://anvil:8545 and <IP_ADDRESS>	anvil in /etc/hosts.

ideally, we fix this in the is_local_endpoint function:
https://github.com/gakonst/ethers-rs/blob/9a5b31a0a2302480080ffe34c9e1f4c957d0fd3d/ethers-providers/src/rpc/provider.rs#L1449

Ok cool! Shall I open an issue on ethers-rs and link it back to here?

Closing—the upstream fix is now in foundry and rpc calls should not be slow anymore (quickly tested and seemed fast enough).


Add support for companion object parents

Hold on, something might be wrong.

Ok, found the bug, added tests, and pushed. Ready for review.

LGTM! Many thanks ... merging :-)


[camera] app crash after setting exposurePoint

Steps to Reproduce
When user touches on screen to focus, the app setExposurePoint to that point and then it crashes.
It just happens in few users in my firebase crashlytics.
Expected results:
Crash does not happen
Actual results:
Fatal Exception: java.lang.AssertionError: The cameraBoundaries should be set (using `ExposurePointFeature.setCameraBoundaries(Size)`) before updating the exposure point.
       at io.flutter.plugins.camera.features.exposurepoint.ExposurePointFeature.buildExposureRectangle(ExposurePointFeature.java:59)
       at io.flutter.plugins.camera.features.exposurepoint.ExposurePointFeature.setValue(ExposurePointFeature.java:13)
       at io.flutter.plugins.camera.Camera.setExposurePoint(Camera.java:6)
       at io.flutter.plugins.camera.MethodCallHandlerImpl.onMethodCall(MethodCallHandlerImpl.java:451)
       at io.flutter.plugin.common.MethodChannel$IncomingMethodCallHandler.onMessage(MethodChannel.java:17)
       at io.flutter.embedding.engine.dart.DartMessenger.handleMessageFromDart(DartMessenger.java:49)
       at io.flutter.embedding.engine.FlutterJNI.handlePlatformMessage(FlutterJNI.java:4)
       at android.os.MessageQueue.nativePollOnce(MessageQueue.java)
       at android.os.MessageQueue.next(MessageQueue.java:335)
       at android.os.Looper.loop(Looper.java:206)
       at android.app.ActivityThread.main(ActivityThread.java:8528)
       at java.lang.reflect.Method.invoke(Method.java)
       at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:602)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1130)

[✓] Flutter (Channel stable, 2.5.1, on macOS 11.5.2 20G95 darwin-x64, locale en)
    • Flutter version 2.5.1 at /Users/maxwell/development/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision ffb2ecea52 (4 days ago), 2021-09-17 15:26:33 -0400
    • Engine revision b3af521a05
    • Dart version 2.14.2

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /Users/maxwell/Library/Android/sdk
    ✗ cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.5.1, Build version 12E507
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2020.3)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.10+0-b96-7281165)

[✓] VS Code (version 1.60.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.26.0

[✓] Connected device (1 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 93.0.4577.82
    ! Error: iPhone is not connected. Xcode will continue when iPhone is connected. (code -13)

! Doctor found issues in 1 category.

Hi @vimaxwell,
Can you please provide a minimal complete reproducible code sample?
Please specify which version camera you're using as well.
Thank you


Game crashing mid-way through a song

Describe your bug here.
All of my songs randomly start lagging and eventually crashes the game around the 2:20 and 2:25 mark.
I don't know if there's an easy solution that I'm missing because I have little coding experience.
Command Prompt/Terminal logs (if existing)
No response
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
All I did was make the mod (Adding Songs, sprites, stages, etc)

do u have the textures and stuff?


Tpagarani dev

name: Pull request
about: Push a change to this project
Motivate of the pull request

[x ] To address an existing issue. If so, please provide a link to the issue.
[ ] Breaking new feature. If so, please decribe details in the description part.

Describe the technical details

What is currently done? (Provide issue link if applicable)
While remove the dependency on activity file, yosys output has to be renamed to work with existing script, otherwise existing flow breaks if power_analysis option is turned off

What does this pull request change?
Copy the yosys output file to another file expected by .openfpga script
Change existing testcase to turn off power analysis and remove dependency on activity file

Which part of the code base require a change
In general, modification on existing submodules are not acceptable. You should push changes to upstream.

[ ] VPR
[ ] OpenFPGA libraries
[ ] FPGA-Verilog
[ ] FPGA-Bitstream
[ ] FPGA-SDC
[ ] FPGA-SPICE
[ x] Flow scripts
[ ] Architecture library
[ ] Cell library

Checklist of the pull request

[ ] Require code changes.
[x ] Require new tests to be added
[ ] Require an update on documentation

Impact of the pull request

[ ] Require a change on Quality of Results (QoR)
[ ] Break back-compatibility. If so, please list who may be influenced.

@ganeshgore The changes look reasonable to me. Can you review it?

I am soon going to have some more refactoring of flow and task scripts. But this looks good to me.

@tpagarani We experienced some CI mismatches when merging this PR. For some reason, the CI shows green but master branch turns red. Can you merge master to dev next time when creating a PR? It can help us resolving the CI issues. Sorry for the inconvenience.


list-prs-for-file dropdown gets hidden behind Symbols panel

Description
The dropdown to list PRs for the current file is obscured behind the opened Symbols panel.
It's easy enough to close the panel to see the content, but it should try to come up to the top of whatever Z index is there.
I found these related bits, might be helpful:

https://github.com/refined-github/refined-github/blob/main/source/features/list-prs-for-file.tsx
https://github.com/refined-github/refined-github/pull/7417
https://github.com/refined-github/refined-github/blob/ce7d7e71c32c11a68e7fa54ce5e46a7227132ceb/source/features/list-prs-for-file.tsx#L40-L53

How to replicate the issue + URL

Visit https://github.com/pypi/warehouse/blob/main/warehouse/packaging/models.py
Open the Symbols panel
Click on the List Pull Requests dropdown
Observe that the behavior is hidden behind the Symbols list

Extension version
24.6.14
Browser(s) used
Chrome Version 126.0.6478.62 (Official Build) (arm64)

I wonder if https://github.com/refined-github/refined-github/pull/7417 was the cause or if it's just a coincidence. cc @Kocal

This is caused by
https://github.com/refined-github/refined-github/blob/037a1d013945d2746e2614aceb359621ab463e18/source/refined-github.css#L177-L180
If we bump that number to 5 we resolve the issue. Follows:

https://github.com/refined-github/refined-github/issues/7408

Thanks!!


separate React from ReactNative

In React Native 0.25, React Native stops wrapping shared React functionality (createClass, PropTypes etc.) and expects end users to import these from the react package instead. This PR implements that behavior.

nice. Is there some way to do this backwards compatible? Or do we need to just reply on peer dependencies and helpful readmes?

@rt2zz I think this is backwards compatible for any version of RN after React was moved to peerDependencies (https://github.com/facebook/react-native/commit/9f01f9677096117da8be721913a09db870505c2f), so going back to 0.21. Haven't actually tested it though.

👍   Took this into branch v1: https://github.com/lwansbrough/react-native-camera/tree/v1
I will PR master with v1 later today. The big issue being the change in response shape from capture.


Tenant aware scheduled commands and notifications

What is the recommended current approach to get tenancy working with scheduled tasks? The problem is that when the scheduled tasks runs it will use the system database connection as opposed to running scheduled tasks in all the tenant databases. It looks like the only way to do this via Artisan command, am I correct?
php artisan tenancy:run

Also it would nice to have out of box support for TenantAwareNotification. Right now the easiest way to get these working is to Queue notification as Tenancy supports Laravel Queues out of the box. Something like this:
<?php

namespace App\Notifications;

use Illuminate\Bus\Queueable;
use Illuminate\Notifications\Notification;
use Illuminate\Contracts\Queue\ShouldQueue;
use Hyn\Tenancy\Queue\TenantAwareJob;

class Announcement extends Notification implements ShouldQueue
{
    use Queueable;
    use TenantAwareJob;

    // Your code here
}

Proposed behavior
It would be nice to have something like this for quick Notifications like database notifications.
<?php

namespace App\Notifications;

use Illuminate\Notifications\Notification;
use Hyn\Tenancy\Queue\TenantAwareNotification;

class Announcement extends Notification
{
    use TenantAwareNotification;

    // Your code here
}

Information

hyn/multi-tenant version: 5.3
laravel version: 5.7

Should be implemented when #711 is working and merged.

Merged, fixed.


canasta add claims the orchestrator is not available

Recreation steps:

Have a successful canasta create run:
canasta create -a megan -i canasta1 -r compose-override.yaml --rootdbpass --wikidbuser wiki --wikidbpass -w defaultwiki
Run a canasta add command pointing to the same canasta instance
$ canasta add -a megan -i canasta1 -s "Second Wiki" -u "wiki2.example.com" -w wiki2 --wikidbuser wiki

This results in the following complaint Orchestrator: compose is not available
This is the conf.json that is generated after the canasta create command
{
        "Orchestrators": {},
        "Installations": {
                "canasta1": {
                        "Id": "canasta1",
                        "Path": "/path/to/canasta/canasta1",
                        "Orchestrator": "compose"
                }
        }
}

docker compose is still working, and as the conf file shows the orchestrator was there for the create command.

Looking at the code I think that error is probably coming from https://github.com/CanastaWiki/Canasta-CLI/blob/2fbcb74ab63d09eed057ae113f86b7ea3d047e68/internal/orchestrators/orchestrators.go#L199-L200
A lot of places emit very similar errors about orchestrators not being available... but this one appears to be the only one to have a capitalized Orchestrator.


feat(polygon, polyline): add path change event

Adds the MVCArray type, and allow to bind to changes in the paths of
AgmPolygon and AgmPolyline

fix #823


System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.Parameter name: start (in v3.0.270)

Bug shows when loading save attached to editor.
To reproduce:
Just open save file with editor.
System Information

OS: Windows 10 1803
Game version: Steam
Version of the editor: 3.0.270

svd_fmt_5_22.zip

Was this save previously edited? It looks like the active buff count was not set correctly in this file for your "Ravenclaw" item.


Refactor/converse messages

Companion PR to https://github.com/OpenVoiceOS/ovos-core/pull/371

note for other devs:

tests removed because they are duplicated from ovos-core
seems like a breaking change, but this api was never stable and introduced in this alpha release cycle
within same alpha version there is no promise of backwards compat


14000855 (PSCIS 198940) - 14000575 (PSCIS 198935) Tributary to Morice River

Should actually be a Tributary to Knapper Creek
Options to fix

fix in QGIS and re-export to submission template to build report
one off fixes in submission spreadsheet

lets fix stream name in qgis and submission spreadsheet then close

fixed in QGIS and pscis phase 1 spreadsheet


Bug: iOS - handle asset not found

Handle when asset is not found + Throw platformException for the details

@erickzanardo Any updates on this one?

@erickzanardo Any updates on this one?

Sorry for the delay, have a lot on my plate atm, Hopefully I will be able to merge this this week!

Released on 0.0.4, thanks again for the contribution!


Support deploying to PyPI automatically from Travis CI

It only requires filling the deploy.user and deploy.password.secure fields as described in https://docs.travis-ci.com/user/deployment/pypi/

Codecov Report

Merging #21 into master will not change coverage.
The diff coverage is n/a.


atom-beautify not respecting .bashrc and similar

Description
To beautify Rust, you need to use rustfmt.  In some situations, you need to manually link a library on Unix systems (see here).
As advised in that thread, I put export LD_LIBRARY_PATH=$(rustc --print sysroot)/lib:$LD_LIBRARY_PATH into my .bashrc and then source'd it.
After this, rustfmt works from the console, but still displays the same error as before when trying to beautify.
Input Before Beautification
< Any Rust code >
Expected Output
< Formatted Rust code >
Actual Output
The code was unchanged, but this error popped up:
dyld: Library not loaded: @rpath/libsyntax-714ca9b0aa3bf580.dylib Referenced from: /Users/<name>/.cargo/bin/rustfmt Reason: image not found
dyld: Library not loaded: @rpath/libsyntax-714cb9b0aa3bc413.dylib
  Referenced from: /Users/<name>/.cargo/bin/rustfmt
  Reason: image not found

Steps to Reproduce

Add Rust code to Atom editor with rustfmt installed
Run command Atom Beautify: Beautify Editor
The above error is thrown

Debug
Here is a link to the debug.md
Checklist
I have:

[x] Tried uninstalling and reinstalling Atom Beautify to ensure it installed properly
[x] Reloaded (or restarted) Atom to ensure it is not a caching issue
[x] Searched through existing Atom Beautify Issues at https://github.com/Glavin001/atom-beautify/issues
so I know this is not a duplicate issue
[x] Filled out the Input, Expected, and Actual sections above or have edited/removed them in a way that fully describes the issue.
[x] Generated debugging information by executing Atom Beautify: Help Debug Editor command in Atom and added link for debug.md Gist to this issue

From your logs:
2017-06-24T00:41:46.908Z - debug: [var/folders/4y/1my687s97v5dnx6_zntcvz4w0000gp/T, ATOM_DISABLE_SHELLING_OUT_FOR_ENVIRONMENT=true, ATOM_HOME=/Users/Kieran/.atom, NODE_PATH=/Applications/Atom.app/Contents/Resources/app/exports, NODE_ENV=production, NVM_BIN=/Users/Kieran/.nvm/versions/node/v4.2.4/bin, ITERM_SESSION_ID=w0t1p1:F8DF32E3-0B76-406B-B72C-91CA8F5D053D, TMPDIR=/var/folders/4y/1my687s97v5dnx6_zntcvz4w0000gp/T/, NVM_PATH=/Users/Kieran/.nvm/versions/node/v4.2.4/lib/node, TERM_PROGRAM=iTerm.app, COLORFGBG=15;0, __CF_USER_TEXT_ENCODING=0x1F6:0x0:0x0, SHELL=/bin/bash, HOME=/Users/Kieran, GOBIN=/Users/Kieran/Documents/Programming/Go/bin, _=/usr/bin/open, SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.f8RRzCeHdZ/Listeners, NVM_IOJS_ORG_MIRROR=https://iojs.org/dist, RBENV_SHELL=bash, TERM_PROGRAM_VERSION=3.0.15, SHLVL=2, swap=/Volumes/Swap, data=/Datalink/OSXData, TERM_SESSION_ID=w0t1p1:F8DF32E3-0B76-406B-B72C-91CA8F5D053D, Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.tEMPy5p2w8/Render, NVM_CD_FLAGS=, DISPLAY=/private/tmp/com.apple.launchd.h9tD5F3cRi/org.macosforge.xquartz:0, PATH=/Users/Kieran/.rbenv/shims:/usr/local/sbin:/Users/Kieran/.nvm/versions/node/v4.2.4/bin:/Users/Kieran/.cargo/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Users/Kieran/Documents/Programming/Go/bin, TERM=xterm-256color, LOGNAME=Kieran, XPC_SERVICE_NAME=com.github.atom.59232.B44EF473-9C48-49EC-A074-CD38219C418A, COMMAND_MODE=unix2003, LANG=en_CA.UTF-8, ITERM_ORIG_PS1=\W $ , GOPATH=/Users/Kieran/Documents/Programming/Go, NVM_NODEJS_ORG_MIRROR=https://nodejs.org/dist, NVM_DIR=/Users/Kieran/.nvm, ITERM_PROFILE=Default, USER=Kieran, SECURITYSESSIONID=186a7, MANPATH=/Users/Kieran/.nvm/versions/node/v4.2.4/share/man:/usr/local/share/man:/usr/share/man:/opt/X11/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man, XPC_FLAGS=0x0, PWD=/Users/Kieran/Documents/Programming/Rust/udemy/module_1, ITERM_PREV_PS1=\[�]133;D;$?��]1337;RemoteHost=Kieran@KIERAN-PC��]1337;CurrentDir=/Users/Kieran/Documents/Programming/Rust/udemy/module_1��]133;A�\]\W $ \[�]133;B�\], GOOGLE_API_KEY=AIzaSyAQfxPJiounkhOjODEO5ZieffeBv6yft2Q
2017-06-24T00:41:46.908Z - debug: [] spawn /Users/Kieran/.cargo/bin/rustfmt 0=--version
2017-06-24T00:41:46.935Z - debug: [] spawn done null dyld: Library not loaded: @rpath/libsyntax-714ca9b0aa3bf580.dylib
  Referenced from: /Users/Kieran/.cargo/bin/rustfmt
  Reason: image not found

2017-06-24T00:41:46.936Z - verbose: [] spawn result, returnCode
2017-06-24T00:41:46.936Z - verbose: [] spawn result, stdout
2017-06-24T00:41:46.936Z - verbose: [] spawn result, stderr dyld: Library not loaded: @rpath/libsyntax-714ca9b0aa3bf580.dylib
  Referenced from: /Users/Kieran/.cargo/bin/rustfmt
  Reason: image not found

I do not see LD_LIBRARY_PATH in there. However, it is expected that Atom itself handles resolving the environment variables -- I think this occurs on Atom load.
I think this is the latest Atom issue which you could comment on and subscribe to: https://github.com/atom/atom/issues/4126
After the merge of https://github.com/Glavin001/atom-beautify/pull/1735 Atom-Beautify will no longer be handling the support of environment variables, as this is Atom's responsibility. I hope the Atom team is able to help you. Thanks for your understanding!


problem with panel batch may 2021 PH3 64*64 V4.1 HX

I have a problem with a display that was delivered the other day ( ordered in may) The pcb layout is a it different. Same chipsets but the power connected is rotated 90 degrees, compared to the older panels. I have trouble getting this one going....see the video I send to the seller....
Anyone who has an idea what is going on there?
https://user-images.githubusercontent.com/60584210/121424145-50dbc680-c971-11eb-94e5-c651e70aa6ea.mp4

Firstly, thank you for making such a great video! This video is the standard of how people should report issues!
Secondly, I think we've seen this before, and @vortigont fixed this as part of: https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/issues/75
You need to change the config to invert the clock signal.
mx_config.clkphase = true;

https://user-images.githubusercontent.com/60584210/122685010-463eee00-d209-11eb-8125-46379118bb27.mp4
Looks like this issue is not solved completely, No idea what changed but inverting the clkphase doesn't work this time.
I played around with some setting but can't crack it:
mxconfig.clkphase = false; // some panels need a  reversed clockpulse I first encountered it in batch may 2021 PH3 64*64 V4.1 HX
mxconfig.latch_blanking = 4;
mxconfig.i2sspeed = HUB75_I2S_CFG::HZ_10M;

For those of you who cant open the video, here is an external link:
http://www.judoles.nl/Projecten/fail.mp4

Is this the same problem panel or another one? Can you make sure there's proper grounding between the power source powering the HUB75 and the ground on the signal pins. They need to both be connected together to a common ground.
What is the chipset?
Try the legacy tree as well, but this has a different setup however (none of this mxconfig stuff):
https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/tree/legacy-1.2.4
Although the legacy branch doesn't have the clock phase inversion, you'll have to hack the copy of the exp32_i2s_parallel.c and add
  if (conf->clkphase)
    GPIO.func_out_sel_cfg[cfg->gpio_clk].inv_sel = 1;

... somewhere around line 200

No ground issues for sure.
Chipset: 7258
same panel as before.
Ill try the legacy and let you know

Also, With the legacy branch you also need to clearscreen every time and repaint before the brightness change takes effect.

I made some progress,
I tried the legacy branch but didn't get it going at all and I didn't spend any time to figure out why.
Instead I concentrated on the new lib. Here is what i learned so far:
These new panels have a mix chipset.  Near the power connector there are ships: RUC7258 but at the bottom and top the chips are labelled: MBI5124
I am using the latest Lib version 2.05 which i confirmed in the compilation log
So I changed the config to: mxconfig.driver = HUB75_I2S_CFG::MBI5124;
The clock phase has no effect as it is hard encoded in the library at line 29
This is getting close!! I can now adjust brightness of the lower part of the display seems like the upper part( I guess the 'E'-pin part..is not working correctly. it is not displaying the right data and it is gosthing when i increase brightness...
https://user-images.githubusercontent.com/60584210/122820652-23313e80-d2dc-11eb-959c-9f40e29f135b.mp4

Wow… Now these china manufacturers can’t even be bothered to use the same chip across the same panel.

This is getting close!! I can now adjust brightness of the lower part of the display seems like the upper part( I guess the 'E'-pin part..is not working correctly. it is not displaying the right data and it is gosthing when i increase brightness...

Actually, the R1, G1 and B1 pins are used to paint the top half, and the R2, G2 and B2 paint the bottom half.
Therefore, can you please swap the pin mapping in your config for the R1/R2, G1/G2, B1/B2 pins around? Yes, this will show a screwed up image with the bottom half painting of the animation painting on the top... but if the top half (per your video) is still blurred then the issue is a different chip issue.
I'd try get a refund from the seller as well by the way.

Also comment out line 29 and try with true/false in your config and see if that fixes it. Who knows.

Also comment out line 29 and try with true/false in your config and see if that fixes it. Who knows.
Doesn't improve...it really needs to be set to true or not even the bottom half will work
Therefore, can you please swap the pin mapping in your config for the R1/R2, G1/G2, B1/B2 pins around? Yes, this will show a screwed up image with the bottom half painting of the animation painting on the top... but if the top half (per your video) is still blurred then the issue is a different chip issue.
Doing this will swop the bottom half and top half but the issue with the top half remains the same.
I see a lot of improvement when i add a pull up resistor (10K to 3.3v) to the lat pin
I will use an oscilloscope later this week to see what is happening on these pins.
maybe this is a version that really needs that 5V Bus, I will measure and try some level shifters  and report here

A little progress update.
Turns out that it is not the pull up resistor that makes a difference but more the long wire I used....This puts me in the capacitance domain. I used the oscilloscope to look at the data bus and all looks fine, no jitter, no explainable voltage levels... But whenever i connect my oscil. probe to the lat pin...the problem is gone....same if i attach a long wire...so...in the end, putting a 100pf cap on the lat pin to gnd solves all...However, I can't help the feeling that this is a workaround. My guess is that this display version has a problem with the bus frequency..... I tried the i2sspeed at 10Mhz and 20Mhz...makes no difference..is there any way to go lower?
I still have to try using the level shifters as that might make a difference too.  In the end we will have a completed topic with hopefully a conclusion and fix or workaround

Great work. Physics and parasitic capacitance strike again.

Whilst the DMA can be made to run at lower speeds, flicker starts to be
visible with the naked eye. Hence why the min frequency of 10mhz. I'd fix
the electrical issue rather than degrade image quality.

In saying that, if you really want to reduce the DMA frequency then you'll have to hack the esp32_i2s_parallel_v2.c file.
Change line 228 from
dev->clkm_conf.clkm_div_num = clk_div_main;

To
dev->clkm_conf.clkm_div_num = clk_div_main*2;

To halve speeds again.

Also, can you try the shorter cable from the esp32 to the first display? Perhaps see if you can get some other better cables as well.
I have had noise issues from using those long 16 pin cables... The price of convenience.

so...in the end, putting a 100pf cap on the lat pin to gnd solves all...However, I can't help the feeling that this is a workaround.

seems to me that the issue is not a speed but bad timing. Putting a cap to LAT you make it's transient more continuous and introduce a delay between LAT transition an OE/addr lines. Need to check timing diagrams for those chips (yeah, mixing different ones on the same panel is a nice way to screw things).
I believe that shifting clk phase to +-90 degrees could fix that, but it is not possible with current i2s design. Reducing clk speed won't help here either. If you are not happy with cap you may try to put a series of 2 or 4 level shifters to the Clk or LAT line. It won't change signal phase but will introduce a propagation delay to the line that might help

Personally I think @donnersm should raise a dispute with the seller and get his money back.
Seems like a garbage panel to me, especially given it has different chipsets for each half.

Personally I think @donnersm should raise a dispute with the seller and get his money back.
Seems like a garbage panel to me, especially given it has different chipsets for each half.

actually....they say its normal.....( is disagree... but never the less..this is what they say) see foto

That doesn't even make any sense. Just raise a dispute anyway.

That doesn't even make any sense because clearly they don't understand that the top and bottom halves of the panel are different shift register chips right (at least that's what you said). Videos prove this in any case.
You won't get anything other than noise from the chinese autotranslation. I doubt they understood your videos as well given the were in English. Just raise a dispute anyway.

This does make sense, what they are saying is that the MBI5124 is the low side shift register and the 7258 is the high side row driver.

It's irrelevant to what @donnersm stated:

These new panels have a mix chipset. Near the power connector there are chips: RUC7258 but at the bottom and top the chips are labelled: MBI5124

@donnersm
I've randomly hacked the library in a different tree - no idea what I'm doing, but see if this makes any difference. Use this:
https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-I2S-DMA/tree/donnersm

Ok I dit raise a dispute but this topic is not about that...
I tried the hack with factor 2, 4 and 16... at 4 it is already so much flickering that it becomes irritating. More important the hack doesn't solve the issue. Even at lower speed, the display is still messed up.
In conclusion, I wasn't able to get it to work by changing the software. I got it working by using a very short flatcable and the 100pf cap on the LAT pin to ground.  When I swop the left and right panels, there shouldn't be any difference but, to my surprise, there is!   In the end, I got a working setup using the workaround.
Thanks all!
I shared my progress for anyone who runs into simular problems. Hope this topic can help them.
Here is a short preview of what i am working on:
https://www.youtube.com/watch?v=6ib_ivA0M0Q

Thanks for the update. Great work with the equaliser.


rtop finishes parsing when not terminated with a ; with no execution

Reason # let f = fun n => n;
let f : 'a => 'a = <fun>
Reason # f 1
Reason # f
Reason # f 1;
- : int = 1

cc @jordwalke @yunxing this is a bit troublesome because it swallows errors.

I don't think this was always the case.

@simonjbeaumont Sorry just saw this. I think this could be related to some of the stuff that I added to support rtop -stdin and use file.
Let me see what's a good solution here.

This should have been fixed in trunk. Closing it.


Requiem&Requiem2 B1

Node Requiem & Requiem2

Node : Requiem
ID : a3c69857d159e63e
Logs attached.
concordium-testnet-node-8cdfb1cb7dbc767af4b1cd5e0686d4a87967c197ec8f01ef4176af9a9fcd3b0f.log
concordium-testnet-system-report.log

Node: Requiem2
ID: 0abfcd689da43905
Logs attached.
concordium-testnet-node-5d3e6327df54f058507c1a6531c1724b6121eb7877839ccf20858d5fb970e03e.log
concordium-testnet-system-report.log

also 2 node id - 45 days full logs attached. fyi.
concordium-testnet-node-51d8aca41f71522f20553554a612c7ad1acb4582e20a3265fde000838fdbb0e7.log
concordium-testnet-node-70acae9bfb60e56b81c38b77904aad7ee217436777aeb93c45e7c6b9c0b0c705.log

confirmed:B1
node:a3c69857d159e63e

confirmed:B1
node:0abfcd689da43905

Concordium testnet3 form submitted. 21.04.2022 / 20.03 UTC +3


update readme to fix instructions for gpg

Something changed in recent version of the libraries within openjdk:8-jdk-slim docker image and now the existing steps were failing with erro gpg: cannot open '/dev/tty': No such device or address.

Thanks @antonmos for reporting the issue, and thanks @tianon for suggesting --batch!
@antonmos: I updated your PR to use --batch accordingly

I just tried it with --batch and it failed:
gpg: directory '/root/.gnupg' created
gpg: keybox '/root/.gnupg/pubring.kbx' created
key 9A84159D7001A4E5:
1 signature not checked due to a missing key
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 9A84159D7001A4E5: public key "Thomas Orozco<EMAIL_ADDRESS>imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
gpg: no signed data
gpg: can't hash datafile: No data
The command '/bin/sh -c apt-get update  && apt-get install gnupg -y  && gpg --batch --keyserver hkp://ipv4.pool.sks-keyservers.net --recv-keys 595E85A6B1B4779EA4DAAEC70B588DFF0527A9B7  && gpg --batch --verify /tini.asc' returned a non-zero code: 2

Per the last message in the debian bug it seems that --no-tty is the recommended solution

@antonmos, it look like you are forgot to download tini, since the error is: gpg: can't hash datafile: No data

My Dockefile is unchanged other then changing from --batch to --no-tty.  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913614#40 for more info.

For the life of me, i cant find where the man page explains how to "specify the data file explicitly". @yosifkit any idea?

Never mind, figured it out. Updating the new PR.


Unify the convention of functions that operate on multiple values

Elvish has two different conventions for functions that operate on arbitrarily many values:

Variadic functions take an arbitrary amount of arguments (possibly after several fixed arguments). Examples include echo, pprint, +.

argument-or-input functions take an optional list argument (also possibly after fixed arguments). When the list argument is present, it operates on the values in the list. When the list argument is missing, it operates on the values from the input. Examples include each, to-json, str:join.

It is not always clear which category a function falls into or should fall into, and it can get confusing when people make the wrong assumption. Some examples:

It is confusing that to-json [] outputs nothing instead of '[]'. The correct way to serialize [] into JSON is put [] | to-json, or to-json [[]], since to-json is an argument-or-input function.

While pprint is a variadic argument, there is a request to make it take input values (#736). The current solution is ... | pprint (all). That issue also contains some earlier discussions about this topic.

It is not clear which category the to-be-introduced math:min and math:max functions should be in (#967).

The obvious way to unify these two conventions is to let commands (1) be variadic, and (2) read from inputs when there are no arguments. Indeed, this is the convention used by almost all the classical UNIX text-processing commands. The problem with that is with code like this:
cat $@files

And it can be surprising if $files is an empty list. The programmer might have intended this code to read from stdin when $files is empty, but it's more likely that they intended this code to not do anything while $files is empty. Since there are many constructs in Elvish that output multiple values (output capture for example), this problem can be very pervasive.
We cannot fix problems in the classical tools, but at least we can avoid the same problem in Elvish's builtin functions. In fact, the motivation of the argument-or-input convention was to avoid this mistake. Consider the following examples with each:
each [x]{ cat $x } $files

When $files is empty, each gets an empty list, so it's clear that it should do nothing, instead of reading from input.

This is not a new problem: any language that support both variadic arguments has to choose whether each function should accept variadic arguments or a list, and it's sometimes arbitrary. In Elvish the problem gets more complex since the problem of inputs gets involved.
The max function in Python accepts both variadic arguments, or a list:
max(1, 2, 3) # this works
max([1, 2, 3]) # this also works

(I do not consider this an example to be emulated.)

argument-or-input functions take an optional list argument....

That is an incomplete description of the current behavior since "argument-or-input" style commands also take zero or more fixed arguments just like variadic functions. Which you included the in characterization of "variadic" style commands. Consider the builtin joins command which has one fixed argument, the separator string, that must be present.

One tiny bit of anecdata: I got bitten by the to-json behaviour just the other day.

With regard to this example:
cat $@files

@xiaq wrote:

And it can be surprising if $files is an empty list. The programmer might have intended this code to read from stdin when $files is empty, but it's more likely that they intended this code to not do anything while $files is empty.

I agree it can be surprising if $files is an empty list that expands to zero arguments. If there is no elvish function named cat I don't see how to avoid the problem. If cat is an external command it is run with zero arguments and reads from stdin. If cat is an elvish function that is a different situation.
Wouldn't it be reasonable to communicate to the function whether or not there was an argument not tied to a fixed parameter even if that argument expanded to zero values? That would allow the function, and the generic "argument-or-input" processing code, to fallback on reading from their stdin stream only if no arguments were supplied; regardless of the fact they expanded to zero values. Or do something else that was appropriate for the situation.
In other words, if I cat $@files and $files is an empty list I don't want an elvish cat to read from stdin. The question is how to square that behavior with that of external commands that are run when a var expansion is empty.

@krader1961 re the description of argument-of-input functions, I corrected it :)
@krader1961 re "sending information on whether there was an argument": that works in the limited example you gave, but consider this immediate difficulty: say str:join is converted to such a function; str:join ',' $@a works, but what about str:join $@a? Was there an "intended final argument" or not - does it depend on the length of $a?
But that is just an illustrative example, the more nasty issue is that it breaks a basic, almost tautological, principle in programming languages: if expression X and expression Y evaluates to the same, they should behave the same in all contexts. (I am not aware of a name for this principle, but let's call this the equivalency principle.) In Elvish's case, $@a evaluates to no values if $a is empty, so it must behave the same with no values; breaking this will only lead to more difficult corner cases (I'm quite sure one can find such more over time).
One may argue that use of str:join $@a must be really rare because the first argument (the separator) and the rest (the strings to join) are quite different and shouldn't be mixed in one $a list. While this still does not justify breaking the equivalency principle, this does correctly observe that "variadic arguments" (a term I now use liberally for any conceptually arbitrary many arguments) are usually quite different from "fixed arguments" and they usually do not mix. In fact, the convention of argument-or-input function is a manifest of that: the "variadic arguments" in this case are either supplied as inputs (completely separate from fixed arguments) or a list (visually separate from fixed arguments). Even in the case of true variadic functions, almost all of them do not take any fixed arguments at all, so there are only variadic arguments.

Possible solution 1.
The observation leads to one hypothetical design: make a syntactical distinction between "variadic arguments" from normal arguments. This is comparable to how Elvish makes a syntactical distinction between options and arguments. Let's say we make % a metacharacter for separating fixed arguments and variadic arguments (this is clearly just for illustration's purpose), the unified convention works like this:

Variadic arguments can only appear after the separator. There could be 0 variadic argument.

If the seprator appears syntactically in the command, the command operatees on those arguments.

If the seprator does not appear syntactically in the command, the command operates on values from the input.

Examples:
str:join ',' % a b c # writes "a,b,c"
str:join ',' % # writes ""
str:join ',' # reads from input
put a b c | str:join ',' # writes "a,b,c"
str:join ',' % $@a # joins elements in $a

This syntax is quite acceptable for current argument-or-input functions, but it makes the current variadic functions much harder to use. Having to write + % 1 2 3 is exceedingly annoying.

Possible solution 2.
Another idea is to make the "read from input" behavior explicit rather than implicit. So the rules are:

Functions take variadic arguments.
If there is a placeholder "read from input" argument, say $input, the function reads from the input.

This does not change anything for the current variadic arguments. For current argument-or-input functions, it works like this (still using str:join as an example):
str:join ',' a b c # writes "a,b,c"
str:join ',' # writes ""
str:join ',' $input # reads from input
put a b c | str:join ',' $input # reads from input

This is actually kind of nice, but my problem with this is that it makes the style of passing values via the pipeline more verbose, and discourages it. Users who do not use the pipeline style a lot may find this fine; but I have a strong preference to encourage more pipeline uses, not fewer.

Non-solution; an idea.
In #736 I mentioned an idea of making argument-or-input functions only take values from the input, never arguments. Using str:join as an example again, disallow this:
str:join ',' [a b c]

And only allow this:
put a b c | str:join ','

And to make this slightly more ergonomic, make lists write out their values when called, so that the following also does the same thing:
[a b c] | str:join ','

This is an idea motivated by "pipeline fundamentalism" and does not solve the problem in this issue, but perhaps some variant of this can be part of the overall solution.

To clarify, I like neither of two "possible solutions" I put forward above, they are intended as straw man proposals.

I need to think more about this problem but I'll point out that the fact the legacy joins, and the recently added str:join, require a single, fixed, separator argument is arguably a mistake. It looks like this is an artifact, presumably, of builtin:joins having been written before function options were supported. Today it would probably be better for both commands to take a &sep option that defaults to a single space or an empty string. That would address a couple of issues raised in this issue. Such as what str:join $@list means. My opinion is it means the first element of the list is the separator char. But if the separator has to be specified as an option then that is no longer a question.

@krader1961 my guess is that the mandatory separator argument is because historically a lot of "join" functions require one. In a cursory search, the "join" functions in Perl, Python and Go all require a separator, whereas Clojure's and PHP's default to an empty string.
@xiaq as for the main topic, I think both the variadic and argument-or-input make sense, and which one makes most sense depends on the function. At the moment only variadic is a language feature, since argument-or-input parameters need to be implemented by each function (I even wrote such a function util:optional-input).
How about leaving still the choice of the model to each function, but make argument-or-input also a language feature? For example, just like variadic arguments are declared with @args, argument-or-input could be declared with %args.

Solving this problem is one of the primary goals of my own open-source project.  I suggest that this is NOT a language problem, but rather a usage problem.  I think that it is critically important to distinguish between the two.  I think that it is also critically important to correctly identify which category fits any particular use case.  Allow me to make this a bit more concrete.
If I say cat $File, and File is undefined, I love that Elvish treats this as a language problem and rightly throws an exception.  I hate that other scripting languages do not handle this, or make it extremely difficult to do so consistently.
If I am referencing the variable File in my script, but defining it is not within the scope of my own code (for whatever reason), then I might have a problem.  How do I avoid throwing the exception, if my code got called but the caller did not define File?  That is a usage problem, and is NOT a language problem.  I can simply write a test for the existence of the variable File before I invoke cat $File.  That rightly shifts to problem to the script writer instead of putting it upon Elvish.
Assuming that I have written such a conditional to test for the existence of somebody else's variable File, what else can go wrong?  As discussed, what if $File is empty (in its various forms)?  Again, I classify this as a usage problem, NOT a language problem.  It is NOT Elvish's problem to protect the user from every possible way that they might misuse the various syntax and commands based on trivial things like whether they actually provided a non-empty argument.
I think that it is essential for us to notice that no programming language can EVER have enough information to properly guess how to handle such a situation.  We are not mind readers, and neither is the machine running our programming language.  Therefore, we should NOT try.  Instead, we should clearly categorize this as a usage problem, then ensure that we have provided the user with some recourse for handling such issues in the various ways that MIGHT apply in any particular situation.
I perceive the discussion above as perhaps being stuck on such an attempt to guess how to properly handle an unknown usage problem; I see it as "borrowing trouble".  I think that much of what we end up hating about various programming languages can be attributed to getting this wrong:  attempting to treat a usage problem as a language problem, thereby making the language arbitrary and ugly in some particular aspect (such as the comment above about Python's max).
I have already implemented part of my project's solution to this usage problem in Fish.  I intend to do the same in Elvish as I make the transition.
I wrote a series of Fish functions that I (and my users) can invoke to routinely solve these kinds of usage problems, which are rampant in SRE/DevOps use cases.  I NEVER write cat $File, then let it go bad in all the various ways when a user executes the script.  Instead, (in Fish) I write cat (file (var File)).  In this case, cat is still the external command (or perhaps a wrapper) that will still fail if used improperly.  File is still a reference to a variable that might not be defined yet, which is NOT protected in Fish as it is in Elvish.  Both file and var are Fish functions that I wrote to handle this usage problem.
My file and var functions, and the rest of their siblings, allow me to apply a very simple pattern to protect my script.  These functions are called using output-capture () syntax, which is the same in Elvish and Fish for this use case.  Each function takes a single input, and returns a single output.  Along the way, each function asserts various conditions (side effects) that must be true at that point in the calling script regarding the provided input.  If any condition fails, an exception terminates the script (fail-fast) with a usable error message pointing directly at the location in the script.
In a few cases such as var, the output is a simple and obvious transformation of the input.  My var function expects the name of a variable and it outputs its value (if any).  If the variable is undefined, then var throws an exception.
In most other cases such as file, the output is (nearly) identical to the input.  This function validates that the input is a single (not empty, not variadic) value that refers to an existing regular file that is readable by the user.  Along the way, the value is transformed into the canonical absolute pathname of the file.
Going back to cat (file (var File)), we can now see that this is a very concise but readable invocation to output the contents of File, BUT it handles the unhappy paths in a fail-fast manner with clear messages.  This simple invocation protects the script against ALL these unhappy paths, while giving a stack trace with these (almost literal) error messages:

variable "File" is UNDEFINED
Value is EMPTY
Value is MULTIPLE instead of singular
Path "PATH" does NOT EXIST
Path "PATH" is NOT A REGULAR FILE
File "FILE" is NOT READABLE

As you can see, it is then easy to compose these little validation functions to cover a wide variety of usage problems that arise in scripts.  These functions properly handle these problems instead of burdening the relevant language to do so.  I believe that this is a crucial concept that needs to be communicated and practiced across our industry, especially when it comes to infrastructure automation.  Solving this ONE problem will have a massive positive impact.  I hope to help solve many others along the way with appropriate understanding, patterns, and simple implementation.
I think that matches and complements what is being attempted with Elvish as well.  Thank you!
Back to the original problem at hand...  I suggest that Elvish should not try to guess, but instead should require the user to be explicit about their intent.  I suggest that Elvish should provide a simple way in the syntax for the user to tell any command that it should expect its input on STDIN rather than as arguments.  I wonder whether the common convention of a - argument would serve that purpose.  If so, could Elvish then apply that consistently, and also make it easy for users to apply the same convention to their own functions?
What do you think?

By the way, in Elvish I am anticipating a syntax like cat (f (v File)) for the same purpose as what I wrote above for Fish.  I feel that these little validation functions will be so omnipresent that they deserve single-letter abbreviations.  Elvish already handles undefined variables (yeah!), nevertheless, I will still write something like my var function to handle cases where the variable is defined outside the script author's scope.


a.Highcharts.error

Hello everybody:
first, i sorry by my horrible english.
I am working in a project with vue-highcharts but at moment to run display this error (TypeError: a.Highcharts.error is not a function) and them nothing!
Someone happened something like this?
I hope you can help me.
Bye people and thanks.

Could you provide a minimal example to reproduce this error?

The Highcharts.error API is introduced in v5.0.6, I'm guessing it might be you're using a previous version. If you still get this error after checking the Highcharts verison, please provide a example to reproduce this error and fell free to reopen this issue.


Add SSDM

Insert URLs to the project here:
https://github.com/sylvainschmitt/SSDM
In one sentence, explain what the project is about:
A package to map species richness and endemism based on stacked species distribution models

[x] The projects is active, documented, open source licensed, shows usage from external parties and is directly targeting environmental sustainability. Find more details in the Contribution Guide.

All issues marked as 'Good First Issue' of the project listed on OpenSustain.tech will be visible on ClimateTriage.com. This is a great way to welcome new community members to your project.

@lukasbaumbach @sylvainschmitt


Added the double entry principle

the double entry principle was added.

Oh, nice. Thank you very much, Olya.

Do you not intend on createing an interface for the app?

@olamilekan000 I struggle to understand your message. Would please rephrase your question?

I mean a UI for your application. Are you not making one?

This module is a low-level library which should be used by any node.js application. Creating a UI for such a module is a very unexpected move.
No, we do not plan to do that. Sorry.

Ok. I was thinking since it's an accounting system a UI should go with it but it's all good.


Text exceeds standard Obsidian margins

Is there a way to have the algorithm code block wrap the LaTeX?

I believe this is a MathJax thing:
https://docs.mathjax.org/en/latest/output/linebreaks.html

Automatic line breaking has not yet been implemented in MathJax version 3, but is high on our list for inclusion in a future release.

MathJax isn't great and lack features, which is why I made this plugin to begin with; but I certainly did not expect it to not even have any kind of automatic line breaking.
There might be some workaround by manipulating the CSS, but I have not looked into it yet. I will let you know if I do find one.

Closing since this is not a plugin or Obsidian issue


BANDWITH: Add DYNAMIC option to be able to autoselect default interface

I often switch between Ethernet and wifi, so it is always a pain to manually change the config file when It happens.
I added an special interface name "DYNAMIC" that when is use will force yabar to take the interface of the default route of your computer.
It fallback to loopback interface if none is found.

Any interest in it ?

Updated with your comments in mind.
I also removed the 2nd goto, as I added it since before my cleanup the function was more complex, now it is not needed anymore

Done

Done

Nice, thank you!


Error 1031: Table storage engine '' doesn't have this option.

2018-09-11 15:05:22 [ERROR] Skipping ::<local_dir_and_schema.sql>::
Error executing DDL: Error 1031: Table storage engine for '' doesn't have this option.

I've gotten Error 1031 when I ran "skeema diff". what this really weird is it only occurred on mysql 5.6 docker. Once I upgrade 5.7, it's not an issue anymore.

Thank you for trying out Skeema and reporting an issue! I may need more info to debug this, but I have an initial hunch.

If you try using skeema diff --connect-options="innodb_strict_mode=0", does the problem go away in MySQL 5.6?
Was this table originally created as MyISAM and later converted to InnoDB? (or perhaps is this diff intended to change the storage engine?)
If you manually run SHOW CREATE TABLE on the table, are there any unusual table-level settings present at the end, such as ROW_FORMAT or KEY_BUFFER_SIZE?

And/or are there any such clauses in your *.sql file? If so, did you put them there manually, or were they placed there automatically by Skeema (e.g. skeema init, skeema pull, or skeema lint)?

The most common cause of this error is that a MyISAM-to-InnoDB conversion can leave a dangling ROW_FORMAT clause, even though that clause doesn't do anything in InnoDB. In mysql 5.6, innodb_strict_mode is overly picky and rejects such no-op ROW_FORMAT clauses; mysql 5.7+ ignores it even with innodb_strict_mode. As of the latest Skeema release, it now defaults to enabling innodb_strict_mode in its connections.
Skeema typically proactively removes/ignores such clauses, so I didn't think the new innodb_strict_mode default would break any mysql 5.6 users. But perhaps some code path isn't removing these clauses properly, which I'll track down if it's the case.
If the problem is caused by something other than the above theory, can you please post the SHOW CREATE TABLE output (original state of the table) and the corresponding *.sql file (desired new state of the table), and/or a brief description of the intended diff? If you can't post this publicly, feel free to email me at the address on any Skeema git commit -- if you clone the repo and run git show -s --format='%ae' HEAD it should show my email. Thanks!

Thanks for explanation. The problem only should be happening for mysql5.6. (I totally agree for it if someone said 5.6 is not the greatest one:-1: ). As I follow your guide by using the option(innodb_strict_mode=0) with skeema, this is working fine.
However, I've already put it on the global variables before to try that. I guess this value is dynamic as well.
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| innodb_strict_mode | OFF   |
+--------------------+-------+
1 row in set (0.00 sec)
Once again, thanks for sharing it. I've first seen your project at Percona live 2017 but this is a truly my first time examine it.

Here is the detail of steps that I've ran.

skeema init -d mysql56_test -uroot -p -P6603
add client.sql to the folder
skeema diff (without option provided)

And configuration files and more
::docker-compose.yaml::
version: "2"
services:
db1:
image: mysql:5.7
command: --datadir=/var/lib/mysql/data
volumes:
- "db-data1:/var/lib/mysql"
- "db-log1:/var/log/mysql"
- "db-cnf1:/etc/my.cnf"
- "db-tmp1:/tmp"
ports:
- 3306:3306
networks:
db_br:
ipv4_address: <IP_ADDRESS>
environment:
MYSQL_ROOT_PASSWORD: complex_pw
MYSQL_DATABASE: test1234
restart: unless-stopped
db2:
image: mysql:5.6
command: --datadir=/var/lib/mysql/data
volumes:
- "db-data2:/var/lib/mysql"
- "db-log2:/var/log/mysql"
- "db-tmp1:/tmp"
ports:
- 6603:3306
networks:
db_br:
ipv4_address: <IP_ADDRESS>
environment:
MYSQL_ROOT_PASSWORD: very_complex_pw
MYSQL_DATABASE: test1234
volumes:
db-data1:
driver: local
db-log1:
driver: local
db-cnf1:
driver: local
db-tmp1:
driver: local
db-data2:
driver: local
db-log2:
driver: local
db-tmp2:
driver: local
networks:
db_br:
driver: bridge
driver_opts:
com.docker.network.enable_ipv6: "false"
ipam:
driver: default
config:
- subnet: <IP_ADDRESS>/24
gateway: <IP_ADDRESS>
:: .skeema file config::
[production]
flavor=mysql:5.6
host=<IP_ADDRESS>
port=6603
user=root
::client.sql::
CREATE TABLE client (
uid int(11) NOT NULL AUTO_INCREMENT,
client_id int(11) DEFAULT NULL,
field_name varchar(100) NOT NULL COMMENT '',
field_description varchar(300) DEFAULT NULL COMMENT '',
field_label varchar(200) DEFAULT NULL COMMENT '',
is_active tinyint(1) DEFAULT NULL,
create_date datetime NOT NULL,
remove_date datetime DEFAULT NULL,
updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (uid),
KEY idx_client_1 (client_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AVG_ROW_LENGTH=164 ROW_FORMAT=DYNAMIC;
Hope this help to improve it
Thanks

add client.sql to the folder
...
ENGINE=InnoDB DEFAULT CHARSET=utf8 AVG_ROW_LENGTH=164 ROW_FORMAT=DYNAMIC;

That helps, thanks! To fix this problem the best way, I would recommend that you configure your dockerized MySQL 5.6 to use innodb_file_format=Barracuda globally.  Or, alternatively, remove ROW_FORMAT=DYNAMIC from your client.sql file.
You're getting mysql error 1031 because of trying to create a new innodb table with ROW_FORMAT=DYNAMIC. In MySQL 5.6, this is not allowed unless innodb_file_format=Barracuda, which isn't the default in 5.6.
However, without innodb_strict_mode, MySQL 5.6 just gives a warning and allows the statement to proceed. But this is generally unsafe; an explicit error is usually preferred, which is what happens with strict mode enabled. So I think Skeema is doing the right thing here by using strict mode by default, and propagating the MySQL error in this situation. It would be better if MySQL gave a clearer error here, but that's really up to MySQL / Oracle.
As for why this works fine in MySQL 5.7+, seems it's due to a change in behavior for innodb_file_format. According to the 5.7 manual,

The innodb_file_format setting is ignored when creating tables that use the DYNAMIC row format. A table created using the DYNAMIC row format always uses the Barracuda file format, regardless of the innodb_file_format setting.

This wasn't the case in 5.6 (nor is it the case in MariaDB fwiw).


Play Audio in background, is it possible ?

Hello !
Thank you for this project !
Is it possible to stream on background, because when audio is streamed we got a big black screen !
Thanks in advance !

Hi currently the plugin is intended only to play videos, and thanks for the suggestion.


Support for Dark color theme needed.

I can't read tooltip text well with Dark color theme.

I'll look into it

I appreciate your help. :bow:

Could you please check version <IP_ADDRESS> and confirm that it indeed renders the text readable.

I need to setup Visual Studio 2015 SDK to build the installer, so please wait.

The installer for version <IP_ADDRESS> can be downloaded from versions

It looks like it's working fine with <IP_ADDRESS>. Thank you! @HJLebbink


Unable to run Hugo extended in Docker

I'm having problems running Hugo extended edition in Docker independent of base image.
Minimal Dockerfile for standard edition running just fine:
FROM busybox:1.28

ADD https://github.com/gohugoio/hugo/releases/download/v0.43/hugo_0.43_Linux-64bit.tar.gz /hugo.tar.gz
RUN tar -zxvf hugo.tar.gz
RUN ["/hugo", "version"]

Minimal Dockerfile for extended edition resulting in error:
FROM busybox:1.28

ADD https://github.com/gohugoio/hugo/releases/download/v0.43/hugo_extended_0.43_Linux-64bit.tar.gz /hugo.tar.gz
RUN tar -zxvf hugo.tar.gz
RUN ["/hugo", "version"]

The resulting error is:
standard_init_linux.go:185: exec user process caused "no such file or directory"
Based on docker/labs#215 may this be caused by a problem during compilation of Hugo.

Please use https://discourse.gohugo.io/ for questions/troubleshooting. Also see  Hugo Documentation.

Just to add some context: We're not staffed to troubleshoot in this repo. That's what the forum for.
The extended version can be run in a docker container.
If you do
./bepdock.sh
 CGO_ENABLED=1 go build -tags extended
./hugo -s docs

From this repo,  that should be proof that it's possible. The Docker container I'm using for testing above is the same that is used for the release build.
This extended release is still young, and these issues will smooth themselves out with a little time, I hope ...

Hi,
I'm very sorry about following up on this on Github if this is really just a problem at my end.
To me it looks like your commands provided above never actually runs Hugo inside a Docker environment.
Could you please add this command to your list?
docker run --rm -it -v $(pwd)/hugo:/hugo busybox /hugo version
In my environment runs the standard edition just fine and the extended edition fails with the above command when using the official Hugo binaries for Linux.
If this happens to work just fine in your environment with a newly compiled version may the extended edition binary for Linux be corrupt.

Hi, sorry for jumping in.
IMHO the issue appears to be that Alpine (and other light-weight images like Busybox) do not include /lib64/ld-linux-x86-64.so.2, on which the “extended” Hugo 0.43 depends. Unfortunately most (if not all) pre-built Hugo images on Docker Hub (like jojomi/Hugo or klakegg/hugo) are based on Alpine and do not work currently.
The same extended 0.43 binary runs just fine in containers with larger base images, such as Debian or Ubuntu (I just made the switch to a Debian base image on a server I run and I can confirm that it works).

Shortest sequence of commands to demonstrate the issue on Alpine:
docker run -it --rm alpine:latest
wget https://github.com/gohugoio/hugo/releases/download/v0.43/hugo_extended_0.43_Linux-64bit.tar.gz
tar -xf hugo_extended_0.43_Linux-64bit.tar.gz
./hugo

/bin/sh: ./hugo: not found

The “not found” error (weirdly) indicates a missing dependency.

As I said: Use the forum.

I've updated klakegg/hugo to now provide images based upon Debian and Ubuntu for extended edition of Hugo. I hope this fixes my problems for now.
I'm unable to find information in the Hugo documentation regarding the extended edition, and the release note for 0.43 ("a single binary with native and fast implementations") does not provide information about the new extended edition having different requirements related to running environment than the standard edition.

on alpine adding the packages libc6-compat g++  will fix this.
FROM alpine:latest as hugo-base
ENV VERSION 0.55.2
RUN apk add --no-cache git openssl py-pygments libc6-compat g++ curl
RUN curl -L https://github.com/gohugoio/hugo/releases/download/v${VERSION}/hugo_extended_${VERSION}_Linux-64bit.tar.gz | tar -xz  \
    && cp hugo /usr/bin/hugo \
    && apk del curl \
    && hugo version

But building sites will fail
Segmentation fault (core dumped)
Building sites … 2019/04/21 19:22:50 build_docs : exit code 139

You can workaround segmentation fault issue by applying muslstack on hugo extended executable and running it in alpine:edge image.
I've submitted a merge request for registry image updates in  https://gitlab.com/pages/hugo.  If you want to try it out, please use registry.gitlab.com/yaegashi/hugo/hugo_extended for now until it gets merged.


charlie qs input handling

coming from https://github.com/NREL/Wattile/issues/156

let's come back to this again later.


Remove dependency on downwardAPI volumes

I'm trying to use tekton on my AKS cluster and would like to run task pods on ACI virtual kubelets. Unfortunately, the ACI virtual kubelet provider doesn't currently support downwardAPI volumes which are used by tekton task pods. There is an issue in the ACI provider project (virtual-kubelet/azure-aci#91) requesting support, but I doubt there will be any progress on it any time soon, given that there's no support for a volume type in the underlying Azure service that might be adapted for this purpose (see the left-hand menu options here for supported volume types).
Removing (or providing an optional alternative to) the single use of a downwardAPI volume in tekton would allow it to be used with ACI virtual kubelets.
The following comment gives me hope that this is something that's already being planned:
https://github.com/tektoncd/pipeline/blob/9b4d3fc4262ccd45325f79946fe2c98a9727b9c4/pkg/pod/entrypoint.go#L80-L82
However, the referenced issue #1605 appears to be much broader, doesn't specifically talk about the removal of downwardAPI and looks on the verge of being declared 'done'.
As I understand it, this volume is used solely for signalling that all sidecars are running before allowing the first step to proceed. I might be happy to offer a contribution here, but I don't currently understand what exactly is meant by the comment:

Signal sidecar readiness by injecting entrypoint

Perhaps @imjasonh or someone else could provide some illumination?
An alternative quick and dirty fix for the cases where sidecars aren't used would be to simply remove the wait arguments to the first entrypoint (and the volume itself) based on similar logic to the shouldAddReadyAnnotationOnPodCreate function:
https://github.com/tektoncd/pipeline/blob/9b4d3fc4262ccd45325f79946fe2c98a9727b9c4/pkg/pod/entrypoint.go#L121-L124
https://github.com/tektoncd/pipeline/blob/3a305a09bdc4d65789e8b6c5a97232001d9ac751/pkg/pod/pod.go#L374-L378

Some background on why we use the Downward API today:
When there are sidecars, we need some way for the controller to send a signal to the first step's injected entrypoint binary that it's okay to start. Today, the controller does this by observing the Ready state of any sidecars, and updating an annotation which is projected via downward API where the first step can observe the file contents change and know to start.
Today, sidecar containers don't have the entrypoint binary injected, and just start, become ready, run, and are stopped, just like regular containers in a Pod. Because they're just regular containers in a Pod.
It works today, mostly, but it's a bit brittle, and it doesn't work in scenarios like yours where the downward API is not available. 😕
The general idea behind the "Signal sidecar readiness by injecting entrypoint" comment was that, instead of having sidecars be "normal" containers, to inject the entrypoint binary into them too, like we do to order steps. This gives us more control over their lifecycle, and more visibility. We've talked about using this to more gracefully stop the sidecars, but it could also give us a way to detect if the sidecar container is ready, and inject logic to write a file in a shared volume to start the first step. If there are multiple sidecars, each would write an "I'm ready" file, and the first step would be configured to wait for all of them.
This would remove the need for the downward API, with the small added complexity of injecting the entrypoint binary on sidecars (we do it for all steps today, and it mostly works, so that's not that bad), and having the first step wait for multiple signals (I believe the code supports it today, but it isn't used in practice today AFAIK), and of needing to have some way for the injected entrypoint binary to detect the sidecar container's readiness (this is the big one IMO). The entrypoint can tell if it's started, but that's not the same as being Ready, and we'd have to think a bit about how to detect that reliably, without adding any more dependencies on brittle things like downward API.
If anybody has any ideas I'm all for them, the downward API has always been kind of a hack, and our usage of it especially. I'd be happy to meet and walk through code or brainstorm ideas if you ping me on Slack.

Thanks for the very quick response!

instead of having sidecars be "normal" containers, to inject the entrypoint binary into them too, like we do to order steps

Won't this present a problem for injected sidecars (which you currently also check the 'readiness' of)?

I'd be happy to meet and walk through code or brainstorm ideas if you ping me on Slack.

Thank you for the kind offer! I may take you up on it, but it won't be for a while (I'm afraid I'm a bit busy right now). Now that you've explained it, I can see that this is a rather more involved problem than I'd hoped. :disappointed:
Would a temporary solution of having a feature flag disable-await-sidecar-readiness be palatable? After all, the normal pod contract is that containers must do their own checking if they need to wait for their sidecars to be in a particular state.

Won't this present a problem for injected sidecars (which you currently also check the 'readiness' of)?

Yes! Excellent point. Let's not forget injected sidecars (the bane of my existence).
This reminds me there's a feature flag to disable behavior to account for injected sidecars, running-in-environment-with-injected-sidecars: false, in case that's useful at all.

Would a temporary solution of having a feature flag disable-await-sidecar-readiness be palatable? After all, the normal pod contract is that containers must do their own checking if they need to wait for their sidecars to be in a particular state.

This sounds fine to me personally, you'd probably want to get feedback from others (@vdemeester @jerop @afrittoli @pritidesai) in case they can think of some reason not to do it.

This sounds fine to me personally, you'd probably want to get feedback from others (@vdemeester @jerop @afrittoli @pritidesai) in case they can think of some reason not to do it.

That does sounds fine to me as well.

I've raised #4953 to hopefully provide a temporary solution for this. Let me know what you think.

#4953 is now merged, but it's only a partial solution. It's good enough for me, for the moment, but the Downward API volume is still needed if one requires waiting on sidecars.
I'll leave it up to the Tekton team to decide whether to close this issue or leave it open.


fuzz: add more coverage for deserialize_block

This PR adds more coverage for the deserialize_block target. First, it serializes the block and compares with the data provided and then call some block functions to ensure they run without any issue.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
19479

Relevant Lines:
23397

💛  - Coveralls


Deps adjustment

Use indy-content-browse-model-java from indy-model library
Use indy-koji-model-java from indy-model library
Disable SwaggerExportTest as it is not used in 3.3.0

LGTM


[CDEC-307] stack2nix doesn't respect -WError flag

Updated Stack2Nix.External.Stack to add ghc-options registered in stack.yaml to the Derivation produced by the cabal2nix library call. The options are added to the configureFlags attribute of the derivation.

LGTM but I'll will wait for devops people to merge it.

@parsonsmatt I added -Werror on this package to make sure it went through correctly and it does

:tada:


Add test project for c# 13 (pre-release version)

@sharwell, I created this mostly to check if there were any regressions so far. None found. Some previous Roslyn problems were fixed and some tests which have syntax errors in them got slightly different behavior, but looks good so far. If you think it is too early to merge this now, I can update this now and then until the time is right.
I added LanguageVersionEx.CSharp13 the way I expect it will be defined eventually even though it was not in place yet.
What do you think?

Also need to incorporate this to https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/build/build-and-test.yml

Added that one and test.yml to the solution so they are easier to remember :-)


Nats Jetstream

Does this work with nats Jetstream ?
the code uses the object name “Stan” so I presume it’s designed for the Nats Streaming platform and not Nats Jetstream ?

It's designed for the Nats Streaming platform :)

Ok shame
would have thought jwt stream is better in 100% of cases because it’s clustered whereas nats streaming is no clustered.
that’s part of the reason they made nats Jetstream

Thanks for sharing @gedw99.
We will look into it.

you can also just compile the golang nats client into Flutter too
https://github.com/capitalpidx/flap compiles a DB and Server inside FLutter and so its easy to add NATS this way.
Its probably not your cup of tea, but another way to approach it.


Cannot autheticate on API. Get the tokens (JWT and csrf) but all responses are "401"

I cannot use the API succefully for any request (except to get the secutiry tokens), always getting " Response 401" for any request.
How to reproduce the bug
On the docker container where the superset is running:
>>>
import requests

session = requests.session()

jwt_token = session.post(
    url='http://localhost:8088/api/v1/security/login',
    json={
    "username": "admin",
    "password": "admin",
    "refresh": False,
    "provider": "db"
    }
).json()["access_token"]

csrf_token = session.get(
    url='http://localhost:8088/api/v1/security/csrf_token/',
    headers={
        'Authorization': f'Bearer {jwt_token}',
    }
).json()["result"]

headers = {
    'accept': 'application/json',
    'Authorization': f'Bearer {jwt_token}',
    'X-CSRFToken': csrf_token,
}

#trying to use the "current user" request as a test
response = requests.get('http://localhost:8088/api/v1/me', headers=headers)

session.close()`

response
Expected results
{
"result": {
"email"<EMAIL_ADDRESS>"first_name": "Superset",
"id": 1,
"is_active": true,
"is_anonymous": false,
"last_name": "Admin",
"username": "admin"
}
}
Actual results
>>> response
<Response [401]>

Screenshots
Environment
(please complete the following information):

superset version: v1.0.0
python version: Python 3.8.12

Checklist

[ x] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[x ] I have reproduced the issue with at least the latest released version of superset.
[ x] I have checked the issue tracker for the same issue and I haven't found one similar.

did you try with 1.4.2?

Instead of
#trying to use the "current user" request as a test response = requests.get('http://localhost:8088/api/v1/me', headers=headers)
you should try:
session.headers.update(headers)

response = session.get('http://localhost:8088/api/v1/me')`

First of all, thank you @MM-Lehmann and @MarcinZegar .
I've tried with 1.4.0 and most of my API problems were solved but one: I still cannot upload a CSV using it. I've tried a lot of different things, learned a lot about requests using python, curl and so on but it seens that it simply doesn't work.
Not a big problem since I've decided to update my database by MySQL directly (witch I had to learn also).
I will keep an eye on the next versions just to test if, someday, it will be possible

Closing this since most issues were resolved. It's also been a while since this thread was active! Hopefully things are working better in 1.5.x or 2.0.x but if there are still bugs being found, let us know and we can re-open this, no problem!

Instead of
#trying to use the "current user" request as a test
response = requests.get('http://localhost:8088/api/v1/me', headers=headers)

you should try:
session.headers.update(headers)

response = session.get('http://localhost:8088/api/v1/me')

This didn't work now.
The code is accessing g.user from flask_login. The flask_login doesn't load the user when the request is sent from the api.
I think there should be a better solution for the new version of code.

I think i'm experiencing the same issue with superset 2.0.1.
this is the script that I run to get jwt token, csrf token, and finally get my user's info:
const base_url = "https://<server_addr>/api/v1/";

async function get_csrf_token(access_token) {
  const res = await fetch(base_url + "security/csrf_token", {
    headers: {
      "Content-Type": "application/json",
      Authorization: "Bearer " + access_token,
    },
    method: "GET",
  });

  const complete_res = await res.json();
  return complete_res.result;
}

async function login() {
  const res = await fetch(base_url + "security/login", {
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      username: "user",
      password: "pass",
      provider: "db",
      refresh: true,
    }),
    method: "POST",
  });

  const complete_res = await res.json();
  return complete_res.access_token;
}

async function get_me(access_token, csrf_token) {
  const res = await fetch(base_url + "me", {
    credentials: "same-origin",
    headers: {
      "Content-Type": "application/json",
      Authorization: "Bearer " + access_token,
      "X-CSRFToken": csrf_token,
    },
    method: "GET",
  });

  return await res.json();
}

(async () => {
  const access_token = await login();
  console.log("res is ", access_token);

  const csrf_token = await get_csrf_token(access_token);
  console.log("res is ", csrf_token);

  const me_res = await get_me(access_token, csrf_token);
  console.log("me is ", me_res);
})();

when I run the script the result is:
$ node ./superset_api_test.js
res is  <jwt token>
res is  <csrf token>
me is  { message: 'Not authorized' }

and I think @raghulprashath is right. lines 35-63 of get_me method of superset.views.users.api.CurrentUserRestApi are like:
    @expose("/", methods=["GET"])
    @safe
    def get_me(self) -> Response:
        """Get the user object corresponding to the agent making the request
        ---
        get:
          description: >-
            Returns the user object corresponding to the agent making the request,
            or returns a 401 error if the user is unauthenticated.
          responses:
            200:
              description: The current user
              content:
                application/json:
                  schema:
                    type: object
                    properties:
                      result:
                        $ref: '#/components/schemas/UserResponseSchema'
            401:
              $ref: '#/components/responses/401'
        """
        try:
            if g.user is None or g.user.is_anonymous:
                return self.response_401()
        except NoAuthorizationError:
            return self.response_401()

        return self.response(200, result=user_response_schema.dump(g.user))

i can confirm that the same workflow works totally fine for version 1.2.0, albeit on a view other than /me
versions:
superset: 2.0.1
python: 3.8.16

Still facing this issue.
versions
superset: v2021.41.0-4182-gdf91664
Python 3.8.13

have tried

node ./superset_api_test.js as @sazary brought up. Result is { message: 'Not authorized' }
hit  /api/v1/me with token obtained from admin, no luck.

The superset service is launched in docker, with superset_config_docker.py as
SESSION_COOKIE_SAMESITE = None
ENABLE_PROXY_FIX = True
PUBLIC_ROLE_LIKE_GAMMA = True
FEATURE_FLAGS = {
  "EMBEDDED SUPERSET" : True
}
CORS_OPTIONS = {
  'supports_credentials': True,
  'allow_headers': ['*'],
  'resources' : ['*'],
  'origins': ['http://localhost:8088', 'http://localhost:8888']
}
CSRF_ENABLED = False
WTF_CSRF_ENABLED = False

Wonder if anyone could point me to possible solutions for this?

Actually I was able to solve this problem.
import requests
# from bs4 import BeautifulSoup

username = "admin"
password = "admin"
session = requests.session()

login_form = session.post('http://localhost:8088/login')
# soup = BeautifulSoup(login_form.text, 'html.parser')
# csrf_token = soup.find('input',{'id':'csrf_token'})['value']
data = {
  'username': username,
  'password': password,
  # 'csrf_token': csrf_token
}
response = session.post('http://localhost:8088/login', data=data)
response = session.get('http://localhost:8088/api/v1/me')

This is a work around to make this api work.
Comment out the lines in above code, if you want CSRF token i.e iff you enabled the flag in config

I can confirm that this issue still exists with the latest release. Expected behavior, what goes wrong and steps to reproduce are the same as my first report.
versions:
apache-superset==2.1.0
Python 3.8.16

@rusackas Could you please re open this issue?

I think the Referer header is missing could be the culprit?
Wrote a guide on it, hopefully, it helps someone 😄 Choose your preferred media 😝
https://huamichaelchen.substack.com/p/end-to-end-example-of-setting-up
https://medium.com/@huamichaelchen/end-to-end-example-of-setting-up-superset-embedded-dashboard-f72fc985559

Hi Guys,
We are facing similar issue while authenticating superset API request (Superset version - 2.0.1).   I have tried all the solution listed here but unfortunately nothing worked for me. Do we have any update on the issue?
Thanks!

This issue seems to be present in version 3.0.0 as well. Running with Docker Compose. Requests to /api/v1/me/roles is always returning 401. This seems to break the embed dashboard feature. It would be great if anyone on the Superset side could look into this.

same issue on 3.0.2

Temporary Solution
On the superset UI I edited the role of public and removed can read on Chart from its permissions.

We've just had this issue when upgrading 3.0.1 to 3.1.0rc3 and this solved it. Thanks @partizaans

3.0.2 Roles was 401, but after turning Talisman on -  all seems work. Except other then security API endpoints :(

Closing this as it seems the issue was resolved in recent versions of Superset. Please reopen if that's not the case.

Hi, I am using the lastest version of Superset, but still facing this issue, can we re-open it?
All settings are leave as default except FAB_ADD_SECURITY_API = True

Closing this as it seems the issue was resolved in recent versions of Superset. Please reopen if that's not the case.

Faced the same problem after following the upgrade instruction to the latest stable version (4.0.2) and happened again.
@michael-s-molina

Closing this as it seems the issue was resolved in recent versions of Superset. Please reopen if that's not the case.

Faced the same problem after following the upgrade instruction to the latest stable version (4.0.2) and happened again. @michael-s-molina

Same thing here, did you manage to solve it?

Closing this as it seems the issue was resolved in recent versions of Superset. Please reopen if that's not the case.

Faced the same problem after following the upgrade instruction to the latest stable version (4.0.2) and happened again. @michael-s-molina

Same thing here, did you manage to solve it?

Unfortunately no. Had to do some manual actions described as the Temporary Solution here: https://github.com/apache/superset/issues/19525#issuecomment-1566791040

Same here. Getting a 404 when calling /api/v1/dashboard/14
1. Possible Explanation:

When the API is called with a session cookie, the user is identified through Flask-Login using current_user, and the @with_dashboard decorator can retrieve the dashboard based on this user.
With a JWT, the decorator might not know how to access the same user context. If @with_dashboard relies on current_user, and current_user is not properly defined when using the JWT, the lookup may fail, resulting in a 404.

2. User Context (current_user)

In the case of session cookies, Flask-Login properly sets up current_user to identify the user. However, when using a JWT, verify_jwt_in_request() verifies the token but does not automatically update current_user used by Flask to reference the authenticated user.
If the subsequent code (such as the @with_dashboard decorator) uses current_user to access the dashboard, and current_user is not properly set with the JWT, the system may fail to find the dashboard, returning a 404.

3. Differences in Initialization of Global Variables (g or current_user)

Flask often uses global variables such as g.user or current_user to store the current user. When the call is made via JWT, these variables may not be correctly initialized, resulting in an inability to locate the resources.
Potential Solution: Make sure that current_user is correctly set after JWT authentication. You can do this by extending the JWT validation process to explicitly set current_user.

Why is def get_me(self) -> Response: not decorated with @protect() ?
I'll confess to not knowing the code that well, but is there another way if g.user is None or g.user.is_anonymous: can return false without @protect() ?