When game finished, undo puts you in strange state

To reproduce:

Score ten goals
Select "undo last game"
Try to score goal

I can't reproduce.
If you score 10 with 2 points difference, the game is finished and you are sent to the game summary.

This probably happened in relation with the shuffle-bug that caused two of the same players. Close.


SUBMARINE-1233. Notebook auto-reload

What is this PR for?
Notebook auto-reload too frequently. Change the reload rate to 10 sec/request
What type of PR is it?
Bug Fix
Todos
What is the Jira issue?
https://issues.apache.org/jira/browse/SUBMARINE-1233
How should this be tested?
Screenshots (if appropriate)
Questions:

Do the license files need updating? No
Are there breaking changes for older versions? No
Does this need new documentation? No

@KUAN-HSUN-LI  please help me review the code.


RGBA support

CSS spec defined an RGBA color specification: https://www.w3.org/wiki/CSS3/Color/RGBA
However, passing a value like 'rgba(0, 0, 0, 1)' results an the error:
ValueError: 'rgba(0,0,0,1)' is not a recognized color.

This makes storing values that are intended for use in stylesheets impossible without doing unnecessary conversion.

There are 2 different problems here:

no support for alpha channel yet in Colour.
no support of full CSS3 specification, but only:

named colour like "red", "blue"...
short and long hexadecimal ("#fa3bed" or "#f00")

Thank you for your suggestion, adding the support of these is a good idea.


fixes #78

Cool, looks great! I'll add a test to verify the app no longer crashes later, unless you send another PR before then :)
:beers:


With path_shorten on, I can't find files by typing their full names

Info

Operating System: Ubuntu 23.10

Shell: zsh

Terminal: kitty

nvim --version:
Using Node v18.18.0
NVIM v0.10.0-dev-1809+g529498685
Build type: RelWithDebInfo
LuaJIT 2.1.1700008891

fzf --version:
0.45.0 (202401011)

[x] The issue is reproducible with mini.sh

Description
With path_shorten=true, I need to type the shortened paths to find the files I want; typing the original paths does not find the files.
For example, if my repository contains
/setup/client/somefile1.txt
/setup/server/somefile1.txt
And I do :lua require("fzf-lua").git_files({path_shorten=true})
Then s/s and s/c will find files, but setup will find nothing.
It's not clear to me if this is intentional, but it's not what I would expect. I see the path shortening as a rendering / output setting, not one that would affect the fuzzy search behaviour.

It's not clear to me if this is intentional, but it's not what I would expect.

This is intentional, with fzf the data is passed to an outside process (fzf), without hidden metadata, there is no way for fzf to match based on the full path as it does not exist.
Currently I have no plans on adding hidden metadata with full paths for path shorten as this will slow down considerably and consume too much memory on large repos.

Ok, fair enough. I will see if I can hack it on the fzf side.


Issues ingesting pdf

Hello I'm having issues ingesting pdfs. I tried with the two included files in the repo as well as other pdfs. Below is the error which complains about Project name not set.
creating vector store...
error [Error: PineconeClient: Project name not set. Call init() first.]
gpt4-pdf-chatbot-langchain/scripts/ingest-data.ts:44
    throw new Error('Failed to ingest your data');
          ^

[Error: Failed to ingest your data]

Node.js v19.7.0

I added a console log inside ingest-data.ts. Which shows my api key and environment, but projectName is undefined.
console.log(pinecone)

creating vector store...
PineconeClient {
  apiKey: 'xxxxxxxxx',
  projectName: undefined,
  environment: 'us-west4-gcp',
  configureIndexRaw: [Function (anonymous)],
  configureIndex: [Function (anonymous)],
  createCollectionRaw: [Function (anonymous)],
  createCollection: [Function (anonymous)],
  createIndexRaw: [Function (anonymous)],
  createIndex: [Function (anonymous)],
  deleteCollectionRaw: [Function (anonymous)],
  deleteCollection: [Function (anonymous)],
  deleteIndexRaw: [Function (anonymous)],
  deleteIndex: [Function (anonymous)],
  describeCollectionRaw: [Function (anonymous)],
  describeCollection: [Function (anonymous)],
  describeIndexRaw: [Function (anonymous)],
  describeIndex: [Function (anonymous)],
  listCollectionsRaw: [Function (anonymous)],
  listCollections: [Function (anonymous)],
  listIndexesRaw: [Function (anonymous)],
  listIndexes: [Function (anonymous)]
}

Thanks in advance.

When I was debugging another issue and I entered an incorrect API key to see what happens, this is the error message that I was getting. So definitely double-check, and if that doesn't solve it, consider starting over like the readme suggests:

Pinecone errors

Make sure your pinecone dashboard environment and index matches the one in the pinecone.ts and .env files.
Check that you've set the vector dimensions to 1536.
Make sure your pinecone namespace is in lowercase.
Pinecone indexes of users on the Starter(free) plan are deleted after 7 days of inactivity. To prevent this, send an API request to Pinecone to reset the counter.
Retry from scratch with a new Pinecone index and cloned rep

This worked for me when I was trying to solve the error message I was getting in #97

Thanks for pointing that out. It turns out it was using a apikey from my profile and not the one in the .env, issue is now resolved.


Is it possible to use it in existing project?

Is it possible to use it in existing Laravel app that already developedd?
If yes how?

Not sure what you're asking here?


Error when saving posts

