[BUG] Part2 - Documentation Improvements

Enabling Third Party Services
Current:- Appsmith ships with third party services that improve the app building experience. All third party services are entirely optional
Improvement:- Appsmith ships with third party services that improves the app building experience. All third party services are entirely optional.
Current:- All third party services are enabled by default in our cloud hosted version
Improvement:- All third party services are enabled by default in our cloud hosted version.
Current:- You may need root access to modify the docker.env file
Improvement:- You may need root access to modify the docker.env file.
Building The UI
Current:- Widget names are important when adding logic so name your widgets well!
Improvement:- Widget names are important while adding logic, so name your widgets well!
Current:- Widget properties can be editing via the property pane which can be toggled next to the delete icon. Widget properties can affect data, style and action to take.
Improvement:- Widget properties can be edited via the property pane which could be opened using top-right icon (name). Widget properties can affect the widget data, styling and actions.
Current:- Widget properties don't have to be static! Connect a widget property to an API by typing {{ }} inside the property and binding the property using an API name or Widget name. You can learn more about working with widgets and APIs here
Improvement:- Widget properties doesn't have to be static! To make it dynamic, type {{ }} inside the widget property and bind it to an API name or Widget name. You can learn more about working with widgets and APIs here

@visibleajay would you consider raising a pr for these fixes here
https://github.com/appsmithorg/appsmith-docs

I'll be taking it up for Hacktoberfest. Confirmed with @visibleajay


:bug: Add coreutils to initrd

Fixes https://github.com/kairos-io/kairos/issues/630

This is looking good, however we need also to bump the initrd packages so it propagates back to alpine


Compatibility issue between CONTEXT variable and parameter space CONSTRAINT

Hi there!
Python 3.8.8
Emukit 0.4.9
I've come across an issue when trying to get_next_points with a context variable for a constrained parameter space. My understanding is that the fact to use context variables passes an array of length n-x (for x context variable) to the constraint function. This function, which is expecting an array of length n, in turns causes it to bug.
Below is an exemple that will cause this issue (modifed from the "Emukit - Bayesian Optimization with Non-Linear Constraints" tutorial)
`FIG_SIZE = (12, 8)
from emukit.test_functions import branin_function
fcn, space = branin_function()
import numpy as np
constraint_radius = 4
constraint_fcn = lambda x: 10 * (-(x[0] - 3)**2 - (x[1] - 7)**2 + constraint_radius ** 2)
optimum = np.array([[-np.pi, 12.275], [np.pi, 2.275], [9.42478, 2.475]])
evaluate objective on grid to plot
x_1 = np.linspace(-5, 10, 50)
x_2 = np.linspace(0, 15, 51)
x_1_grid, x_2_grid = np.meshgrid(x_1, x_2)
x_all = np.stack([x_1_grid.flatten(), x_2_grid.flatten()], axis=1)
y_all = fcn(x_all)
y_reshape = np.reshape(y_all, x_1_grid.shape)
evaluate constraint to plot
theta_constraint = np.linspace(0, 2*np.pi)
x_0_constraint = 3 + np.sin(theta_constraint) * constraint_radius
x_1_constraint = 7 + np.cos(theta_constraint) * constraint_radius
import matplotlib.pyplot as plt
plt.figure(figsize=FIG_SIZE)
plt.contourf(x_1, x_2, y_reshape)
plt.title('Branin Function')
plt.plot(x_0_constraint, x_1_constraint, linewidth=3, color='k')
plt.plot(optimum[:, 0], optimum[:, 1], marker='x', color='r', linestyle='')
plt.legend(['Constraint boundary', 'Unconstrained optima']);
import GPy
from emukit.model_wrappers import GPyModelWrapper
x_init = np.array([[0, 7], [1, 9], [6, 8]])
y_init = fcn(x_init)
model = GPy.models.GPRegression(x_init, y_init)
emukit_model = GPyModelWrapper(model)
from emukit.core.acquisition import Acquisition
from emukit.core.constraints import NonlinearInequalityConstraint
from scipy.special import expit # expit is scipy's sigmoid function
constraints = [NonlinearInequalityConstraint(constraint_fcn, 0, np.inf)]
space.constraints = constraints
from emukit.bayesian_optimization.acquisitions import ExpectedImprovement
ei = ExpectedImprovement(model)
from emukit.bayesian_optimization.loops import BayesianOptimizationLoop
from emukit.core.optimization import GradientAcquisitionOptimizer
Create acquisition optimizer with constraints
acquisition_optimizer = GradientAcquisitionOptimizer(space)
Make BO loop
bo_loop = BayesianOptimizationLoop(space, emukit_model, ei, acquisition_optimizer=acquisition_optimizer)
append plot_progress function to iteration end event
bo_loop.get_next_points(results=None,context={'x2': 3})`
BTW: I love this package! Good work :-)

Hi @AlbanMor and thanks for a great bug report. I was able to easily reproduce it.
The core of the issue, as you correctly surmised, is that we apply context to the space, and do the constrained optimization over context free space: here. That puts a lot of implicit assumptions on the constraints about order and usage of variables.
To unblock yourself now you can design your constraints to refer to non-context variables only, and design your parameter space so that non-context variables always come before context ones.
But a proper fix isn't clear at all to me at the moment. Ideas welcome

Seems like we could just make the documentation more explicit about the assumptions made here? e.g. "we have a canonical ordering of variables in the parameter space" or whatever it shakes out to be.

To unblock yourself now you can design your constraints to refer to non-context variables only, and design your parameter space so that non-context variables always come before context ones.

Thank you for the quick reply. A more agile approach on my end might be to take into account the specified context variable in my constraint function. How would i go about to call the context variable in my function?

