Docker version requirement is wrong

The docker version requirement for starting a local cluster is documented [here] (https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/locally.md) as 1.0.0+.
I had docker 1.0.x installed on my machine and couldn't start a cluster. After examining the log, the health check sent to the nodes all failed. Manually sending the check showed that the docker version was too old.
curl -L http://<IP_ADDRESS>:10250/healthz
Docker version is too old (1.12)

We should update docs.  We require Docker 1.3.
The docker version requirement for starting a local cluster is documented
here
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/locally.md
as 1.0.0+.
I had docker 1.0.x installed on my machine and couldn't start a cluster.
After examining the log, the health check sent to the nodes all failed.
Manually sending the check showed that the docker version was too old.
curl -L http://<IP_ADDRESS>:10250/healthz
Docker version is too old (1.12)
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/4394.

Closed with #4398


Error in makeContrasts("arg.groupC3-TAG-arg.groupILC-Pik3Ca/Cdh1Null",  :

Error in makeContrasts("arg.groupC3-TAG-arg.groupILC-Pik3Ca/Cdh1Null",  :
The levels must by syntactically valid names in R, see help(make.names).  Non-valid names: arg.groupC3-TAG,arg.groupILC-Pik3Ca/Cdh1Null,arg.groupKPB-1A,arg.groupKPB-1B,arg.groupKPB-Primary,arg.groupKPB25L-Apobec,arg.groupKPB25L-UV,arg.groupNML-BALBC,arg.groupNML-FVB,arg.groupp53-2151,arg.groupp53-2153F,arg.groupp53-2224,arg.groupp53-2224L,arg.groupp53-2225L,arg.groupp53-2245,arg.groupp53-2336R,arg.groupp53-9263-3,arg.groupp53-T1,arg.groupp53-T12,arg.groupp53-T2,arg.groupp53-T6,arg.groupp53-T7,arg.groupT11-Apobec,arg.groupT11-UV
Calls: eval -> eval -> eval -> makeContrasts
Execution halted

Hi @xhhwhc,
As you see from the error message, the issue is your group names. You have a bunch of "special" characters in these names that the makeContrasts function does not like, this is also stated in the manual.
So my idea would be to do a search and replace in your file.
Replace the "/" and importantly the "-" with an "_".
You might also consdier replacing the "," with a ".", however I am not sure this is absolutely necessary.
Cheers,
Thilde


Avoid cancellation of other architecture tests if one fails

Prevents all architecture tests from being cancelled if one fails

📚 Documentation preview 📚: https://metatrain--345.org.readthedocs.build/en/345/

Why? the point of cancelling is to not waste CI time doing the same thing twice since the CI will have to re-run after the one architecture is fixed.

I think it's useful to see what broke and what didn't. Anyway, there is a codecov issue

It can be useful, but it also hogs resources in a single PR. As far as I understand, github only allows for a limited number of simultaneous jobs across a given organization, so every job running on code that we know is broken might prevent CI from running in a separate PR on a separate repo.


[FR] Support links within the select column type.

Currently links show link this in select columns:

Would hope that they could show as actual links!

hi @arminta7! currently links are just supported with text column type. Render markdown links inside that label could be a thing... It will be considered =)

This go out of my capabilities.
Render links inside select needs a markdown render of obsidian and affect the actual visual component. Sorry but I have to discard this issue until the arch of obsidian allows it


Owned key type

Currently the Key type takes either a ref, or a fixed-length byte slice:
pub enum Key<'a> {
    Ref(&'a [u8]),
    Val8([u8; 1]),
    Val16([u8; 2]),
    Val32([u8; 4]),
    Val64([u8; 8]),
    Val128([u8; 16]),
}

The drawback of this is that when implementing the PrimaryKey trait, we can't use any custom serialization method of which the output is of variable length.
Example
Here is an actual use case I've worked on. Consider the following type:
enum AssetInfo {
    // bank module native coin
    Native { denom: String },
    // cw20 token
    Cw20 { contract_address: String },
}

We want to create a Map<&AssetInfo, Uint128> to record a user's asset balances. To do this we need to implement PrimaryKey on &AssetInfo. Specifically we want to serialize it the following way:
impl AssetInfo {
    pub fn serialize(&self) -> Vec<u8> {
        let mut bytes = vec![];

        // for native coins, we prefix the denom with a zero-byte (0x00)
        // for cw20s, we prefix the contract address with a one-byte (0x01)
        match self {
            AssetInfo::Native { denom } => {
                bytes.push(0);
                bytes.extend(denom.as_bytes());
            }
            AssetInfo::Cw20 { contract_address } => {
                bytes.push(1);
                bytes.extend(contract_address.as_bytes());
            }
        }

        bytes
    }
}

And we implement PrimaryKey as follows:
impl<'a> PrimaryKey<'a> for &'a AssetInfo {
    type Prefix = ();
    type SubPrefix = ();
    type Suffix = Self;
    type SuperSuffix = Self;

    fn key(&self) -> Vec<Key> {
        let bytes = self.serialize();
        vec![Key::Ref(&bytes)] // compile error!
    }
}

But this doesn't work! The bytes variable goes out of scope at the end of the function, so the returned &bytes becomes a dangling pointer!
Alternatively, we can do something like this:
impl<'a> PrimaryKey<'a> for &'a AssetInfo {
   type Prefix = ();
   type SubPrefix = ();
   type Suffix = Self;
   type SuperSuffix = Self;

   fn key(&self) -> Vec<Key> {
       let mut keys = vec![];

       match self {
           AssetInfo::Native { denom } => {
               keys.push(Key::Val8([0]));
               keys.push(Key::Ref(denom.as_ref()));
           }
           AssetInfo::Cw20 { contract_addr } => {
               keys.push(Key::Val8([1]));
               keys.push(Key::Ref(contract_addr.as_ref()));
           }
       }

       keys
   }
}

But this this is inefficient, as the first key (the Val8) is going to be prefixed by its length. The resulting key is two bytes longer (you get an extra 0x00 0x08).
Potential solution
Add a enum variant to Key which takes an owned, variable-length byte array:
pub enum Key<'a> {
+   Owned(Vec<u8>)
    Ref(&'a [u8]),
    Val8([u8; 1]),
    Val16([u8; 2]),
    Val32([u8; 4]),
    Val64([u8; 8]),
    Val128([u8; 16]),
}

This way, when implementing PrimaryKey we can simply do:
impl<'a> PrimaryKey<'a> for &'a AssetInfo {
    type Prefix = ();
    type SubPrefix = ();
    type Suffix = Self;
    type SuperSuffix = Self;

    fn key(&self) -> Vec<Key> {
        let bytes = self.serialize();
        vec![Key::Owned(bytes)]
    }
}

Yes, I had the same problem before. Adding an owned variant seems like a straightforward solution to me.

The fixed size value types are there to avoid creating arbitrarily sized keys in the first place.
Now, I see the reason for your change. And, we never really measured the performance impact of using a large key by value.
So, I'm OK with this change. It would be good to benchmark the overhead of using a large key value instead of a reference. It's probably negligible.


Unstable feature: const generic domain

Description
This addresses the replacement of Vec with const, as per this comment (@Pratyush is this what you meant?). Unfortunately, right now const generic parameter type of &'static [u8] is only available on nightly under the adt_const_params feature.
We should probably leave this PR out for now, but I am opening a draft for future reference.

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[x] Targeted PR against correct branch (master)
[x] Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
[ ] Wrote unit tests
[ ] Updated relevant documentation in the code
[ ] Added a relevant changelog entry to the Pending section in CHANGELOG.md
[x] Re-reviewed Files changed in the Github PR explorer

