Allow to specify the tsconfig.json filename explicitly

From @aleksey-bykov on September 22, 2016 16:57
currently VSCode uses the file with the exact name tsconfig.json in the folder as the project file for a typescript project,
i have a few other project files named differently for corresponding sub-projects inside the same folder, I wish there was a way to tell VSCode to use one of them rather then the default tsconfig.json
Copied from original issue: Microsoft/vscode#12463

From @dbaeumer on September 26, 2016 7:5
@waderyan this first needs support in the tsserver IMO. We can't tell tsserver the name or location of a tsconfig.json.

From @aleksey-bykov on September 26, 2016 22:37
no, i have it differently, in the folder structure that you showed there is no problem to compile a sub-project if the VSCode is run from under a sub-folder
my file structure looks like this:
- shared-libs
- shared-assets
- client-side
- server-side
- tsconfig.server.json
- tsconfig.client.json

I want to be able to focus either on tsconfig.client.json or tsconfig.server.json

@aleksey-bykov thank you for opening this issue. I'm not sure I completely understand.
Can you provide a simple example of what you are describing?
Is it something like this?
MainProject/
--- tsconfig.json
--- SubProject-X/
------src/
------tsconfig.json
--- SubProject-Y/
------src/
------tsconfig.json
And your feature request is to have SubProject-Y be able to use MainProject/tsconfig.json?

Interesting. Ok moving to TS repo.

The whole concept of tsconfig.json is to allow the same code to work in different editors by just opening it. this seems like a request to add "solution" file that tells you which "project" or tsconfig.json file to use.
While this is a useful feature, i do not think the complexity to implement it and to support this in all tools warrants the change. I would recommend adding two tscongfig.json files in your folders client-side and server-side, and add an include entry to you shared-libs and shared-assets in both.
One last thing to note, this is not different from other config files like package.json or bower.json.

i am thrilled with your anxiety to close items, isn't there already the --project parameter to tsc why can't there be the same for tsserver?

whole concept of tsconfig.json...

nobody says that the whole concept  is going away, the default case remains, unless said otherwise the default file is tsconfig.json

i do not think...

i respect you opinion, i hope your opinion it's not final (there might be people who think otherwise)

I would recommend adding two tscongfig.json files in your folders...

which turns everything insideout by having to reference the files/projects using ../, would have been ok, but it's not working properly, i tried already

While this is a useful feature

it's not the only scenario, the other ones are:

enabling new features: tsconfig.strict-null-checks-wip.json
building different features/layers of application: tsconfig.essentials-only.json
having personalized configurations for noUnusedLocals and noUnusedParams that are off in developers config to let them develop with comfort, but on at the final build before pushing

this is not different from other config files...

so what does this argument brings? that there are other less than ideal configuration alternatives and that's why it doesn't make sense even to talk about making it better?
please reopen

i am thrilled with your anxiety to close items, isn't there already the --project parameter to tsc why can't there be the same for tsserver?

I am sorry if I offended you closing issues. but I have to look at around 40 issues a day. and I have found that not responding immediate means i will not get to it until a few month has passed and it makes it harder for me to reparse the whole context for the issue.
Closing an issue does not mean you can not respond to them, I have not locked it, intentionally. Also closed issues can be reopened if needed.
Closing an issue means we have no plans to pursue this change at the time being. I would say this is less misleading than leaving it open.

It's okay to disagree but it's not okay to not respect our ability to have a process that results in decisions. This is a software project and it's subject to the constraints of having a finite number of features and behaviors.
It is not preferable that we just leave issues open and pretend we're considering several thousand possible new features at once. Humans, like computers, can only do a finite number of things at once. We're listening to feedback and if we think available data and priorities change, we'll reconsider. That's all we can do.

it's not preferable to keep an issue open so it can gain a little attention? what kind of software project are you working on?

it's not the only scenario, the other ones are:

I am not sure I see how these are all diffrent scenairos, (unless you consider every combination of compiler options a scenario). We have recentlly added support for configuration inheritance.. consider making your default tsconfig.json file somehting like this:
{
    "extends" : "tsconfig.essentials-only.json"
}

then change it when you are ready to try something else to be:
{
    "extends" : "tsconfig.strict-null-checks-wip.json"
}

so what does this argument brings? that there are other less than ideal configuration alternatives and that's why it doesn't make sense even to talk about making it better?

The way tsconfig.json works, and implicit inclusion of files, implicit exclusion, etc.. are all convention-based. so i think the argument that it behaves like package.json is a valid one.

@aleksey-bykov You've been here long enough to know that we have a triage process that we find acceptable and are not interested in changing it at this time. The issue metadata means only what we intend it to mean.
Believing that "Closed" means any "No feedback accepted", "All comments ignored", "Never ever ever going to happen", "Cannot be found from search", or any other thing other than "We have decided not to do this for now" -- these are your own choices. We are not accountable to your personal interpretation of the issue metadata.
This is well-trod territory. We are not going to have thousands of open suggestions. We're faced with an unfixable dilemma:

We have to have issue metadata to track things that have been discussed to a conclusion
People complain when they see metadata they don't agree with

We could adopt a non-transparent metadata system where you couldn't see that we had come to a conclusion on a particular issue. Thousands of suggestions could sit open and idle for years with no clear feedback from the team. I don't think this is what you want, but it's what you're asking for when you complain about issues being marked with the "Closed" metadata.

@mhegazy,
to your question, no, inheriting properties from other project files isn't the problem discussed here, the matter in question is whether tsserver can be explicitly given a project file other than tsconfig.json so that the development environment (VSCode in this case) is able to instantiate it with settings different from the ones found in the default tsconfig.json of the root folder

@mhegazy @RyanCavanaugh
now on closing items versus tagging them
a closed item:

is not shown in the default issues screen (search only considers open items by default)
it not shown in the default search results (search only searches open items by default)
requires some special effort to be found and seen, even if i know it's there, let along can it be ever found by chance

a tagged item:

is displayed on the issues screen no problem by default
is searchable by default
is listed in google results

i don't mind tagging you can tag my item with anything, i do mind closing it before even being seen: this item was opened a day ago, come on, close some month old items that no one cares about
yes, if you say your process is broken as is, because closing really impacts discoverability of an item, even if the item is found by chance the fact that it was closed indicates that something is wrong with it and it's very likely to be ignored rather than read and understood
your process is also broken because any individual with enough perimissions can send an item into oblivion just because:

he didn't understand it
he thought it should be closed, because he might have heard something at the last design meeting, but he doesn't rememeber the details
he has a very special peronal opinion about it
he had a bad day
he accidently clicked a wrong button

a better way forward would be let an item die naturally, by letting it sit generating no traffic, after a month such item can be automatically closed due to the lack of interest
now i feel smart having said that, water is wet

@mhegazy,
to your question, no, inheriting properties from other project files isn't the problem discussed here, the matter in question is whether tsserver can be explicitly given a project file other than tsconfig.json so that the development environment (VSCode in this case) is able to instantiate it with settings different from the ones found in the default tsconfig.json of the root folder

This is already available in https://github.com/Microsoft/TypeScript/blob/master/src/server/protocol.d.ts#L688.

a better way forward would be let an item die naturally, by letting it sit generating no traffic, after a month such item can be automatically closed due to the lack of interest

should we close these issues then?

looks like you can, no one gives a shit

So, something changed? :D


Is there any other example of Options?

Hello, to be honest, the documentation is a little bit confusing. What is the difference between Option and Feature?
And what is the use case of it? Do you have more example (in code)?

The Options and Features section in the documentation tries to explain it and gives some examples.
But it ultimately comes down to how an Option is implement and what exactly it's configuring, so it can be difficult to pin it down exactly. There are different types of Options and they each might define what exactly their Feature is in a different way.
On a technical level:

Options are the Trimmer classes used for configuring aspects of your project. Depending on the Build Profile used, they can be completely compiled out of the build when excluded.
A Feature is an additional flag associated with each root Option in a Build Profile. When the Feature is included, an additional conditional compilation define is set – but otherwise it's up to the Option to decide how to handle the Feature flag.

The basic idea is that there can be two separate things that can be in-/excluded in builds: The Option that allows changing the configuration but also the thing itself that the Option is configuring.
Maybe explaining the different possible combination helps:

Option and Feature included: The functionality is in the build and can be configured at runtime using the Option
Option excluded and Feature included: The functionality is in the build but the configuration of the Option is applied when building and cannot be changed at runtime
Feature excluded: The functionality is removed from the build (including the Option doesn't make sense here)

Some Options might inject a Feature (there are methods on OptionHelper to help implement this), actively remove it when building (e.g. using PostprocessScene, changing the scenes list, not setting conditional compilation defines, etc) or not have a Feature at all (by not setting HasAssociatedFeature in its capabilities attribute). It really depends on what you want to configure with Trimmer and how you prefer to implement it.
For examples, check out the Options included in Trimmer: https://github.com/sttz/trimmer/tree/master/Options

Uhhh... I'm still confused by this...
What should I do if I have this case:
I want some ScriptableObject change it's value depending on which build that I want to do.
For example, the ScriptableObject has a string field, let's call it "text", and for the "Development" build, I want it to be changed to "dev", and for the "Demo" build, I want it to be changed to "demo".
What should I do in this case?
I guess this one should not have Option, because it's supposed to be not changed during runtime. So for the capabilities, I should not include CanIncludeOption, is that right?
Actually side note: I've read that the documentation says that we can change the Option during runtime, but I'm still not sure how.
Then I want it to takes effect when I go to play mode, so I could inspect what is the behaviour when I build it. So I guess, I should include CanPlayInEditor, and do the function with overriding Apply.
Because I want it change the ScriptableObject before building, I guess I should hook the PrepareBuild, and I need ConfiguresBuild, so it will call when it builds.
But how can I configure to execute PrepareBuild or not? Because it seems, it's always called.
And the same thing with the PlayMode, Apply is always called, and it seems I can't disable it.


Fix links in batching.md

Type

[ ] Bug Fix
[ ] New Feature
[ ] Sample
[x] Documetation fix

Related Issues?
None
What is in this Pull Request ?
Fix links in batching article.

Thank you @dc366 for this fix, much appreciated !
Great to have you contributing to this repo 😊


Update slate version and removed deprecations

Hello! I was using your plugin with the latest version of slate and found some annoying warnings about the use of deprecated transforms.
I updated the slate's version and substituted the deprecated transforms with the new ones.
Unfortunately two tests are not passing but I don't think they are related with the new transforms, probably just some other changes to slate core (they are both generated by a TypeError from the raw serializer).

Thanks, I'll fix the remaining tests in an upcoming commit

Whoa thanks for the fast release :)