@AlbanMor that's the thing, context variables aren't available inside constraints at the moment. So the best you can do is to have a global variable that you refer to. In the example:
X2_VALUE = 3
...
constraint_fcn = lambda x: 10 * (-(x[0] - 3)**2 - (X2_VALUE - 7)**2 + constraint_radius ** 2)
...
bo_loop.get_next_points(results=None,context={'x2': X2_VALUE})`

Admittedly, that's far from ideal.

@ekalosak that is a possibility, but I'd rather explore ways to solve it first. We just need to find a good way of passing full variables in constraints instead of a context-free ones. It is probably not too hard, and I think can be done by context manager.


Cross-browser testing w/ Sauce Labs

Coverage remained the same at 88.7% when pulling 9e018a1518d7770219bac30bae131eb4c9db1961 on saucelabs into e67092ce8eb94948530dab6363ede2740a091f5f on master.


API Register Device Endpoint

Hey everyone,
as I have noticed there is a /device/register endpoint in your API.
It is also usable but not documented at all although it is very helpful. (https://github.com/balena-io/docs/blob/master/config/dictionaries/resource.json)
You can find proof for the endpoint at https://github.com/balena-io-modules/balena-register-device/blob/master/lib/register.ts ;)
Does it make sense to add it to the documentation or is there a reason that it is not documented?

Hey @Sebi55, that endpoint is invoked by a device on first boot as part the provisioning process. What is it you want to do? Documenting APIs increases the exposed API surface we must maintain and unless there is a reasonable use case for doing so, it's best we don't.

@dfunckt Sorry for the very late response.
I have created a post on the balena forum now to discuss this.
Actually I might or might not have a use case where is makes sense. Have a look: https://forums.balena.io/t/multi-tenant-but-only-one-application-support/338693
So in a scenario where I have to manage many devices in a B2C platform it would make sense to let the user create a device upfront before having the device booted with the image as this allows to let the customer switch plans on certain device limits. If I wait for the device to come up on balena I end up paying for that device but the user might not have might paid at my platform though.
Would be interested to get your feedback on this!


Rerun project

Create a new project and run it. Run it again, without closing the previous window.


Likelihood initialisation with source specific parameters

Right now the parameters in the likelihood init have to be common parameters to all the sources used (excluding the column source).
If we want to fit a full dataset with, say, ERSource and NRSource, the 2 of them will have source specific parameters besides the common parameters. Right now we don't support having source specific parameters and this should be a key feature that needs implementation.

Solved by #51


Assembly and Annotation pipeline: "/tmp" folder full issue with shovill

Note: Not able to find the repository for Assembly and Annotation pipeline. So, I am creating this issue here.
Even though we mention the location for the temp directory (--tmp-dir) for spades in "Shovill advanced options for spades" while running Assembly and Annotation Pipeline, we noticed that Spades is using  "/tmp" and it gets filled up very quickly (We have assigned about 20GB for "/tmp" in our set up).
Any tips on how to fix it?

to give more details:

spades receives the second parameters,  as defined by Jeevan, but completely ignores the second set of values, keeps the first ones it receives:
[spades] Command line<EMAIL_ADDRESS>--pe1-1 /opt/galaxy/21.09/database/jobs_directory/052/52207/working/out/flash.notCombined_1.fastq.gz --pe1-2	/opt/galaxy/21.09/database/jobs_directory/052/52207/working/out/flash.notCombined_2.fastq.gz --only-assembler --threads 1 --memory 4 -o /opt/galaxy/21.09/database/jobs_directory/052/52207/working/out/spades --tmp-dir /tmp -k 31,55,79,103,127 --pe1-m /opt/galaxy/21.09/database/jobs_directory/052/52207/working/out/flash.extendedFrags.fastq -- tmp-dir /opt/galaxy/tmp --threads 12 --memory 64
I am not sure who is responsible for appending the variables this way: is it the pipeline, when installed via irida or is it something the galaxy devs need to look at? or is it something we misconfigured?
for the record, the spades repo is here;
https://github.com/ablab/spades


Prepare Monitor Ingestion March 2024 Patch Release (Manual)

API change check
API changes are not detected in this pull request.


Improving readme

Your Readme.md file has many issues:

"To Do!" should have been in a different file, or handled through issues. If it is clear, then remove it in any case.
"THIS IS A WIP!!!": please, avoid all caps, and phrase this disclaimer in a more refined way.
"(crazy ik)": what does this mean?
"Code that you want to benchmark": I'm sure the specification is a bit more precise than that. Could you provide a template to help the user in getting started?
"Save your code.": what are you referring to?
"In your terminal, naviagte to the LQICM-Benchmark folder. (Use cd)": aren't we there already?
"Compile your code using clang in the terminal. I recommend using this line: clang-15 benchmark.c -O0 -o benchmark -lm.": Ok, but it compiles just fine with gcc as well. Why would clang be needed / recommended?
"Inserting Code": again, an example to get started would help. What is the protocole, here? Do I need 2 files, 1 file, particular methods, a main method, can I load libraries, etc.

The Readme.md had a lot of temporary additions to it while we were working on it a bunch. A part of the final revisions includes revising this so that it's as clear and easy to follow as possible.


NoNodeAvailableException starting collector (when connecting to Elasticsearch

Please answer these questions before submitting your issue.

Why do you submit this issue?
[ ] Question or discussion
[x ] Bug
[ ] Requirement
[ ] Feature or performance improvement

Question

What do you want to know?

Bug

Which version of SkyWalking, OS and JRE?
SkyWalking Alpha 5.0
Java 8
Elasticseach 6.2.4

Which company or project?

What happen?
I get the following in collector log and it does not start. i verified Elasticsearch transport responding on 9300
skywalking-collector-server.log

Requirement or improvement

Please describe about your requirements or improvement suggestions.

@RajKumarBalaiya You are not following out documents:  https://github.com/apache/incubator-skywalking/blob/master/docs/en/Deploy-backend-in-cluster-mode.md
ElasticSearch 5.x is required.


Unified diff when checking C++ code format and remove Slack notifications from Travis

Current coverage is 93.28% (diff: 100%)

Merging #234 into master will not change coverage

@@             master       #234   diff @@
==========================================
  Files            72         72
  Lines          4842       4842
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           4517       4517
  Misses          325        325
  Partials          0          0

Powered by Codecov. Last update 0420a4f...b5434a2


Add CLMBR to Piton

This is going to be a huge PR to add CLMBR to Piton, so we are going to review it in parts.
We will review it in 4 stages:

The CUDA kernels

The dictionary creation

The dataloader

The CLMBR model

Currently, we will start at stage 1 with the gather_scatter kernel.

Let's start by reviewing the gather_scatter kernel.
https://github.com/som-shahlab/piton/blob/jax/src/piton/jax.py#L43 is the core definition of the kernel and the Python fallback.
https://github.com/som-shahlab/piton/blob/jax/tests/test_jax.py#L25 contains the tests.
https://github.com/som-shahlab/piton/blob/jax/native/gather_scatter.cu is the actual kernel implementation.
Those files have a lot of other content, but please ignore everything not related to gather_scatter.

Shoot, accidentally messed up this branch. Will have to fix, wait a sec.


Calendar/Schedule not updating on long running HA instance

I find that if my HA is not restarted for a long period, the calendar/schedule eventually stops updating.
In the area/zone entity sensor.load_shedding_area_capetown_6_durbanville, I see the following attributes:
Forecast
- stage: 1
start_time: '2023-03-29T03:00:00+00:00'
end_time: '2023-03-29T04:30:00+00:00'

Last update
March 23, 2023 at 8:53:59 AM

I seem to be on version 1.3.0
See the difference between HA and ESP:
HA

ESP

Hmm...anything in the Logs?
What's the attributes for the stage and area sensors in Dev Tools?

Havent seen anything in the logs.
The stage sensor was up to date. the attributes for hte area is in the OP.

Hmm...I see...not updating the forecast, because the area schedule is not updating every day as it should.

Interesting that yours and mine both were last updated March 23, 2023 🤔

I've had the same issue before and had it again this week, this evening, I hit reload, and it sorted it out, and it loaded the latest schedules. It does feel like a month-end issue because I have tried that before to no avail.

Mine was doing the same thing with my area sensor, I see the last update was on 26 March, I hit reload under Devices and it's working again. The Eskom load shedding sensor kept updating correctly, though.

I suppose the workaround in the meantime is to set up an automation to reload the integration every 3-5 days

Same issue here.

yup here as well, thanks for the reload tip.

The issue might be fixed in https://github.com/wernerhp/ha.integration.load_shedding/releases/tag/v1.5.0-beta.2 . Need to test.


File size added in readable format in Resources -> Datasets

@ mention of reviewers
@Didayolo
A brief description of the purpose of the changes contained in this PR.
Now users can see file size in readable format in Resources -> Datasets

Issues this PR resolves
#713 -> Interfaces -> Point 1

Add the size of the files

Checklist

[x] Code review by me
[x] Hand tested by me
[x] I'm proud of my work
[x] Code review by reviewer
[x] Hand tested by reviewer
[x] CircleCi tests are passing
[x] Ready to merge

Thank you for the PR.
I think it breaks the buttons to navigate through pages in the resources interface (bottom right):

Nice work!

@Didayolo
When a submissions file is stored, the standard used for Kilobytes (KB) is 1024 and not 1000.
https://github.com/codalab/codabench/blob/develop/src/apps/datasets/models.py#L67
In the change I have made, I use 1000.
// loop over n until it is greater than 1000
while(n >= 1000 && ++i){
     n = n/1000;
 }

Should this be changed to 1024?

So I guess right now we showing MiB, GiB, etc. instead of MB or GB.
Yes, maybe it is better to change this to 1024.

I think KiB, MiB,  GiB are multiples of 1024 while KB, MB, GB are multiples of 1000.
my change is showing KB, MB, Gb.

OK then we can let it as it is, because the information provided is accurate.


New version (3.1.1) import error

New version (3.1.1) gets errors when importing:
Error: Cannot find module './lib/dash'

I think this is what caused the error:

Closed by #113


[Adaptive] [Docs] forEach function is not documented

We should get this documented and add to the pre-built functions list.

Also see this - 'forEach does not have a built-in expression evaluator.'
Is forEach not implemented yet? I thought it was.

'foreach' function is already there.

We need to add it to docs + include a sample usage snippet.


Mismatched Brackets

Ok this has been bugging me for a while but because @Catsarefluffy recently brought it up, I thought it might be a good time to bring this up.
Mismatched brackets do not necessarily cause Brain-Flak to error.  Here are three examples of mismatched brackets that do not cause an error, each for a different reason:
(()()) #I'm a mismatched bracket :)
(<><>){I'm a mismatched bracket :)}
(()){()}I'm a mismatched bracket :)

1, 2, 3
The first one is obviously not a problem; its just a comment doing its job, however the next two are iffy.  They are in portions of non-executed code, the first because it is skipped by a loop and the second because a infinite loop prevents the code from being run.
The reason this behavior exists is that balance checking is done during run time rather than compile time.  Currently a bracket can only be mismatched if it is run.  The solution to this "problem" would be to check for mismatched brackets before we begin running the program.

Is this a Problem?
In short, I'm not sure there is a pretty good case both ways.  I'll start with the case that these are bad, and I'll start this case with a quote from DJMcMayhem:

The whole point of the language is the matching bracket restriction.

Brain-flak is the language of balanced brackets, thats what its about.  We should stick to our values and enforce this restriction no matter what.
The next reason why it might be a good is error messages.  Currently our mismatched bracket error messages are rather useless.  Take this for example:
Where's the Mismatched bracket? ( <--- Is it that one?
>){}(<>[()]{})({({}()<(())>)})(({({}[])({}{})}<({})<(()({}))<>>(())>)<[]>
                              ^ No its that one

When run this will output the rather unhelpful:
Error at character 33: Unmatched '(' character.

Make no mistake the 33rd character is a perfectly closed (, however Brain-Flak really just means that the 33rd bracket is mismatched (I don't know why I wrote the error messages to say Unmatched that's not a word).  If Bracket matching was checked at compile time, this would be incredibly easy to check.  It is possible to check with the current system, but it would be rather difficult and inconvenient, and likely would cause some slow down in the system.  These messages really have to be fixed, and if the new system makes this easier thats a pro right?
Ok, tell me has this ever happened to you?

You just finished writing a massive Brain-Flak program, maybe your latest Mini-flak quine that takes hours to run, so you start it running so you can test it.  You get up, get a drink, come back and the program is running, so you open the review queue, you review a couple of low quality posts and the program is still running, so you get another drink, you come back and its still running, so you figure it would be a good time for a nap.  When you wake up from your nap the program has finally finished running. Like a kid on christmas morning you rush over to see if it worked.
Error at character 1516: Unmatched '<' character.

If enforced that all programs must be fully matched we could avoid this situation altogether.  A compile time check would tell you in an instant whether or not you are going to encounter a bracket mismatch.  Currently checking if a program is syntactically valid is equivalent to solving the halting problem and cannot be done at compile time. The only way to have a check at compile time is to make our check into something that can be computed.  Whether or not brackets are matched is computable.

Ok, here's why we might want to keep it the way it is.
It will take longer to run every program with a compile time check.  Our interpreter is already pretty bloated and slow, we should avoid any more overhead on programs.  Our current system is pretty smart for checking the bracket matches as it runs the program.  The current system might cause issues in a couple of places, but we would need to have this overhead every time we run a Brain-Flak program.
You can check yourself.  If you have a giant program or want to make sure that your program wont error before you start it off, you can just check if its balanced using a pretty simple script.  If you want you could even alias it to do so every time you run a Brain-Flak using a little bit of bash magic.  This way people running small programs don't have to bother with the overhead each time.
It would not be backwards compatible.  The behavior has been like this since the beginning of Brain-Flak, changing it would break at least one program I've written.  I'm usually against legacy decisions like this one, but I've put this in here because I know that it might make a difference to some people, and they are entitled to that opinion.
We are writing an esolang, its just a quirk of the language.  "practical" and "good practice" are not in our vocabulary.  It just adds a little bit of spice to Brain-Flak that can be used to interesting effect, particularly in polyglot challenges.

What we should not do
Ok, I've been pretty flimsy on everything about this so far, but here I am going to take a stand.  We should not add a new flag.  I feel like every time we discuss a new change this is brought up by someone (sometimes me).  We have a lot of flags right now, and we don't need another flag for something that might not even be noticeable.  We should make a hard decision and stick with it.
We should also not do nothing.  The two major problems mentioned in the first section should at least be attempted to be fixed.  Our error messages are really bad right now.  If we are not going to check balance before we run a program we should at least give people the option to do something when their program crashes several hours in.  This may be allowing users to see the data, or even modify their code after the error to fix the problem and then resume execution.

Not that this necessarily matters but currently CraneFlak (the C implementation of the Brain-Flak interpreter) does not allow mismatched braces of type 2, but does allow mismatched braces of type 1 and 3 (because it never checks to the end of the program before it finishes). BrainLack, the Brain-Flak compiler I'm working on, will not mismatched braces of types 2 or 3 since it needs to fully analyze the program beforehand.

Thanks for bringing this up! And +1 for We should not add a new flag, I wholeheartedly agree.
Here are my thoughts on the matter:
The current behavior isn't wrong. This might seem counterintuitive, but it's true. If (<><>){I'm a mismatched bracket :)} doesn't throw an error, this is not incorrect behavior. Similarly, if this program does throw an error, this isn't wrong either. This program can do anything because it's undefined behavior. To quote wikipedia:

In the standards for these languages, the semantics of certain operations is described as undefined. An implementation is allowed to assume that such operations never occur in standard-conforming program code; the implementation will be considered correct whatever it does in such cases

So if this is technically not invalid, the next question is what is most useful? IMO, we should check the brackets for validity and compile time for the ruby interpreter, and leave the runtime checking as is for more heavily optimized compilers such as crane-flak.
Let's address a few points:

It will take longer to run every program with a compile time check

This is true. This is definitely the biggest downside. However, I'm pretty sure the difference will be in milliseconds, and rarely make a significant difference. But FWIW, brain-flak isn't exactly the fastest of languages to begin with. I don't generally expect brain-flak to run blazingly fast. And generally most programs don't take very long anyway.
For large/slow programs, we'll just recommend using crane-flak instead. Since this one can continue to rely upon runtime checking, it'll run faster. It'll just take a little bit more thought to double check your program is indeed entirely balanced before assuming it's running correctly.

You can check yourself. If you have a giant program or want to make sure that your program wont error before you start it off, you can just check if its balanced using a pretty simple script. If you want you could even alias it to do so every time you run a Brain-Flak using a little bit of bash magic.

Yeah, but who wants to? The diehard flakheads might be willing to do this, but it'll be hard to convince everyone to add aliases or write balance checking scripts. Having an interpreter that will tell you when you're running an invalid program is much more user-friendly.

It would not be backwards compatible. The behavior has been like this since the beginning of Brain-Flak, changing it would break at least one program I've written.

Which program? I'd consider that program to be invalid to begin with, so I don't know if keeping that program around for backwards compatibility is worth it.

We are writing an esolang, its just a quirk of the language.

The language can be both impractical and convenient to use.

All of this is to say that I think compile time checking is a great idea. In terms of practically implementing this, I propose the following approach:
On program startup, do the following first:

Remove all comments (everything matching /#.*$/)

Remove all non-brackets (everything matching /[\[\]()<>{}]/). This includes newlines.

Verify that the resulting string is balanced. If it isn't, give an error and exit. Otherwise, run the program.

I have only one detail I'm not sure about. What should
aa((

output? Currently it outputs:
Error at character 1: Unmatched '(' character.

But an argument could be made for instead printing:
Error at character 3: Unmatched '(' character.

This same question applies to the debug output. For example,
aa(())

outputs:
 Cycles:
 3
 Program:
 (())
     ^
 Chararacter 5
 Stack:
 1
 ^

Maybe this should output
 Cycles:
 3
 Program:
 aa(())
       ^
 Chararacter 5
 Stack:
 1
 ^

Instead. Whichever one we pick, the two should be consistent.

...Was only asking because it would be easier to write programs. (Also, -d
should also print the third stack if this is implemented, because it could
be nonempty.)
On Mon, Jun 5, 2017 at 10:21 AM, DJMcMayhem<EMAIL_ADDRESS>wrote:

Thanks for bringing this up! And +1 for We should not add a new flag, I
wholeheartedly agree.
Here are my thoughts on the matter:
The current behavior isn't wrong. This might seem counterintuitive, but
it's true. If (<><>){I'm a mismatched bracket :)} doesn't throw an error,
this is not incorrect behavior. Similarly, if this program does throw
an error, this isn't wrong either. This program can do anything because
it's undefined behavior. To quote wikipedia:
https://en.wikipedia.org/wiki/Undefined_behavior
In the standards for these languages, the semantics of certain operations
is described as undefined. An implementation is allowed to assume that such
operations never occur in standard-conforming program code; the
implementation will be considered correct whatever it does in such cases
So if this is technically not invalid, the next question is what is most
useful? IMO, we should check the brackets for validity and compile time for
the ruby interpreter, and leave the runtime checking as is for more heavily
optimized compilers such as crane-flak.
Let's address a few points:
It will take longer to run every program with a compile time check
This is true. This is definitely the biggest downside. However, I'm pretty
sure the difference will be in milliseconds, and rarely make a significant
difference. But FWIW, brain-flak isn't exactly the fastest of languages to
begin with. I don't generally expect brain-flak to run blazingly fast. And
generally most programs don't take very long anyway.
For large/slow programs, we'll just recommend using crane-flak instead.
Since this one can continue to rely upon runtime checking, it'll run
faster. It'll just take a little bit more thought to double check your
program is indeed entirely balanced before assuming it's running correctly.
You can check yourself. If you have a giant program or want to make sure
that your program wont error before you start it off, you can just check if
its balanced using a pretty simple script. If you want you could even alias
it to do so every time you run a Brain-Flak using a little bit of bash
magic.
Yeah, but who wants to? The diehard flakheads might be willing to do this,
but it'll be hard to convince everyone to add aliases or write balance
checking scripts. Having an interpreter that will tell you when you're
running an invalid program is much more user-friendly.
It would not be backwards compatible. The behavior has been like this
since the beginning of Brain-Flak, changing it would break at least one
program I've written.
Which program? I'd consider that program to be invalid to begin with, so I
don't know if keeping that program around for backwards compatibility is
worth it.
We are writing an esolang, its just a quirk of the language.
The language can be both impractical and convenient to use.
All of this is to say that I think compile time checking is a great idea.
In terms of practically implementing this, I propose the following approach:
On program startup, do the following first:

Remove all comments (everything matching /#.*$/)
2.
Remove all non-brackets (everything matching /[[]()<>{}]/). This
includes newlines.
3.
Verify that the resulting string is balanced. If it isn't, give an
error and exit. Otherwise, run the program.
I have only one detail I'm not sure about. What should
aa((
output? Currently it outputs:
Error at character 1: Unmatched '(' character.
But an argument could be made for instead printing:
Error at character 3: Unmatched '(' character.
This same question applies to the debug output. For example,
aa(())
outputs:
Cycles:
3
Program:
(())
^
Chararacter 5
Stack:
1
^
Maybe this should output
Cycles:
3
Program:
aa(())
^
Chararacter 5
Stack:
1
^
Instead. Whichever one we pick, the two should be consistent.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/DJMcMayhem/Brain-Flak/issues/75#issuecomment-306249274,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARIzhsdUWBS7XQwRpFC79jwJ3VwhYDmeks5sBDkrgaJpZM4NvomA
.

Ok it seems we are in agreement.  I will implement compile time balance checking, and revamp the error messages.


[REQUEST] pynvml package seems to be deprecated in favor of nvidia-ml-py

Is your feature request related to a problem? Please describe.
Managing package dependencies is complicated by deepspeed having a requirement of pynvml instead of nvidia-ml-py.
It seems that pynvml has been folded back into the nvidia-ml-py project, as both seem to have nearly identical pypi pages, but nvidia-ml-py has been updated recently while pynvml has been dormant for a year.
https://pypi.org/project/pynvml/#history
https://pypi.org/project/nvidia-ml-py/#history
Describe the solution you'd like
Please replace the pynvml entry in requirements.txt with nvidia-ml-py.
Describe alternatives you've considered
N/A
Additional context
At some point, it's likely that pynvml 11.5 will stop working with updated nvidia drivers unless it starts getting updates again.

Hi @elistevens - thanks for the reminder, I'll take a look at this.


Moving Machine Learning Compoute to public repo.

Description
Moving machine learning compute to public repo.
This checklist is used to make sure that common guidelines for a pull request are followed.

[x] I have read the contribution guidelines.
[x] The pull request does not introduce breaking changes.

General Guidelines

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

SDK Generation Guidelines

[x] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[x] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code.
[x] The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK.

@shutchings,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

@shahabhijeet I regenerated the files using the new generate file. Also, here's the PR for the public swagger.

@shahabhijeet would it be possible to get permissions to see the build so I can check the failures?

@shutchings we also need a link to the swagger spec in the PR comments

Link to PR for merging the public swagger spec.
Link to current version of swagger spec.

@markcowl I updated the tests so that the location is not hard coded. Any other changes?


Write an empty message to the channel

(I already asked the question on SO but nobody answered. I suspected that is a bug or something.)
I'm trying to send an empty message over the channel using:
channelHandlerContext.writeAndFlush(Unpooled.EMPTY_BUFFER)
Expected behavior
An empty message (some TCP packet) to be sent over the channel.
Actual behavior
Nothing happens. Using wireshark, I can confirm that there's no TCP packet going over the wire.
Steps to reproduce
# Run the server
$ mvn spring-boot:run
# in a different terminal, connect to the server
$ telnet localhost 8080
# Start capturing using wireshare or any other tools.

Minimal yet complete reproducer code (or URL to code)
https://github.com/akefirad/netty-tcp-keep-alive-demo
Netty version
4.1.43.Final
JVM version (e.g. java -version)
openjdk 11.0.4 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.4+11, mixed mode)

OS version (e.g. uname -a)
Linux catter 5.0.0-32-generic #34~18.04.2-Ubuntu SMP Thu Oct 10 10:36:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Thats expected… writing an empty buffer will not result in any sys call.

On 11. Nov 2019, at 10:14, Rad<EMAIL_ADDRESS>wrote:
(I already asked the question https://stackoverflow.com/questions/58399274 on SO but nobody answered. I suspected that is a bug or something.)
I'm trying to send an empty message over the channel using:
channelHandlerContext.writeAndFlush(Unpooled.EMPTY_BUFFER)
Expected behavior
An empty message (some TCP packet) to be sent over the channel.
Actual behavior
Nothing happens. Using wireshark, I can confirm that there's no TCP packet going over the wire.
Steps to reproduce
Run the server
$ mvn spring-boot:run
in a different terminal, connect to the server
$ telnet localhost 8080
Start capturing using wireshare or any other tools.
Minimal yet complete reproducer code (or URL to code)
https://github.com/akefirad/netty-tcp-keep-alive-demo https://github.com/akefirad/netty-tcp-keep-alive-demo
Netty version
4.1.43.Final
JVM version (e.g. java -version)
openjdk 11.0.4 2019-07-16
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.4+11)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.4+11, mixed mode)
OS version (e.g. uname -a)
Linux catter 5.0.0-32-generic #34~18.04.2-Ubuntu SMP Thu Oct 10 10:36:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/netty/netty/issues/9772?email_source=notifications&email_token=AADLIQQFYITMSWDPOD3JWUDQTEO6DA5CNFSM4JLSTQUKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HYLGSPA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADLIQXWFY2IJM4ISWVJ6E3QTEO6DANCNFSM4JLSTQUA.

@normanmaurer thanks for the reply. So you mean this code is useless?

@akefirad I did not check in detail but often an empty buffer is written down the pipeline to do something once all previous writes are complete (like closing the channel). For example people use this to close the channel once all previous data was written


add immovable rod event

About the PR

adds new dangerous event and removes immovable rod launcher because it didn't work in the first place
Media

Changelog

:cl:

add: added rare immovable rod event that can happen late in the game and can literally cut station in half
remove: removed immovable rod launcher

I think it's funny but too illogical, if you want to cut the station in half with meaning, I think it's worth a look here.
https://github.com/space-wizards/space-station-14/assets/60344369/22894b17-f7fa-463b-ae4c-ea4edb631221
Of course it can be done faster.

The rod literally cutting the station in half is effectively an instant round-end since there’s no way to put the station back together. If the event could use a variant of the rod that didn’t destroy floors, I think it would work much better as a midround event.

The rod literally cutting the station in half is effectively an instant round-end since there’s no way to put the station back together. If the event could use a variant of the rod that didn’t destroy floors, I think it would work much better as a midround event.

Even so, if the station is as big as a box, it will kill half the crew and there will be no opportunity to restore the station

Right now it can spawn 1 hour and 30 minutes into the game and has same chance to happen as space dragon. Plus trajectory is random it can potentially only "cut corners", so station cut in half should be not that common overall.

Right now it can spawn 1 hour and 30 minutes into the game and has same chance to happen as space dragon. Plus trajectory is random it can potentially only "cut corners", so station cut in half should be not that common overall.

My opinion on how it should work is:
* Rod can’t destroy floors

* Can happen 60 minutes in, same chance as lone op

There isn’t really any random event that engineering can interact with right now, and a tame version of the immovable rod that didn’t split the station into two pieces would fill that niche by creating a repair job for engineers.

there are meteors

also "high velocity" doesn't make sense
the universe is moving around it not the other way around :godo:

rod MUST be an admin event, it should never spawn normally

remove: removed immovable rod launcher

why

because it didn't work, rod flies like 3 tiles max and stops

also "high velocity" doesn't make sense
the universe is moving around it not the other way around :godo:

its all relative

its called the immovable rod

this is honestly funny maybe make it have an even lower weight but i love this.

with pro spacing you have a solid 5 minutes to fix the breaches before its dangerous, low hazard event

i made it not destroy tiles (fun fact - it can destroy gravity generator, have fun flying!) and appear earlier into shift (45 min)

fun fact - tg station has it and i only discovered it now

Kinda suss because every other event is recoverable besides this one.

maybe make a variant of it that doesnt destroy tiles for the event version

I made it not destroy floors

ok its good then

i think What the fuck was that? would be better announcement

rods now move on spawn (i guess it was a bug because there is RandomizeVelocity field set to true by default)

rod launcher still doesn't work properly


Start re-organising tests "recipes" in component directories

At some point, every component that interacts with the resinOS tests will have "snippets" of code to perform a specific task. The Resin SDK, for instance, can have a snippet to download an image.
Once that's in place, this resinOS Tests repo will only contain high level recipes for test cases, without caring about how the low level details are implemented.
For example, a high level test would look something like this (in pseudo-code):

Download image
Flash image
Connect to resinOS

In that case, the "Download Image" bit would be part of the SDK, the "Flash image" one would be part of Etcher, and the "Connect to resinOS" one would be obviously part of resinOS.
As a way to start moving to that architecture, lets start to extract and re-organize the set of actions we use in a per-component basis. We can create a top level directory called components, which can have the following files:

components/resinio/sdk.js
components/flasher/etcher.js
components/os/resinos.js

The resinio/sdk.js file will contain functions to command the resin.io platform to do several actions. These are the ones I found in the repo:

Download OS (takes version and device type)
Remove an application (takes the id of the application)
Create an application (takes the name and the device type)
Get information about an application (takes the id of the application)
Get the devices from an application (takes the id of the application)
Get information about a device (takes the id of the device)

If we later want to run the same test cases with the CLI, we can implement a resinio/cli.js file that implements the same functions and we're set.
Then, the flasher/etcher.js will contain a single function:

Flash an image (takes path to image and drive device)

Finally, os/resinos.js will contain:

Configure image (takes image, OS version, and configuration object)

Lets also add components/client/git.js which implements:

Deploy (takes source code directory and application id)

At some point we want the Resin CLI to replace the git push, so we will then implement a components/client/resin-cli.js as well.


v2.1.0-beta.1 issue in preview panel with input_select button

Describe the bug
When in the editor and after having added a bubble card select button, if testing in the preview panel, after selecting an entry in the list, it closes the editor without saving and loses any modifications in that session.
Screenshots
https://github.com/Clooos/Bubble-Card/assets/513044/d4f9b6cc-66c5-439e-b61e-263f217b173e
Informations (please complete the following information):

OS: Windows 11
Browser/App: Firefox
Bubble Card version: 2.1.0-beta.1
Home Assistant version: 2024.6.4

This is now fixed on my side, thank you for the feedback!

Thanks. Just adding more bubble card buttons to dashboards. I'll raise more if I come across anything.

This is now fixed 👌
https://github.com/Clooos/Bubble-Card/releases/tag/v2.1.0-beta.2

Fab!


Rename main method to run or enter (or something else)

Right now, there are two mains. One from @effection/node and another from effection, which is confusing. I think that main is the understood term as an entry point to an entire process, so @effection/node main should stay the same since that really is its purpose.
That means we really ought to come up with a better name for it in effection proper. I'm thinking that we should call it run or enter. It should convey that you are entering an effection entry point, but not necessarily for the entire process.

I like run, it feels very short and concise.

@jnicklas I agree. Short, concise, and intuitive👍
@taras while technically you can, have several runs in a process tree since run would convert an operation into what amounts to a promise, you would never do it, since if you're already in an effection context, running a subtask is as simple as yielding to an operation, and you get all the benefits of scoping and cancellation.
Where it could happen is if you have two completely separate libraries, that are not connected using effection, they could each use run internally.
What's not allowed, is using more than one main from @effection/node per node-process since it installs global signal handlers and has hard hooks to process.exit()

I'm going to update this with the good first issue label if anybody wants to tackle it.


[Reguest] Bring the "Edit_OnClick" Setting back

Hi :-)
In the last versions, there was a setting (i dont remember how its called exactly) Edit_onclick or sth like that...
You had the possibility to turn off (Edit entrys if you just click them)... So you had to click on edit before you can change an entry...
After the Update (All the settings to database) some comments ago, it was removed :-(
Cheers :-)

Oops, it was called allow_quick_edit but missing setting value in the DB. Bring it back in commit 615413ae90da109309a2d94066c203eb76a5ea11 of #345

@ngoduykhanh the setting was missing from the initial database on purpose, as it makes little sense to have to handle both database contents AND code for implementing a setting.
The revamped settings "infrastructure" handles the database side of things for you, so all you need is the code changes. Defaults are assigned in the code and any the setting is automatically written to database when toggled.
See #287

Nice, thanks!
Can i close this then?

Solved, fixes are already in upstream....
Cheers :-)


Replace all usages of | in type strings for Python 3.9 compat

Proposed Changes
Modified all type annotations that used |. Most could be replaced by Optional[], while a few actually needed Union[]. Use of | is Python 3.10+ only, which is not widely used yet. e.g. the latest stable Debian is on 3.9.
Related Issues
Fixes #1831
At least the first part of it, for me.
Checklist

[x] Change has been tested and works on my device(s).

Looks like the CI failures are spurious git errors, but I don't have permission to retry them.

Rebased, fixed conflicts/new issues.
We should probably have CI run some tests on Python 3.9 otherwise it will be too easy to have something 3.9-incompatible sneak in again.

I think there's something wrong with your workflows, all the Black jobs work fine but the others error out when trying to clone from Git. I wonder if it's not handling the fact that I have a fork of the repo, instead of pushing to the origin.

@timmo001 Have you had a chance to take a look at this?

Confirmed version 3.4.3 has fixed this specific error for me. Thanks @rpavlik!


Improve deterministic contract creation. Add convenient RGB20 contract builder

@cryptoquick yeah, and this is how it simplifies the code: https://github.com/RGB-WG/rgb-schemata/pull/25/files#diff-4df006067551c6856f6cc2101216b0bc8ab7626eafaee07992d6eeac7ffb13d3L33-L70


Speed up npx @backstage/create-app

Expected Behavior
I should be able to run npx @backstage/create-app in a reasonable amount of time on a modest network connection.
Current Behavior
When I run npx @backstage/create-app, npx first installs @backstage/create-app in a temporary location, which currently downloads ~844MB worth of packages.  On a mobile broadband connection, this can take 5-10 minutes.  This can sometimes result in ERR_SOCKET_TIMEOUT errors in the middle of the process, which then must be restarted.
...Only then does it begin the process of actually scaffolding out the app and running (another) yarn install, which itself takes quite a bit of time (but this is outside the scope of this issue, in my opinion).
Possible Solution
It appears npx installs all peer dependencies.  Do all of the included @backstage/* packages really need to be included as peer dependencies?  Can we express that some other way?

The biggest offenders:

@material-ui/*: ~85MB
aws-sdk: ~70.5MB
TypeScript: ~60MB
typescript-json-schema: ~59MB
@azure/*: ~16MB
@testing-library/*: ~14MB

Your Environment

NodeJS Version: v16
Operating System and Version: MacOS Catalina 10.15

Oh installing peer deps look so unnecessary for the first step in create-app. 850 MB is too much 😕

Yeah the entire point of having create-app separate from backstage-cli is to be able to make it lightweight and not pull in the entire world upfront before starting. We'll look into it.

Good find! A sneaky one it seems, couldn't reproduce without a custom cache location, as in it seemed to install a lot less stuff than in a clean install. Trying out #8231

Verified that this is indeed fixed after #8231 was released, so gonna close


await instance.exit();

await instance.exit();
console.log('pass');
Expected behavior
do show 'pass'
Actual behavior
Sometimes it can't pass the exit() and show nothing. Even added try()catch{}
Steps to reproduce the behavior
I don't know how to reproduce, but it occur every some hours in our system.
Environment

OS: Windows Server 2008
Node version (node -v):  7.5.0
package version: 3.2.0

I'm developing a crawler which parses a list of sites in a loop with throttle.
I think I also have the same problem which appear randomly time to time.
For example this first "zombie" instance if hanging for a long time and uses CPU time
http://prntscr.com/eeotcr

@shirmin any update? I am not sure what is the action item here. Also pease update to version 4.0.0

We changed code to:
try{
await instance.kill();
await instance.exit();
} catch ...
and updated to 4.0.0
Our system runs as we expected.
thanks.

WOOHOO!


Multiprocessing-safe SharedClientServer

Current Situation
SharedClientServer is currently not multiprocessing safe.
Proposed Changes
Assess different implementations for getting something that is multiprocessing safe.
Implementation Details
May want to consider funneling everything through Redis.
Alternatively, we could use a separate process and funnel data between child processes via pipes or HTTP.

Closed as SharedClientServer no longer exists


Links Broken In 2-ltr

A few links in the second scenario i.e 2-Itr are not working.
In Step 3:
The link for New UI shows a 404 page not found error.
https://github.com/thanos-io/tutorials/blame/main/2-lts/step3.md#L81
In Step 4:
*Setup Verification- The link for Bucket view shows a 502 Bad Gateway error.
https://github.com/thanos-io/tutorials/blame/main/2-lts/step4.md#L40
*Compaction and Downsampling- The link for Querier shows a 404 page not found error.
https://github.com/thanos-io/tutorials/blame/main/2-lts/step4.md#L53

#6


LXC cannot resolve DNS name for containers when configuring a proxy

Required information

Distribution: ubuntu
Distribution version: 16.04.5 LTS

Issue description
Hello! I'm not sure whether this is the right place for this issue but I've encountered the following bug / issue after upgrading to the newest lxd:
After snap upgraded my lxd to 3.13, I could not configure a proxy device for a container, using the container dns-name as IP. This was possible in version 3.12.
Steps to reproduce
Running the following leads to an error when using lxd 3.13:
$ lxc launch ubuntu:16.04 testcontainer
Creating testcontainer
Starting testcontainer
$ lxc config device add testcontainer proxy0 proxy listen=tcp:<IP_ADDRESS>:12345 connect=tcp:testcontainer.lxd:27017
Error: Invalid devices: Not an IP address: testcontainer.lxd

In lxd 3.12 there is no issue running these commands:
$ lxc launch ubuntu:16.04 testcontainer
Creating testcontainer
Starting testcontainer
$ lxc config device add testcontainer proxy0 proxy listen=tcp:<IP_ADDRESS>:12345 connect=tcp:testcontainer.lxd:27017
Device proxy0 added to testcontainer

That's normal, the fact that we were resolving was a bug and could have evolved to be a security issue, it was never intended to support DNS names.
In your case, maybe connect=tcp:<IP_ADDRESS>:27017 would do the trick?

Yes that did the trick, I used the proxy definition wrong. Thanks for your response anyway!


Bazel distribtests

This PR adds Bazel Distribtests, officially codifying our supported range of Bazel versions. Two new CI jobs are added, whose triggers are TBD:

Basic Distribtests - Runs bazel build on all supported Bazel versions, based on a manually curated list.
Bazel Latest Version Distribtest - Pulls down and builds with the latest version of Bazel.

Several targets are currently on a blocklist due to preexisting build failures. A next step is to triage this build errors and have them either fixed or removed.
One snag -- upb doesn't currently support our range of builds. An older version of their repo supports the 2.X series, while the commit I've introduced in this PR supports 3+. I've added a check for the Bazel version and manually swap out the upb version  based on the Bazel version. This pattern should be moved to the upb repo so it can support multiple Bazel versions and we can remove the check from our repo.

FYI The toolchain problem is the same as in here: https://github.com/grpc/grpc/pull/25001

Is this still blocked on the bazel toolchain update (same as in #25001). It would be good to address this somehow and unblock this functionality. This PR has been open for >6months now.

I upgraded the repo to bazel 4.2.1, which makes many changes in this PR unnecessary:
https://github.com/grpc/grpc/pull/27410

This needs to be rebased / updated now that https://github.com/grpc/grpc/pull/27486 has been merged.

This PR is very out of date and we might not need the compatibility layer for bazel 2.x anymore (since we support bazel 3.x,4.x and 5.x now), so I'm going to remove myself from the reviewer list.
Consider updating / closing the PR.


Fixed dump profiling

Configuring the DumpListener before subscribing to its events, allowing it to correctly capture dump function calls in the WebProfilerToolbar

/cc @nicolas-grekas Can you validate this one please?

I confirm this resolves my issue with debug tag in toolbar, and also it resolves #95

But please check that this patch doesn't have any unwanted side effect on CLI apps.

This PR fix the issue for me.
In console mode I use \Knp\Provider\ConsoleServiceProvider() and the \Silex\Provider\WebProfilerServiceProvider() is not loaded.
In fact, the dump() function work fine.
You need other test for merge ?

I can confirm this patch fixes the issue for plain Silex web applications.

@nicolas-grekas I think I know what you've meant ... After applying the patch, there's a tiny bug (maybe you can fix it @qkdreyer? ;) ): dump() outputs the HTML twice outside of the application, e.g. placing a dump($app); after $app->run(); will print the application's data twice. Without this patch there won't be any output et all.

@fabpot @nicolas-grekas Any news on this issue?
This fix works for me. Call of  Symfony\Component\Debug\Debug::enable(); hide the Debug panel in profiler.
Minimal working examle (index.php in the root of fabpot/silex-skeleton):
<?php

use Silex\Application;
use Silex\Provider;
use Silex\Provider\WebProfilerServiceProvider;
use Symfony\Component\VarDumper\VarDumper;

require_once __DIR__.'/vendor/autoload.php';

//Symfony\Component\Debug\Debug::enable();

$app = new Application();
$app['debug'] = true;

$app->register(new Provider\HttpFragmentServiceProvider());
$app->register(new Provider\ServiceControllerServiceProvider());
$app->register(new Provider\AssetServiceProvider());
$app->register(new Provider\TwigServiceProvider());
$app->register(new Silex\Provider\VarDumperServiceProvider());
$app->register(new WebProfilerServiceProvider(), array(
    'profiler.cache_dir' => __DIR__.'/../var/cache/profiler',
));
$app['twig.path'] = array(__DIR__.'/templates');

$app->get('/', function () use ($app) {
    VarDumper::dump([1, 2, 3]);
    dump([1, '2', 'three']);

    return $app['twig']->render('index.html.twig', []);
});

$app->run();

Composer.json from fabpot/silex-skeleton with two new packages: symfony/var-dumper and symfony/debug-bundle
{
    "name": "fabpot/silex-skeleton",
    "description": "A pre-configured skeleton for the Silex microframework",
    "license": "MIT",
    "type": "project",
    "require": {
        "php": ">=5.5.9",
        "silex/silex": "~2.0",
        "silex/web-profiler": "^2.0",
        "symfony/asset": "~2.8|^3.0",
        "symfony/browser-kit": "~2.8|^3.0",
        "symfony/class-loader": "~2.8|^3.0",
        "symfony/config": "~2.8|^3.0",
        "symfony/console": "~2.8|^3.0",
        "symfony/css-selector": "~2.8|^3.0",
        "symfony/debug": "~2.8|^3.0",
        "symfony/finder": "~2.8|^3.0",
        "symfony/form": "~2.8|^3.0",
        "symfony/monolog-bridge": "~2.8|^3.0",
        "symfony/process": "~2.8|^3.0",
        "symfony/security": "~2.8|^3.0",
        "symfony/translation": "~2.8|^3.0",
        "symfony/twig-bridge": "~2.8|^3.0",
        "symfony/validator": "~2.8|^3.0",
        "symfony/var-dumper": "^3.4",
        "symfony/debug-bundle": "^3.4"
    },
    "autoload": {
        "psr-0": { "": "src/" }
    },
    "extra": {
        "branch-alias": {
            "dev-master": "2.0.x-dev"
        }
    },
    "scripts": {
        "run": [
            "echo 'Started web server on http://localhost:8888'",
            "php -S localhost:8888 -t web"
        ]
    }
}

Thank you @qkdreyer.


Speech-to-text button

Cloud-based options:

https://cloud.google.com/speech/
https://wit.ai/
https://www.ibm.com/watson/developercloud/doc/speech-to-text/index.html

Found a wit.ai library for Unity: https://github.com/tanejamohit/witUnity

Also this from Unity Labs: https://www.assetstore.unity3d.com/en/#!/content/69399

You would just have to ensure that any modification like this is completely optional - we run most of our VR applications in locations with no internet access (for security reasons).
Given the existing framework, it wouldn't be all that difficult to create your own special key and hook it up to your choice of speech-recognition service. You'd just need to create a custom class based on Key, wouldn't you?


[Connector-v2]Extract Connector public fields

The connector has a public field is fields, usually the schema that defines the Connector,
But at present our definitions are very confusing, each Connector has its own set, a good example is this,
https://github.com/apache/incubator-seatunnel/pull/2439/files
https://github.com/apache/incubator-seatunnel/pull/2451/files
At the same time, there is also an abstraction of public method extraction, which allows developers to not need to parse the schema again, etc.
But I have questions about the fields and schemas in it, can we unify a set of standards? The latter use this.
In addition, for some fields (used by some connectors), such as delimiter, format, etc., whether the standard and format can be unified (I am not sure), we may need a package to do these things,
What do you think?

In my opinion, format in file connectors is a little ambiguous. For some text-based connector format is a best option. But your question is very right, we should unify a set of standards for all connectors to support user-defined schema. I think we can defined some common parameters to represent the current schema information.
fields represent the fields information of upstream data
format represent the format of upstream data, for example: json csv orc parquet etc...
delimiter represent the delimiter of upstream text data to splite fields.
The function of parsing user-defined schema has implemented in connector-common, all that remains is that unified the parameters of connectors
What do you think about?

This discuss is base on Connector-V2 or Connector?

This discuss is base on Connector-V2 or Connector?

yup, I updated

In my opinion, format in file connectors is a little ambiguous. For some text-based connector format is a best option. But your question is very right, we should unify a set of standards for all connectors to support user-defined schema. I think we can defined some common parameters to represent the current schema information.
fields represent the fields information of upstream data
format represent the format of upstream data, for example: json csv orc parquet etc...
delimiter represent the delimiter of upstream text data to splite fields.
The function of parsing user-defined schema has implemented in connector-common, all that remains is that unified the parameters of connectors
What do you think about?

great, but about fields and schema, do we still need nesting? For now, it doesn't seem necessary.

In my opinion, format in file connectors is a little ambiguous. For some text-based connector format is a best option. But your question is very right, we should unify a set of standards for all connectors to support user-defined schema. I think we can defined some common parameters to represent the current schema information.
fields represent the fields information of upstream data
format represent the format of upstream data, for example: json csv orc parquet etc...
delimiter represent the delimiter of upstream text data to splite fields.
The function of parsing user-defined schema has implemented in connector-common, all that remains is that unified the parameters of connectors
What do you think about?

great, but about fields and schema, do we still need nesting? For now, it doesn't seem necessary.

The same as you, i think nesting is useless too. So the conclusion is that we will unified the schema options for all connectors as behind, right? I can do this work and I will create a issue to track this work.

agree with you. you don't need to create an issue separately, you can do it here

The sub tasks about this issue as the following shown:

[ ] local file source connector
[ ] hdfs file source connector
[ ] oss file source connector
[ ] http source connector
[ ] kafka source connector

I don't think format should be a child of schema, format should be a connector-level option with schema.
schema is used to represent the meta information of the table such as field information(fields), primary key, etc.

format is useless in some connectors, such as mysql, oracle.


originSelectionRange not work while targetting non-text file

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.86.0
OS Version: MacOS 14.3 Intel

Steps to Reproduce:

Create a DefinitionProvider that returns a LocationLink with targetUri set to uri of an image and originSelectionRange set to range of multiple word.
Check the behavior of vscode -> goto definitio works, but underline not shown up.
Change the targetUri to uri of an text file.
Check the behavior of vscode -> underline shown properly.

repository
source

I'm not sure whats the best practice of providing a definition to non-text file. GPT4 tells me that non-text files don't have concepts of row or column and just set the target position to (0, 0), which does work properly.

Sorry to bother, but then what's the best practice to allow user jumping to non-text file from text file, e.g. a path to an image?

Yeah, doc link seems like a good fit


DrawTool: bind marker style function [#45104491]

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

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

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
12484

Relevant Lines:
12485

💛  - Coveralls


[Review] Atharva Shirdhankar

https://github.com/StarTrooper08/

Reviewed on live stream https://www.youtube.com/watch?v=xsZIKzE7gy8
Looks great, some thoughts

GitHub profile fields on the left not being used (location, url, description)
contribution graph needs some Code Review love 🤓


Support for mochawesome reporter is missing

Hi,
I am using mochawesome as the reporter and I am getting below exception.
"mochawesome" reporter not found
Uncaught exception: Error: invalid reporter "mochawesome"
    at MochaWrapper.Mocha.reporter (C:\git\ac3-api-test\node_modules\mocha\lib\mocha.js:174:13)
    at Object.applyReporter [as default] (C:\git\ac3-api-test\node_modules\mocha-parallel-tests\dist\bin\options\reporter.js:7:11)
    at Object.<anonymous> (C:\git\ac3-api-test\node_modules\mocha-parallel-tests\dist\bin\cli.js:121:19)
    at Module._compile (module.js:660:30)
    at Object.Module._extensions..js (module.js:671:10)
    at Module.load (module.js:573:32)
    at tryModuleLoad (module.js:513:12)
    at Function.Module._load (module.js:505:3)
    at Function.Module.runMain (module.js:701:10)
    at startup (bootstrap_node.js:193:16)

Please be informed that mochawesome is one of the most famous reporters for mocha

Hi @jain-neeeraj, thank you for posting the issue.
As for mochawesome:

mochawesome is not one of mocha internal reporters which means you need to add it to your dependencies
There was still a bug in<EMAIL_ADDRESS>with mochawesome but it's already fixed in master branch. The new version will be released in 2-3 days, I will mention you here.

<EMAIL_ADDRESS>has just been published. Follow by advice from above (regarding dependencies) to make it work


Added title font size and weight settings to match other OOTB web parts

Category

[ ] Bug Fix
[ ] New Feature
Related issues: fixes #493

What's in this Pull Request?
Added font size and weight definitions for the Title of the web part so that the title matches other OOTB web parts.
Guidance
This web part looked different than all the other web parts on a page. This change will make it match other web part titles.

Thank you for the PR and your patience.


Problems upgrading from the Initial v1 release

There were several issues with upgrading from the initial release that broke everything until I did some trial and error troubleshooting.
A big issue was that you changed from using import appapi to import appdaemon.appapi as appapi, which stopped all of my pervious apps from running. I only found out the proper import by looking at the hello.py, so I had to replace that line in all of my apps.
I was forced to run it as a systemd service because the /etc/init.d script you provided will not work as it keeps giving the error:
ImportError: No module named 'appdaemon.conf'; 'appdaemon' is not a package
So it is not finding the conf.py from the appdaemon.py
So, then, using the systemd service throws an error because it does not include the -c argument to point to the configuration file, which is at the default location along with the included appdaemon.cfg.example, but it still told me it couldn't find it, so I had to add the -c flag to the appdaemon.service file.
I really LOVE appdaemon, but enough has changed from the setup of the original version that I can guarantee that all users of the previous version will have errors and problems upgrading. Hopefully this will not be a problem for new users starting out fresh.
Thanks again for the appdaemon, don't know how I lived without it :)

Hi there - thanks for the feedback - I did mention some of these points in the History file and also in the post where I announced the upgrade - particularly the change to the import.
I'll take a look at the init script - I just moved to the systemd script (I have my stuff in the default path) so it worked for me and the init script obviously needs a tweak.

Pushed a new version of the INIT script that should work now and I also updated the systemd unit file with instructions on using the -c option if required.


Add more info to about screen

Belongs to #57.

#57 is still open and in TODO

#57 is still open and in TODO


Nested bullet points in callouts are broken

Describe the bug
- bullet
	- nested
- not nested

> [!note]
> - bullet
> 	- nested
> - not nested

Renders like this in quartz:

Expected behavior

Try this
> [!note]
>
> - bullet
>   - nested
> - not nested

This is a known parser difference between quartz and obsidian. We will improve this once we have more bandwidth.
#1496


Do we need -funwind-tables option for some boards?

Do we still need -funwind-tables option for some boards ? It's not compatible with CLANG compiler so we need additional condition in Make.defs.
This option was introduced in 4d43b05db3bdd79f5438798d3f05625b746e71f6 for stm32f4discovery and then probably copied to  other boards based on stm32f4discovery.
@acassis do you remember the details of the problem (it was a long time ago, PR probably on the old bitbucket repo) ?
Support for stack unwidner is already supported by CONFIG_UNWINDER_ARM option:
https://github.com/apache/incubator-nuttx/blob/d4ba93067ee76e656c39d42e6dcf5f8daa48322e/arch/arm/src/common/Toolchain.defs#L77-L79
but I'm not sure if this has any effects on the C++ code with exceptions enabled.
Boards with this option in Make.defs:

[raiden00:~/git/RTOS/nuttx/nuttx/boards]$ grep -R unwind-tabl
arm/stm32/b-g431b-esc1/scripts/Make.defs:ARCHCFLAGS += -funwind-tables
arm/stm32/b-g431b-esc1/scripts/Make.defs:ARCHCXXFLAGS += -funwind-tables
arm/stm32/nucleo-g431rb/scripts/Make.defs:ARCHCFLAGS += -funwind-tables
arm/stm32/nucleo-g431rb/scripts/Make.defs:ARCHCXXFLAGS += -funwind-tables
arm/stm32/b-g474e-dpow1/scripts/Make.defs:ARCHCFLAGS += -funwind-tables
arm/stm32/b-g474e-dpow1/scripts/Make.defs:ARCHCXXFLAGS += -funwind-tables
arm/stm32/nucleo-g474re/scripts/Make.defs:ARCHCFLAGS += -funwind-tables
arm/stm32/nucleo-g474re/scripts/Make.defs:ARCHCXXFLAGS += -funwind-tables
arm/stm32/stm32f4discovery/scripts/Make.defs:#   ARCHCFLAGS += -funwind-tables
arm/stm32/stm32f4discovery/scripts/Make.defs:#   ARCHCXXFLAGS += -funwind-tables
arm/stm32/nucleo-g431kb/scripts/Make.defs:ARCHCFLAGS += -funwind-tables
arm/stm32/nucleo-g431kb/scripts/Make.defs:ARCHCXXFLAGS += -funwind-tables
arm/eoss3/quickfeather/scripts/Make.defs:  ARCHCFLAGS += -funwind-tables
arm/eoss3/quickfeather/scripts/Make.defs:  ARCHCXXFLAGS += -funwind-tables

I found it on my email:
"I was facing this error caused by recent modifications on mainline ldscripts:
...
LD: nuttx
arm-none-eabi-ld: section .data LMA
[000000000800e644,000000000800e6ab] overlaps section .ARM.exidx LMA
[000000000800e640,000000000800e647]
make[1]: *** [Makefile:185: nuttx] Error 1
Searching for this error I found a solution here:
https://stackoverflow.com/questions/30778614/arm-none-eabi-ld-section-arm-exidx-overlaps-section-data
The inclusion of "-funwind-tables" fixed the error, but we need to
doable check if it will not generate size effects for other people
(same way previous modification generated side effects to me)."

The thread name on Google group is:
PATCH: Fix .ARM.exidx section overlap

We need to check again and depending on result we can put CONFIG_UNWINDER_ARM as dependence for these boards


Core SDK Actions are missing from the UI

Describe the bug
These actions are missing from the UI:
DialogManagement:

CancelDialog
GetConversationReference
ContinueConversation
ContinueConversationLater

Looping

GotoAction

Debugging

DebugBreak

Expected behavior
Those actions to be there.

@EricDahlvang I know you've been interested in this one!

They don't have uischema defined, needs to be updated in dotnet runtime repo.
Refs another thread of Trigger kinds: https://github.com/microsoft/BotFramework-Composer/issues/7035#issuecomment-821047705
Needs to have another wave of SDK release. @cwhitten

@tomlm Tom, I noticed CancelDialog and CancelAllDialogs have the same schema definition: CancelDialog.schema vs CancelAllDialogs.schema
However, in the underlying implementation they are different from each other, where CancelDialog.cancellAll equals false and CancelAllDialogs.cancellAll equals true.


Add back finite difference tests

Codecov Report

Merging #22 (e3c1644) into main (305ce9a) will increase coverage by 0.10%.
The diff coverage is n/a.

Additional details and impacted files


feat(sync): download peer penalization

Codecov Report

Merging #427 (55295e7) into main (ae2fc49) will decrease coverage by 0.48%.
The diff coverage is 83.25%.

@@            Coverage Diff             @@
##             main     #427      +/-   ##
==========================================
- Coverage   74.44%   73.96%   -0.49%
==========================================
  Files         238      240       +2
  Lines       22933    23188     +255
==========================================
+ Hits        17073    17150      +77
- Misses       5860     6038     +178

Impacted Files
Coverage Δ

bin/reth/src/node/mod.rs
0.00% <0.00%> (ø)

crates/interfaces/src/p2p/bodies/client.rs
0.00% <ø> (-100.00%)
:arrow_down:

crates/interfaces/src/p2p/downloader.rs
0.00% <ø> (ø)

crates/interfaces/src/p2p/headers/client.rs
50.00% <ø> (-50.00%)
:arrow_down:

crates/interfaces/src/p2p/headers/downloader.rs
57.14% <ø> (ø)

crates/interfaces/src/p2p/headers/error.rs
100.00% <ø> (+100.00%)
:arrow_up:

crates/interfaces/src/test_utils/bodies.rs
0.00% <0.00%> (ø)

crates/net/network/src/fetch/client.rs
58.82% <0.00%> (-12.61%)
:arrow_down:

crates/net/network/src/peers/manager.rs
65.81% <ø> (-6.77%)
:arrow_down:

crates/net/downloaders/src/headers/linear.rs
84.35% <46.15%> (-1.68%)
:arrow_down:

... and 27 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


[FLINK-34259] Fix fails to compile with NPE on hasGenericTypesDisabled

[FLINK-34259] Fix fails to compile with NPE on hasGenericTypesDisabled

CI passed locally https://github.com/Jiabao-Sun/flink-connector-jdbc/actions/runs/7709389700/job/21010504922

IIUC, we're just failing the test not compiling, right?

Yes

@reswqa can you please elaborate why it was decided to merge it here nevertheless it was mentioned by @MartijnVisser

@Jiabao-Sun This shouldn't be fixed in the JDBC connector, this appears to be a blocker for 1.19 since they shouldn't break interfaces

I feel like we need more info

ok, thanks for clarification
i should have looked at jira as well


Seperate kitspace summaries for different variants

Someone on twitter was confused about the descriptions

Thanks! There was an error in this proposal which commit 7aca050ecb2eb7984058e4e4f611ed8ac36ac246 fixed.


Permission problem with testusbserial.py

I am trying to run testusbserial.py on my Android 4 smartphone running sl4a via the QPython app.
The script runs fine until line 63, then a permission dialog shows up and after i confirm it keeps looping "waiting for connect...".
(I have a CH340 Arduino Nano connected to the USB OTG port, so i changed the lines 45 and 53 with the correct IDs.)

Sorry too late, I'm no longer use USBHostSerialFacade.
Above is for another users want to use CH340.
My USBHostSerialFacade is for limited serial devices.
Android USB Host programing is very low level and My USBHostSerialFacade is not created for various devices.
Maybe this proglem is caused by difference of USB commands among my PL3404, RL78 and your CH340.
CH340 users will need to change USBHostSerialFacade program.


use graphql to request repo & fork info

This does not work yet. Also, github graphql requires oauth token right now so not really interested in getting this in until github probably provides read-only access without token

graphQL can also get fork commits, see here
so we can get ahead/behind status of forks with just one query
and even more fancy stuff like plotting a commit graph

This does not work yet.

i even got variables and pagination to work ^^
included suggestions for oauth, fetch-retry, graphql-client

github graphql requires oauth token right now so not really interested in getting this in until github probably provides read-only access without token

poor excuse : P
the benefits of graphql are well worth the "sign in with github" click
we can still offer a "light version" without login
related projects:
github has its own network graph in the repo-insights menu
gitgraph.js can render commit graphs in html + svg
has support for different graph styles
graphql rover is a graphQL schema browser, rendering to canvas/webGL
a study on: Commit graph drawing algorithms
SO/pretty-git-branch-graphs has a huge list of commit graphs
and SO/visualizing-branch-topology-in-git has even more
its hard to choose only one graph style, so ideally provide a variety of styles
toddsifleet.com/projects/github-forks is another github fork browser, also with d3.js visuals [found here]
hbt/git-forks-analysis is a git fork analyzer, only html


polybar doesn't detect sink on boot

The polybar module will flash an error about the sink not existing, intermitently. Reloading i3 removes the error and the module works correctly.

It seems likely that the pulseaudio sink is not yet initialized when this line runs in pulseaudio-tail.sh.
There's 2 things to potentially fix here:

Fix error/flashing. Something more graceful should happen if a sink doesn't exist (for example, if no audio device is actually installed).

Somehow compensate for delay in sink initialization (if I'm correct about that being the cause). Or maybe only print the volume when we receive an event trigger of the sink being ready to use.

I was thinking of looping while the command returns exit code 1 and pipeing output to Dev null. Removes the constant flashing of the error message and compensates for the initial failure of variable duration. I think.

Feel free to fix, or I will later

@amasover resolved. see commit above.


Jkbms_Can: Cell count: 1 | Cells populated: 0 && TypeError: '>' not supported between instances of 'float' and 'NoneType'

Describe the bug
Hi, I'm trying to run my Jk bms over CAN bus using this project. When I setup everything and make running, the bms entry is appearing and disappearing from the VenusOS screen - most likely the driver is constantly restarting or so. When it is visible, no data shown (all fields empty).

See logs bellow for details. It looks like there is Cells populated: 0 which leads to TypeError: '>' not supported between instances of 'float' and 'NoneType'. Can anyone give me any ideas ?
Similar problem with zero cells I noticed with Daly_Can.
I tested with master (commit e3206f7) and dev (commit 5e025e6). Project didn't run with latest release since I had a python wheels issue.
Hardware: RaspberryPI zero 2w with clean VenusOS 3.14 large image, CAN Bus adapter MCP2515/TJA1050, JK BMS B2A8S20P heat can.
CAN adapter is connected according to: https://forums.raspberrypi.com/viewtopic.php?t=141052, with dtoverlay=mcp2515-can0,oscillator=8000000,interrupt=12 in boot config.txt. I confirmed that my can0 works against computer at 250kbps. I see "some" can messages from the JK bms on the computer as well in the canable cangaroo app (all are on the same can bus).

candump can0
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  4F5   [8]  DD 0C 01 DC 0C 02 55 AA
  can0  5F5   [8]  3A 01 3A 00 11 55 00 AA
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  4F5   [8]  DC 0C 01 DC 0C 02 55 AA
  can0  5F5   [8]  3A 01 3A 00 11 55 00 AA
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  4F5   [8]  DC 0C 01 DD 0C 02 55 AA
  can0  5F5   [8]  3A 01 3A 00 11 55 00 AA
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  4F5   [8]  DC 0C 01 DD 0C 02 55 AA
  can0  5F5   [8]  3A 01 3A 00 11 55 00 AA
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  4F5   [8]  DC 0C 01 DD 0C 02 55 AA
  can0  5F5   [8]  3A 01 3A 00 11 55 00 AA
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01
  can0  4F5   [8]  DC 0C 01 DD 0C 02 55 AA
  can0  5F5   [8]  3A 01 3A 00 11 55 00 AA
  can0  2F5   [8]  83 00 9F 0F 04 AA 4A 01

How to reproduce

Installed clean venus os on my rpi zero 2w, connected to wifi, made ssh
connected CAN adaper, set CAN speed to 250kbps
tested CAN with PC (both, JK bms and rpi with venus)
installed dbus_serialbattery according to documentation (dev and master)
enabled DVCC
set the config.ini
reinstall dbus_serialbattery & reboot

Expected behavior
I see the Jk bms entry on the venusos board.
Driver version
e3206f7
Venus OS device type
Raspberry Pi 2
Venus OS version
3.14
BMS type
Daly Smart BMS, JKBMS / Heltec BMS
Cell count
4
Battery count
1
Connection type
Serial USB adapter to TTL
Config file
[DEFAULT]
LOGGING = DEBUG
CAN_PORT = can0
BMS_TYPE = Jkbms, Jkbms_Can

Relevant log output
2024-02-04 12:58:53.026649500 INFO:SerialBattery:
2024-02-04 12:58:53.027291500 INFO:SerialBattery:Starting dbus-serialbattery
2024-02-04 12:58:53.028287500 INFO:SerialBattery:dbus-serialbattery v1.0.20231117dev
2024-02-04 12:58:53.766530500 INFO:SerialBattery:-- Testing BMS: 1 of 3 rounds
2024-02-04 12:58:53.767151500 INFO:SerialBattery:Testing Jkbms_Can
2024-02-04 12:58:53.768072500 DEBUG:SerialBattery:Can bus init
2024-02-04 12:58:53.842501500 DEBUG:SerialBattery:Can bus init done
2024-02-04 12:58:55.192490500 INFO:SerialBattery:Connection established to Jkbms_Can
2024-02-04 12:58:55.193168500 INFO:SerialBattery:Battery Jkbms_Can connected to dbus from can0
2024-02-04 12:58:55.193757500 INFO:SerialBattery:========== Settings ==========
2024-02-04 12:58:55.194309500 INFO:SerialBattery:> Connection voltage: NoneV | Current: NoneA | SoC: None%
2024-02-04 12:58:55.194822500 INFO:SerialBattery:> Cell count: 1 | Cells populated: 0
2024-02-04 12:58:55.195345500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2024-02-04 12:58:55.195894500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 50.0A | MAX BATTERY DISCHARGE CURRENT:                                                                                60.0A
2024-02-04 12:58:55.196417500 INFO:SerialBattery:> CVCM:     True
2024-02-04 12:58:55.196960500 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.9V | MAX CELL VOLTAGE: 3.45V
2024-02-04 12:58:55.197496500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2024-02-04 12:58:55.198020500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2024-02-04 12:58:55.198544500 INFO:SerialBattery:> CCCM SOC: True  | DCCM SOC: True
2024-02-04 12:58:55.199069500 INFO:SerialBattery:Serial Number/Unique Identifier: NoneAh
2024-02-04 12:58:55.235715500 INFO:SerialBattery:DeviceInstance = 4
2024-02-04 12:58:55.236534500 INFO:SerialBattery:com.victronenergy.battery.can0
2024-02-04 12:58:55.257097500 INFO:SerialBattery:publish config values = 1
2024-02-04 12:58:56.820386500 Traceback (most recent call last):
2024-02-04 12:58:56.820393500   File "/opt/victronenergy/dbus-serialbattery/dbushelper.py", line 389, in publish_batt                                                                                ery
2024-02-04 12:58:56.820398500     self.battery.manage_charge_current()
2024-02-04 12:58:56.820401500   File "/opt/victronenergy/dbus-serialbattery/battery.py", line 580, in manage_charge_c                                                                                urrent
2024-02-04 12:58:56.820406500     if utils.MAX_BATTERY_CHARGE_CURRENT > self.max_battery_charge_current:
2024-02-04 12:58:56.820410500 TypeError: '>' not supported between instances of 'float' and 'NoneType'
2024-02-04 12:58:57.037272500
2024-02-04 12:58:58.125645500 INFO:SerialBattery:
2024-02-04 12:58:58.126370500 INFO:SerialBattery:Starting dbus-serialbattery
2024-02-04 12:58:58.127602500 INFO:SerialBattery:dbus-serialbattery v1.0.20231117dev

Any other information that may be helpful
No response

After changing CAN_FRAMES in the `jkbms_can.py" to following, some BMS data was read correctly:
Connection voltage: 13.1V | Current: -4.5A | SoC: 4%
but cell count 3 still doesn't seem to be correct and I'm still facing the TypeError
    CAN_FRAMES = {
        BATT_STAT: 0x02F5,
        CELL_VOLT: 0x04F5,
        CELL_TEMP: 0x05F5,
        ALM_INFO: 0x07F5,
    }

