formset html should wrap form fields for adding/removing formsets

In trying to support an add/remove feature for formsets, I discovered that the html from:
{% bootstrap_formset form %}

is:
<input id="id_form-TOTAL_FORMS" name="form-TOTAL_FORMS" type="hidden" value="1" />
<input id="id_form-INITIAL_FORMS" name="form-INITIAL_FORMS" type="hidden" value="0" />
<input id="id_form-MAX_NUM_FORMS" name="form-MAX_NUM_FORMS" type="hidden" value="1000" />

Title<input class="form-control" id="id_form-0-title" maxlength="120" name="form-0-title" placeholder="Title" title="" type="text" />

Body
<textarea class="form-control" cols="40" id="id_form-0-body" name="form-0-body" placeholder="Body" rows="10" title=""></textarea>

In order to create some JS to add additional forms, there has to be a selector to duplicate just the form fields (without the management form).  Perhaps not including the management form in {% bootstrap_formset %} would be the simplest fix -- since that doesn't actually require any bootstrap styling.

Should be fixed with renderers a while back. Sorry for the late reply.


Dan's golint branch - trimmed

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR-trafficops-test/548/

🥇

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/incubator-trafficcontrol-PR/592/
Test PASSed.


Long press support

Instead of press.
Is it possible?

Ok, I was thinking about the Context Menu functionality in iOS where the user long press an item and a menu pops up: https://developer.apple.com/design/human-interface-guidelines/ios/controls/context-menus/
There is already another library that does implements it that also use UIMenu: https://github.com/mpiannucci/react-native-context-menu-view. I do wonder though if this library can or will support it regardless.

Hello! Is there any hope that the proposed PR will be merged?


Not working - fails silently

I have no idea whats wrong. I have installed Composer and installed allocine/twigcs globaly with composer. Also installed your VSCode plugin.
Its simply not working here. Errors in Twig are not highlighted nor mentioned in the "Problems"-Tab.
Have you any idea what could be wrong here?
Restarted VSCode, restarted Windows, reinstalled the plugin ..
Its Windows 10, VSCode 1.24.1
Installed Composer Packages:
allocine/twigcs           v3.0.1             Checkstyle automation for Twig
asm89/twig-lint           dev-master 9ce57f6 Standalone twig linter.
pimple/pimple             v3.2.3             Pimple, a simple Dependency Injection Container
psr/container             1.0.0              Common Container Interface (PHP FIG PSR-11)
psr/log                   1.0.2              Common interface for logging libraries
symfony/console           v3.3.10            Symfony Console Component
symfony/debug             v3.3.10            Symfony Debug Component
symfony/finder            v3.3.10            Symfony Finder Component
symfony/polyfill-mbstring v1.6.0             Symfony polyfill for the Mbstring extension
twig/twig                 v1.35.0            Twig, the flexible, fast, and secure template language for PHP

If i try to run it in the console ("twigcs lint FOLDER") i get:
PHP Fatal error:  Declaration of Allocine\Twigcs\Compatibility\TwigLexer::tokenize(Twig_Source $source) must be compatible with Twig_LexerInterface::tokenize($code, $name = NULL) in C:\Users\XXX\AppData\Roaming\Composer\vendor\allocine\twigcs\src\Compatibility\TwigLexer.php on line 28

Same issue here. Tried to set the executable path multiple different ways and no errors at all, but the linter won't start in any case.

Hi,
Is it possible tu update composer/twigcs and retry ?
I think the problem is fixed with https://github.com/allocine/twigcs/issues/43

Hi, I'm having the same problem described above.  I have a system-wide install of twigcs version ^3.1 .  I can run twigcs from the command prompt to lint a file successfully.  However, I cannot get any linting visible in vs code for twig files, and nothing in the "problems" output.  Nothing happens differently than before the plugin was installed.
MacOS Mojave 10.14.5
Composer version 1.9.0
Using PHP version 7.3.7.
I've also tried doing a project wide installation of twigcs in addition to the system wide installation, but with same result.  I've also tried specifying twigcs.executablePath in settings.json.
If I change the output in the debug console to show "Log(Extension Host)", I see the following line:
[2019-08-20 15:28:24.484] [exthost] [info] ExtensionService#_doActivateExtension cerzat43.twigcs {"startup":false,"activationEvent":"onLanguage:twig"}
That seems to be saying the extension is recognized and will activate when a *.twig file is loaded.  If there's any other information I can provide, please let me know.  In my list of language options, there's one called "HTML (Twig) (twig)" and this has the Twig icon next to it.  The second parentheses with "(twig)" is in gray and seems to indicate the file extension.  I'm wondering if your "Twigcs Linter" extension is being loaded but somehow never recognizing that a twig file has been displayed?
If you have any ideas, please let me know.  Thanks!

@spchaplin I was able to get mine working recently in Twigcs Linter 1.1.0 by installing twigcs globally :
composer global require friendsoftwig/twigcs
Then in VSCode preferences, find twigcs.executablePath and set it to the twigcs binary from your global installation:
../path/to/your/global/Composer/vendor/bin/twigcs
Hope that helps!

Adam, thanks so much for the idea! I've added the following line to my settings.json:
"twigcs.executablePath": "/Users/myusername/.composer/vendor/bin/twigcs"
I can use that path to run the twigcs executable from command line successfully, e.g.,
$  /Users/myusername/.composer/vendor/bin/twigcs filetolint.twig
result:
// l.19 c.41 : WARNING Unused macro import "buttons".
// l.20 c.39 : WARNING Unused macro import "forms".
// l.21 c.42 : WARNING Unused macro import "identity".
// l.22 c.37 : WARNING Unused macro import "svg".
// l.54 c.20 : ERROR A line should not end with blank space(s).
But it's still having no effect on vs code.  Anyone's ideas are welcomed, and thanks in advance!