[os-bind] break-dnssec toggle needed for Enable filter-aaaa on IPv4/IPv6 clients

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
[x] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
[x] The title contains the plugin to which this issue belongs

Describe the bug
Since there's no way to filter AAAA records with Unbound (FILTER_AAAA is not even compiled in) - this features is often needed for things such as Netflix/HBO/Disney+ with IPv6 tunnels / VPNs), the solution is to forward those queries to local BIND instance listening on another port on localhost with domain overrides in Unbound and set BIND to filter AAAA records.
However, this does not work when the domain is signed with DNSSEC. For filtering AAAA with DNSSEC-signed domains, the configuration needs to be as follows:
plugin query "/usr/local/lib/bind/filter-aaaa.so" {
                   filter-aaaa-on-v4 break-dnssec;
                   filter-aaaa-on-v6 break-dnssec;
           };

To Reproduce
Enable filter-aaaa on IPv4 Clients/ filter-aaaa on IPv6 Clients
Query AAAA for some DNSSEC-signed domain.
; <<>> DiG 9.18.19 <<>> AAAA justice.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58965
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;justice.cz.                                        IN      AAAA

;; Query time: 30 msec
;; SERVER: <IP_ADDRESS>#53(<IP_ADDRESS>) (UDP)
;; WHEN: Sat Nov 04 13:32:15 CET 2023
;; MSG SIZE  rcvd: 39

Additional context
Probably easiest to implement with DNSSEC Validation set to No in BIND (could be,a separate toggle for the two filter checkboxes as well).
Environment
Software version used and hardware type if relevant.
e.g.:
OPNsense 23.7.7_3 (amd64).
os-bind plugin: 1.27_1

@doktornotor thanks! as a side note if you want to try and bring the functionality to Unbound I'm ok with that. Port options can be changed :)

Well, after some digging, having the noAAAA feature in Unbound would require plugging the feature to the DNSBL python script. No time for that ATM.
Thanks. 😉


Please invite me to the GitHub Community Organization

Name
Varshika Choudhary
Discord Username (if applicable)
No response
Additional Context
No response

Welcome to the community, @varshika15! 🎉:wave:


Tellstick Net or Duo?

@nfarina @johngson  Thanks a lot for that, will get to it during the autumn break. Please pardon my question if this sounds obvious but I am a noob. Just wondering if you can use Tellstick Net and Duo regardless or is it working better with one? What would you recommend?
My config is homebridge installed on raspbian.
Also wondering if there is a need to specify specific Siri commands (like it used to be the case on Siriproxy) or will she just pick up on anything related to the Telldus Live installation?

I worked on the Telldus platform implementation. I believe you would use "Telldus" with the Duo, and "TelldusLive" with Net.

Thanks a lot! have installed homebridge, tellstick net is running with telldus live but can't get to have siri controlling the thing. I have mytouchhomeapp and see my "fake-homebridge" and "fake-accessory" but can't add any device.
Do you have any advice?


Fix panic when diff

Fix #9173

Codecov Report

Merging #9187 into master will increase coverage by 0.03%.
The diff coverage is 57.14%.

@@            Coverage Diff             @@
##           master    #9187      +/-   ##
==========================================
+ Coverage   41.02%   41.05%   +0.03%
==========================================
  Files         553      553
  Lines       72041    72041
==========================================
+ Hits        29557    29580      +23
+ Misses      38755    38732      -23
  Partials     3729     3729

Impacted Files
Coverage Δ

services/gitdiff/gitdiff.go
66.86% <57.14%> (+3.31%)
:arrow_up:

models/repo_list.go
73.14% <0%> (-0.93%)
:arrow_down:

models/gpg_key.go
55.03% <0%> (-0.56%)
:arrow_down:

routers/repo/view.go
39.47% <0%> (+0.87%)
:arrow_up:

models/unit.go
67.56% <0%> (+5.4%)
: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 6e578dd...db8798b. Read the comment docs.


Fix layout missing email prop

marked as a bug because I also had an error related to email

Warning no longer exists, closing.


Setting example value 'null' to fields in json request body with @Schema, not "null" string without model converter

Hello,
While I was making an API document, I struggled to set value of fields to 'null' in json request body.
I used @Schema annotation because I was in spring boot and kotlin.
At first, I thought that setting "null" in an attribute like defaultValue or example would be helpful.
But it showed "null" string.
So I searched it on the Internet because I thought many people would have faced same issue with me.
With help of Generative AI, I finally found that ModelConverter could solve my issue and solved it.
Below is the way I solved.
@Configuration
class SwaggerConfiguration {
    @Bean
    fun customModelConverter(): CustomModelConverter {
        return CustomModelConverter()
    }

}

class CustomModelConverter : ModelConverter {
    override fun resolve(type: AnnotatedType, context: ModelConverterContext, chain: Iterator<ModelConverter>, ): Schema<*>? {
        var schema: Schema<*>? = null
        while (chain.hasNext()) {
            schema = chain.next().resolve(type, context, chain)
            if (schema.example == "null") {
                schema.example = null
            }
        }

        return schema
    }
}

But It seems that it can be solved in easier way.
For example, in JUnit, @CSVSource can pass argument as null with nullValues attribute.
Below is the sample code, which converts "null" string to null.
@CsvSource(value= {"null"}, nullValues={"null"})

Or it can be set to null if nullable is true and example is not defined.
I'm curious that this issue is being considered to be solved
or many people are satisfied with using model converter
or there is another way to handle it in easier.
Thank you.

@infomuscle could you provide your code snippet from your code of using @Schema as this functionality should already exist?

@ponelat hi, you mean sample code of @Schema to set null value?
If so, I made a pull request #4794 and please refear the link https://github.com/swagger-api/swagger-core/pull/4794.
Or if you didn't mean it, could you explain what you intended again?
Thank you..


I can’t Dectect lame on yellowshoes

I tried everything on windows to get lame to work however I didn’t have a solution to the problem I have  iOS devices and my server that runs use windows

Try placing lame.exe into your %PATH% before launching yellowShoes.
Closing, not a bug of my creation.

hi @elmogosogo09usa , can you please try with this test build and see if that works?

Also I should add different audio formats


Add support for APS 2.3.3

We have to generate the swagger client for APS 2.3.3

Released in v2.3.3:
https://github.com/OpenPj/aps-2x-client/releases/tag/v2.3.3


[CI] Ensure that go.mod files are tidied up

This stems from https://github.com/open-telemetry/opentelemetry-collector-releases/pull/600 where the go.mod and go.sum file were not tidied up after some code changes that removed a Go dependency.
It should be fairly easy to add a tidy check to the CI pipeline.

Hi @mowies I'm an outreachy applicant for the December 2024 cohort. Can I work on this?


Support AUTO_INCREMENT.

This a proposal draft for #43.
SQL Server seems good because it proposes a customizable AUTO_INCREMENT with a "natural language".
### Default value
CREATE TABLE foo (id INTEGER AUTO_INCREMENT);
INSERT INTO foo VALUES {"a": "foo"};
SELECT * FROM foo;
{ "a": "foo", "id": 1}

### Set a start index and an increment value;
###`AUTO_INCREMENT(startIndex, incBy)`
###The first value of the sequence start at 10 and the next is incremented by 5
CREATE TABLE bar (id INTEGER AUTO_INCREMENT(10, 5));
INSERT INTO bar VALUES {"a": "bar"};
INSERT INTO bar VALUES {"a": "baz"};
SELECT * FROM bar;
{ "a": "bar", "id": 10 }
{  "a": "baz", "id": 15 }

AUTO_INCREMENT have to be applied only on number value type. INTEGER and DOUBLE
genji> CREATE TABLE foo(bar TEXT AUTO_INCREMENT);
genji> found text, expected integer, double at line 1, char 27

About ALTER TABLE table_name AUTO_INCREMENT=100, If we keep it like that, we should be able to write the both following syntaxes:
###For default value
ALTER TABLE foo AUTO_INCREMENT=100;

### And this even if the creation was with default value
ALTER TABLE foo AUTO_INCREMENT(100, 10);

Thank you for your feedbacks.

Codecov Report

Merging #250 into master will decrease coverage by 0.20%.
The diff coverage is 45.67%.

@@            Coverage Diff             @@
##           master     #250      +/-   ##
==========================================
- Coverage   61.34%   61.13%   -0.21%
==========================================
  Files          68       68
  Lines        6327     6407      +80
==========================================
+ Hits         3881     3917      +36
- Misses       1933     1961      +28
- Partials      513      529      +16

Impacted Files
Coverage Δ

sql/scanner/token.go
22.22% <ø> (ø)

database/table.go
54.15% <18.18%> (-3.11%)
:arrow_down:

sql/parser/create.go
65.62% <53.84%> (-3.01%)
:arrow_down:

database/config.go
67.31% <57.57%> (-1.28%)
:arrow_down:

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 7788929...728fdd2. Read the comment docs.

@tzzed thanks for your work! What’s the current status of this PR? It looks like the counter is not being persisted.

Step 1
tie@xhyve ~/genji/cmd/genji $ go run . bolt.db
On-disk database using BoltDB engine at path bolt.db.
Enter ".help" for usage hints.
genji> CREATE TABLE foo (id INTEGER AUTO_INCREMENT);
genji> INSERT INTO foo VALUES {"a": "foo"};
genji> SELECT * FROM foo;
{
  "a": "foo",
  "id": 1
}
genji> .exit

Step 2
tie@xhyve ~/genji/cmd/genji $ go run . bolt.db
On-disk database using BoltDB engine at path bolt.db.
Enter ".help" for usage hints.
genji> SELECT * FROM foo;
{
  "a": "foo",
  "id": 1
}
genji> INSERT INTO foo VALUES {"a": "foo"};
genji> SELECT * FROM foo;
{
  "a": "foo",
  "id": 1
}
{
  "a": "foo",
  "id": 1
}
genji> INSERT INTO foo VALUES {"a": "foo"};
genji> SELECT * FROM foo;
{
  "a": "foo",
  "id": 1
}
{
  "a": "foo",
  "id": 1
}
{
  "a": "foo",
  "id": 2
}
genji> .exit