When I save a post, I'm getting this error:
NoMethodError: undefined method `join' for nil:NilClass
Did you mean?  JSON
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/apps/plugins/visibility_post/visibility_post_helper.rb", line 74, in save_visibility
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/apps/plugins/visibility_post/visibility_post_helper.rb", line 21, in plugin_visibility_create_post
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/helpers/camaleon_cms/hooks_helper.rb", line 39, in block in _do_hook
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/helpers/camaleon_cms/hooks_helper.rb", line 33, in each
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/helpers/camaleon_cms/hooks_helper.rb", line 33, in _do_hook
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/helpers/camaleon_cms/hooks_helper.rb", line 19, in block in hooks_run
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/helpers/camaleon_cms/hooks_helper.rb", line 18, in each
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/helpers/camaleon_cms/hooks_helper.rb", line 18, in hooks_run
  File "/app/vendor/bundle/ruby/2.3.0/bundler/gems/camaleon-cms-aa54fce8ed2e/app/controllers/camaleon_cms/admin/posts_controller.rb", line 104, in update

The posts are saving correctly, just throwing an error both in the logs and onscreen. I'm forced to manually navigate back to my post to continue editing.
Camaleon 2.4, Rails 5

Update: This appears to occur only when setting visibility to Private, but not selecting any of the checkboxes indicating who can view it. It's uncorrected user error. I suggest requiring that one of the boxes be checked to avoid this error.

Fixed!
Github version.


Provide README for autotools

Fix Makefile.am: error: required file './README' not found by
providing a README target in Makefile.am, per
https://stackoverflow.com/questions/15013672/use-autotools-with-readme-md/44859139#44859139

Thanks!


bug-OPEX-multiplied

The operational cost value (OPEX) should be multiplied by the gap between two consecutive  year steps except the last one that should be multiplied by one.
It should be fixed in both code and the documentation.

done


Allow specifying target filename for JSON config output

Right now, when using -s, it outputs a JSON with a pre-determined filename, appending a date.
This is not super great for automation. Could we have the ability to set a snapshot name just like the old SMI?

Hey Raymond, we have it already added that feature in, you have to use the -f flag to set the filename of the snapshot, exactly like old SMI. Link to instructions - https://github.com/tenstorrent/tt-smi?tab=readme-ov-file#snapshots

Hey @sbansalTT - I mean with the -g option, not the -s option.
For example, here, it would be nice if the first one generated log.log instead of a pre-determined JSON filename.

Oh gotcha - yes, I will add that into the next release

This has been fixed as of release 2.1.0
you should now be able to specify the file, or use the default with -g when generating the reset config


GUACAMOLE-179: Move PulseAudio support into utility library.

This change moves the PulseAudio support provided by the VNC client into a common utility library which can be shared by other protocol implementations, including the WIP X.Org driver.
Part of this change involved modifying libguac's audio stream implementation such that it does not rely on a connection "owner" existing. Not all guacd-like Guacamole protocol implementations will have a connected user at all times.

Looks good to me!


[Bug] Selecting text generates numerous errors

Hello, I noticed that my devtools where flooded by errors when selecting text in any page.
So I disabled all my extensions one by one to find the culprit, which is your extension, sorry 😅
content.js:7 Uncaught TypeError: Cannot read properties of undefined (reading 'target')
    at content.js:7:494323

Not sure if this one is also related though

Thanks for your nice extension and good luck debugging !

Thanks for the report.
I cannot replicate it here. Can you provide the steps you did that triggered that issue? Something like:

install extension
select text in any page
check devtools for that page


Add stopMovement to stop all movement

What use case does this serve?
In the future please describe your changes and why you made them; please don't open pull requests that don't have descriptions.

Sorry thought the title was description enough. Adds a function stopMovement which stops any movement.
Use case is to stop an animation before it completes. My client wishes to pan view a long distance slowly and have a button to stop movement.Currently in the animate function it check to see if an animation is running and will ignore any subsequent animation calls until the first one has finished so you can't simply animate to current position to stop the first animation. As far as I'm aware currently there is no way to stop an animation while in process, this addresses that.

Thanks!


System.IO.Path.Combine seems to work differently from .NET framework

General
Tested on .NET Core v2.1, 2.2, 3.0:
System.IO.Path.Combine("string\nwith", "other");

In .NET Framework this throws an Argument Exception as documented:
        // Exceptions:
        //   T:System.ArgumentException:
        //     One of the strings in the array contains one or more of the invalid characters
        //     defined in System.IO.Path.GetInvalidPathChars.

In .NET Core it returns the string with the newline character.

@JeremyKuhne and @carlossanlop to hopefully talk to the behavior difference.


Appstudio update test-component-pac-ykxa

Pipelines as Code configuration proposal
To start the PipelineRun, add a new comment with content /ok-to-test
For more detailed information about running a PipelineRun, please refer to Pipelines as Code documentation Running the PipelineRun
To customize the proposed PipelineRuns after merge, please refer to Build Pipeline customization

Pipelines as Code CI/test-component-pac-ykxa-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
7 seconds
init

✅ Succeeded
15 seconds
clone-repository

✅ Succeeded
38 seconds
build-container

✅ Succeeded
17 seconds
inspect-image

✅ Succeeded
14 seconds
deprecated-base-image-check

✅ Succeeded
14 seconds
clair-scan

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
9 seconds
sbom-json-check

✅ Succeeded
17 seconds
label-check

✅ Succeeded
7 seconds
show-sbom

✅ Succeeded
8 seconds
show-summary

Pipelines as Code CI/test-component-pac-ykxa-on-pull-request has successfully validated your commit.

StatusDurationName

✅ Succeeded
7 seconds
init

✅ Succeeded
14 seconds
clone-repository

✅ Succeeded
35 seconds
build-container

✅ Succeeded
20 seconds
inspect-image

✅ Succeeded
18 seconds
deprecated-base-image-check

✅ Succeeded
1 minute
clamav-scan

✅ Succeeded
13 seconds
clair-scan

✅ Succeeded
11 seconds
sbom-json-check

✅ Succeeded
15 seconds
label-check

✅ Succeeded
9 seconds
show-sbom

✅ Succeeded
10 seconds
show-summary


[watchtower] [feature]: mark exhausted sessions as inactive

Is your feature request related to a problem? Please describe.
By default, each watchtower session has at most 1024 updates. Once it is exhausted, it is not used for further updates and a new session is created on demand. During startup of lnd, all active sessions (including those that are exhausted) are loaded as candidates, and once a new update needs to be added to a session, lnd loops over these candidates to find an eligable one.
As, over time, most sessions are exhausted, this is a rather long trial-and-error loop (I have over 60,000 exhausted sessions on my node) which runs (only) once after each startup (when the first update is handled).
Describe the solution you'd like
I'd like lnd to mark exhausted sessions as inactive once all updates are acked by the watchtower server (as it is already done when removing/disabling a tower), so that the exhausted sessions do not need to be consired for new updates (possibly improving lnd startup performance).
Furthermore, this would help with #6886 #6259 #7035 as exactly these sessions (exhausted, inactive, all updates are acked) are candidates for removal from both the server's and the client's databases.

Note that it does not suffice to mark a session as inactive once the last (acked) update is added, as there may be older exhausted sessions where no new update will ever be added.

Took another approach with #7405. I think it solves the same issue though :)

Fixed in https://github.com/lightningnetwork/lnd/pull/7405


Create #references for all the arguments to an endpoint in /api docs.

User should be able to refer exact argument via a #reference link like https://chat.zulip.org/api/register-queue#arguments even for all the arguments to an endpoint.
For example, a link like https://chat.zulip.org/api/register-queue#client_capabilities  should go directly to client_capabilities argument within https://chat.zulip.org/api/register-queue#argument.

@zulipbot claim

@zulipbot abandon

@riibeirogabriel were you interested in working on this?
@orientor FYI in any case.

@timabbott yes, but i have a problem with environment setup in windows.

@zulipbot claim

@zulipbot abandon

@zulipbot claim

Someone working on this might also want to fix the scrollbars, there are too many of them currently.

@amanagr Would it be better to do that in this issue, rather than opening a new issue specifically for that? I'm a new contributor, and this is my first issue, so I might be wrong, but I think that making a separate issue seems a bit cleaner than doing all of them in one issue. Thanks!

Opened #15706 for it.

@amanagr Thanks!

Still working on this. Close to done.

@zulipbot abandon

@zulipbot  claim , as I am new here can you tell me about where will be the files for this, it will help me to get idea faster, I have done with all development setup.

@orientor As I am very new to open source contribution, I am going through the urls, then views and then template to get exact file for change ,but I can;t be able to find desired file. What I have understood about this issue is that I have to create reference urls such that we can directly go to a desired heading at same page. Hope to get learning from this issue.

@Amitsinghyadav most of the changes will have to be done in zerver/lib/markdown/api_arguments_table_generator.py. This file renders the arguments in all API docs.

@timabbott I want help for this issue ,as I am new  to open source community Zulip,I am not able to find the right file for this issue to make changes.I have tried to go through the templates ,urls and views but not getting.
What have I understood about this issue is that I have to create url to directly reach to a particular section at same page.
Hope to learn from this issue.

@timabbott  I have made changes for this issue and created a pull request , I am new here , this is my first issue on which I worked.
I don't know what to do next to get code merged.

@Amit Singh Yadav Thanks for working on this issue. Can you also add the chain icon on hover so that it is easier to create and copy links to these references?

@zulipbot  claim

Fixed in https://github.com/zulip/zulip/pull/16384.


Remove argocd username from psr.yaml

The code passed when triggered.
https://github.com/ploigos/spring-petclinic/actions/runs/2558253888


Matching two terrains

Hello,
I have question i want to make 2 exactly same terrains with probability addon(giving some cracks on my wall). I made identical bitmaps but now if i change any tile all the neiberhods are changing, but i want only that one change( i see no reason to change others that fit perfectly) is there any way to make it possible? Like i need special bitmask or something?
i use 3x3 with 48 tiles
This addon is awesome, thank you!

If someone wants to make something simmilar i just made 2 terrains and combined them. There is a tutorial on how to do it, i didnt find earlier.
THANKS
https://www.youtube.com/watch?v=RmxtwYzciZY&ab_channel=Portponky


update Table 1.1: Fish species recorded

include columns for CARP and CRKD (example of how this could be done in past bulk/skeena and Elk reports)  and define BClist and Cosewic terms in footnotes

have a good look at build script in peace and skeena repos.  skeena one might cross right over with very minor changes.  elk might be a bit odd because flathead isn't actually a different watershed group from elkr so not a good place to start.
watch out for and test the pdf build too as sometimes it is too wide and messes up the pdf

@Mateo9569 - make sure you update Fish PC from GitHub because the cost cosewic and Sara listings may have changed since the last version on your machine.

Completed everything you mentioned except for testing the pdf build as I'm unable to print to pdf. I think it's a package problem. I'll take a look at my session info and compare to yours.

Table looks good in pdf, fits the page

looks like the BT population is not showing as special concern
this is from last year.  will see if can see why

it must have come from the elk.
mutate(CDCode = case_when(species_code == 'BT' ~ 'F-SACO-11', ##pacific population yo
these fish come from the arctic
https://www.sararegistry.gc.ca/virtual_sara/files/cosewic/sr_omble_tete_plat_bull_trout_1113_e.pdf


Backport 2.1: Allow the entry_name size to be set in config.h

Description
Allow the size of the entry_name character array in x509_crt.c to be configurable through a macro in config.h. entry_name holds a path/filename string. The macro introduced in MBEDTLS_X509_MAX_FILE_PATH_LEN.
This addresses issue #492, and is a backport of #592 to mbedtls-2.1 to address issue #1188.
Status
READY
Requires Backporting
NO
Todos

[ ] Tests
[ ] Documentation
[ ] Changelog updated
[ ] Backported

I've rebased this against mbedtls-2.1/mbedtls 2.1.12.
@andresag01 / @Patater - Could you please re-approve?

@Patater - I understand your point on the commits, but I am reluctant to do that for different authors.
Regardless, that's a minor comment, so am taking the two reviews as acceptance, and marking as 'ready for merge'.


Webpack @import sass error

Hi,
I'm not sure if this is a bug in webpack or a defined loader (ExtractTextPlugin, ...). I'm also not sure if this is the right place to ask, but the error/behavior is quite strange and after several hours en various config trials i always end up with the same error:
ModuleBuildError: Module build failed:
@import 'path/to/my/_partial.scss';
File to import not found or unreadable ...
Whenever i do a first run with 'npm run dev ' and the below configurations  everything builds fine and all .scss files are compiled nicely into one .css file in the correct folder.
But when i modify or add some scss markup in one of the scss files the above error is thrown. But, and this is the strange part, when i save again without modifications the build passes again and in most cases the console does not show a build log but the css is rebuild correctly.
At first I was looking for wrong path configurations, but the first run builds correctly so the files are found... .  I've been searching quite a while for a solution but didn't find anything,
Below my installed packages, webpack config and folder structure
My installed packages are:
"scripts": {     "dev": "set NODE_ENV=development && webpack --watch"   } "webpack": "^2.1.0-beta.22" "resolve-url": "^0.2.1", "resolve-url-loader": "^1.6.1", "sass-loader": "^4.0.2", "style-loader": "^0.13.1", "css-loader": "^0.23.1", "node-sass": "^4.0.0", "extract-text-webpack-plugin": "^2.0.0-beta.4", "file-loader": "^0.9.0", "glob": "^7.1.1", "node-sass": "^4.0.0", "path": "^0.12.7", "postcss-cssnext": "^2.9.0", "postcss-import": "^9.0.0", "postcss-loader": "^1.2.1",  "autoprefixer-loader": "^3.2.0",
My webpack.config.js is quite simple and is as follows:
    entry: {
        styles: ['app.scss'],
    },

    output: {
        filename: '[name].css',
        path: __dirname + '/app/styles'
    },

    resolve: {
        modules: [
            path.resolve(__dirname, 'dev'),
            'node_modules'
        ],
        extensions: ['', '.css', '.scss', '.sass']
    },

    module: {
        loaders: [

            // SASS
            {
                test: /\.scss$/,
                loader: extractTextPlugin.extract({
                    fallbackLoader: "style-loader",
                    loader: "css-loader?modules&sourceMap&importLoaders=1&localIdentName=[local]!resolve-url!sass-loader?sourceMap"
                })
            }
        ]
    },

    plugins: [
        new extractTextPlugin({ filename: '[name].css', allChunks: true })
    ]
}

The folder structure contains one app.scss file in the root ./dev from where alle other .scss files are included:
@import 'assets/styles/_variables.scss';
@import 'assets/styles/_mixins.scss';

@import 'assets/styles/_base.scss';
@import 'assets/styles/_motion.scss';

@import 'components/form/UiButton/_UiButton.scss';
@import 'components/router/UiSideBar/_SideBar.scss';
@import 'components/router/UiTopMenu/_TopMenu.scss';
@import 'components/router/UiSubMenu/_SubMenu.scss';
@import 'components/router/UiToolBar/_ToolBar.scss';
@import 'components/popup/UiModal/_UiModal.scss';
@import 'components/media/UiSpinner/_UiSpinner.scss';

so the first build always succeeds, the next builds throw an error like above mentioned but succeed after double save without modifications.
Has anyone encountered this problem/behavior? Or is this a wrong configuration?

I have the same situation

@artnova-david Got a repro/repository I could check out?

@ev1stensberg currently i don't have a repository for this cause i'm playing around with some code.
I'm not convinced this is a webpack bug though. Webpack was always giving me the same error and so I tried to compile my sass with gulp to see what this would result in. After the first 5 saves or so, ...bam same error as I received from webapck.
So this problem was no so obvious and this got me thinking maybe it is not the transpiler thats causing the error. The next in line that could cause this error was or npm itself, my editor (vscode) or my OS (windows 10). With these options I found this posts: https://github.com/dlmanning/gulp-sass/issues/235. So I tried to compile with Sublime and Atom. Sublime gave me the same error until I set atomic_save: true and then it stopped giving me the error. Atomic editor never gave me the error neither with gulp nor webpack. And when I added a timeout of 1sec to my gulp task I also stopped getting the error when compiling with vscode.
So I guess some editors seem to temporary remove a file when it is saved and webpack --watch and gulp --watch kick in before the editor has put the file back causing a "not found error" for that sepecific file. I must add, the error only happens with .scss files not with .js files.
note: Webpack does seem to have an issue when one uses a .scss file as entry and the --watch option. When compiling with gulp --watch i get an output in the console with every save I do, when I compile with wepack I only get the console output once but the .css file does get rebuild with every save.

@artnova-david That's weird. Would need a repro to check what is going on. Try the --save option once that PR has been added to check if it's any different. A theory of mine would be that webpack first needs to compile to javascript from sass and the watch mode can't pick up the change.
Is your issue solved?

@ev1stensberg well, my issue is kinda solved, because now I use webpack to compile my javascript and component files and use gulp to compile my sass files. I don't find this a huge problem and can live with that. I must state that webpack does pick up the changes in my main.scss and the imported child.scss files, because the resulting .css file contains the changes. Its only that webpack does not output the change log for .scss files to the console in contrast to changes in .js files which are always outputted to the console. And this only happens when I use a .scss file as entry in webpack it does output the logs when I include my .sccs files in the app.js file like (import styles from './app.js')
I will attach the project files asap as a .zip

Could be that scss are being seen as static files. Should output anyway. You should use webpack for your sass as well. Removes a big dependency hole with both webpack and gulp in one project. Your entry should be plain javascript. If you import the scss through an index.js first, and specify it to be the entry point, it should work. Issue is that webpack has to compile down  to js, making it async would delay stats output and make sure the compilation makes it in time.
As for you editor issues, I cannot really comment on that, try putting up a issue on their discord or their chat group if they have any.
Hope this helps! Issue should be closed now. Happy holidays!

@ev1stensberg I tried including my app.scss file into my app.js true import styles from 'app.scss' and in my app.scss @importing all partials and this didn't work either (= no console output but webpack does add the changes to my .css file.) . The only way it works is when I import the .scss partial individual in my .jsx or .vue components and thus my .scss files are compiled on .js changes (I gues this would make them async), but I would like one main .scss file with all my imports to keep things organised. Could you specify on how to make on on main.scss file async in webpack?
I included a reduced example of the current structure and commented out irrelevant code.
Please ignore the 'modules' section in the webpack.config.
MyApp.zip
Happy holidays!!!

You need to change your webpack command in package.json to use this

when I just type --webpack into the console the all modules (paths, ...) are logged only for the first time and only for .js file watches, after that, all changes are logged for .js files but not for .scss files. When i turn on --progress, I do see a blink of the progress appear when a .scss files changes so the watch does occur but nothing is logged/outputted to the console for .scss files.

Can you screenshot your unexpected output?

Sorry for the late response. Here is a screenshot.
As you can see, de sass is compiled to a .css (styles.css) file and the first time the output is logged in the CLI. When this screenshot was taken I modified 5 .scss files that were imported into app.scss, all modifications are visible in the styles.css file but the watch of webpack does not output changes to the CLI.

@artnova-david
Because you are using the new version of extract-text-webpack-plugin "^2.0.0-beta.4"
Need to be modified into this way:
before:
{
    test : /\.scss$/,
    exclude: /node_modules/,
    loader: extractTextPlugin.extract(['css-loader', 'sass-loader'])
}

after:
{
    test : /\.scss$/,
    exclude: /node_modules/,
    loader: extractTextPlugin.extract({
        loader: ['css-loader', 'sass-loader']
    })
}

See details : https://github.com/webpack/extract-text-webpack-plugin#usage-example-with-css

@xyyjk
I tried this before but same result. First log is outputted to the CLI and thats it.

Are you using a webpack.config.dev.js file at all? I had a similar issue but when using webpack as part of create-react-app. My dev environment would work properly after editing webpack.config.dev.js by adding .scss to the loaders' exclude but when running npm run build would get the same @import error when scss files. Turns out I needed to define it in webpack.config.prod.js as well so the build.js script would find the necessary files.

@denisinla yes, i'm definitly using webpack.config

Importing scss file on webpack, easiest way. It worked for me!
Install
npm install sass-loader node-sass webpack --save-dev
import 'file''
Webpack file
... {test: /.scss$/, loaders: ["style", "css", "sass"]}

It works for me with
"webpack": "^4.42.0",
"webpack-cli": "^3.3.11"
 {test: /.scss$/, loaders: ["style-loader", "css-loader", "sass-loader"]}


one stage train problem

CUDA_VISIBLE_DEVICES=2 python ./pytorch/train.py train --config_path=./configs/car.fhd.onestage.config --model_dir=./save_model_one_stage_mask/ --resume=True
Traceback (most recent call last):
File "./pytorch/train.py", line 561, in
fire.Fire()
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/fire/core.py", line 127, in Fire
component_trace = _Fire(component, args, context, name)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/fire/core.py", line 366, in _Fire
component, remaining_args)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/fire/core.py", line 542, in _CallCallable
result = fn(*varargs, **kwargs)
File "./pytorch/train.py", line 168, in train
text_format.Merge(proto_str, config)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/google/protobuf/text_format.py", line 574, in Merge
descriptor_pool=descriptor_pool)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/google/protobuf/text_format.py", line 631, in MergeLines
return parser.MergeLines(lines, message)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/google/protobuf/text_format.py", line 654, in MergeLines
self._ParseOrMerge(lines, message)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/google/protobuf/text_format.py", line 676, in _ParseOrMerge
self._MergeField(tokenizer, message)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/google/protobuf/text_format.py", line 801, in _MergeField
merger(tokenizer, message, field)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/google/protobuf/text_format.py", line 875, in _MergeMessageField
self._MergeField(tokenizer, sub_message)
File "/home/sugon/.conda/envs/pytorch_env/lib/python3.6/site-packages/google/protobuf/text_format.py", line 768, in _MergeField
(message_descriptor.full_name, name))
google.protobuf.text_format.ParseError: 108:3 : Message type "second.protos.InputReader" has no field named "max_number_of_voxels".
the other configs has all passed except this so could you give me some advice or offer me a  new onestage.config.

use car.fhd.config wo have get a 90.12%(easy) in val dateset,so ,I wanna to see the result by using one stage config,thank you.

I forget to update car.fhd.onestage.config. actually the only difference between car.fhd.config and car.fhd.onestage.config is "rpn" in config file. it's very simple.

so just change this line module_class_name: "RPNV2"   to module_class_name: "RPN"?if not,can you send me a file. thank you for answering our questions on the go.

I have update that file. you can compare it with car.fhd.config.

I notice that, thanks.

use car.fhd.config wo have get a 90.12%(easy) in val dateset,so ,I wanna to see the result by using one stage config,thank you.

Hi @yangyongguang , I run the config for 50 epochs, and only achieve 88% for easy 3D object detection(@0.7), I wonder how could you achieve 90% and what about the median and hard result? Thanks!

use car.fhd.config wo have get a 90.12%(easy) in val dateset,so ,I wanna to see the result by using one stage config,thank you.

Hi @yangyongguang , I run the config for 50 epochs, and only achieve 88% for easy 3D object detection(@0.7), I wonder how could you achieve 90% and what about the median and hard result? Thanks!

I have change the model and used the image at the same time. all 3 result is better than the second,but
during test in kitti test dataset the median the worser than second, the others is better. and i also run the
model without change anything ,the result also worser than the second offer.I remerber the median about 78.2.


Vertical Section add empty columns

Category
[X] Bug
[ ] Enhancement
Problem Area
[ ] Page Transformation: Error during the setup/use of the Page Transformation UI solution (did you check our troubleshooting guide?)
[ ] Page Transformation: Error during the use of page transformation from PnP PowerShell
[ ] Page Transformation: Error during the use of page transformation from .Net
[X] Page Transformation: Page is not looking correct after transformation
[ ] Modernization Scanner: something went wrong...
Expected or Desired Behavior
Unused columns are removed or not added to get web parts into vertical section, there maybe cases where not all columns are needed to populate vertical section.
Observed Behavior
If you transform a page with 2 web parts, one with text, one image, set the image to Column 4, enable vertical section, on transform, the text resides in column 1, image in column 4, but 2 empty columns are added.
Steps to Reproduce
Source page with image and text
<PageLayout Name="NewsPageLayout" AssociatedContentType="" PageLayoutTemplate="AutoDetect" PageHeader="Custom" IncludeVerticalColumn="true">
...

<Field Name="PublishingPageImage" TargetWebPart="SharePointPnP.Modernization.WikiImagePart" Row="1" Column="4">
          <Property Name="ImageUrl" Type="string" Functions="ToImageUrl({PublishingPageImage})" />
          <Property Name="AlternativeText" Type="string" Functions="ToImageAltText({PublishingPageImage})" />
          <Property Name="Anchor" Type="string" Functions="ToImageAnchor({PublishingPageImage})" />
          <Property Name="Caption" Type="string" Functions="ToImageCaption({PublishingImageCaption})" />
        </Field>
        <Field Name="PublishingPageContent" TargetWebPart="SharePointPnP.Modernization.WikiTextPart" Row="1" Column="1">
          <Property Name="Text" Type="string" />
        </Field>

You're right. BasePageTransformator.RemoveEmptySectionsAndColumns does not take in account vertical column section types. Will fix this for the December release, this is not a blocking issue as the use of vertical columns anyhow is optional.

@pkbullock : just fixed this one


Halo theory in CCL

Halo theory in CCL
(Tagging relevant people: @elisachisari @damonge @villarrealas @pennalima @aimalz @beckermr @alexander-mead @BenediktDiemer @cavestruz @matthewkirby @elikrause @KuanWang-Astro @zdu863 @c-d-leonard. I’m sure I forgot someone that will want to see this post. My bad.)
This issue is meant to subsume issues #656, #655, and #291. It is also relevant for #344, #235, #275, and #219, so maybe close those too.
As of now, halos are missing from CCL. This is a problem because a huge fraction of the community would benefit from these theory tools. Both cluster science and HOD models are unable to use CCL without these routines. The upside is that most of halo theory is very easy to write down!
This issue contains (my vision for) an outline for how a full halo model should be implemented in CCL. It includes where we need to make changes to the existing code structure, what new files we need to create and build tests for, what theory routines should go into CCL for now, and what pieces of code I think we should toss out/rewrite. I also point out routines that I think should exist elsewhere (namely Firecrown). At the end I also gave a wishlist for things that would be nice but tricky to implement (like how to generally accommodate emulators).
If you don’t spend most of your day thinking about halos and want some background reading, my suggestion is to look at Frank van den Bosch’s lectures. Lectures 4, 6, 8, 9, 10, and 13 would cover everything I mention here. The seminal review paper on halo theory is Cooray & Sheth (2002).
An aside: halo theory =/= cluster science
Cluster science is distinct from halo theory because the former includes a selection function. A ton of effort outside of CCL and DESC is spent understanding cluster (and galaxy) selection functions. Numerically, dealing with selection functions amounts to doing extra integrals over PDFs of your observables and any other quantities you need to consider to link your observable with halo mass. For instance, with redMaPPer clusters, to accurately model some observable (forgetting about redshift for a second) you have to integrate over a fixed bin of observed richness, an infinite integral over true richness, and an infinite integral over halo mass.
The selection function can be arbitrarily more complicated than that, so CCL should probably not try to support cluster science directly. Those routines are probably best left to Firecrown, and as CCL developers we should look to provide highly-optimized versions of functions of halo mass so that those higher-level routines won’t be bogged down.
What I am NOT talking about
When I say “halo theory” I don’t mean halofit. Halofit is an analytic fit to the nonlinear power spectrum. It got its name because it models the power spectrum with a “1-halo” and “2-halo” term, but it has nothing to do with halo theory w.r.t. CCL. This is because, for all practical purposes, halofit makes no effort to model halos themselves. It has no bearing on the halo bias, halo mass function, halo clustering, or anything else halo related. It can be thought of as a black box that spits out the matter power spectrum.
When I say “halo theory” I don’t mean @alexander-mead’s halo-based power spectrum, although this model admittedly takes a lot from actual halo theory. Again, for all practical purposes, Alex’s routine is a method for modeling the nonlinear power spectrum. It makes some assumptions about how matter is distributed in halos (in Fourier space) that are most stringent than in halofit. Like halofit however, it is a black box for predicting the power spectrum. If we wanted to be super-duper sticklers for theoretical consistency, then one could not mix Alex’s model with any parts of halo theory that he did not explicitly include (e.g. non-NFW profiles).
What I am talking about
CCL should accommodate the most basic science that can be done with halos (not clusters; see above). This includes in order of my opinion of priority:

Mass definitions
Mass conversions
Density profiles
Halo number counts
Mass-concentration relations
Halo bias
Halo correlation functions
Projected density profiles
Halo occupation distributions
Fourier-space versions of normalized density profiles

For the most part, the lower points on the list won’t function without the higher parts being implemented correctly if we want to support arbitrary halo mass definitions. I will now go through these one by one and outline what goes into implementing each part of halo theory fully. I will provide some background where I think it’s warranted, but I will probably just link a paper that I think would do the job.
I know that I cannot exhaustively list all the potential models that we could accommodate. There are at least a half dozen different mass-concentration relations. People that have read more of the literature than I should chime in when something is left out, and I can edit in more models later.
0. Mass definitions
Halo mass is written in terms of the background density of the Universe

In this equation, \bar{\rho} is the background density being considered, and is usually either the critical density or the matter density \bar{\rho} = rho_m = Omega_m * rho_crit. Delta refers to the overdensity relative to the background of the halo. In other words, the halo lives in a peak in the density field that is Delta times more dense than rho. Under this definition, a single halo mass M maps to a single halo radius R (R_\Delta in the equation). Sometimes people like to work in physical units rather than comoving, so then a (1+z) appears attached to R and rho becomes a physical density. In the literature you will see things like 200m, 500c, or vir. This indicates which background density is being considered (mean or critical) and which overdensity value is being used (200, 500, or the virial value for that cosmology at some redshift).
We need to decide what halo definitions we want to support. In simulations, people build models under certain halo definitions (e.g. my emulators are for 200m). There are also halo definitions that don’t assume sphericity, like friends-of-friends halo finders, that at fixed halo mass won’t match up to measurements made under a spherical halo definition.
In addition to deciding which halo definitions to support, we should decide how much work we want to put in to warn the user about potentially incompatible models. For instance, it’s one thing to warn the user that mass function A was calibrated for the 200m definition and is incompatible with halo bias B calibrated for 500c, but it is more work to say that two models calibrated under 200m used different halo finders, so they might not agree.
Finally, we also need to decide where mass definitions are specified. The most restrictive and simple way for the user to handle this is to specify a mass definition at the same time that they specify cosmology. This way, everything is done internally, and we can implement functions very cleanly like halo_bias(M, z) rather than halo_bias(M, z, definition). The other extreme is to perhaps make a halo_definition object which gets passed into things. This would have the upside of allowing for more flexibility, such as allowing the user to compute quantities under more than one halo definition at a time (which is of scientific interest).
To summarize, for halo definitions we need to decide the following:

[ ] decide which halo definitions to support
[ ] decide how much flexibility in combining models we allow and what kind of warnings should exist
[ ] decide where we let the user define halo definitions

1. Mass conversions
Once we know which halo definitions we want to support, we should implement a way to convert between mass definitions. To do this in the most general way, we need to also have density profiles (next subsection). Implementing mass conversions early on is nice because it can save us the trouble of rewriting code later on.
Performing a mass conversion involves solving:

Given the left hand side, the halo mass and radius under definition Delta_1, what is the right hand side (note that any factors of Omega_m are absorbed into the Deltas)? We need a second equation to get at both the new halo mass and radius. Without getting into the weeds, one solves this by assuming a density profile of the halo and specifying the concentration (if it’s NFW). After some math and root finding, you can get the right hand side as well as the concentration (or any other profile parameters, given the assumed profile) under the new definition.
The steps for implementing this include:

[ ] write up the mass conversion equations in LaTeX form to put in the CCL note so that we don’t screw this up
[ ] implement the NFW profile as a base (see next section)
[ ] implement mass conversions assuming and NFW profile, but write it in such a way as to allow any profile definition (e.g. Einasto)
[ ] test the conversions against Colossus

2. Density profiles
Halo density profiles describe where the mass is located inside of a halo. First though, a bit of terminology via an equation:

The halo density profile rho can be written in terms of the normalized density profile u, or the halo-matter cross correlation function 1-halo term xi. All of these descriptions are equivalent, but people prefer their own particular function. What we should really do is implement them once and then have routines all call the same function. My preference is that we should only be implementing correlation functions, since they are unitless, but I could see how working with density profiles would be more digestible.
Also, more often than not people are computing density profiles over a range of scales and masses. So our design should reflect this.
We should do the following to bring halo profiles in realspace into CCL:

[ ] decide which is the default representation (density profile, normalized density profile, or correlation function)
[ ] implement the NFW profile (so that mass conversions can be completed)

Then we can implement other profiles.

[ ] Einasto profile
[ ] isothermal sphere?
[ ] plummer profile?

Note for those that follow the literature, these would all constitute “1-halo” terms. The Diemer & Kravtsov model is a combined 1 and 2 halo term, so it should wait until after correlation functions are implemented.
Another note: @KuanWang-Astro implemented the NFW profile in ccl_haloprofile.c. Once we have steps 0 and 1 finished, we should return to that implementation and see if it needs updating. Kudos for taking the first leap into the great unknown :).
3. Halo number counts
Halo number counts would be the halo mass function and integrals of it. In other words, models like the Tinker et al. (2008) mass function provide a model for the comoving number density of halos (dn/dM). Equivalently, one can write the halo mass function in terms of the halo multiplicity f(M). Additional desired functionality would be integrals over the mass function over bins of mass and/or redshift.
Here is a checklist of what we would want:

[ ] Tinker 2008 & 2010 mass functions & multiplicity functions (the former calls the latter)
[ ] Press & Schecter mass functions & multiplicity functions

To do these things, we also need a fast implementation of halo peak height from mass. See, e.g. equation 3 in my halo mass function emulator paper. This is an integral over the power spectrum given some window function. For now we should go with convention and assume a spherical top-hat window function (see the wishlist later). Checkbox items are:

[ ] implement rms variance as a function of mass (i.e. sigma(M)) at fixed redshift. This is equivalent to inverse peak height
[ ] implement the derivative dsigma/dM as a function of mass (this goes into the mass function)

Right now, @villarrealas has implemented these things in ccl_massfunc.c along with the halo bias. However, I think it’s worth revisiting this implementation and modifying it. First, I think the computation the derivative of sigma(M) should be made analytic, rather than the numerical derivative in place now (ccl_massfunc.c lines 486+487). Second, it is worth pulling out the sigma(M) and its derivative out of the mass function file into its own file. This is because those quantities are used in, e.g. the halo bias, correlation functions, mass-concentration relationships, and other areas. Right now, the massfunc file is the halo-theory behemoth that must be tamed.
4. Mass-concentration
As mentioned before, under the NFW model one can describe the halo density with only two parameters (mass and concentration). People like single parameter models roughly 100% more than two parameter models, hence many people spend a lot of time developing mass-concentration relations. Thus, CCL should support them.
All jokes aside though, I think a mass--concentration file would be very beneficial. Additionally, not only should it have mass--concentration relations, but also mass--parameter relations under different models. For instance, the paper introducing the Diemer-Kravtsov profile gave fitting functions for parameters in their profile in terms of halo mass, so it would make sense to put them here.
It is likely that users will want to compute c(M) for an array of masses and/or redshifts, so we should keep this in mind when writing code.
To do items here:

[ ] identify mass-concentration relations that we should use (e.g. Bhattacharya, Duffy, Bullock, Ludlow, Child, Diemer).
[ ] pick one and implement it well
[ ] implement the rest
[ ] test them against Colossus

5. Halo bias
At large scales, halos cluster proportionally to matter. To first order, the halo bias is only mass and redshift dependent, and there exist a few models out there for the halo bias. We should implement them, since they appear in, e.g. cluster lensing, cluster clustering, HOD models, and probably more places. Also, they are very simple to implement.
Just like for concentration, users will want b(M,z) at arrays of masses and redshifts.
The to do list:

[ ] identify halo bias relations people want to use (Tinker 2010 main text and appendices, Sheth & Tormen)
[ ] implement one well
[ ] implement the rest well
[ ] find implementations to test against and do so. The cluster_toolkit has the Tinker halo bias implemented, and would be a good baseline for that.

@villarrealas has implemented some of these in the ccl_massfunc.c file, but the halo bias should be pulled out into its own file.
6. Halo correlation functions
Halos cluster. Therefore, we should implement halo-matter cross correlation functions (xi_{hm}) and halo autocorrelation functions (xi_{hh}). Thankfully, this is easy to do and we have all the tools already implemented. This is because, at small scales the halo-matter cross correlation function is proportional to the density profiles (\xi_{hm}(r,M) \propto rho(r,M)), while at large scales it is proportional to the halo bias times the matter autocorrelation function (b(M) * xi_mm(r)). The halo autocorrelation is 0 at small scales (halo exclusion) and can usually be modeled as xi_hh(r, M1, M2) = b(M1)*b(M2)*xi_mm(r).
Note: everything in the above paragraph has a redshift dependence that I’m dropping to save characters.
So, as long as we trust the Fourier transform of the matter power spectrum (which @zdu863 merged into master last year) to go from P(k) to xi(r), then we have the 2-halo term done already. It’s just a matter of putting all the pieces together.
The to-do items look like this:

[ ] implement the halo autocorrelation function
[ ] implement ways to combine 1-halo and 2-halo terms (take the max or add them)
[ ] test against the cluster_toolkit. Note that these tests would technically be superfluous, since we would already test the density profiles, halo bias, and matter autocorrelation functions themselves.

At this point it would be worth double checking that the benchmarks for xi_mm(r) are good.
7. Projected density profiles
Weak lensing and the like are measured in projection on the sky. For instance, the surface mass density (proportional to kappa) looks like

From there it is simple to go to the differential surface mass density DeltaSigma. To see these equations written out, look at section 5.1 in this paper.
Note: in the above equation the arguments would also include any other properties of the halo, like concentration, but this is obviously model dependent and would be accommodated by our implementation of how the user specifies halo definitions.
The to-do list would be the following:

[ ] implement the line-of-sight integral to go from the halo-matter cross correlation function to projected surface mass density
[ ] implement the projected radial integral to go to differential surface mass density
[ ] implement azimuthal averaging, i.e. the ability to integrate over annuli projected on the sky (this is easy)

Systematics like miscentering and reduced shear would live in Firecrown.
Note that an alternative formalism to all this is to go from xi_hm to the halo-matter power spectrum P_hm(k), and then do an inverse transform (an integral w/ a Bessel function) to get DeltaSigma directly. This was done by our HSC collaborators, and might be faster computationally. This should be explored.
Another note is that it is my opinion that since CCL is a theory-only code we should not provide the means to compute projected clustering w(theta) or gamma(theta), or anything else that requires knowledge of source/lens redshift distributions. Open for discussion.
8. Halo occupation distributions (HODs)
HOD is a prescription to put galaxies into halos. An HOD model coupled with the halo model parts described above would allow us to do galaxy-galaxy lensing directly. It’s possible that this should live in Firecrown rather than CCL, but I’d like to hear the audience’s thoughts.
The todo list would include:

[ ] identify forms of HOD models that people use
[ ] implement them
[ ] find a good benchmark to test against and make tests

9. Fourier-space versions of correlation functions & density profiles
As I alluded to earlier when I was talking about Alex’s halo-based power spectrum model, one can also compute halo density profiles in Fourier space. Essentially, the normalized density profiles can be transformed according to

I personally see this as low priority. BUT, implementing (3D) Fourier transforms of the profiles we have written in realspace is nice because it “completes the picture” and also might allow someone to build more complicated versions of the halo-based power spectrum model with different 1-halo terms (which is an actual research project).
The todo items would be

[ ] find analytic forms for some transformations and implement those
[ ] use fftlog to do numerical transforms for those that cannot be solved analytically
[ ] find benchmarks and test against them

Gorey details
IMO including the halo theory should be a milestone for V2. I think it would be a travesty to reach the LSST era and not have a proper halo theory in CCL. Nevertheless, getting the job done will result in growing pains.
New files
I think the following files should get torn up in order to be replaced by new files that are more sensibly organized:

ccl_correlation.c - the term “correlation” is too broad for what this file does. I think it should be broken down into smaller parts, or at a minimum have the 3d transform of the matter power spectrum separated away from anything done in projection. I also think anything RSD related should be pulled out and put into their own files.
ccl_massfunc.c - this file is a behemoth that does more than its name suggests. Mass functions should be isolated. sigma(M) and its derivatives should be isolated and put next to peak height. Halo bias should be isolated.

Here are my suggestions for new files that should exist and what should be put in them

ccl_mass_definitions.c - this file contains routines to do mass conversions. Also, if we go this design route, it would have the structure (an enum or whatever) for a halo definition (overdensity, mean vs crit, assumed density profile)
ccl_halo_profiles.c - this file would have halo density profiles as well as normalized density profiles. If I had my way, this file would just have wrappers that would call the corresponding correlation functions, but this can be discussed.
ccl_mass_concentration.c - this file would have mass-concentration relations as well as other mass-property relations mentioned above.
ccl_3d_halo_correlation_functions.c - this file would have correlation functions for 1-halo terms like the NFW and einasto profiles, as well as 2-halo terms that look like b(M)*xi_mm. It also has routines for combining them, so that one can call xi = xi_hm(r, M) and get back a curve that already has the 1 and 2 halo terms combined.
ccl_halo_statistics.c or maybe ccl_peak_statistics.c - this file would have the routines that compute sigma(M,z), its derivatives, and peak height.
ccl_halo_mass_functions.c - self explanatory
ccl_halo_bias.c - self explanatory
ccl_projected_halo_profiles.c - this file has all projected halo profiles described above.
ccl_fourier_space_halo_profiles.c - self explanatory

Development cycle
The hardest part of getting all this done is getting developers to work on it. The easiest way to do this is to make the development cycle easier. I’ll admit that one of the main reasons why I took a hiatus on contributing to CCL was because the process was difficult. I don’t have the skillz that the senior devs have. I think that largely thanks to @beckermr the workflow has been made easier.
Since my outline constitutes a huge addition to the codebase in CCL, it would be great if the senior devs could spend a little bit of time trying to think if the workflow suggested on the README accommodates this effort. Also, I only outlined what needs to be done on the C side. It would be good to know what would need to be done in Python to make everything work correctly.
Benchmarks
Some of the things I suggested implementing don’t have benchmarks. We also need to decide what halo definitions we make benchmarks for (since 200m is obvious, but 201m is probably not worth looking at). We should consult cluster people, especially those that work in other wavelengths, to see what definitions they would like. Off the top of my head I know we should benchmark 200m, 500c, and vir. Not sure what else.
Stretch goals
Here is a non-exhaustive list of things that would be super dope to have in CCL, but probably not worth including in the V2 benchmark

A seamless way to incorporate halo theory emulators. Things like DarkQuest and the Aemulus Project have emulators to compute various parts of the halo theory I outlined above. For instance, I have an emulator for b(M,z). In an ideal world, we implement things so that emulators (perhaps existing externally from CCL) can be hot-swapped in where appropriate.

Halo splashback, assembly bias, and other fun things that exist in simulations. These are all research topics, but some things, like splashback radii, have analytic fitting functions that could in principle be implemented in CCL. Not sure it’s worth the development time but this is the pipedream section.

Nonspherical halos. Cluster science today requires us to consider non-spherical halos, so this will be something that DESC folks will work on. It’s possible to kick this up to Firecrown, but it would be cool if we had it in CCL. I actually think this is the highest priority item out of our stretch goals.

Arbitrary window functions. Halos don’t have to be defined by a spherical top hat. We could have arbitrary window functions, like a Gaussian. This only effects the integrand when computing sigma(M) and its derivatives, so this might not actually be such a stretch goal and could be very easy to do.

Implement really tiny effects like the true critical overdensity for collapse \delta_{crit}. I think @alexander-mead already has this implemented in fortran, so it would be possible to port that over.

So, my first impression is that a lot of this makes sense, but it is going to be a substantial bit of work. The changes suggested involve pretty dramatic changes to underlying routine and probably involve disentangling a lot of routines from the cosmology object in order to allow for the mixed utilization of various parts. Thankfully, since the C API is depreciated, this may be a little easier (although our C code would become an abomination if unaltered).
Aside from that during the planning phase, a very serious concern I have is about model consistency. This is briefly mentioned in the above text, but (I believe) one of the stated goals of CCL in the early periods was to make certain that a user generating summary statistics would not accidentally create measurements that were inherently incompatible with each other. This probably motivated some of the intermediate steps for, say, the halo mass function not being publicly exposed. However, given a desire to open up more of the process from end to end as callable functions and being passed into each other, it is certainly worth considering how we are making sure any naive outputs are sane.
Aside from those two concerns that I think we need to address before settling into any extensive refactoring of this code, I think the idea is good. Unfortunately, I cannot offer time to help personally... ultimately, I think the big blocker is a halo expert who is happy coding in Python that has time to develop this out, and can put any slow pieces into the C.

We should give up on model consistency. None of our models are consistent so demanding them to be so means we ship nothing.

@villarrealas can you explain exactly what you mean by model consistency in this case, and what you mean by "inherently incompatible"?

@tmcclintock One easy to imagine case is somebody pulls halo mass function for an FOF based halo definition and then pulls halo bias for a SO based halo definition. Since they're describing entirely different objects, that could cause some severe inconsistencies.
However I should note that I am inclined to agree with Matt that ensuring model consistency for everything inside of the halo model seems like a nightmare of checks and cross-checks for something that is accurate on only the 10% level anyway in most cases.

It sounds like we are all in agreement on that. Changing goals is fine, I think.

If we want to put in major changes to the python API, we need to do it ASAP. We can't change the function signatures or locations once we release v2.
I'd be ok stripping halo stuff out of v2 so that we can add it back later.

Hi all,
sorry it took me a while to get time to get to this. Thanks a lot to @tmcclintock for starting this. I agree it's absolutely necessary for us to have a robust halo model framework for DESC.
Here are a few thoughts:

I would be more ambitious and make this general enough that you can generate halo model prediction not just for galaxies or for matter, but for any other quantity. To this end, I would make a generic HaloProfile class that can accommodate both matter profiles, galaxy density profiles and anything else (e.g. pressure, gas density, n^2*T for X-rays etc.). I would then create specific subclasses for matter profiles and galaxy density profiles. Each of these classes should return the real-space profile, the fourier-space profile and, I would argue, at least the 2nd order cumulant in fourier space (which you need to compute the 1-halo term).
I would use python as much as possible. There are certain things where C makes sense. E.g. several things to do with mass conversion, matter density profiles, mass functions, halo biases etc. since those will be used by all halo profiles. The rest, I would code up in python.
I would create a routine/class/whatever that, given two HaloProfiles, spits out a Pk2D object corresponding to the halo model prediction for the cross-correlation between the quantities described by those profiles. This way you could generate predictions for g x g, g x m, m x m, g x tSZ, m x tSZ ...

This framework would then make it easy to add functionality in CCL to compute non-Gaussian covariances, bispectra etc.
What do you think? Do we have a timeline on this? I'd be happy to start implementing this in my spare time now (we actually have coded some of this up for the HSC project in LSS with @anicola).

@tmcclintock @beckermr let me know if you have any thoughts on the above. I'd be very happy to start implementing this kind of functionality soon.

So we should decide if we want to do this work post v2 or before v2

I think it can wait until after v2 if we want to do that soon.
Tagging @elikrause

OK, so here's a concrete proposal for a possible API. Tagging the relevant people: @tmcclintock @elikrause @beckermr @elisachisari
Aims of this extension:

compute P(k,z) between any two quantities U and V using the halo model
provide functionality to compute all the intermediate quantities that go into the above:

halo mass functions
halo bias
concentration-mass relation
halo profiles

Some equations
Halo-model power spectra
The power spectrum is split between the 1-halo and 2-halo terms:

The 2-halo term reads

where  is the cross-spectrum between halos of masses M1 and M2, and  is the mean profile of quantity U around a halo of mass M1 in Fourier space.
Assuming a linear bias relation for halos, this simplifies to:

where P_L(k) is the linear matter power spectrum, and I've defined

The 1-halo term reads

Mass definitions
Now, the really tricky part is gonna be translating between mass definitions. The most common way to define halo mass is through a spherical overdensity criterion. The halo mass is defined as the mass enclosed by a sphere inside which the density is a factor  higher than the average density , where  is normally either the matter density (x=M) or the critical density (x=c):

The problem is that all the quantities above (mass functions, halo biases, halo profiles), are usually only provided for a discrete set of mass definitions , and often you don't have all the pieces you need to build a halo model power spectrum for the same definition. A typical way to get around this difficulty is to assume that use the concentration-mass relation assuming an NFW profile for all halos.
For the NFW profile, the mass enclosed within a given radius is
.
Defining the concentration parameter as  we get

and therefore the concentrations for two different mass definitions  and  are related through the implicit equation:

So, you can translate between two mass definitions as follows:

Get a concentration-mass relation for , compute  and
Solve the previous equation to find .
From  and  compute  and then .

This is not the only way to change between mass definitions, but it's the most generic one I know of. There are good reasons not to like it though. E.g. you can find that, even if you start from a concentration-mass relation that has been fit to simulations, the concentration-mass for a different mass definition you derive using this method does not actually match the one you would find from direct fit to simulations with this new mass definition. For this reason I propose making the interface generic enough that other ways of translating between mass definitions can be supported in the future.
Specific API proposal
The API will come in the form of the following classes and functions.
Mass definition
The MassDef class will look as follows:
class MassDef(object):
    def __init__(self, Delta, dens_type, c_m_relation=None):
        ''' Store Delta and dens_type (where dens_type is either 'matter' or 'critical').
           These two define this mass definition.
           If c_m_relation is provided, it would be a string that defines one of a set of
           concentration-mass relations we should support. If not provided, then an
           error will be raised if the `get_concentration` or `translate_mass` methods
           below are called.
        '''

    def get_concentration(self, M, z):
        ''' Return the concentration for a halo of mass M at redshift z'''

    def translate_mass(self, M, z, m_def_other):
        ''' Return the mass under definition `m_def_other` for a halo of mass M (under
           the current mass definition) and redshift z. `m_def_other` should be
           another `MassDef` object defining the output mass definition (which doesn't
           need to have an associated c-M relation).
        '''

There is key functionality that should live in C here. In particular, we want the non-linear equation solver that translates between c-M relations to be as fast as possible. Other possibly useful methods would be get_radius(M,z) and get_mass(R,z).
Mass functions
class MassFunc(object):
    def __init__(self, mf_parametrization, mass_def):
        ''' This defines a mass function. `mf_parametrization` will be a string that determines the
           mass function parametrization to use from a set of parametrizations we need to support.
           Alternatively, we can support generic mass functions (a la generalized Pks), but this
           can be discussed later. `mass_def` is a `MassDef` object defining the mass definition
           to use for this mass function. An error will be thrown if the chosen parametrization
           does not support this mass definition.
        '''

    def multiplicity_function(self, M, z, mass_def=None):
        ''' Return multiplicity function for a halo of mass M and redshift z. The mass would
           correspond to mass definition `mass_def`. If `mass_def` is not provided, it is
           understood that the mass definition is the same one that this `MassFunc` object was
           initialized with. Otherwise, unless the mass definitions coincide, `mass_def` should
           be able to translate masses into this object's mass definition.
        '''

    def mass_function(self, M, z, mass_def=None):
        ''' Same as above for the mass function'''

Things that should live in C: sigmaM and dsigmaMdlnM splines  (as they are right now). Possibly some of the halo mass function parametrizations if they require a lot of interpolation. Emulators?
Halo bias
Same structure as the mass function, but for the halo bias.
class HaloBias(object):
...

Halo profile
class HaloProfile(object):
    def __init__(self, mass_def, name):
        ''' Initialize a given halo profile. We need to provide a mass definition and a
           name (for bookkeeping).
        '''

    def profile_r(self, r, M, z, mass_def):
        ''' Return the mean profile at comoving distance `r` from the halo centre. M, z
           and mass_def are the same as those passed to `MassFunc.multiplicity_function`.
        '''

    def profile_k(self, k, M, z, mass_def):
        ''' Return the mean Fourier-space profile at comoving wavenumber `k` from the
           halo centre. M, z and mass_def are the same as those passed to
           `MassFunc.multiplicity_function`.
        '''

    def profile_squared_k(self, k, M, z, mass_def):
        ''' Return the second-order moment of the Fourier-space profile at comoving
           wavenumber `k` (i.e. the quantity that goes into the 1-halo term). By
           default this would just be the square of the mean profile.
        '''

    def profile_norm(self, M, z, mass_def):
        ''' Return the k->0 limit of the Fourier-space profile (or, equivalently, the
           volume integral of the profile.
        '''

The idea would be to make it possible for people to code up their own halo profiles that inherit from this class (e.g. to include profiles for any other quantity), but we should provide a few basic ones (e.g. NFW, Einasto, anything else CL want).
Halo-model power spectra
The following set of functions should be supported:
def mean_field(z, profile, halo_bias, mass_function):
    ''' Return the k->0 limit of I^0_U (defined above) at redshift `z`. This
       correspond to the halo model prediction for the mean value of the
       field U. `profile` is a `HaloProfile` object, corresponding to the
       quantity U. `mass_function` is a `MassFunc` object and halo_bias is
       a `HaloBias` object.
    '''
def large_scale_bias(z, profile, halo_bias, mass_function):
    ''' Return the k->0 limit of I^1_U (defined above) at redshift `z`.
       `profile` is a `HaloProfile` object, corresponding to the quantity U.
       `mass_function` is a `MassFunc` object and halo_bias is a `HaloBias`
       object.
    '''

def scale_dependent_bias(k, z, profile, halo_bias, mass_function):
    ''' k-dependent version of `large_scale_bias`. '''

def pk_hm_1_halo(k, z, profile1, mass_function, profile2=None):
    ''' 1-halo power spectrum term for the cross-correlation between
       the quantities represented by `profile1` and `profile2`. If
       `profile2` is `None`, then this will compute the auto-correlation
       of `profile1`.
    '''

def pk_hm_2_halo(k, z, profile1, mass_function, profile2=None):
    ''' 2-halo power spectrum term for the cross-correlation between
       the quantities represented by `profile1` and `profile2`. If
       `profile2` is `None`, then this will compute the auto-correlation
       of `profile1`. This function could be extended with more optional
       arguments if we want to use emulators of the halo-halo power
       spectrum.
    '''

def pk_hm(k, z, profile1, mass_function, profile2=None):
    ''' Wrapper for 1-halo + 2-halo power spectrum'''

This could be extended to compute all integrals of the form I^n_{UVW...}, (e.g. for bi-spectra etc.) but not necessarily right now.
I am not sure this functionality needs to be wrapped into a class, but maybe it makes sense to do so (e.g. if we want to pass halo-model-specific precision parameters for the mass integrals etc.).

Alright, everything to do with mass definitions, n(M), b(M) and c(M) has been solved in #688
Left to do:

profiles
halo model power spectra


Clarify and fix up metric-imperial user stories

The user stories on the metric imperial converter should use "you" instead of "me". There could also be some clarification to the expected output as discussed here. Note that the linked PR is not in production as of this post. We should also update the description to what is described here, along with anything else mentioned there.

The user stories on the metric imperial converter should use "you" instead of "me".
I belive it's written that way, beacause that's the way users usually express their request. "I want to do this... and that... I want the app to use this color..."

Heya @haragona - we actually try to maintain the second-person perspective for user stories across our projects, and recently updated the back-end project pages to match this. 🙂
@moT01 I've got #40358 open to move the tests from the boilerplate to the /learn page - I could hit the "me" => "you" verbiage in that PR?

Might as well @nhcarrigan?


Change Markdown files to match Github's expectations

Github expects the SECURITY_DISCLOSURE.markdown file to be called SECURITY.markdown.
The code-of-conduct should be moved out of CONTRIBUTING.markdown and put in a dedicated file.

I believe that this issue can be closed by #15 and #17.


version 2.0

The version should address inconsistencies with how dataPaths are reported in errors and also expose in properties of error objects information that is currently only available in error messages (without the need to use i18n option).

[x] additionalProperties should have dataPath at the parent level, not additional property level (revert the change in #11). - WONTFIX
[x] possibly, report all additional properties in a single error with the array of properties available in error. To make it more backward compatible, the old (current) behaviour can be still available with some option. WONTFIX
[x] required should have dataPath at the parent level, not missing property level (revert the changes in #18 and #55). WONTFIX
[x] possibly, report all missing properties in a single error with the array of properties available in error. WONTFIX
[ ] add additional property to error object with missing and additional properties and other parameters that are only available with i18n option now. Probably it can still be called params as it is now. EDIT: with params option
[ ] address the issue with dependencies (#68). There should be only missing dependency (for property dependencies) in the error, not all required. In {allErrors: true} mode there should be a separate error for each missing dependency. EDIT: dataPath should point to the property in dependencies keyword.
[ ] document properties of error objects for all validation keywords
[ ] update the messages in ajv-i18n accordingly
[x] EDIT: custom keywords via user supplied functions.
[ ] macro custom keywords
[ ] inlined custom keywords

Any plans also to add possibility to specify

custom messages
custom validation functions which can validate property based on values of other properties ?

The use case is to to use validator not only on backend but also in frontend. So defining custom messages is really a nice feature (defining different messages even for the same keyword but for different properties).
Cheers

@jsdmc You can create custom messages with ajv-i18n I think. It's a bit clunky as you either need to fork or to supply functions rather than templates, I'll think how to improve it. Also you can generate any messages you want from available information in error objects - at the moment you have to use a18n option to have additional info in errors.
Re custom validation functions I am kind of fighting this trend :), in a losing battle I should admit. I still tend to believe that it is much better to keep all custom validation outside of JSON-schema to preserve schema compatibility and portability. When you add custom keywords your JSON "schema" is no longer a JSON-schema... But many people seem to want it anyway. So maybe I will do it. No asynchronous validation though at least for now :)

Yeah, I already played a bit with this repository. But I must admit for now creating custom messages looks a bit messy because you have to handle all keywords and other params. For example, for displaying in UI nice message ('Please select correct date format') that corresponds to 'format' keyword you have to create 2 matchers - 1 for processing keyword and second for possible format values
```javascript````
format: {
en: 'should match format "{{=e.params.escaped}}"'
}