2024-02-04 15:32:55.582081500 INFO:SerialBattery:
2024-02-04 15:32:55.582713500 INFO:SerialBattery:Starting dbus-serialbattery
2024-02-04 15:32:55.583704500 INFO:SerialBattery:dbus-serialbattery v1.0.20231117dev
2024-02-04 15:32:56.323313500 INFO:SerialBattery:-- Testing BMS: 1 of 3 rounds
2024-02-04 15:32:56.323938500 INFO:SerialBattery:Testing Jkbms_Can
2024-02-04 15:32:56.324844500 DEBUG:SerialBattery:Can bus init
2024-02-04 15:32:56.399649500 DEBUG:SerialBattery:Can bus init done
2024-02-04 15:32:57.748679500 INFO:SerialBattery:Connection established to Jkbms_Can
2024-02-04 15:32:57.749491500 INFO:SerialBattery:Battery Jkbms_Can connected to dbus from can0
2024-02-04 15:32:57.750182500 INFO:SerialBattery:========== Settings ==========
2024-02-04 15:32:57.750917500 INFO:SerialBattery:> Connection voltage: 13.1V | Current: -4.5A | SoC: 4%
2024-02-04 15:32:57.751556500 INFO:SerialBattery:> Cell count: 3 | Cells populated: 3
2024-02-04 15:32:57.752282500 INFO:SerialBattery:> LINEAR LIMITATION ENABLE: True
2024-02-04 15:32:57.752952500 INFO:SerialBattery:> MAX BATTERY CHARGE CURRENT: 50.0A | MAX BATTERY DISCHARGE CURRENT: 60.0A
2024-02-04 15:32:57.753781500 INFO:SerialBattery:> CVCM:     True
2024-02-04 15:32:57.754468500 INFO:SerialBattery:> MIN CELL VOLTAGE: 2.9V | MAX CELL VOLTAGE: 3.45V
2024-02-04 15:32:57.755121500 INFO:SerialBattery:> CCCM CV:  True  | DCCM CV:  True
2024-02-04 15:32:57.755853500 INFO:SerialBattery:> CCCM T:   True  | DCCM T:   True
2024-02-04 15:32:57.756706500 INFO:SerialBattery:> CCCM SOC: True  | DCCM SOC: True
2024-02-04 15:32:57.757466500 INFO:SerialBattery:Serial Number/Unique Identifier: JKBMSCAN3cells_NoneAh
2024-02-04 15:32:57.811788500 INFO:SerialBattery:DeviceInstance = 4
2024-02-04 15:32:57.812386500 INFO:SerialBattery:com.victronenergy.battery.can0
2024-02-04 15:32:57.834986500 INFO:SerialBattery:publish config values = 1
2024-02-04 15:32:59.406252500 Traceback (most recent call last):
2024-02-04 15:32:59.406258500   File "/opt/victronenergy/dbus-serialbattery/dbushelper.py", line 389, in publish_battery
2024-02-04 15:32:59.406263500     self.battery.manage_charge_current()
2024-02-04 15:32:59.406266500   File "/opt/victronenergy/dbus-serialbattery/battery.py", line 580, in manage_charge_current
2024-02-04 15:32:59.406271500     if utils.MAX_BATTERY_CHARGE_CURRENT > self.max_battery_charge_current:
2024-02-04 15:32:59.406275500 TypeError: '>' not supported between instances of 'float' and 'NoneType'
2024-02-04 15:32:59.630628500
2024-02-04 15:33:00.765353500 INFO:SerialBattery:
2024-02-04 15:33:00.766070500 INFO:SerialBattery:Starting dbus-serialbattery
2024-02-04 15:33:00.767314500 INFO:SerialBattery:dbus-serialbattery v1.0.20231117dev
2024-02-04 15:33:01.537696500 INFO:SerialBattery:-- Testing BMS: 1 of 3 rounds
2024-02-04 15:33:01.538409500 INFO:SerialBattery:Testing Jkbms_Can
2024-02-04 15:33:01.539847500 DEBUG:SerialBattery:Can bus init
2024-02-04 15:33:01.616658500 DEBUG:SerialBattery:Can bus init done

