How do classifiers work?

Thanks for your repo!
I'm working on a dataset with a hierarchical multi-label structure, the depth is only 2: rootnode -> node1 -> node2.
I read your evaluation code. I found it in the paper you mentioned, it does make sense to me.
But I'm curious about how the classifiers work or they are just like their names?
Could you share some references or anything related to it?
Thank you,

Hi @reobroqn,
It is a great question. I am currently writing more documentation and I will be explaining there how the current implementations work. I will let you know once I release the new documentation on read the docs.
Kind regards,
Fabio

Hello @reobroqn,
I finally finished updating the documentation. Here are the explanations on how the classifiers work: https://hiclass.readthedocs.io/en/latest/algorithms/index.html
Please, let me know if anything is not clear so I can improve the documentation.
Kind regards,
Fabio

Hi @reobroqn,
I am closing this issue, but again please let me know if anything is not clear on the online documentation at https://hiclass.readthedocs.io/en/latest/algorithms/index.html so I can reopen the issue.
Kind regards,
Fabio


Link correction

Update the link to the SDK download to the actual doc where the download links live

Hi @TheBeardedLlama, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no contribution license agreement is required at this point. Real humans will now evaluate your PR.

TTYL, AZPRBOT;

@TheBeardedLlama - can you merge the patch I submitted to your fork?