Regarding custom messages - it's just nice to have all validation declared (including validation based on few fields)  in one place using one tool)

Thanks

@jsdmc custom keywords are available in version 2 (npm install 2.0.0-beta.0 to use them).

@epoberezkin is the function registered for custom keyword synchronous and have to return a boolean to indicate it is valid?  What is this parentSchema that I can access as 3 parameter?  I build each key of my schema with z-schema from a definition so I can reuse each piece, will this help me?

is the function registered for custom keyword synchronous and have to return a boolean to indicate it is valid?

Yes, it is in readme I think... Maybe not, I will add then. It can also return custom errors by assigning array of errors to .errors property of validation function (whether supplied in definition or returned from compilation function). If it doesn't, the standard error will be used when the validation fails.

What is this parentSchema that I can access as 3 parameter?

See the example for range in exclusiveRange keywords. Inside the function for range keyword you may want to access parent schema to change it's behaviour based on some other keyword on the same level. Many standard keywords use the same logic.

I build each key of my schema with z-schema from a definition so I can reuse each piece, will this help me?

I don't understand... Some example may help


Check if exists when the first fragment is added

Description
Check if exists when the first fragment is added
Test
All passed.
Coverage
No changes

LGTM


fix stric-aliasing warning

Before: http://ci.ros2.org/view/nightly/job/nightly_linux_release/6/warnings17Result/
After: http://ci.ros2.org/job/ci_linux/1091/