It seems exception and rest of troubles are fixed by following:
jkbms_can.py
self.max_battery_current = MAX_BATTERY_CHARGE_CURRENT

change to
self.max_battery_charge_current = MAX_BATTERY_CHARGE_CURRENT

Same self.max_battery_charge_current issue seems to be in daly_can.py

I found the CAN_FRAMES are different for Black and Silver JK Bms. So I introduced another fix to deal with it: https://github.com/mr-manuel/venus-os_dbus-serialbattery/pull/24


Bulk method for model fitting

[ ] Additional function parameters, change functionality or change defaults?
[ ] New estimator in cr.tl.estimators?
[ ] New kernel in cr.tl.kernels?
[ ] New gene trend model in cr.ul.models?
[ ] New plotting function in cr.pl?
[x] Other?

Investigate how to do know placement (see tradeSeq) and how to deal with low abs. prob. for some lineages.

Seems like we're going to need some bulk fitting method before implementing this, if we want to implement something similar akin to tradeSeq - it will also help with #305 and lineage-related parameters.

Closing this in favor of #377


User can login to their server

For the status key in the login store, it doesn't make as much sense to use 'not fetched'|'fetching'|'fetched'. What do you think of 'not done'|'doing'|'done'? Perhaps we could use that in all of our stores. It seems semantic for all async actions that could succeed or fail, regardless of whether or not they actually "fetch" something (e.g. accessing local storage or a device api).

