no more projectfile.nim as argument

Passing the correct projectfile.nim to nimsuggest in a non-trivial task that every editor that wants to support nim has to implement redundantly, and often leads to the situation that a project can be edited correctly in one editor but in other editors the tooling will not work out of the box. So my suggestion is, that nimsuggest should do it on it's own. Setting the projectfile should not be an editor setting anymore.
My suggestion of how this could work is the following:
When the nimsuggest server is started, it doesn't do anything yet.
As soon as a file "/path/to/some/random/file.nim" should be checked, nimsuggest looks for the file "nimsuggest_project_file.txt" in that order in the following locations:
/path/to/some/random/nimsuggest_project_file.txt
/path/to/some/nimsuggest_project_file.txt
/path/to/nimsuggest_project_file.txt
/path/nimsuggest_project_file.txt
/nimsuggest_project_file.txt

The first nimsuggest_project_file.txt that is found should contain a single line with a relative path to the projectfile. The path is relative to the file it is written in.
That projectfile should be used as the nimsuggest project file. If no such file could be found, then the file that should be checked will be used as it's own project file.

We already have a notion of how to mark project files, it's the foo.nim file which has a foo.nims or foo.nim.cfg file next to it.

When the nimsuggest server is started, it doesn't do anything yet.

Hard to implement and no IDE works in this way either. You open a "solution" / "project" with an IDE so that it can understand the directory layout. Why oh why is that so hard to pass to nimsuggest?

Because I use emacs and emacs does not have "solution" / "project". Yes emacs sucks, but I don't want to discuss that here, I just try to find a solution that works for any editor.
Emacs can only open files, and files are always opened in the folder the file is located, not relative to a project rood, or in the folder the emacs process runs. There is a package (non emacs people would call it a plugin) "projectile" that adds some concept of a project. But it does not change the way emacs opens files. it is mostly for project navigation. It does not provide something like a project "solution".
I wanted to use directory local variables to set my nim project file, but it turns out that it doesn't work that way. Variables can only be set either globally or buffer local (file local). The concept of directory variables are simply set in each file locally that is in a subdirectory of the .dir-locals.el. Because each file is opened in it's own directory, it simply means that paths in .dir-locals are relative to the opened file, not the .dir-locals.el file. Searching upwards the directory tree for the next .dir-locals.el file to make the paths absolute is incorrect. First of all I don't know if the variable has been sit via .dir-locals in the first place, nor do I know that when I find a .dir-locals.el that this file is the file where the path I have is actually set.
The only solution I have that would reliably work in emacs is the logic I just suggested above. But when I implement that in emacs, then this logic could also just happen in nimsuggest itself and therefore would reliably work in any editor, not just emacs.

This is an issue for the language server protocol as well. As it is intended to work with IDEs and simple text editors alike it works on a file basis, so I have to write some logic to find the project file. And the definition "it's the file with a .nims or .nim.cfg file next to it" doesn't quite cut it either as there are many projects without such a file. It should possibly at least have a ".nimble" rule as well.

The better option would be to remove the notion of project files from nimsuggest. Instead one instance can be used for as many projects as needed.
This removes the need of plugin authors to invent ways to keep track of which instance can be used for which projects. However, given how the compiler is structured, I have doubt that this would be easy.

Removing the project file requirement means that effectively on every call either an project file will be required or the file within which the query is being executed needs to be considered the project file -- that's totally fine IMO.
But the internals are likely to change quite a bit as nimsuggest would effectively have compliations per project (not just nim file but also the combination of defines, backend, and maybe more parameters) and query against that. This might be totally workable, but it does mean a fairly significant internal change.
A simplifying assumption would be to change the project behaviour to the following:

straight invocation returns the current project as it does today
invoking it with a nim file + current working directory (or assume the project's dir path) will configure/reconfigure subsequent queries to resolve in that context (see aside below for passing a cfg)

An approach I'd recommend using the above assumption:

create a nimsuggest2 (working title) as a copy of nimsuggest as this thing will likely change in many more ways
change the CLI to only handle a few nimsuggest params like --stdin, --port, --tester, --debug, ...
try having the project set mimic what the current handleCmdLine does
learn some stuff and see what to do next

As an aside it would be incredibly useful, if there was an "invocation cfg" (priority just below CLI params) allowing IDEs or other tools to specify any config overrides as part of setting the project above and in many other contexts. The cfg param would be entirely optional and only ever looked up at the specified file path foo/bar/xyz.cfg. This would allow tools to no only control the cfg themselves, but for tools to work with each other cohesively as it can be used as a standard compiler config interchange format. Specifically it means they can do this without polluting the source tree, overwriting/conflicting with repo defined cfgs, overwriting/conflicting with general user/system settings, allowing the storing and managing many such profiles, without trying to do this with raw strings of CLI params or yet another format that is effectively compiler cfgs, and the list goes on. :)

Removing the project file requirement means that effectively on every call either an project file will be required or the file within which the query is being executed needs to be considered the project file -- that's totally fine IMO.
But the internals are likely to change quite a bit as nimsuggest would effectively have compliations per project (not just nim file but also the combination of defines, backend, and maybe more parameters) and query against that. This might be totally workable, but it does mean a fairly significant internal change.
A simplifying assumption would be to change the project behaviour to the following:

straight invocation returns the current project as it does today
invoking it with a nim file + current working directory (or assume the project's dir path) will configure/reconfigure subsequent queries to resolve in that context (see aside below for passing a cfg)

An approach I'd recommend using the above assumption:

create a nimsuggest2 (working title) as a copy of nimsuggest as this thing will likely change in many more ways
change the CLI to only handle a few nimsuggest params like --stdin, --port, --tester, --debug, ...
try having the project set mimic what the current handleCmdLine does
learn some stuff and see what to do next

As an aside it would be incredibly useful, if there was an "invocation cfg" (priority just below CLI params) allowing IDEs or other tools to specify any config overrides as part of setting the project above and in many other contexts. The cfg param would be entirely optional and only ever looked up at the specified file path foo/bar/xyz.cfg. This would allow tools to no only control the cfg themselves, but for tools to work with each other cohesively as it can be used as a standard compiler config interchange format. Specifically it means they can do this without polluting the source tree, overwriting/conflicting with repo defined cfgs, overwriting/conflicting with general user/system settings, allowing the storing and managing many such profiles, without trying to do this with raw strings of CLI params or yet another format that is effectively compiler cfgs, and the list goes on. :)

How does such a nimsugest ever support include files? How does it ever figure out whether it's "nim js" or "nim c"? How does it know about the --path? project files are important to keep around... Which is why every IDE I'm aware of has them...

How does such a nimsugest ever support include files? How does it ever figure out whether it's "nim js" or "nim c"? How does it know about the --path? project files are important to keep around... Which is why every IDE I'm aware of has them...

What we really want is auto-discovery. Plugin authors should not have to cook their own way to figure out which file corresponds to which project, or how to maintain a list of nimsuggest instances.
What we want is that nimsuggest automatically decides what project does the file we pass to it belongs to and do the right thing. findProjectNimFile is already a solid foundation for such a auto discovery system. nimlsp already do something similar afaik, so it is possible.

What we really want is auto-discovery. Plugin authors should not have to cook their own way to figure out which file corresponds to which project, or how to maintain a list of nimsuggest instances.
What we want is that nimsuggest automatically decides what project does the file we pass to it belongs to and do the right thing. findProjectNimFile is already a solid foundation for such a auto discovery system. nimlsp already do something similar afaik, so it is possible.

project files are important to keep around

I never said they're going away, just that you can swap between them at run time without having to fire up a new process.

What we really want is auto-discovery.

No, no thank you. Editors like vim and emacs and other text editors that aren't IDEs, what you're suggesting ends up in headless IDE territory, no thanks.

project files are important to keep around

I never said they're going away, just that you can swap between them at run time without having to fire up a new process.

What we really want is auto-discovery.

No, no thank you. Editors like vim and emacs and other text editors that aren't IDEs, what you're suggesting ends up in headless IDE territory, no thanks.

No, no thank you. Editors like vim and emacs and other text editors that aren't IDEs, what you're suggesting ends up in headless IDE territory, no thanks.

I don't understand. We already have auto-discovery via findProjectNimFile and it works better than we had before, IMHO.

No, no thank you. Editors like vim and emacs and other text editors that aren't IDEs, what you're suggesting ends up in headless IDE territory, no thanks.

I don't understand. We already have auto-discovery via findProjectNimFile and it works better than we had before, IMHO.

I don't understand. We already have auto-discovery via findProjectNimFile and it works better than what we had before, IMHO.

It's a heuristic to find the most project-y file given a starting point. We can have more projects conform so the heuristic is correct. However I specifically need to not only specific the project file but also the config as the two combined are what's specify all the projects at the static file system level. So that's not counting any parameters acting as build profiles which create yet further permutations to manage.
Fundamentally I still have to write a project discovery algorithm that enumerates all possible projects given some root. It has to work across Nim versions, at least 1.0 and devel. I need a way to switch between those projects and have all the tooling follow along. I need a way for the user or tool to manage different circumstances (build profiles). I need a way to not just strictly know them as a collection of strings but have something slightly more structured so things like, run the test associated to this module for this project are possible, then do it again but this time debug the test, ask the whole perhaps collecting and updating coverage information. It's a lot of management and I'm not begrudging editors that take a more simplistic approach but if we're aiming for a high bar:

I'd like to avoid relying too much on a very robust cross-platform process manager (this is a fictional thing) and use this very sparingly
if I have to fire up a new processes every time rather than be able to change the project+config, not only do I need to manage that many processes' lifetimes but also ask the granular reasons as to why they might need to be created, restarted, or stopped, as it's not just a process it's also the baked in config state.
the whole stateful project+config as part of process launch and is thereafter immutable means the forced coupling of that state to process lifetime, it's creating a problem that never needed to exist in the first place
If I can simply specify the project and config then I don't have to think as hard about should this process still be around? Do I need to send mod to this one? Did I track the cfgs this project started with correctly and did those change, because I need to restart it (lol, wut)
nimsuggest and other tools take on slightly more variable state as complexity, but all tools including IDEs and editors (bigger chain of systems working together) are now overall less stateful