I think the existing API (after your PR https://github.com/w3f/arkworks-algebra/pull/23) is pretty good!
In particular, since we aren't storing the domain in the hasher, we can just pass it in once during initialization (as is done currently), and don't need a const-generic for it.


Now custom operators can also inherit Operator indirectly

Change Description
In OperatorsFactory in function __get_operators_by_type() line operators = Operator.__subclasses__() was commented out. Inplace of this line, new line operators = OperatorsFactory.__get_all_subclasses(Operator) was added. Function __get_all_subclasses() was added:
    @staticmethod     def __get_all_subclasses(cls):  # add this method         subclasses = []         for subclass in cls.__subclasses__():             subclasses.append(subclass)             subclasses.extend(OperatorsFactory.__get_all_subclasses(subclass))         return subclasses
Unit-tests and integration-tests was provided.
Issue reference
This PR fixes issue #1093.
Checklist

[x] I have reviewed the contribution guidelines
[x] I have signed the CLA (if required)
[x] My code includes unit tests
[x] All unit tests and lint checks pass locally
[ ] My PR contains documentation updates / additions if required

@alex-ber please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]

Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

Thanks @alex-ber! We'll review this in the next few days.

/azp run

Hi @alex-ber, I've reviewed the PR and left a few comments. However, I feel that while this is solving the specific problem you've experienced, we can think of a more generic solution of allowing the user to plug in custom operators, similarly to how we can plug in recognizers in the presidio-analyzer side of things. This would not only solve this problem, as there will be no searching for subclasses, but also would allow users to create tailored de-identification pipelines.
As you've done all this great work, I would suggest that we integrate those changes once the PR is approved, but if you're interested in tackling the more generic problem, that would be very beneficial for users of this package.

@alex-ber will you be interested in completing this? Please take a look at the CI pipeline results and/or ping us if we can help with anything.

help

I would like to receive help with hints.
@omri374 Thank you for you feedback, I will continue to wok on this later.

/azp run

Closing this PR. While we definitely want to have an ability to load new types of operators, the solution should be similar to the RecognizerRegistry and not through cls.__subclasses__() as it might have unexpected behaviors.


[Enhancement] Config to re-enable Fallen Knight Archers

I saw this in the changelog on the Curse page.
"Fixed Fallen Knights doing zero attack damage; also now they never spawn with a bow."
Was something wrong with them?
I don't want to never encounter mounted archers. So a config option to re-enable Fallen Knight Archers would be appreciated.

Sure I will look into, i forget why i changed it.

I remember now, the ranged attacks werent working .  But still i will revisit this later

They now default to 40% archers or something, change in config  https://minecraft.curseforge.com/projects/emberroot-zoo/files/2535187


Gluon 2.0 Dataloader should support BERT training using GluonNLP

Description
Currently we cannot use 2.0 Dataloader to train BERT, and the reason is 2.0 Dataloader is not flexible to support the data schema used by GluonNLP BERT, specifically if passing in a nested list of variable length numpy array, the construction of dataset would fail and throw NDArray conversion errors
Here is a minimal reproducible code, which is the similar data schema BERT pre-training script is using:
import mxnet as mx
import numpy as np
a = np.ndarray(shape=(128,)) # similar to one feature of one sequence
b = np.ndarray(shape=(19,))
l1 = [a,b]                                   # similar to one feature of all sequences
l2 = [a,b]
c = [l1, l2]                                 # similar to a training instance that will be sampled against
ds = mx.gluon.data.ArrayDataset(*c)
dt = mx.gluon.data.DataLoader(dataset=ds, batch_size=1, num_workers=1, try_nopython=True)
print('ok') # error out before prints
References
https://github.com/apache/incubator-mxnet/pull/17841

@eric-haibin-lin @sxjscience @zhreshold FYI

I can reproduce this failure message:
import mxnet as mx
import numpy as np
mx.npx.set_np()
a = np.ndarray(shape=(128,)) # similar to one feature of one sequence
b = np.ndarray(shape=(19,))
l1 = [a,b] # similar to one feature of all sequences
l2 = [a,b]
c = [l1, l2] # similar to a training instance that will be sampled against
ds = mx.gluon.data.ArrayDataset(*c)
dt = mx.gluon.data.DataLoader(dataset=ds, batch_size=1, num_workers=1, try_nopython=True)
print('ok') # error out before prints

Error message:
~/miniconda3/lib/python3.7/site-packages/mxnet/gluon/data/dataset.py in __mx_handle__(self)
    383                     datasets.append(data.__mx_handle__())
    384                 else:
--> 385                     datasets.append(NDArrayDataset(arr=default_array(data)))
    386             self.handle = GroupDataset(datasets=datasets)
    387         return self.handle

~/miniconda3/lib/python3.7/site-packages/mxnet/util.py in default_array(source_array, ctx, dtype)
    936     from . import np as _mx_np
    937     if is_np_array():
--> 938         return _mx_np.array(source_array, ctx=ctx, dtype=dtype)
    939     else:
    940         return _mx_nd.array(source_array, ctx=ctx, dtype=dtype)

~/miniconda3/lib/python3.7/site-packages/mxnet/numpy/multiarray.py in array(object, dtype, ctx)
   2407             # printing out the error raised by official NumPy's array function
   2408             # for transparency on users' side
-> 2409             raise TypeError('{}'.format(str(e)))
   2410     ret = empty(object.shape, dtype=dtype, ctx=ctx)
   2411     if len(object.shape) == 0:

TypeError: setting an array element with a sequence.

in 2.0, if try_nopython is set to false, then the behavior is the same as 1.0
if try_nopython is true, dataset has to be converted to ndarray and the nested arrays with different types and shapes is causing the problem. If anyone can help figure out the correct layout for converting the complex bert style dataset I can help look into the fix.


Add device capability HVTypeKubevirt

Add HVTypeKubevirt as a device capability

Also, add the missing capabilities CPUPinning and VHost.
These capabilities should match the Capabilities published by domainmgr in eve.
Even if those missing capabilities are not used by Controller, lets publish those
for consistency.

We cannot use api_capability IMO. That's a hardcoded value and will be used for kvm based eve too !
Can we compile time generate that ?

@zedi-pramodh I agree with Erik on this. What you describe here is Software capability of specific hypervisor. So it would be confusing to developers if we have software capability in hardware capabilities. Moreover, this field will depend on EVE version which makes backward compatibility trickier.
Perhaps, it might make sense to structure software capabilities in API

We cannot use api_capability IMO. That's a hardcoded value and will be used for kvm based eve too ! Can we compile time generate that ?

We can make it report different api_capabilities based on eve-hytype.
However, when we introduce the next api capability we will end up with holes on the sequence with some implement "next" + kubevirt + current set, and others implementing "next" + current set.
So we need to start planning for reporting a map of eve api capabilities and not just the largest number (something we knew we'd need to do sooner or later). Question is whether we want to do that as an opt-in or opt-out. For kube-virt the opt out would be efficient - can express "next" + current set except kubevirt.
But if we want to have EVE agents which implement a small subset of the API down the road then an opt in might be more clear? In any case, we don't need to solve that until we need to add the next api capability after this.

@naiming-zededa @milan-zededa please provide your inputs too.

@naiming-zededa @milan-zededa please provide your inputs too.

I think Erik's suggestion on temporary solution for kubevirt is fine with me. Basically we add 'kubevirt' to the end of the this api-capability enum. Only kubevirt eve software set this, kvm will just use 'kubevirt' - 1 number. If later we want to add one more capability in the future, we need to redesign this to a map structure for api-capability, that that is for later to handle.

IMHO this is neither HW nor SW capability, rather a field informing about which EVE OS variant is running on a given device. Therefore, it might make sense to add Hypervisor enum into ZInfoDevice, perhaps under a new OSInfo structure?

current APICapability 'Snapshot' uses 5, maybe Kubevirt can be added as '10', so later on new capability if is only related to EVE version support, can still use number 6-9 (kubevirt also needs to add 11-14 definitions), thus further kicking the can down the road :-)