+1. btw, I believe those additional test failures will be fixed by ros2/examples#94 and ros2/rclpy#6, which I merged after you launched those jobs.


All pods in NS crashed with Tap

Description
All pods in the namespace of the pod I tapped started tripping out. Some time after I ran the command to tap my pod, random pods in the same namespace started failing and restarting. It didn't do this right away, it started happening an hour or so after I left the tap on, i.e. after I was done sniffing some headers, I didn't do kubectl tap off my-service. Not only did pods start failing, entire nodes started getting tainted with NoSchedule which in turn caused the cluster autoscaler to overwork itself replacing failed nodes over and over.
Kubectl commands to create reproducable environment / deployment
First off, when I ran the initialize command, it would always complain the tap took too long and didn't immediately port-forward on it's own.
Here is what I ran.
kubectl tap on -n my-ns -p 4000 my-service --port-forward

Then because the port-forward didn't activate because of timeout, I ran:
kubectl port-forward svc/my-service 2244:2244 -n my-ns

Then I did my sniffings then killed the port-forward, but did not turn off the tap.
Leaving that extra container in one pod seemed to cause all hell to break loose in the namespace.
As soon as I turn it off, everything went back to normal.
Screenshots or other information
Kubernetes client version: 1.17
Kubernetes server version: 1.17
Cloud: AWS EKS
One thing to note is we have Appmesh Auto-Inject active on the namespace. Not all pods in the NS are injected with Appmesh, however the pod I injected with tap was also injected with Appmesh. This means the pod had an X-Ray sidecar and an Envoy sidecar already present when I injected the tap. Maybe this was part of the issue?