I just submitted the idea, before push the persistance. It was draft.
What do you think about the proposition?

Looks nice! I’d also suggest using AUTOINCREMENT as a keyword (underscore feels weird).
Though I’m not quite sure what we actually want from the auto increment feature. E.g. in SQLite it guarantees monotonically increasing 64-bit integer sequence for rowid (pk() in Genji) with an error on overflow. Also, I think it’s possible to compute non-primary key auto incremented value with (start, step) parameters given a document sequence number.
See also

https://sqlite.org/autoinc.html
https://sqlite.org/fileformat2.html#seqtab

Note that we currently don’t handle integer overflows for sequence numbers.

If the AUTOINCREMENT keyword appears after INTEGER PRIMARY KEY, that changes the automatic ROWID assignment algorithm to prevent the reuse of ROWIDs over the lifetime of the database. In other words, the purpose of AUTOINCREMENT is to prevent the reuse of ROWIDs from previously deleted rows.
https://sqlite.org/autoinc.html

Thank you @tie ! In view of the documentation, this PR is more complex than I though. @asdine can you revert it. We should create a new table and more...
Thanks

Trying to understand whether auto incrementing primary keys work, even though this PR wasn't accepted. The documentation says:

This will create a table teams that can hold any document. An auto-incrementing primary key will be generated every time a document is inserted.

However, in a quick test locally this doesn't seem the case - at least not with only a CREATE TABLE mytable; schema. Do auto incrementing ID fields require a full schema specification?

Trying to understand whether auto incrementing primary keys work, even though this PR wasn't accepted. The documentation says:

This will create a table teams that can hold any document. An auto-incrementing primary key will be generated every time a document is inserted.

However, in a quick test locally this doesn't seem the case - at least not with only a CREATE TABLE mytable; schema. Do auto incrementing ID fields require a full schema specification?

@mrusme For now, only auto generated "docids" are generated. These are internal IDs, equivalent to SQLite's rowids.
You can select them using SELECT pk() FROM foo; but like rowids you have no guarantee that they will always be the same.
Regarding auto incremented user defined primary keys, they are not supported yet.
I suggest using uuids or equivalent for now, until the feature is implemented.

@mrusme For now, only auto generated "docids" are generated. These are internal IDs, equivalent to SQLite's rowids.
You can select them using SELECT pk() FROM foo; but like rowids you have no guarantee that they will always be the same.
Regarding auto incremented user defined primary keys, they are not supported yet.
I suggest using uuids or equivalent for now, until the feature is implemented.


[feature request] oobabooga webui support

would this work with oobabooga webui?

I haven't tested it but it should work just fine. You could try replacing WebUI with oobabooga service in docker-compose.yml. Then point oobabooga to openAI api at http://openresty:80/v1

Or you could remove the WebUI from docker-compose.yml and just run remaining 2 services. Expose port 80 from openresty service on your host or add it to docker network from your separate oobabooga docker-compose project.


when makeAccessibleGlobally=true, typing an unknown position name throws an error

Describe the bug
When the setting makeAccessibleGlobally is set to true, typing an unknown position name to retrieve a known player's personal position, an error occurs.
To Reproduce
Steps to reproduce the behavior:

Use settings 'personalposition.makeAccessibleGlobally=true'
Enter command '/personalposition playername positionname'
See error: 'An internal error occurred while attempting to perform this command.'

Expected behavior
A message showing up with a text similar to: 'This position name is unknown in playername's personal positions.'
Minecraft:

Client Badlion 1.17.1
Server Paper 1.17.1 #228
Plugin 0.3

fixed in commit a440ea7


OSL switch node

Hi @johnhaddon ,
I'd like to create a switch node for OSL network, but ideally it would type independent, do you have any suggestions?
Cheers

Hi Lucien,
I don't think we can make it type independent I'm afraid, unless you want to create a shader which contains all types and has multiple outputs, one for each type. The existing ShaderSwitch is kindof what you want (and works with all shaders, not just OSL), but can only be plugged into a ShaderAssignment.
In Gaffer, an "untyped" connection would be represented by an instance of Plug (not a derived class), so the untyped output of a ShaderSwitch is also a Plug. The ShaderAssignment input is also a Plug so this works. But the plug for a colour input (for instance) on another shader will be a Color3fPlug, and won't accept an untyped input. There's not really any getting around that.
You could instead do some jiggery pokery in the UI to generate different plug types automatically based on what was dragged onto the node (we do something like this for Dots), but it wouldn't be pretty, and it certainly wouldn't be a case of just writing an OSL shader any more.
I'm going to close this issue, because I'd like issues to be used for work which is reasonable clearly defined (or at least believed to be possible!), and that we intend to schedule at some point, rather than for general discussion. Since we've started here, feel free to continue, but for future discussions I think the gaffer-dev mailing list or internal IE email would be best.
Cheers…
John


Repo still needed?

Hi @mcleo-d !
I see that this repo was never used; is this still needed or shall we archive it?
TIA!

Correct, we moved away from this strategy and the repo will not be used

https://github.com/finos/community/issues/238


Router-executor revert errors not bubbled up to users

Describe the bug
Router-executor revert errors not bubbled up to users.
To Reproduce
Steps to reproduce the behavior:

Send a transfer that will fail in slow path, due to slippage error.
Notice error seen in Router-executor is not seen on UI

Additional context
Router-executor should send to sequencer even on errors, especially in the case of relayer fee or slippage errors, so that sequencer can parse the revert, and update transfer error status on carto db, so that the execution error is user visible.

Proposed solution:

Don't run the estimate on the router side.
Send bids from router to sequencer
At sequencer, if the selected bid from the auction estimate fails;

if it errors, log the error at DB & run the auction again to select a new bid.
else if Error is related to bump slippage or relayer fee exponentially bump the time to run the auction for the transfer.
Also mark the bid with the error it fails at the cache.

Stop running the cycle for all the bids before we run the auction, that just increases the computation(not sure if we are doing this though)


Catch exceptions in main()?

I expect that exception handling is usually supported by a C++ program. I wonder why your function "main" does not contain corresponding try and catch instructions so far.
How do you think about recommendations by Matthew Wilson in an article?
Would you like to adjust the implementation if you consider effects for uncaught/unhandled exceptions like they are described by Danny Kalev?

Hello elfring,
Thanks for providing those links, they were interesting and I learned a few things!
I will be leaving the main function as it is. I meant for the main method to contain a simple example for how to use the FluidSimulation class and I would like to keep that method as uncluttered as possible. The user is free to add in exception/error handling when using the FluidSimulation class themselves.
I did modify the public methods in the FluidSimulation class to throw exceptions on invalid input instead of triggering assertions.
Best Regards,
Ryan

Thanks for your small source code improvement.


Error "Received function must be a mock or spy function" when passing a stub to expect(...).toHaveBeenCalled()

Describe the bug
A stub is not accepted as such, because the expect matchers check for a symbol which the stub function does not seem to set.
Steps to Reproduce

Create a file main_test.ts with the contents
import {stub} from 'jsr:@std/testing/mock';
import {expect} from "jsr:@std/expect";

Deno.test(function someTest() {
    const fetchStub = stub(globalThis, 'fetch', () => Promise.resolve(new Response(JSON.stringify([]))));

    await fetch('');

    expect(fetchStub).toHaveBeenCalled();
});

Run the command deno test

See error
error: Error: Received function must be a mock or spy function
throw new Error("Received function must be a mock or spy function");
      ^