apologies!
I did not check for link format :(

Not your problem! Thanks for calling it out and fixing.

...and sorry for not forgetting to do a squash... I take it you would have preferred that?

We aren't sufficiently git-sophisticated to do that as a general practice yet  :)


Error attempting to merge large files.

>>> ls -la -h addresses_area.geojson
-rw-r--r--  1 s30226  staff   272M Aug 27 19:20 addresses_area.geojson

>>> ogrinfo addresses_area.geojson
ERROR 4: GeoJSON Driver doesn't support update.
Had to open data source read-only.
INFO: Open of `addresses_area.geojson'
      using driver `GeoJSON' successful.
1: OGRGeoJSON

>>> geojson-merge addresses_area.geojson
buffer.js:488
    throw new Error('toString failed');
    ^

Error: toString failed
    at Buffer.toString (buffer.js:488:11)
    at Object.parse (native)
    at /usr/local/lib/node_modules/geojson-merge/geojson-merge:6:17
    at Array.map (native)
    at Object.<anonymous> (/usr/local/lib/node_modules/geojson-merge/geojson-merge:5:65)
    at Module._compile (module.js:413:34)
    at Object.Module._extensions..js (module.js:422:10)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Function.Module.runMain (module.js:447:10)

toString failed seems to be coming from this: https://github.com/nodejs/node/issues/3175.
Any ideas how I can work around this?

@garnertb I used something like this to concat large GeoJSON:
https://gist.github.com/drewbo/e6fcc6958571e2fb6b3823c7aafcefd2
@tmcw any desire to see this added or worth abstracting as another module?

💭  That's a clever approach @drewbo! My only reservation related to replacing the logic of this module completely is that we currently use geojson-normalize to allow people to merge a Feature and a Feature, or a FeatureCollection and a Geometry, etc. I always want to rally for 100% "all the things GeoJSON can do" compatibility rather than assuming FeatureCollections at the top level.
geojson-stream doesn't normalize and probably can't, without adding a lot of complexity (or, idk, there's probably a way that streaming-data-pros know and I don't).
Maybe we should add big-files mode as an option to the CLI so that people can get flexibility on small data and performance on large?

Very good point. I'll like the idea of a --big flag which only accepts FeaturesCollections and letting the base module retain the flexibility that comes with normalization. I'll push a small PR in a few to get things started

Fixed in 409bff784e5419ebf0126b1722f1f73bf90fa223


JS: Do not recursively import javascript into DataFlow:: scope

This PR puts a stop to recursive imports of javascript.qll in DataFlow, through paths like:
// javascript.qll
import semmle.javascript.DataFlow

// DataFlow.qll
module DataFlow {
  import Nodes
  import Sources
  import TypeInference
  import Configuration
  import TrackedNodes
  import TypeTracking
}

// Nodes.qll
import javascript

So no more shenanigans like
import javascript

from DataFlow::DataFlow::DataFlow::DataFlow::DataFlow::DataFlow::DataFlow::Node node
select node

More importantly, DataFlow::InvokeExpr no longer works, which should help to avoid confusion regarding what's actually part of the data flow library.
Currently the AnalyzedNode hierarchy is still exposed through DataFlow:: which isn't a huge problem as these classes are subclasses of data flow nodes.

Blocked on https://git.semmle.com/Semmle/code/pull/33268

Looks like my cookbook changes didn't make it into the migration, so now it's blocked on https://github.com/Semmle/ql/pull/1634


RuntimeError: merge_sort: failed to synchronize: cudaErrorIllegalAddress: an illegal memory access was encountered

When I run pytorch/testtest_octree_trilinear.py, the error occurs:
Ran 1 test in 1.483s

FAILED (errors=1)

Error
Traceback (most recent call last):
  File "/media/brl/dataDisk/WangRuowei/3d_2021/O-CNN/pytorch/test/test_octree_trilinear.py", line 13, in test_forward1
    linear = ocnn.octree_trilinear(data, octree, depth, depth + 1)
  File "/home/brl/anaconda3/envs/pt190_py37/lib/python3.7/site-packages/ocnn-1.0-py3.7-linux-x86_64.egg/ocnn/modules.py", line 286, in octree_trilinear
    output = octree_trilinear_pts(data, octree, depth, xyz)
  File "/home/brl/anaconda3/envs/pt190_py37/lib/python3.7/site-packages/ocnn-1.0-py3.7-linux-x86_64.egg/ocnn/modules.py", line 271, in octree_trilinear_pts
    output = torch.sparse.mm(mat, data)
  File "/home/brl/anaconda3/envs/pt190_py37/lib/python3.7/site-packages/torch/sparse/__init__.py", line 91, in mm
    return torch._sparse_mm(mat1, mat2)
RuntimeError: merge_sort: failed to synchronize: cudaErrorIllegalAddress: an illegal memory access was encountered

The code has been tested before release.
What's your PyTorch version and Cuda version? It seems that the error is caused by the sparse matrix product of PyTorch.

pytorch 1.9.0
cuda 11.1
GPU RTX 3080

I have not thoroughly tested the code with pytorch 1.9.0. Please follow the instructions in our readme file and try the code with pytorch-1.7.0.

Thanks, I will try it.


Unknown receiver 'FlutterNumberCaptcha'; did you mean 'FlutterNumberCaptchaPlugin'?

Hi Lustea00, I have Semantic Issue in IOS for flutter_number_captcha,

I looking forward to receiving your reply.

hi @tranphuc269, thank you for your report
fix already uploaded in new version


[Request] Support Foundry projects out of the box

It seems like hardhat projects work out of the box, where the addon doesn't seem to have an issue tracking down dependencies.
As Foundry is getting more popular, at least for the work I do, it would be nice to have equal support for Foundry, so that I don't have to do a lot of manual steps to get imports to resolve.

I am not very happy with the way Foundry chose to resolve "external" imports - remappings. Remappings can get complicated or even counterintuitive in some cases. With other projects (external dependencies stored in the node_modules directory), the situation is easier. We can just add node_modules to the include_paths config (i.e., paths where to search for non-relative imports) - the rest of the import path reflects the actual path in the filesystem, and everything works fine. This is not the case for Foundry remappings, where imports do not reflect the path in the filesystem. Because Foundry remappings are specific for every project, we cannot include a simple default config option to make it work out of the box. Still, we would like to include at least some support for Foundry.
To make imports in Foundry projects work:

we should overwrite VS Code workspace settings of woke.compiler.solc.remappings with the output of forge remappings

we don't want to overwrite users' settings without their knowledge
instead, we would like to implement VS Code command "Import Foundry Remappings" that can be manually executed by a user

I had a chance to work with a Foundry project where forge remappings does not print all the remappings needed (the project does not compile with this remappings) - we can do nothing about that
we will have to guess the location of the forge binary - it is not stored under a common path like /usr/bin
as a fallback, we can try to read remappings.txt file in the workspace root directory

however, the file name does not seem to be standardized and the file does not seem to be included in every Foundry project

Yeah, I understand. What I've done in the interim is used a combination of the woke.compiler.solc.remappings and symlinks in the filesystem to deal with projects developed in hardhat and thus using the @ notation for imports.

I think manually importing remappings from foundry.toml into the woke.compiler.solc.remappings and letting the user address any lingering missing imports is the best bet. This way, you don't have to worry about the location of forge and the user will get the preponderance of the imports, enough that the leftovers won't be that bad.

Turned out to be easier to guess the location of the forge binary than parsing foundry.toml. I think we would have to process all foundry.toml files recursively in subdirectories. As a fallback, we try to read remappings.txt in the workspace root. The command Tools for Solidity: Import Foundry Remappings is available in version 1.4.0 (released just now, should be available soon on the marketplace).

Just wanted to say that I had the chance to try this just now, and it worked perfectly. Thanks again for adding it!

Could another approach be to have a CLI flag for the LSP that tells it to dynamically import Foundry remappings on initialization, rather than having a separate command to update a static config?


add support for refreshing a grouped security update

Forgot to add support for this in #8331

I just noticed using the CLI it's creating a new PR instead of updating the existing one because the data is coming as existing_pull_requests instead of existing_group_pull_requests. This is because currently for grouped security updates the group is ephemeral.
It's a quick fix in dependency_change to look there instead when it's a group, so I'll do that.

LGTM


Setup Continuous Monitoring For Core Web Services

💡 Description

[x] Website
[x] planetarydata.org
[x] Legacy Registry
[x] Search API

🧒 Sub-tasks

https://github.com/NASA-PDS/monitoring/issues/16

New GitHub repo created for monitoring: https://github.com/nasa-pds/PlanetPatrol/


roller skates ahould be obtainable

They're in the toy box orderable at cargo (ie. they already are obtainable)

Also obtainable in maints lockers

oh ok sorry


feat: conditional block row actions

Description
We have a use case where we want to have a condition where some users should be able to add/remove/reorder block rows. While other users should just be able to change the content inside the block rows.
I have made the change by adding a new condition to the Block called accessRowActions.
If this condition is not present or returns true, it will work like it does now and allow all access to row actions.
If the condition is present and returns false, it will disable the viewing of these actions in admin UI.
When this condition is not present or true:

When this condition is present and false:

[X] I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

[X] New feature (non-breaking change which adds functionality)
[X] This change requires a documentation update

Checklist:

[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Existing test suite passes locally with my changes
[ ] I have made corresponding changes to the documentation

Note that this is my first contribution to Payload, so please be friendly :)
Also the tests and documentation is not done yet. When I get some feedback on the initial work I will tackle that next.

Closing this. It's not very useful, missing tests, has bad naming, has conflicts and is against v2.


Prevent Float32Array undefined error on missing typed array support.

Fix for missing typed array support in old browsers.

Thanks!


Styled Components Props suggestion not showing up

This might be already addressed, but couldn't find the solution. I am styling simple heading component. I am following two different approach:
Approach 1:
export const StyledHeading = styled.h1.attrs({
  "data-component": "HEADING",
})<HeadingProps>`
  color: ${(props) => props.color};
`;

Approach 2:
export const TestHeading = styled(({ ...props }) => (

))<HeadingProps>`
  color: ${(props) => props.color};
`;

Consuming like this:
export default function App() {
  return (

Hello CodeSandbox

Start editing to see some magic happen!

      <TestHeading> Test</TestHeading>
      <Divider />

  );
}

Both works as expected, but Approach 1  shows the suggestions of the props available but not the second approach.
"react": "18.2.0"
"react-dom": "18.2.0"
"typescript": "5.4.5"
"styled-components": "5.3.11"

Here is the Code sandbox
https://github.com/user-attachments/assets/cd279b13-216f-4dc0-abfb-4a59d11e20c4

Updated the above solution with :
Approach 3
export const ThirdHeading = styled(({ ...rest }: HeadingProps) => (

))`
  color: ${(props) => props.color};
`;

Just wondering whats the best practice ???

The easiest way to handle this in my opinion would be to pass the HeadingProps interface directly as a generic type parameter and let TypeScript interpret the prop.
export const TestHeading = styled.h1<HeadingProps>`
  color: ${(props) => props.color};
`;

If you want to use the add the data-component, you can use the .attrs method like you did in your first solution:
export const TestHeading = styled.h1.attrs({
  "data-component": "TestHeading",
})<HeadingProps>`
  color: ${(props) => props.color};
`;


[Bug]: Intermittent Internal Server Error when deploying a workflow

This appears sometimes but, workflow deploys when we click on deploy again.

Not able to reproduce this issue on my Local.
Also, the logs related to the previous error aren't present on Mezmo anymore.
Slack thread

For the moment, closing the ticket.
Will re-open it if this issue is resurfaced.


Cache previews in S3

Our preview API currently takes a while to render GIF and WEBM.
Ideally we aren't live-generating any of these. We should be caching them into S3 and pulling from there if available. This would dramatically improve the frontend experience.
A further optimization would be to trigger a request during storage so that the cache is already there when the user first hits it.

Done.


Fix Rubocop styleguide violations

Not sure why this wasn't caught by Rubocop earlier.
Mostly fixed with govuk-lint-ruby -a.

@tijmenb is the linter running on Jenkins for previous commits?
Weird it wasn't flagged in previous commits as a failure, maybe it's not working anymore...

👍


Add fill_null on dataframe/expr level

Is your feature request related to a problem or challenge?
I would like to be able to fill_nulls per col/expr and on the dataframe level, akin to polars/pyspark/pandas
Describe the solution you'd like
Add a fill_null method to DataFrame struct, add fill_null logical expr.
Describe alternatives you've considered
No response
Additional context
No response

This seems like it may almost be an alias for nvl or nvl2

@Omega359 indeed, for now I've opened a PR for a fill_null in datafusion-python that calls nvl: https://github.com/apache/datafusion-python/pull/919


MIP2 post-fork update

Set activation by block height.

utACK
Noticed that you left the BIP9 Deployments in chainparams.cpp intact. I think this is a good approach until the timeout is reached. Basically, we shouldn't use bit 4 again until Feb 1st, 2019.
I think the regtest network will also need this.


Bug #3733: xmlrpc-c / scheduler problems with big XML-Sets

Switched from xmlParseMemory to xmlReadMemory; xmlReadMemory allows parameter XML_PARSE_HUGE which adds support for files >10MB.

This has been merged.


Initial commit

This looks really awesome!! Super minimal, I dig it :D I added this issue to track the wasm-pack RFC: https://github.com/yewstack/yew-wasm-pack-minimal/issues/2


Add count of retrieved members to other groupings tab

Ticket Link
1317
List of squashed commits

Remove getting members... message added spinner to header for each groupings tab
Add count of retrieved members to other groupings tab

Test Checklist

[x] Unit Tests Passed:
[x] Jasmine Tests Passed:
[x] General Visual Inspection:

Do you know if it is possible to run codacy locally?

Do you know if it is possible to run codacy locally?

Codacy uses eslint, and we can export the Codacy rules to a eslint file.


fix #875

修复 #875
原因：strip("##")会把原本有意义的#给删除！
例子：
text = "#1 it is a nice day 1##"
print(text.strip("##"))
# 打印结果：1 it is a nice day 1
print(text.replace("##",""))
# 打印结果：#1 it is a nice day 1

测试代码：
examples = [{'id': '56bf41013aeaaa14008c959c', 'title': 'Super_Bowl_50', 'context': '## a niThis was the first Super Bowl to feature a quarterback on both teams who was the #1 pick in their draft classes. Manning was the #1 selection of the 1998 NFL draft, while Newton was picked first in 2011. The matchup also pits the top two picks of the 2011 draft against each other: Newton for Carolina and Von Miller for Denver. Manning and Newton also set the record for the largest age difference between opposing Super Bowl quarterbacks at 13 years and 48 days (Manning was 39, Newton was 26).', 'question': 'In 2011, who was the first player to be chosen in the NFL draft?', 'answers': ['Newton', 'Newton', 'Newton'], 'answer_starts': [171, 171, 171], 'is_impossible': False}]
def prepare_validation_features(examples, tokenizer):
    contexts = [examples[i]['context'] for i in range(len(examples))]
    questions = [examples[i]['question'] for i in range(len(examples))]

    tokenized_examples = tokenizer(
        questions,
        contexts,
        stride=128,
        max_seq_len=512)

    # For validation, there is no need to compute start and end positions
    for i, tokenized_example in enumerate(tokenized_examples):
        # Grab the sequence corresponding to that example (to know what is the context and what is the question).
        sequence_ids = tokenized_example['token_type_ids']

        # One example can give several spans, this is the index of the example containing this span of text.
        sample_index = tokenized_example['overflow_to_sample']
        tokenized_examples[i]["example_id"] = examples[sample_index]['id']

        # Set to None the offset_mapping that are not part of the context so it's easy to determine if a token
        # position is part of the context or not.
        tokenized_examples[i]["offset_mapping"] = [
            (o if sequence_ids[k] == 1 else None)
            for k, o in enumerate(tokenized_example["offset_mapping"])
        ]

    return tokenized_examples[0]
outputs = prepare_validation_features(examples,tokenizer)
for ids,offsetmap in zip(outputs["input_ids"],outputs["offset_mapping"]):
    if offsetmap:
        print(offsetmap,examples[0]["context"][offsetmap[0]:offsetmap[1]])
        print("="*20)

测试结果正确

LGTM! Thank you for your contribution!


Documentation: Add simple "getting started" examples

It would be great if the documentation included a few minimal working examples to get started with.
For example, it wasn't intuitive to me how to recreate something similar to the ChatGPT web interface.

You can use a ConversationChain, but you won't be able to customize the prompt or use tools it seems.
With LLMChain, I've almost managed to do a simple ChatGPT-style bot. You have to add a ConversationBufferMemory, and the following PromptTemplate:
The following is a friendly conversation between a human and an AI. The AI is talkative and provides lots of specific details from its context. If the AI does not know the answer to a question, it truthfully says it does not know.

Current conversation:

{history}
Human: {text}
AI:

This has a few flaws: you still cannot use tools, and does fairly often dream up the rest of the conversation:

but it might be a good starting point.

@notpushkin  Thanks for the hint. This seems to behave like ChatGPT:

I think something like this should be included as a "Hello World" example in the documentation.

This is definitely something we are lacking at the moment. We improved a lot of the code and added many simpler options to experiment with so now might be a good time for us to add these examples.
@notpushkin the ConversationChain is essentially a LLMChain with a preconfigured prompt.
We are looking into improving the prompt experience(mainly by adding more control to input_variables and such).
In the case of the ConversationChain some improvements could be made. Keep an eye on #146.

Tangential: I was able to get tools working if I drop conversation memory:

langflow-tools-without-memory.json
Bad news: when I add any kind of memory to the mix, I get the following error:
Error: One input key expected got ['input', 'agent_scratchpad']

My best guess is, memory.save_context gets both input and agent_scratchpad and doesn't know which one of these it should save as the user message. Is there a way to get it working? (perhaps this could be a good cue for me to start a separate issue haha)

I hope that a template market can be realized, and everyone can contribute to the directory, just like the marketplaces of https://github.com/FlowiseAI/Flowise

I think a simple method to add tutorials would just create an examples folder. Then export some working code.

@frankjoshua I think that's what's going on in https://github.com/logspace-ai/langflow_examples? (e. g. see PR directly above your comment)
I think this examples repo needs some more visibility though.

We plan on publishing something about them really soon. We are just working on the docs first.


[AutoDiff] TF-249: Enable @differentiable on initializers.

@differentiable may now be declared on initializers.
Differentiation of initializers is already supported by the
existing differentiation infrastructure.
Resolves TF-249.
Introduces TF-284: unexpected error for unmet @differentiable
protocol initializer requirements.

@swift-ci Please test tensorflow


ERROR: Error: Error with flickr API: Photoset not found

I get the above error when trying to download an AutoUpload album (the only album I have). Not sure if this has anything to do with the change in URI from Set to Album in the API or whether its a special condition on the AutoUpload album.
Any help appreciated. Thanks.

Hello @thehaven ,
thanks for having reported this issue.
Are you currently using authentication as explained in the documentation?
If yes can you please describe all the steps that I should do to recreate the issue.
Thanks again!

Hi @lmammino,
Thanks for getting back to me. Yes I've walked through those steps as part of the setup. The only difference is that my URL used is of the format:
https://www.flickr.com/photos//albums/
Rather than the documented example:
https://www.flickr.com/photos//sets/.
Let me know what details would help or whether the above is the problem and I'll provide as required.
Regards

Thanks Simon @thehaven for the very detailed reply.
I recreated a case like yours (where I have an "albums" url) with private photos inside and after having setup my credentials it seems to be working.
On your instructions I noticed you are not using the --authenticated flag. When you don't use this flag the command will not issue a request signed with your credentials so flickr will get an anonymous request and if your album does not contain any public photo it will tell you that the photoset is not found. I should probably make the error message more descriptive and explain this possibility when a "Photoset not found" occurs.
Can you please try again using the --authenticated flag?
E.g.
flickr-set-get get --authenticated <setID> <userID>

Hope this works for you.
Thank you in advance!

On a side note I just realized that Flickr finally implemented a download feature on the albums! 😈

Thank you Luciano @lmammino,
It was the fact I was missing --authenticated in my request, adding that made it work perfectly. Many thanks for all your help :)
I'll close this off now as user error.
Regards
Simon

You are very welcome! I am glad that it is working for you now.
Best regards


[GALLERY] Gallery landing page