I am fine with the 'not done'|'doing'|'done'.


orcaslicer: Add version 1.7.0

Closes https://github.com/ScoopInstaller/Extras/issues/12201

[x] I have read the Contributing Guide.

/verify


Renaming all occurrences of revision0 to version0

Renamed all occurrences of the term revision0 to version0 to better reflect the current terminology. The change was discussed here.

/azp run

/azp run

/azp run


Iconv::IllegalSequence when printing € char

Hi,
I'm creating a pdf document with your wonderfull tool.
I'm french and I have to print some prices on my documents. So I need to print the prices in Euro with '€' character. But when doing so I have an Iconv error or 'â¬' printed instead.
I tried to change, in rghost configuration, the font encoding and charset convert but nothing changed.
Is this an issue or a configuration problem from me?
ps: I tried  with several fonts too.
Thanks for your time.

Hi,
i ran into the same issue, but can't get it work. The Euro symbol won't be displayed and all other special characters like German äöü, too. I'm always getting this error: "\xE4" from ASCII-8BIT to UTF-8 (Encoding::UndefinedConversionError)
what i have tried so far:

RGhost::Config::GS[:charset_convert]=nil
RGhost::Config::GS[:charset_convert]=lambda {|text| Iconv::iconv('ISO-8859-15','UTF-8//TRANSLIT1', text).first.to_s} and some other combinations
doc = Document.new(..., :font_encoding => "UTF-8")
adding # encoding: UTF-8 to the .rb file
text_var.force_encdoding("UTF-8") to all variables i want to assign to the output PDF

i'd be really glad if somebody could help me. i'm running ruby 1.9.2 and rails 3.1.1.
thx, Christian.

can you wrap up this code in a file and send it to me in pvt? shairon.toledo at gmail


use aliyun mns service exception

Prerequisites
Please check the FAQ, and search existing issues for similar questions before creating a new issue.YOU MAY DELETE THIS PREREQUISITES SECTION.

[x] I have checked the FAQ, and issues and found no answer.

aliyun mns service reject my request,because the request message with some message like Pinpoint-TraceID、Pinpoint-SpanID。
i want to know that is there some ways to skip or resolve this question

According to #4882 issue, it seems that aliyun sdk solved the problem.
Upgrade version of aliyun sdk or Disable the pinpoint plugin that aliyun sdk is using.