at getMockCalls (https://jsr.io/@std/expect/1.0.5/_mock_util.ts:18:11)
at toHaveBeenCalledWith (https://jsr.io/@std/expect/1.0.5/_matchers.ts:540:17)
at applyMatcher (https://jsr.io/@std/expect/1.0.5/expect.ts:218:13)
at Proxy.<anonymous> (https://jsr.io/@std/expect/1.0.5/expect.ts:228:13)

Expected behavior
The test should pass.
Environment

OS: alpine running on docker engine in Ubuntu WSL on Windows 10
deno version: 2.0.2
std version:

<EMAIL_ADDRESS><EMAIL_ADDRESS>

The current stub/spy's are not directly compatible with expect. You can however workaround this by using fn as an intermediate for the spy tracking. For example:
import {stub} from 'jsr:@std/testing/mock';
import {expect, fn} from "jsr:@std/expect";

Deno.test(function someTest() {
    const mockFetch = fn(() => Promise.resolve(new Response(JSON.stringify([]));
    const fetchStub = stub(globalThis, 'fetch', mockFetch);

    await fetch('');

    expect(mockFetch).toHaveBeenCalled();
});

That said fn is not typed to Function for input/output so it requires casting. I've been meaning to file a GH issue about fn typing as well.

@std/testing/mock and @std/expect are not supposed to work together.
If you use stub from @std/testing/mock, please use assertions in the same module (such as assertSpyCall)
If you prefer to use mock assertions from @std/expect, then use fn in @std/expect for stubbing/mocking/spying as @andrewthauer suggests


checkDeviceTypeOverride will now detect a cl device if not given one

Previously multiple test_image_stream.exe tests were failing because the test would not use the right device type if not given one. Now, when the test uses checkDeviceTypeOverride to check for device types, it now detects the device type in addition to previously checking for environmental variables.
All image tests passed when ran.

Hi,
I've moved gDeviceType to imageHelper.cpp/.h and it seems to be ok, but I have a bit of an issue trying to set gDeviceType in checkDeviceTypeOverride, in testharness.c., as testharness.c does not have an include for imagehelper.h, and including that brought some unresolved external symbols. Should I try resolve these symbols, or should something else be done?

Hi,

I've moved gDeviceType to imageHelper.cpp/.h and it seems to be ok

Great! I suggest you create a PR already for that change alone. This is unambiguously good and we can get this out of the way.

but I have a bit of an issue trying to set gDeviceType in checkDeviceTypeOverride, in testharness.c.

Hmm, why did you keep checkDeviceTypeOverride?

including that brought some unresolved external symbols. and other conflicts. Should I try resolve these symbols and conflicts, or should something else be done?

It's hard for me to help without seeing the exact issues/conflicts. Could you comment with some specifics?

Hi,
Sorry for the clutter above. I misclicked a few things there.
A new PR was created for the first step here: https://github.com/KhronosGroup/OpenCL-CTS/pull/575.
When I mentioned checkDeviceTypeOverride, I mean runTestHarnesswithCheck. I mixed those two up by mistake. I've talked with someone about the issue I was having, and I think I have a solution for step 2. I will try to finish that, and report if I have any other issues.

No worries!

Hello,
I have an update on step 2. Currently I have what it seems to an issue between header files. In order to access the variable gDeviceType from imageHelper.cpp/.h from testharness.c, I have written an include statement. There were several attempts to then assign gDeviceType, but they have all errored.
The first attempt was to define gDeviceType as a global in testHarness.c and then assign it in runTestHarnessWithCheck, but the build errored with gDeviceType already defined.
The second attempt was to not define gDeviceType as a global, and just straight up assign it in the function. However, the build errored with unresolved external symbol "bool gTestRounding", which is declared as an extern in imageHelper.cpp.
I have also tried other ways to access gDeviceType, such as declaring an extern cl_device_type gDevicetype in testharness.cpp or .h, but anytime it seems try to access the correct gDeviceType, comes with a conflict of gTestRounding.
How should I proceed with this conflict?

Hi,
I'm not sure I understand the problem. What's wrong with including imageHelpers.h in testHarness.c?

Hi,
I'm not exactly sure what exactly are you not sure about. When I try to access gDeviceType from imageHelpers.h, when building, it errors with a unresolved external symbol "bool gTestRounding". It is a strange situation as gTestRounding was not touched at all.
In addition to the #include, Here's the change I've done to assign gDevicetype, just for testing purposes:
![gdevicetype](https://user-images.githubusercontent.com/57198431/73883257-9e05d080-4831-11ea-823
Here's the build errors:

8-d449c7530f81.png)

Ok, I've pinpointed the issue.
gTestRounding is declared as an extern used in a function in imageHelper.cpp, set somewhere else. Whatever includes imageHelpers.h, has access to that function (being generate_random_image_data), therefore needs gTestRounding defined and set.
When I try to include imageHelpers.h in testharness.c, not all that use testharness.c (usually using the function runTestHarnesswithCheck) has a gTestRounding set, and consequently erroring due to gTestRounding not set for generate_random_image_data.
Setting gTestrounding in testharness.c does not work, as it yields an error saying the variable "gTestRounding" already declared. The brute force way is to set gTestRounding in every file that has an instance where testharness.c is used but has not yet set gTestRounding. This solves the issue, but produces redundant code.
Is there a better way you think could resolve this issue better?

Have you tried to move gTestRounding to imageHelper.{cpp,h}? Looking around, it seems that this should work.

I'm looking into that, but I ran into more errors as I solve gTestRounding:
harness.lib(imageHelpers.obj) : error LNK2005: "int __cdecl DetectFloatToHalfRoundingMode(struct _cl_command_queue *)" (?DetectFloatToHalfRoundingMode@@YAHPEAU_cl_command_queue@@@Z) already defined in utils.obj [C:\Users\jiabaxie\Deskto
p\ConformTest\OpenCL-CTS\build\test_extensions\media_sharing\test_media_surface_sharing.vcxproj]
There's a couple of these errors with the same message, namingly:
int __cdecl DetectFloatToHalfRoundingMode(struct _cl_command_queue *)
unsigned short __cdecl convert_float_to_half(float)
float __cdecl convert_half_to_float(unsigned short)
I'm not too sure how to resolve these.

Hmm, we have two copies of that function (https://github.com/KhronosGroup/OpenCL-CTS/blob/master/test_extensions/media_sharing/utils.cpp#L1588 and https://github.com/KhronosGroup/OpenCL-CTS/blob/master/test_common/harness/imageHelpers.cpp#L2929). They've diverged but looking at the diff it seems the copy in the media sharing tests just wasn't updated as helpers were introduced in the common code. Two options:

Fully solve the issue now: get rid of the copy in the media sharing tests and use the one from the image helpers there. This probably should be a separate pre-requisite change.
Hack your way around it and defer the full resolution: rename the function in the media sharing tests and create an issue to address this.

@jiabaxie Are you still working on this issue?

Hi kpet,
Yes I am. I recently had to switch locations and I got hung up on some setup. My plan is to attempt to solve the issue and if too much trouble comes across I will create an issue to address it instead.
Thanks

Great, thanks!

Ok, I took a look at these functions, and they are identical except DetectFloatToHalfRoundingMode, which has a small amount of difference. Simply removing these three functions from utils.cpp seems ok. No errors from building occurred. Do you know a reliable way of testing that the tests using utils.cpp functions correctly?
After moving gTestRounding to imageHelpers.cpp/.h everything seemed ok. I've set gDeviceType in testharness.c. I will make a new PR for this shortly
Thanks


Expose rule & group evaluation

Exposes rule & group evaluation from rules package, so other Go code can evaluate parsed rules.
Context: I'm looking at doing multi-tenant recording rules for https://github.com/weaveworks/cortex. While we could get something extremely kludgey working with the existing public methods, exporting a bit more will probably help us.
I haven't yet experimented with actually using the changes in this PR, but intend to do so immediately after submitting it.
I spoke a bit with @fabxc about this on IRC today. Summary:

rules implementations parse queries on each evaluation, which is less than ideal
implementing #1595 and #1095 could help quite a lot

I don't think either of those ought to prevent this PR, but would be happy to learn otherwise.

👍


QT5.6: Fixes compile error with wrong LD env variable

QT uses -Wl linker flags and these flags only work with gcc/g++
and not with LD directly.
Motivation for this change
Things done
Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers.

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Fixed :)

Now it finally should work! First I hard $GCC and replaced that with $CC, but it needed to be $CXX. :) On my laptop it compiled now with my latest commit.


XFULLHD Sophie Rain Spiderman Viral Leaks Video On Social Media X Twitter[1980K]

XFULLHD Sophie Rain Spiderman 2024
10 sec ago Sophie Rain Spiderman, XFULLHD Sophie Rain Spiderman Viral Leaks Video On Social Media X Twitter[1980K]

Sophie Rain Spiderman's recent video has gone viral across social media platforms, captivating audiences and sparking widespread discussion. The young digital creator has gained significant attention for her engaging content, particularly her latest Spiderman-themed video, which has taken the internet by storm. Viewers are eager to find out where they can watch the full video, with many turning to platforms like Instagram, Twitter (X), and Discord for access.
As the buzz around Sophie Rain Spiderman continues to grow, fans are sharing their excitement and reactions online. The viral nature of her video highlights the power of social media in propelling creators into the spotlight. With her unique style and creativity, Katherinne has quickly become a notable figure in the digital landscape, leaving many curious about her future projects and content.


Multiple secondary keys from a single record

According to the documentation regarding secondary keys a custom function can be defined in the macro that can be used to finagle a secondary key from the user's struct.
The following tells native_db to use the user-supplied function custom_name to get the secondary key for the struct:
#[derive(Serialize, Deserialize)]
#[native_model(id=1, version=1)]
#[native_db(secondary_key(custom_name, optional))]
struct Data {
    #[primary_key]
    id: u64,
    #[secondary_key]
    name: String,
    flag: bool,
}

I wonder, is #[secondary_key] necessary if #[native_db(secondary_key(custom_name, optional))] is defined?
The user-defined custom_name function returns an Option<String> as the secondary key:
impl Data {
    fn custom_name(&self) -> Option<String> {
        if self.flag {
            Some(self.name.clone().to_uppercase())
        } else {
            None
        }
    }
}

Since, according to the documentation, users can define "define it or not, define one or more" I assume it should be possible to return multiple secondary keys for a single struct?
If so, I'd like to propose an additional secondary_keys definition that can return a Vec<T> rather than an Option<T>. If the secondary key isn't optional, an empty Vec would fail.
I get the impression that native_db's internal structure should support this, it's just a matter of implementing the feature? Any thoughts?

I wonder, is #[secondary_key] necessary if #[native_db(secondary_key(custom_name, optional))] is defined?

Actually, no, it's not linked. You can have as many secondary_key associated with fields as you have custom secondary_key defined in the macro.
Here are some examples:

Two secondary keys on two distinct fields secondary_key_attribute.rs#L133-L136.
Two custom secondary keys with_secondary_keys.rs#L38-L39.
Each time it is a new key whether it is custom or not, you can have a mix of the two without any problem. And you can create as many as you want.

Does this answer your questions?

Thank you, yes that did answer my question.
I still think it would be very useful to be able to return an arbitrary number of secondary keys for a record using a function or by implementing a trait for the struct?
Just a hypothetical example here - let's say each struct in the database represented a country. A person could use an enum as a key:
enum CountryKey {
    City(String)
    State(String)
}

struct CountryValue {
    cities: Vec<String>,
    states: Vec<String>,
}

let united_states = CountryValue {
    cities: vec!["Houston", "San Antonio", "Galveston"],
    states: vec!["Texas],
}

The custom function could return a collection of cities and states. For example:
&[City("Houston"), City("San Antonio"), City("Galveston"), State("Texas")]

And then when searching by City("Houston") or State("Texas") the database could return the Country record for the United States.

Thank you, yes that did answer my question.
I still think it would be very useful to be able to return an arbitrary number of secondary keys for a record using a function or by implementing a trait for the struct?
Just a hypothetical example here - let's say each struct in the database represented a country. A person could use an enum as a key:
enum CountryKey {
City(String)
State(String)
}
struct CountryValue {
cities: Vec,
states: Vec,
}
let united_states = CountryValue {
cities: vec!["Houston", "San Antonio", "Galveston"],
states: vec!["Texas"],
}
The custom function could return a collection of cities and states for the CountryValue. For example:
[City("Houston"), City("San Antonio"), City("Galveston"), State("Texas")]
And then when searching the database by City("Houston") or State("Texas") the database could return the CountryValue record for the "United States".

It's an interesting idea, I see several things in your example:

The fact of having multiple values available for search for a single secondary key. And the possibility to search by value.
The fact that a custom type like City is used as a key.

For the first case: it could be possible, do you have a specific use case in mind?
For the second case: you are right, it should be possible to add these custom types in the search. I will open a PR for that. https://github.com/vincent-herlemont/native_db/pull/149


General JSX Transformer

Great project! I made a general JSX transformer, babel-plugin-transform-jsx if you are interested in recommending that and avoiding /* @jsx h */ comments and even repetitive imports.

Nice work.  Any chance you'd be interested in making the property names configurable?  Preact VNodes use nodeName instead of elementName to match the DOM's API, but otherwise everything else would be identical.  That would mean people could use the plugin without modification to their code:
{
  "plugins": [
    ["transform-jsx", { "function": "h", "useVariables": true }]
  ]
}

Or another thought - provide a "to hyperscript" option.  Preact's h() is intentionally identical to the hyperscript spec in order to be interoperable.  That way people could use babel-plugin-transform-jsx with preact, vhtml and hyperscript right out of the box!  Perhaps that warrants a wrapper plugin, I'm not sure.  Curious to hear your thoughts - I would love to encourage everyone to understand the relationship between JSX and hyperscript a bit better, this could be a neat way to promote that.

@calebmer

I do this in webpack:
Babel loader:
{
  loader: 'babel',
  test: /\.jsx?$/,
  exclude: /node_modules/,
  query: {
    cacheDirectory: true,
    presets: ['es2015'],
    plugins: [
      'transform-class-properties',
      ['transform-react-jsx', {
        pragma: 'jsx'
      }]
    ]
  }
}

Provide plugin:
new ProvidePlugin({
  jsx: resolve('src/jsx.js'),
})

and jsx.js:
const preact = require('preact');
module.exports = preact.h;

This way I don't need to define any pragma nor import Preact everytime when I need to use JSX. Probably makes sense to provide Component this way too.

Nice! Might steal that.

would be nice if you could inline that somehow, not requiring the extra file
but I don't think my IDE or ESLint would agree with providing Component that way

I just had a PR merged into webpack to eliminate that extra file
https://github.com/webpack/webpack/pull/3597
So in the next webpack release you can just do:
new ProvidePlugin({
  jsx: ['preact', 'h']
})

@gdub22 very nice

would be nice if you could inline that somehow, not requiring the extra file

It can be this way right now:
new ProvidePlugin({
  preact: 'preact'
})

{
  loader: 'babel',
  test: /\.jsx?$/,
  exclude: /node_modules/,
  query: {
    cacheDirectory: true,
    presets: ['es2015'],
    plugins: [
      'transform-class-properties',
      ['transform-react-jsx', {
        pragma: 'preact.h'
      }]
    ]
  }
}

I just had a PR merged into webpack to eliminate that extra file

That's great!
But anyway, I'm totally fine with an additional file since it doesn't harm anything for me.

@developit

Nice! Might steal that.

Take it! Take it! 😄

well, yeah, I'm currently using the imports-loader
['transform-react-jsx', { pragma: 'preact.h' }]

{
  test  : /\.jsx$/,
  loader: 'imports-loader',
  query : {
    preact: 'preact',
  },
}

but just h will be nice with the next version of webpack

I think we can close this out now - there are 3 or 4 great solutions including the original posted here :)

Just to let it here.
I used this to make it work:
{ "pragma": "require('preact').h" }


KARAF-7817: Upgrade Spring Security features to 5.7.12/5.5.3/5.1.6

I'm releasing the needed SMX bundles (vote will start soon).


RADIUS attributes on Mikrotik

Currently Casdoor supports RADIUS protocol yet you have to pass a Class attributes to determine the organization. This somehow not supported by Mikrotik (correct me if I'm wrong). Is it possible to add a new config to mark an organization as the default fallback if Class attributes is not provided?

@satoufuyuki @MrT3acher can you make a PR?
I want a config in app.conf can be recognized to do this job if it exists. But that config doesn't need to exist to have default value in this repo. Because it's a little trivial feature to me.  Mikrotik does authentication using CHAP protocol through Radius. but Casdoor just implemented the plaintext username and password authentication through Radius.
Mikrotik sends these attributes too:
CHAP-Challenge
CHAP-Password
Message-Authenticator

I tested this changes. but It doesn't work for Mikrotik. there is another problem. Mikrotik does authentication using CHAP protocol through Radius. but Casdoor just implemented the plaintext username and password authentication through Radius. Mikrotik sends these attributes too:
CHAP-Challenge
CHAP-Password
Message-Authenticator

You can actually use password authentication instead of CHAP, just make some tweak on the Mikrotik RADIUS's config.

I need it too! I used a custom build that set organization to "built-in" if Class attribute doesn't exist. (https://github.com/MrT3acher/casdoor)

I forked this repo (https://github.com/ict-neskar/casdoor) and added the default organization and also a default role/group to whitelist RADIUS login.

I tested this changes. but It doesn't work for Mikrotik. there is another problem. Mikrotik does authentication using CHAP protocol through Radius. but Casdoor just implemented the plaintext username and password authentication through Radius. Mikrotik sends these attributes too:
CHAP-Challenge
CHAP-Password
Message-Authenticator

You can actually use password authentication instead of CHAP, just make some tweak on the Mikrotik RADIUS's config.

How can I do it on Mikrotik? I couldn't find any solution.

I could do it.
/ip hotspot profile add hotspot-address=<IP_ADDRESS> login-by=cookie,http-pap name=hsprof1 use-radius=yes
/radius add accounting-port=1812 address=<IP_ADDRESS> require-message-auth=no service=hotspot

the point is:

http-pap
require-message-auth=no


conditional logic for YAML interface

YAML conditional logic

Vote on this issue by adding a 👍 reaction
If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details
My Pulumi project has multiple stacks where a stack == environment.
I would like to be able to utilise conditional logic via YAML to define projects and resources based on active stack (where stack = environment).
I have achieved this previously using a python wrapped terraform propriery solution in which jinja2 syntax was defined along with YAML to control file parsing.
Would it be possible to introduce:

Default behaviour in which the current active stack name is inferred via new YAML interface during preview / deploy and
utilised via some rudimentary template language that wraps definition blocks within the Pulumi.yaml file?

Affected area/feature

Dupe - closing


Error Message In Log

Great project by the way!
When I start a server with SimpleDLNA.exe I see a bunch of reoccuring errors in the log. Everything appears to work fine though and I can still browse the folders from my DLNA client. I am not sure if the port binding error is causing some other problem, but I thought I would at least report it.
2013-12-23 10:31:24,261  DEBUG [  1] HttpServer     - Registered Handler for /icon/
2013-12-23 10:31:24,305   INFO [  1] HttpServer     - Running HTTP Server: WIN64/6.2 UPnP/1.0 DLNADOC/1.5 sdlna/0.13 on port 53015
2013-12-23 10:31:24,313   INFO [  1] SsdpHandler    - SSDP service started
2013-12-23 10:31:41,197   INFO [  6] FileStore      - FileStore at C:\Users\Nathan\AppData\Local\Temp\sdlna.cache is ready
2013-12-23 10:31:41,397  DEBUG [ 10] Thumbnailer    - thumber started
2013-12-23 10:31:41,406  DEBUG [  6] HttpServer     - Registered Handler for /mm-1/
2013-12-23 10:31:41,439  DEBUG [  6] SsdpHandler    - NotifyAll
2013-12-23 10:31:41,444  DEBUG [  6] SsdpHandler    - NotifyDevice
2013-12-23 10:31:41,471  ERROR [  6] Datagram       - System.Net.Sockets.SocketException (0x80004005): The requested address is not valid in its context
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at NMaier.SimpleDlna.Server.Ssdp.Datagram.Send()
2013-12-23 10:31:41,473  ERROR [  6] Datagram       - System.Net.Sockets.SocketException (0x80004005): The requested address is not valid in its context
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at NMaier.SimpleDlna.Server.Ssdp.Datagram.Send()
2013-12-23 10:31:41,474  ERROR [  6] Datagram       - System.Net.Sockets.SocketException (0x80004005): The requested address is not valid in its context
   at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
   at System.Net.Sockets.Socket.Bind(EndPoint localEP)
   at NMaier.SimpleDlna.Server.Ssdp.Datagram.Send()

I have the same issue. I had to disable the VirtualBox Host-Only and Ethernet adapters to get it to work.


Fix broken links for formatting in 1.23.3 docs

See https://github.com/detekt/detekt/issues/6602
Turns out links are actually broken in the website for formatting in the 1.23.3 docs. I'm fixing them.

Warnings

:warning:

It looks like you're editing the versioned copy of our website. This affects only users on the 'current' version of detekt, and it's correct only if you intend to fix the documentation for an already released version of detekt. Most of the time you want to update also the docs inside website/docs/ as well, so this change will reflect also for documentation on future versions of detekt.

Messages

:book:

Thank you very much for making our website better :heart:!

  Generated by :no_entry_sign: dangerJS against 57a8e103355d7809a83016e3c4322a677901c6e9


Minify JS with source map

To reduce JS size and increase page load times, you can use projects like UglifyJS to minify JS and let it output sourcemaps to continue to provide a pleasant debugging experience.

https://github.com/mishoo/UglifyJS2
http://www.html5rocks.com/en/tutorials/developertools/sourcemaps/

There are many ways to do it, but it can be very simple:
var result = UglifyJS.minify({"file1.js": "var a = function () {};"}, {
  outSourceMap: "out.js.map",
  fromString: true
});

// or

var result = UglifyJS.minify([ "file1.js", "file2.js", "file3.js" ], {
  outSourceMap: "out.js.map"
});

The problem with these is that they rely on nodejs, and I don't want to make that a dependency of Flexx. Ideally we'd use a pure-Python minifier (Flexx includes a very minimalist one that removes comments etc. but keeps the code readable (because it does not do sourcemaps). Another option might be to make nodejs an optional dependency.

Maybe there is stuff that we can use from https://github.com/django-compressor/django-compressor/tree/develop/compressor

Another option is to generate minified JS by the parser itself. It already has AST, so it should be well-capable to e.g. shorten variable names.

Did you see the section "Building for the browser"?
http://lisperator.net/uglifyjs/
Maybe you can vendor it?

But then Flexx would first need to spin up a (local) browser send it the JS, get the JS back, and then spin up the actual browser with the app?

You raise a good point! I stand corrected. :)

Source maps explanation: https://www.schneems.com/2017/11/14/wtf-is-a-source-map/

Issue moved to flexxui/pscript #10 via ZenHub


Multiple Choice / String Combo question

Sometimes we want to give the user multiple choice for values, but sometimes there will be something we don't have in the list.
For example, it would be nice for the key cuisine to have a list of possible values, but we dont want to present some obscure value. We might want to provide Mexican, but what if the user comes across a Tibetan restaurant?

Maybe something like this:
http://stackoverflow.com/questions/17795156/adding-edittext-alongside-radiobutton


Overhaul of Set#members needed

Right now, handling the content of character sets with regexp_parser is hard:

The Scanner only detects few ranges successfully, as detailed in issue #29.
The Scanner returns inconclusive information about member tokens because they all have the type :set. Issue #28 describes this for properties, but it also affects \a, \e, \n, \t, \u, \v and more.
The Parser then "throws away" even this limited information as it only relays the Token#text to Set#members. (Re-running Parser#parse on individual Set#members is a poor workaround for this.)

What I have in mind as a general solution is the following:

removing the :subset token type, leaving #set_level to differentiate between sets and subsets
using the :set token type only for tokens that are particular to sets ([, ^, &&, ] and ranges)
removing the :member, :member_hex, :range and :range_hex tokens
treating set ranges and members like any other sub-expression instead
removing the attr Set#members, leaving #expressions to access members, ranges and subsets

Thus, parsing /a[bc-d]/ could yield something like
#<Root @expressions=[
  #<Literal @type=:literal, @token=:literal, @text="a" >,
  #<CharacterSet @expressions=[
    #<Literal @type=:literal, @token=:literal, @text="b" >,
    #<Range @type=:set, @token=:range, @expressions=[
      #<Literal @type=:literal, @token=:literal, @text="c" >,
      #<Literal @type=:literal, @token=:literal, @text="d" >
    ]>
  ]>
]>

The only tricky bit is rewiring the ragel machines in the right way and catching all ranges.
On the other hand, it would probably lead to less code, as special treatment is only needed for a few things within sets: the set tokens plus ., \b, and [:...:] if I am not mistaken.
What do you think, @ammar?

Thanks for this @janosch-x.
Characters sets are the poorest implemented part of the scanner. Barely satisfied the most basic of cases.
I like the approach you outlined. Removing :subset and treating :set members as sub-expressions is a great idea. It should simplify the scanner and its use.
I wonder if extracting the character set scanning logic into a sub-machine, like properties.rl, would make it easier to implement the changes. it might require breaking scanner.rl into smaller parts, which could be a good thing. I'd like to explore that a little, soon hopefully.

I wonder if extracting the character set scanning logic into a sub-machine, like properties.rl, would make it easier to implement the changes.

Thats what I thought, too. I might be able to help a bit with the whole thing, at least by setting up tests beforehand.
Another thing that just crossed my mind is that it could make sense to have an Intersection expression with subexpressions as well. Right now, you have to keep track of the preceding and succeeding set member yourself to find out what is being intersected. We could do something like this instead:
Regexp::Parser.parse(/[a-c&&b]/) # =>
#<Root @expressions=[
  #<CharacterSet @expressions=[
    #<Intersection @type=:set, @token=:intersection, @expressions=[
      #<Range @type=:set, @token=:range, @expressions=[
        #<Literal @type=:literal, @token=:literal, @text="a" >,
        #<Literal @type=:literal, @token=:literal, @text="c" >
      ]>,
      #<Literal @type=:literal, @token=:literal, @text="b" >
    ]>
  ]>
]>

