sbd discovery

SBD data discovery. It is used within the cluster discovery loop.
The data is stored in trento/v0/clusters/$cluster/sbd.
The major part of the logic is in internal/cluster/sbd.go
The stored data:

/etc/sysconfing/sbd conent
sbd dump command output
sbd list command output

It brings some new views in the cluster view too:

@stefanotorresi I have changed the code for:

Improve the regular expression to cover all the use cases
Load partial information in case of failure (this might need some changes in the future, as I don't exactly know all the use cases, but now it sends all the available data). I bet for let it as it is until we have some real users feedback

@arbulu89 you are possibly already keeping it in mind, if not, then it must not necessarily be a disk-based sbd, it could also be a qdevice or a diskless sbd when 3 nodes.

Have some 🐝


Refactor swift and kitura docker images.

Details coming soon...

all code is in the master branches for both repo's


Autocomplete Not Working

Installing styled-vanilla-extract into a fresh project with yarn qwik add styled-vanilla-extract installs the plugin correctly but the autocomplete is not working as intended. I tested this on the latest versions of qwik and styled-ve. I also checked on the stackblitz that is provided in the README, which also has the same issue.

Qwik: 0.16.1
styled-vanilla-extract: 0.5.3

I apologize if this is mentioned anywhere but I couldn't find anywhere mentioning that autocomplete is not supported by this library (since @vanilla-extract/css supports it). Let me know if you need more information.

Ah, you mean that it's not correctly getting the exports from the library? Indeed, it seems that I need to figure that out some more. Thanks for reporting!

@wmertens Just put up a PR that should fix this! The TS types were just a bit off. Should've resolved them.


Maybe "SHOULD" instead of "SUGGESTED" for issue tracker?

I'm sure there was much internal debate about whether to use "SUGGESTED" or "SHOULD" for this one in doc/criteria.md:

It is SUGGESTED that the project use an issue tracker for tracking individual issues.

So I'm not sure I have much to add except that IMHO that should be a "SHOULD".  There are some projects out there that just use email threads, but it's so much better for everyone if there's a tracker.  For one thing, it's a lot easier to say to someone "That's a duplicate report, thanks -- see ticket #BLAH" when there's an actual ticket "#BLAH" to point to.  A mailing list thread just doesn't cut it as a substitute for a ticket.  Threads have multiple entry points, tend to meander and cover different topics, and (perhaps most importantly) don't have a human friendly tag by which they can be referred to.  One ends up using some arbitrary combination of the subject line, the date of the posting, the archive link, the author's name (ah, but which post?  now you have one more thing to think about)... Or you can use a thread/topic link, but those are unwieldy for various reasons.
Basically, everything gets harder without a ticket tracker.  Casting my vote for "SHOULD" :-).

I'm fine with raising it up to a SHOULD, for all the reasons given.
To me the most important reason for an issue tracker is that things don't get lost.  In any case, as stated: "everything gets harder without a ticket tracker."  Anyone else have any thoughts?

I'm sure there was much internal debate about whether to use "SUGGESTED" or "SHOULD" for this one in doc/criteria.md

You're right about that.  One project in particular that argues against issue trackers is the Linux kernel project.  A number of its developers believe that an issue tracker is unwieldy and counter-productive for a project as large and fast-moving as the Linux kernel.  These developers do use issue trackers on other projects, so it not because they don't understand them; they do understand them.  It may very well be that current issue trackers break down at the massive scale of projects like the Linux kernel.  We could still make it a "SHOULD", and the Linux kernel folks can note their unusually large scale as the justification for not using one.
Any more comments?

I agree that "SHOULD" is the right level.  The Linux kernel developers can justify their idiosyncracy any way they want.  There is a semi-official tracker at https://bugzilla.kernel.org/, by the way.  Whether one should use it or not to track a given bug apparently depends on which subsystem that bug is in -- see the section "Identify who to notify" in https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/REPORTING-BUGS (or in https://github.com/torvalds/linux/blob/master/REPORTING-BUGS, which is the same file) for details.
The rest below is just for fun and does not need a response:
FWIW, I don't really buy the notion that massive scale -- in terms of number of lines of code, number of committers, commits merged per day, or whatever -- is by itself an argument against having an issue tracker.  If anything, I would think the opposite.  I certainly believe you that there are kernel developers other than Linus who feel that using an issue tracker for the kernel is counterproductive.  However, let's face it, if Linus said "From now on I'm going to be using XYZ issue tracker for kernel work", all the other developers would start using it too :-).  The Linux kernel project's real justification for why they don't require primary developers to use the tracker should simply be "Linus doesn't use it".
(I guess I'm assuming he doesn't use it, though would be surprised & interested to learn otherwise.)


Synthesize VT Mouse Events

Summary of the Pull Request
Make TerminalControl synthesize mouse events and Terminal send them to the TerminalInput's MouseInput module.
The implementation here takes significant inspiration from how we handle KeyEvents.
References
Closes #545 - VT Mouse Mode (Terminal)
#376 - VT Mouse Mode (ConPty)
⚠ NOTE: This should not be merged until the following PRs are merged:

#4848: add MouseInput to TerminalInput (base branch)
#4856: VT input passthrough in ConPty

Detailed Description of the Pull Request / Additional comments
TerminalControl

_TrySendMouseEvent attempts to send a mouse event via TermInput. Similar to _TrySendKeyEvent
Use the above function to try and send the mouse event before deciding to modify the selection

TerminalApi