Hi @kferrone, sorry you encountered this issue. Have you been able to reproduce the issue, by chance? Do you have a set of manifests I could apply to a local cluster to reproduce on my end?
It's possible that kubetap's interaction with the other sidecars is causing the problem. Kubetap deploys the mitmproxy sidecar and then essentially sed's the Service port, replacing the target port with the mitmproxy sidecar port. The mitmproxy sidecar then forwards the traffic to the original port. It stores the original port value as an annotation. It is therefore very possible that there is an unfavorable interaction with X-Ray/Envoy.
If you could provide instructions to reproduce this issue, I'd be happy to take a look.
If you're interested in debugging this on your own, I suggest looking at the tap.go file here.
Thanks for filing this issue!

First off, when I ran the initialize command, it would always complain the tap took too long and didn't immediately port-forward on it's own.

Just to comment on this, the timeout can occur if the Deployment is taking a while to init. That is to say, if the node needs to download an image and blow-up the container to be run, sometimes this can cause the timeout to be reached if the image is large.


Deprecate onm.Namespace.fromData/fromJSON API's

Both methods effectively automate component remove, component create. With an arbitrary data object used on the component create path.  Always was. So these methods should be deprecated in favor of a new API, onm.Namespace.applyData that leverages the new namespace resolver infrastructure for doing data merging. Use of these API's is limited, I believe, to a couple modules I wrote so nobody is going to miss them. Client code will need to be changed to manually call onm.Store.removeComponent and onm.Store.createComponent in cases where it doesn't make sense to simply use onm.Namespace.applyData.