FWIW that wouldn't work since we'd be making the statement that the kubevirt image we ship today would support all the (undefined) capabilities with APICapability < 10.

IMHO this is neither HW nor SW capability, rather a field informing about which EVE OS variant is running on a given device. Therefore, it might make sense to add (more generic) Hypervisor enum into ZInfoDevice, perhaps under a new OSInfo structure (or into existing ZInfoDevSW)?

Good point.
If it is not about particular capabilities but effectively sending /run/eve-hv-type to the controller, then it would make sense to define that in the info message (maybe in the hwinfo since it doesn't change unless the device is rebooted).
But it all depends what decisions we think the controller will make based on this. Do we know what those planned decisions hence implied semantivcs are today?

But it all depends what decisions we think the controller will make based on this. Do we know what those planned decisions hence implied semantivcs are today?

Current plan is to use this field to support native container deployments and as well as any storage/compute clustering related features.

We can do that @naiming-zededa . Just that controller/UI need new code to process that new message. I am fine with whatever the decision is.

it should be similar for controller/UI to check either something called 'apicapacity' or the 'optionalcapability' items, not much difference in this regard.

Should we leave this API-capability along since it's basically a software-version, and just adding another 'capability', say message OptionalCapability { bool HvTypeKubevirt = 1 } to start with, it seems cleaner.

Might want to name that in plural (OptionalCapabilities) since I assume the intent is to potentially add additional items here over time (even though we don't yet know what they might be.)

'OptionalCapabilities' sounds good to me. yes, definition it is meant to be later on more optional software capabilities to use

We can do that @naiming-zededa . Just that controller/UI need new code to process that new message. I am fine with whatever the decision is.

it should be similar for controller/UI to check either something called 'apicapacity' or the 'optionalcapability' items, not much difference in this regard.

I know. But apicapability code already exists in controller/UI hence adding additional capability does not require code changes at controller side.  With this new message optional capabilities some change is required in controller.
But that is fine, I will amend this commit.

Amended the commit

This is OK although I still think that it might be useful to publish Hypervisor enum as part of device info.
Then in the future we might be able to search for devices using hypervisor XYZ in the controller database etc. I don't know if we can rely on EVE image name for this.

This is OK, although I still think that it might be useful to publish Hypervisor enum as part of device info. Then in the future we might be able to search for devices using hypervisor XYZ in the controller database etc. I don't know if we can rely on EVE image name suffix for this.
Plus HVTypeKubevirt does not sound like capability, more like a property. Capabilities could be:

supports native containers
supports clustering
etc.

We are not picking by eve image name. Its actually eve hypervisor type which we generate during build and save in /etc/eve-hv-type file.  Kubevirt type of virtualization is also a capability of this device. But I do see your point that we are overriding a lot on just one virtualization type. Ideally we should have hierarchy under Kubevirt type, may instead of bool it should be a map. We should think about it.


Sycamore router not cleaning up when navigating

Describe the bug
When navigating using sycamore-router to a new page, the reactive scope (ScopeRef) of the previous page is not cleaned up. This results in a memory leak.
Expected behavior
Previous contexts once no longer needed should be automatically cleaned up.

I forgot that the view function is actually only called once with a reactive signal. There is therefore no issue.


[Python] How to add one level of nesting to flat table?

Describe the usage question you have. Please include as many useful details as  possible.
I have flat pa.Table:
table = pa.table({"a": [1, 2, 3], "b": [3, 4, 5]})

How can I create new table from this one by adding one level of nesting?
So I want to have a new table with  only one column "c" of type struct with two fields "a" and "b" and keep data from original table.
Component(s)
Python

If you can work with record batches I would suggest using to_struct_array() method:
import pyarrow as pa
batch = pa.RecordBatch.from_pydict({"a": [1, 2, 3], "b": [3, 4, 5]})
struct_array = batch.to_struct_array()
batch_result = pa.RecordBatch.from_arrays([struct_array], names=["c"])
# pyarrow.RecordBatch
# c: struct<a: int64, b: int64>
#   child 0, a: int64
#   child 1, b: int64
# ----
# c: -- is_valid: all not null
# -- child 0 type: int64
# [1,2,3]
# -- child 1 type: int64
# [3,4,5]

If you need to work with tables then you can do the same for each individual chunk:

If you can work with record batches I would suggest using to_struct_array() method:
import pyarrow as pa
batch = pa.RecordBatch.from_pydict({"a": [1, 2, 3], "b": [3, 4, 5]})
struct_array = batch.to_struct_array()
batch_result = pa.RecordBatch.from_arrays([struct_array], names=["c"])
# pyarrow.RecordBatch
# c: struct<a: int64, b: int64>
#   child 0, a: int64
#   child 1, b: int64
# ----
# c: -- is_valid: all not null
# -- child 0 type: int64
# [1,2,3]
# -- child 1 type: int64
# [3,4,5]

If you need to work with tables then you can do the same for each individual chunk:
# I think this should work
table = pa.table({"a": [1, 2, 3], "b": [3, 4, 5]})
batches = []
for b in table.to_batches():
    batches.append(pa.RecordBatch.from_arrays([b.to_struct_array()], names=["c"]))
table_result = pa.Table.from_batches(batches)
# pyarrow.Table
# c: struct<a: int64, b: int64>
#   child 0, a: int64
#   child 1, b: int64
# ----
# c: [
#   -- is_valid: all not null
#   -- child 0 type: int64
# [1,2,3]
#   -- child 1 type: int64
# [3,4,5]]

Thanks a lot @AlenkaF !
Am I right such transformations Table <-> Batches cost close to zero according:
https://arrow.apache.org/docs/cpp/tables.html#record-batches
?
"However, a table can be converted to and built from a sequence of record batches easily without needing to copy the underlying array buffers. A table can be streamed as an arbitrary number of record batches using a arrow::TableBatchReader. Conversely, a logical sequence of record batches can be assembled to form a table using one of the arrow::Table::FromRecordBatches() factory function overloads."

Table to/from RecordBatches transformations are zero-copy.

We might want to add to_struct_array to Table as well? (returning a ChunkedArray of struct type) To make this a bit more convenient in case of a table.

Oh, forgot the issue already exists with an open PR! :)https://github.com/apache/arrow/pull/38520


chore: use errors.New to replace fmt.Errorf with no parameters

Important note to contributors: We deeply value your contributions. However, due to a large influx of airdrop hunters, we are currently unable to accept small lint changes from first-time contributors. We encourage you to look for issues that offer more substantial contributions to the project or issues from the good first issue label. This helps us maintain the quality and integrity of the codebase, and provides a more meaningful experience for you as a contributor.


fix(locale): Improve German translation

🔗 Linked issue

❓ Type of change

[ ] 📖 Documentation (updates to the documentation or readme)
[x] 🐞 Bug fix (a non-breaking change that fixes an issue)
[ ] 👌 Enhancement (improving an existing functionality)
[ ] ✨ New feature (a non-breaking change that adds functionality)
[ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

The previous translation was grammatically incorrect and sounded weird in my opinion.
📝 Checklist

[ ] I have linked an issue or discussion.
[ ] I have updated the documentation accordingly.

Thanks! 😊 This makes sense as it was made with LLM.


Adding Multimodal Abilities to Crew

This PR:

Adds a series of new test to cover overall tools features
Fix bugs around tools being overwritten by combination of factors (agent tools vs task tools vs code execution vs allow delegation)
Adds the ability to multimodal agents

Disclaimer: This review was made by a crew of AI Agents.
Code Review Comment for CrewAI PR #1805
Overview
This pull request introduces significant enhancements to the CrewAI framework, specifically focusing on the handling of delegation tools, multimodal capabilities, and general code organization improvements. This review highlights key changes, suggests actionable improvements, and emphasizes historical context and implications.
Key Changes

Agent Class Enhancements

Addition of multimodal flag in the Agent class.
New support for multimodal tools through the method get_multimodal_tools().
Improved handling for code execution tools.

Core Changes to CrewAI

Refactored logic for tool preparation and delegation.
Better support for multimodal agents and tools.
Enhanced inheritance and override behavior for tools.

Detailed Analysis & Recommendations
1. Tool Management Refactoring
Current Implementation Example:
def _prepare_tools(self, agent: BaseAgent, task: Task, tools: List[Tool]):

Recommended Improvement:

Introduce a structured approach for preparing tools, enhancing maintainability.

def _prepare_tools(self, agent: BaseAgent, task: Task, tools: List[Tool]) -> List[Tool]:
    ...

Documentation: Add docstrings to clarify arguments and return types, improving readability.

2. Multimodal Support Implementation
Current Implementation Example:
def get_multimodal_tools(self):

Recommended Improvement:

Ensure that the method returns a list of multimodal tools clearly indicated with type hints.

def get_multimodal_tools(self) -> List[Tool]:
    ...

Consider expanding this for future multimodal tools and providing documentation.

3. Tool Response Handling
Current Implementation Example:
if formatted_answer.tool == "Add image to content":

Recommended Improvement:

Streamlined handling of tool responses by creating dedicated methods to check tool types and manage responses.

def _handle_tool_result(self, formatted_answer, tool_result):
    ...

General Recommendations

Type Hints: Ensure type hints are added for all new methods to promote clarity and support for IDE features.
Error Handling: Implement more robust error handling mechanisms to ensure fault tolerance.

def _execute_tool_and_check_finality(self, formatted_answer):
    ...

Testing: Further develop tests to cover edge cases, focusing on multimodal interactions and tool delegation scenarios.

Historical Context
This PR marks a notable evolution in the functionality of agents within CrewAI. Past PRs have laid the groundwork for delegation strategies and modular tool usage, making these enhancements timely and necessary. Existing related PRs should be reviewed to ensure no overlapping functionalities exist, and to leverage prior learnings.
Implications for Related Files

Agent Class: The changes in the Agent class will require updates across any other components that interact with agents, particularly in scenarios where multimodal capabilities are integrated.
Tool Management Logic: The refactoring of tool management could introduce different tool behavior if not adequately tested against legacy behavior.

Conclusion
PR #1805 represents a meaningful improvement in the CrewAI framework by enhancing delegation and multimodal support. While the modifications are largely beneficial, the suggested recommendations focus on improving code clarity, maintainability, and system robustness, ensuring a solid foundation for future enhancements. Implementing the proposed changes will not only improve code quality but will also set a precedent for adopting best practices within the codebase moving forward.
Overall, the changes will significantly increase the functional capacity of CrewAI agents, but attention must be given to the suggestions regarding documentation, type safety, and testing to secure long-term maintainability and effectiveness.


Publish / Provision management should be part of the Publish Experience in Composer

Is your feature request related to a problem? Please describe.
Today the Publishing and Provisioning experience is spread between the Publish and the Bot Settings pages in Composer.  This should be unified under the Publish location.
Describe the solution you'd like
Move the Publish and Provision Experiences to a new experience that should reside under the Publish location.  This solution should allow for bot selection as part of the actions vs requiring the selection ahead of kicking off the process.  We should change the view of Publish and Provision to be aligned to the bot project and not each individual bot.
Additional context
This may require an iteration in R13 and then another in later implementations to fully rework this experience.
First stage of this should be getting the experiences into the right location and then we can rework the Publishing and Provisioning Experience all up.  This request is just for the unifying of the experiences in R13.

I think this was essentially completed when Ben moved the list of publish targets to the publish page.


Remove command-line options that describe the build layout

The -b and -c command-line options are effectively used to describe a non-standard build layout to Gradle. This is problematic because it means that a specific combination of options must be used whenever Gradle is used on that build, for example whenever invoked from the IDE, CI, command-line or some other tool. These command-line options also have some potentially surprising behaviours, such as running a settings script present in the target directory.
We don't think there are any use cases that are strong enough to justify keeping these options, and we should remove them (via deprecation). If we discover there are some use cases, we might consider replacing the options with more self-describing contracts, for example conventions for build script names.
Expected Behavior
It is not possible to structure a build in such a way that it requires special command-line options in order to be used.
Current Behavior
It is possible to structure a build in such a way that special command-line options are required to use that build.
Context

Related: https://github.com/gradle/gradle/issues/14756

Do we want to also deprecate setting a custom build file location via GradleBuild task?
https://github.com/gradle/gradle/blob/eee7487396c2e6c27747b8ee85c9c42ff478cb92/subprojects/core/src/main/java/org/gradle/api/tasks/GradleBuild.java#L103-L120

Related https://github.com/gradle/gradle/issues/3828

I can describe a use case. The Nebula release plugin is opinionated (that's their own assessment, not mine, see https://github.com/nebula-plugins/nebula-release-plugin/issues/182). It does not have any support for excluding modules. We have a multi-module repo that is a combination of libraries that we want to publish, and services that we don't want to publish. Without excludes, our current solution is to modify the Gradle configuration with a script in our Jenkins sign/publish pipeline. But security and compliance regard any monkeying around with configuration as no better than monkeying around with code--they want to be able to say, forensically, what you see in this git repo is what went to production. So we were investigating using Gradle command-line options to tell the sign/publish pipeline "use this other Gradle configuration that does not include the services' modules". Because the alternative Gradle configuration would be checked in, it's not a security/compliance issue--it's in github, and is used unchanged. Is there some other way in Gradle to have a multi-module repo that builds and tests all modules but only signs and publishes a subset of those modules, and all without modifying any files in the pipeline? If so, we'll use that instead of trying to use command-line options.

@jimshowalter If the only difference between your two settings files are the list of modules, another way to do this would be to conditionally include the subprojects based on a property:
In settings.gradle:
if (!hasProperty("publishing")) {
    include("a", "b", "c")
}

include("x", "y", "z")

And then invoke the build with gradle -Ppublishing ... which would exclude subprojects a, b, and c.
I'm not super familiar with the release plugin, but you might also be able to push this down into the configuration of the plugin by selectively disabling the tasks for subprojects that should not be published.
How do you deal with project dependencies on the "service" projects if you're removing them from the build when publishing?

Thanks! Ironically it turns out we have a big repo that uses conditionals in settings.gradle. It never occurred to me to try that, which in retrospect is silly (it's all just code).
With that solution, there's no need for the command-line options.


Building rest client to kyuubi instance including original host urls

Why are the changes needed?

Usually, the host url to create a batch is the load balancer uri.
To reduce the internal rest redirection when fetching log, we support to call the kyuubi instance that created the batch directly.
It is better to add original host urls when building the rest client to kyuubi instance, in case that there is firewall to the kyuubi instance directly.
How was this patch tested?

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

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

cc @pan3793

Codecov Report

Merging #4657 (689ff8f) into master (0fdf145) will increase coverage by 3.98%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #4657      +/-   ##
============================================
+ Coverage     53.61%   57.59%   +3.98%
  Complexity       13       13
============================================
  Files           579      579
  Lines         31810    31962     +152
  Branches       4253     4269      +16
============================================
+ Hits          17054    18410    +1356
+ Misses        13171    11790    -1381
- Partials       1585     1762     +177

Impacted Files
Coverage Δ

...cala/org/apache/kyuubi/ctl/RestClientFactory.scala
93.44% <100.00%> (+0.10%)
:arrow_up:

...ava/org/apache/kyuubi/client/KyuubiRestClient.java
86.40% <100.00%> (-1.83%)
:arrow_down:

... and 53 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

thanks, merging to master


Gazebo Garden and ROS Humble

Requirements:

Ubuntu 22.04
ROS Humble (Installation instructions). I installed  ros-humble-desktop from debs.
ROS Garden (Installation instructions). I installed from source, as Garden hasn't been released yet.

How to test it?

Compile VRX following the updated instructions.
Launch the simulation following the updated instructions.

You should see the usual Sydney Regatta with the WAM-V.
Big thanks to @srmainwaring for helping with the port.

e4901ee

Updated in e4901ee

there is a ros_ign reference here. Change to ros_gz? Not sure if it matters.
This works for me. I was able to build and run this with Garden + Humble on 22.04 in docker.

Updated in e4901ee.


[5.9][Test] Force unicode_filename JSON verification to use UTF-8

On older Linux CI machines the JSON file being validated was opened as ASCII, leading to encoding errors. Force the validation to use UTF-8 to fix this test.
Scope: Testing on Ubuntu 18.04 and CentOS 7.
Risk: Very low, it's a test change.
Reviewed by @artemcm and @drodriguez
Cherry-pick of #67359

@swift-ci Please test


[cxx-interop] Fix incorrect diagnostic for non-imported functions

If a C++ function cannot be imported into Swift, we try to emit a diagnostic that explains why. This diagnostic wasn't always correct: for functions that return a C++ struct, we emitted a note saying "function uses foreign reference type in a return type which breaks 'swift_shared_reference' contract" even if the return type is a trivial struct without any attributes. This was emitted unless there was another diagnostic that we also provided for the same function.

I don't know a good way to test this, because ideally we should always have an explanation why something is not imported.

@swift-ci please smoke test


Rename the System Service app to Maestral from Sam Schott

Is your feature request related to a problem? Please describe.
In System Settings/General/Login Items/Allow in the Background the name of the launch deamon is Sam Schott, which is kinda weird, I didn't know what's that at first.
Describe the solution you'd like
I'd like it renamed to Maestral.
Additional context

Could you try to uncheck 'Start at login' and re-check it in Maestral's settings? I think this should be fixed for newly registered startup items.

Yep, it's fixed now, thank you!


Update set-up-topic-experiences.md

Added Groups admin to required AAD roles

@ruthholls
PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

Change made in the source and live on the page: https://learn.microsoft.com/en-us/microsoft-365/topics/set-up-topic-experiences?view=o365-worldwide


Cloud Native Chapter 3

Summary
Chapter 3 files. Images are in ch1 PR.

@ardalis please check the remainder of my edits. It should be good to merge.


An unknown error occured

When I click on any of the tabs: historic, send, balance, inflation and accept assets the following error occurs:
An unexpected error happened. If you want to help this error get fixed, please report it to the GitHub issue tracker. DO NOT SHARE YOUR PRIVATE KEY WITH ANYONE (begins with an S).
Your funds are safe and not affected by this error. This error is just a display error in StellarTerm.
TypeError: Cannot read property 'split' of undefined
at n.niceDate (https://stellarterm.com/:23:945039)
at https://stellarterm.com/:23:696506
at Array.map ()
at t.value (https://stellarterm.com/:23:696367)
at a (https://stellarterm.com/:23:400627)
at beginWork (https://stellarterm.com/:23:402335)
at r (https://stellarterm.com/:23:414456)
at s (https://stellarterm.com/:23:414777)
at i (https://stellarterm.com/:23:415015)
at E (https://stellarterm.com/:23:418555)
at w (https://stellarterm.com/:23:418292)
at h (https://stellarterm.com/:23:417421)
at p (https://stellarterm.com/:23:416811)
at Object.enqueueSetState (https://stellarterm.com/:23:391412)
at t.d.setState (https://stellarterm.com/:23:532272)
at https://stellarterm.com/:23:596044
in t
in div
in div
in div
in t
in t
in div
in t
in div
in t

Public key: GD6ZED54G3J2EROBZMU63U6E4FSOHWHK325RIZAPLTDWTHIKWTLWRLFS

Can you give me the error output on the new version of StellarTerm? And also steps on how to recreate this. Thanks


Minor updates for academic applications (Compatibility with Pandoc and Papers)

GitHub Markdown is used for academic applications. Here I have tried to fix two bothering issues:

Pandoc front-matters typically end with '...' rather than the standard '---'. I have added this to the specification.

See in-line comments.

Papers citation software generates Pandoc citation keys in [@Author:year] format. Standard GFM does not recognize ':' as a character that can be used in a Markdown mention. The reason why Papers turned to ':' delimited citekeys is an interesting read on its own. I have added support for this type of citekey so that syntax highlighting works correctly for Papers citekeys in Atom.

See in-line comments.

Looks like the tests are failing, mind updating them?

Hopefully this fixes the issue. What flavour of Regex does the CSON processor use?

What flavour of Regex does the CSON processor use?

Oniguruma

Thanks! :ship:


feat(trace): host-controlled tracing

Currently, the tracing collector in the Allwinner D1 platform impl is
hardcoded to the DEBUG level. This is unfortunate, as it means that we
will always do the work of collecting and formatting DEBUG traces, even
when no one is listening on the UART tracing port. It would be more
efficient if we only formatted traces when a crowtty instance has
subscribed to the UART tracing port. Additionally, because trace
metadata is sent when the callsite is initially registered, a crowtty
instance that attaches after the board has started running may miss some
trace metadata. Finally, there is no way to change the trace level on
the fly, as it's hard-coded in the kernel.
This branch changes the mnemos-trace-proto wire protocol to include a
host to target message to select a tracing level. Now, the board can
start up with all tracing disabled, and crowtty can send the desired
tracing level once it connects. This way, we don't collect or format
traces at all when crowtty isn't connected. In order to ensure
crowtty waits to send the tracing level message only once the board's
tracing code has been initialized, we add a periodic "heartbeat" message
sent by the board on the tracing port while tracing is idle. This is
used by the host which is listening for traces to detect the presence of
the tracing collector on the debug target. The same message is used to
ack a successful request to select the tracing level.
When the tracing level is selected, the target rebuilds tracing's
callsite cache, which means all metadata for callsites which have
previously been hit will be sent to the host. This ensures that
crowtty always has the metadata for all tracing spans and events that
are enabled, even if the target encountered them before crowtty
connected.
Making this work required fixing an upstream tracing bug,
https://github.com/tokio-rs/tracing/pull/2634, where calling into code
that includes tracing diagnostics from inside a
Collect::register_callsite method would cause a deadlock.
Additionally, I had to add code to the collector for tracking whether
it's inside its own send method, in order to temporarily disable bbq
tracing. This is because the collector's use of bbq creates an
infinite loop when the TRACE level is enabled.
Check this out:

In a subsequent branch, I intend to also add a host -> target heartbeat, so that the target can detect when crowtty has disconnected, and turn tracing off again.


Invalid device info

Logger: homeassistant.components.sensor
Source: helpers/entity_platform.py:624
Integration: Sensor (documentation, issues)
First occurred: 09:58:48 (1 occurrences)
Last logged: 09:58:48

Ignoring invalid device info: Invalid device info {'configuration_url': 'https://web.drivvo.com/', 'default_manufacturer': 'Drivvo', 'default_model': 'Ford/C-Max', 'entry_type': <DeviceEntryType.SERVICE: 'service'>, 'identifiers': {('drivvo', '978231')}, 'name': 'Ford'} for 'drivvo' config entry: device info needs to either describe a device, link to existing device or provide extra information.

Fixed with v1.0.9.


[Bug] Repairing players causes a disconnect

When you attempt to repair a player, that player disconnects. Any player singularly disconnected when this happens (meaning all other players remain connected and the server does not crash/roll back) will reconnect at their spawn point.
In rare cases, the entire server appears to crash, and all players are immediately disconnected. It happens in such a way that ServerCharacters by smoothbrain does not seem to be able to activate it's emergency save. Any disconnected players are reverted to their most recent save, as is the server map.

Repairing players should be now blocked.


Fix/issue 1151 pool chart fill color

Fixes #1151.

could't find any example older than 1/2 days

Yeah, not too much data, I was checking the volume on this asset:  did:op:4d2f05f8314049d3f105946feff33e0bb99763c21e5ceebca56e24f959250a83


fix encoding adding extra nulls at the end of some tokens

StandardCharsets.UTF_8.encode().array() returns the underlying bytebuffer that might have extra capacity at the end of the buffer. This results the returned array having extra nulls that were not intended to be encoded. See the added test case.
(https://stackoverflow.com/questions/42912994/null-characters-added-when-a-string-is-encoded-into-utf-8-bytes)

Thanks for great PR.


Remove implicit conversions from {File,Dir}BrowserFormAction

This is a small step towards #2326.

coverage: 61.096% (+0.07%) from 61.029%
when pulling c6629996ea69f75f3537c479d112f9f07da187fb on feature/2326-remove-implicit-conversions-from-file-dir-browser
into d0306662f210bc38ebc8ecf1d701dad291a4bc06 on feature/2326-filepath.

It looks like Coveralls had an issue, explained here: https://github.com/coverallsapp/github-action/issues/224#issuecomment-2389467014
Rerunning the failed jobs seems to work now/


InstallWindowsDefenderApplicationGuard

Can someone please inform the correct Custom CSP for InstallWindowsDefenderApplicationGuard??
Install or Uninstall as Strings it does not work.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 6a60ddc1-46b6-0e0e-c51c-4d8daf13b8a3
Version Independent ID: 76543649-84f0-c371-3a8d-4f8d87c7d859
Content: WindowsDefenderApplicationGuard CSP
Content Source: windows/client-management/mdm/windowsdefenderapplicationguard-csp.md
Product: w10
Technology: windows
GitHub Login: @ManikaDhiman
Microsoft Alias: v-madhi

@officedocsbot assign @e0i

@schenardie click settings --windows security-apps and browser control -- install windows defender application guard.
i dont know about CSP . but above solution might help to you
I think this options will be available in enterprise

Thanks for the help @RAJU2529 but that woks well for a handful of devices, i need to deploy more than 200 so its kind of a lot of work to do it manually.

@schenardie . Try this method.  Mount the  windows  baseimage  say like   windows 10 1903  install.wim
to a  another  directory .
mount the  image   install.wim with index to  directory add language packs  ,
add device drivers  .inf   only
add  windows update packs  like  clu and  ssu  in .msu  or  cab  files
set  required  edition
install product key
add  registry keys  by  loading registry hives
then use  dism online  command  enable the windows defender application guard features.
reset the system components
make  default language
then unmount the  image
export the  image to reduce and  optimize
AT last  take  modified windows 10 image say    masterimageinstall.wim  and  apply the image  by using
boot  the computer with  windows 10 PE 1903  cd , apply the image to  desired computer. boot the computer  with audit mode ,  recheck all required  features  are  enabled , do some changes as you like .
after finished , do  sysperp  generalize image , shutdown the computer.
boot  the computer with  windows 10 PE  , recapture the  image say  install1903.wim   and save it to the   64GB pendrive .
again boot  the computer with  windows 10 PE 1903  cd , apply the image to  desired computers.

Hi @RAJU2529 i dont have an image. All these devices are Azure AD only. There is no OSD, no image and no USB deployment happening.
Given the CSP is documented it should work. Sorry but i dont need alternate methods, only need to know how i can get the documented CSP working.
Thanks

@schenardie,I  am sorry  . I dont use azure service.
let wait for days,  azure users might help with CSP  methods

@schenardie Thank you for reaching out and helping improve MS Docs. Please have a look at this link and let me know if it answers your question regarding custom CSP - https://docs.microsoft.com/intune/endpoint-protection-windows-10.

Hi @lindspea, i'm completely aware there is a method of deploying the same setting via endpoint-protection. I currently need to use the CSP to deploy the setting manually as documented. The only problem is it doesn't work following the recommendations above. The simple fact the endpoint protection profile works and these profiles are based on CSPs makes me believe there is just something wrong with this specific setting and there has to be a way to make it work via CSP. So this currently doesn't answer my question. But thanks for the effort.

Hello, @schenardie  thank you for providing feedback.
The issues section of this repository is intended for product documentation issues only.
Please consider opening a product support ticket by the following link below for your problem so that it gets resolved quickly.
Windows 10 Support
Thank you.

@officedocsbot close


Package pyautogui miss the function screenshot() in the intellisense

We can see that intellisense didn't give the screenshot() method in the lise while we can run it correctly.
Thank you for any help.

Is there any update？

I believe this is by design. Screenshot is not a member of pyautogui, but rather something it imports from pyscreeze. Pyright (the typechecker pylance uses) does not consider screenshot a part of pyautogui because it's just a side effect of importing.
For more information see this issue (similar situation):
https://github.com/microsoft/pylance-release/issues/3320


make mlflow plugin work with python 3.11

TL;DR
Remove upper python constraint on flytekit-mlflow to allow for installation on 3.11, in line with other plugins.
Type

[ ] Bug Fix
[x] Feature
[ ] Plugin

Are all requirements met?

[x] Code completed
[x] Smoke tested
[x] Unit tests added
[x] Code documentation added
[x] Any pending items have an associated Issue

Complete description
NA
Tracking Issue
NA
Follow-up issue
NA

Hi Team,
This is my first PR 🙌, hopefully more to follow. We are trying to use the plugin with python 3.11, but it is restricted. Is there any reason why that was the case? I couldn't find any.

thanks @bcvanmeurs and congrats on your first contribution to flytekit!


Request: make this project a dictionary

Rationale:
Programming is full of abbreviations, and for non-native English speakers or beginners in programming, there is rarely a complete dictionary on the Internet for them to understand common abbreviations.
This project has the potential and foundation to be a dictionary, we just need to make more of it.
Suggestions:

First: We shouldn't be limited to abbreviations, acronyms should be covered as well.

Second: There is already a list of acronyms on Wikipedia, and if the #45 license issue is resolved, we can extend our project with existing words on Wikipedia.

Third: Make the whole project a wiki project that everyone can contribute to, because the language is from the people, by the people, for the people.

This issue is a fork of a previous thread (#41), you may be interested in reading the previous discussion history.

There is already a list of acronyms on Wikipedia

Could you link that Wikipedia page to see many new entries would adding acronyms mean?

Make the whole project a wiki project that everyone can contribute to [...]

Unlike Wikipedia, this repo is opinion based to some extent. I'm afraid without a maintainer we will end up having inconsistent content.

Could you link that Wikipedia page to see many new entries would adding acronyms mean?

Sorry, I forgot to link, here is https://en.wikipedia.org/wiki/List_of_computing_and_IT_abbreviations

Unlike Wikipedia, this repo is opinion based to some extent. I'm afraid without a maintainer we will end up having inconsistent content.

You are right, the purpose of a wiki is to increase user engagement.
But I realize this may not be an accurate representation of whether an abbreviation is actually popular to a certain extent.
I noticed that there are many internet slang/acronym dictionaries on the internet, take this as an example, a db will have multiple different interpretations, where ranking is based on user votes.
I think this is very good, but I don't know how to implement it in github.
We need to achieve two things:
First: Increase user engagement, including making it easier to contribute new abbreviation or explanations of existing abbreviation.
Second: Display user votes for each abbreviation.
Remember the referral in http? It's a typo, but it has been accepted because of consensus.
A voting system can help generate consensus.

I noticed that there are many internet slang/acronym dictionaries on the internet, take this as an example, a db will have multiple different interpretations, where ranking is based on user votes.

The urban dictionary is not that such reliable source.

To be honest I haven't been thinking about this highly consensus based same system. I have a conventional open-source software developer background and I could imagine only the "open and issue or PR if you would like to contribute" approach.
The main problem I see with a voting system is that there is no filtering. Anyone can up vote anything regardless how deeply they have considered that vote. E.g. any novice developer can vote for something, and this vote will be worth the same as a senior developer's vote. So in the end end the ratio of beginners vs. seniors will determine the quality of the list.
The "open an issue/PR" approach helps to filter out the non serious ideas as we can make changes only if some evidence is shown about the proposed word is better than the current one.

Sorry, I forgot to link, here is https://en.wikipedia.org/wiki/List_of_computing_and_IT_abbreviations

Thank you! However I think we shouldn't integrate this list for various reasons:

Potential licensing issues of using content from Wikipedia
It'd be a duplicated content -> maintenance burden
There are much more acronyms than abbreviations (as I foresee at least). I'm afraid it'd be hard to find the  abbreviations among the many acronyms

I think it'd be better to link this Wikipedia page as "For the list of acronyms visit this Wikipeda page".

@T1xx1 @kisvegabor
How about that, we continue with the current model, using issue templates to let people submit abbrs, because issue templates can be voted on, because there are emojis.
The change that was made is that each abbr is connected to an issue so people can see the history of previous discussions and vote on them.
an example:

standard input output • 🟢 stdio

The urban dictionary is not that such reliable source.

Agreed with this, but I like their voting system.

However I think we shouldn't integrate this list for various reasons:

As discussed earlier, I wanted this project to be a complete dictionary for newcomers and non-native English speakers so that they don't have to go to a second site to see other parts.
As to whether there would be a licensing issue with the Wikipedia word, if we rewrite then there shouldn't be a licensing issue.
You can see that there is nothing original in that Wikipedia list, just words.
So, if we add more content on a per-word basis, including context, explanation, then we are not considered plagiarized from Wikipedia.
They cannot claim copyright to an abbreviation like db.

The change that was made is that each abbr is connected to an issue so people can see the history of previous discussions and vote on them.

We will have ~200 issues but it's okay if it's consistent.

As to whether there would be a licensing issue with the Wikipedia word, if we rewrite then there shouldn't be a licensing issue.

It's great if it's not an issue. What about the other two concerns?

It'd be a duplicated content -> maintenance burden

There are much more acronyms than abbreviations (as I foresee at least). I'm afraid it'd be hard to find the abbreviations among the many acronyms

@T1xx1 @kisvegabor
How about this, we continue with the current method, using issue templates to let people submit abbrs, because issue templates can be voted on, because there are emojis.
The change that was made is that each abbr is connected to an issue so people can see the history of previous discussions and vote on them.
an example:

standard input output • 🟢 stdio

But don't use a PR unless fix a typo, as it will be hard to have a record of the discussion.

This method seems to messy and complicated. When I said to you that I didn't like the discussions way it was because I thought you wanted to move everything in the discussion section.
What about.
When someone suggest a new abbr it's made via issues with the templates. We discuss a little under it and when agreed we add the abbr, close the issue and in the same time we open a new discussion with the abbr in it, referring this discussion in the abbr in README like you shown. In this way we don't have 200 issue as @kisvegabor pointed out still having a place to discuss the abbr.

It'd be a duplicated content -> maintenance burden

There are much more acronyms than abbreviations (as I foresee at least).

Yes, that would be an endless list, but we need to make a rule to ensure that we only record common and well-known acronyms, such as db, http, this project aims to help those who are new to programming and non Native English speakers, so if we exclude words like db, they have to go to another site to find it.
Of course, it's not necessary to cover acronyms like HGDCFUDFS that most people don't know (which, by the way, doesn't exist, I just made it up myself). 🤣

I'm afraid it'd be hard to find the abbreviations among the many acronyms

Two things I recommended earlier can help improve:
The first is sorted alphabetically, one file per letter, we just need to link to correct files in the main readme file.
abbreviations-in-code
├─── readme.md
├─── en-US
|	├─── A.md
|	├─── B.md
|	├─── ...
|	└─── Z.md
├─── it-IT
|	├─── A.md
|	├─── ...
|	├─── Z.md
|	└─── readme.md
├─── raw
|	└─── raw
└─── docs

The second is to sort by abbreviations.
like:
db, database
db, debug

because I thought you wanted to move everything in the discussion section.

Sorry, my thoughts are constantly adjusted according to the actual situation. It changes every day, lol.

What about.
When someone suggest a new abbr it's made via issues with the templates. We discuss a little under it and when agreed we add the abbr, close the issue and in the same time we open a new discussion with the abbr in it, referring this discussion in the abbr in README like you shown. In this way we don't have 200 issue as @kisvegabor pointed out still having a place to discuss the abbr.
That's great, I hope this! and I like the idea. So open issues are just for new abbreviations, and closed issues are archives of old discussions.
Also, I don't think we have to open an issue for an old abbreviation that hasn't created a discussion yet, which would be a hassle, we can create a link to encourage others to create an issue discussion.

because I thought you wanted to move everything in the discussion section.

Sorry, my thoughts are constantly adjusted according to the actual situation. It changes every day, lol.

Don't worry. At the end it counts what we build.

What about.
When someone suggest a new abbr it's made via issues with the templates. We discuss a little under it and when agreed we add the abbr, close the issue and in the same time we open a new discussion with the abbr in it, referring this discussion in the abbr in README like you shown. In this way we don't have 200 issue as @kisvegabor pointed out still having a place to discuss the abbr.

That's great, I hope this! and I like the idea. So open issues are just for new abbreviations, and closed issues are archives of old discussions.

Yes. So this method will also not waste my templates HAHAH. I will still remove the "editAbbr.md" as we will use the discussions.
If it's not a problem for you I would like to do the "translateLang.md" template.

Also, I don't think we have to open an issue for an old abbreviation that hasn't created a discussion yet, which would be a hassle, we can create a link to encourage others to create an issue discussion.

Exactly.

abbreviations-in-code
├─── readme.md
├─── en-US
|	├─── A.md
|	├─── B.md
|	├─── ...
|	└─── Z.md
├─── it-IT
|	├─── A.md
|	├─── ...
|	├─── Z.md
|	└─── readme.md
├─── raw
|	└─── raw
└─── docs

It would not imply having 26 files for each lang. After making the db and the script for the en I want to request the it. The file will be 52 not counting the index, scripts and any type it's not a list. You will also need a separate file for the lang index.
If we use headers and paragraph we should be able to keep list sorted alphabetical without creating 34959 files. In each one we will format an index like in the curr README so is easy to navigate also on long lists.
Abbr in code

db

abbr.json
meta.json

scripts

builder (idk how to call this thing)

lang

en.md
it.md

readme.md

So we mantain abbrs.json and everything should be ok.
Also suggest to have package.json without having dependencies. Npm is useful for because you can exe script easily.

Yes. So this method will also not waste my templates HAHAH. I will still remove the "editAbbr.md" as we will use the discussions.
If it's not a problem for you I would like to do the "translateLang.md" template.

No problem, and I hope I can help too.
Also templates allow comments, which are not visible in the final issue, but are visible to people creating new issue, maybe we can introduce that functionality to explain the format to people.
And make the final issue look uniform in format.
I remember seeing this in a project before and I needed to find out how to do it because I forgot.

If we use headers and paragraph we should be able to keep list sorted alphabetical without creating 34959 files. In each one we will format an index like in the curr README so is easy to navigate also on long lists.

You are right.
Also, if we import that Wikipedia list, (I haven't counted), but it looks like there are at least 1,000 unique new acronyms.
How do we deal with it?

So we mantain abbrs.json and everything should be ok.
Also suggest to have package.json without having dependencies. Npm is useful for because you can exe script easily.

It does look easier to use. and I'm assuming English abbreviations + acronyms are no more than 5000 words in total, so perhaps putting them in one file would work.

It does look easier to use. and I'm assuming English abbreviations + acronyms are no more than 5000 words in total, so perhaps putting them in one file would work.

In any case we can change it after. Right now we need to test if works or not.

In any case we can change it after. Right now we need to test if works or not.

Yes! let's do it.

I am not sure whether this project is the same as that Wikipedia list ?

I am not sure whether this project is the same as that Wikipedia list ?

No, Wikipedia is just an acronym. We'll focus on being a dictionary, potentially larger than Wikipedia in the future, and that includes multiple languages, contexts of words, multiple formats, and even future IDEs may embed our dictionaries to suggest names as you type.
So, this is definitely not just another Wikipedia.

But why bring in all that stuff from that wikipedia entry?

... and even future IDEs may embed our dictionaries to suggest names as you type.

One of my projects was actually a vs code extension that could provide suggestion on words of their abbrs.
Apart the fact that I like this project that's also why I'm so active on this repo.

But why bring in all that stuff from that wikipedia entry?
e.g. ARPANET does not belong into this repo I think, and there are many many more of this kind

In my opinion we need to do these things:
Choose an organization name > formulate our goals > formulate our inclusion standards > formulate our format standards > improve the dictionary.
Importing to Wikipedia is just one possible move to improve the dictionary, but there are inclusion criteria there before then, so I'm not worried about some abbreviations being added that shouldn't exist in this project.
Before that, the goal still needs to be determined, because the dictionary is only a potential possibility, and further discussion is needed in the future.

BTW I could not implement these abbrs as there no remote method to retrieve them.

It is hoped that a format that can be generated for your expansion will be adopted after the database is complete.

BTW I could not implement these abbrs as there no remote method to retrieve them.

It is hoped that a format that can be generated for your expansion will be adopted after the database is complete.

Hope so. Maybe an other related project could be an API.

Let figure out what to do with the acronyms because I think some other things are depending on this decision.
My opinion is the we should not include the acronyms because:

there is no added value: RAM means Random Access Memory, it's a fact, you can find in google or Wikipedia what it means
it's a maintenance burden to constantly  update from Wikipedia
acronyms will greatly outnumber the abbreviations so what really has an added value will be harder to find
acronyms needs to be handled differently:

no translation  (doesn't make sense to translate Random Access Memory)
no linked issue (no discussion needed as it's a fact)
no level of recommendation (RAM mean Random Access Memory, it's always recommended)

Let figure out what to do with the acronyms because I think some other things are depending on this decision.
My opinion is the we should not include the acronyms because:

there is no added value: RAM means Random Access Memory, it's a fact, you can find in google or Wikipedia what it means
it's a maintenance burden to constantly  update from Wikipedia
acronyms will greatly outnumber the abbreviations so what really has an added value will be harder to find
acronyms needs to be handled differently:

no translation  (doesn't make sense to translate Random Access Memory)
no linked issue (no discussion needed as it's a fact)
no level of recommendation (RAM mean Random Access Memory, it's always recommended)

Another thing that comes to my mind is that acronyms are acronyms and abbrs are abbrs. I don't see the point of mixing them.

Let figure out what to do with the acronyms because I think some other things are depending on this decision.
My opinion is the we should not include the acronyms because:

there is no added value: RAM means Random Access Memory, it's a fact, you can find in google or Wikipedia what it means

it's a maintenance burden to constantly  update from Wikipedia

acronyms will greatly outnumber the abbreviations so what really has an added value will be harder to find

acronyms needs to be handled differently:

no translation  (doesn't make sense to translate Random Access Memory)
no linked issue (no discussion needed as it's a fact)
no level of recommendation (RAM mean Random Access Memory, it's always recommended)

Another thing that comes to my mind is that acronyms are acronyms and abbrs are abbrs. I don't see the point of mixing them.

Yes, maybe in two documents.

So maybe two docs would be good for them? Or start a separate project in that organization that works for acronyms?

I prefer this solution.

I prefer this solution.

Yes, we can have two different repositories under the same org, I like that, easy to find!
And it can be managed centrally, and the same collection rules and issue templates can be formulated to reduce the maintenance burden.

Yep, rules, formats, and goals are of the org among all projects. There will be also native project tasks and others but referred as development of the org itself.

Or start a separate project in that organization that works for acronyms?

If anything than this. I personally would not maintain this though. I am only interested in creating a clear reference for abbreviations that are used for variable naming

Or start a separate project in that organization that works for acronyms?

If anything than this. I personally would not maintain this though. I am only interested in creating a clear reference for abbreviations that are used for variable naming

So it will be better to have them separate so you have to mantain a repo without having to seek in the code if their are mixed for the abbrs only.

Then the org name can not include "abbr", if the org attempts to also list "acro" - which I thoroughly believe it should NOT.

Got it.

I see, why not join the organization? @philipeachille

how do i join the organization?

how do i join the organization?

@T1xx1 @kisvegabor
How to invite?

how do i join the organization?

@T1xx1 @kisvegabor
How to invite?

Wait

Sent

btw, i think "abbrcodes" is somewhat wrong, because code is not plural, the abbreviations are plural

It stands for "abbreviate codes"

btw, i think "abbrcodes" is somewhat wrong, because code is not plural, the abbreviations are plural

makes sense.
🤔 abbrscode? But in this case you need abbrsincode, or just abbre (that name is available) ?

"abbres" ? 🤔 ... i still prefer "abbrcode"

Can we open a new discussion about names?
@T1xx1  @philipeachille
There is no link to the discussion yet in brevis.

Want to discuss it?
Open a discussion here: https://github.com/abbrcodes/discussions/discussions

Can we open a new discussion about names?

There is 4