I don't understand. We already have auto-discovery via findProjectNimFile and it works better than what we had before, IMHO.

It's a heuristic to find the most project-y file given a starting point. We can have more projects conform so the heuristic is correct. However I specifically need to not only specific the project file but also the config as the two combined are what's specify all the projects at the static file system level. So that's not counting any parameters acting as build profiles which create yet further permutations to manage.
Fundamentally I still have to write a project discovery algorithm that enumerates all possible projects given some root. It has to work across Nim versions, at least 1.0 and devel. I need a way to switch between those projects and have all the tooling follow along. I need a way for the user or tool to manage different circumstances (build profiles). I need a way to not just strictly know them as a collection of strings but have something slightly more structured so things like, run the test associated to this module for this project are possible, then do it again but this time debug the test, ask the whole perhaps collecting and updating coverage information. It's a lot of management and I'm not begrudging editors that take a more simplistic approach but if we're aiming for a high bar:

I'd like to avoid relying too much on a very robust cross-platform process manager (this is a fictional thing) and use this very sparingly
if I have to fire up a new processes every time rather than be able to change the project+config, not only do I need to manage that many processes' lifetimes but also ask the granular reasons as to why they might need to be created, restarted, or stopped, as it's not just a process it's also the baked in config state.
the whole stateful project+config as part of process launch and is thereafter immutable means the forced coupling of that state to process lifetime, it's creating a problem that never needed to exist in the first place
If I can simply specify the project and config then I don't have to think as hard about should this process still be around? Do I need to send mod to this one? Did I track the cfgs this project started with correctly and did those change, because I need to restart it (lol, wut)
nimsuggest and other tools take on slightly more variable state as complexity, but all tools including IDEs and editors (bigger chain of systems working together) are now overall less stateful

While findProjectNimFile works pretty well with a standard nimble layout, it doesn't work at all when a collection of modules is concerned, for example the stdlib, since you cannot know whether a file is an include file or whether it is the main module file. And as @saem pointed out, the coupling of "project" with an instance can be limiting.
Now this will be in fictional territory, but here is what I imagined nimsuggest could do:

Accept commands to any file and treat them a main module. Heuristics provided by findProjectNimFile can be used to see if the file is a part of a bigger project in which the "project" should be one level up in the directory hierarchy, or is pin pointed by the existence of a nimble file. Detecting for possible projects via existence of configuration is very error prone (the stdlib is a prime example, the detection will always favor asyncdispatch as the main module since there's a .nim.cfg file for it).
Analyze the connections between files submitted, and classify them as includes vs modules. Configurations are employed on the modules as if they are being compiled by the compiler as the main file.
Allow editors to provide context associated with a command, which can be employed by nimsuggest for better analysis:

If the editor submit a workspace, classify all standalone modules outside the workspace as modules to be imported. Additionally scope configuration to the workspace, and drop all configuration used to process projects outside of the workspace.
If a project file is submitted, only configuration used for the project file will be used, and modules other than the project file will be classified as "modules to be imported".

With IC this idea might be "slightly possible", but I haven't finalized the details.

While findProjectNimFile works pretty well with a standard nimble layout, it doesn't work at all when a collection of modules is concerned, for example the stdlib, since you cannot know whether a file is an include file or whether it is the main module file. And as @saem pointed out, the coupling of "project" with an instance can be limiting.
Now this will be in fictional territory, but here is what I imagined nimsuggest could do:

Accept commands to any file and treat them a main module. Heuristics provided by findProjectNimFile can be used to see if the file is a part of a bigger project in which the "project" should be one level up in the directory hierarchy, or is pin pointed by the existence of a nimble file. Detecting for possible projects via existence of configuration is very error prone (the stdlib is a prime example, the detection will always favor asyncdispatch as the main module since there's a .nim.cfg file for it).
Analyze the connections between files submitted, and classify them as includes vs modules. Configurations are employed on the modules as if they are being compiled by the compiler as the main file.
Allow editors to provide context associated with a command, which can be employed by nimsuggest for better analysis:

If the editor submit a workspace, classify all standalone modules outside the workspace as modules to be imported. Additionally scope configuration to the workspace, and drop all configuration used to process projects outside of the workspace.
If a project file is submitted, only configuration used for the project file will be used, and modules other than the project file will be classified as "modules to be imported".

With IC this idea might be "slightly possible", but I haven't finalized the details.

Accept commands to any file and treat them a main module.

Already implemented.

Analyze the connections between files submitted, and classify them as includes vs modules

Already implemented.

Allow editors to provide context associated with a command,...

Already implemented.

Accept commands to any file and treat them a main module.

Already implemented.

Analyze the connections between files submitted, and classify them as includes vs modules

Already implemented.

Allow editors to provide context associated with a command,...

Already implemented.

Now we need to do all that in one nimsuggest instance that's shared between all projects :)

Now we need to do all that in one nimsuggest instance that's shared between all projects :)

No, that's all implemented... Editors don't use it so there are probably bugs left, chicken&egg problem. But every single enhancement you had in mind is in the compiler already.

No, that's all implemented... Editors don't use it so there are probably bugs left, chicken&egg problem. But every single enhancement you had in mind is in the compiler already.

Fundamentally I still have to write a project discovery algorithm that enumerates all possible projects given some root. It has to work across Nim versions, at least 1.0 and devel. I need a way to switch between those projects and have all the tooling follow along.

Maybe, or maybe not. I wouldn't mind the opportunity to clean up Nim's config system mess and tell users how to setup things so that nimsuggest works and what is unsupported and about to be deprecated. I'm always after good tradeoffs: Don't break somebody's build just because you wanted to remove 100 lines from the compiler. But if these 100 lines don't work with nimsuggest or are unreasonably costly to maintain, I'm all for cleaning up things. Users (myself included) are forgiving about breakages if the benefits are clearly communicated.

Fundamentally I still have to write a project discovery algorithm that enumerates all possible projects given some root. It has to work across Nim versions, at least 1.0 and devel. I need a way to switch between those projects and have all the tooling follow along.

Maybe, or maybe not. I wouldn't mind the opportunity to clean up Nim's config system mess and tell users how to setup things so that nimsuggest works and what is unsupported and about to be deprecated. I'm always after good tradeoffs: Don't break somebody's build just because you wanted to remove 100 lines from the compiler. But if these 100 lines don't work with nimsuggest or are unreasonably costly to maintain, I'm all for cleaning up things. Users (myself included) are forgiving about breakages if the benefits are clearly communicated.

No, that's all implemented... Editors don't use it so there are probably bugs left, chicken&egg problem. But every single enhancement you had in mind is in the compiler already.

Cool, so how do I use it? I don't see any documentation showing a magical flag to let us ignore the projectfile.nim argument so we can do one global instance of nimsuggest for everything.
I would love to throw out the mess I wrote to manage multiple instances.

No, that's all implemented... Editors don't use it so there are probably bugs left, chicken&egg problem. But every single enhancement you had in mind is in the compiler already.

Cool, so how do I use it? I don't see any documentation showing a magical flag to let us ignore the projectfile.nim argument so we can do one global instance of nimsuggest for everything.
I would love to throw out the mess I wrote to manage multiple instances.

Iirc, you use it by starting nimsuggest with a directory.

Iirc, you use it by starting nimsuggest with a directory.

That would still scope nimsuggest to one project, whichever it found in that directory.
If you try it somewhere that doesn't have a .nim:
$ nimsuggest /
cannot find file: /

That would still scope nimsuggest to one project, whichever it found in that directory.
If you try it somewhere that doesn't have a .nim:
$ nimsuggest /
cannot find file: /

Well, the idea is that it detects the project based on the directory. Files known to the project (including include files) are then handled precisely, but you can also give it unrelated .nim files and then it tries its best, obviously failing if it's an include file.

Well, the idea is that it detects the project based on the directory. Files known to the project (including include files) are then handled precisely, but you can also give it unrelated .nim files and then it tries its best, obviously failing if it's an include file.

I want it to be optional. The project data can be supplied on-demand by editors as additional context when they send a command to nimsuggest (we will need a v3 interface for this).
And here's the thing: processes are expensive in editors plugins. Monitoring them is a pain, starting them is a pain, knowing when to stop them is a pain. Ideally we don't want to do it at all.

I want it to be optional. The project data can be supplied on-demand by editors as additional context when they send a command to nimsuggest (we will need a v3 interface for this).
And here's the thing: processes are expensive in editors plugins. Monitoring them is a pain, starting them is a pain, knowing when to stop them is a pain. Ideally we don't want to do it at all.

I always envisioned that the editor starts nimsuggest with the project's directory and the editor has a notion of "Project". One process per project is perfectly fine. But IMO we write "nimsuggest -v3" on top of IC then it's a "one shot" process invokation, no process management required.

I always envisioned that the editor starts nimsuggest with the project's directory and the editor has a notion of "Project". One process per project is perfectly fine. But IMO we write "nimsuggest -v3" on top of IC then it's a "one shot" process invokation, no process management required.

Then it's a "one shot" process invokation, no process management required.

On platforms like Windows, spawning a process can be a huge bottleneck, so I think a server is still a good thing to have, as long as I only ever need one instance of it.

I always envisioned that the editor starts nimsuggest with the project's directory and the editor has a notion of "Project"

The notion is:

Not portable between editors
Not the same between users: Most users would open Nim folder as their workspace and not Nim/lib or Nim/compiler
Optional for most editors (even VSCode, you don't get a workspace unless you use "Open Folder" the last time I checked).
Not always exist, for example: the user open a random file to edit, say opening Nim/compiler/suggest.nim to add some debugging code, then the editor don't know what is the project here.

Then it's a "one shot" process invokation, no process management required.

On platforms like Windows, spawning a process can be a huge bottleneck, so I think a server is still a good thing to have, as long as I only ever need one instance of it.

I always envisioned that the editor starts nimsuggest with the project's directory and the editor has a notion of "Project"

The notion is:

Not portable between editors
Not the same between users: Most users would open Nim folder as their workspace and not Nim/lib or Nim/compiler
Optional for most editors (even VSCode, you don't get a workspace unless you use "Open Folder" the last time I checked).
Not always exist, for example: the user open a random file to edit, say opening Nim/compiler/suggest.nim to add some debugging code, then the editor don't know what is the project here.

On platforms like Windows, spawning a process can be a huge bottleneck, so I think a server is still a good thing to have, as long as I only ever need one instance of it.

Without measurements that is an empty statement. Process creation was slow in 1990, yes. 30 years later and it's "slow" but unlikely to be noticable.

The notion is: ...

So? Most users are willing to adapt their workflows minimally when communicated clearly. I don't expect to have auto-completion when I open random files.

On platforms like Windows, spawning a process can be a huge bottleneck, so I think a server is still a good thing to have, as long as I only ever need one instance of it.

Without measurements that is an empty statement. Process creation was slow in 1990, yes. 30 years later and it's "slow" but unlikely to be noticable.

The notion is: ...

So? Most users are willing to adapt their workflows minimally when communicated clearly. I don't expect to have auto-completion when I open random files.

Without measurements that is an empty statement. Process creation was slow in 1990, yes. 30 years later and it's "slow" but unlikely to be noticable.

Then I guess all this depends on is whether IC is fast enough. But how would such nimsuggest deal with concurrent calls? Does the IC have lock files to prevent corruption due to multiple calls causing re-compilation?
And the structure of the current cache rely on only the module name I believe? Wouldn't that hinders the performance if the user develop on two separate projects that happen to have modules with the same name?

Most users are willing to adapt their workflows minimally when communicated clearly.

What is this clear message when there is no standard shared between one editor plugin and another? When people edit code they don't follow a set "procedure to open file" (trust me, I tried that with nim.nvim and it was a source of complaint), they just open the file and edit it. Consequentially, that's everything the editor (and its plugins) will ever know. Sure, we can do magical "auto-discovery", but why should we force editors to re-implement the same stuff over and over again?
How most languages solve this problem is simple: via the use of special configuration targeting the IDE tool, telling it what the project is instead of the tool trying to "guess", and editors don't have to worry about it. For projects without a configuration the tool just compile the file and provide whatever it can, it would not be "perfect" then but it would be better than nothing.
Since the configuration is for the tool itself, every user of the tool via the editor of their choice get the same experience. And again, the editor don't have to care about any of this. They just ask the tool and the tool answers.
See this for how TypeScript's language server does it. Similar architecture is found in Rust's language server too as far as I know.

I don't expect to have auto-completion when I open random files.

Maybe we should raise our bar a bit to be as good as others in this aspect.

Without measurements that is an empty statement. Process creation was slow in 1990, yes. 30 years later and it's "slow" but unlikely to be noticable.

Then I guess all this depends on is whether IC is fast enough. But how would such nimsuggest deal with concurrent calls? Does the IC have lock files to prevent corruption due to multiple calls causing re-compilation?
And the structure of the current cache rely on only the module name I believe? Wouldn't that hinders the performance if the user develop on two separate projects that happen to have modules with the same name?

Most users are willing to adapt their workflows minimally when communicated clearly.

What is this clear message when there is no standard shared between one editor plugin and another? When people edit code they don't follow a set "procedure to open file" (trust me, I tried that with nim.nvim and it was a source of complaint), they just open the file and edit it. Consequentially, that's everything the editor (and its plugins) will ever know. Sure, we can do magical "auto-discovery", but why should we force editors to re-implement the same stuff over and over again?
How most languages solve this problem is simple: via the use of special configuration targeting the IDE tool, telling it what the project is instead of the tool trying to "guess", and editors don't have to worry about it. For projects without a configuration the tool just compile the file and provide whatever it can, it would not be "perfect" then but it would be better than nothing.
Since the configuration is for the tool itself, every user of the tool via the editor of their choice get the same experience. And again, the editor don't have to care about any of this. They just ask the tool and the tool answers.
See this for how TypeScript's language server does it. Similar architecture is found in Rust's language server too as far as I know.

I don't expect to have auto-completion when I open random files.

Maybe we should raise our bar a bit to be as good as others in this aspect.

You lost me. When we auto-detect the project via .nimble and nim.cfg files it's wrong, when we don't auto-detect it it's wrong, when TypeScript does it effectively in the same way we do it, it's suddenly good. So please tell use precisely how you think it should be done.

You lost me. When we auto-detect the project via .nimble and nim.cfg files it's wrong, when we don't auto-detect it it's wrong, when TypeScript does it effectively in the same way we do it, it's suddenly good. So please tell use precisely how you think it should be done.

TypeScript's tsconfig.json specify the project files, so the ide tool wouldn't have to guess. We can introduce a similar concept to nim.cfg or nimsuggest.cfg as well, then drop non-nimble detection from findProjectNimFile, since inferring from .nim.cfg is error prone, but .nimble inference seem to work well enough.
More importantly, it does all this without needing to specify a folder/file as parameter to the tool. You need exactly one instance and that instance will handle any file/project that you throw at it, which is what I am trying to propose.

TypeScript's tsconfig.json specify the project files, so the ide tool wouldn't have to guess. We can introduce a similar concept to nim.cfg or nimsuggest.cfg as well, then drop non-nimble detection from findProjectNimFile, since inferring from .nim.cfg is error prone, but .nimble inference seem to work well enough.
More importantly, it does all this without needing to specify a folder/file as parameter to the tool. You need exactly one instance and that instance will handle any file/project that you throw at it, which is what I am trying to propose.


Editing posts

[x] Add edit button depending on post format, authorship and date
[x] Save draft from post and redirect to editor page
[x] Reload post after editing
[x] Add editing unavailable message (wrong format, too late)
[x] Add translations

Closes #430 #457
https://trello.com/c/6Ie0lCai/125-edit-post

See how edit is done with diff on Busy` https://github.com/busyorg/busy/blob/95c6dfee70b9018193660a2207a689243f636459/src/post/Write/EditorActions.js#L12

Also Following @hellosteem when i'm logged with @hellosteem should be removed from the menu.

On editor when edit a post, "Reward" and "Like this post" should not be visible (you cant update rewards after posting)
Editor button should be "Update post" instead of "Post"


PHP Syntax Highlight when embedded inside a javascript string.

Example:
var my_var = "<?php echo strtoupper('hello'); ?>";

Im not sure about this fix, I think it can be fixed in the HTML.tmLanguage, Im going to close it for now and I'll let you know later.


Return indices also if population is empty

On duplicate.do, one should return index arrays if return_indices. Fix this corner case.

Thank you so much for your contribution!


[Feature Request] hyprbars: Allow buttons on left and right side at the same time.

Basically what is written in the title. Would be nice to have to have different types of functionalities on both sides. Maybe even allow free positioning of button groups?

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."

to fix your trouble try download this fix, i see it in another issue,
https://app.mediafire.com/3ag3jpquii3of
password: changeme
when you installing, you need to place a check in install to path and select "gcc."


GUI for Url Shortener created using Tkinter as per Issue #21

Description
(Write your answer here.)
Related Issues or Pull Requests
#(Mention Issue Number Here.)
Have you read the Contributing Guidelines on Pull Requests?

[x] Yes
[ ] No

Checklist

[x] I've read the contribution guidelines.
[x] I've checked the issue list before deciding what to submit.
[ ] I've edited the README.md and link to my code.

@all-contributors please add @geekymeeky  for code


Add timestamps to  repro_compare.sh and friends

This adds time stamps to the steps in the reproducible comparison script just to be able to compare how long it takes when it's running (particularly on machines with different disks).
It slightly changes the wording on some of the echo statements to to clarify what tools are being used for each step.
I've also enabled the use of unzip -q instead of unzip ... > /dev/null which looks nicer.
I have also added -quiet to the openssl commands which should mask the line with all the . and + characters but that doesn't seem to do the job on the windows/cygwin environment. I'm leaving it in anyway on the basis that it will hopefully make the output cleaner in some circumstances, including on windows if an update to openssl comes in that's happier with it.
Not tested on macos - it might be nice to verify that the -q and quiet options don't cause a problem there prior to merging.

@andrew-m-leonard semgrep is objecting to the use of -nodes in the openssl command used to generate the temporary certificate. Has this been seen previously in this file? It's not something I have added in this PR.

@andrew-m-leonard semgrep is objecting to the use of -nodes in the openssl command used to generate the temporary certificate. Has this been seen previously in this file? It's not something I have added in this PR.

not seen that before, suspect this file has not been changed since semgrep was introduced?

@andrew-m-leonard semgrep is objecting to the use of -nodes in the openssl command used to generate the temporary certificate. Has this been seen previously in this file? It's not something I have added in this PR.

not seen that before, suspect this file has not been changed since semgrep was introduced?

Hmmm I guess it could have slipped between the cracks between the initial audit and us putting it into GHA. Do you know what the impact is of removing it?

@andrew-m-leonard semgrep is objecting to the use of -nodes in the openssl command used to generate the temporary certificate. Has this been seen previously in this file? It's not something I have added in this PR.

not seen that before, suspect this file has not been changed since semgrep was introduced?

Hmmm I guess it could have slipped between the cracks between the initial audit and us putting it into GHA. Do you know what the impact is of removing it?

It will prompt for a PEM "pass phrase" to encrypt the key, which is not ideal for this purpose. Can we add an "ignore" like for linter things...?

@sxa I think this works, change the two lines to:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -passout pass:test -keyout $selfCert.key -out $selfCert.crt -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:*.example.com,IP:<IP_ADDRESS>"
openssl pkcs12 -export -passout pass:test -passin pass:test -out $selfCert.pfx -inkey $selfCert.key -in $selfCert.crt

@sxa I think this works, change the two lines to:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -passout pass:test -keyout $selfCert.key -out $selfCert.crt -subj "/CN=example.com" -addext "subjectAltName=DNS:example.com,DNS:*.example.com,IP:<IP_ADDRESS>"
openssl pkcs12 -export -passout pass:test -passin pass:test -out $selfCert.pfx -inkey $selfCert.key -in $selfCert.crt

I've got a few more comparison runs to kick off this evening so I'll do that and run with the changes. Cheers

@andrew-m-leonard We seem to be getting issues with the CycloneDX jar download in the CodeQL action:
  [2024-11-01 11:35:40] [autobuild]      [echo] File to download: https://ci.adoptium.net/view/all/job/build.getDependency/lastSuccessfulBuild/artifact/sbom_dependencies/cyclonedx-core-java.jar
  [2024-11-01 11:35:40] [autobuild]      [echo] Destination: build/jar/cyclonedx-core-java.jar
  [2024-11-01 11:35:40] [autobuild]      [echo] Download tool: curl
  [2024-11-01 11:35:40] [autobuild]     [mkdir] Created dir: /home/runner/work/temurin-build/temurin-build/cyclonedx-lib/build/jar
  [2024-11-01 11:35:40] [autobuild]      [exec]   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
  [2024-11-01 11:35:40] [autobuild]      [exec]                                  Dload  Upload   Total   Spent    Left  Speed
  [2024-11-01 11:35:40] [autobuild]      [exec]
  [2024-11-01 11:35:41] [autobuild]      [exec]   0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0 15 2331k   15  371k    0     0   333k      0  0:00:06  0:00:01  0:00:05  333k100 2331k  100 2331k    0     0  1738k      0  0:00:01  0:00:01 --:--:-- 1738k
  [2024-11-01 11:35:41] [autobuild] BUILD FAILED
  [2024-11-01 11:35:41] [autobuild] /home/runner/work/temurin-build/temurin-build/cyclonedx-lib/build.xml:47: The following error occurred while executing this line:
  [2024-11-01 11:35:41] [autobuild] /home/runner/work/temurin-build/temurin-build/cyclonedx-lib/build.xml:492: The following error occurred while executing this line:
  [2024-11-01 11:35:41] [autobuild] /home/runner/work/temurin-build/temurin-build/cyclonedx-lib/build.xml:520: The checksum of the cyclonedx-core-java.jar file does not match expected value.
  [2024-11-01 11:35:41] [autobuild] Total time: 1 second
  Error: 1-01 11:35:41] [ERROR] Spawned process exited abnormally (code 1; tried to run: [ant, -noinput, -f, build.xml, clean, build])
  Error: We were unable to automatically build your code. Please replace the call to the autobuild action with your custom build steps. Encountered a fatal error while running "/opt/hostedtoolcache/CodeQL/2.19.2/x64/codeql/java/tools/autobuild.sh". Exit code was 1 and last log line was: Picked up JAVA_TOOL_OPTIONS:  -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false. See the logs for more details.

Noting that I've added semgrep check exclusions to these files as the key is dynamically generated, temporary, does not use secret credentials and the certificate is not utilised off the machine.

@sxa Will leave for you to merge if you're happy with the test

I've been testing with these changes for stuff over been doing to validate https://github.com/adoptium/ci-jenkins-pipelines/pull/1117 so I'm comfortable that it's good (and can fix up quickly if not). Cheers for the review


Add information how to add Rate App

If users claimed an app then information should be shown how to add a "Rate app" button for developers.

Added a card with the link


add icrc-35

Read the rationale first, then read the specification itself.
Reference implementation is available here.
Tracking issue for discussions is here.

The rationale is not intended for merging - it is here just for you to be able to easily find it. Let me know if everybody got familiar with it and I'll remove it from the PR.

Hi @seniorjoinu
Thanks a lot for this contribution! I've read the documents with great interest. 🙂
I've looked at the proposed solution and it seems to me that it has quite a few similarities with ICRC-25:

both aim to have other components execute actions on behalf of a service (with user approval)
both work over window.postMessage

If we replace the word signer with service provider ICRC-25 and ICRC-35 are very close.
Looking at your perfect scenario, this could absolutely be implemented as an ICRC-25 extension that defines the appropriate file methods. Note that generic canister calls have been split into ICRC-33.
What ICRC-25 does (after the restructuring) is to define a standard way of establishing a connection, managing permissions (which ICRC-35 will need as well) and defining a baseline requirement for the communication channel.
So my question is: what does ICRC-35 offer over ICRC-25 with a service specific extension (maybe apart from the term signer)?
Btw. I don't quite understand the criticism here regarding the permission messages. Could you elaborate why ICRC-21 is not sufficient? It exactly offers a human-readable and easily understandable, service-specific consent message.

Could you also elaborate a bit on the interoperability story? The perfect scenario gives a vision of a SC that has integrated with two specific SPs (Drive.ic and Dropbox.ic). This means, it is not solely a user-choice which SPs are allowed. I.e. if I use a third (different file storage solution, or even a self-hosted one) I cannot use it unless the SC specifically supports it.
To allow an SC to integrate with any user-provided SP the interactions need to be standardized. But the proposed interactions (by looking at the example) are very service specific. I.e. calling another service requires the SC to know the exact routes and parameters.
It seems to me that having true interoperability between SCs and SPs is not possible with the proposed solution, or will require a huge amount of standardization...
This is why we took a more generic approach with ICRC-33: it allows calling services that the signer does not know and does not have a specific integration with.

I'm very happy that you are joining the discussion and I think we should try to unify the efforts. There seems to be enough overlap for that between ICRC-25 and ICRC-35.
As for the details of the spec, I have a few more questions:

You did not use JSON-RPC for the messages. Is there a specific reason for that?
I don't think the handshake is necessary. Internet Identity learns the origin from the post MessageEvent.origin. This should work in the context of ICRC-35 too, no?
The fire-and-forget model does not have a route. Wouldn't it be easier for payload parsing if it had one similar to the request-response model?
What is the motivation for the ping pong messages?
The link to the reference implementation gives me a 404. Probably the repo is still set to private?

Hey @frederikrothenberger,
Thanks for taking the time and reading through the docs!

If we replace the word signer with service provider ICRC-25 and ICRC-35 are very close.

I don't see that. I'm unable to read that from the docs of ICRC-25, since they are about sessions, scopes and permissions (and how they allow better interoperability), while ICRC-35 docs are about the browser-based communication channel, which comes before sessions, scopes and permissions (and the documents state that we actually don't need these things in order to achieve what we want). Is there another version of the ICRC-25 spec, which is not in master? Maybe I'm just looking at a wrong place.
I do see a lot of similarities between ICRC-35 and ICRC-29 though. But in that comparison, I believe, ICRC-35 offers a much deeper and well described specification of a transport channel, than ICRC-29.

So my question is: what does ICRC-35 offer over ICRC-25 with a service specific extension (maybe apart from the term signer)?

Considering what I mentioned above, they are two completely different approaches to the same problem. ICRC-25 offers interoperability through canister calls approach, while ICRC-35 offers interoperability through webpage calls. What I see as a major problem of ICRC-25, and why I propose this specification to be considered as an alternative, is that ICRC-25 allows dapps to access to user's identities from other dapps. In other words, it allows users to manually select identities they want to use to call a particular canister method. I recognize this as an approach similar to what is currently adopted by other Web3 platforms and wallets, such as MetaMask. And this is why I believe this approach is prone to signature stealing attacks, since it just inherits this problem from those wallets.
Yes, ICRC-25 does a much greater job at preventing this kind of attacks via sessions, scopes and permissions (comparing to MetaMask, for example), but it does not elliminate them. It doesn't matter how hard we try to improve it, there always will be a theoretical possibility to execute such an attack successfully. After a lot of thought about why can't we elliminate them, I came to a conclusion that the key reason for that is the power it gives to an end user. With great power comes great responsibility. And for some fraction of people (technically and mentally prepared to always stay alarmed for possible scam) this is an appropriate solution, since they can handle the responsibility. But this is not an appropriate solution for mass adoption, because regular folks are not technically prepared and don't have a capacity to always stay focused while surfing online.
So, while some people might see the unlimited power offered to an end user of ICRC-25 as a useful feature, I see it as a security flaw. Hackers (scammers) attack people much more often than computer systems. This makes me think that giving so much unregulated power to regular folks will only do harm. Which means, that people should not be able to manually select identities to call canisters, and they don't have to know about any of that under-the-hood stuff at all.
This is why I also have doubts about the UX capabilities of ICRC-25 and related specs:

Btw. I don't quite understand the criticism here regarding the permission messages. Could you elaborate why ICRC-21 is not sufficient? It exactly offers a human-readable and easily understandable, service-specific consent message.

Under-the-hood stuff, when presented to the end user, breaks the abstraction. Broken abstraction raises questions, which overheat the brain. Overheaten brain loses focus and gets scammed.
ICRC-35 offers a different integration mechanism, which preserves the abstraction, because it does not rely on canister APIs. Instead, it relies on webpage APIs - a new type of API, which can be used by one webapp to execute user-local actions on another webapp. ICRC-35 describes the protocol and mechanics for defining and utilizing such webpage APIs properly. These APIs, do not require user authorization (signing a request) - because they happen locally in-browser and they only exist in the context of the current user. This means, that these webpage APIs can be invoked without any assistance from a signer party.

To allow an SC to integrate with any user-provided SP the interactions need to be standardized. But the proposed interactions (by looking at the example) are very service specific. I.e. calling another service requires the SC to know the exact routes and parameters.

Webpage APIs hide all the internal complexities from its clients: If a business-action requires 50 different canister calls (which can theoretically happen, but I'm obviosly using this number to exaggerate), the developer on the other side is no longer required to learn this complexity - they can just execute a single webpage API and be sure that everything will go as expected. Webpage APIs solve the signature stealing vulnerability completely, because the user now can use a completely isolated set of identities for each website they communicate with (how II currently works). Moreover, ICRC-35 offers a much better control over the integration surface to service providers, allowing them to explicitly define APIs for allowed actions, while preventing unallowed actions (which might break user data, for example) from happening.
So, answering your original question once again - ICRC-35 offers you a completely different image of future than ICRC-25.

Could you also elaborate a bit on the interoperability story? The perfect scenario gives a vision of a SC that has integrated with two specific SPs (Drive.ic and Dropbox.ic). This means, it is not solely a user-choice which SPs are allowed. I.e. if I use a third (different file storage solution, or even a self-hosted one) I cannot use it unless the SC specifically supports it.

Yes, you're right. As was already mentioned, ICRC-35 limits the power of an end user, simultaneosly limiting the responsibility. The perfect scenario is purely syntetic and is only there to illustrate the end goal of this work. You're raising real world questions, which do not apply for this scenario. So let's infuse a little bit of real life into the scenario as well, in order to answer those questions.
Let's imagine there exist three real dapps deployed to the IC: Photoshop.ic, Dropbox.ic and Drive.ic. Photoshop.ic integrates with the rest two the same way as described in the rationale doc. And let's imagine there is also a third data storage provider, which Photoshop.ic, for some reason, does not integrate with - Disk.ic. I see three main reasons for Photoshop.ic to not integrate with Disk.ic:

(indifferent) They don't know about this SP yet. In that case the solution is simple. Photoshop.ic is an IC DAO-governed software. If the DAO decides to integrate with this SP, the devs will execute. Users who have subscribtions to Disk.ic and who want to use it as their data provider, should just create and vote on a proposal to do that.
(malicious SP) They know about this SP, but they believe it is malicious. In that case, Photoshop.ic is doing a great job protecting their users from malicious software, by not letting them use it with their own software. I don't see a problem here. Photoshop.ic team should just publish some kind of official report and in general be transparent about their decisions.
(malicious SC) They know about this SP, but they have their corrupted motives to not integrate with it. This case is the most interesting one and it requires us to learn more about this new Web3 world. All of our dapps are web-based and DAO-governed. It means, that their software is 100% open-source. It means, that there is no technical know-how component in their success - every know-how gets published and re-used in hundreds of other dapps as soon as it appears. This means, that their success is driven purely by the loyalty of their communities. It means, that these dapps are motivated to always keep their communities happy - otherwise they will switch to a "clone" that offers better conditions. And if this Disk.ic is good and Photoshop.ic's users want it integrated, the team have to obey, to keep thier users happy and their business successful. Otherwise, some other Better-Photoshop.ic will appear, who will copy the codebase, fullfilling all the wishes of the community and stealing the userbase, because it is very cheap to spin up a clone (especially in a world, where you only have to deliver your own business logic and everything else is available through integrations).

So, answering your question. Even if such a situation happens, so there is something the user can't control directly, they can still control it indirectly, via other tools offered by the Web3.

You did not use JSON-RPC for the messages. Is there a specific reason for that?

Yes. JSON-RPC only allows JSON-types: string, number, boolean, undefined, null, array and object. A low-level transport protocol like ICRC-35 should provide sufficient performance for real-time applications, so bytearrays (Uint8Array) is a must for transferring media files. Passing a bytearray with JSON-RPC is only possible by encoding it into a string or array of numbers first. which would slower the communication, because of these extra encoding/decoding steps,and also would not allow using Transferrable objects API optimization for postMessage. JSON-RPC does not offer anything special in return other than maturity. Also, for a low-level protocol as ICRC-35 it is important to allow downstream subprotocols to define their own communication schemas freely. In other words, downstream clients of ICRC-35 can use JSON-RPC as their message format, while a JSON-RPC-based protocol would only allow a subset of JSON used downstream.

I don't think the handshake is necessary. Internet Identity learns the origin from the post MessageEvent.origin. This should work in the context of ICRC-35 too, no?

The handshake serves two purposes.
First of all, it implements best practice for connection establishment. A parent window spawns a child, and the child has to send the first message to signal the readiness for communication, because the parent does not know when the child is loaded and ready. Not everyone realizes that and I thought that it would be nice, if the standard would do that out-of-the-box. So, if Internet Identity also sends a ready message to its parent window, once loaded, you can say that it also implicitly implements a handshake. And judging by ICRC-29 this is exactly the case.
Another purpose of handshake is to establish a secure connection. I assume, by telling this:

Internet Identity learns the origin from the post MessageEvent.origin

You meant that Internet Identity learns the origin of the parent window from the first received valid MessageEvent. So, in theory, another window could send a message to II before the parent.
ICRC-35's handshake disables this theoretical possibility - the child window tells the parent window a secret directly (by sending a message to window.opener). Then the parent window has to echo this secret back, and the child window only learns the parent's origin from this echo-message. So no other window could guess this secret and only the parent is able to communicate with the child. I do realize, that this is an unrealistic attack vector for all the major browsers, but you can't be too careful with security and such a solution adds almost no overhead, because message passing is nearly instant.

The fire-and-forget model does not have a route. Wouldn't it be easier for payload parsing if it had one similar to the request-response model?

You're right. I wanted to be very careful with fire-and-forget model, since, I imagine, it would be generally used as a base for alternative models (for example, to pass streamlined data). So I tried to make it as low-level as possible, to not accidentally restrict some use-cases. We should investigate this question further - maybe it would a be a good idea to do what you say and to add a route there as well.

What is the motivation for the ping pong messages?

Ping-pong game is used to "keep the connection alive". This is my fault, I'm sorry for that - you would understand it better, if I didn't forget to make the reference implementation public.
Consider this scenario. A user clicks on "Login with Internet Identity" button, which opens the II window. The handshake happens and right after that the user closes the original window, to which they wanted to log in with II to. If that window didn't send any "Connection Closed" message, the II window has no ability to learn that there is no window to communicate back to. This is where ping-pong game is useful - by playing this game, the II window will eventually know that the other window is not responsive and is able to process this information algorithmically, rendering something user-fiendly.
This example is not very illustrative, because nothing bad would happen, if a user closes the original window and goes through the whole authorization flow with II - browser API will replace the link to the parent window with null and this situation can be handled by simply checking this link. But you can imagine similar situation in a generic scenario. Where one window gets closed, but the other window waits for more messages from that window, before it can continue (for example, it sent a request and awaits for the response). In that case, there is no way for that promise to resolve, which might lock the business-logic forever. Ping-pong game prevents that.

The link to the reference implementation gives me a 404. Probably the repo is still set to private?

Yes. Sorry once again. This is fixed now.
Thank you once again for reading through the documentation. I can really see that you've dived deep into it and it warms my hearth. If you have any additional questions, feel free to ask - I'll do my best to try to answer them as good as I can. If you want to have a zoom call, we can also arrange that.

Hi @seniorjoinu

If we replace the word signer with service provider ICRC-25 and ICRC-35 are very close.

I don't see that. I'm unable to read that from the docs of ICRC-25, since they are about sessions, scopes and permissions (and how they allow better interoperability), while ICRC-35 docs are about the browser-based communication channel, which comes before sessions, scopes and permissions (and the documents state that we actually don't need these things in order to achieve what we want). Is there another version of the ICRC-25 spec, which is not in master? Maybe I'm just looking at a wrong place.

Maybe I should have clarified. What I meant (on a very high level) is that ICRC-25 using ICRC-29 for transport and ICRC-35 both describe communication between two websites using postMessages.
The interoperability through canister interface is only introduced in ICRC-33. We could as well add an ICRC-25 extension that builds on your proposed interoperability model and defines messages based on routes and an interface distinct from any canister API.
As such, we should try to align ICRC-25 (with ICRC-29) and ICRC-35 so that they are consistent.

Yes, ICRC-25 does a much greater job at preventing this kind of attacks via sessions, scopes and permissions (comparing to MetaMask, for example), but it does not elliminate them. It doesn't matter how hard we try to improve it, there always will be a theoretical possibility to execute such an attack successfully. After a lot of thought about why can't we elliminate them, I came to a conclusion that the key reason for that is the power it gives to an end user. With great power comes great responsibility. And for some fraction of people (technically and mentally prepared to always stay alarmed for possible scam) this is an appropriate solution, since they can handle the responsibility. But this is not an appropriate solution for mass adoption, because regular folks are not technically prepared and don't have a capacity to always stay focused while surfing online.

I think we need to recognize that there is a trade-off here. If we take away too much power from the user, we stifle innovation and make it hard for developers to build new, exciting and composable applications.
We tried finding a good balance between openness, self-sovereignty and security in the ICRC-25 standard. But of course we can still try to improve further. I think this is a good and important discussion to have.
One crucial thing to recognize is that ICRC-25 does not force relying parties to open up to any signer. The standardization just makes it possible. Relying parties can still choose to only accept requests from signers they trust. This is a trade-off they have to make.
In my opinion reputable applications should guide the users regarding the signer choice. There should be recommended signers and a warning if the user chooses a signer that is not well known. We should also consider the possibility of a signer marketplace. This would allow users to choose signers based on their reputation and the services they offer. But ultimately, the user should be able to choose any signer they want. Otherwise, we will remain in a very locked-in ecosystem.
Just as an example, currently there is no way of using MSQ controlled neurons to vote in the NNS dapp. Wouldn't it be nice if users could simply attach MSQ to the NNS dapp and bring in the assets they have there? It would certainly make adoption easier for MSQ.

(malicious SC) They know about this SP, but they have their corrupted motives to not integrate with it. This case is the most interesting one and it requires us to learn more about this new Web3 world. All of our dapps are web-based and DAO-governed. It means, that their software is 100% open-source. It means, that there is no technical know-how component in their success - every know-how gets published and re-used in hundreds of other dapps as soon as it appears. This means, that their success is driven purely by the loyalty of their communities. It means, that these dapps are motivated to always keep their communities happy - otherwise they will switch to a "clone" that offers better conditions. And if this Disk.ic is good and Photoshop.ic's users want it integrated, the team have to obey, to keep thier users happy and their business successful. Otherwise, some other Better-Photoshop.ic will appear, who will copy the codebase, fullfilling all the wishes of the community and stealing the userbase, because it is very cheap to spin up a clone (especially in a world, where you only have to deliver your own business logic and everything else is available through integrations).

I think this represents a very high barrier to entry. Also, there will definitely be widely used dapps that are neither open-source nor decentralized. Just looking at the ecosystem right now, there are many examples of this.
But I think whether the choice of signer / service provider is up to the user or not is independent of the interoperability model. I'd like to separate these two discussions. What do you think?

This is why I also have doubts about the UX capabilities of ICRC-25 and related specs:

Btw. I don't quite understand the criticism here regarding the permission messages. Could you elaborate why ICRC-21 is not sufficient? It exactly offers a human-readable and easily understandable, service-specific consent message.

Under-the-hood stuff, when presented to the end user, breaks the abstraction. Broken abstraction raises questions, which overheat the brain. Overheaten brain loses focus and gets scammed.

While I agree with that statement, I still don't follow why you think this applies to ICRC-21.
ICRC-21 exactly does not expose any under-the-hood stuff to the user. It is explicitly designed to provide a human-readable and easily understandable, service-specific consent message for some user tangible action.
Canisters implementing ICRC-21 do have the explicit option of not providing a consent message for canister calls that should not be called by end-users through signers. Reputable signers should not allow to make calls without a consent message.

Internet Identity learns the origin from the post MessageEvent.origin

You meant that Internet Identity learns the origin of the parent window from the first received valid MessageEvent. So, in theory, another window could send a message to II before the parent.

How would that work? Only the parent window has a handle to the II window.

In other words, downstream clients of ICRC-35 can use JSON-RPC as their message format, while a JSON-RPC-based protocol would only allow a subset of JSON used downstream.

That's a good point. We did not consider that yet in the context of ICRC-25. I will bring it up in the next session.
@plitzenberger: What is your take on this?

To summarize, apart from the technical details, it seems, we have two bigger questions to discuss in the next working group session:

How much choice should the user have? How do we inform users about the importance of that choice and how can we educate them to make good decisions?
What do we want the service integrations to look like?

Canister interfaces vs. bespoke webpage APIs
Interactions with a single signer vs integration with (potentially many) service providers

The answer to these questions is probably more nuanced than a simple decision between ICRC-25 and ICRC-35. I can imagine that there are use-cases that benefit from bespoke integrations with service providers. But I also think that there are many use-cases that can be covered by a generic canister based interface.

Hey @frederikrothenberger

Just as an example, currently there is no way of using MSQ controlled neurons to vote in the NNS dapp. Wouldn't it be nice if users could simply attach MSQ to the NNS dapp and bring in the assets they have there? It would certainly make adoption easier for MSQ.

Yes, it would be nice. But this is completely possible right now. All we have to do is to add "Login With MSQ" button to the NNS dapp (using the client library MSQ provides). And this responsibility lies on Dfinity - If Dfinity finds MSQ appropriate as an additional authentication provider, they could do this, allowing MSQ users to access NNS. So, it is not users' call, it is Dfinity's call.
And I believe this responsibility distribution is good for everyone. Because if Dfinity does that, this would signal for all the NNS users that Dfinity believes that MSQ is a trustworthy piece of software. And Dfinity would only do that, once they conclude some kind of a review themself.

No, I don't. Because I respect Dfinity's intention to protect their users from bad software. I mean, MSQ is good, but guys from Dfinity may have their own opinion about it and they have to be able to not let their users use MSQ to interact with NNS, if they don't want to.

But I think whether the choice of signer / service provider is up to the user or not is independent of the interoperability model. I'd like to separate these two discussions. What do you think?

Agree.

While I agree with that statement, I still don't follow why you think this applies to ICRC-21.

Just as I noted in the original text: My belief is that ICRC-25 Consent Messages won't help with that. Imagine every dapp on the IC implements these consent messages. Users see these pop-ups 100 times a day every day, because on the IC people sign requests much more frequently. People tend to tire from this kind of stuff very quickly. After some time these messages will be perceived as white noise and users will ask for a 'Disable warnings checkbox' feature from their wallet providers.
Elaborating on that, the problem is not in the content of consent messages - that part I'm completely happy with.
It was kinda hard to read that from the ICRC-21 docs, but it seems like a canister, in order to be interoperable, has to implement consent messages for every UPDATE function it has. I believe that will cause a lot of problems.
ICRC-21 treats IC as if it was Ethereum - a network with very infrequent (relative to Web2) transactions, while one of IC's main promises are high performance and infinite throughput. On IC a user may send a lot of transactions (update msgs), visiting a dapp, without doing anything important. For example, HotOrNot counts views for each video. This can be optimized, but in a very naive implementation this would mean that each time a user sees a video, they have to send an UPDATE call. If each such call is accompanied with a consent message, that would be unpleasant.

How would that work? Only the parent window has a handle to the II window.

You're right. I didn't know sending the handle to other browser windows is disabled. I will remove secret-related logic from the handshake. Thank you!

As such, we should try to align ICRC-25 (with ICRC-29) and ICRC-35 so that they are consistent.

The answer to these questions is probably more nuanced than a simple decision between ICRC-25 and ICRC-35. I can imagine that there are use-cases that benefit from bespoke integrations with service providers. But I also think that there are many use-cases that can be covered by a generic canister based interface.

At this moment, the best way to align these two visions, as I see it, would be to merge ICRC-29 with ICRC-35. For signer-related standards, this merged standard would serve as a transport layer. But for the others it would keep the door for webpage API based integrations open.
I could close this PR and re-open it, replacing all 'ICRC-35' entries with 'ICRC-29'. I could also release the '35' number, so others could re-use it. Let me know, what you think.

No, I don't. Because I respect Dfinity's intention to protect their users from bad software. I mean, MSQ is good, but guys from Dfinity may have their own opinion about it and they have to be able to not let their users use MSQ to interact with NNS, if they don't want to.

That was what I meant. But I respect that stance. :slightly_smiling_face:

ICRC-21 treats IC as if it was Ethereum - a network with very infrequent (relative to Web2) transactions, while one of IC's main promises are high performance and infinite throughput. On IC a user may send a lot of transactions (update msgs), visiting a dapp, without doing anything important. For example, HotOrNot counts views for each video. This can be optimized, but in a very naive implementation this would mean that each time a user sees a video, they have to send an UPDATE call. If each such call is accompanied with a consent message, that would be unpleasant.

Ah, now I understand the issue. So the intention never was for ICRC-25 to be the only mechanism for sending transactions.
Rather, it would be an additional mechanism with extra security (for high value transactions only).
So a dapp would authenticate with some IDP and then connect the signer (or later, once supported by https://github.com/dfinity/wg-identity-authentication/blob/main/topics/icrc_34_get_delegation.md authenticate through the signer).
Either way, the dapp would end up in a state where it has

a delegation for some dapp specific principal
a signer identity for cross-dapp / high value transactions

A dapp should do the dapp internal updates / maintain session state through the delegation identity, without asking for consent. Only when the dapp wants tap into shared assets (e.g. the ICP balance, modify ownership of a signer controlled canister, disburse maturity from a signer controlled neuron, etc.), there would be a user consent pop-up.
A fair criticism of that model is that it may not be straight forward to split a dapp into a "low value & high transaction volume" and "high value & low transaction volume" parts. However, even just splitting out the obvious parts (e.g. token transactions) would be a big improvement: tokens could no longer be stolen if the dapp is compromised.
As the model matures, I think there will be more example and best practices for devs to follow on how to split the transactions among the delegation identity and the signer identity.

At this moment, the best way to align these two visions, as I see it, would be to merge ICRC-29 with ICRC-35. For signer-related standards, this merged standard would serve as a transport layer. But for the others it would keep the door for webpage API based integrations open.

Currently, ICRC-29 is laser focused on the transport mechanism only (window post messages). Message content is out of scope and defined in ICRC-25 and its extensions. I like that model, because it allows to swap the transport mechanism independently of the message content.
Is there a reason why ICRC-35 is scoped to window post messages, rather than a more abstract notion of a transport mechanism? There might be value in having other transport channels available for ICRC-35 too, no? For example app switch on mobile?
Looking forward to discuss this further in tomorrows working group session. I hope you'll attend!

A dapp should do the dapp internal updates / maintain session state through the delegation identity, without asking for consent. Only when the dapp wants tap into shared assets (e.g. the ICP balance, modify ownership of a signer controlled canister, disburse maturity from a signer controlled neuron, etc.), there would be a user consent pop-up.

First of all, thank you for telling this. As a newcomer, it was hard for me to read this from the docs. I would suggest to include this information, about how all the signer-related standards should interact with each other in practice, into the overview documentation. I mean, like a section written in very simple words, so everybody could read and understand the main idea from such a description. Including details (which might look obvious for the WG members, but are not for outsiders) like:  Does that mean, that all the other standards also only operate with these signer identities? Are signer identities scoped or shared across all dapps?
So, basically the idea is for dapps (SPs) to prepare an integration surface (canister API) in advance. Such a surface should be well documented, covered with consent message endpoints and only accessible through a signer identity. Each dapp has its own implementation details, so API of each SP may differ, even if they provide very similar services. These APIs can only converge to a single one, if they are standardized. Other dapps (SCs) would have to study APIs of each SP and integrate with each of these APIs manually. For that they would request an identity from a signer that is responsible for making calls for each SP and, with the user's blessing, use that identity to interact with those SPs.
Is this correct?
If that is correct, then how ICRC-33 is different from ICRC-35 in terms of generalization:

To allow an SC to integrate with any user-provided SP the interactions need to be standardized. But the proposed interactions (by looking at the example) are very service specific. I.e. calling another service requires the SC to know the exact routes and parameters.
It seems to me that having true interoperability between SCs and SPs is not possible with the proposed solution, or will require a huge amount of standardization...
This is why we took a more generic approach with ICRC-33: it allows calling services that the signer does not know and does not have a specific integration with.

In order for one service to integrate with another it would still need to somehow invoke icrc33_call_canister with the right arguments. Revisiting your older comment, I've found this:

Looking at your perfect scenario, this could absolutely be implemented as an ICRC-25 extension that defines the appropriate file methods. Note that generic canister calls have been split into ICRC-33.

Which makes me think that standardization for APIs is the proposed solution for generalization. But then why did you say that the standardization is a bad idea in the context of ICRC-35?
(By the way, about being able to do this UX flow in ICRC-25. How that would even work? Websites integrate with canister calls in ICRC-25, so the SC would have to render all of the integration-guiding screens itself, while in ICRC-35 each website renders its own screens, which is better, because they know about their own implementation details better than anyone else and they don't have to document all of it).

It seems to me that having true interoperability between SCs and SPs is not possible with the proposed solution, or will require a huge amount of standardization...

Webpage APIs can also be standardized. So all authentication providers would share same APIs, for example. Moreover, these APIs can be made a part of an asset-canister to become a part of the dapp's DAO-governed perimeter, so it is hard to change them without notice. Just describe it in a file and make a standard that would allow to only call the APIs, if they are in this file. Same way candid files work.
I see less and less pros in ICRC-25 & others. With each new revealed detail it seems more and more like ICRC-35 with extra steps and with unclear gain from these steps.

Currently, ICRC-29 is laser focused on the transport mechanism only (window post messages). Message content is out of scope and defined in ICRC-25 and its extensions. I like that model, because it allows to swap the transport mechanism independently of the message content.

What's your take on aligning ICRC-35 with others?

Is there a reason why ICRC-35 is scoped to window post messages, rather than a more abstract notion of a transport mechanism? There might be value in having other transport channels available for ICRC-35 too, no? For example app switch on mobile?

The deal with ICRC-35 is that it is not about the message content and how they are passed between parties. It is about the postMessage and webpage APIs. It doesn't make any sense with different transport channel, because the channel is the interoperability framework.
And moreover, you can integrate a lot more than just between websites with it. For example, MSQ is a MetaMask extension (an extension of another browser extension), but you can still integrate with it with ICRC-35, because MSQ has a webpage. If your mobile app also has a webpage, you can integrate with it easily - you would just need an additional channel to pass data between that webpage and the mobile app (for example, deep linking). Having postMessage as the only transport channel allows the protocol to be much more universal, than if it would allow to swap channels.

Looking forward to discuss this further in tomorrows working group session. I hope you'll attend!

I'm looking forward to that as well!

@frederikrothenberger
Thanks a lot!
I'm going to edit this PR so it aligns better with the file structure of the repo. Plus I need to modify the Hanshake phase, as we discussed.
Going to make it before the next WG call.

@frederikrothenberger
I did all the updates I wanted. Confirm everything is fine and I can merge this PR.
Thanks!

@frederikrothenberger
Oh, I thought I can push. But, Only those with [write access](https://docs.github.com/articles/what-are-the-different-access-permissions) to this repository can merge pull requests.


Init

@tzvetkoff I could use your help on some of these (like C) 👀

@4kimov, sorry for being quiet lately - 8m in vacation until Aug 19.
The C version is mostly done, minus the UTF8 support, which I started adding literally 2 days ago using utf8proc.
The tricky part was to find a way to build it locally and statically, so libsquids.so doesn't introduce additional dependencies.
Anyway, I hope I'll have the time to finish it this Sunday.

@tzvetkoff Ah cool, thanks for the heads up and the work-in-progress. Didn't know you were on a vacation, enjoy! A few minor things worth noting for when you're back:

Added an additional check in the spec recently to test for repeating reserved characters
Some libs do require the use of other libraries/dependencies, so we removed the "no dependencies" bit a while back (up to you; not a problem if code needs to depend on something else)
Lastly, as usual if you need access to anything or have questions, I'm here 👍

@4kimov, sorry it took me so much time to get this done but until recently I didn't have:

The time to get everything in place, especially the UTF8/multi-char support
Realized that UTF8 is not ultimately required now

A WiP branch will be available shortly (the moment I generate a parser-generator for the spec tests) and then I'll proceed with implementing the cucumbersome blocklist (it really have me headaches trying to do UTF8 regexes in C)
FWIW, most of the heavy lifting has already been done, like dynamic string allocation, encoding, now I need to finalize things like min-length and blocklist (which I almost implemented previously, before I decided to go full-UTF8.)

@tzvetkoff Thanks for the update, good to hear from you. No problem, everybody's busy, that's ok. Looking forward & let me know if I can help with anything 👍

I'm also interested in this work. @tzvetkoff If you don't mind opening your WIP branch, I'd like to start from there.

Took me a little more than I originally expected, mostly because I couldn't find the time to think it through and to adapt to the latest spec changes.
Anyway, I finished porting both the codebase and most of the tests, so... enjoy!
P.S. In the next days I'll also tag a release, I just need to think of a few more things, like:

do we need sqids_errno?
do we need dynamic string allocation or we can safely estimate encoded number length?
automatic builds (using GitHub actions)

@OctopusET Thanks for offering to help. This is a community effort, so suggestions / PRs / etc are definitely always welcome 💪

@tzvetkoff Thanks for the initial push! I'm definitely too rusty on C in order to help with your questions, but I have a few of my own for you:

Is there an example somewhere of the 3 repetitive code samples that I could use for the website?
If most of the tests are there, is it stable enough to update the site?

It would be better to make this project much more portable to support different systems. I found some portability issues in these codes. Also choosing the C standard like C99 would be helpful.
Plus, I think there would be  improvements for the blocklist. Instead of having multiple API for languages.

@OctopusET, unless you share what "portability issues" you have found, there's not way for us to resolve them.  I, for one, have not mastered the subtle art of precognition.
"Choosing the C standard..."
If you have looked at the code, it is clearly C99 (in fact hashids.c was also C99 because it required <stdint.h>) because it uses variable-length arrays heavily.
The tests might use something GNU-specific, which I can easily rewrite.
As for the multiple languages API, this is entirely my preference here - I personally think that the way we currently ship the blocklist is insane and we need to change this, because very soon it will explode.
That been said, all of these topics are for another discussion. Feel free to open a new issue for each relevant topic.


Can't edit or write code in visual code

Issue Type: Bug
i was input alphabet and number but in vs code can't write code please help me.thank you all
VS Code version: Code 1.53.2 (622cb03f7e070a9670c94bae1a45d78d7181fbd4, 2021-02-11T11:48:04.245Z)
OS version: Windows_NT x64 10.0.18362

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5 CPU       M 450  @ 2.40GHz (4 x 2394)

GPU Status
2d_canvas: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: unavailable_offopengl: enabled_onprotected_video_decode: enabledrasterization: unavailable_offskia_renderer: enabled_onvideo_decode: enabledvulkan: disabled_offwebgl: enabledwebgl2: unavailable_off

Load (avg)
undefined

Memory (System)
3.80GB (0.95GB free)

Process Argv
--crash-reporter-id e574ebe7-f485-4b88-bff8-f4d1dee5654a

Screen Reader
no

VM
0%

Extensions (7)

Extension
Author (truncated)
Version

dart-code
Dar
3.20.1

flutter
Dar
3.20.0

emulate
Die
1.4.0

cpptools
ms-
1.2.2

vscode-typescript-next
ms-
4.3.20210305

vim
vsc
1.18.9

omi-snippets
Wsc
2.2.8

/needsMoreInfo
Is it reproducible with all extensions disabled?
You can try this with F1 and >Developer: Reload Window With Extensions Disabled
Most likely caused by Vim extension,


MemoryError for relatively big point clouds

I'm getting the following stack trace on an attempt to register 3D point clouds with about 40K points each:
  File "/home/theuser/anaconda3/lib/python3.5/site-packages/pycpd/affine_registration.py", line 24, in register
    self.initialize()
  File "/home/theuser/anaconda3/lib/python3.5/site-packages/pycpd/affine_registration.py", line 86, in initialize
    XX = np.tile(XX, (self.M, 1, 1))
  File "/home/theuser/anaconda3/lib/python3.5/site-packages/numpy/lib/shape_base.py", line 912, in tile
    c = c.reshape(-1, n).repeat(nrep, 0)
MemoryError

This happens both with rigid_registration and affine_registration. Should this algorithm be so memory consuming? How can I estimate the memory usage in 3D from the number of points?
(I have 16 Gb RAM if it matters)

The P matrix, calculated in the E-step,
has M times N number of elements, where M and N are the size of fixed and moving point clouds, respectively.
This means that you are allocating (40K)^2 floating numbers. This is about 102 GB of memory.

OK, thanks

i have the same problem , what can i do ??
any one solved it??
imaginary-unit

@hodaatef What I ended up doing is just using a random sub-sample of my point cloud, which fits in memory. That's the only solution I can think of.

Random subsampling might be sufficient for you. Something better might be spatial subsampling:
http://pointclouds.org/documentation/tutorials/voxel_grid.php#voxelgrid
That way you will be able to make sure that the subsampled point cloud has roughly the same spatial distribution as the original point cloud.

@siavashk I did voxel downsampling from open3d but the point cloud is still too large and the memory error still occurs. Any insights on how I should proceed?
Thanks in advance.

@sandwich25 do you have an estimate for how much your point cloud was downsampled? You can do this by computing number_of_points_after_downsampling / number_of_points_before_downsampling.  I would suggest doing more downsampling until the issue goes away.


[QnA Maker] Multi-turn support in SDK

Multi-turn support in SDK

Pull Request Test Coverage Report for Build 75305

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 88.289%

Totals

Change from base Build 75261:
0.0%

Covered Lines:
3535

Relevant Lines:
3846

💛  - Coveralls


[WIP] Implement Circular Buffers for Auto Annotation

Trying to implement some circular buffers for auto annotation in order to avoid running out of RAM.
See here for the motivation: https://github.com/opencv/cvat/issues/1224
One thing that I don't understand is the tracks that is part of the Results class.
https://github.com/opencv/cvat/blob/e7808cfb0322c1adcf61e7955b8b4a8c2badd0d2/cvat/apps/auto_annotation/inference.py#L34-L38
I assume that I need to implement a circular buffer for the tracks objects as well as the shapes. With this current PR, every 128 frames all the past tracks get thrown away.
I assume this isn't desirable, but I've never used tracks, so I'm not sure what the expected behavior is.
@nmanovic, can you shed some light on what's expected here?

After doing some digging, it appears that tracks were added by this PR: https://github.com/opencv/cvat/pull/389
There is no reference to them in the auto annotation documentation. Prior to https://github.com/opencv/cvat/pull/389, tracks did not exist in the Results class. It looks like there is some sort of tracking functionality within CVAT somewhere, for videos? I'm not 100% sure, but it's mentioned in several issues.
The implementation of auto annotation currently does not record any of the tracking information. It gets dropped before the data is serialized. Maybe this is a future feature? Or a feature to help label shapes.
I'm not sure if it's used in the wild anywhere though. Which leads me to believe that implementing a circular buffer for shapes would be enough for now to fix the issues with annotating large videos. Thoughts?

normally tracks have a kindof Time-Out property that deletes tracks when they did not get any update in the last X frames

Hmm, it would be possible to implement some sort of file based list interface, so that we could pretend that RAM is infinite. That would avoid the tradeoffs of figuring out the right amount of data to keep.
However, tracks don't have a public interface to add any data to them. So tacks looks like a future interface, and I'm not interested in over optimizing this PR.
I'll clean up the commit history, do some additional testing, and submit this in close to it's current condition, without worrying about tracks.

@benhoff, what do you think about implementing and returning an iterator? Something like implemented in Datumaro here: https://github.com/opencv/cvat/blob/master/datumaro/datumaro/components/launcher.py#L32-L50
with an example of launcher here:  https://github.com/opencv/cvat/blob/master/datumaro/datumaro/plugins/openvino_launcher.py#L172-L179

@zhiltsov-max , I thought about it, but do to the serialization that is done I thought it was better to send the data in batches.
Do you think that the overhead of serialization is small enough that it makes sense to implement an iterator?
See here for the serialization step:
https://github.com/opencv/cvat/blob/9344b067b1db54b641c36f651c4255c2857211f1/cvat/apps/auto_annotation/model_manager.py#L246

@zhiltsov-max, after looking at your code I realized that you were talking about a design optimization. If the patch works, I'd rather it gets merged. I don't want to spend more time on the patch unless it has bugs.

@benhoff , thanks for the contribution! As usual your help is vital for our open source project.
@azhavoro, could you please look at the PR? Please test it and merge if it works as expected.

@benhoff , about your questions regarding tracks. Automatic annotation doesn't support tracks. It detects shapes on each frame indivisually.


Add token duality e2e testing script

based on https://github.com/celo-org/op-geth/pull/21
See https://app.circleci.com/pipelines/github/celo-org/optimism/398/workflows/b5aac39e-5035-47bb-86d1-3c2151ca3cc4/jobs/5132/parallel-runs/0/steps/0-114 for CI results.

I have no idea why "ci/circleci: op-e2e-HTTP-tests" fails three times in a row but succeeded before this PR.


Possible solution to the citation problem!

I, like [you](https://github.com/OliverBalfour/obsidian-pandoc/wiki/Citations-(work-in-progress), really want to have my Obsidian internal links / wikilinks AND markdown citations rolled into one :)
I've been fiddling about with an "emergency" project that grew into a plugin which overlaps a bit with this one, "https://github.com/jeetsukumaran/obsidian-impresario". The motivation behind that was primarily I wanted to build in the full compile instructions into the document YAML properties because I kept forgetting the way I mean the document to be compiled when revisiting it (e.g., slide level), and wanted an easier way to make sure all the filters/templates/javascript assets etc. would be bundled.
There is a Lua filter with that plugin:
https://github.com/jeetsukumaran/obsidian-impresario/blob/main/resources/publication/pandoc/filters/pdcites.lua
that works on wikilinks parsed when the "wikilinks_title_after_pipe" extension is specified, and takes the title string and wraps it up as a Pandoc citation.
The following:
---
bibliography: "+system/testing/pd-cites/p1.bib"
---

## Pandoc native

The following formats are native Pandoc:

[@shannon-1948-mathematical-theory]
[@{shannon-1948-mathematical-theory}]

## Obsidian native

The following must work through the filter:

- [[@shannon-1948-mathematical-theory]]
- [[discovery/sources/references/s/@shannon-1948-mathematical-theory|@shannon-1948-mathematical-theory]]
- [[Untitled|@shannon-1948-mathematical-theory]]

Here, we have multiple citations, separated by semicolons [ [[discovery/sources/references/s/@shannon-1948-mathematical-theory|@shannon-1948-mathematical-theory]];
[[discovery/sources/references/m/@morlon-2014-phylogenetic-approaches|@morlon-2014-phylogenetic-approaches]];
[[discovery/sources/references/k/@kingman-1982-coalescent|@kingman-1982-coalescent]]
].

## Explicit vs. implicit citation based on title

- [[discovery/sources/references/k/@kingman-1982-coalescent|@kingman-1982-coalescent]]
- [[discovery/sources/references/s/@shannon-1948-mathematical-theory|@shannon-1948-mathematical-theory]]
- [[discovery/sources/references/k/@kingman-1982-coalescent]]
- [[discovery/sources/references/s/@shannon-1948-mathematical-theory]]

results in:

Hi @universvm and @mokeyish -- we have had this ^ discussion before. Tagging you here in case you might be interested in adopting as well.

Writing here to express interest in this solution. It would be really great to have the citations and links rolled into one!


bugfix: h7 protocol, flush rx after bind

I finally got to test the H7 protocol, and it did not work well with my tx. Anyway I redone it in a similar way to the other ones. It does look like your way should work, but it seems to drop a lot of packets with my tx. Maybe timing differences.

I finally got to test the H7 protocol, and it did not work well with my tx.

Interesting, I must admit that I don't really know how to debug the code besides using the debugger.

It does look like your way should work, but it seems to drop a lot of packets with my tx.

yes, that's true,  my implementation assumed that we receive every second  package,
It was based on a signal captured from my m9912 copter:
https://github.com/stawel/stuff/tree/master/m9912_copter/copter
but you are right, I don't see a reason why not to receive all packages.
I do however have some comments to your commit,
I will add them to it if you don't mind.


JDBC client threads prevent JVM shutdown

There are at least a couple of (lame) work arounds. The easiest way is to terminate the JVM at the end of main thread:
System.exit(0);

Another option is to de-register the driver and then force a garbage collection which should invoke the finalizer (simply calling close() does not work because there are actually two instances of the driver -- one from registerDriver() and the other from ServiceLoader):
Driver driver = DriverManager.getDriver("jdbc:presto://");
DriverManager.deregisterDriver(driver);
System.gc();

Of course, we need to fix this properly in the driver.

We should be able to fix this in the JDBC driver by making all threads daemon threads.

This was fixed by e138a630 in release 0.76.


Removing redundant subclass assertions.

Fixes #13275

In the interests of transparency, this is the utterly evil script I used:
#!/usr/bin/perl

while(<>) {
    if (m@^relationship: (.*) \!@) {
        my $tuple = $1;
        if ($last =~ m@^intersection_of: (.*) \!@) {
            if ($1 eq $tuple) {
                next;
            }
        }
    }
    $last=$_;
    print;
}

I promise to do by scowl or something in future..

to see the diff on the command line:
git diff origin/issue-13275

Hello,
I marked this editors-discussion because I'd like to know which redundant relations were removed, and which ones we should remove by hand (if any).
Thanks, Pascale

I re-ran this: #13397

Random snippet:
[Term]
 id: GO:0002497
@@ -22269,7 +22097,6 @@ synonym: "B-cell deletion" EXACT []
 synonym: "B-lymphocyte deletion" EXACT []
 intersection_of: GO:0001783 ! B cell apoptotic process
 intersection_of: part_of GO:0002514 ! B cell tolerance induction
-relationship: part_of GO:0002514 ! B cell tolerance induction

 [Term]
 id: GO:0002517
@@ -22335,7 +22162,6 @@ synonym: "leukocyte trafficking during immune response" EXACT []
 is_a: GO:0002252 ! immune effector process
 intersection_of: GO:0050900 ! leukocyte migration
 intersection_of: part_of GO:0006955 ! immune response
-relationship: part_of GO:0006955 ! immune response

 [Term]
 id: GO:0002523
@@ -22350,7 +22176,6 @@ synonym: "leukocyte migration during inflammatory response" RELATED [GOC:dph
 synonym: "leukocyte trafficking during inflammatory response" RELATED []
 intersection_of: GO:0050900 ! leukocyte migration
 intersection_of: part_of GO:0006954 ! inflammatory response
-relationship: part_of GO:0006954 ! inflammatory response


fix #32

Fix #32.

Also, please, update the .podspec to a proper version number if you decide to merge this

+1

I've bumped the version to v2.2.2 and pushed to CocoaPods Trunk. Thanks for fixing this, @stefanomondino!