The least complicated way to achieve this might be doing it purely in parser.rb, kind of the same way alternation expressions are handled.

resolved by #55


Remove repo.spring.io/release from pom.xml in where-for-dinner

Unauthenticated access to repo.spring.io/release will be rejected starting January 26
See: https://spring.io/blog/2022/12/14/notice-of-permissions-changes-to-repo-spring-io-january-2023

Merged


Change Order of Function Args to align with docs

newDebtAmortizationCustomPeriodLength($debtPrincipal, $debtNoOfPeriods, $debtInterest, $debtSinglePeriodLength)

Thank you, I haven't noticed this. I merged your change and updated the test concerning this method.


Add error reporting for invalid values

Please check if the PR fulfills these requirements

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

[X] Bugfix
[X] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[X] Other... Please describe: Examples update

What is the current behavior?
See #31 - invalid breakpoint names are not reported and it messily explodes
There was also a bad example in test.scss
What is the new behavior?
If the user submits a value not a keyword (up, down, retina) and not in the breakpoints map, a pretty error is shown during the build time.
Fixes an error in test.scss
Does this PR introduce a breaking change?

[ ] Yes
[X] No

Github Issue(s) this is regarding:
Fixes #31

Note that the validation function returns a value needlessly. Function have to return a value, so something had to placed there, unfortunately.