This PR adds the Gallery landing page, along with its associated styles and components.
In this particular PR there are dead links to a template named gallery-inner.amp.html, but those will be added in the next PR.
I know there are a fair number of changed files here, but the majority are images that we'll need for this PR as well as the next one, so hopefully the actual amount of code here isn't too big for a review :)

I signed it! (this account should be associated with our org's CLA account)

@bentranter - let me know when your next PR (or resolution this PR is ready for review.) Let me know if you need some help!

Majority of comments are now addressed, also I've created staging branch for this (and future) PRs: https://ampstart-pr-metalab.firebaseapp.com/templates/gallery/gallery.amp
Regarding the reuse of the navbar component for the sidebar and header, I feel like it's not worth it due to how much we'd need to override. Please see the staging link if you have a chance, it should highlight how drastically different our header and sidebar is from the navbar component.
Regarding semantics, I've updated a few of the tags from <div> to something more descriptive. I've also refactored the majority of the landing page into a component, so that should help eliminate a lot of the repetitive markup.
Finally, all unused CSS was removed from this PR, as well as the changes to the validation task and gulpfile were reverted.

@bentranter

Regarding the reuse of the navbar component for the sidebar and header, I feel like it's not worth it due to how much we'd need to override.

I just took a look and i think it is totally reusable. Not sure what is blocking.
I think it might be easier if you pull the navbar in a separate PR and we can work on it fast, Ill take a pass at rest of the stuff soon.

@bentranter - Are we still proceeding with this PR?

Hey @camelburrito, yup, we're still proceeding with this PR. I've made a ton of changes based on feedback I received from my team (that I believe came from you a while ago). If you could take another pass at this, that would be much appreciated.

Closing in favour #646


create a command for mass renaming channels with specific prefixes

for the AikoBliss server we usually update the channel names to fit certain themes for holidays and events.
command name: !chprefix <emoji/s>
channel name format: {emoji/s}-{name}
note: we need to make sure the bot has permission to change channel names.

The formatting of the server channels have changed and I don't think this feature would be helpful anymore.


Deprecated TO GUI invoking /newlogcount

Now that the old TO UI is disabled it's no longer possible to login.  If you just sit on the deprecation page, your web browser will still try to make calls to the TO /netlogcount api endpoint.  This will always return a 401 since it's nolonger possible to login.  We should remove the javascript that's making this call.

TO GUI is dead!


Fix createRoot typings

Description of change

Adding a typing for exported createRoot functionality.
Fixes: #403

Great, thank you! ❤


expandParent fails when the child node has negative x or y position values

Describe the Bug
If you have a node that has a parentNode assigned to it with negative x and/or y values, and have expandParent for the child node, an error is thrown and it results in deletion of the parent node.
Encountered it in an application I'm working on where I assign parent nodes for a node when I drop the child node onto the parent.
Your Example Website or App
https://codesandbox.io/s/sandpack-project-forked-omrogk
Steps to Reproduce the Bug or Issue

Create a node
Create another node with negative x and/or y position values, set its parentNode to the node created earlier along with expandParent

Expected behavior
The height of the parent should be calculated correctly regardless of the presence of negative position values
Screenshots or Videos
No response
Platform

OS: macOS 11.6.7
Browser: Chrome
Version: 103.0.5060.114

Additional context
No response

Warning: `NaN` is an invalid value for the `width` css style property.
    at div
    at NodeWrapper (http://localhost:3000/static/js/bundle.js:86998:19)
    at div
    at NodeRenderer (http://localhost:3000/static/js/bundle.js:86109:72)
    at div
    at Viewport (http://localhost:3000/static/js/bundle.js:86805:23)
    at div
    at ZoomPane (http://localhost:3000/static/js/bundle.js:85220:21)
    at FlowRenderer (http://localhost:3000/static/js/bundle.js:85993:23)
    at GraphView (http://localhost:3000/static/js/bundle.js:86829:24)
    at Wrapper (http://localhost:3000/static/js/bundle.js:87222:23)
    at div
    at http://localhost:3000/static/js/bundle.js:87290:20
    at div
    at div
    at Canvas (http://localhost:3000/static/js/bundle.js:443:5)
    at $59d09bcc83651bf9$export$ceb145244332b7a2 (http://localhost:3000/static/js/bundle.js:37673:15)
    at main
    at $b9606c0c41d55371$var$View (http://localhost:3000/static/js/bundle.js:37751:78)
    at Main (http://localhost:3000/static/js/bundle.js:23090:24)
    at div
    at $994c48bfb00b620b$var$Grid (http://localhost:3000/static/js/bundle.js:33816:15)
    at IntlProvider (http://localhost:3000/static/js/bundle.js:88627:43)
    at IntlProvider (http://localhost:3000/static/js/bundle.js:22547:23)
    at Layout (http://localhost:3000/static/js/bundle.js:22886:24)
    at Provider (http://localhost:3000/static/js/bundle.js:99974:7)
    at ReactFlowProvider (http://localhost:3000/static/js/bundle.js:87518:23)
    at div
    at $884c64d19340d345$var$Flex (http://localhost:3000/static/js/bundle.js:33885:15)
    at App (http://localhost:3000/static/js/bundle.js:44:96)
    at $59d09bcc83651bf9$export$ceb145244332b7a2 (http://localhost:3000/static/js/bundle.js:37673:15)
    at div
    at $b9606c0c41d55371$var$View (http://localhost:3000/static/js/bundle.js:37751:78)
    at div
    at ProviderWrapper (http://localhost:3000/static/js/bundle.js:36231:15)
    at $f57aed4a881a3485$export$178405afcd8c5eb (http://localhost:3000/static/js/bundle.js:28332:15)
    at $1051245f87c5981d$export$8214320346cf5104 (http://localhost:3000/static/js/bundle.js:37354:15)
    at $18f2051aff69b9bf$export$a54013f0d02a8f82 (http://localhost:3000/static/js/bundle.js:25270:13)
    at $7167f8da3cce35e4$var$Provider (http://localhost:3000/static/js/bundle.js:36146:21)
    at IntlProvider (http://localhost:3000/static/js/bundle.js:88627:43)
    at IntlProvider (http://localhost:3000/static/js/bundle.js:22547:23)
    at Wrapper (http://localhost:3000/static/js/bundle.js:5018:5)

This is what the stack trace looks like

@moklick we are seeing this issue as well. Thoughts?

Thanks @mlndshh ! Fixed in v10.3.11

Thanks!


templateSpecId cannot be derived from resourceId() function if deploying at the subscriptionLevel scope

It would be convenient to derive the resourceId as
resourceId([resourceGroupName], 'Microsoft.Resources/templateSpecs/versions/', '[templateSpecName]', '[templateSpecVersion]'
This unfortunately is unsupported at the subscriptionScope so we are forced to use concat, etc to build the templateSpec resourceId. This then goes against the ARM Test Toolkit best practice test case 'IDs Should Be Derived From ResourceIDs' and 'ResourceIds should not contain' so we are force to exclude these tests.
Brief Example
{
  "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
  "contentVersion": "<IP_ADDRESS>",
  "parameters": {
    "templateSpecsResourceGroupName": { "type": "string" },
    "resourceGroupName": { "type": "string" }

  },
  "variables": {
    "location": "[deployment().location]",
    "templates": {
      "rg": {
        "name": "resourcegroups",
        "version": "0.1.0"
      }
    }
  },
  "resources": [
    {
      "name": "rg",
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2020-06-01",
      "location": "[variables('location')]",
      "properties": {
        "mode": "Incremental",
        "templateLink": {
          "id": "[resourceId(parameters('templateSpecsResourceGroupName'), 'Microsoft.Resources/templateSpecs', variables('templates').rg.name, variables('templates').rg.version)]"
        },
        "parameters": {
          "name": {
            "value": "[parameters('resourceGroupName')]"
          }
        }
      }
    }
  ],
  "outputs": {}
}

THis would also imply and probably have more value when deploying to multiple subscriptions
resourceId('[subscriptionId]', [resourceGroupName], 'Microsoft.Resources/templateSpecs/versions/', '[templateSpecName]', '[templateSpecVersion]')

You are right - this is a known issue with the resourceId() function. It is basically impossible to construct an RG-scoped resourceId in non-RG scoped deployments. The fix for this is in progress, so hoping it is resolved sometime in Feb of next year.

BTW - you should be able to get around this by creating a nested deployment targeting a resource group with expressionEvaluationOptions.scope set to inner:
    {
      "type": "Microsoft.Resources/deployments",
      "apiVersion": "2019-10-01",
      "name": "test",
      "resourceGroup": "test",
      "properties": {
        "expressionEvaluationOptions": {
          "scope": "inner"
        },
        "mode": "Incremental",
        "template": {
          "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
          "contentVersion": "<IP_ADDRESS>",
          "functions": [],
          "resources": [
            // create deployment resource that references ts here and resourceId() should work like normal
          ]
        }
      }
    }

It's definitely a hack, so hopefully we can get this resolved quickly

Definitely going to wait as this requires having the RG first
This would require an inline deployment of the RG, then the hack, then follow up with the deployments
but we include a standard linked RG template which does all the proper tagging, etc
For now the pipeline passes in the root templateSpec resourcegroup id to create the base pointer for the versions which are derived from semantic versioning

 "templates": {
      "rg": "resourcegroups/versions/0.13.0",
      "bh": "bastionhosts/versions/0.4.0",
      "pip": "publicipaddresses/versions/0.6.0"
    },
    "baseTemplateSpecId": "[concat(parameters('pipelineVariables').templateSpecResourceGroupId,'/providers/Microsoft.Resources/templateSpecs/')]",
    "rgTemplateSpecId": "[concat(variables('baseTemplateSpecId'), variables('templates').rg)]",
    "pipTemplateSpecId": "[concat(variables('baseTemplateSpecId'), variables('templates').pip)]",
    "bhTemplateSpecId": "[concat(variables('baseTemplateSpecId'), variables('templates').bh)]",


Add Joinable trait allowing filtering the results of one query with another

Objective
There's a bit of boilerplate when using the entities from Children to join against a second query.
Solution
Add a method on Children that takes a second query and calls .get on it in a loop, skipping entities that have no results in the subquery.
An alternative might be a more general join type of function that will subquery anything that is an Iterator<Item=Entity> and put that directly on Query maybe? Another option might be to add a Join at the type level.

CC @BoxyUwU @OptimisticPeach for a prototype of a relations feature using pure ECS.

FWIW, I think this is very useful functionality and should be merged in the meantime rather than waiting on relations. I'm a bit nervous about performance for this but I don't immediately see a faster approach.

Unfortunately I have to agree with Alice in that this'll most likely be a bit slow, given the complexity of query.get. Additionally, it does not permit mutable queries.
I'd probably add a temporary with_query_mut which returns a streaming iterator of some sort to deal with this.
If it becomes a big issue prior to relations being merged (and they become powerful enough to do this), we might want to consider a faster solution built into Query for dealing with querying over &[Entity].

Otherwise this isn't looking too bad, nice and elegant too :P.

I'd probably add a temporary with_query_mut which returns a streaming iterator of some sort to deal with this.

I took a quick stab at this, but it turned out to be kind of difficult to do so I gave up. I tried to implement a version where you pass in a callback that gets access to the mutable value, but that ended with an ICE: https://github.com/rust-lang/rust/issues/87531
:shrug:

@deontologician the ICE has since been fix; interested in taking another stab at this?

Yeah, I'll have some time later this week. I can give it a shot

Also, regarding design, I haven't kept up with how relations are going etc. Is this still a reasonable place to put this method?

Maybe this could be implemented for any Entity iterator?
then we could do:
for entity in some_entity_list.iter().with_query(some_query) {
}

A variant like this might also be nice:
for (transform, velocity) in some_entity_list.iter().filter_map_query(some_query) {
}

This doesn't feel like it needs to be Children-specific functionality.

Fixed some formatting and renamed things a bit. I still need to add the doc comments and doc examples.
Also curious if this is the best location for the tests. I felt it was a little more natural in the system tests, even though it's defined in the query module.

I'm really liking the new direction. Could you update the PR title and description to reflect the changes? #1658 is probably worth mentioning.

Also curious if this is the best location for the tests. I felt it was a little more natural in the system tests, even though it's defined in the query module.

Hmm. This feels like a query-joining tool; I'd prefer the tests stay with the query code.

@deontologician I'd like to see this design merged eventually, so I'm adding the Adopt-Me label. Feel free to remove it (or bug me) if you end up wanting to tackle this yourself.

is this case covered by Query::iter_many?


Catch no copr owner

Raise an exception when there is no copr project owner.
Related to the #647

but not test updates? :(

I'll take a look and try to add some.

There are no tests for copr-build at all...;-(

recheck

@TomasTomecek tests added


[Bug] Immersive mode issue

Losing immersive mode on AndHUD.Shared.Show  trigger

As mentioned in your PR:

This is why I added the prepareDialogCallback and the dialogShownCallback so authors can customize the WindowFlags to support immersive mode.

I customize the behavior like so in my code:
private void BeforeShow(Dialog dialog)
{
    if (dialog.IsNull())
        return;

    dialog.Window.AddFlags(WindowManagerFlags.NotFocusable);
}

private void AfterShow(Dialog dialog)
{
    if (dialog.IsNull())
        return;

    // maintain immersive mode
    if (ShowsImmersive)
    {
        dialog.Window.DecorView.SystemUiVisibility = ViewExtensions.DefaultImmersiveVisibilityFlags;
    }

    dialog.Window.ClearFlags(WindowManagerFlags.NotFocusable);
}

Where ViewExtensions.DefaultImmersiveVisibilityFlags is:
public static StatusBarVisibility DefaultImmersiveVisibilityFlags =>
    (StatusBarVisibility)(
        SystemUiFlags.ImmersiveSticky |
        SystemUiFlags.LayoutStable |
        SystemUiFlags.LayoutFullscreen |
        SystemUiFlags.LayoutHideNavigation |
        SystemUiFlags.HideNavigation |
        SystemUiFlags.Fullscreen);

Then I show the dialogs by always adding the two methods above as callback like:
AndHUD.Shared.ShowSuccessWithStatus(activity, status, maskType, new TimeSpan(0, 0, 5), prepareDialogCallback: BeforeShow, dialogShownCallback: AfterShow);

thanks a lot, this helps a lot


Flaky Test: KyuubiBatchYarnClusterSuite - open batch session

Why are the changes needed?

To close #2522
How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[x] Run test locally before make a pull request

Codecov Report

Merging #2523 (e84d3da) into master (cdfae8d) will increase coverage by 0.05%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #2523      +/-   ##
============================================
+ Coverage     63.62%   63.67%   +0.05%
  Complexity       41       41
============================================
  Files           373      373
  Lines         17829    17829
  Branches       2378     2378
============================================
+ Hits          11344    11353       +9
+ Misses         5430     5424       -6
+ Partials       1055     1052       -3

Impacted Files
Coverage Δ

...ache/kyuubi/operation/KyuubiOperationManager.scala
83.60% <0.00%> (-1.64%)
:arrow_down:

...in/scala/org/apache/kyuubi/config/KyuubiConf.scala
96.63% <0.00%> (+0.11%)
:arrow_up:

...ain/scala/org/apache/kyuubi/engine/EngineRef.scala
85.71% <0.00%> (+8.57%)
:arrow_up:

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 cdfae8d...e84d3da. Read the comment docs.

thanks, merging to master

Hi @turboFei @ulysses-you, any diagnosis provided? Increasing timeout blindly could solve the test flakiness, but also might suppress actual bugs

Hi @turboFei @ulysses-you, any diagnosis provided? Increasing timeout blindly could solve the test flakiness, but also might suppress actual bugs
checking.

Before, It only happened for jdk11 testing.
And I can not reproduce it, but it seems that it is not resolved now.
Looking into this.

After think twice, I think the reason is might that, the application is running in yarn-client mode and the local process does not terminate quickly.
I can set spark.submit.deployMode to cluster.


Add myself in the jenkinswalldisplay dev team to release the plugin

@pellepelster This would grant permission to release the Wall Display Plugin to Arnaud (e.g. to properly publish 0.6.33 based on the new plugin parent). Please let us know whether you approve.

@pellepelster Ping.

sorry i was afk for a few days will do the release asap

perfect @pellepelster Thx a lot


Annotations for Data Path Components

Another shot to answer the evergreen undefinedness of undriven signals in Calyx (https://github.com/cucapra/calyx/discussions/922). In its most reduced operational form, it asks when is it safe to provide 'x as the default value for a port instead of '0.
The core of this proposal are two new attributes: @data and @control. The @data attribute marks a cell as a data path component, and the @control attribute marks a cell as a control path component. These attributes are mutually exclusive, and a cell can only have one of them.
comb primitive std_add[WIDTH](@data a: WIDTH, @data b: WIDTH) -> (out: WIDTH);
primitive std_mult_pipe[WIDTH](@control go: 1, @data a: WIDTH, @data b: WIDTH) -> (out: WIDTH, @control done: 1);
cells {
  @data add0 = std_add(32);
  @control incr = std_add(32);
  @data mult = std_mult_pipe(32); // mult.go must always be defined
}

An instance marked with @control requires all its ports to have '0 as the default value. An instance marked with @data additionally needs to mark some of its ports with the @data attribute to state that these can accept 'x as the default value. This is because even for data path components, certain ports like the go port might always need a non-'x value.
This proposal follows a safe-by-default approach to the problem: it is always safe to ignore the @data attributes and provide all ports with a default value of '0. The @control attribute is just a safety mechanism that can be used to catch errors early.
Conditions for @control Instances
Following the things enumerated in https://github.com/cucapra/calyx/discussions/922, here is a list of some constraints the forces an instance to be a control instance:

If it is used in the guard of an assignment
If it is used as the done condition of a group
If it is used as the conditional port for if or while
If it is used as the input to a @go port such as write_en
If it is used as an input for another @control instance

Note that if any port of an instance is used in these positions, the instance must be marked as a @control instance. Number (5) is the challenging one here since it's a recursive condition. However, I don't see any other way to address the problem of propagation of undefinedness from data path to the control path. The interesting question is whether this approach will leave any instances as @data instances.
We can design a new pass that can compute which cells are @control using the criteria above. If these conditions are necessary and sufficient, all the cells not marked with @control are @data cells.
Semantics
Everything up till now gives a very operational view of how to address the undefinedness problem. However, it doesn't give us a clear view on what the exact semantic properties are. As far as I can tell, the semantics needs to be defined in terms of these attributes. There is no a priori way to define which signals are data path and which are control path; we can only call programs undefined given an assignment of attributes to instances.

The Filament issue above points out an optimization that this can enable in the backend:

It occurs to me that this optimization should be done by Calyx and not Filament itself because this reasoning applies to all data ports. Specifically, rewriting:
in = guard ? data : 'x

into
in = data

Should always be safe

Finally catching up on this very nice idea, @rachitnigam, after your helpful explanation today!
I think the note about allowed optimizations above is especially important. It's a very cool upside that we can show that certain optimizations are allowed on always-never-undefined values that are not possible on maybe-undefined values!!
Just to jot down some high-level thoughts that came out of today's brief discussion:

One way to "phase" this work would be to hammer things out in a fully dynamic context first, then work out the static checking. That would look like this:

In the first phase, define the dynamic semantics of the undefined value (here denoted undef) and the dynamic events that should be errors. For example, for error conditions: a guard expression evaluating to undef is not allowed, and it is also an error for a @go port ever to be assigned to undef. For dynamic semantics, undef aggressively taints guard expressions (e.g., (undef < 42) == undef), and it propagates aggressively through parameters like std_add. Hopefully, we extend the interpreter to implement these semantics precisely.
In the second phase, add @data/@control annotations as a way of soundly avoiding the dynamic error conditions. The theorem is basically that a well-typed (with respect to these annotations) Calyx program cannot ever encounter an undef-related error at run time.

For the static checker, I think it would be nice to view this as an information flow type system—i.e., all types are qualified (so, like, @data 32 or @control 1). The design and goal guarantees would be pretty similar to nullability annotations, as in Java's nullability checker.
As a corollary, a fun way to approach the issue above with annotated cells would be to make cells qualifier-polymorphic. The problem here is that we want to support cells that are sometimes used as data and sometimes used as control. For example, you might want the out port of std_add(32) to sometimes be @data 32 and sometimes be @control 32, depending on the adder. Qualifier polymorphism would mean that you would pass in a qualifier parameter, in exactly the same way that you pass in a width. So you could declare the primitive to have all its ports have type @Q WIDTH, and Q would be a type-level variable. Then if you instantiate std_add(32, @data) or std_add(32, @control) to fill in that Q.
A big question in my mind is whether we want non-undefness to be required or enforced by the compiler.

Required: The program itself needs to guarantee that the value is never undef. The compiler doesn't need to insert any zero fallbacks. This has somewhat more predictable behavior, I'd say, since there aren't any mysterious zeroes that appear implicitly; all values that happen at run time come from the program text.
Enforced: The compiler inserts zero-fallback assignments for all @control ports. This is the current behavior (but we currently do this to all ports). It would be lower effort, especially on the frontends' parts, because this is pretty much what they're expecting anyway. But it's admittedly funkier in terms of semantics, because you don't get direct control over where the zeroes get injected.

A big question in my mind is whether we want non-undefness to be required or enforced by the compiler.

One important consequence of answering this question is whether the optimization can be represented in Calyx or not. If the compiler enforces this property then the optimization occurs in backend while the Calyx code is being compiled in Verilog. On the other hand, if programs are required to maintain it, then we can represent the optimization within Calyx.
A middle ground solution is following the philosophy outlined in #518 and explicitly instantiating all the muxing in Calyx program before we even reach the backend.

Yeah, good point. I think it could be fun to think a bit about what the IR would look like in the "required" version, and what the relevant lowering/optimization passes would look like.

We need to say something stronger here:

If it is used as an input for another @control instance

In general, a lot of the computations are going to end up transitively related to assignments to a group's done signal. For example, here is an image of a part of the writes-to graph for lpm.futil:

The thing to notice is that most group[done] writes come from the done condition of a register (or something similar). Concretely, for assignment like this:
r.in = lt.out
r.write_en = 1'd1
group[done] = r.done;

We should still be able to mark lt.out as a @data cell because the r.done signal is going to contain a non-undef value regardless of what lt.out contains.
In contrast, for something like this:
r.in = lt.out
r.write_en = c.out ? 1'd1
group[done] = r.done;

We would need to mark c.out as a @control cell because whether or not r.done triggers depends upon c.out's value and because of this, it cannot be undef

Hmm; interesting example. You observed:

We would need to mark c.out as a @control cell because whether or not r.done triggers depends upon c.out's value

Correct me if I'm wrong, but in the statically-checked version of this system, we would need to require anything used in a guard to be @control, right? That is, it would be a compile-time error for a guard to have a @data type annotation. (Is that right?)

Yup! Guards are not allowed to "glitch" and hold 'x values ever


disposePinia missing types

Reproduction
https://play.pinia.vuejs.org/#eNqNU0Fu2zAQ/Aqhix3EJhO4SAHXDtwWOaSHNmh61EWW1g4dckmQlCPA0N+7Im1ZSYsgN3J3dnY4xByyr9byfQ3ZPFv40kkbmIdQW6YK3C7zLPg8u81RamtcYAdWe3gMxgFr2cYZzUZclKbGAI4HPxoAK+mt8fAgURY92Ha30ZcccywNetoVuZY97fgix4VIQmgtXQJoq4oAdGNssa5DMMhWpZLlM8mL8xwvL0nlPZYONCBtPyRijqxtFyINEcFCDNiySZbETnVh+c4bJA8O3Zb82KCnz1msdLWovavkmYhnDl5P1868eHr8jsCTE3RFhooK9sEY5aeFlWnsKQTr50KUFRK+AiX3jiMEgVaLf2ZWN/yGXwsl14IWCYkVNK/X0MS0Av0R9hN0dcWvP/HPkXU/O5LqjrUjbXNsyZbg6XM2cvvGlNJoKxW4XzZI+rxX5hRKmZcfsRZcDb3E8gnK5//Ud75Jqh8ckH17GDwrFG4LIbXvHn9CQ+e+qU1VK0K/0/wN3qi605hg32qsSPYAF9Xexz+WuP3j75oA6E+P6oRGNyI+2vz9naef5c74bODiORZk4TkWsJH4JkIpFYPsONj0TdpOrRyhic0Umz6FyyHheHTcOZqw8QVb3iaRaQQJS7zjK0pYV3WUcoe0jDJCgqmatX8BmYJeeQ==
Steps to reproduce the bug
import { disposePinia } from 'pinia';

Expected behavior
Should be able to import disposePinia.
Actual behavior

Additional information
No response

It’s just not published yet

I have a an interval that is set and cleared through onScopeDispose (useCookies from vue-use: https://github.com/vueuse/vueuse/blob/main/packages/integrations/useCookies/index.ts#L63) in a setup store. In tests the composable often still tries to access document after the test, meaning the interval wasn't properly cleared. Will calling disposePinia in afterEach make sure the store's scope is stopped before the test environment is torn down?


Name this thing

What should we call this app?
Bonus points if there's an available easy-to-remember URL.

Possibilities:

Renter Haven (suggested by Nina Maxberry)
Renter Ally
Renter Partner


[Config]Allower use to config different thrift server model

Doris only support TThreadPoolServer model in thrift server, but the server model is not effective in some high concurrency scenario, and the server model is not easy to solve high concurrency scenario.So I propsal to introduced a new config to allower use to choose different server model by their scenario, and we can add more server model when there is a need.

There is an article discuss about different Thrift Server model https://www.codelast.com/原创（翻译）java版的各种thrift-server实现的比较/


Confluent Cloud Certified Connector

Hi Team,
Request to have ScyllaDB sink connector in Confluent Cloud.
It should have a wizard to configure the connector. By now, the Confluent Cloud wizard asks for API Key and Secret Key.
More info: https://docs.confluent.io/cloud/current/connectors/index.html#preview-connectors
I understand that they want a fully-managed connector in Confluent Cloud

I'm not sure what is the ask here. I also don't know what happened on business side in the end.


Can't build the project with<EMAIL_ADDRESS>

I have updated the @project-serum/anchor version to 0.23.0 and I tried to build in anchor-cli.
But I can't get the success with this new version.
When using the 0.22.1, I got the success.

have you updated both your versions as well as the cli? (with avm use latest)

Yeah

this is very likely a version mismatch on your side.
make sure that anchor -V returns 0.23.0

Yeah, I have got that version fully and success the build
But at this time, I think we can't use the spl-token version greater than 3.2.0

Okay, thank you


add mysql row subquery test

Fixes #ISSUSE_ID.
Changes proposed in this pull request:

Pull Request Test Coverage Report for Build 7752

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

Totals

Change from base Build 7750:
0.0%

Covered Lines:
8728

Relevant Lines:
15811

💛  - Coveralls


fix: do not lowercase values

I updated the e2e test to support E2E_USER_2FA so that I could test with my 2FA enabled test user account. That worked, but the test never completed, and I'm not sure why. So I coudln't verify that the test actually passed locally on my machine. But I did update the snapshots and test manually according with the issue.
closes #1

Therefore I wonder how your setup is supposed to work, given it needs a 2fa code at runtime so to say

I don't think a GitHub login would ever work on CI. But you could run it locally. Maybe add a simple e2e test to test the whole stack, but create integration tests for the rest

I don't think a GitHub login would ever work on CI. But you could run it locally. Maybe add a simple e2e test to test the whole stack, but create integration tests for the rest

Ahhh I see, I thought you made to 2FA login work on CI and I couldn't figure it out how. Right now I do run the tests locally with my test account (without 2fa), so thanks for this awesome contribution. As said, the test setup needs some further thinking but I'm quite busy with another GitHub related project ... https://jumpcat.dev (a command palette for GitHub)

could you merge this fix in for the time being?

You're welcome 🙂


ASP.NET

How can you use this in an ASP.NET site?

As part of the asp.net pipeline? You almost certainly can't. This is
designed for standalone servers.
On Thu, 12 Apr 2018, 22:50 Terry Phillips<EMAIL_ADDRESS>wrote:

How can you use this in an ASP.NET site?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/NetGain/issues/18, or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsNCbaNUpR1J1SE-yCs_DR4gBljENks5tn8wdgaJpZM4TSjCk
.

Got it. I actually had it working, but I guess it is a lot easier to just have this as a standalone server anyway.


Add direct link to services "run" and short description to services list

The "demo" (run) link is still hard to find, and services on the "More Apps" page have to be surveyed one by one in order to find which one is suitable for those who are looking at the list. The suggestion is to add a very short description to each service (see below), possibly in smaller font to fit on one line and smaller line spacing, AND add a Run button (I suggest rather a "Go!" labelled one) net to tne name of the service (to the right of it), i.e.
MorphoDiTa         Go!
Czech morphology and tagging
Suggestions for the short descriptions:
Treex::Web
Framework for text analysis and generation
Cesilko
Czech to Slovak machine translation
PML-Tree Query
Advanced treebank search
PDT-Vallex
Czech valency lexicon w/real text examples
EngVallex
English valency lexicon w/real text examples
CzEngVallex
Bilingual valency lexicon w/advanced search
Morph
Original (old) Czech morphology
MorphoDiTa
Latest Czech morphology and tagging
NameTag
Czech and English NER
ILRB
Czech language online reference (ÚJČ)
ElixirFM
Arabic morphology
Dialogy.org
Annotated TV (spoken) discussions
Korektor
Spelling correction for Czech
Moses
Machine translation Czech-English (PBSMT)
KonText
KWIC search for LINDAT corpora
Parsito
Parser for UD langauges (CoNLL-U I/O)
KER
Keyword extractor for Czech and English
UDPipe
Parser for UD languages (plaintext to parse)
EVALD 1.0
Text coherence assessment tool (Czech)
EVALD 1.0 for foreigners
Text coherence assessment w/English interface

I have just add the link to search Czech National Corpus 201PUB: https://kontext.korpus.cz/first_form?corpname=syn2013pub and I have to bump this issue. The demo name is completely outdated, the search of the corpus is its main form, production service, no demo. The same is true for most our services. Also lets' make the "Run" link more prominent 👍
Also agreed on naming / labeling / describing the services in some form, so that info can be used elsewhere, like in the service list on the web.


Fixing Uqload scraper with new TLD

Uqload changed (again) its TLD, from .co to .io, thus breaking the uqload support. This PR fix this problem and add a corresponding test for old .co support. I ran the tests successfully and confirmed the fix is working on the latest version of Firefox.

Thank you for your contribution. I've changed it to no longer check the Uqload TLD. When it changes TLD again, Cast Kodi should support future changes.


BangleRun distance doesn't go above 9.99km

Hi - just used my Bangle.js for the first time and the BangleRun app. It worked great, but I noticed that once I had run more than 10km, the distance field reverted back to showing 0.XX. I ended up running 10.37km, but the distance display showed 0.37.
I guess its the BangleRun's equivalent of the y2k bug, but we could call it the d10k bug.

Thanks! That'll be fixed in the next update


Status - fix compact padding

This is a change that was missed in https://github.com/microsoft/vscode/commit/f97316f0c34eb4cf79326aa85496c7c89010c55f.

Thanks!
fyi @daviddossett , compact items are on the left and right of the status bar


bug: Weeks data overflowing and not hiding under the course content thing

Describe the bug
The data for each week (Week 1, Week 2, Week 3, Week 4) is overflowing and is not being properly hidden when the user navigates the collapsed view under "Course Content." Instead of hiding the content, it remains visible, leading to layout overflow.
To Reproduce
Steps to reproduce the behavior:/
1.Load the course content page.
2.Collapse or expand the sections for Week 1, Week 2, etc.
3.Observe that the content for Week 4 overflows instead of being hidden properly under the collapsed sections.
Expected behavior
When the course content sections (Week 1, Week 2, etc.) are collapsed, the contents inside should hide properly. The overflowed content should only be visible when the section is expanded.
Screenshots or GIFs
If applicable, add screenshots to help explain your problem.

Browser:chrome
latest version
(Will be fixing this bug)

hi @sahilc-xd . I wanted to let you know that I’ve raised a PR for the issue you mentioned and made the necessary fixes as of yesterday.

Ohh it's okay , can you please let me know any bugs that have not been touched by anyone , any new bugs, anything

@wraith2009 any bugs that have not been touched , can you please mention them here or assign it to me please

i am not the moderator bro even i look for bugs . u can ask others or just
find one and update the mode on it . ask them to assign the bug to you. ofc
u can solve the bug and let them know at the same time
On Thu, Sep 19, 2024 at 3:13 PM sahilc-xd @.***> wrote:

@wraith2009 https://github.com/wraith2009 any bugs that have not been
touched , can you please mention them here or assign it to me please
—
Reply to this email directly, view it on GitHub
https://github.com/code100x/cms/issues/1269#issuecomment-2360516097, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A3E3H4EFLQPZD5ASGSI7VS3ZXKMF5AVCNFSM6AAAAABOPMMYOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRQGUYTMMBZG4
.
You are receiving this because you were mentioned.Message ID:
@.***>


Support NULL Megerable field for pull request query

Based on statement of mergeability,

The value of the mergeable attribute can be true, false, or null. If the value is null, this means that the mergeability hasn't been computed yet, and a background job was started to compute it. Give the job a few moments to complete, and then submit the request again. When the job is complete, the response will include a non-null value for the mergeable attribute.

However, current mergeable in go-github is boolean type. So when it is null, seems like it is assigned as false, which cause calling application making wrong decision. During my concurrent testing, I did find sometimes, GitHub returns null field. So seems like it need to be supported.

@gmlewis I think we can close this issue. Agreed?

Otherwise, GetMergeable method probably should just not be exposed to avoid confusion for other people.

For consistency, we will keep all accessors available, but just realize that their use it optional.
Thank you, @wesleimp!
Closing.


RandomFu is a huge dependency

Dang its real big. Compilation times shot up drastically upon including it. I think we should think about moving it out to a separate package (polysemy-random-fu maybe?).

Before:

Separate package is fine! Or you can just drop it. I still have it in knit-haskell (hadn’t upgraded yet!) so I’m personally indifferent at the moment.

@adamConnerSax would you want to be the maintainer of such a package? I'd prefer it be you instead of me, since I don't know anything about randomfu!

Sure!  I’ve never dealt with that.

I don't care! But putting it on stackage turns out to be super easy:
https://github.com/commercialhaskell/stackage/pull/4562/files
On Sat, Jun 8, 2019 at 7:30 PM Adam Conner-Sax<EMAIL_ADDRESS>wrote:

Sure!  I’ve never dealt with that.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/isovector/polysemy-zoo/issues/16?email_source=notifications&email_token=AACLAF2QQYPX6BB6AR3I5VDPZQ6ITA5CNFSM4HSB23G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXIAQ7Q#issuecomment-500172926,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACLAFZU6G5323DLFBVMOWTPZQ6ITANCNFSM4HSB23GQ
.

I’ve seen that! Does it only work if you use hpack or stack? I’m sort of all cabal but willing to learn hpack...
You want me to just make a package with just RandomFu and publish or will you do it, leave in this repo and make me the maintainer?

Bump.  Just making sure you're not waiting on me for something...
I'm happy to take over whatever when you want me to or to leave things as they are or whatever.

Thanks for the reminder --- totally forgot about this. I'd prefer if you are solely responsible for the package:

Moving it into its own repo
Publishing it on hackage

if you're cool with that. Afterwards I'd be happy to link to your package from this one!

Sure.  Might not happen until next week.
Same namespacing, that is, call the module "Polysemy.RandomFu"?  Or do you want something different when they are external?
Maybe you should add an "EffectsPackages.md" file here with links?  Or a section at the bottom of the readme?

The module name is fine! The dream is that no effects are more privileged
than any others. Good idea about the markdown file; will do after the
package is published.
On Thu, Jun 13, 2019 at 2:28 PM Adam Conner-Sax<EMAIL_ADDRESS>wrote:

Sure. Might not happen until next week.
Same namespacing, that is, call the module "Polysemy.RandomFu"? Or do you
want something different when they are external?
Maybe you should add an "EffectsPackages.md" file here with links? Or a
section at the bottom of the readme?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/isovector/polysemy-zoo/issues/16?email_source=notifications&email_token=AACLAF2O2ZIEAHQLTFLALP3P2KGUPA5CNFSM4HSB23G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXUUFVA#issuecomment-501826260,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AACLAF7SCVGPXBK3UI76UCDP2KGUPANCNFSM4HSB23GQ
.

So my plan is to push a new version of polysemy-zoo that exludes Polysemy.RandomFu. Then the module name is available to you, you can link against polysemy-zoo for Polysemy.MTL, and put #20 in your package.

That works!
Also, I've noticed that this (https://github.com/kowainik/co-log/tree/master/co-log-polysemy) exists.  I don't know if it has any tests nor have I tried to use it, but it's there, in case you're interested in adding it to the list.

polysemy-zoo-<IP_ADDRESS> is up, without the RandomFu stuff, so the ball is now in your court, @adamConnerSax. Thanks again for your work on this!

Had a few minutes today and it was easier than I thought to re-arrange.
https://hackage.haskell.org/package/polysemy-RandomFu-<IP_ADDRESS>

Awesome. I'll add it to the PR.
PS, if you find that hacakge refuses to build your haddocks (it's an issue with the plugin, I think), get back in touch and I can walk you through it.

I could use that walkthrough!  Also effects my knit-haskell package.

But haddock is broken when using plugins: https://github.com/haskell/haddock/issues/900. So the solution is to comment out the -fplugin bits, and to use -fdefer-type-errors. I just switch which parts of this are commented out before running haddock-up:
https://github.com/isovector/polysemy-zoo/blob/488c961945b9bbd64806199e5fe991f57f7e83ac/package.yaml#L32-L37

Cool!  I'll give it a try!

@isovector I thought I read somewhere this is fixed in ghc-8.8. Is that true?

@Avi-D-coder I think so

I mentioned before that uploading docs should just be: cabal upload -d --publish. No need for external tools. I'd be curious if that doesn't work.

@ocharles i don't have cabal! i don't know how to cabal!

absolute mad lad

That worked!  For clarity, since there was some v1,v2 cabal dancing:

cabal v2-haddock --haddock-for-hackage
cabal upload -d --publish /Path/to/haskell/libs/knit-haskell/dist-newstyle/knit-haskell-<IP_ADDRESS>-docs.tar.gz

Strange, mine doesn't even require two steps. Is this the latest stable Cabal?

It’s at least 2.4.
When I try to just do “publish” it runs into a dependency issue because it seems to be a v1 command? So I build the haddock using the v2 command and then upload. But maybe there’s a better way?

Yes, cabal upload --publish -d, as I keep saying :stuck_out_tongue: If you show me what that produces, I might be able to see what's going on. I'm sure I did exactly this only a day or so ago with no problems on one of my repos.

Didn't realize you wanted the details.  Here you go!
After cabal --version
cabal-install version <IP_ADDRESS>
compiled using version <IP_ADDRESS> of the Cabal library

After cabal upload --publish -d
No documentation tarball specified. Building a documentation tarball with
default settings...
If you need to customise Haddock options, run 'haddock --for-hackage' first to
generate a documentation tarball.
Resolving dependencies...
Warning: solver failed to find a solution:
Could not resolve dependencies:
[__0] trying: polysemy-RandomFu-<IP_ADDRESS> (user goal)
[__1] unknown package: random-source (dependency of polysemy-RandomFu)
[__1] fail (backjumping, conflict set: polysemy-RandomFu, random-source)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: polysemy-RandomFu, random-source
Trying configure anyway.
Configuring polysemy-RandomFu-<IP_ADDRESS>...
Warning: The flag --disable-executable-profiling is deprecated. Please use
--disable-profiling instead.
cabal: Encountered missing dependencies:
polysemy >=0.3,
polysemy-plugin ><IP_ADDRESS> && <<IP_ADDRESS>,
polysemy-zoo >=0.2,
random-fu >=<IP_ADDRESS> && <<IP_ADDRESS>,
random-source >=0.3 && <<IP_ADDRESS>

Strange, it almost looks like you need to cabal update, so cabal knows about random-source


feat(v1): rewrite engine, make a monorepo

Following #95

@SGAMERyu ; you might want to look at this one :)

Thanks for the support @MrHBS :)
I made huge progress in the latest commit, including fully testing (almost 100% coverage) both @pinceau/core and @pinceau/theme which are biggest parts of the new arch.
I'll now be doing the same on @pinceau/style and @pinceau/vue.
This led to major stability improvements and overall rewrite of both these packages.
I can't wait to share more about the project, happy to know some of you are following. 😊

Hey @MrHBS ; @zanfee ; @henrycunh ;
I fully revamped all existing package features and tested them all.
Runtime engine is now framework agnostic and Vue integration is fully tested.
Now, I'll put some focus on Volar integration, and Pinceau IntelliSense extension.
Next, I'll upgrade the docs, and aim toward the v1.0 release.
Thanks for following the project.

Hey @MrHBS ; @SGAMERyu ; @zanfee ; @henrycunh ;
In the latest commit, I added full support for Svelte and the whole test suite for it.
In the next commit, I'll be shipping the support for all JSX-based frameworks through @pinceau/jsx.

Hey @MrHBS ; @SGAMERyu ; @zanfee ; @henrycunh ;
In the latest commit, I added full support for Svelte and the whole test suite for it.
I started trying to support Svelte as I was building the VSCode extension, which now works much better thanks to that little detour.
In the next commit, I'll be shipping the support for all JSX-based frameworks through @pinceau/jsx and hopefully a working version of play.pinceau.dev that uses this new Pinceau version.

Looking forward to version 1.0, I'm currently working on a demo of pinceau's viewer, just like the tailwind viewer

@SGAMERyu ; I can't wait to show you what I built for this v1; I'm getting amazed a bit more every day. 😄

React is now fully supported as well, with some great discoveries from the new API.
const TestComponent = $styled.a<{ color: ThemeTokens<'$color'> }>({ color: (color) => props.color }).withVariants({ ...variants })

const MyPage = () => {
   return (
      <TestComponent color="$color.red.1">Hello World</TestComponent>
   )
}

This is cool for React, but after making it fully work there, I tried to integrate it with Vue and Svelte, as the new Pinceau engine makes it just a few lines for me to add between frameworks.
That unlocked:
In Vue:

<template>

      <TestButton color="$color.blue.1">
      	BlueButton
      </TestButton>

      <TestButton color="$color.green.2">
      	Green button
      </TestButton>

</template>

In Svelte:

   <TestButton color="$color.blue.1">
    BlueButton
   </TestButton>

   <TestButton color="$color.green.2">
    Green button
   </TestButton>

I think this is a HUGE gain for developer experience in .svelte and .vue contexts, because this kills the 1 component per-file that I myself encountered many times.
When you want to create a single component that is reusable, but still has no need to be a SFC because it will only be used in your local component, this becomes very handy.
It also makes it a breeze to create components with props typed from the theme.

Well, now that this is all done and pushed, I'm hoping on the playground and expect to ship a first version very soon!

This PR is now ready, I'll proceed with merging on main.
Documentation is obviously not up-to-date, but will be very soon.
I am rushing on finishing the playground now, so anyone can try the new features and syntaxes right from the browser.
I will be making a v1-beta release as well, as I need it for the playground, and so anyone curious can try.
You can find examples of any compatible setup in the examples/ directory of the repository.


Version 2.0.0-rc.1 fails to start

Version
nuxt-security: 2.0.0-rc.1
nuxt: 3.11.2
Reproduction Link
Let me know if you need one, but this seems to affect all new installations.
Steps to reproduce
Use nuxt-security.
What is Expected?
It works
What is actually happening?

 ERROR  RollupError: Could not resolve "../../../defaultConfig" from "node_modules/nuxt-security/dist/runtime/server/middleware/requestSizeLimiter.mjs"                                                             nitro 19:09:26

This looks like a mistake in the build.

The extension is missing here, and the defaultConfig.mjs file does not seem to exist as part of the bundle.

@AaronDewes you're right, patching now

Thank you!


new plugin: Flow.Launcher.Plugin.IPDetails

Please see more details here: https://github.com/ibnuh/Flow.Launcher.Plugin.IPDetails

Hi there, I see you added the AppVeyor file in the repo but I don't see any jobs run to publish your release, is it connected?

Hi there, I see you added the AppVeyor file in the repo but I don't see any jobs run to publish your release, is it connected?

Hi! I will setup a github actions, pipeline first for the repo to automatically publish a release. Will update here

I have configured github actions for automated release, please kindly check


Can't get to run or build on macOS

Can someone provide instructions to get ComicTagger 1.1.30-rc1 to run on MacOS 10.14? I've got everything installed right that I can think of - Python, beautifulsoup4, configparser, pyqt5... and just can't get it to work from the source. Setup.py just gives errors. And the file on the release page isn't a .app or .py or any other file that I can think of to get working. I'd really, really, really appreciate help getting it working. Hoping that the updates fix the problems with the ComicVine API returning thousands of results, but just can't get it to work. Thanks.

Kedickso,
Do we know if there's a working version right now on either platform? I've abandoned the Mac app because no version will run properly on it, but the error you describe above (ComicVine API) is also found in the Win version. So right now this all seems unusable.
Cheers

The newest 1.1.31 RC on windows seems to work fine and corrects the issues with searches returning too many results. I’m still unable to get a working build for Mac, so for now I’m just using the Windows version in a VM I built just to run the application.

Thanks! I didn't see that there had been a new RC since 1.1.30. That seems to be working. My Mac is older so I can't get a working version of it on there either. In the meantime, I've got that on a Win 10 machine that can see a shared Mac folder so I can run the app in Windows but still access the files.
Thanks for the heads up.

Any more luck with 1.1.31 RC on the Mac? Got 1.1.30-rc1 to run from its release but as you all know, it still returns too many results from CV. I may have to resort to the Windows version, too, I guess. Appreciate everyones hard work on this.

@jbellanca I've been able to get 1.1.31 RC to build successfully, and can verify that it fixes search results. However, drag & drop is still apparently broken as it causes the app to crash any you drag a file into the application window.

Yeah I verified that 1.1.131 RC works with pulling results on the Windows side, but I haven't been able to build it on the Mac, and there's no release build on GitHub here either, and saw that 1.1.30 RC breaks drag and drop (which is fine, that's minor). Do you have a build of 1.1.31 RC on the Mac that I could download?

@jbellanca https://www.dropbox.com/s/ritwi4cwrpm9o7a/ComicTagger-1.1.31RC.zip?dl=0

@kedickso I tried running your compiled version, but it's constantly telling me my unrar isn't properly configured. I know it isn't, as I upgraded to your version from a working on because of this "too many search results" issue with ComicVine.

Hi
Were build instructions provided in the end elsewhere? There's a simple error that requires changing the TLS version but I can't manage to build the app in MacOS. I must be missing something.
Existing instructions in the Wiki are from 4 years ago and don't work on MacOS.
The two lines that need changing to get comictagger working back are on this commit.

The current alpha release does not have this issue.


width is being converted to floating point

Challenge adjust-the-width-of-an-element-using-the-width-property has an issue.
User Agent is: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36.
Please describe how to reproduce this issue, and include links to screenshots if possible.

Google

Google was founded by Larry Page and Sergey Brin while they were Ph.D. students at Stanford University.

    Larry Page
    Sergey Brin

    ```

When you press check tests it fails because the call to verify test of
$('.fullCard').css('width')
is returning a floating point number instead of the decimal value entered:
"244.98295020214843px"

@ratracegrad I can verify that this causes an issue on Firefox. This runs just fine on Chrome. How were you able to verify the floating point number?

I am using Chrome and it did not work for me. I did try Firefox before reporting issue and had the same problem with it too.
I verified that it was a floating point number by opening up the developer console and entering:
$('.fullCard').css('width')
and this returned "244.98295020214843px". This will of course make the test assert fail which is the problem I am encountering.

@ratracegrad thanks for the information. This issue appears to be a duplicate of https://github.com/freeCodeCamp/freeCodeCamp/issues/12687. So I'll be closing this issue in favor of that one. Happy coding!


[WebUI] Replace common English names with user-specific names

Suppose the user has a family member and frequent convo partner named "Joe". When an AE option says "How are you, Jim?" based on the entered abbreviaton "hay,j", the "Jim" part should automatically be replaced with "Joe".
This needs to be supported by a backend endpoint or a local settings that serves the set of partner names.

Originally @vsubhashini 's idea :)

This is now fixed in the webui-2 branch.


CASMCMS-8758: Update RPM repos so that CFS and image recipes will have the packages they require

Summary and Scope
This PR updates some RPM versions, adds some RPMs to the Nexus repos, and moves some RPMs around in those repos. This is motivated by the following:

csm-config changed in CSM 1.5 so that it only sets up the Zypper repos for the appropriate SLES version where it is running (in addition to the noos repository). This means that for CFS, the RPMs it wants to update can no longer be in a repo for a different SLES release.
Some RPMs have changed to being built as noos. But any image recipes which install those RPMs have to specify the repository where they can be found. We have seen problems in the past where recipes stopped working when an RPM was moved to a different repo.
Some RPM versions in the csm repo were behind the version of the corresponding RPMs in the metal-provision repo, which is undesirable. The versions in csm should always be >= the versions in metal-provision.
Some RPMs are now built both x86 and aarch64, and both should be uploaded into Nexus
A few entries in the RPM manifests had superfluous ".rpm" strings at the end -- this PR cleans those up to match the rest

For CSM 1.5 specifically, in order to avoid breaking recipes this late in the game, this PR does not remove any RPMs from the repos. If an RPM has changed from being tied to a SLES version to being noos, then this PR adds it to the noos repo, and also updates the SLE repos where it is found to include the new noos build of that RPM. The CSM 1.6 version of this PR will clean that up, so that noos RPMs are only in the noos repository.
The version bumps in this PR are just to move to the version of the RPM with the updated build specs (noos, noarch, etc) -- they are not content changes.
This PR is in draft mode because it is still being finalized
Summary of changes, by package

Packages
Change

acpid, csm-node-heartbeat
Added aarch64 RPM, removed superfluous .rpm from listing

bos-reporter, canu, cray-uai-util, csm-node-identity, csm-testing, goss-servers, hpe-csm-scripts, ilorest, manifestgen
Updated to noos versions of RPM. Added noos version to noos repo; replaced OS-specific versions with noos version in SLE repos where they were present

craycli, spire-agent
Added x86_64 and aarch64 RPMs to noos repo. replaced OS-specific versions with noos versions in SLE repos where it was present

pit-init
Moved its location in the noos repo listing to be in alphabetical order, bumped version to match metal-provision

smart-mon
Removed superfluous .rpm from listing

cfs-debugger, cfs-state-reporter
Added to SLE SP3 repo, since compute nodes install it

cfs-trust
Added to SLE SP3 repo, since compute nodes install it. Bumped version to match version in metal-provision

hpe-yq
Added aarch64 RPMs

loftsman
Bumped version to match version in metal-provision

Issues and Related PRs

Forthcoming CSM 1.6 manifest PR
Forthcoming metal-provision 1.5 PR
Forthcoming metal-provision 1.6 PR

It isn't clear what the mix-n-matching is fixing, we shouldn't be adding noos repos to the sle specific files. csm-config for 1.5 and 1.6 is configured to add sle-{current distro service pack}, noos, and csm-embedded. Other than metal-provision and csm-config, what other recipes need to know?

I'd have to defer to @dlaine-hpe , as he is the one who informed us that we broke some recipes when a different RPM was moved to a different repo. But I don't see this being a big deal to have this intermediate step between moving them fully to noos for CSM 1.6

Did a partial review, but I am still unsure about the the mix-n-match repos.

@mharding-hpe You can use the following code to filter out packages, which do not to be under rpm/cray/*, because they are already in embedded repo:
$ git checkout -b CASMCMS-8758-1.5 -t origin/CASMCMS-8758-1.5

# Requires ARTIFACTORY_USER and ARTIFACTORY_TOKEN env variables.
# Validates RPM indexes and generates file named rpm/embedded/index.yaml
$ ./hack/embedded-repo.sh --validate
Downloading package lists ...
List of packages for embedded repo:
    Mesa-22.3.5-150500.75.2
    Mesa-dri-22.3.5-150500.75.2
    Mesa-gallium-22.3.5-150500.75.2

# List packages which can be removed from rpm/cray/*
$ for p in $(grep -r -E '^ +- .*' -h rpm/cray | sed -e 's/^ *- //' | sort -u); do echo "$embedded" | grep $p; done
cfs-debugger-1.4.0-1.noarch
cfs-state-reporter-1.9.3-1.noarch
cfs-trust-1.6.7-1.noarch
cm-cli-1.5.0-1.x86_64
cray-site-init-1.32.0-1.x86_64
csm-auth-utils-1.0.0-1.noarch
csm-node-heartbeat-2.1-3.x86_64
cvt-1.5.9-20230804061353_2d3e92970639.x86_64
hpe-csm-goss-package-0.3.21-hpe3.x86_64
hpe-yq-4.33.3-1.x86_64
ilorest-<IP_ADDRESS>-20.x86_64
loftsman-1.2.0-3.x86_64
metal-basecamp-1.2.6-1.x86_64
metal-ipxe-2.4.4-1.noarch
metal-nexus-1.2.3-1.x86_64
metal-observability-1.0.9-1.x86_64
pit-init-1.4.2-1.noarch
platform-utils-1.6.3-1.noarch
smart-mon-1.0.3-1.noarch
spire-agent-1.5.5-1.8.x86_64

Did a partial review, but I am still unsure about the the mix-n-match repos.

It seems like the clearly less risky course to me, because it just removes possible problems. And CSM 1.6 doesn't have it, so it's temporary. I am erring on the side of caution with the changes.

@mharding-hpe You can use the following code to filter out packages, which do not to be under rpm/cray/*, because they are already in embedded repo:
$ git checkout -b CASMCMS-8758-1.5 -t origin/CASMCMS-8758-1.5

# Requires ARTIFACTORY_USER and ARTIFACTORY_TOKEN env variables.
# Validates RPM indexes and generates file named rpm/embedded/index.yaml
$ ./hack/embedded-repo.sh --validate
Downloading package lists ...
List of packages for embedded repo:
    Mesa-22.3.5-150500.75.2
    Mesa-dri-22.3.5-150500.75.2
    Mesa-gallium-22.3.5-150500.75.2

# List packages which can be removed from rpm/cray/*
$ for p in $(grep -r -E '^ +- .*' -h rpm/cray | sed -e 's/^ *- //' | sort -u); do echo "$embedded" | grep $p; done
cfs-debugger-1.4.0-1.noarch
cfs-state-reporter-1.9.3-1.noarch
cfs-trust-1.6.7-1.noarch
cm-cli-1.5.0-1.x86_64
cray-site-init-1.32.0-1.x86_64
csm-auth-utils-1.0.0-1.noarch
csm-node-heartbeat-2.1-3.x86_64
cvt-1.5.9-20230804061353_2d3e92970639.x86_64
hpe-csm-goss-package-0.3.21-hpe3.x86_64
hpe-yq-4.33.3-1.x86_64
ilorest-<IP_ADDRESS>-20.x86_64
loftsman-1.2.0-3.x86_64
metal-basecamp-1.2.6-1.x86_64
metal-ipxe-2.4.4-1.noarch
metal-nexus-1.2.3-1.x86_64
metal-observability-1.0.9-1.x86_64
pit-init-1.4.2-1.noarch
platform-utils-1.6.3-1.noarch
smart-mon-1.0.3-1.noarch
spire-agent-1.5.5-1.8.x86_64

Per Rusty, some packages need to be in there even though they are in the embedded repo. I have already modified my PR so that I am not adding any NEW RPMs that are not currently in these repos. I consider it beyond the purview of this PR to prune the list of RPMs that are already in there. I think that you and Rusty should make a follow-up PR to prune the list, but this PR is big enough already.

Why would we need aarch64 packages? We only ship x86_64 NCN images. Without them, PR will be much smaller.

Why would we need aarch64 packages? We only ship x86_64 NCN images, so they are of no use for NCNs. Without them, PR will be much smaller.

I only included aarch64 packages for RPMs that we install on compute nodes (or compute node images), as I believe we are adding aarch64 support for compute nodes in CSM 1.5. We added support for them to IMS for this release. That's why many of our RPMs are now built both x86_64 and aarch64.

Still, do not mix-n-match the repos. Sure it might seem harmless, but so would just making a single index.yml file and copying/symlinking it in all the directories. It isn't about being clean, we really shouldn't mask any issues here given Noos is a 1.5 deliverable and 1.5 isn't out until November.. we have time to point folks at noos.

Rusty requested changes which we just discussed on a call.  He's good moving this forward.

Did a partial review, but I am still unsure about the the mix-n-match repos.

@rustydb It seems like the clearly less risky course to me, because it just removes possible problems. And CSM 1.6 doesn't have it, so it's temporary. I am erring on the side of caution with the changes. If you wish to make a follow-up PR to prune the RPM list, I won't oppose you. I just don't feel confident that removing the RPMs is safe.

Still, do not mix-n-match the repos. Sure it might seem harmless, but so would just making a single index.yml file and copying/symlinking it in all the directories. It isn't about being clean, we really shouldn't mask any issues here given Noos is a 1.5 deliverable and 1.5 isn't out until November.. we have time to point folks at noos.
EDIT: Pete and I were clinically going through these packages for the noos conversion, between docs-csm, csm-config, and metal-provision everything is set currently to look at noos. Outside of CSM we obviously have no control over, and we can either publish those packages to the distros to accommodate or accept the risk and get the team(s) to switch. Since Pete is gone, Mikhail and I are now tag-teaming this. We shouldn't pretend repos have things they don't actually have in artifactory.

I've added a commit with the changes you requested, and I've added a comment at the top of the PR description with an explanation of it. I'll leave it up to Dennis whether he finds the risk acceptable or not.

Thank you.
On the contrary, I thought Dennis may have had a hard time accepting what was going on with the giant diff. As thoughtful as we are, we're just speculating.

I would be more inclined to agree with you if I was proposing doing this going forward, instead of just for CSM 1.5. Given that the CSM 1.6 PR doesn't have these issues, I'm not sure why it is such a big deal that CSM 1.5 would be in an intermediate stepping-stone state.

Again, noos is a deliverable for 1.5. The driving folks for this (Pete, myself, Mikhail, and partially Dennis) have take a stepping stone step of having packages continue to publish to ^sle- repos in addition to the noos. Those were each discussed and impleneted after conferring with one another. Since the concern didn't come to light this week, and I didn't explicitly bring it up, I (in hindsight) falsely judged the notions by the CMS team (or just for you and David). In hindsight, to circumvent having this entire thread we should've done the stepping stone thing we already were doing and just publish to both.

The mix-and-match repo is not unprecedented, as evidenced by the embedded repo. The CSM embedded repo contains both noos and SLE RPMs, sourced from multiple different artifactory repos. So we clearly don't have a philosophical objection to having RPMs from different artifactory repos or with heterogeneous OS types in the same Nexus repo (and RPM repos themselves allow for this as a matter of course -- it's not a "wrong" use of RPM repos).

No, I coined mix-and-match/mix-n-match as a reference to pulling an entirely different repo URL into another for these YAML files. The CSM embedded repo is not defined within these YAML files, it has no manifests, it is besides the point. Using it as an example to justify making these files weird is a too much.

I'm not sure why you are conflating the Nexus repos with artifactory. We do pull RPMs from artifactory to populate the repos, but I don't think there's anything to suggest that there's a 1-to-1 relationship between repos in Nexus and repos in artifactory. For example, look at the noos repo defined here -- it pulls from two different artifactory sources. And if anyone wanted to know where an RPM in a Nexus repo came from, they'd just go look at the manifest file in here, and it would be obvious where in artifactory it originated.

I'm sorry if you misunderstood, or interpreted it that way. My words seem very twisted at this point. There's no conflation going on.
If I have a noos package in Artifactory that I want to update the CSM manifests for, it is counter-intuitive to update the non-noos index.yml files. Some people may grep and figure it out, but not everyone does.

But like I said, I added a commit with your requested changes, and Dennis/whoever can decide what they're comfortable with. Since it's a separate commit, it's easy to remove if Dennis wants to go the other way.

Much appreciated. Apologies on the misunderstandings, I did not mean to involve CMS even remotely close to this much in the noos manifest changes.


Test automatic assignment for new Blazor issues

Should we try it and see what happens?
🤔 ... If it doesn't work out and the whole repo crashes, I could always go back and play for the Celtics again! 🤣

WORKS!
See test issue at https://github.com/dotnet/AspNetCore.Docs/issues/26926.


Update users of jax.tree.map() to be more careful about how they hand…

…le Nones.
Due to a bug in JAX, JAX previously permitted jax.tree.map(f, None, x) where x is not None, effectively treating None as if it were pytree-prefix of any value. But None is a pytree container, and it is only a prefix of None itself.
Fix user code that was relying on this bug. Most commonly, the fix is to write jax.tree.map(lambda a, b: (None if a is None else f(a, b)), x, y, is_leaf=lambda t: t is None).

Wonderful stuff! Thank you for the fix Peter :)


Default constructor workaround for Android 4.2+

The existing default constructor workarounds at SerializerPojo fails since Android 4.2, making a no-arg constructor required for serialized classes.
Solves this: #295
This overcomes the changes in android introduced in this commit - the constructor ID is now a long.

Needs to be included in beta2 release


Deduplicate on bank statement import

Bank statement lines should be grouped per day.
Two movements are said to 'match' if they have a timestamp within 24 margin, exact same amount, and exact same  'to' component. The overlap in description determines how 'strong' or 'weak' the match is.
For each line in the day group, see if it has any matches inside the day group.
Based on that, split the day group into lookalike groups, such that each entry matches all other entries in its own lookalike group but none of the entries outside it.
For each lookalike group, see how many matches there are in the db.
If there are fewer matches in the db than in the lookalike group, create movements in the db from the weakest matches.
Add statement entries that are directly traceable to the bank statement line, either to the newly created movement, or to the movement the line was matched to.
In the trivial case with an empty database this means that each entry is just imported.
In the case where some entries already exist in the database because they were already imported, this adds the missing ones.
In the case where some entries already exist in the database because they were reported from the counterpart account, this will hopefully add the corresponding statements to the right movements.

Got some code in the fix-98 branch, but it's not matching yet.
Will debug further.

See #100 for further progress details


NetPeer Connection Fix #102

#102 near the end references an edge case where both clients are trying to connect to each other in v0.7.5,  First connect would succeed if one person is faster.  If they arrive near the same time, the ConnId would be incorrect due to SendConnectRequest() and handle ConnectRequest() indexes are incorrect.
Added Two new Buffer Indexes in NetConstants.  One for ConnectRequest and one for ConnectAccept, since ConnectAccept uses index 1 (no ProtocolId) and ConnectRequest uses index 5.

Thanks for fix)


DB connection through psql issue

Hi,
I'm facing issues while connecting to database through psql and getting error as below-
postgres@evosfncll1065 ~]$ psql
psql: /tcg/app/postgresql/postgresql-14.4/lib/libpq.so.5: no version information available (required by psql)
psql: /tcg/app/postgresql/postgresql-14.4/lib/libpq.so.5: no version information available (required by psql)
psql: connection to server on socket "/tmp/.s.PGSQL.5432" failed: No such file or directory
Is the server running locally and accepting connections on that socket?
Kindly provide a solution/steps to follow to resolve the above issue.

Hi Chitrasree24
First of all I apologize for the late answer.
This platform provides possibility to report a bug on our Documentation portal - in order to improve the quality of our documentation. It should not be used to solve issues with the services or recourses.
Issues like that should be reported in different channel.
In case your question is still valid and you still facing this issue, please contact<EMAIL_ADDRESS>Thank you for understanding.


Tgstation.Server version 0.0.0

[ ] Have you signed the Contributor License Agreement?
[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

This was a test

[Policy] Needs-CLA

@microsoft-github-policy-service agree


minor specification document corrections and XLink usage question

regenerate html and PDF documents
correct minor typo and grammar errors
add 'XLinks' definition, see clause_6_0_Global line 51

In this PR I wanted to align the usage of 'XLinks' but I wasn't sure where we stood on that front. Currently, we use the following:

XLink/XLinks (as a noun, e.g. "an XLink" or "using XLinks")
XLink references
XLink relations
XLink (referring to the XLink language I suppose, e.g. "using XLink")

@clausnagel is there are preferred vocabulary for this?
If there is, I can make the changes before we accept the PR. Personally, I prefer using XLinks as nouns vs referring to the language, and using 'XLink references' over 'XLink relations'.

@TatjanaKutzner, Ok I've re-added the brackets to the 2nd rule to leave it marked for discussion and changed occurrences of XLink relations to XLink references.
Is there anything else we want to add for this PR?

@DiegoVinasco Thanks, I think it's fine now. I just corrected some typos.