Fixed in forthcoming v0.3


Could not connecto to repository

Hello,
i transferred the repository to my libreelec kodi installation, installed manually the repository. When i try to access the repository to install the addon it gives me the error with the error message "Could not connect to repository."
Thanks
Ervin

If you’re using kodi 11 it won’t work, there’s a defect open. If you’re on 10, share a log and I’ll take a look

On 13 Sep 2022, at 20:44, darzu84 @.***> wrote:

Hello,
i transferred the repository to my libreelec kodi installation, installed manually the repository. When i try to access the repository to install the addon it gives me the error with the error message "Could not connect to repository."
Thanks
Ervin
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Hello,
sorry it was my bad, i had some connection issues on my rpi2 btw i am using kodi 19.4 and the repository id working.


I'd like to have post images downloaded/duplicated to the assets directory

...so we're not dependent on fb/insta servers for displaying them. I think this was supposed to be working already(?) but it didn't in my initial testing, not sure.
Anyway, this behaviour of downloading to assets is probably not desirable per fb/insta API user agreements so it would be good to make it optional, configurable by a config flag.

Images are being save locally on each MediaInput Object and can be accessed via many_many Images() relationship. The current template is using $ImageURL which should change to $Images.First of <% loop $Images %>


Implement #89 for khal

Implemented highlighting of days with events in khal calendar display.
Fully configurable - foreground/background highlight, multiple colors for one day, defaults.
Not supported: "light"/bold colors. Right now the implementation just strips dark/light from the color name. Will add that later.