No tests? :'(


Collate scraped data files

Aggregate scraped (daily) data files at end of month.

CBOE data has minute resolution.
We will fetch data once per day at specified time (eg 15:30 ET) and aggregate at end of month.


Add setScaleY(float) and setTranslateY(float) to IndeterminateHorizontalProgressDrawable

Fixes #79
Verified by changing the scaleY at runtime

Why do you need to change the drawable? You should be able to animate the view itself with the animation framework, even if it contains zero or multiple drawables.

Just checked, you are right. It does animate scaleY correctly, I had a bug in my code previously causing it to appear broken. Sorry for the hassle.


WIP prepare for password management service election strategy

At the moment, we need to be able to configure what password manager is used for a given website. In the current solution, we have no influence on it. There is always one to load. The current PR is preparing space for further work and the configuration of this in RegisteredService.

Can You open this PR for me ?


Add Spring Dependency injection to Data Prepper Core

Is your feature request related to a problem? Please describe.
Data Prepper (DP) does not utilize any Dependency Injection(DI) frameworks at this moment nor are we leveraging an existing framework which supports DI. Without a DI framework there are numerous code smells in DP. Currently, DP couples construction of dependent objects with implementation of other objects. DP also has cyclical dependencies and leverages static methods and instances to solve its own singleton management.
Describe the solution you'd like
Introduce dependency injection to the core of Data Prepper.
Tasks:

[ ] Add Spring DI framework as dependency and create DataPrepper class from the DI framework
[ ] DataPrepper should inject all dependencies and eliminate singleton implementation
[ ] DataPrepperServer should inject all dependencies
[ ] Plugin Package classes should be updated to use new DI framework
[ ] Pipeline package classes should be updated to use new DI framework
[ ] LogstashConfigConverter should be updated to use new DI Framework

Additional context
Implements: #519
Dependencies should be injected via a constructor and not via setter methods.
Unit tests should be updated to leverage dependency injection.

Thanks for putting this issue together and creating the GitHub tasks! This issue calls for using Spring Dependency Injection. I believe this is good, but I also recommend that Data Prepper use JSR-330 annotations wherever possible. This way, if Data Prepper ever changes DI frameworks, there are fewer places to update.


xineUI: 0.99.9 -> 0.99.10

Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:

built on NixOS
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check -h got 0 exit code
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check --help got 0 exit code
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check help got 0 exit code
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check -V and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check --version and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check version and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check -h and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check --help and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check help and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport -h got 0 exit code
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport --help got 0 exit code
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport help got 0 exit code
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport -V and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport --version and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport version and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport -h and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport --help and found version 0.99.10
ran /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport help and found version 0.99.10
found 0.99.10 with grep in /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10
directory tree listing: https://gist.github.com/38a0309d9443aca1e54f071937c1e1cc

No attempt on x86_64-darwin
The following builds were skipped because they don't evaluate on x86_64-darwin: xineUI
No partial log is available.

Success on x86_64-linux (full log)
Attempted: xineUI
Partial log (click to expand)
shrinking /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-remote
shrinking /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/fbxine
shrinking /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine
gzipping man pages under /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/share/man/
strip is /nix/store/fzcs0fn6bb04m82frhlb78nc03ny3w55-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin
patching script interpreter paths in /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10
/nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-bugreport: interpreter directive changed from " /bin/sh" to "/nix/store/q1g0rl8zfmz7r371fp5p42p4acmv297d-bash-4.4-p19/bin/sh"
/nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10/bin/xine-check: interpreter directive changed from " /bin/sh" to "/nix/store/q1g0rl8zfmz7r371fp5p42p4acmv297d-bash-4.4-p19/bin/sh"
checking for references to /build in /nix/store/zca8nmwqrr97lpvmprr5hqglxlqig2d4-xine-ui-0.99.10...


tokens {{ and }} in binders