Hookup (re)setting the various modes to handle VT Input
Terminal is always in VT Input mode (important for #4856)

TerminalDispatch

Hookup (re)setting the various modes to handle VT Input

TerminalInput

Convert the mouse input position from viewport position to buffer position
Then send it over to the MouseInput in TerminalInput to actually do it (#4848)

Validation Steps Performed
Tests should still pass.

Okay, I played with a build of this extensively and only found two issues. One isn't even a bug, it's just ~ ~ weird ~ ~.

(the bug) if you launch mc and un-focus the window, your first click-drag inside the window will begin a selection and send a mouse event. All click-drags after that will extend the selection and send mouse events.
(the weirdo) if you're using standard X10 coordinate mode, which can only address cells up to 94x94, clicking outside of the 94x94 rectangle in the top left of the terminal causes normal mouse events to fire!

2 is a weird case and the encoding is not often used, i bet, so we can ignore it.

Also, yes, gotta figure out how that "revert" commit got in here.

do not automerge this -- it is not into master.

/azp run

old status cannot be cleared.


Fix gradle wrapper version.

@digitalbuddha Looks like people are finding this annoying after all 😅. Should we stick to the latest stable release for Gradle wrapper?

Codecov Report

Merging #102 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #102   +/-   ##
=========================================
  Coverage     82.52%   82.52%
  Complexity      234      234
=========================================
  Files            45       45
  Lines           950      950
  Branches        151      151
=========================================
  Hits            784      784
  Misses          109      109
  Partials         57       57

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3e27766...ab1e2fa. Read the comment docs.


Unable to extract the rules with the absence of CIS control

Hi, I have try out the parsers on the latest benchmark for windows 10 and seems like there are some issue with the condition if CIS controls are missing.

You could try to comment the cis_count in the if :
if rule_count:
row_count = [
rule_count,
level_count,
description_count,
rat_count,
acnt,
rem_count,
defval_count,
#cis_count,
]
Something like this, maybe check is default value is there


feat(hardhat): implement contract deployment persistence

Description
This PR implements persistence for contract deployments in the Hardhat development environment. It ensures that deployed contracts' information persists between container restarts by properly configuring Docker volumes and implementing manual deployment file saving.
Changes

Added volume mappings in docker-compose.yml for:

/app/deployments
/app/artifacts
/app/cache

Updated Dockerfile.hardhat with proper permissions
Implemented manual deployment file saving in deploy scripts
Updated Hardhat configuration for correct deployment paths

Testing Done

Verified deployment file persistence after container restart
Tested contract deployment process
Verified file permissions and access
Checked deployment file integrity

Notes
This PR addresses only deployment persistence. Block/state persistence will require a separate solution (likely migration to Ganache or a full Ethereum client) as Hardhat Network doesn't support state persistence.
Breaking Changes
None. This is a backwards-compatible enhancement.
Related Issues

Closes #669
Depends on #626

Checklist

[x] Code follows project style guidelines
[x] Changes are tested and working as expected
[x] Documentation has been updated
[x] Docker configuration has been validated
[x] All tests pass
[x] No new warnings introduced

/label enhancement
/label blockchain
/label persistence

@cristiam86 I created an issue related about that: https://github.com/yeagerai/genlayer-studio/issues/659

Closing this PR as the persistence functionality will be implemented as part of https://github.com/yeagerai/genlayer-studio/pull/713, which provides a more comprehensive solution including:
Contract deployment persistence through Docker volumes
Proper file handling and permissions
Integration with the consensus service
Complete deployment workflow
The requirements from this PR will be fully covered there as part of the larger consensus service integration. Please refer to https://github.com/yeagerai/genlayer-studio/pull/713 for the implementation.


Unexpected error - System.ArgumentException: Start and End must be well ordered

This poped out when I was typing some stuff (defining a function). Dunno why it happened, didn't do anything "special".
I'll post it here, I guess.
[Window Title]
devenv.exe
[Main Instruction]
An unexpected error occurred
[Content]
Please press Ctrl+C to copy the contents of this dialog and report this error to our issue tracker.
[^] Hide details  [Uždaryti]
[Expanded Information]
Build: 15.6.18072.2

System.ArgumentException: Start and End must be well ordered
   at Microsoft.PythonTools.SourceSpan.ValidateLocations(SourceLocation start, SourceLocation end)
   at Microsoft.PythonTools.Intellisense.LocationTracker.Translate(SourceSpan span, Int32 fromVersion, Int32 toVersion)
   at Microsoft.PythonTools.Intellisense.VsProjectAnalyzer.ConvertNavigations(Navigation[] navigations, LocationTracker translator, Int32 fromVersion, ITextSnapshot snapshot)
   at Microsoft.PythonTools.Intellisense.VsProjectAnalyzer.<GetNavigationsAsync>d__169.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudioTools.UIThread.<>c__DisplayClass18_0`1.<<InvokeTask>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PythonTools.Navigation.DropDownBarClient.<RefreshNavigationsFromAnalysisEntry>d__36.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PythonTools.Navigation.DropDownBarClient.<Microsoft-PythonTools-Editor-IPythonTextBufferInfoEventSink-PythonTextBufferEventAsync>d__35.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.PythonTools.Infrastructure.VSTaskExtensions.<HandleAllExceptions>d__5.MoveNext()

Thanks! This is already fixed and will be available in 15.7.


Route without handler

I'm having an issue where I want to display a modal based on a route. The problem I'm running into is that the route doesn't have a handler since the modal is being brought in as a partial. Is there a way around this or a pattern that's better suited for this scenario?

On one hand, it seems to be supported in Route.js:
/*
 * If no handler is provided for the route, it will render a matched child route.
 */

  getDefaultProps: function(){
    return {
      handler: RouteHandler
    };
  }

Yet I get the warning Warning: Required undefined handlerwas not specified inRoute. (can't find in source) and it fails:
TypeError: Cannot read property 'willTransitionTo' of undefined
    at webpack:///./~/react-router/modules/utils/Transition.js:72:1
    at webpack:///./~/react-router/modules/utils/Transition.js:16:1
    at Array.reduce (native)
    at runHooks (webpack:///./~/react-router/modules/utils/Transition.js:13:1)

@anthonator - here's how I approached this.
With a route config like this, where New User is route that should trigger a modal...
<Route name="Users" path="goats" handler={require('./views/Users/Handler')}>
  <Route name="New User" path="new" handler={require('./views/Goats/views/NewUser/Handler')}/>
  <Route name="User" path=":id" handler={require('./views/Users/views/User/Handler')}/>
</Route>

... New User renders the following:
return (
  <View title="New User" {...this.props}>
    <Modal {...this.props}>
      {modalContent goes here}
    </Modal>
  </View>
);

That's one of the nice things about react-router's view nesting -- in this case the modal is rendered over the Users route, and you can call transitionTo to close the modal and transition back to the Users route (or anywhere else). The open/close state of the modal is simply the state of the router, so you get the whole transition lifecycle of react-router for free. Comes in handy when you want to do something async before a modal loads, before it's closed, when you want multiple steps inside a modal, etc.
I'm not quite sure what you're trying to do with "route without a handler" -- if you want something to render based on a route, that route needs a handler, unless it has children, but modals generally don't have child routes. Are you maybe looking for query params?

Thanks for the input. I think I'm taking the wrong approach using the route to manage the modal. If the component can't be managed using <RouteHandler /> then it probably doesn't deserve a route. Triggering the hide state of a pre-rendered component seems like a flawed approach.
If that's seems right let me know and I'll close.

@grrowl That was added just recently, so its not in the distributed version yet.

:+1: Thanks for letting me know.


How to turn off Stacksight

The events system seems to be tied directly to stacksight. Is there a way to disable sending events to sts?

We're working on disabling it alltogether.
In the meantime I think running *mean disable user-reporting *should stop
it.
Lior
On Wed, Feb 3, 2016 at 10:08 PM, Tim Elfelt<EMAIL_ADDRESS>wrote:

The events system seems to be tied directly to stacksight. Is there a way
to disable sending events to sts?
—
Reply to this email directly or view it on GitHub
https://github.com/linnovate/meanio/issues/96.

--
Lior Kesos - http://www.linnovate.net
Linnovate - Community Infrastructure Care
mail<EMAIL_ADDRESS>office: +972 722500881
cell: +972 524305252
skype: liorkesos

Thanks @liorkesos


OBSDATA-440 Adding SegmentMetadataEvent and publishing them via KafkaSegmentMetadataEmitter

Note
This PR was already approved on top of 24.0.0-confluent branch via https://github.com/confluentinc/druid/pull/106
For PR review comments and discussions, refer to that PR.
Details
Adding the new SegmentMetadataEvent and publishing these segment-related metadata events into Kafka by enhancing the KafkaEmitter
Description
In this PR, we are enhancing KafkaEmitter, to emit metadata about published segments (SegmentMetadataEvent) into a Kafka topic. This segment metadata information that gets published into Kafka, can be used by any other downstream services to query Druid intelligently based on the segments published.
Old behavior of Kafka Emitter
Kafka Emitter always emits metrics and alerts and would emit requests if the config request.topic is configured.
Configs metric.topic and alert.topic are always mandatory and cannot be null.
Current behavior of Kafka Emitter [with backwards compatibility]
We introduced a new config named event.types which dictates the types of events we want the KafkaEmitter to emit. This config takes in a list of strings and can have one or more from [alerts, metrics, requests and segmentMetadata]. And based on this config, alert.topic, request.topic, metric.topic and segmentMetadata.topic should be configured and not left empty.
If no event.types is set, then by default, the kafka emitter would emit metrics and alerts. And in that case, to maintain backwards compatibility, decision to send out requests are based on if request.topic is empty or set.
Metadata format
The emitter by default would emit the metadata in json string format. If segment.metadata.format is set to protobuf, then the emitter emits it in protobuf format.

I'll merge once the build is green


Upgrade to RevealJS 5.1.0

@joshed-io, Hello, I upgraded your work to the latest RevealJS version (5.1.0).
To test it, I started and browsed the example website (hugo server -s exampleSite).
I also tried the new features of RevealJS since 4.4.0, like F1 for help and the new scroll view (?view=scroll).
Tell me if there is something else I should do.

@mraber Thanks for the contribution! I'll give it a quick review in the next few days and tag the current version before I merge it in so that users of the current version can target that.

Hi @joshed-io
Any chance to merge this pull request?
Thanks

@veljko Thanks for the reminder 🙏
@mraber I'll go ahead and merge this in. Thanks again for the contribution.

Thank you @joshed-io and @mraber !


issue with gamma.fit() and automatic start-values

I've recognized a rather strange behaviour of gamma.fit() with my dataset:
Using the automatically evaluated start-value the fit fails completely....
however, using almost any other start-value the fit works perfectly!
I can't really determine what's happening here and where the issue might come from.
... digging a bit more into the issue, I've realized that using data = data[:65093] causes the fit to perform correctly while data = data[:65094] causes the fit to fail... the additional (single!!) value is 0.0418202979878212 which is not an outlier or so...
I've added my dataset as well as  the code to reproduce the issue:
here's the data: data.zip

Reproducing code example:
import numpy as np
from scipy.stats import gamma
import matplotlib.pyplot as plt

data_path = 'PATH TO data.csv'

data = np.genfromtxt(data_path,
              skip_header=1, usecols=1, delimiter=',')

alpha_start_auto = gamma._fitstart(data)[0]

alpha_starts = [0, 1, 1.2, 1.28, 1.3, 1.5, 2]

f, ax = plt.subplots(figsize=(10,6))
# plot histogram
ax.hist(data, density=True, bins=100, cumulative=False, color='k', alpha=0.25, label='')
ax.hist(data, density=True, bins=100, cumulative=False, color='k', histtype='step', label='')
# store y-limits to avoid stupid plot-limits due to very high values of the fitted pdf
ylimits = ax.get_ylim()

for i, [startvals, label] in enumerate(zip([[]] + [[i] for i in alpha_starts],
                                [rf'automatic $\alpha$ = {alpha_start_auto:.4f}',
                                 *[rf'fixed         $\alpha$ = {i:.4f}' for i in alpha_starts]
                                 ])):

    fit_alpha, fit_loc, fit_scale = gamma.fit(data, *startvals)

    ax.plot(np.linspace(data.min(), data.max(), 1000),
            gamma.pdf(np.linspace(data.min(), data.max(), 1000),
                      fit_alpha, loc=fit_loc, scale=fit_scale),
            label = label + rf'  || FIT:  $\alpha$={fit_alpha:.2f}, loc={fit_loc:.2f}, scale={fit_scale:.2f}',
            lw=len(alpha_starts) + 1 - i)
    # reset y-limits
    ax.set_ylim(ylimits)

Scipy/Numpy/Python version information:
import sys, scipy, numpy; print(scipy.__version__, numpy.__version__, sys.version_info)

1.2.1 1.16.3 sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0)

Thanks for reporting the problem, and for providing a detailed description along with data that can be used to reproduce the problem.  I can reproduce the problem with the master development branch.  I haven't looked into what the cause might be yet, but I agree, it is strange!

Hey, thanks for the reply (and good to know that an upgrade to scipy v 1.3 is not going to solve this...)
If I find some more clues to what's happening here, I'll let you know!

I think the problem is that the data is not actually distributed according to the gamma distribution, and that's just causing the optimizer to choke.
The _fitstart method of gamma is overridden based on the fact that the skewness of a gamma distribution is 2 / sqrt(a): _fitstart chooses a = 4 / (1e-8 + _skew(data)**2) (where the 1e-8 is to deal with degenerate data).
At first, I wondered whether the author of that code made a mistake* (see footnote). For instance, perhaps _skew was not the right function to call. (I get confused about central vs noncentral moments, etc..., in SciPy.) But I generated data for a gamma distribution with known a, and then tried to fit the data, and the formula a = 4 / (1e-8 + _skew(data)**2) was very close to the the value of a from which the data were generated. So I think that code is right.
Here are some observations that suggest that the data are not gamma distributed.
Observation 1:
As you noted, you can successfully fit your data using almost any other guess of a, and it looks like this:

If you measure the skewness of the fitted gamma distribution, or if you generate random data from the fitted distribution and measure the skew, it does not match the skew of your original data:
fit_alpha, fit_loc, fit_scale = gamma.fit(data, 0)
g = gamma(fit_alpha, fit_loc, fit_scale)
data2 = g.rvs(size=len(data))
print(skew(data))
print(skew(data2))
print(g.stats(moments='s'))

1.7674055695288915
0.8464624612202976
0.8417291391291958

So the fit is not really that good.
Observation 2:
I tried fixing alpha to match the skew of your data, and the fit looks pretty bad:
falpha = 4/skew(data)**2
fit_alpha, fit_loc, fit_scale = gamma.fit(data, f0=falpha)
g = gamma(fit_alpha, fit_loc, fit_scale)
x = np.linspace(data.min(), data.max(), 1000)
pdf = g.pdf(x)
ax.plot(x, pdf)
data2 = g.rvs(size=len(data))
print(skew(data))
print(skew(data2))
print(g.stats(moments='s'))

Here's the console output:
1.7674055695288915
1.720015944208805
1.7674055695288915

and here's the plot:

Observation 3:
> len(data)
69120

We should be getting a lot better fit than the plot above if the data is really distributed according to the gamma distribution. If we generate that many data points from the fitted gamma distribution, the histogram (red) matches the fitted distribution much better.

So I don't think we have a SciPy bug here; we're just having trouble forcing a round peg in a square hole. It would be nice if we could guarantee that the optimizer would converge to a reasonable-looking result for arbitrary combinations of distributions and data, but numerical optimization just isn't perfect. In some cases, maybe it's better if it doesn't fit nicely - it might be telling us something about the data!
Thanks for reporting the issue; it was interesting to look into! Do you agree we can close this, or would you like to see some other change to SciPy to address this?

* They did make a small typo: they wrote "The skewness of the gamma distribution is 4 / np.sqrt(a)", but they meant 4 / np.sqrt(a). The code is correct, though.

I agree with @mdhaber; it looks like the default initial guess that is passed to the numerical optimizer just doesn't work for this data set.  For initial guesses near 1.28, the solver appears to end up pushing the loc parameter very close to the lower value of the input data, which means it is probably hitting a lot of cases where the objective function penalty kicks in (i.e . when the loc parameter exceeds the minimum value of the data).
As an experiment, I used the optimizer argument to try a couple different optimizers.  Using fmin_bfgs also failed, but fmin_powell converged.
While we can't guarantee convergence, it would be nice if the method could detect the bad result and raise an exception or warning, and/or provide some additional information that could be used to assess the quality of the result.  @mdhaber and I have talked about this, and something like this might end up in fit eventually.

I'll go ahead and close this since it does not indicate a problem with gamma's fit-start. There are many improvements to be made to fit, but I don't think we need this issue to remind us. Thanks for reporting @raphaelquast, as it is definitely an undesirable behavior, but it's more of a shortcoming of the algorithms than a fixable bug. Please re-open if we've missed something!

I'll go ahead and close this since it does not indicate a problem with gamma's fit-start. There are many improvements to be made to fit, but I don't think we need this issue to remind us. Thanks for reporting @raphaelquast, as it is definitely an undesirable behavior, but it's more of a shortcoming of the algorithms than a fixable bug. Please re-open if we've missed something!

@mdhaber
sorry for not responding in time!  (i was quite busy recently...)
I agree that this does not seem as a real "fixable bug", but it serves well as a worst-case example to remind users to be cautious when trusting automated fit-procedures...
Thank's a lot for having a detailed look into this!

@mdhaber
sorry for not responding in time!  (i was quite busy recently...)
I agree that this does not seem as a real "fixable bug", but it serves well as a worst-case example to remind users to be cautious when trusting automated fit-procedures...
Thank's a lot for having a detailed look into this!


Expose a python_venv_default_packages_file

There is a python-default-packages-file setting allowing to install some common packages when installing a Python version.
However, it is useless if you use virtualenv. I propose adding a python_venv_default_packages_file setting on the same model which would contain a list of packages to install on venv creation.

I'd like to add that it seems the documentation is currently a bit unclear regarding this feature.  I thought for sure I was doing something wrong with setting my MISE_PYTHON_DEFAULT_PACKAGES_FILE environment variable in zsh. I spent far too long thinking this would set up dependencies inside the virtual environment that gets set up in a project, much like many other virtual environment managers that use the requirements.txt file that is common among python projects. I'm glad to see this is a tracked issue.

Sounds like a reasonable idea to me

I feel like the pipx backend is a better solution for this

Not really, and actually pipx purpose is the opposite of this:

pipx provide sandboxed Python tooling. Anything installed with pipx won't be share and accessible in a virtualenv
here, the idea was to be able to install my personal tooling in the current venv

Classical use cases:

I want my prefered tooling (ipython, pudb...) installed
I need some tool installed for my IDE (debugpy)

With pipx, those tools won't be able to use dependencies from the current venv, and vice-versa.
Note that I already use pipx for Python tooling I don't want in the current virtualenv, and I'd like it to remain this way or else it will mess with the virtualenv


useState/for handling onBlur in forms

onBlur show notifications for:
email/username/password required.
reference contact form on react bio page.

code implimented but not functioning correctly. the onBlur func is executing, but not displaying alert text.
maybe change to an overscreen JS alert.


Modbus write_register accept single value and array

Description:
Updated voluptuous schema to accept single value and array. That way the correct function code modbus function code is called (0x06 for integer (single register), 0x10 for list (multiple registers)).
Related issue (if applicable): fixes #
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#8814
Example entry for configuration.yaml (if applicable):

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass
[x] There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.io

@fabaff Just recognised, that this merge creates an exception "(): did not find expected ',' or '}' while parsing a flow mapping at line 12 column 12 ". You can paste the services.yaml into a yaml checker to see the same error. The range needs to be represented differently. "example: 0 or [4,0]}" could be changed to "example: 0 or 4..0}".
I guess a new PR is required?

Sorry, don’t know how I overlooked this. Forgot double quotes, change to example: "0 or [4,0]" will fix this. New PR needed?

Yes, a new PR is needed since this PR is merged.

Ok, just created PR #21923 to fix this.

Using 0.90.0 I have several automations using Input Number's to write to registers. These have all been working fine using @monkey-house multiple modbus hub workaround and @gertdb fix (to write to single values) which became incorporated to 0.90.0 recently.
To make this new inbuilt system work I have modified the automations like:
- id: IrrigationShadehouseSetpoint
  alias: Irrigation Shadehouse Setpoint
  trigger:
    platform: state
    entity_id: input_number.slider3
  action:
    service: modbus.write_register
    data_template:
      hub: hub1
      unit: 3
      address: 3079
      value: "{{ states.input_number.slider3.state|int }}"

Also my config is all up and running now (with no trouble at all for modbus sensors, modbus binary sensors and modbus switches) for multiple modbus hubs using:
modbus:
  - name: hub5
    type: tcp
    host: MyIP
    port: 5003

  - name: hub3
    type: tcp
    host: MyIP
    port: 5001

  - name: hub1
    type: tcp
    host: MyIP
    port: 5002

However I now get this error in my logs when I try to set the register value with input number:
Sat Mar 30 2019 15:58:42 GMT+1000 (Australian Eastern Standard Time)
Error while executing automation automation.irrigation_start_time. Unknown error for call_service at pos 1:
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/components/automation/__init__.py", line 381, in action
    await script_obj.async_run(variables, context)
  File "/usr/src/app/homeassistant/helpers/script.py", line 131, in async_run
    await self._handle_action(action, variables, context)
  File "/usr/src/app/homeassistant/helpers/script.py", line 210, in _handle_action
    action, variables, context)
  File "/usr/src/app/homeassistant/helpers/script.py", line 299, in _async_call_service
    context=context
  File "/usr/src/app/homeassistant/helpers/service.py", line 88, in async_call_from_config
    domain, service_name, service_data, blocking=blocking, context=context)
  File "/usr/src/app/homeassistant/core.py", line 1138, in async_call
    self._execute_service(handler, service_call))
  File "/usr/src/app/homeassistant/core.py", line 1162, in _execute_service
    await self._hass.async_add_executor_job(handler.func, service_call)
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/app/homeassistant/components/modbus/__init__.py", line 149, in write_register
    hub_collect[client_name].write_register(
KeyError: 'default'

Is there something I have missed in my config or automation changes?
Cheers in advance for any help with this problem!

Please open an issue if you suspect a bug. If you need help please use our help channels:
https://home-assistant.io/help/#communication-channels
Merged PRs should not be used for support or bug reports. Thanks!


2nd date is processed from app before fully entered causing 400 on request to api.polygon.io

Hi,
I get the setup running, but when I enter the second date, the app already takes the input when entering the first digit of a year leading to a 400 on the request to api.polygon.io.
Adding a video to reproduce the error.
Br, Lorenz
https://github.com/HusseinJammal/Liquid-Neural-Networks-in-Stock-Market-Prediction/assets/12223628/06cafa24-85ca-4896-8838-8699476adac0

Hello,
It automatically takes the date as you type it in before entering all the digits of the year.
There's a calendar icon inside the box (check the image below). You can select the date for now by clicking on this icon.

Thank you Hussein, this part is working fine now but on "Predict" I`m getting quite some errors.
It could be related to the fact that my version of tensorflow is not the same you used for model training.
Could you indicate which version you are using ?
Traceback (most recent call last):
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\flask\app.py", line 1498, in call
return self.wsgi_app(environ, start_response)
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\flask\app.py", line 1476, in wsgi_app
response = self.handle_exception(e)
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\flask_cors\extension.py", line 178, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\flask\app.py", line 1473, in wsgi_app
response = self.full_dispatch_request()
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\flask\app.py", line 882, in full_dispatch_request
rv = self.handle_user_exception(e)
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\flask_cors\extension.py", line 178, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\flask\app.py", line 880, in full_dispatch_request
rv = self.dispatch_request()
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\flask\app.py", line 865, in dispatch_request
return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)  # type: ignore[no-any-return]
File "C:\Users...\LNN\Liquid-Neural-Networks-in-Stock-Market-Prediction\app.py", line 315, in predict
model = load_model('tesla_best_model_lnn_2 (1).h5')
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\keras\utils\traceback_utils.py", line 67, in error_handler
raise e.with_traceback(filtered_tb) from None
File "C:\Users...\AppData\Local\Programs\Python\Python310\lib\site-packages\keras\optimizers\optimizer_experimental\optimizer.py", line 94, in _process_kwargs
raise TypeError(f"{k} is not a valid argument, kwargs should be empty "
TypeError: weight_decay is not a valid argument, kwargs should be empty  for optimizer_experimental.Optimizer.

I'm using the version 2.11.0

Hi Hussein,
i got it running now with 2.11.0. ;-)
It is also important to set the model_path to an absolute path, so on Windows something like:
model_path = 'C:\users\xxx\Liquid-Neural-Networks-in-Stock-Market-Prediction\tesla_best_model_lnn_2.h5'
Maybe you could update the documentation as I assume that others will run in the same issue.
A last point: could you please share your code you used for the model training, I would like to add other tickers and timeframes, Open to share new models after.
Best regards,
Lorenz


FetchedResultsDataProvider not update a tableview cell if fetchRequest has set sort description

Lets assume I have core data object like:
public class Person: NSManagedObject {
      @nonobjc public class func sortedFetchRequest() -> NSFetchRequest<Person> {
        let fetchRequest: NSFetchRequest<Person> = self.fetchRequest()
        let sortByAge = NSSortDescriptor(key: #keyPath(Person.age), ascending: false)
        fetchRequest.sortDescriptors = [sortByAge]
        return fetchRequest
}

extension Person: NSManagedObject {
    @nonobjc public class func fetchRequest() -> NSFetchRequest<Person> {
        return NSFetchRequest<Person>(entityName: "Person")
    }

  @NSManaged public var name: String?
  @NSManaged public var ega: Int16
}

and I use Person.sortedFetchRequest() in FetchedResultsDataProvider. Then I update two  properties(name & age) in one object and save it in NSManagedObjectContext.  The NSFetchedResultsControllerDelegate will call
public func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChange anObject: Any,
                           at indexPath: IndexPath?, for type: NSFetchedResultsChangeType, newIndexPath: IndexPath?) { .

from FetchedResultsDataProvider only once, with type move. In this situation there is missing action  update. So the result of this situation is that tableview of person objects are good sorted but with one invalid data cell.

Hey. Thanks for bringing this up with this level of detail.
We could create an implicit ‚update‘ with a move. This could fix the issue.
If you like you could create a Pull Request with an implementation

Thanks @pkalinowski, we had that issue too and we used reloadRowsAtIndexPaths for visible cells as temporary fix. If that helps for now.
https://developer.apple.com/documentation/uikit/uitableview/1614935-reloadrowsatindexpaths?language=objc

But ideally, we call update at sourcing before move.

Was this fixed? :)

Not yet, I will make fix in this week.

Great thanks! @pkalinowski

sorry, for late - today will push fix with tests

Don´t hurry. Take you time to get to a great solution.

I have tested the fix, update seems ok but insert and delete is throwing the same core data errors.

CoreData: error: Serious application error.  An exception was caught from the delegate of NSFetchedResultsController during a call to -controllerDidChangeContent:.  attempt to perform an insert and a move to the same index path (<NSIndexPath: 0xc000000000000016> {length = 2, path = 0 - 0}) with userInfo (null)

down with #51


Cannot find user defined WIQL query

Azure DevOps Extensions
Generate Release Notes (Node Cross Platform)
Platform
Azure DevOps Services
Azure DevOps Server (TFS) Version
No response
Extension Version
4.17.12
Describe the bug
When I fill in the wiqlSharedQueryName for a shared query the generator is not able to find that query;
Getting Work Items using user defined WIQL query '/Shared Queries/Release X'
Cannot find user defined WIQL query '/Shared Queries/Release X'

Repo Steps

Set Pipeline steps

steps:
- task: XplatGenerateReleaseNotes@4
  inputs:
    outputfile: '$(Build.ArtifactStagingDirectory)/releasenotes.html'
    templateLocation: 'InLine'
    inlinetemplate: |

Features in release ({{queryWorkItems.length}})

      {{#forEach queryWorkItems}}

          {{this.id}} {{lookup this.fields 'System.WorkItemType'}}: {{lookup this.fields 'System.Title'}}

          {{lookup this.fields 'System.State'}} | {{lookup this.fields 'System.AreaPath'}}

      {{/forEach}}

    dumpPayloadToConsole: false
    dumpPayloadToFile: True
    replaceFile: True
    getParentsAndChildren: false
    getAllParents: True
    getIndirectPullRequests: False
    stopOnError: False
    considerPartiallySuccessfulReleases: False
    checkForManuallyLinkedWI: False
    getPRDetails: false
    getTestedBy: false
    wiqlSharedQueryName: "Release X"

- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    publishLocation: 'pipeline'

Run pipeline
Check logs

Expected Behavior
Queries are loaded from shared query
Logging Information
No response

Have a look at #1872 , the issue is usually permission related i.e. the build service does not by default have permissions to see the shared queries

That was indeed the case, may I advise to put this next to the documentation for wiqlSharedQueryName


Title: Translate Extension

Is your feature request related to a problem? Please describe.
The main goal of this project is to leran about the web service call
Describe the solution you'd like.
This extension calls a web service that translates a language
Describe alternatives you've considered.

Add any other context or screenshots about the feature request here.
No response

@praniti111 The PR is made #230  . Kindly review and merge it.
Thank You


[BUG]: Page "Module Index" on arneis.readthedocs.io is broken

Description of the bug
I spotted at least one broken link on the site https://arneis.readthedocs.io/ generated by ReadTheDocs

Steps To Reproduce

Go to https://arneis.readthedocs.io/en/latest/index.html#
Click on the "Module Index" link

Expected Result
Something relevant
Actual Result
Page https://arneis.readthedocs.io/en/latest/py-modindex.html is displayed:

Additional Information
No response

Hey @gmacario I would really like to fix it. Can I?

Hey @gmacario I would really like to fix it. Can I?

Of course! Feel free to contribute as much as you want 😄

Thanks @gteti I will do it!

Hey @gmacario Which link you want here in module index? Can you please give me that link.

Hey @gmacario I would really like to fix it. Can I?

Hello @NaincyKumariKnoldus,
Sorry for my late reply, and nice to meet you!
I am very excited that you want to contribute to the ARNEIS project.

Hey @gmacario I would really like to fix it. Can I?

Sure you can 😄. Let me provide you with some more context first.
As you can see, the generated documention for the ARNEIS project (i.e. https://arneis.readthedocs.io/) is a task which is still at a very early stage. I have been leveraging the excellent infrastructure provided by https://readthedocs.org/ and the Open Source Sphinx project.
More specifically I created the website using the sphinx-quickstart tool - you can look at this HOWTO for the full story.
More specifically, the "Module Index" link on the landing page is caused by the following line in docs/index.rst
* :ref:`modindex`

I am still a beginner with ReadTheDocs therefore I do not yet know if the module should be configured, or simply removed.
@NaincyKumariKnoldus do you know ReadTheDocs or want to have a look at it? I will appreciate.

@NaincyKumariKnoldus do you plan to look at this during this week?
Otherwise I will postpone the resolution to a future milestone

yes @gmacario I will look at this.

No updates received so far, postponing to next sprint

@NaincyKumariKnoldus since I did not see updates on this bug I applied a quick-and-dirty workaround with #168.
Please feel free to improve it, or look after other unassigned open issues in ARNEIS backlog. Thanks!


subsys: net: net_mgmt: fixed typo in doxygen

The subsys:  still needs to be dropped from the git subject.


Added mentions to fixed and slash menu

Fixes #118

Added mentions to slash menu.
Added mentions to the fixed menu as a dropdown.

Demo: https://vimeo.com/660657942/b70f931315
@labeebklatif _a please review.
cc: @goutham-subramanyam

@AbhayVAshokan @amaldinesh7 @karthiknmenon Just want to know your opinion on https://www.loom.com/share/62d72ef5cc50416e985ab1dc7493624c
Not sure if this change was intentionally done. Let me know

@AbhayVAshokan @amaldinesh7 @karthiknmenon Just want to know your opinion on https://www.loom.com/share/62d72ef5cc50416e985ab1dc7493624c
Not sure if this change was intentionally done. Let me know

@labeebklatif please have a look https://vimeo.com/661231570/bcbbfb1212
cc: @karthiknmenon, @amaldinesh7

@labeebklatif _a please review the new changes.

@labeebklatif _a please review the new changes.

@goutham-subramanyam _a Changes LGTM. Please review the UI and merge.


Docstrings needed for L.Marker.getElement

Checklist

[X] I've searched through the current issues to make sure this change hasn't been suggested already.
[X] I agree to follow the Code of Conduct that this project adheres to.

Which documents need updating?
reference.html
Motivation
I was looking at #9178, and had to look at the JS code to see how to get a reference to the HTMLElement of a L.Marker.
Suggested changes
The getElement() method of L.Marker needs docstrings.
The docstrings for the getElement() method of L.ImageOverlay can serve as a starting point.

Hello. Can I still contribute to this issue?


SageMaker FML: Fix Build Path & add integ test dependency

Description
Brief description of what this PR is about

If this change is a backward incompatible change, why must this change be made?
Interesting edge cases to note here

Validated the container builds locally now for py311


Looking for a way to comb through organization CloudTrail

Linking the previous issue as well: https://github.com/duo-labs/cloudtracker/issues/46

Closing as duplicate of the linked issue. I don't see how this differs.


add thumbv8m baseline

bors r+

@evq I don't know what the status of thumbv8m as a target in Rust is but we once that is rolling we need to add it to CI.

I have a PR open to add the baseline target - which is blocked on another PR for a cargo change:
https://github.com/rust-lang/rust/pull/55041

@evq Maybe open tickets so we don't forget?

@evq Hm, you used a different toolchain to build this it seems.

+diff -u bin/thumbv8m.base-none-eabi.after bin/thumbv8m.base-none-eabi.before
--- bin/thumbv8m.base-none-eabi.after	2018-11-03 23:01:03.168136948 +0000
+++ bin/thumbv8m.base-none-eabi.before	2018-11-03 23:01:03.120136241 +0000
@@ -3,8 +3,8 @@
 cortex-m-rt.o:     file format elf32-littlearm

-Disassembly of section .HardFault:
+Disassembly of section .text.HardFault:

 00000000 <HardFault>:
    0:	f3ef 8008 	mrs	r0, MSP
-   4:	e7fe      	b.n	0 <UserHardFault>
+   4:	f7ff fffe 	bl	0 <UserHardFault>

Ah, I'm using arm-none-eabi-binutils-2.31.1-1 on Arch

Looks like the version installed in ci/install.sh is slightly older?
GNU assembler (GNU Tools for Arm Embedded Processors 7-2018-q2-update) <IP_ADDRESS>80329

I guess more important is the question: Which one is the better version.

+   4:	f7ff fffe 	bl	0 <UserHardFault>

I think this is correct - right?
Since asm.s uses the bl instruction:
  .section .text.HardFault
  .global HardFault
  .thumb_func
HardFault:
  mrs r0, MSP
  bl UserHardFault

The ARMv8-M architecture reference manual seems to indicate that the bl instruction has two 16-bit components - which seems to match

You might not have an up to date master - asm.s recently (a week ago)
changed to use b instead of bl.

aha, thanks @adamgreig, that'll do it! :)

bors r+


✨ Access to Bedrock - AI for Linked Data Projects

Describe the feature request.
Similar to this issue for the AI for Linked Data team. We would like access to Bedrock.
Describe the context.
We have a number of projects for which access to Bedrock would be helpful.

Extracting structured information on whether prisoners are in a drug recovery programme.
Extracting structured information on the number of children a prisoner has.
Generating summaries for use in pre-sentence reports.

Value / Purpose
Allow us to complete the above projects as they require LLM access.
User Types
BOLD Data Scientists

Could I request access for the following users:

@bcrawford-moj
@carolinetudor
@yznlp
@DaoudC
@wmartin-gss

Hiya, what models are you looking to use?
Additionally, are you planning to use data help in AP for this or openly available?

For this ticket probably thinking Claude. We were planning on comparing what we can do with Bedrock and Claude compared to open models on gpu enabled by this ticket. It would be useful for us to compare the ease of and performance of Bedrock with a closed model set up, compared to the flexibility (e.g. finetuned models, further fine tuning) of the open model + gpu set up.

@bcrawford-moj Are you planning to use AP data or open source data? This determines where we set you up with Bedrock access.

AP data

AP will onboard the request user/s.

@bcrawford - moj please raise a support ticket for the onboarding of the user/s.

The users already have AP accounts or are you saying I have to raise a ticket somewhere else for onboarding to Bedrock?

Bedrock

:D It's not a feature request. It's all good, I'll onboard you but I am just letting you know that the other project we've done this with had to raise a DPIA to cover the usage of their data outside the Ireland region. Bedrock is only available in Frankfurt and Paris at present. I'll post a comment here when you've been set up.

Thanks! For future reference, which issue type should I use for things like this?

Hiya, you're all enabled. Now that we offer this service, even if it's limited, it's a support request.


monit should ping to slack before giving up on DJ

In one of the projects soon we are going to have large number of 100+ DJ instances. Sometimes monit gives up on a DJ instance and we are not notified of it. Because of DJ dying now that client does not get any background job processing done.
Any time monit gives up on any process monit should ping on slack.
//cc @ershad @vipulnsward @rkr090
@RahulMahale _a

Bumped up the priority. We need a solution in 1 to 2 weeks.

@ershad Where are we with this ?

@RahulMahale I moved to other priority issues in between. Would you like to take this up? cc: @neerajdotname

@ershad I can pick it up, will look into it

@neerajdotname @ershad I need slack channel webhook to test monit alerts, is it ok if I use  existing webhook from #internal-project Channel ?

@RahulMahale sure

@RahulMahale _a this is already implemented, right? If yes, please close this issue.

Yes this feature has been pushed in https://github.com/bigbinary/boxy-rails/pull/22


Cancel a Subscription?

How do you go about canceling a subscription?

This issue tracker is not for support requests, as mentioned in the README. Sorry!


change response for approvals according to apiary

change response for approvals according to apiary

client_name was added to response
filter by client_name

request
curl -X GET \
  'https://api.dev.asclepius.com.ua/api/admin/apps?client_names=%D0%90%D0%BF%D1%82%D0%B5%D0%BA%D0%B0%20%D0%94%D0%BE%D0%B1%D1%80%D0%BE%D0%B3%D0%BE%20%D0%94%D0%BD%D1%8F' \
  -H 'Authorization: Bearer d3l3TUxjbkgxNmJxZHdCY0MzOFAzZz09' \
  -H 'Cache-Control: no-cache' \
  -H 'Postman-Token: c7b0afc2-1c90-4146-90c6-42dc44b5d1c0'

response
{"meta":{"url":"http://api-svc.mithril/admin/apps","type":"object","request_id":"c75758e9-3788-41c1-bd01-d324d8c2a0fb#25880","code":500},"error":{"errors":{"detail":"Internal server error"}}}

[ ] filters do not work.
Example,  request one client_id
expected result - only one app in response
actual result - full list of apps in response
request

curl -X GET \
  'https://api.dev.asclepius.com.ua/api/admin/apps?client_ids=e38f2528-0bd5-4aa8-bb22-adb1558e5758' \
  -H 'Authorization: Bearer L1U2b2g1QUE1ZjJPRXlndUlBQVh2dz09' \
  -H 'Cache-Control: no-cache' \
  -H 'Postman-Token: 05267f70-24a1-4858-8bd4-82d6919b7365'

response
{
    "meta": {
        "url": "http://api-svc.il/admin/apps",
        "type": "list",
        "request_id": "69ac5e41-d124-4a81-b7d3-ddd166b50046#4005",
        "code": 200
    },
    "data": [
        {
            "user_id": "d8ab18b3-25d1-46f0-aabd-88867158850c",
            "updated_at": "2018-08-03T07:14:51.239632",
            "scope": "cabinet:read employee_request:approve employee_request:reject user:request_factor user:approve_factor user:change_password app:authorize declaration_request:write declaration_request:read declaration_request:terminate declaration:read person:read person:write declaration:terminate app:read app:write app:delete",
            "id": "493b7458-2cdf-45e0-8f5f-367d7a67f896",
            "created_at": "2018-08-03T07:14:51.239620",
            "client_name": "Кабінет",
            "client_id": "30074b6e-fbab-4dc1-9d37-88c21dab1847"
        },
        {
            "user_id": "d8ab18b3-25d1-46f0-aabd-88867158850c",
            "updated_at": "2018-08-10T11:12:46.953816",
            "scope": "cabinet:read employee_request:approve employee_request:reject user:request_factor user:approve_factor user:change_password app:authorize declaration_request:write declaration_request:read declaration_request:terminate declaration:read person:read person:write declaration:terminate app:read app:write app:delete",
            "id": "bd87a548-4163-4752-9b71-e15b8045d56c",
            "created_at": "2018-08-10T11:12:46.953802",
            "client_name": "Кабінет (Local)",
            "client_id": "e38f2528-0bd5-4aa8-bb22-adb1558e5758"
        }
    ]
}

@svetavedmed  header x-consumer-id required

according to apiary prefix 'client-' should be added
{"meta":{"url":"http://api-svc.il/admin/apps","type":"list","request_id":"69ac5e41-d124-4a81-b7d3-ddd166b50046#5315","code":200},"data":[{"user_id":"8341b7d6-f9c7-472a-960c-7da953cc4ea4","updated_at":"2018-08-06T08:40:56.048104","scope":"address:read address:write","id":"6d0cc6a5-4702-43e7-be00-7ee7217e36d5","created_at":"2018-08-06T08:40:56.048095","client_name":"eHealth Local UAddresses Admin","client_id":"0423bab7-4aa0-475f-a6a8-46738524eaf7"}]}edenlabs-MacBook-Pro:mithril.api edenlab$
edenlabs-MacBook-Pro:mithril.api edenlab$

[ ] error 500 with wrong client_id
request

curl -X GET \
  'https://api.dev.asclepius.com.ua/api/admin/apps?client_ids=client-30074b6e-fbab-4dc1-9d37-88c21dab1847ff' \
  -H 'Authorization: Bearer MmhSL2kxVDZYQndkQ0JIRGR0Q1JZdz09' \
  -H 'Cache-Control: no-cache' \
  -H 'Postman-Token: 6c6c5579-7515-4042-a452-065bb638eee7'

response
{
    "meta": {
        "url": "http://api-svc.il/admin/apps",
        "type": "object",
        "request_id": "69ac5e41-d124-4a81-b7d3-ddd166b50046#8074",
        "code": 500
    },
    "error": {
        "errors": {
            "detail": "Internal server error"
        }
    }
}

[ ] filter by user_ids does not work

user_id should be taken from headers
@AlekzandrV  please update apiary

apiary updated


Default nullness of type parameter bound in defaulted context (working decision: non-nullable)

[update: direct link to doc about this issue]
In the document, it's been said about @DefaultNotNull:

This annotation establishes defaults for unannotated method parameters etc. in the annotated package or class/interface (but not sub-packages or subtypes) and matches CF’s defaults except for declarations of type variables without explicit bounds, which default to non-null in this proposal

Does it mean that generic (type) parameters have not-null bounds independently of the presence of @DefaultNotNull somewhere in the scope or have I just misread the statement?

I've moved discussion of this issue into an editable document. It's a bit alarming that this one issue fills six pages, but well, at least it's organized/skimmable.
We invite review, comments, and even edits by all.
https://docs.google.com/document/d/1mD_wvJLiSvg7YOLcVTqZh303XktqO-S4vzQEgx-Gnts/edit

We'll need more scrutiny of this doc before we ever make a final decision, but at this time we are closing issues when we have a "working decision", and I am very confident we've met the bar for that.  The implicitly-bounded <T> will have an upper bound of non-nullable T.
There is no need to stop making/suggesting edits to the document just because this issue is currently closed, and at some point it could even become clear we need to rethink it.

Current decision: T's upper bound is non-nullable in @NullMarked class Foo<T> and in @NullMarked class Foo<T extends Object>. (Those are identical in bytecode.) Object is not treated specially when it is a type parameter's upper bound.
Argument for changing: A bare, apparently unbounded type parameter has always meant effectively unbounded, and with the current decision that's no longer the case. Now to get an actually unbounded type parameter you have to do @NullMarked class Foo<T extends @Nullable Object>. That is awkward and is surprising. It is important to maintain the status quo that a plain type parameter is unbounded. In addition, IDEs like Eclipse have UIs that allow users to augment third-party code with extra annotations. In the case of <T>, there is no visible upper bound to annotate, and users will often want to annotate that upper bound.
However, if users have assumed that a plain type parameter always means it is unbounded, that has never even included nullness, so it's hard to say that introducing nullness will violate their assumption that those parameters can accomodate nullable types.
Since class Foo<T> and class Foo<T extends Object> are identical in bytecode, making this change would require JSpecify to treat even type parameters explicitly bounded by Object specially.
That would mean that unlike any other type parameter bound, <T extends Object> would have a nullable bound; you would have to do <T extends @NonNull Object> to get a non-null bound. That would also make JSpecify treat Object type usages differently when they appear as a type parameter bound, compared to all their other appearances.
Treating Object type parameter bounds specially (compared with other type parameter bounds and other type usages of Object) means this proposal complicates the JSpecify nullness model a lot, in a way that will affect lots of users. It will have to be carefully documented in the Javadoc, the specification, and other user documentation.
On the other hand, documenting the fact that plain type parameters are bounded by non-null Object is simpler, especially because it follows from the basic model of nullness.
The benefits of this special case are outweighed by the complexity costs.
Timing: This must be decided before version 1.0 of the jar.
Proposal for 1.0: Finalize the current decision. If you agree, please add a thumbs-up emoji (👍) to this comment. If you disagree, please add a thumbs-down emoji (👎) to this comment and briefly explain your disagreement. Please only add a thumbs-down if you feel you can make a strong case why this decision will be materially worse for users or tool providers than an alternative.


no zip data registered

whats wrong with that?

And whats happening here?

You are expected to import the generated statik package to register zip data or call https://godoc.org/github.com/rakyll/statik/fs#Register to manually do it. If you are not registering any zip data, it will complain.
What's the use case for importing this package and not registering no data?

@mehmetkose you need to import the generated package and the init will do the trick:
import 	_ "github.com/your/package/route/statik"

@mehmetkose you need to import the generated package and the init will do the trick:
import _ "github.com/your/package/route/statik"

Thank you


Like totes got all refactory on ALL THE SPECS. They run at least 10% faster now.

Thanks tons man.  @robyurkowski called it :)  I don't get that failure locally or on my jenkins box but it seems prevalent on travis so have to figure that guy out.


Rename Auto Import to Repo Auto Import

Anywhere we talk about "auto imports" make sure we convey it's "repo auto imports"

handled in: https://github.com/mergestat/fuse/pull/263


Grid/Boundary selection UI enhancement

Addresses https://github.com/kartoza/rezoning-2-project/issues/5
Made the grid type and size selection UI work in the same way the country and resource selection is done.
UI changes demo:
Screencast from 21 ديسمبر, 2022 CET 02:19:32 م.webm

perfect!


Bot Not Building

I tried to run mix hedwig.gen.robot and kept receiving an error that SenderInfo struct couldn't be found. I had to change "alias ExIrc.SenderInfo" to "alias ExIRC.SenderInfo" in hedwig_irc.ex. I'm not sure if this was my compiler having problems or if it was a dependency issue.

Fixed in ba40c67


types\optional_test.cc compilation issue with Visual Studio 2017 (v15.8)

Description
When trying to do a CMake-based build with test of abseil-cpp, I got an compile error on
types\optional_test.cc
note: I've applied the PR #194 (absl::container similar issue?) and #196 (alignment conformance) and PR #197 (CI cmake jobs)
optional_test.cc
  Building Custom Rule C:/projects/abseil-cpp/absl/debugging/CMakeLists.txt
  exception_safety_testing.cc
  CMake does not need to re-run because C:/projects/abseil-cpp/build/absl/debugging/CMakeFiles/generate.stamp is up-to-date.
c:\projects\abseil-cpp\absl\types\optional_test.cc(1108): fatal error C1001: An internal error has occurred in the compiler. [C:\projects\abseil-cpp\build\absl\types\optional_test_bin.vcxproj]
  (compiler file 'msc1.cpp', line 1518)
   To work around this problem, try simplifying or changing the program near the locations listed above.
  Please choose the Technical Support command on the Visual C++
   Help menu, or open the Technical Support help file for more information
  Internal Compiler Error in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe.  You will be prompted to send an error report to Microsoft later.

Full Appveyor-CI log line 708:
https://ci.appveyor.com/project/Mizux/abseil-cpp/builds/19632736/job/thal0yvy6dacd9e0
The code optional_test.cc in the error log:
https://github.com/abseil/abseil-cpp/blob/2019e17a520575ab365b2b5134d71068182c70b8/absl/types/optional_test.cc#L990-L1058

I'm currently working through all of our MSVC bugs.  I'll add this to the list :)


fcitx5-configtool propagates some packages

Describe the bug
fcitx5-configtool is installed by default when fcitx5 is used. It propagates some packages, e.g. kwallet and cups, which pollutes the user environment, because it uses kdePackages.callPackage.
https://github.com/NixOS/nixpkgs/blob/9d1b71582777cf400aef1bc08645ad024d45e77e/pkgs/top-level/qt6-packages.nix#L40
Steps To Reproduce
Steps to reproduce the behavior:

Add qt6Packages.fcitx5-configtool to systemPackages or set

i18n = {
  inputMethod = {
    enable = true;
    type = "fcitx5";
  };
};

The icon of cups shows up in the launcher
Or check nix-support/propagated-user-env-packages in qt6Packages.fcitx5-configtool directly

Expected behavior
Unrelated packages should not be added to user environment. This is the point of NixOS.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.
Notify maintainers

@NickCao @NixOS/qt-kde
Metadata

Add a :+1: reaction to issues you find important.

This is a problem with a lot of packages (talking about cups specifically):
› nix why-depends .\#nixosConfigurations.hp-laptop.config.system.build.toplevel n\#cups.out --all
/nix/store/d36yjcvhimwk16iiv99rbxjzfsm9v1bb-nixos-system-hp-laptop-24.11.20241105.4aa3656
├───/nix/store/ic0jcj434wilb2bn9j12nzmngi3cvkph-system-path
│   ├───/nix/store/3mfk8bbdm218328q4m8ldfdkir4s6969-cups-2.4.11
│   ├───/nix/store/qwzscsi3s9qvdhkm1vrwsr9jk3xahdcb-telegram-desktop-5.7.1
│   │   ├───/nix/store/3mfk8bbdm218328q4m8ldfdkir4s6969-cups-2.4.11
│   │   └───/nix/store/wjp3g6rvjz80llsgnampyggxrij32s4p-kcoreaddons-6.7.0
│   │       └───/nix/store/3mfk8bbdm218328q4m8ldfdkir4s6969-cups-2.4.11
│   ├───/nix/store/bb159ix8681aipiqcf2njacf8gkn0hnp-chromium-130.0.6723.91
│   │   ├───/nix/store/6ai2r568mgh6ckv7dnwh0rjj6plag199-chromium-130.0.6723.91
│   │   │   └───/nix/store/3mfk8bbdm218328q4m8ldfdkir4s6969-cups-2.4.11
│   │   └───/nix/store/i08nq7diqm66fmai3xd069cr02w7iqsa-chromium
│   │       └───/nix/store/6ai2r568mgh6ckv7dnwh0rjj6plag199-chromium-130.0.6723.91
│   ├───/nix/store/pgdngdv9g5s2ggday3v6cs3rmw0szpgw-inkscape-1.3.2
│   │   └───/nix/store/00k65b5bmwji0q799jq6nc4drhww1ij2-ghostscript-with-X-10.04.0
│   │       └───/nix/store/3mfk8bbdm218328q4m8ldfdkir4s6969-cups-2.4.11
│   ├───/nix/store/rcn8zfr3a4dvlcpx3nha9w655lmc3v1w-krita-5.2.6
│   │   ├───/nix/store/d4z62aw36hd27aibmll18khkrs0gj02k-kded-5.116.0
│   │   │   └───/nix/store/3mfk8bbdm218328q4m8ldfdkir4s6969-cups-2.4.11
│   │   ├───/nix/store/6pbdsihmmbrzy5rsslkdqjv326zk0h73-krita-unwrapped-5.2.6
│   │   │   ├───/nix/store/d4z62aw36hd27aibmll18khkrs0gj02k-kded-5.116.0
│   │   │   └───/nix/store/mlzv1m48nrwziq7a2lprcjilyxlyksax-kio-5.116.0
│   │   │       └───/nix/store/d4z62aw36hd27aibmll18khkrs0gj02k-kded-5.116.0
│   │   ├───/nix/store/mlzv1m48nrwziq7a2lprcjilyxlyksax-kio-5.116.0
│   │   └───/nix/store/xihx28ca7lcldngbh4vlks5rz60pqz2j-krita-plugin-gmic-<IP_ADDRESS>
│   │       └───/nix/store/6pbdsihmmbrzy5rsslkdqjv326zk0h73-krita-unwrapped-5.2.6
│   ├───/nix/store/azqnhf0z40clwwgbhh8w5w9k7k1l0rlf-keepassxc-2.7.9
│   │   └───/nix/store/mlzv1m48nrwziq7a2lprcjilyxlyksax-kio-5.116.0
│   └───/nix/store/bknmmbfb5cbqr5z786k4qnpljp8m1kif-zathura-with-plugins-0.5.8
│       └───/nix/store/m47gvlyxgc5fay0wj66rl74vjayln417-zathura-ps-0.2.8
│           └───/nix/store/srnfqvhc68hyhrmbcxsfj6qrflhlyzic-libspectre-0.2.12
│               └───/nix/store/00k65b5bmwji0q799jq6nc4drhww1ij2-ghostscript-with-X-10.04.0

› cat /nix/store/qwzscsi3s9qvdhkm1vrwsr9jk3xahdcb-telegram-desktop-5.7.1/nix-support/propagated-user-env-
packages
/nix/store/ii86djqx6kb39qqhzsbwd5hmqf276xzz-dbus-1.14.10 /nix/store/7bvzsk07az1d9hnpy9d5cpvnizbzmdcd-systemd-256.7 /nix/store/3mfk8bbdm218328q4m8ldfdkir4s6969-cups-2.4.11 %

As you can see adding any of the following will install cups globally: Telegram, Inkscape, Zathura, Krita, Chromium, Keepassxc.
Especially seems weird to see this with the recent vulnerabilities in cups.
Title needs to be adjusted, seems like a major problem.

This has nothing to do with kdePackages.callPackage, and everything to do with the extra-cmake-modules hook. This is intentional, it will propagate everything that exposes a dbus service because the application may want to activate it.

I do not want the application to activate cups on my computer. I don’t use it to print stuff and cups exposes an attack surface. I feel like automatically installing cups with every application that is potentially capable of printing is very much a misfeature.

I’ve done some (pretty painful, git bisect is not great with this amount of merge commits) bisecting, and I think 6111416de7983c0918bb953778d226c71e4ae72c is a relevant commit here. Since this commit, kdePackages.breeze-icons contains cups in propagated-user-env-packages, which I hope we can agree shouldn’t happen.
(kdePackages.breeze-icons propagated dbus and systemd even before this commit, but at least dbus and systemd are generally likely to be already installed).

https://github.com/NixOS/nixpkgs/blob/edaa7ce8cf995e86302f0d029361303ab863c7da/pkgs/kde/frameworks/extra-cmake-modules/ecm-hook.sh#L110
https://github.com/NixOS/nixpkgs/blob/edaa7ce8cf995e86302f0d029361303ab863c7da/pkgs/development/libraries/kde-frameworks/extra-cmake-modules/setup-hook.sh#L114
Not sure why there are two extra-cmake-modules but both propagate dbus packages.

I'm open to removing that hack for 25.05, but we'll need to actually investigate the impact.

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/manage-printers-in-applications-list-while-cups-disabled/55909/2


Headers & Hashtags

Correct Syntax Header
to string #my-hash-tag bootstrap-markdown generate header tag. It's wrong.
For example correct behavior you can see here on GitHub
#my-hash-tag
#my-hash-tag
# my-hash-tag
my-hash-tag

hash-tag

kj

this is your parser's issue.


Updating children props dynamically ignores "0"

I have a Parent component, that takes children components. I want to dynamically add props to each children so I’m adding “index” in a loop. Every child element is supposed to have attributes "index=0", "index=1" and so on. But the generated DOM's 1st element doesn’t have the attribute "index=0" while the rest of them have "index=1", "index=2" and so on.
Below codepen reproduces the issue:
https://codepen.io/rajaraodv/pen/aLPWgd

raja
    <-- notice that the 1st element is missing index="0"

 rao

A solution could be in setElementProp, instead of evaluating value, that fails is value is falsy, we could test value != null:
if (typeof value !== "function") {
  if (value != null) {
    element.setAttribute(name, value)
  } else {
    element.removeAttribute(name)
  }
}

So, falsy values will not result in calling removeAttribute, but is it correct? Don't we want to call removeAttribute for falsy values? 🤔
/cc @rajaraodv @zaceno @okwolf

I'd remove them explicitly for undefined (===), not even null.
null, 0 and false are falsy but are values explicitly assigned by a programmer. undefined means that something either wasn't touched by a developer or was explicitly changed back to "nothing" -- which is the behavior we're looking for here.

Thanks @lazarljubenovic. While I wouldn't encourage != null if you I can avoid it (and one can totally avoid it in 99.99% of situations), in this case is fine because we are (in addition to want to save bytes 😉) giving you the ability to set any property as null  as a way to tell Hyperapp to remove it. This also fixes @rajaraodv's bug.

Come to think about I am only worried about empty strings. Does it make sense to remove attributes when set to an empty string? (current behavior) or should we simply:  setAttribute(name, value) even if value is an empty string?

@JorgeBucaran checked, selected, etc.

@JorgeBucaran I mean attributes like checked, selected, etc would never get removed.

@infinnie Ah, yes, you are right.

@infinnie @lazarljubenovic @rajaraodv So, we want to remove attributes for falsies, except "". Does that sound good?

Why remove any attribute at all unless undefined?

@rajaraodv for example: h('button', {disabled: true}, [...]) should render into <button disabled>...</button>. So what should h('button', {disabled: false}, [...]) render into, if not <button>...</button>?

So what should h('button', {disabled: false}, [...]) render into?

It should render into: <button disabled="false">test</button>. Because disabled=false is treated by HTML as disabled. If you want to enable it, then you the attribute shouldn't send that parameter at all to the VDOM.

I agree with @rajaraodv it seems to make the most sense to only remove if the attribute is undefined, otherwise you have those weird cases if you happen to want an attribute set to 0/false/""/null.

I vote for removing attributes that are null or undefined.  I think those are the most intuitive values to set for removing an attribute.

@rajaraodv Then, by the same token, h('button', {disabled: true}, [...]) should become <button disabled="true">...</button> right?
What should we write in order to achieve <button disabled>...</button> (valueless attribute)?

@rajarodv

Because disabled=false is treated by HTML as disabled

... is this true in all browsers? What about selected="foo" -- is that treated as selected (in an <option> tag?

So if I understand the suggestion from @rajaraodv, @andyrj and @SkaterDad, then where I previously may have written
h('input', {
  type: 'submit',
  value: 'Submit',
  disabled: isFormBusy || !isFormValid
})

I should now write:
h('input', {
  type: 'submit',
  value: 'Submit',
  disabled: (isFormBusy || !isFormValid) ? 'disabled' : undefined
})

I guess it's reasonable. But I don't really have a problem with special handling of explicit boolean (not "booleany") values for "valueless attributes". In fact I kind of prefer it as it makes the code less noisy.

As per w3c every attribute has value. If you don't set one, it's set to "" and assumed to be true.

Note:
A boolean attribute without a value assigned to it (e.g. checked) is implicitly equivalent to one that has the empty string assigned to it (i.e. checked=""). As a consequence, it represents the true value.
Note:
The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

So when you pass h('button', {disabled: true}, [...]), ideally, Hyperapp should generate: <button disabled>...</button> or <button disabled="">...</button>. But I think most browsers ignore that w3c standard of not allowing "true" or "false". So generating  <button disabled="true">...</button>, while not ideal, is also fine.
If we pass h('button', {disabled: "something"}, [...]), it should generate: <button disabled="something">. This will also result in a disabled button.
If we pass h('button', {disabled:0}, [...]), then I think we should generate :  <button disabled="0">..will also result in a disabled button.
But when you pass h('button', {disabled: false}, [...]), Hyperapp should generate: <button>...</button> because any other value will be considered as true. We can add functionality where h('button', {disabled: null}, [...]) or h('button', {disabled: undefined}, [...])  will also result in removing that attribute.

@rajaraodv

But when you pass h('button', {disabled: false}, [...]), Hyperapp should generate: <button>...</button> because any other value will be considered as true

Oh, I misunderstood you then. I thought you wanted disabled: false to result in <button disabled="false">..</button> -- which of course would be the opposite of the programmer's intent. (Because the button would be disabled)
I'm also with you on the null and undefined -- they should be treated the same as false. I also thing "" should be removed, but not 0.

Oh, I misunderstood you then. I thought you wanted disabled: false to result in .. -- which of course would be the opposite of the programmer's intent. (Because the button would be disabled)

@zaceno I am edited my earlier comment. You are correct in your original understanding that I actually want <button disabled="false">..</button> when  h('button', {disabled: false}, [...]) is passed. Sorry for the confusion.
But people should be aware that 'null' or 'undefined' is what they should send if they want to remove that attribute Everything else will resulting in button being disabled.

@rajaraodv Ah, ok -- good we understand eachother at least. 😅 Anyhow I'm still on the side that explicit false attributes should be removed.
If, for whatever reason a programmer wants <x disabled="false">... they can set {disabled: "false"}

But people should be aware that only 'null' or 'undefined' is what they should send if they want to remove that attribute. Everything else will resulting in button being disabled.

The way I see it, this is one of those things where it won't matter how much we document this -- everyone will make this mistake. It's so natural to expect {disabled: false} means "not disabled". I see no reason not to go along with that.

@rajaraodv Ah, ok -- good we understand eachother at least. 😅 Anyhow I'm still on the side that explicit false attributes should be removed.
You are right. I just checked how React does this and they use explicit false  to removes the attribute.

Great summary I think there @zaceno
false - remove
undefined - remove
null - remove
"" - remove
0 - set as string value

Using an empty string "" as a remove signal might not work as expected for input.value.

@thysultan that's a good point!
Maybe it's best to just leave string values as is, empty or not.
So:

typeof attrVal === 'string' - leave as is.
typeof attrVal === 'number' - cast to string
else if !attrVal - remove

The current behavior will remove attributes when the property is "" and I haven't found any problems using inputs, so I am a bit confused.

Case no.1 would produce Incorrect behavior in the following example:
var input  = document.createElement('input')
input.value = "value"

// 1
input.removeAttribute('value')
console.log(input.value) // "value"

// 2
input.value = ""

@thysultan Ah, you are right, right! 😅
We already handle "stateful" props like value and selected specially here.

Yes, now that i look at how it's handled here, it probably shouldn't matter for the mentioned case(unless the logic of setElementProp changes) since app.js#L134-L143 executes both the setter and setAttribute operations.

Even undefined could not remove certain properties like value, which sometimes causes the result that even an intention to remove the value attribute/property would not have the desired effect, but set the value of the element to undefined. See: https://codepen.io/anon/pen/mBoErw?editors=0010
Example code:
const { h, app } = hyperapp
/** @jsx h */

app({
  state: {
    test: false
  },
  view: (state, actions) =>
    state.test?
<input value="test"/><button onclick={actions.test}>Click me</button>
:
<input/><button onclick={actions.test}>Click me</button>
,
  actions: {
    test:function(state){
      return {test:!state.test};
    }
  }
})

@rajaraodv Can we just not use 0 as an id? Seems like the most useless id.

Fixed in master!

@infinnie @rajaraodv Still not published, but all the issues commented on this thread are now fixed in master!
https://github.com/hyperapp/hyperapp/blob/e02342b8f2ede9e655fcef406908ac536f904720/src/app.js#L146-L153
💪😄


Problem On Wiki

Hello @mbdavid,
I think there is a problem on wiki. If you click -Changes from v1.0.x / v2.0.x- that under -Table of Content- section, directing to -Home Page- again. Also there is -Query- page under -Pages- section that completely empty page.
Regards,
Aytaç

Hi! With the objective of organizing our issues, we are closing old unsolved issues. Please check the latest version of LiteDB and open a new issue if your problem/question/suggestion still applies. Thanks!


 I will start with this as it has the smallest scope of all the visibly needed pages to be fixed.

The backup seed page seems to have been broken after the major Gio update version.
Below are screenshots of its UI before the update

The issue relates to something related to the Stack widget and the positioning by the constraints, the go forward button is not being padded by the inset properly and it's filling the whole window now. I think these are operating on the wrong context, from an outer closure.


Discard the validator registrations from slashed validators?

According to the current spec, builder software can accept registrations from validators who are currently active but also slashed.
Given that slashed proposers cannot produce valid blocks, we could tighten the spec to disallow this set of possible registrations.
It is a bit of an edge case but does reduce the possible load on builder software so I wanted to open this issue to see if there is any interest to modify the spec here.

If in doubt, I think we may as well allow it. Might be additional overhead to keep up with slashed validators, and it doesn't really hurt. 🤔


Retry on failed download.

cc @tvolkert

Fixed the import, PTAL and let me know what you want changed for the other issues.

Updated. PTYAL :-)


Conda-forge package doesn't have thrift version pinned to 0.10.0

It ends up pulling thrift 0.11.0 which causes the following error when trying to create a connection:
TypeError: expecting list of size 2 for struct args

Sample conda create to show issue:
conda create --dry-run -n dummy -c conda-forge pymapd
Fetching package metadata .............
Solving package specifications: .

Package plan for installation in environment /home/nfs/kkraus/anaconda3/envs/dummy:

The following NEW packages will be INSTALLED:

    arrow-cpp:       0.8.0-py36_2          conda-forge
    ca-certificates: 2017.11.5-0           conda-forge
    certifi:         2017.11.5-py36_0      conda-forge
    intel-openmp:    2018.0.0-hc7b2577_8
    libgcc-ng:       7.2.0-h7cc24e2_2
    libgfortran-ng:  7.2.0-h9f7466a_2
    mkl:             2018.0.1-h19d6760_4
    ncurses:         5.9-10                conda-forge
    numpy:           1.14.0-py36h3dfced4_1
    openssl:         1.0.2n-0              conda-forge
    pandas:          0.22.0-py36_0         conda-forge
    parquet-cpp:     1.4.0.pre-0           conda-forge
    pip:             9.0.1-py36_1          conda-forge
    pyarrow:         0.8.0-py36_0          conda-forge
    pymapd:          0.3.1-py36_0          conda-forge
    python:          3.6.4-0               conda-forge
    python-dateutil: 2.6.1-py36_0          conda-forge
    pytz:            2017.3-py_2           conda-forge
    readline:        7.0-0                 conda-forge
    setuptools:      38.4.0-py36_0         conda-forge
    six:             1.11.0-py36_1         conda-forge
    sqlalchemy:      1.2.1-py36_0          conda-forge
    sqlite:          3.20.1-2              conda-forge
    thrift:          0.11.0-py36_0         conda-forge
    tk:              8.6.7-0               conda-forge
    wheel:           0.30.0-py36_2         conda-forge
    xz:              5.2.3-0               conda-forge
    zlib:            1.2.11-0              conda-forge

For a workaround until thrift 0.11.0 is supported do:
conda install -c conda-forge pymapd thrift=0.10.0

@kkraus14 Sorry! I had updated the package on pypi, but looks like I didn't get it through to Conda.
@TomAugspurger Looks like I don't have write access to the feedstock. PR submitted at https://github.com/conda-forge/pymapd-feedstock/pull/4 , though I'm not sure why the one Windows build failed.


Godot 4.3 C#/Mono build on Linux comes without the necessary mono descriptor and therefore wants the wrong export template

Tested versions

Godot v4.3.beta1.official (Mono build) [a4f2ea91a]

System information
Ubuntu 24.04 LTS 24.04 - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 950M (nvidia; 555.42.02) - Intel(R) Core(TM) i5-6300HQ CPU @ 2.30GHz (4 Threads)
Issue description
The Mono build on Linux comes without the mono descriptor (Godot v4.2.2 does have it) and therefore it wants the wrong export template (the one not intended for the Mono build)
And yes, I'm sure chose the correct download. I verified. The build also takes attached C# scripts fine, so it appears to be the correct one.

Steps to reproduce

Download https://github.com/godotengine/godot-builds/releases/download/4.3-beta1/Godot_v4.3-beta1_mono_linux_x86_64.zip

(optionally) Download https://github.com/godotengine/godot-builds/releases/download/4.3-beta1/Godot_v4.3-beta1_mono_export_templates.tpz

Unpack the Godot archive

Start the unpacked Godot

go into a project (new or otherwise)

check Help -> About Godot ... or the lower right corner and see that it's missing the mono tag/descriptor (that the Godot v4.2.2 Mono build did have)

go to Editor -> Manage Export Templates ...

If you downloaded the export templates earlier:

install the downloaded export template
see that actually wants the non-mono template rather than the installed mono template

Or if you didn't download the export template earlier:

click on Download and Install
see that it installs the non-mono template rather than the mono enabled one

Minimal reproduction project (MRP)
N/A

This has already been solved (and is a pinned issue):

https://github.com/godotengine/godot/issues/92630

Oh, I see, sorry for the noise. I didn't even know Github has pinned issues, so I went to the issues tab with "Banner blindness", if you know what I mean.
Thanks for mentioning it, good to know.

It's also helpful to search before opening an issue, including closed ones

Well, yeah, I can see them clearly now, thanks to you making me aware of their existence.
And yes, I should have included closed issues in my search. Will do better in the future.


[CWS] make sure release callbacks are cleared, but not the pool releaser

What does this PR do?
Alright so https://github.com/DataDog/datadog-agent/pull/30513 is important in that it fixes the release callbacks never being cleared on reset. The issue is that the main callback (the one provided by the process cache entry pool) is used to put back the pce in the pool, and also to count the cache size, so this one should not be released. To fix this this PR splits the callback list into coreRelease which is the one for pool and never clearer, and the usual release callback list that is effectively cleared.
Motivation
Describe how to test/QA your changes
Possible Drawbacks / Trade-offs
Additional Notes

/merge


Samples: Bluetooth: CAP Acceptor broadcast support

Samples: Bluetooth: CAP Acceptor broadcast support

Rebase to solve merge conflicts

Rebase to solve merge conflicts


Pawno characters issue.

This is reported by Malganys here http://forum.sa-mp.com/showthread.php?t=547598&page=2.

Fixed in 6fe9df8.


refactor: rename file server, remove literal string using Backtick & remove unused file import

Hi, I added some changes to the main section, and DataSource
This is a list of some of the files I changed:

Rename DataSource to data-source
reimport "./Server" to "./server"
remove literang string and change to using backtick
remove unused file import in some files

Hi, thanks for the pull request!

Looks alright, thank you so much for the PR!

Woah!!, Thank you 😁✌


How do I saved audio into 10 second chunks?

IMPORTANT: Be sure to replace all template sections {{ like this }} or your issue may be discarded.
Overview
I want to process audio poritions of streams through a transcription service and it only accepts 10 second chunks. How do I save the audio into <audio-001...audio-999.mp3) etc?
Expected behavior
This is the code I have from the sample posted on this forum, how do I detect the 10 second interval within the audio frame?
import av

input_container = av.open(
    'http://<IP_ADDRESS>/vod/smil:BigBuckBunny.smil/playlist.m3u8')
input_stream = input_container.streams.get(audio=0)[0]

output_container = av.open('live_stream.mp3', 'w')
output_stream = output_container.add_stream('mp3')

for frame in input_container.decode(input_stream):
    frame.pts = None
    for packet in output_stream.encode(frame):
        output_container.mux(packet)

for packet in output_stream.encode(None):
    output_container.mux(packet)

output_container.close()

Investigation
Unfortunately new to pyav and could use some starter help.
Research
I have done the following:

[ ] Checked the PyAV documentation
[x ] Searched on Google
[ x] Searched on Stack Overflow
[ ] Looked through old GitHub issues
[ ] Asked on PyAV Gitter
[ ] ... and waited 72 hours for a response.

Additional context
{{ Add any other context about the problem here. }}

@shashi-netra how did you solve this issue?


Deprecation Warnings for Pydantic V1 Usage

When using crewAI, I'm encountering deprecation warnings related to Pydantic V1 usage. These warnings suggest that the library is using some deprecated Pydantic V1 features that will be removed in Pydantic V3.0.
Warnings

Support for class-based config is deprecated:

PydanticDeprecatedSince20: Support for class-based `config` is deprecated, use ConfigDict instead. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.8/migration/

This warning appears to be coming from crewai/task.py.

Pydantic V1 style @validator is deprecated:

PydanticDeprecatedSince20: Pydantic V1 style `@validator` validators are deprecated. You should migrate to Pydantic V2 style `@field_validator` validators, see the migration guide for more details. Deprecated in Pydantic V2.0 to be removed in V3.0. See Pydantic V2 Migration Guide at https://errors.pydantic.dev/2.8/migration/

This warning appears to be coming from crewai_tools/tools/base_tool.py.
Suggested Action
It would be beneficial to update the codebase to use Pydantic V2 features instead of the deprecated V1 features. This will ensure compatibility with future versions of Pydantic and remove these deprecation warnings.
Additional Information
crewai version: 0.35.8
Though this is not recommended, we can ignore these specific warnings with the following code:
import warnings
from pydantic import PydanticDeprecatedSince20
warnings.filterwarnings("ignore", category=PydanticDeprecatedSince20)
warnings.filterwarnings("ignore", message="Pydantic V1 style `@validator` validators are deprecated")

I'm using crewai v0.74.2 (with Python 3.12.7) and I'm seeing the same warnings.

This issue has been fixed, please upgrade to latest version


Hitting authentication errors when running octodns sync for multiple new zones on the same run

So we are creating new zones with DNS records in Cloudflare using octodns, and almost every time if there are enough new zones, we hit a octodns_cloudflare.CloudflareAuthenticationError: Authentication error at some point of the process. Usually before the 40th or so zone in the set.
My gut feeling is that this is because octodns tries to create the records into the newly created zone too soon after creation, and Cloudflare throws back a 403. But I have a hard time verifying this, as this happens so sporadically.
Here's the full stacktrace for reference:
Traceback (most recent call last):
  File "env/bin/octodns-sync", line 8, in <module>
    sys.exit(main())
  File "env/lib/python3.10/site-packages/octodns/cmds/sync.py", line 62, in main
    manager.sync(
  File "env/lib/python3.10/site-packages/octodns/manager.py", line 856, in sync
    total_changes += target.apply(plan)
  File "env/lib/python3.10/site-packages/octodns/provider/base.py", line 298, in apply
    self._apply(plan)
  File "env/lib/python3.10/site-packages/octodns_cloudflare/__init__.py", line 1107, in _apply
    getattr(self, f'_apply_{class_name}')(change)
  File "env/lib/python3.10/site-packages/octodns_cloudflare/__init__.py", line 920, in _apply_Create
    self._try_request('POST', path, data=content)
  File "env/lib/python3.10/site-packages/octodns_cloudflare/__init__.py", line 131, in _try_request
    return self._request(*args, **kwargs)
  File "env/lib/python3.10/site-packages/octodns_cloudflare/__init__.py", line 156, in _request
    raise CloudflareAuthenticationError(resp.json())
octodns_cloudflare.CloudflareAuthenticationError: Authentication error

We can work around this by just rerunning the sync until all the zones are successfully processed, but this is a bit of a nuisance.

What version are you running. The line numbers in your stack track e.g. 920, don't align with the current release 0.0.7 as that line isn't even in the _apply_Create function.
Some sort of creation timing issue is a good guess, other possibility would be a rate limit of some sort. You might try throwing resp.content into https://github.com/octodns/octodns-cloudflare/blob/5489b15ea20d907399378417b3ba8f8c6bc986d8/octodns_cloudflare/init.py#L151 and running with --debug if you can reliably recreate the problem.
When I get a change to sit down and mess with it I'll try and reproduce the issue, but it sounds like it might be a tough one to do and may even rely on latency to CF's api servers etc.

Yeah i was running 0.0.6. I'll try to run with extra debugging once we get the next bigger batch of zones to process through octodns! Thanks for the info!

One extra tidbit of information: We intially worked around this issue by just running octodns-sync targeted at one zone at a time, and in this way the authentication error never happened. Also we had our request quotas increased from Cloudflare side to make sure we weren't hitting rate limits, but that had no effect.

in a loop targeted at one zone at a time, and in this way the authentication error never happened.

That does make it sound more like a rate limit than race condition, but 🤷

Also we had our request quotas increased from Cloudflare side to make sure we weren't hitting rate limits, but that had no effect.

OK. Since it sounds like you have an account contact you might check with them and see if they have anything to say about eventually consistent creates/race conditions.

So far no luck recreating this. I put together a test data source that creates 64 zones each with a single record and then tries to sync them. Eventhing works fine up to the point it hit the rate limit:
...
********************************************************************************

2024-10-07T14:06:09  [140704633040320] INFO  CloudflareProvider[cloudflare] apply: making 1 changes to sub-0000.dev.
2024-10-07T14:06:11  [140704633040320] INFO  CloudflareProvider[cloudflare] apply: making 1 changes to sub-0001.dev.
2024-10-07T14:06:12  [140704633040320] INFO  CloudflareProvider[cloudflare] apply: making 1 changes to sub-0002.dev.
...
2024-10-07T14:07:29  [140704633040320] INFO  CloudflareProvider[cloudflare] apply: making 1 changes to sub-0049.dev.
2024-10-07T14:07:30  [140704633040320] INFO  CloudflareProvider[cloudflare] apply: making 1 changes to sub-0050.dev.
2024-10-07T14:07:31  [140704633040320] WARNING CloudflareProvider[cloudflare] rate limit encountered, pausing for 300s and trying again, 3 remaining

Going to rework things to create more records in each zone to see if that makes a difference, but otherwise this one is probably going to sit until it times out if we can't come up with reliable steps to reproduce.

Actually looks like the rate limit (for me anyway) never recovers:
2024-10-07T14:07:29  [140704633040320] INFO  CloudflareProvider[cloudflare] apply: making 1 changes to sub-0049.dev.
2024-10-07T14:07:30  [140704633040320] INFO  CloudflareProvider[cloudflare] apply: making 1 changes to sub-0050.dev.
2024-10-07T14:07:31  [140704633040320] WARNING CloudflareProvider[cloudflare] rate limit encountered, pausing for 300s and trying again, 3 remaining
2024-10-07T14:12:31  [140704633040320] WARNING CloudflareProvider[cloudflare] rate limit encountered, pausing for 300s and trying again, 2 remaining
2024-10-07T14:17:31  [140704633040320] WARNING CloudflareProvider[cloudflare] rate limit encountered, pausing for 300s and trying again, 1 remaining
Traceback (most recent call last):
  File "/Users/ross/octodns/octodns-cloudflare/env/bin/octodns-sync", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/Users/ross/octodns/octodns-cloudflare/env/lib/python3.12/site-packages/octodns/cmds/sync.py", line 62, in main
    manager.sync(
  File "/Users/ross/octodns/octodns-cloudflare/env/lib/python3.12/site-packages/octodns/manager.py", line 856, in sync
    total_changes += target.apply(plan)
                     ^^^^^^^^^^^^^^^^^^
  File "/Users/ross/octodns/octodns-cloudflare/env/lib/python3.12/site-packages/octodns/provider/base.py", line 298, in apply
    self._apply(plan)
  File "/Users/ross/octodns/octodns-cloudflare/octodns_cloudflare/__init__.py", line 1186, in _apply
    resp = self._try_request('POST', '/zones', data=data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ross/octodns/octodns-cloudflare/octodns_cloudflare/__init__.py", line 145, in _try_request
    return self._request(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ross/octodns/octodns-cloudflare/octodns_cloudflare/__init__.py", line 172, in _request
    raise CloudflareRateLimitError(resp.json())
octodns_cloudflare.CloudflareRateLimitError: You have exceeded the limit for adding zones. Please activate some zones.


Working ESP32 pin config

Preliminary working config for ESP32. Serial2 by default is 16/17 so I moved DEC S/D to 26/27.
I cannot seem to get SoftwareSerial to compile on ESP32. It doesn't seem like it affects anything because the behaviour of ESP32 serial and Arduino SoftwareSerial is the same anyway once it's opened? The ESP32 pins don't get loaded for Mega so there's no need for the extra ifdefs in Config_adv. Apparently with HardwareSerial you can use any pin for serial TX/RX anyway so shouldn't be too hard to add GPS on Serial1.

Hm that's my exact setup that failed - I just did a clean & build with no issues 🤔

Hm that's my exact setup that failed - I just did a clean & build with no issues 🤔

Hm yeah I understand that but SERIAL_PORT is undefined if I don't include that. Serial2 is just a placeholder, it could be Serial0 or Serial1, I don't know if there's a better/more generic way to refer to it.

Hm yeah I understand that but SERIAL_PORT is undefined if I don't include that. Serial2 is just a placeholder, it could be Serial0 or Serial1, I don't know if there's a better/more generic way to refer to it.

Hi @trishmapow . The CI tests currently just check that the different builds compile correctly, so the values in _CI are only "valid enough" to pass the build. The pin assignments are however safe invalid values and will be ignored by digitalOutput() etc., so it is safe to deploy on hardware, but it will do nothing.

Hi @trishmapow . The CI tests currently just check that the different builds compile correctly, so the values in _CI are only "valid enough" to pass the build. The pin assignments are however safe invalid values and will be ignored by digitalOutput() etc., so it is safe to deploy on hardware, but it will do nothing.

Having said that, the default assignments in all the config files should pass CI tests for both ESP32 and Mega. This part of https://github.com/OpenAstroTech/OpenAstroTracker-Firmware/pull/18 which included valid configuration examples for Mega and ESP32.

Having said that, the default assignments in all the config files should pass CI tests for both ESP32 and Mega. This part of https://github.com/OpenAstroTech/OpenAstroTracker-Firmware/pull/18 which included valid configuration examples for Mega and ESP32.

Thanks for the explanation. I think I will close this for now and wait until I/someone else can incorporate GPS, both stepper types and display in one config (your setup on Slack looks good, I will work around that and try to get NEMA working).

Thanks for the explanation. I think I will close this for now and wait until I/someone else can incorporate GPS, both stepper types and display in one config (your setup on Slack looks good, I will work around that and try to get NEMA working).