It doesn't look elegant at all, but it should be ok. Again, any suggestions are welcome.

Do we really need to make every single detail of this configurable? The added complexity is staggering...

As noted in the #89 - it is an open question how exactly should the days with events be represented. Making it fully configurable seems to me the best approach. And also I find it pretty straightforward to implement.

Maintaining the additional code is another story...

I had a look, gave it a try, like it and do think this will be a valuable addition to khal (I believe it has been the most sought-after feature). I do have a small nit-picks I'll add as comments.
Furthermore while I do like the customizability and I think we should add it like it is for the moment I believe we should than ask the users what they use and strip out the options nobody uses (def. not now, but before we hit a 1.0, if that ever is the case), just to keep the code base small. On the other hand, if somebody other than me is willing to maintain it (you?) I don't have a problem with it either.

Oh, and could you add yourself to AUTHORS.txt, please?

UTF-8 or ASCII only?
There's this ů and č in y name :)
On 10/01/2015 10:32 PM, Christian Geier wrote:

Oh, and could you add yourself to AUTHORS.txt, please?
—
Reply to this email directly or view it on GitHub
https://github.com/geier/khal/pull/271#issuecomment-144839293.

On 10/01/2015 10:25 PM, Christian Geier wrote:

I had a look, gave it a try, like it and do think this will be a
valuable addition to khal (I believe it has been the most sought-after
feature). I do have a small nit-picks I'll add as comments.