From the Lean mailing list:
Dear Jeremy,
I will fix this issue. The problem is how the parser handles {{ and }} in binders.
It treats {{ as two tokens {  followed by {. This is the problem.
It should treat it as a single token {{.
When you define
              notation `{{`:max s:(foldr `,` (a t, insert a t) ∅) `}}`:0 := s

The tokens {{ and }} are added to Lean.
After that, the only one to enter the binder
                {{ X : Type }}

is to type
                { { X : Type } }

Of course, this is unacceptable. I will fix it.
BTW, for lists and vectors, we use the notation [1, 2, 3] for explicit collections.
Perhaps, we should use the same notation for sets.
What do you think?
Best,
Leo
From<EMAIL_ADDRESS><EMAIL_ADDRESS>On Behalf Of Jeremy Avigad
Sent: Tuesday, March 24, 2015 11:43 AM
To<EMAIL_ADDRESS>Subject: [lean-discuss] notation for sets
Dear all,
There is an MS student here who is formalizing properties of sets (i.e. subset of a type).
We introduced notation { x : A | P x } for forming a subset, and also notation
  {{1, 2, 3}} or ⦃1, 2, 3⦄

for writing explicitly enumerated sets.
The first of these, however, conflicts with the {{ x : X }} notation for binders. (The second one causes no problems, whether we write ⦃x : X⦄ or {{ x : X }} for the binder.)
Is there a workaround? One solution is to use only ⦃1, 2, 3⦄ for enumerated sets, or find some other ascii-equivalent.
An example of the problem is appended below.
Best wishes,
Jeremy
import data.set
open set

section
  variable {A : Type}

  definition set_of (P : A → Prop) : set A := P

  notation `{` binders `|` r:(scoped:1 P, set_of P) `}` := r

  definition insert (a : A) (s : set A) : set A := {x : A | x = a ∨ x ∈ s}

  notation `⦃` s:(foldr `,` (a t, insert a t) ∅) `⦄` := s
  notation `{{`:max s:(foldr `,` (a t, insert a t) ∅) `}}`:0 := s

  check ⦃1, 2, 3⦄
  check {{1, 2, 3}}

  definition foo  {X : Type} {{ x : X }} : X := x    -- error here
end

@avigad I recalled why the parser tries to parse {{ as { { and }} as } }.
The motivation is declarations such as {A : Type.{l}}. If }} is a single token, we would be forced to write {A : Type.{l} }. This is a pretty common case.
We can use the following workaround for this problem
notation `{` `{` s:(foldr `,` (a t, insert a t) ∅) `}` `}` := s

That's reasonable. Squiggly braces play a special role.
The problem with the workaround is that it breaks the notation {x : A | P}:
import data.set
open set

section
  variable {A : Type}

  definition set_of (P : A → Prop) : set A := P

  notation `{` binders `|` r:(scoped:1 P, set_of P) `}` := r

  definition insert (a : A) (s : set A) : set A := {x : A | x = a ∨ x ∈ s}

  check {x : A | x = x}  -- o.k.

  notation `⦃` s:(foldr `,` (a t, insert a t) ∅) `⦄` := s
  notation `{` `{` s:(foldr `,` (a t, insert a t) ∅) `}` `}` := s

  check ⦃1, 2, 3⦄
  check {{1, 2, 3}}

  check {x : A | x = x} -- broken
end

I think the best solution is to use the notation {[1, 2, 3]} for an enumerated set:
  notation `⦃` s:(foldr `,` (a t, insert a t) ∅) `⦄` := s
  notation `{[`:max s:(foldr `,` (a t, insert a t) ∅) `]}`:0 := s

  check ⦃1, 2, 3⦄
  check {[1, 2, 3]}

I kind of like it. What do you think?

The problem with the workaround is that it breaks the notation {x : A | P}

Yes, you are right. The workaround introduces an ambiguity. The beginning of a binders primitive is an identifier, or any binder annotation: (, {, {{, [, ...
I think it is silly to consider binder annotations for {x : A | P}.
We may create a simplebinder that expects something of the form x : A.
If we do that, we will be able to disambiguate this instance.

I think the best solution is to use the notation {[1, 2, 3]} for an enumerated set:
I kind of like it. What do you think?

It looks good.

The simplebinder idea sounds good. We'll have lots of uses for such binders, for sums, products, unions, intersections, etc.

I'm closing this issue. The simplebinder is a mess to implement. To be useful, we would have to implement a form of backtracking/lookahead in the parser.
Here is an alternative solution for this kind of problem. We can tell emacs to render some patterns in a slightly different way. For example, {[ would be rendered as {. Similarly, ∀₀ would be rendered as ∀. This is not different from the Isabelle approach where the user uses "tags" such as \<noteq> and \<lambda>, but they are rendered in a nice way by JEdit.

That's o.k. I don't mind a little ascii art.
The emacs trick is o.k., though it wouldn't extend e.g. to the github listings.
Other hacks are to use exotic unicode characters, like the full width braces here:
http://xahlee.info/comp/unicode_matching_brackets.html
Or even to use invisible unicode characters in tokens:
http://www.fileformat.info/info/unicode/char/2063/index.htm
http://www.fileformat.info/info/unicode/char/200B/index.htm
But I expect there will be all sorts of problems with that.

The emacs trick is o.k., though it wouldn't extend e.g. to the github listings.

Yes. At least, it would still be readable. On github, we would see {[ instead of { and ∀₀ instead of ∀.
I don't really want to go into the "backtracking" parser direction.
It would produce even more counter intuitive behavior.

But I expect there will be all sorts of problems with that.

Yes. I think this would produce a lot of confusion.

FYI, since emacs-24.4, we have a minor-mode, prettify-symbols-mode, which easily allows us to do what @leodemoura mentioned. For example, have the following elisp in your emacs:
(add-hook 'lean-mode-hook
          (lambda ()
            (push '("forall" . ?∀) prettify-symbols-alist)))

then, turn on prettify-symbol-mode in a lean file. You will see that forall is rendered as ∀.


Use the correct the application data directory for inso

This PR makes inso use the correct application directory path on Windows and Linux. As env-paths is an opinionated library with no relation to Electron, I've opted to make a small utility function for this instead.
It also starts looking for the Insomnia data directory instead of Insomnia Designer one by default, and adds a fallback to for the Insomnia Designer data directory if it does not exist.
This creates a potential breakage if a user have both Core and Designer installed, but have not yet migrated their Designer data to Core. Please let me know your thoughts on whether that should be addressed or not (cc @nijikokun).
I have tested this on macOS and Windows, but would be great to have some more people test on those platforms, and also Linux in particular.
Fixes INS-458
Fixes INS-421
Fixes #3058

Please let me know your thoughts on whether that should be addressed or not (cc @nijikokun).

Let's note it within the changelog as a breaking change, and to use the previous version.


It can't work with error '*** Error unlocking FLASH ***'

Hi, I trying flash stm32 device but no using Keil.
I Try it successfully on Ubuntu.

The version of firmeware of ST-LINK debuger is: V2.J28.S7

OK, if on Ubuntu is flashing successful, can you send me also log from Ubuntu and then again from Windows on same micro-controller with same flashing command for comparison? And be sure that you have same version of pystlink. (Please send logs as attachment if it is possible). Thanks.

I tested and I found that :

If I flash the chip on a SMT Test Socket(https://www.adafruit.com/product/1280), nothing go wrong.
If I flash the chip (that is mounted in a PCB) from the PCB's SWDIO port, And I get that errors.

Anyway, I can use Keil to flash the chip from the PCB's SWDIO port and get no warning.

I will update if i get more information.

For now, No more information.
I will update if I have useful info.
Close for now.

probably is necessary to FLASH under reset, because the SWDIO pins are used by application and this feature is not implemented in pystlink right now.


Fix jest related extension.

How did that dot got there? Must had a bad weekend...

I didn't see it myself during the review process so... we all must have had a bad weekend! 😉

I'll see to it to add another test case to catch those type of things.

Unfortunately it's not possible to add a test when the case is a filename.
What is possible is to check that the extension doesn't have a leading dot if it's a file extension.


Photos example

Comprehensive in-app drag&drop example: A simple photo organizer with folder support.


First step towards external metadata computation

Add blocked reflection node logic
Hook up to metadata policy in MetadataGeneration.cs (Note: existing metadata policy always returns false for isBlocked, so doesn't do much)
Factor MetadataGeneration.cs so that metadata policy is configurable by an outside class, and that metadata generation itself is moved out

Looks good!


Use investpy for rich source of data

https://investpy.readthedocs.io seems to provide a rich source of data: historical stocks, bonds, commodities, etfs, crypto and much more. Assess this data source and support its use.

Added preliminary implementation of views for bonds, cryptos and commodities. Easy to work with and impressive online performance.


Fix Clippy warnings

These changes are already in master/v0.8.

The Windows CI is failing due to https://github.com/MSxDOS/ntapi/issues/19, but I don't if the upgrade to ntapi v0.4 is a breaking change, in v0.8 we don't depend on ntapi.

Is any of its types in the public api of mio anywhere?

I don't think so, it's being pulled in via Miow, I don't think we use it directly anywhere.
But since v0.7 doesn't compile with rustc v1.67 (?) on Windows... I don't think a lot people are using v0.7 any more. I'm not sure if it's worth putting much more time into it.

It sounds like its probably not a breaking change.

It sounds like its probably not a breaking change.

I think we need to update to Miow v0.4/v0.5, both already use windows-sys. I personally don't have the time to do this, so I'm going to merge this as-is, since it doesn't further break the code, but now we at least have a working CI for v0.7 again.


Exchanging Gadget UI doesn't respect radius slider

Building Gadgets Version
1.3.7
Modpack/Version
FTB Evolution/1.4
Describe the bug
Initially, I found that using the UI (default g) to set the radius to 1 sets the radius 2 upon closing the menu. Using the radius keybind works as expected. Using the buttons works as expected. Grabbing and dragging the slider does not - this seemed like a rounding issue.
However, the temporary tooltip (radius set to x) is also wrong. And moving the slider faster exacerbates the problem. This seems more like a packet issue, with the slider not sending a final update to the server when it stops moving. If you move it fast enough, you can end up with a slider that says one on an effective range of 13. Leaving the GUI open for a few extra seconds has no effect.
To Reproduce
See description.
Expected behavior
Settings being correctly applied upon exiting the menu.
Screenshots
N/A
Log Files
N/A

Verified that the problem applies to the building gadget as well.


Compatibility between interop chain ID and batch inbox convention

Currently the interop spec allows 256 bit chain IDs. The current convention (not requirement) for the batch inbox address is 0xFF00...{chainId}. These are not compatible, as the batch inbox address only can fit chain IDs up to 19 bytes because addresses are 20 bytes.
This is currently not a big problem, and this issue is low priority, because:

The batch inbox address is only a convention, so chains with chain IDs larger than 19 bytes can choose an arbitrary batch inbox address. But we don't yet spec out what requirements (if any) that address should have.
From my research, no chain IDs are currently large enough for this to be a problem. However, some OP Stack chains do not follow the batch inbox convention anyway.

So one consideration here is: should we enforce a batch inbox convention? Doing so would be a nice property, and we may want to spec out the required work to make this convention into a requirement.
Regardless, possible solutions to the existing incompatbility are discussed below:
Shrink max allowable chain ID
EIP-2294 proposed a max chain ID of floor(MAX_UINT64 / 2) - 36. This value was chosen to prevent overflow of a uint64 when calculating the v-component of a signature as {0,1} + CHAIN_ID * 2 + 35 per EIP-155. Many popular tools, like MetaMask, only support chain IDs that are within the javascript Number.MAX_SAFE_INTEGER based on the same v-component calculation (resulting in ~4e15, below this proposed max).
This is my preferred solution because (1) it fixes the issue with minimal work, (2) mitigates the risk of OP Stack chains not supporting popular tools, and (3) can be expanded to a larger value in the future when needed.
A factor in this proposal becoming stagnant was because it prevents an easy way for chains to pick a unique chain ID through a process like keccak256("myUniqueChainName"). This is a good point, but we already do not do this, and we can expand allowable chain ID and change the convention in the future if this becomes necessary/desirable.
Change Batch Inbox Convention
Since we only have 20 bytes to work with, the new batch inbox address convention have to be something like keccak256(schemeVersion, chainId)[:20]. This would require changes to op-node so it can read from two batch inbox addresses: the legacy address, and a new address. It also makes it harder to look at a batch inbox address and back out the chain it's for, but this can is solved by the superchain-registry anyway
Do Nothing
Because this is just a convention, and not enforced, the status quo is ok—for chains that cannot meet the convention, they just choose a different, arbitrary batch inbox address. This should still be documented in the spec somewhere, e.g. in this case does the address still need to start with 0xFF?

Requirements

Chain IDs must be unique
Batch inbox address must be unique
Maybe: Forward compatibility with https://github.com/ethereum-optimism/specs/issues/221

Proposal

Initial scheme is version 0
Batch inbox address is versionByte || keccak256(bytes32(chainId))[:19], where || denotes concatenation and chainId is a uint256

This supports 256 iterations, and makes the version extractable from the address.
Example:
For Chain ID 123, we first compute the hash to be 0x5569044719a1ec3b04d0afa9e7a5310c7c0473331d13dc9fafe143b2c4e8148a

Solidity: keccak256(bytes.concat(bytes32(uint256(123))))
Cast: cast keccak 0x000000000000000000000000000000000000000000000000000000000000007b

Next we take the first 19 bytes of the hash: 0x5569044719a1ec3b04d0afa9e7a5310c7c0473
Then we perform the concatenation with version 0 to get a batch inbox address of 0x005569044719a1ec3b04d0afa9e7a5310c7c0473
Questions

If this convention is agreed on, do we want existing chains to migrate towards this, or do we only use this convention for new chains going forward, e.g. as part of the OP Stack Manager (https://github.com/ethereum-optimism/specs/pull/236)
This scheme can be made compatible with https://github.com/ethereum-optimism/specs/issues/221 by deploying to vanity addresses that have the expected versionByte prefix. However, requiring a vanity address as part of the spec feels leaky and suboptimal. Do we only use this new proposal until #221 is implemented?

I am on board with this as a default but ultimately if we support #221 we will need to have the ability to modify the batch inbox address on the SystemConfig and have the op-node listen to those modifications.  I am not opinionated on what the default standard is as long as its adopted when people do not explicitly say what their batch inbox is. We could always make the L2 chain id a getter on the system config and not need to worry about encoding it in the batch inbox
A side thought is the batch inbox in a way is a file path in a file system. Nothing super useful or actionable about that statement, just throwing it out there

We could always make the L2 chain id a getter on the system config and not need to worry about encoding it in the batch inbox

I do think we should keep the batch inbox address discoverable via SystemConfig, this way external tools like L2Beat can easily find it to e.g. verify data is actually being posted there.

It sounds like we agree with a simple, minimal solution for now at a stopgap for #221. The only place in the specs where the current convention is mentioned is in the standard config, so I'll open a PR to change that to the above proposal


Do the spatial analysis in squidpy have to be done on a sample by sample basis?

Hi there! I was wondering if the spatial analysis in squipy, e.g. sq.gr.co_occurence(...) have to be done on a sample by sample basis? I'm asking in the case where let's say I have an AnnData object with data from multiple different samples, then do I have to break up the AnnData by sample and then apply squipy's algorithms or is squidpy able to run it's algorithm on all the samples simultaneously? Thanks!

Hi @shanzaayub , sorry for late reply. Yeah as of now you'd have to perform it on a sample by sample basis. For graph-based metrics you could also use the trick explained in this comment https://github.com/theislab/squidpy/issues/318#issuecomment-886541340
we will eventually implement ways to compute scores considering batching but don't have an estimate of such feature

Ah okay, thank you!


JOSS review: Documentation

[x] I think the documentation should include instructions on how to reproduce the results. I've ran benchmarks.jl using PkgBenchmarks but it's not entirely clear to me how the results relate to what is reported in the documentation. The files perf.jl and perf.py probably should not be included in the package as they contain hard-coded file and path names that aren't part of the package.
[x] The paper comments on how good the interoperability is with other community packages. I'm curious why you have chosen to define your own physical constants, instead of using a community package, such as PhysicalConstants.jl
[x] The link to repo in https://github.com/henry2004y/Vlasiator.jl/blob/feda666f96ed87fb2928221680b2b5cd5473106b/docs/src/manual.md?plain=1#L233 is broken

https://github.com/openjournals/joss-reviews/issues/4906

Thanks for the review!

The link is fixed.
PhysicalConstants.jl is a nice collection of constants, but it come naturally with the dependencies on Unitful.jl which is something we haven't tested carefully. Having predefined units is good, but it unavoidably comes at a cost of performance. Also, in order to make computations convenient and consistent, we may have to define my own unit system for commonly used units in our community, which is also not fully tested. Thus we decided to define the constants inside the package (which is currently only ~ 10 lines). Currently based on this list, a few of the astrophysics packages depend on it.  In the future, we may make a switch if PhysicalConstants.jl proves to be a nice addition.
About the benchmarks between Julia and Python, the most tricky part, as the reviewers also pointed out in #122 and #115, is that VLSV format files generated from Vlasiator are either large or non-public. In order to show the comparisons at real work situations, our current solution is to run perf.jl and perf.py on private data on the server with different sizes. The test data for this package contains 3 VLSV files which are intently kept small. If we use those for the benchmarks, then only reading DCCRG grid variables at very small array sizes can be shown, which may not be ideal. Our current plan is to update perf.jl and perf.py and make better descriptions to the benchmark results.

Apologies, I had not looked under Log for instructions on how to run the benchmarks. I think renaming it to FAQ makes it a bit more obvious, but I would also put a link to it from the Benchmarks page. Probably that's part of your plans in making better descriptions of the benchmark results.
I understand that the size of the data files may prevent you from distributing them as part of the package. I don't really have an universal solution for that, I would suggest looking at services your institute or HPC center may offer for data storage and distribution. I'm perhaps a bit confused about the issue of data being non-public. If there is no public data, it's difficult to see the benefits of an open source processing tool. I understand you might want to keep unpublished data private, but you should have something published that can be used to run the benchmarks on.
I would suggest at least clearly documenting the benchmarks that only make sense to run on large datasets that may not be available as part of the package, and providing data for the benchmarks where you can get meaningful results within the limits of what you can store on GitHub.

Thanks for the suggestions! Upon inquiring our colleagues, we now find some open-access Vlasiator data. We will update the benchmarks and add the links to the data.

In Vlasiator.jl v0.9.34, we have updated perf.jl, perf.py as well as the benchmark results. perf.jl and perf.py can be run directly to produce a major portion of the benchmarks listed in the doc. One of the files (file index 5) is private, while others are all publicly accessible. We have also fixed some issues in comparing the performance between Python/Numpy and Julia, which should now give fairer results.

I would still like to ask for a bit clearer documentation on Benchmarks. With some guesswork I can link some of the numbers reported in https://henry2004y.github.io/Vlasiator.jl/dev/benchmark/ to the output of benchmarkpkg(Vlasiator), for example file index 2 of "loading meta data" is probably "meta" => Trial(310.480 μs). If you could describe on the Benchmarks page which numbers I can expect to extract from running benchmarkpkg on the data you provide, and how, that would make me happy.

I would also note that I ran into an error
ERROR: LoadError: Cannot locate '(Julia)Artifacts.toml' file when attempting to use artifact 'testdata' in 'Main'

that seems to be reported in https://github.com/JuliaLang/IJulia.jl/issues/1060. The solution in the first comment of the issue fixed it for me

I ran this issue as well and indeed the first comment fixed it. However, for some reason it didn't work for the pkgbenchmark that I added recently. In CI, my current workaround is to manually create a symbolic link under the benchmark folder:
https://github.com/henry2004y/Vlasiator.jl/blob/19b203b46d9d602c9463057652a8c21756082169/.github/workflows/benchmark.yml#L26
Then this works for both CI and local pkgbenchmark.

I would still like to ask for a bit clearer documentation on Benchmarks. With some guesswork I can link some of the numbers reported in https://henry2004y.github.io/Vlasiator.jl/dev/benchmark/ to the output of benchmarkpkg(Vlasiator), for example file index 2 of "loading meta data" is probably "meta" => Trial(310.480 μs). If you could describe on the Benchmarks page which numbers I can expect to extract from running benchmarkpkg on the data you provide, and how, that would make me happy.

Are you running perf.jl or benchmarks.jl @tkoskela ? In the benchmark page, the numbers are generated with perf.jl and perf.py, while benchmarks.jl is used for checking regressions within the pkg. I can cleanup the benchmarks further to get better links to each part.

I was running benchmarks.jl, thank you for pointing that out! I can verify the benchmark data, so I am happy to close the issue. Labeling the benchmark suites in perf.jl to match the documentation a bit better could be helpful.

Yeah this is indeed kind of confusing, because currently PkgBenchmarks requires the file benchmarks.jl so I cannot use it for comparing against Python with exactly the same tasks and larger datasets. But we will find a clearer (and automatic) way of doing this!


v4 - Scrollspy: Example in navbar broken

Fixed by #17156.

Hm. Thought the merge should have auto closed this

They are only auto-closed when the commit lands in the main branch - "master" in our case.

Ah ok. Sorry, I wasn't clear on that


Full MAUI support

Describe the solution you'd like
Since Microsoft expects all Xamarin Forms apps to be migrated to .NET MAUI by next May, the fact that App Center doesn't support .NET MAUI for build and distribution becomes a massive road block for us devs.
I personally believe that this should be one of your priorities right now but I respect the work you are all putting
Additional context
There is currently a work around which proves that it's definitely feasible.
If I can help in any way please let me know 🙂

I hope they at least merge this one! :")
https://github.com/microsoft/appcenter-sdk-dotnet/pull/1771