@spchaplin that's strange! I'm not on Mac, so I haven't tried this - but try escaping the '/' and using a backslash in the path instead in your settings.json:
`"twigcs.executablePath": "\Users\myusername\.composer\vendor\bin\twigcs"

Adam, many thanks for this suggestion, it's a good one.
I tried escaping as you suggested "//", and also tried escaping the forward slash in a separate attempt "/" , but with same result.  Other attempts included running vs code as administrator (sudo), and installing twigcs in a separate location (my home directory), then listing that path as the twig.executablePath in settings.json.  Also tried uninstalling the Twig 2 vs code extension in case that might be causing a conflict, and it's related entries in settings.json:
"files.associations": {
"*.html": "twig",
},
"emmet.includeLanguages": {
"twig": "html"
}
Still the same result.  If you or anyone else have further ideas, I'm open to them, and thanks for the ideas thus far.


Generate unified diff for ADD

Add for the minimal configuration of ADD, this configuration should be enough to compute all the metrics and patterns detection.

Hi @tdurieux , thanks!
I didn't know that ADD needs the diff file. I thought it was enough with the Diff object computed by GT-Spoon.
For curiosity, For what is used the diff file?

The diff file is used to compute some metrics and also the single line pattern.
It is used for additional information, it could be possible to remove it from add but why not to keep it :)

Perfect, thanks for the clarification.
I would keep it on ADD, however, it could be nice to have the option to avoid compute them.
Example (a simple idea): if you pass a null to config.setDiffPath(tempFile.getAbsolutePath()); ADD does not compute nothing related to the diff.
That could allow us to improve the performance when we analyze thosands of commits and revisions.
WDYT?

this could be considered in the future

perfect!

Hi @tdurieux
Just a question for curiosity: Was the ADD.1.1-snapshot version used by Coming generated from the ADD's master branch or from the backport branch from Martin's fork?
Thanks

the master branch

Cool, thanks.
I will open an issue about what we have discuss yesterday and eventually a PR.


SARSAAgent does not use test_policy

class SARSAAgent(Agent):
    """Write me
    """
    def __init__(self, model, nb_actions, policy=None, test_policy=None, gamma=.99, nb_steps_warmup=10,
                 train_interval=1, delta_clip=np.inf, *args, **kwargs):
        super(SarsaAgent, self).__init__(*args, **kwargs)

        # Do not use defaults in constructor because that would mean that each instance shares the same
        # policy.
        if policy is None:
            policy = EpsGreedyQPolicy()
        if test_policy is None:
            test_policy = GreedyQPolicy()

        self.model = model
        self.nb_actions = nb_actions
        self.policy = policy
        self.test_policy = policy
        self.gamma = gamma
        self.nb_steps_warmup = nb_steps_warmup
        self.train_interval = train_interval

        self.delta_clip = delta_clip
        self.compiled = False
        self.actions = None
        self.observations = None
        self.rewards = None

It looks like a typo to me. I am guessing you meant self.test_policy = test_policy.

please refer to the pull request whose title is Fix default policy handling of DQNAgent #70

I am not sure what you are saying. Do you mean that the commit for #70 addresses the issue I am raising? Or do you mean this is an additional problem that #70 should deal with before that PR is accepted and merged?
As I see it, the commit for #70 does not fix the oversight/typo I am pointing to, if that's what you meant.

Yep, you are right, this was a typo. Has been fixed in https://github.com/matthiasplappert/keras-rl/commit/8b1940c5613e124a55d11ba257a8800bc12d65a5


Improvements to ImageExtractor wrt integration_correction and sampling rate

The integration_correction is a powerful tool. It removes the dependance of the resulting extracted charge on the size of the integration window used. This means that any other calibration is integration window independent!
However, there are two problems in the way we currently use it:

As it is currently attached to the CameraCalibrator, it is the same method applied for any ImageExtractor. For the currently defined extractors this has been somewhat alright, as they are all integration-window based. But for more advanced extractors (e.g. digital filter), this will not be the correct correction to apply
We allow it to be skipped if there is no reference_pulse_shape defined. This means that real camera data might not benefit from this function if the developer has not specified a reference pulse shape, and then their calibration is integration window dependant (which may be accidentally overlooked)

I have addressed both of these points in this PR, by:

Adding a _calculate_correction method to the ImageExtractors, so one can define the appropriate way to calculate the correction for each particular extractor. For a noise-less unit pulse the resulting charge from an ImageExtractor should always equal 1, ensuring the correct units for the resulting charge - this is the goal of the correction factor.
Removing the ability to skip over the correction if there is no reference pulse defined.
Moving integration_correction method to extractor.py, as this is a more appropriate place for it now.

Also included in this PR is the correct application of the sampling rate to the extracted charge and pulse time. So they are now in units of "waveform unit * nanosecond" and "nanosecond" respectively.
These changes have allowed me to update the tests for ImageExtractor so that they no longer expect an otherwise meaningless value for the charge, but instead the charge should equal the total charge (i.e. the true charge) specified in generating the waveform.
There is no change to the API of the calibration in this PR.

This PR will also solve #1044

It would be useful to also add a config option to disable this correction - @HealthyPear  had to hack that in ProtoPipe in order to cross-check with MARS (which does no integration correction). So just a boolean enable_integration_correction would be great, perhaps in the base Extractor class, such that _compute_correction() is not called if is is disabled.

Yeah I had considered this. Honestly I'd prefer to avoid adding this option...the integration correction should be an integral part of the charge extraction, and having that option could lead to misuse...
With regards to the cross-checks - the integration correction should only introduce a scale factor difference. Unless I am mistaken, the comparisons done by @HealthyPear remove account for  possible bias due to different calibrations, and so should be unaffected by the integration_correction. Is that correct @HealthyPear?

Besides, with the integration correction, the extracted charge from simtelarray should match 1-to-1 with the true charge, with no additional calibration needed. So it is technically the correct way to process the MC (especially for calculating the charge resolution).
This is a plot of the extracted charge distribution for different window widths and shifts, versus the true charge for no integration correction applied:

This is the same plot with integration correction applied:

Hi @watsonjj !
Yes I agree with you.
It is true that I had to do this hack into protopipe as @kosack mentioned, but:

it is no the "worst" hack; there are bigger things that I had to overwrite and they will disappear almost completely with the next release of ctapipe,
the fact that I had to disable the integration correction is only temporary, since I did it just to minimize any possible source of mistake in the comparison; as you correctly state, applying it will just change the (average) bias in the charge resolution, for which we correct when assessing the calibration benchmarks (i.e. the calibration notebook in protopipe).

I agree that this correction should be always there.
If we want to implement this option anyway, a possible solution would be to set it true by default and let the the documentation will do the rest...

A couple of (late) comments on this:

Adding a _calculate_correction method to the ImageExtractors, so one can define the appropriate way to calculate the correction for each particular extractor. For a noise-less unit pulse the resulting charge from an ImageExtractor should always equal 1, ensuring the correct units for the resulting charge - this is the goal of the correction factor.

It does not seem to me that the goal is the right one. Real or simulated pulses are composed of photons with a time structure. Take a single p.e. pulse shape (like LST's low-gain one) which has some "ringing" with undershoots after the main peak. For the single p.e. shape, if you integrate a number of samples which don't include any undershoot, the correction factor would be <1. But for a real pulse (be it a calibration pulse, or a pulse from a shower), with a time structure, the main peaks of the photon pulses will fill the undershoots of earlier photons, so the mean or typical pulse will have a pretty different shape, and the correction will be wrong.

Removing the ability to skip over the correction if there is no reference pulse defined.

I actually think it would be nice, at least for testing purposes, if the pulse correction could be skipped altogether in some easy way, through a line in the configuration file.


What constant catch levels to use for projections?

Option f in Table g should use 2020 TAC of 475,255 (from Table e), currently uses the 2019 TAC of 597,500.

Changing involves updating the line in forecast-catch-levels.R, but then we have to re-order (and edit captions etc.) because this catch option of 475,255 is now less than the option e of 500,000. But then 500,000 is close to 475,255, so should probably change the 500,000. To 600,000?
Also option d (previous year's catch) will change to 379,270 (let's use 380,000).
Summary (x1000 t):
2020 values                   2021 suggestions
0                                    0
180                                180
350                                350   (I think there's historical reason for sticking with 180 and 350)
410 (2019 catch)                   380 (2020 catch)
500                                475,255 (2020 TAC)
597,500 (2019 TAC)                 600?? (new constant value not so close to 475,255).

For reference, the remaining values are currently:

[Not sure why 2021 g and h catches are identical, when I don't think they should be identical by definition - well, they weren't last year - I can look into it].
So the only question is really whether to stick with 500,000 as a constant (but a bit close to 475,255), or bump it to 600 (or something else)? I can make the changes in the code, we just need to decide what the values should be.
The TAC in 2016 was 497,500, and for 2017 assessment we used that and then 600,000. So 600,000 has precedent.

What about the following for 2021:
0
180 (reason: historical use)
350 (reason: historical use)
380 (2020 catch)
430 (constant, just because it fills the gap here)
475,255 (2020 TAC)
597,500 (2019 TAC)
So essentially the same as you suggest Andy, but just keeping the 2019 TAC in there rather than moving to 600.  That way there is some meaning to the number, such as "what if we went back to the 2019 TAC" - though I suspect nobody will wonder that so it will act as a higher number in our range.  And then filling that near 100k gap, which is potentially a zone of consideration (i.e., below the 2020 TAC) given the stock trajectory continual decline from last year.

What about the following for 2021:
0
180 (reason: historical use)
350 (reason: historical use)
380 (2020 catch)
430 (constant, just because it fills the gap here)
475,255 (2020 TAC)
597,500 (2019 TAC)
So essentially the same as you suggest Andy, but just keeping the 2019 TAC in there rather than moving to 600.  That way there is some meaning to the number, such as "what if we went back to the 2019 TAC" - though I suspect nobody will wonder that so it will act as a higher number in our range.  And then filling that near 100k gap, which is potentially a zone of consideration (i.e., below the 2020 TAC) given the stock trajectory continual decline from last year.

That makes sense. I offer to be the one to change these and commit.
We will all have to run the forecasts and catch-levels again using build_rds() once I fix Issue #730

That makes sense. I offer to be the one to change these and commit.
We will all have to run the forecasts and catch-levels again using build_rds() once I fix Issue #730

Hopefully adding that one row doesn't make fixing the table hellish

Hopefully adding that one row doesn't make fixing the table hellish

If it does, let's re-evaluate...

If it does, let's re-evaluate...

Good idea @aaronmberger-nwfsc , though I have a feeling that in the past we had issues with adding an extra row in table (and figures), so went with replacing where we could. There's still the three non-constant catch values at the end.
But your idea does fill that 100,000 t gap. Could actually remove 350,000 as it's so close to 380,000 anyway so doesn't really add anything (and would clutter up the figures). Think that may be simpler, and keep the number of policies constant.

Good idea @aaronmberger-nwfsc , though I have a feeling that in the past we had issues with adding an extra row in table (and figures), so went with replacing where we could. There's still the three non-constant catch values at the end.
But your idea does fill that 100,000 t gap. Could actually remove 350,000 as it's so close to 380,000 anyway so doesn't really add anything (and would clutter up the figures). Think that may be simpler, and keep the number of policies constant.

All those suggested are in there now, it turns out that last year I made it really easy to add and remove rows. 350,000 is currently there.

All those suggested are in there now, it turns out that last year I made it really easy to add and remove rows. 350,000 is currently there.

Yes, and the captions seem to automatically upate. I'll re-run today. Keep this Issue open as I'll also update the associated text, which isn't automated and actually needs some thinking.
Also, Aaron and Kelli should give a thumbs up here once they've rerun stuff (today onwards, since #730 also).

Yes, and the captions seem to automatically upate. I'll re-run today. Keep this Issue open as I'll also update the associated text, which isn't automated and actually needs some thinking.
Also, Aaron and Kelli should give a thumbs up here once they've rerun stuff (today onwards, since #730 also).

I was happy to see the caption update correctly even with the addition of a new row :)

I was happy to see the caption update correctly even with the addition of a new row :)

Great that the tables expand so well. Just looking at them, someone will probably ask why we don't have the non-constant catch values in increasing order:

But I think on balance it makes sense to keep them in the same order each year (and it's easier for us). So the first 7 are all constant catch, then the final three are the weird ones. Just wanted to mention it here.

Great that the tables expand so well. Just looking at them, someone will probably ask why we don't have the non-constant catch values in increasing order:

But I think on balance it makes sense to keep them in the same order each year (and it's easier for us). So the first 7 are all constant catch, then the final three are the weird ones. Just wanted to mention it here.

This all looks good. 350,000 is in there for historical reasons even though it's close to 380,000. I don't think there's anything more to think about here so I'll close it.
@andrew-edwards We should probably keep the order as it has been in other years, even though the catch is out of order: i.e: constant catch in the first 7 rows followed by the calculated rates.

This all looks good. 350,000 is in there for historical reasons even though it's close to 380,000. I don't think there's anything more to think about here so I'll close it.
@andrew-edwards We should probably keep the order as it has been in other years, even though the catch is out of order: i.e: constant catch in the first 7 rows followed by the calculated rates.


Error Setting Up Development Environment: pip install -e . in root throws ValueError

Greetings of the day 👋🏻
TL;DR: I encountered an error while trying to set up the development environment for the project. I was following the contribution guide and ran pip install -e .. The error message indicates that the build system is unable to determine which files to include in the wheel package due to missing or incorrectly specified file selection options in the pyproject.toml:
Error logs
× Preparing editable metadata (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [52 lines of output]
    Traceback (most recent call last):
      File "/home/arjxnpy/miniconda3/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 167, in prepare_metadata_for_build_editable
        hook = backend.prepare_metadata_for_build_editable
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AttributeError: module 'hatchling.build' has no attribute 'prepare_metadata_for_build_editable'

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/home/arjxnpy/miniconda3/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 353, in <module>
        main()
      File "/home/arjxnpy/miniconda3/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 335, in main
        json_out['return_val'] = hook(**hook_input['kwargs'])
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/arjxnpy/miniconda3/lib/python3.12/site-packages/pip/_vendor/pyproject_hooks/_in_process/_in_process.py", line 176, in prepare_metadata_for_build_editable
        whl_basename = build_hook(metadata_directory, config_settings)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/tmp/pip-build-env-93bum18r/overlay/lib/python3.12/site-packages/hatchling/build.py", line 83, in build_editable
        return os.path.basename(next(builder.build(directory=wheel_directory, versions=['editable'])))
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/tmp/pip-build-env-93bum18r/overlay/lib/python3.12/site-packages/hatchling/builders/plugin/interface.py", line 155, in build
        artifact = version_api[version](directory, **build_data)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/tmp/pip-build-env-93bum18r/overlay/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 494, in build_editable
        return self.build_editable_detection(directory, **build_data)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/tmp/pip-build-env-93bum18r/overlay/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 505, in build_editable_detection
        for included_file in self.recurse_selected_project_files():
      File "/tmp/pip-build-env-93bum18r/overlay/lib/python3.12/site-packages/hatchling/builders/plugin/interface.py", line 180, in recurse_selected_project_files
        if self.config.only_include:
           ^^^^^^^^^^^^^^^^^^^^^^^^
      File "/tmp/pip-build-env-93bum18r/overlay/lib/python3.12/site-packages/hatchling/builders/config.py", line 806, in only_include
        only_include = only_include_config.get('only-include', self.default_only_include()) or self.packages
                                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/tmp/pip-build-env-93bum18r/overlay/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 260, in default_only_include
        return self.default_file_selection_options.only_include
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/arjxnpy/miniconda3/lib/python3.12/functools.py", line 995, in __get__
        val = self.func(instance)
              ^^^^^^^^^^^^^^^^^^^
      File "/tmp/pip-build-env-93bum18r/overlay/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 248, in default_file_selection_options
        raise ValueError(message)
    ValueError: Unable to determine which files to ship inside the wheel using the following heuristics: https://hatch.pypa.io/latest/plugins/builder/wheel/#default-file-selection

    The most likely cause of this is that there is no directory that matches the name of your project (jupytercad_root).

    At least one file selection option must be defined in the `tool.hatch.build.targets.wheel` table, see: https://hatch.pypa.io/latest/config/build/

    As an example, if you intend to ship a directory named `foo` that resides within a `src` directory located at the root of your project, you can define the following:

    [tool.hatch.build.targets.wheel]
    packages = ["src/foo"]
    [end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> See above for output.

note: This is an issue with the package mentioned above, not pip.
hint: See above for details.

System Configuration:

Operating System: Tested on both Windows 11 and WSL (Ubuntu 22.04)
Python Version: 3.11

Initially I tried to to some workaround as I wasn't aware about the existence of dev-install.py, I tried defining tool.hatch.build.targets.wheel in the pyproject-
[tool.hatch.build.targets.wheel]
packages = [
    "python/jupytercad",
    "python/jupytercad_app",
    "python/jupytercad_core",
    "python/jupytercad_lab"
]
include = [
    "python/jupytercad/**/*.py",
    "python/jupytercad_app/**/*.py",
    "python/jupytercad_core/**/*.py",
    "python/jupytercad_lab/**/*.py"
]

But project was not being installed it was very quickly finishing up with the following logs:
Obtaining file:///C:/Users/Arjun/Desktop/Arjun/JupyterCAD
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... done
  Installing backend dependencies ... done
  Preparing editable metadata (pyproject.toml) ... done
Building wheels for collected packages: jupytercad_root
  Building editable for jupytercad_root (pyproject.toml) ... done
  Created wheel for jupytercad_root: filename=jupytercad_root-2.0.1-py2.py3-none-any.whl size=3633 sha256=5d0154eb3bdb87b13bde89383145d3aff422b80ab7ca342bc8bff58195858baa
  Stored in directory: C:\Users\Arjun\AppData\Local\Temp\pip-ephem-wheel-cache-p_ncnlug\wheels\09\d9\53\5aff060f2802ec5ca276c86b3bf0f84b1d59d9f65bb57cbaee
Successfully built jupytercad_root
Installing collected packages: jupytercad_root
  Attempting uninstall: jupytercad_root
    Found existing installation: jupytercad-root 2.0.1
    Uninstalling jupytercad-root-2.0.1:
      Successfully uninstalled jupytercad-root-2.0.1
Successfully installed jupytercad_root-2.0.1

Later I tried using dev-install.py & I noticed that it needed jupyterlab to be installed already for jlpm & if not installed it was throwing error - No such file or directory: 'jlpm'.
I didn't actually need to execute any further command from Contributing.md as jupyter cad worked for me nicely and I was able to locally setup the project successfully.
Hence it might be the case that the contribution guide is a little bit outdated if we've moved our dependency from the root pyproject.toml to install-dev.py for development environment setup.
Apologies in advance in case this was not the valid approach to have a follow up on this. I'd be so happy to have a response. Thanks a lot 💐

Thank you for testing out JupyterCAD, indeed the contribution guide is outdated. A PR to update this guide is very welcome

I was writing this on #379, but as it is already merged so I'm posting this here 😄
However there are some pain-points that I'd like to highlight which I experienced while trying to make minimal changes to the UI render them in browser with jlpm run watch.

I'm yet not been able to exactly figure out which is the most suitable directory to stably run jlpm run watch i.e. there is root, python/jupytercad_core, python/jupytercad_app, python/jupytercad_lab (haven't tried running in this one yet) & then there is packages/* (I've tried running watch in packages/base as I've made changes in packages/base/src/panelview/objectproperties.tsx)

The most responsive one I felt was python/jupytercad_core when i watched some changes in python/jupytercad_core/src/jcadplugin/plugins.ts

Re-compilation of the project after any change takes around a minute which is pretty reasonable considering the size of the project. But the issue I faced was that even after compilation I can't see the changes i made in the browser, it takes X amount of time(varying b/w 5-10 minutes) and a number of tries to show up on the browser. I'd like to confirm if it's the same situation on your end as well or if I should be doing something incorrectly.

I'm a little reluctant to open a new issue for this because I'm not sure if it's an issue with me only. I'm currently using WSL2 (Ubuntu 22.04) on Windows 11 as I'm using Docker ce right now, I can fully switch to windows too if you suggest after moving to Docker Desktop.
Sorry for the long text, I got a little carried away ^^

Re-compilation of the project after any change takes around a minute

That's usually what I do when working on JupyterCAD, I feel like it takes less than a minute on my side. I've not used the watch command in a while and I'm not sure it's properly setup, maybe @trungleduc knows if it works.
Wait until you want to change the symbols we compile in the OCC WASM build, you'll see that rebuilding takes maybe 10 minutes 😆 And actually I wonder if this could be the reason for you to wait 5/10 minutes with the watch command, could it trigger an OCC rebuild everytime?

calling jlpm run watch at the root is the correct way to watch the project. But lerna watch does not work well with WSL

But the issue I faced was that even after compilation I can't see the changes i made in the browser

did you disable your browser cache?

could it trigger an OCC rebuild everytime?

I couldn't see much logs to verify this, i guess the verbosity is low by default is there some way that it could be increased? I'll definitely follow up on this further

did you disable your browser cache?

No I didn't, I just confirmed. I'd do it again with disabled browser cache. And I think this is also something we should include in the documentation as a note.

calling jlpm run watch at the root is the correct way to watch the project. But lerna watch does not work well with WSL

Ah I see, I think then I'd rather try migrating/replicating the development environment fully on windows  too and then test again.

I've not used the watch command in a while

Is there something else that you use more often? If yes, may I also know 🙂.
Thanks both :)

Hi there, Good News(for me 😅)
I have set-up the project fully on windows and It's compiling much faster than WSL.
However, I think there's one issue that hasn't been addressed yet & that's about $LERNA_PACKAGE_NAME. i.e.:
When I watch the build in root & modify any files, it throws an error saying -
lerna notice filter including "$LERNA_PACKAGE_NAME"
lerna ERR! EFILTER No packages remain after filtering [ '$LERNA_PACKAGE_NAME' ]

I feel it's because LERNA_PACKAGE_NAME is not set for me locally but I'm not exactly sure what to set it.
But just to verify that jlpm run watch is working nicely for me, in package.json in temporarily replaced

lerna watch -- lerna run build --scope=\\$LERNA_PACKAGE_NAME --include-dependents with
lerna watch -- lerna run build --scope=@jupytercad/jupytercad-core --include-dependents

& It now works as expected with no more issue of being able to see changes on browser. Really glad, Thanks a lot both 💐

Hi @trungleduc @martinRenou, sorry to ping you.
Just a gentle follow up on this -

I feel it's because LERNA_PACKAGE_NAME is not set for me locally but I'm not exactly sure what to set it.

I feel it's because LERNA_PACKAGE_NAME is not set for me locally but I'm not exactly sure what to set it.

Small Update: I just removed --scope=\\$LERNA_PACKAGE_NAME for now, i.e. lerna watch -- lerna run build --include-dependents & it works for me & compiles all 7 projects at the same time.
However there's a very small issue now, that the project is always re-compiling without me even modifying anything after the first change I make. Fortunately it doesn't prevent me from developing the code :)

LERNA_PACKAGE_NAME  is defined automatically by lerna, you should not remove it from the command.
https://lerna.js.org/docs/features/workspace-watching#watch-environment-variables

LERNA_PACKAGE_NAME  is defined automatically by lerna, you should not remove it from the command.
https://lerna.js.org/docs/features/workspace-watching#watch-environment-variables

Thanks so much for the response 🚀, I think i found the issue with the help of this.
Quoting from lerna doc link you've sent:

If you use Lerna in Windows, you must frame environment variables in '%'. For example:
$ lerna watch -- lerna run build --scope=%LERNA_PACKAGE_NAME% --include-dependents

JupyterGIS's Contributing Guide also looks outdated. Would you mind if I fix that there too?

JupyterGIS's Contributing Guide also looks outdated. Would you mind if I fix that there too?

We don't mind at all! Thanks a lot for this

Should be good to close this one now. Thanks a lot both 💐


fix BigNumber usage with undefined - assume 0 in that case.

Nano Node v24.0 returns no values for unused accounts rather than 0 in pre v24.0
Nano Node PR: https://github.com/nanocurrency/nano-node/pull/3790

Is this still needed?

optional as it was fixed in v25 node release - https://docs.nano.org/releases/release-v25-0/#rpc-updates

I think we'll merge it as makes sense to assume 0 in case of issues in the future


React to kestrel merge conflict

Merge conflict with breaking changes...

Got offline approval from @anurse to merge immediate to fix build.

Compilation on macOS completed as a sanity check.

Got offline approval from @anurse to merge immediate to fix build.

Confirmed

🤞


An error occurred when creating a pool using batch shipyard

The vm image used before was microsoft-azure-batch 20-04-lts. Since it will be discontinued on April 23, 2025, the following error occurred when upgrading to microsoft-dsvm 2204: "ValueError: unsupported Docker (and/or GPU) Host VM Config, publisher=microsoft-dsvm offer=ubuntu-hpc sku=2204 vm_size=standard_d2_v3"，Is it because batch shipyard does not support higher versions of Ubuntu, or is there some other reason?

Batch Shipyard is no longer supported. See issue #147 along with the clear archival state of the GitHub repo and README stating that it is no longer supported.


Governance. Delegate activity. Does not send additional request to subquery

Description
Request to the SubQuery does not send, when user open delegate details.
Steps to Reproduce

Go to Governance
Perform Add new delegation case with a new account
Check delegation data by opening and closing delegator's detail

Expected Behavior
Each time, when delegator details opens - send SubQuery request
Or send SubQuery request each block
Actual Behavior
Will be sent only one request, when click on Delegate button from the Governance page
Environment
https://github.com/novasamatech/nova-spektr/commit/907ef85d25843ce185820b08897f97ef87d87e49

Add a new request when open view.

Status verification: ✅


Adding Rx logos

Very shiny - these will look great on some mugs, hoodies and stickers!  Thanks for adding.


Events Feed: Recurring events capability

Is your feature request related to a problem? Please describe.
I'm starting to use the Events feed to share events with members and it would be really helpful if I could add recurring/repeating events like the daily hang out call without having to do it on each individual day.
Describe the solution you'd like
I would love an option like on Google Calendar where you can indicate the event is repeating and set the frequency and number of repeats when creating or editing the event in question
Describe alternatives you've considered
I currently use Google calendar for repeating events but I'd rather get them on the Events feed

Hey @dawnkelly09, that's actually a great suggestion, I will get working on this


Wondering if anyone has experienced issues with this approach

Hey there,
I'm currently using redux-act in a small project and finding it to be very nice to work with. I like how little boilerplate needs to be written, which in turn makes things all the more easier for me to understand.
That said, I haven't used it on a larger/more complex project, and I'm wondering if there are any downsides to using the redux-act approach? I know that it is all redux under the hood, but I'm mostly worried about compatibility issues, like other libraries or patterns that can't be used in conjunction with the redux-act way of creating reducers/actionsCreators.
Thanks for the library and your advice,
Thomas

Compatibility isn't a problem, all action types have a generated unique id in it (except for serializable actions but you know what you're doing when using them) but right now, you cannot handle non redux-act actions inside redux-act reducers nor the other way around. redux-act kind of live in its own world.
If you are planning to use server-side rendering, you should not use all the assignTo and bindTo stuff. That's because on the server, you will have one store per request so you cannot assign your action creators once and for all.

Hmm thanks for your opinion. That seems like it can be a kind of big deal, not being able to listen to outside actions in your reducers when using the redux-act create reducer. Is there any way around that?

Not right now, but I'm thinking about implementing one. That's because redux-act reducers only rely on the action id and ignore any action without it.

Is it possible to get the action type from the action creator generated by redux act?
export const uploadCompleted = createAction('uploadCompleted');
The type is generated randomly for uploadCompleted and is inaccessible, right?
There's no
uploadCompleted.type field, is there?
If not it seems like this would be an issue for using something like redux-saga, which requires listening to the action type coming in. Or special helper functions would need to be used.
Thanks for the help,
Thomas

uploadCompleted is an action creator, so it's just a function. The type is on the action itself. You can create an action to get it.
const uploadCompleted = createAction('uploadCompleted');
const action = uploadCompleted();
console.log(action.type);

All redux-act have string types, just like it is documented in redux.

Hey @pauldijou, thanks for the response.
I understand that the actionCreator will produce an action object with a type field, but say you want to handle a specific action type in an outside reducer (or in my case redux-saga), there doesn't seem to be an easy way to specify what the type of the action is until you actually call the actionCreator.
It would be nice in my opinion if you could get the type of the action without having to invoke the action creator, like:
uploadCompleted.type or uploadCompleted.getType(),
That said, I guess it isn't that bad to just invoke the actionCreator and get the type that way.
uploadCompleted().type
Just my two cents. I'm not sure the library is set up in such a way to allow for the actionCreator function to be assigned a .type property or a .getType method.

You're totally right, it will be done in the next version.

Sweet! Sounds great

Hey @pauldijou , just out of curiosity, when do you think the next version will be published?

Soon :-)

0.4.0 is out. Way better compatibility with other Redux libs. getType() is in too.

@tnrich would love to see an example of your use case with redux-saga, that sounds pretty awesome

hey @kjanoudi, I unfortunately don't have one yet, but was reading about it and wondering how the two libraries would work together

Ok, closing for now, don't hesitate to post a redux-saga example if you do one.


igv: 2.13.2 -> 2.14.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/igv/versions.
meta.description for igv is: "A visualization tool for interactive exploration of genomic datasets"
meta.homepage for igv is: "https://www.broadinstitute.org/igv/"
meta.changelog for igv is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 2.14.0 with grep in /nix/store/0vwmaxsrfp8v0ifzj6dfgcd9w2s21csj-igv-2.14.0
found 2.14.0 in filename of file in /nix/store/0vwmaxsrfp8v0ifzj6dfgcd9w2s21csj-igv-2.14.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
igv

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/0vwmaxsrfp8v0ifzj6dfgcd9w2s21csj-igv-2.14.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A igv https://github.com/r-ryantm/nixpkgs/archive/f4c3ff2d7f49e1bc538fc2625061eb85c5ab7794.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/0vwmaxsrfp8v0ifzj6dfgcd9w2s21csj-igv-2.14.0
ls -la /nix/store/0vwmaxsrfp8v0ifzj6dfgcd9w2s21csj-igv-2.14.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

igv

Maintainer pings
cc @mimame for testing.

Result of nixpkgs-review pr 186958 run on x86_64-linux 1

1 package built:

igv


Script needed to run Ondex KnetBuilder GUI

In addition to the existing .sh and .bat for the Ondex KnetBuilder CLI....
Users should be able to run the Ondex Integrator GUI from the ondex-knet-builder release.
I suppose we can create .sh and .bat scripts for the GUI version as well and make sure it recognizes all plugins from the plugins/ folder?

I've started a branch for this and I've reached the point where I can run the Integrator window, but it still misses a number of things and is buggy: several plugins seems to be missing (despite being listed in the POM, needs debugging to understand why) and, when I try to use a plugin to start building a workflow, a null pointer exception is reported on the stdout and nothing happens on the GUI.
So, it's not so easy and, as discussed today, it doesn't seem to be such a high priority feature, given that the main reason to build workflows visually is to see the execution result in the ONDEX GUI application (the integrator can be invoked from within that).


React-native run-adroid not working

What is wrong?
app is not getting build in to my phone.
on running $react-native run-android on windows cmd
gradle repo is getting downloded and installed while installing application to device I'm getting this error
Exception in thread "main" java.lang.NullPointerException
at org.gradle.wrapper.BootstrapMainStarter.findLauncherJar(BootstrapMain
Starter.java:34)
at org.gradle.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.ja
va:25)
at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:127)
at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
Where does it happen?
it happens on graddle I guess i don't know clearly
How do we replicate the issue?
just use command react-native run-android
How important is this (1-5)?
I am not even able to create a sample hello world app because of this issue.
Expected behavior (i.e. solution)
App should open in my android device

This project was not built to support React Native or mobile apps.

https://github.com/jamrizzi/react-gantt/issues/7


Small bug?

Helllo,
In index.js, line 162, instead of
return parseShp(shp);
shoudn't it be
return parseShp(shp, prj); ?

yes I think you are right, do you want to open a pull request to fix it ?

this has been fixed


This works to testing ?

Great work :D  , this would work just to testing behavior?

I've followed the Docker image API specifications, so the pull feature could be used for testing, it doesn't use BRTFS sub volume mounting - yet so I've noticed the tomcat image for example doesn't work.
The project is supposed to be about learning core concepts of Docker, thinking about how they could work in Python and also, keeping it simple.


haskell.compiler.ghc912: init at 9.12.1

See: https://www.google.com/search?client=firefox-b-d&q=ghc+9.12+relreased
This is a bit tricky because hadrian now requires directory > 1.39. But GHC-9.6 comes with an older version. Therefore we need to bump directory, but also make sure everything that has directory as a dependency (process, ghc-toolchain, ghc-platform, Cabal) is also using the same version. The process boot library is one such package, so we need to make sure it actually gets built rather than being taken from GHC's pkg-db.
I wasn't sure what the best way to do that is. I'm happy to change if folks have ideas.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[X] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[X] Tested basic functionality of all binary files (usually in ./result/bin/)
25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Upgrading directory does not seem to be necessary with Linux. Closing in favor of #367194.


Python 2 support

Any plans to support Python 2? Specifically 2.7.
Upgrading to Python 3 is not something that we can currently do with our system.
Thanks

Tried to run 3to2 on it but, the unit tests are failing with:
$ python tests/client_tests.py
test_is_connected_decorator_works_as_expected (__main__.BtfxWssTests) ... ok
test_subscribing_to_data_works (__main__.BtfxWssTests) ...

Also fixed the issue with KeyError.
If for whatever reason this doesn't get merged and deployed. You can modify your requirements.txt to replace:
btfxwss==1.1.1
with
-e git://github.com/TapWealth/btfxwss.git#egg=btfxwss

Hey @apotapov!
thanks for the PR and the issue!
As I have pointed out in the PR, I will not merge it since I do not believe in supporting Python2 development at this point, since it's just a little over 2 years left before it is officially not supported anymore.
Thank you again for your efforts!


Serialize string enums and AccessControlRequest

Serialize string enums and AccessControlRequest
Initial issue: TypeError: Object of type CanManage is not JSON serializable while passing acl to TypeError: Object of type CanManage is not JSON serializable. This is solved by (str, Enum) changes.
Subsequent issue: {'error_code': 'BAD_REQUEST', 'message': 'Principal name not defined'} after making Enum serializable. This was caused by poorly formatted JSON passed to Databricks.
Example of poor JSON:
"access_control_list": [
        {
            "__root__": {
                "permission_level": <CanManage.canmanage: "CAN_MANAGE">,
                "user_name"<EMAIL_ADDRESS>            }
        },
        {
            "__root__": {
                "permission_level": <CanView.canview: "CAN_VIEW">,
                "user_name": None,
                "group_name": "users"
            }
        }
    ]

Closes https://github.com/PrefectHQ/prefect-databricks/issues/49
Example
It is not affecting functionality/usability, just fixing behaviour.
Snippet to show case initial issue:
import json
import os
from asyncio import run

from prefect_databricks import DatabricksCredentials
from prefect_databricks.flows import jobs_runs_submit_and_wait_for_completion
from prefect_databricks.models.jobs import (
    AccessControlRequestForGroup,
    AccessControlRequestForUser,
    CanManage,
    CanView,
    NewCluster,
    RunSubmitTaskSettings,
    SparkPythonTask,
)

owners =<EMAIL_ADDRESS>acl = [
    json.loads(
        AccessControlRequestForUser(
            permission_level=CanManage.canmanage,
            user_name=user,
        ).json()
    )
    for user in owners
]
acl.append(
    json.loads(
        AccessControlRequestForGroup(
            group_name="users", permission_level=CanView.canview
        ).json()
    )
)

run(
    jobs_runs_submit_and_wait_for_completion(
        databricks_credentials=DatabricksCredentials(
            databricks_instance=os.environ["DATABRICKS_INSTANCE"],
            token=os.environ["DATABRICKS_TOKEN"],
        ),
        tasks=[
            RunSubmitTaskSettings(
                new_cluster=NewCluster(
                    spark_version="10.4.x-scala2.12",
                    num_workers=1,
                    node_type_id="m5d.large",
                ),
                spark_python_task=SparkPythonTask(python_file="s3://foo/bar.py"),
                task_key="foo",
            )
        ],
        access_control_list=acl,
    )
)

Screenshots
none
Checklist

[x] References any related issue by including "Closes #" or "Closes ".

If no issue exists and your change is not a small fix, please create an issue first.

[x] Includes tests or only affects documentation.
[x] Passes pre-commit checks.

Run pre-commit install && pre-commit run --all locally for formatting and linting.

[x] Includes screenshots of documentation updates.

Run mkdocs serve view documentation locally.

[x] Summarizes PR's changes in CHANGELOG.md

Thanks for fixing this! Can you add a unit test for AccessControlRequest converting that to a JSON and asserting that the output is what you expect?

I think this just needs a CHANGELOG.md entry, then it's good to go!

I think this just needs a CHANGELOG.md entry, then it's good to go!

Hey @ahuang11 , sorry, it took me a while to add one line :) Hope now it can be merge.


Change jobs and or services to account for new relationships

child of #996
Go into existing files where the relationship is being created and change to use the new predicate.  Remove the population of the old predicate.

Focus of the project has changed and we are moving to a new ScholarSphere that may not be dependent on the current technology stack.


infer_schema! fails on table, removing a column yields success

Setup
Versions

Rust: 1.21.0
Diesel: 0.16.0
Database: SQLite
Operating System OS X 10.13

Feature Flags

diesel: ["sqlite"]
diesel_codegen: ["sqlite"]

Problem Description
infer_schema! fails when running cargo build for this table:
CREATE TABLE test (
    e01 INTEGER NOT NULL,
    e02 VARCHAR NOT NULL,
    e03 TEXT NOT NULL,
    e04 VARCHAR NOT NULL,
    e05 VARCHAR NOT NULL,
    e06 FLOAT NOT NULL,
    e07 FLOAT NOT NULL,
    e08 FLOAT NOT NULL,
    e09 FLOAT NOT NULL,
    e10 FLOAT NOT NULL,
    e11 FLOAT NOT NULL,
    e12 FLOAT NOT NULL,
    e13 FLOAT NOT NULL,
    e14 FLOAT NOT NULL,
    e15 FLOAT NOT NULL,
    e16 FLOAT NOT NULL,
    e17 VARCHAR PRIMARY KEY NOT NULL
);

Removing a column (e.g. e16) followed by cargo clean and cargo build yields a successful build.
What are you trying to accomplish?
A successful inference of the test table.
What is the expected output?
A successful build.
What is the actual output?
% cargo build
   Compiling diesel_issue v0.1.0 (file:///Users/abhik/Development/rust/diesel_issue)
error[E0277]: the trait bound `(__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17): diesel::Expression` is not satisfied
 --> src/lib.rs:7:1
  |
7 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `diesel::Expression` is not implemented for `(__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17)`
  |
  = note: this error originates in a macro outside of the current crate

error[E0277]: the trait bound `(__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17): diesel::expression::NonAggregate` is not satisfied
 --> src/lib.rs:7:1
  |
7 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `diesel::expression::NonAggregate` is not implemented for `(__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17)`
  |
  = note: this error originates in a macro outside of the current crate

error[E0277]: the trait bound `(__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17): diesel::SelectableExpression<__diesel_infer_schema::infer_test::test::table>` is not satisfied
 --> src/lib.rs:7:1
  |
7 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `diesel::SelectableExpression<__diesel_infer_schema::infer_test::test::table>` is not implemented for `(__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17)`
  |
  = note: this error originates in a macro outside of the current crate

error[E0277]: the trait bound `(__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17): diesel::SelectableExpression<__diesel_infer_schema::infer_test::test::table>` is not satisfied
 --> src/lib.rs:7:1
  |
7 | infer_schema!("dotenv:DATABASE_URL");
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `diesel::SelectableExpression<__diesel_infer_schema::infer_test::test::table>` is not implemented for `(__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17)`
  |
  = note: this error originates in a macro outside of the current crate

error: aborting due to 4 previous errors

error: Could not compile `diesel_issue`.

To learn more, run the command again with --verbose.

Are you seeing any additional errors?
Nope.
Steps to reproduce
Please see example repo and follow README
Checklist

[x] I have already looked over the issue tracker for similar issues.

Did you try the large-tables feature?
Abhik B Pramanik<EMAIL_ADDRESS>schrieb am Sa. 28. Okt. 2017 um
02:10:

Setup Versions

Rust: 1.21.0
Diesel: 0.16.0
Database: SQLite
Operating System OS X 10.13

Feature Flags

diesel: ["sqlite"]
diesel_codegen: ["sqlite"]

Problem Description
infer_schema! fails when running cargo build for this table:
CREATE TABLE test (
e01 INTEGER NOT NULL,
e02 VARCHAR NOT NULL,
e03 TEXT NOT NULL,
e04 VARCHAR NOT NULL,
e05 VARCHAR NOT NULL,
e06 FLOAT NOT NULL,
e07 FLOAT NOT NULL,
e08 FLOAT NOT NULL,
e09 FLOAT NOT NULL,
e10 FLOAT NOT NULL,
e11 FLOAT NOT NULL,
e12 FLOAT NOT NULL,
e13 FLOAT NOT NULL,
e14 FLOAT NOT NULL,
e15 FLOAT NOT NULL,
e16 FLOAT NOT NULL,
e17 VARCHAR PRIMARY KEY NOT NULL
);
Removing a column (e.g. e16) followed by cargo clean and cargo build
yields a successful build.
What are you trying to accomplish?
A successful inference of the test table.
What is the expected output?
A successful build.
What is the actual output?
% cargo build
Compiling diesel_issue v0.1.0 (file:///Users/abhik/Development/rust/diesel_issue)
error[E0277]: the trait bound (__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17): diesel::Expression is not satisfied
--> src/lib.rs:7:1
|
7 | infer_schema!("dotenv:DATABASE_URL");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait diesel::Expression is not implemented for (__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17)
|
= note: this error originates in a macro outside of the current crate
error[E0277]: the trait bound (__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17): diesel::expression::NonAggregate is not satisfied
--> src/lib.rs:7:1
|
7 | infer_schema!("dotenv:DATABASE_URL");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait diesel::expression::NonAggregate is not implemented for (__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17)
|
= note: this error originates in a macro outside of the current crate
error[E0277]: the trait bound (__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17): diesel::SelectableExpression<__diesel_infer_schema::infer_test::test::table> is not satisfied
--> src/lib.rs:7:1
|
7 | infer_schema!("dotenv:DATABASE_URL");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait diesel::SelectableExpression<__diesel_infer_schema::infer_test::test::table> is not implemented for (__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17)
|
= note: this error originates in a macro outside of the current crate
error[E0277]: the trait bound (__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17): diesel::SelectableExpression<__diesel_infer_schema::infer_test::test::table> is not satisfied
--> src/lib.rs:7:1
|
7 | infer_schema!("dotenv:DATABASE_URL");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait diesel::SelectableExpression<__diesel_infer_schema::infer_test::test::table> is not implemented for (__diesel_infer_schema::infer_test::test::columns::e01, __diesel_infer_schema::infer_test::test::columns::e02, __diesel_infer_schema::infer_test::test::columns::e03, __diesel_infer_schema::infer_test::test::columns::e04, __diesel_infer_schema::infer_test::test::columns::e05, __diesel_infer_schema::infer_test::test::columns::e06, __diesel_infer_schema::infer_test::test::columns::e07, __diesel_infer_schema::infer_test::test::columns::e08, __diesel_infer_schema::infer_test::test::columns::e09, __diesel_infer_schema::infer_test::test::columns::e10, __diesel_infer_schema::infer_test::test::columns::e11, __diesel_infer_schema::infer_test::test::columns::e12, __diesel_infer_schema::infer_test::test::columns::e13, __diesel_infer_schema::infer_test::test::columns::e14, __diesel_infer_schema::infer_test::test::columns::e15, __diesel_infer_schema::infer_test::test::columns::e16, __diesel_infer_schema::infer_test::test::columns::e17)
|
= note: this error originates in a macro outside of the current crate
error: aborting due to 4 previous errors
error: Could not compile diesel_issue.
To learn more, run the command again with --verbose.
Are you seeing any additional errors?
Nope.
Steps to reproduce
Please see example repo
https://github.com/abhikp/diesel_infer_schema_issue and follow README
Checklist

I have already looked over the issue tracker
https://github.com/diesel-rs/diesel/issues for similar issues.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/diesel-rs/diesel/issues/1280, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABOX9K1UDS7uWoMdDtAi3KMPrGXB-xOks5swnDqgaJpZM4QJvtD
.

That worked. Thanks!


Fix launch.json

Purpose
Fix minor regression caused by a previous PR.
Check List

[ ] Read the Contributing Guide
[ ] Required Balo version update
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[ ] Added necessary tests

[ ] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

Codecov Report

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

@@           Coverage Diff           @@
##           master   #19689   +/-   ##
=======================================
  Coverage   15.21%   15.21%
=======================================
  Files          50       50
  Lines        1308     1308
  Branches      199      199
=======================================
  Hits          199      199
  Misses       1096     1096
  Partials       13       13

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 23ddb6a...21c43bd. Read the comment docs.


Updating Ingress docs for 1.19

This updates the Ingress docs for the 1.19 release as the feature graduates to GA.
Enhancement issue: https://github.com/kubernetes/enhancements/issues/1453
/sig network
/cc @cmluciano

/milestone 1.19

LGTM. But I will defer it to people who are more involved in this area. Thanks

/remove-language fr id ja ko pl ru zh

@cmluciano Thanks for taking this on! I've marked this as ready for review and left a few comments as well. One higher level question - do we have any examples of ingressClassName being set inside Ingress? If not, it might be good to include that in one of the examples.
As far as docs review, maybe @sftim can help? He's had great feedback on some of my previous PRs.
/cc @sftim

All updates are pushed and review comments are all addressed. @sftim @robscott

This all LGTM from a technical perspective, thanks @cmluciano! Since I'm the one that created the PR I don't think I can actually /lgtm it though, so anyone can feel free to do that on behalf of me.

/lgtm
(on behalf of @robscott )
Will approve once @sftim takes a look and is okay with the PR. Thanks @robscott @cmluciano

/assign @bradtopol

Page preview:
https://deploy-preview-21590--kubernetes-io-vnext-staging.netlify.app/docs/concepts/services-networking/ingress/

@savitharaghunathan  it looks fine to me

@kbhawkey @sftim I believe this PR should be good to go now, please take another look whenever you have a chance.

:+1:

@robscott , Changes look good.
/lgtm

@tengqm , Do you think this PR has merits to merge and address the remaining nits in a follow-up pull request?
I don't recall the 1.19 deadline date.

Thanks for the review @tengqm! Please take another look whenever you have a chance.

@kbhawkey Absolutely. AFAICT, the changes made to Ingress resource are among the headlines for 1.19 release.

/lgtm

btw, 1.19 release schedule here: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.19

Hi @robscott @cmluciano 👋 , Thank you both for this PR. Friendly reminder that docs should be reviewed and ready to be merged by July 16th. We have the lgtm from the docs team, still, need one from tech review to be able to merge this PR.
Thanks, @sftim @kbhawkey @tengqm for your time and great reviews :)


Allow guests to request a new read-write terminal

Currently, guests are able to request read-write access to existing shared terminals, but there isn't a way for them to request access to a new terminal in read-write mode. This could enable a more intuitive experience, then requiring guests to verbally ask the host to share a new read-write terminal.

Closing this since we haven't heard sufficient demand for this capability. Please re-open it if you'd like to see us prioritize this. Thanks!


[RFC] Improve MNIST example

Avoid from chainer import training which I think is not normally done by ordinary users.
When breaking lines, put a single argument in each line. This is easier to read and recommended in OpenStack guideline.
Avoid a if b else c, which is difficult to read.
Some other minor fixes.

Requesting for comments.
If these fixes are acceptable, I would like to apply to all other examples.

Avoid from chainer import training which I think is not normally done by ordinary users.

I don't think so personally, because one famous chainer implementation does this.
https://github.com/pfnet-research/sngan_projection/blob/e84b1a5f604de5fec268f37c3f26478e80b7f475/train.py#L6-L9

@crcrpar
It seems the code was based on one of Chainer examples.
I guess not many people would have written this way by their own.
That may be just a guess, but there is more concrete reason to avoid that (restating what I wrote above):

For those who are not familiar with Chainer, it's more difficult to figure out actual location of identifiers like training.updaters.StandardUpdater. They have to go back to the top  of the script to check.

It would be fine if we were going to say it's a convention (like F or extensions), but I don't think this is the case.


How to run the tests?

There is not documented how to run the tests and which testsuite is used.

Thanks for your comments, @rabbl - test running is a very important topic, but it's a topic for another lesson. Here we're just learning how to put your existing project together into a shippable package; hopefully, those tests were written and run before you ever got to this step.


rename/rescope to shinymodulehelper

if in fact helpers like abort_if_reactive() and friends also become part of this pkg

nope, got a better name/scope


Unable to create an AD App from a manifest file

Description
Unable to create an AD App from a manifest file using the m365 aad app add command.  I'm sure I'm doing something wrong, Looking for guidance on how to move forward.
Steps to reproduce

In the Azure Portal, create an AD App with the default settings and some name.
Navigate to that app and download the manifest file
Update the name of the app within the manifest to something unique
Run these commands from the same location the file was created in

$json= Get-Content 'testmanifest.json'
m365 aad app add --manifest $json

Expected results
App should be created in the Azure Tenant with the specified name
Actual results
Error running script:
Error: Error while parsing the specified manifest: SyntaxError: Unexpected token a in JSON at position 3
Diagnostics
Error: Error while parsing the specified manifest: SyntaxError: Unexpected token a in JSON at position 3
CLI for Microsoft 365 version
v5.1.0
nodejs version
v16.14.2
Operating system (environment)
Windows
Shell
PowerShell
cli doctor
{
"os": {
"platform": "win32",
"version": "Windows 10 Enterprise",
"release": "10.0.19042"
},
"cliVersion": "5.1.0",
"nodeVersion": "v16.14.2",
"cliAadAppId": "31359c7f-bd7e-475c-86db-fdb8c937548e",
"cliAadAppTenant": "common",
"authMode": "DeviceCode",
"cliEnvironment": "",
"cliConfig": {},
"roles": [],
"scopes": [
"AllSites.FullControl",
"AppCatalog.ReadWrite.All",
"AuditLog.Read.All",
"ChannelMember.ReadWrite.All",
"ChannelMessage.Read.All",
"ChannelMessage.Send",
"ChannelSettings.ReadWrite.All",
"Chat.Read",
"Chat.ReadWrite",
"Directory.AccessAsUser.All",
"Directory.ReadWrite.All",
"Group.ReadWrite.All",
"IdentityProvider.ReadWrite.All",
"Mail.ReadWrite",
"Mail.Send",
"Place.Read.All",
"Policy.Read.All",
"Reports.Read.All",
"ServiceHealth.Read.All",
"ServiceMessage.Read.All",
"ServiceMessageViewpoint.Write",
"Tasks.ReadWrite",
"Team.Create",
"TeamMember.ReadWrite.All",
"TeamsApp.ReadWrite.All",
"TeamsAppInstallation.ReadWriteForUser",
"TeamSettings.ReadWrite.All",
"TeamsTab.ReadWrite.All",
"TermStore.ReadWrite.All",
"User.Invite.All",
"User.ReadWrite.All",
"profile",
"openid",
"email"
]
}
Additional Info
Suspect I'm doing something wrong in loading the json.  Using this example from the docs:
m365 aad app add --manifest @testmanifest.json
Results in this error:
ParserError:
Line |
1 |  m365 aad app add --manifest @testmanifest.json
|                              ~~~~~~~~~~~~~
| The splatting operator '@' cannot be used to reference variables in an expression. '@testmanifest' can
| be used only as an argument to a command. To reference variables in an expression use '$testmanifest'.

Sorry to hear you're running into trouble and I appreciate you reaching out to us. Which version of PowerShell are you using?
For the first case, where you're storing the contents of a manifest file in a variable, I suspect that you're getting an error because the contents of the variable contain spaces and quotes which must be escaped as you're passing them to an executable.
In the second case, when you try to pass the contents of a file using the @ token, since it's a special character in PowerShell, do you know if there's a way to escape it so that it's not recognized by PowerShell but it's picked up by the CLI?

Awesome! Great to hear you found the solution and thank you for sharing it with us. I'm sure it will help others.


Xsoar contrib/shubham sudo contrib generic sql add headers

Contributing to Cortex XSOAR Content
Make sure to register your contribution by filling the contribution registration form
The Pull Request will be reviewed only after the contribution registration form is filled.
Status

[x] In Progress
[ ] Ready
[ ] In Hold - (Reason for hold)

Related Issues
fixes: link to the issue
Description
Added headers to GenericSQL context output to Fix #17417 issue.
Screenshots
Paste here any images that will help the reviewer
Minimum version of Cortex XSOAR

[ ] 6.0.0
[ ] 6.1.0
[ ] 6.2.0
[ ] 6.5.0

Does it break backward compatibility?

[ ] Yes

Further details:

[ ] No

Must have

[ ] Tests
[ ] Documentation

hi @shubham-sudo,
Thank you for your submission.
please re-open this PR under the content repository instead of this one.
if you need any help with the process, feel free to reach out.

Hi @yaakovi ,
Does that mean I have to raise a PR to demisto/content repository? I couldn't find any content repository with xsoar-contrib/content and not really sure about this. If you could guide me a bit would be helpful. Thanks

Hi @yaakovi , Does that mean I have to raise a PR to demisto/content repository? I couldn't find any content repository with xsoar-contrib/content and not really sure about this. If you could guide me a bit would be helpful. Thanks

yes, open the repository in demisto/content (where is issue is posted)

Closing as a duplicate of the content PR: https://github.com/demisto/content/pull/17828


data/insurance.json file is missing

data/insurance.json file mentioned in "Run locally" procedure is missing in the repository and data/banking.json and data/skill-insurance-voice-bot.json exist instead.
https://github.com/IBM/watson-voice-bot/blob/master/doc/source/local.md
37: * Click the `Choose JSON File` button and choose the `data/insurance.json` file in your cloned watson-voice-bot repo.
38: * Make sure the `Everything` button is enabled.
39: * Click `Import`.
40: * Go back to the Skills page (use the left sidebar).
41: * Look for `insurance-voice-bot` card.

It looks line number 37 of the "Run locally" procedure should be modified as follows.
37: * Click the `Choose JSON File` button and choose the `data/skill-insurance-voice.json` file in your cloned watson-voice-bot repo.
38: * Make sure the `Everything` button is enabled.
39: * Click `Import`.
40: * Go back to the Skills page (use the left sidebar).
41: * Look for `insurance-voice-bot` card.

thank you @sn6t