Tried to resolve all of them.

Furthermore while I do like the customizability and I think we should
add it like it is for the moment I believe we should than ask the
users what they use and strip out the options nobody uses (def. not
now, but before we hit a 1.0, if that ever is the case), just to keep
the code base small. On the other hand, if somebody other than me is
willing to maintain it (you?) I don't have a problem with it either.

No problem maintaining it. I'm kind of used to maintaining various
things for longer than a decade. However I'm not a python person - so be
patient with me :)

Quoting Dominik Joe Pantůček (2015-10-01 22:43:57)

UTF-8 or ASCII only?
There's this ů and č in y name :)

UTF-8 is good, if it breaks anything it needs to be fixed (the tool, not
your name).

Quoting Dominik Joe Pantůček (2015-10-01 22:57:43)

However I'm not a python person - so be
patient with me :)

Sure!  I found
it strange when getting into the python ecosystem, but now I'm so used
to it, code just looks wrong otherwise.

@dzoep Thx! From my point of view, this is good to merge. What do you say?

Let's merge it and I'll continue with ikhal and request another pull when that part is ready.

Done. And thank you again!


refactor: separate message dequeueing from publish method

Modifies the queuing implementation to clear the queue upon leaving the suspended state
Adds a test fixture for publishing before/during/after suspension

I'm not exactly sure what the purpose of this PR is

Modifies the queuing implementation to clear the queue upon leaving the suspended state

Why do we clear the queue? The whole point of the main queue is to maintain and republish messages (from sink records) while the connection was suspended. The existing implementation queues when the connection is in suspended state and dequeues when connection is back while connection is not suspended.

@ikbalkaya By "clear the queue" I meant dequeueing all the records from the queue, not discarding the messages, sorry I should have worded that part better.
As far as I can tell the implementation in create_intermediate_queue_to_publish_failed_messages only clears the queue once a message has been published, so if you publish a message while suspended and then don't publish another message after connection is re-established then the queue will never be dequeued.
As for the other changes in this PR, the new tests ensures that messages are dequeued upon leaving the suspended state and there were comments on this PR about improving synchronisation/avoiding race conditions which I also addressed.


Remove slider quick wins

Without switching to new component some quick wins addressing #196 to make the slider a bit more bearable:

Address main pain point: turn the maximum % display into a max button:

Make custom slider styles appear in Chrome too

Majority of weirdness on simple screen comes from the multiple calls happening when slider is moved, and then when multiple values are updated in component, effects fire too often while the calls are still running, all leading to this number sluggishness when moving the slider.

Addressed this a bit by splitting up and reducing the effect usage and doing more directly in the onChange handlers.

And finally split up that method with the 4 pool calls, this was blocking getting amountOcean, the displayed value in UI. All not perfect but a bit better before we switch to some other component.

alright, finished like 20 tests with this in different amountMaxPercent combinations and I'm mostly sure everything works. All a bit more snappy and the max button alone feels like a huge improvement for that user flow, so we can get this out

Something is wrong with the pool, same asset on this branch and on main

Debounce was not actually working, it worked only for the first call. Did multiple tests with useCallback, throttle and debounce and finally I found this. He is actually right, I did the tests.
A downside is that you have to pass as params the values that change, I added only amountPoolShares and isAdvanced since the rest don't change

wow, what a weird trick, good find!


Modify the schema with a new Regimes table

Add a new Regimes table.  Attempt to make it a reference table that constrains the regime entries in the SpectralTypes and Spectra tables.
Link to relevant issue: #271 , #460

If I load the new schema, I can make a new database connection, but when I try to save it, I get this error:
>>> db.save_database("data/")
Clearing existing JSON files...
0it [00:00, ?it/s]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/kelle/miniforge3/envs/simple-db/lib/python3.9/site-packages/astrodbkit2/astrodb.py", line 754, in save_database
    self.save_json(row, directory)
  File "/Users/kelle/miniforge3/envs/simple-db/lib/python3.9/site-packages/astrodbkit2/astrodb.py", line 699, in save_json
    data = self.inventory(name.__getattribute__(self._primary_table_key))
  File "/Users/kelle/miniforge3/envs/simple-db/lib/python3.9/site-packages/astrodbkit2/astrodb.py", line 421, in inventory
    self._inventory_query(data_dict, table, name)
  File "/Users/kelle/miniforge3/envs/simple-db/lib/python3.9/site-packages/astrodbkit2/astrodb.py", line 388, in _inventory_query
    column = table.columns[self._foreign_key]
  File "/Users/kelle/miniforge3/envs/simple-db/lib/python3.9/site-packages/sqlalchemy/sql/base.py", line 1556, in __getitem__
    return self._index[key][1]
KeyError: 'source'

I made a bunch of changes to the tests by implementing a conftest.py to initiate the test databases. @dr-rodriguez , could you take a look?
I also don't know how to make the ParallaxView test work.
Once #470 gets merged with the cleaned up regimes, I'll try (again) to make the Regimes table a Foreign Key on the Spectra and SpectralTypes tables.

Not sure why I needed to add the home directory by hand to the paths, but it made the github tests pass!


Added rvsteel_mtimer to the SoC + Example

To quickly check, change the makefile in SoC sim:
FIRMWARE   = $(RVSTEEL_ROOT)/demos/examples/mtimer/software/build/mtimer.hex
RUN_CMD +=--cycles=1000000 --host-out=0x80000000

I have an idea to write cmake for build and change some things, I'll try to do that next time.

I thought a little more, it seems I was wrong when I suggested separating boards and examples :(
Perhaps I will be wrong again, but maybe we need to combine them?
For example like this (in demos):
arty_a7_hello_world/
arty_a7_mtimer/
arty_a7_gpio/
cmod_a7_hello_world/
soc_sim_mtimer/

Ok. I can offer one more option, but I’m not sure which is better)
demos
  +--hello_world
  |    +--arty_a7
  |    +--cmod_a7
  |    +--tang_nano_20k
  |    +--soc_sim
  |    +--software
  |
  +--mtimer
       +--soc_sim
       +--software


CS Audit, Lime 170, Added description of the return value

Description
Return value of SavingsAccount.transferFrom lacks description
Change Log
Natpsec comment of SavingsAccount.transferFrom was improved.

Codecov Report

Merging #258 (995aa5d) into v1-alpha (2230ce8) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           v1-alpha     #258   +/-   ##
=========================================
  Coverage     78.40%   78.40%
=========================================
  Files            16       16
  Lines          1681     1681
  Branches        310      310
=========================================
  Hits           1318     1318
  Misses          363      363

Impacted Files
Coverage Δ

contracts/SavingsAccount/SavingsAccount.sol
66.66% <ø> (ø)

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 2230ce8...995aa5d. Read the comment docs.


Use spacer in title row

Hi,
I have a layout issue using your wizzard (cool project!). I debugged into it and it seems that the width calculation of the title is causing the problem. I think you can easily use a Spacer() in the header row. It renders the same way but removes the layout problem on my setup.

Please merge this!

Thanks @chrallard for your contribution. Your PR has been merged


memory problem

hi, thanks for sharing this fantastic emoji rating. I used it , but i occurred a memory problem. when it load the view the memory would rush to 270M, and then it will crash on 1g ram device. how could i solve this problem, thanks?

I will fix it ! Thank you !

@rickysou I have fixed the memory problem in the new version 0.1.6. You can try it :)

great thanks for your work. i test it on iPhone memory cost 196m , it is good. but test on 1g ram device(ipod 5) still crash,,,you test on 1g device, it runs fine?

I created 100 EmojiRateView instances like this:

I have tested it by creating 100 EmojiRateView instances in TTGEmojiRate Demo like this:
for i in 0...100 {
    let tmp = EmojiRateView.init(frame: CGRectMake(20, (CGFloat)(i * 10), 200, 200))
    self.view.addSubview(tmp)
}

It only cost 7.1MB memory on my iPhone 6.
So maybe it's some other reason that lead to your memory problem. :)

wow, i will check that. if so, really sorry for troubling you

You are welcome. :)


Issue to track development of Terminal User Interface in Yast

Changed branch name from bubbletea to tui for better context.

After the review is done, we are ready to move on to different View Models for yast. For now, we can discuss the approach of whether to develop each model separately and handle integration between each model later or do both at the same time.

Integrations might pose a different challenge. Will have to use sync library to handle different views as we can consider the rendering of each view as a different process. But lets discuss on that in our next meet up. @tiklup11

Rather the running a separate process for each model view, we can try to handle it internally by creating a stack of the Rendered Views.

Just writing it out here. Details can be mentioned in docs.

I think rather than having one issue to track development of tui. We should break it down.
We can do naming like tui-* or scraper-* or bug-*`  for branches and keep the issue titles descriptive.
Also we need should make initial issue comment more descriptive.