timer interrupt fires immediately after being enabled

If I configure a timer peripheral with a long duration, like this:
    let mut timer = p.TIM15.timer(&mut rcc);
    timer.start(4_000.ms());
    timer.listen();

the associated interrupt fires immediately and then again every 4 seconds.
I want to use the timer to implement a watchdog-style behaviour where I reset the timer whenever a good event happens, and thus if the interrupt fires it's bad. For that usage pattern I need the interrupt handler not to fire until the actual timer has elapsed, not immediately.

For the timer peripherals in their default configuration, the prescaler and counter are "pre-loaded" via a shadow register, which means that when you write new prescaler and auto-reload values (PSC and ARR) the new values do not take effect until the next "update event". In the reference manual RM0444 page 750, you can see a timing diagram that explains how the updates to PSC and ARR are handled.
I think this explains why the current code for .start() triggers an interrupt immediately when the counter is enabled -- the timer starts counting from 0 to 0, immediately triggering the first "update event" which sets UIF and updates the desired PSC and ARR values. Then the next time around it counts from 0 to ARR.
It seems the expected way of setting up the timer is to write new PSC and ARR values, then set the UG bit to generate an update event explicitly so that the PSC and ARR values are copied to the shadow registers, then wait for the UIF bit to be set by hardware, and then clear it, then enable interrupts. There is an unspecified delay between setting UG and UIF being set by hardware as well. I found a few mentions of this sequence in the ST Community forums, for example:
https://community.st.com/s/question/0D50X0000Avg2LB/correct-way-to-clear-timsruif-after-setting-timegrug
I tried implementing this sequence and it seems to give the desired behaviour for my code which does .start() then .listen().

The reference manual also mentions you can set ARPE=1 to avoid the shadow registers and have PSC and ARR changes take effect immediately. But when I tried that, I still saw a spurious interrupt as soon as the counter is enabled. I'm not sure why that is.


Support Python 3

What does this PR do?
This moves couchbase to Python 3. There are no real complexities to this. It was already using a hack to get the future division behavior anyway.
Motivation
🐍 3⃣ 🚂 choooo choooo
Review checklist

[x] PR has a meaningful title or PR has the no-changelog label attached
[x] Feature or bugfix has tests
[x] Git history is clean
[ ] If PR impacts documentation, docs team has been notified or an issue has been opened on the documentation repo
[ ] If PR adds a configuration option, it has been added to the configuration file.

Additional Notes
This was a simple one, nothing big

Codecov Report

Merging #2851 into master will decrease coverage by 7.35%.
The diff coverage is 42.85%.

@@            Coverage Diff             @@
##           master    #2851      +/-   ##
==========================================
- Coverage   84.52%   77.16%   -7.36%
==========================================
  Files         636        7     -629
  Lines       37079      346   -36733
  Branches     4426       60    -4366
==========================================
- Hits        31340      267   -31073
+ Misses       4436       48    -4388
+ Partials     1303       31    -1272


Simplify functions that generate scenario input files

Fixes #307.
This PR refactors the functions that generate scenario input files. There is now one function that does this instead of two, and much of the template code previously required is removed.
I have also taken this opportunity to do a very minor refactoring on scenarios for consistency. This should fix #318 too.

@david451lima @IvanPombo @cristianacarpinteiro, will you help me making sure that this does not introduce breaking changes in the scenarios you own, please?

For the windtunnel is giving the following error:

It concerns the opening of a temporary file when calling the function
commands = self.read_commands_from_file(commands_file)

Thanks @IvanPombo for pointing out the error, it should be fixed now.
When trying to run the wind tunnel scenario with default parameters (and no object) I get an error, though:
AttributeError: 'WindTunnel' object has no attribute 'object_path'

Are you sure that the scenario can be run without specifying an object path?

It requires an object.

It requires an object.

Then the scenario class should raise an error at initialization when an object is not given.

It requires an object.

Then the scenario class should raise an error at initialization when an object is not given.

Actually the object is just passed on the simulate. But I will remove the None...


Included array shape in JSON encoding.

Issue #76
This PR is just for discussion.

Yeah I'm guessing both JSON and MsgPack codecs will break when an object array contains lists or tuples or other sequence-like things because of this.

Just to update on this: I've monkey patched my local copy of the JSON class with this update, and it has definitely solved the problem for me. If you think that this solution is technically good @alimanfoo, I'm happy to help out with pushing through the implementation. I'll need some guidance on what needs doing though.
If there's another solution which doesn't involve breaking backward compatibility though, of course this would be better.

Thanks Jerome, I've been trying to think of a clever way to do this but can't see a way around it. When converting object arrays to lists there is an ambiguity, without also knowing the shape it's not possible to correctly restore the original array. Just to illustrate for the record:
In [21]: a = np.empty((2, 2), dtype=object)

In [22]: a[0, 0] = 0

In [23]: a[0, 1] = 1

In [24]: a[1, 0] = 2

In [25]: a[1, 1] = 3

In [26]: a
Out[26]:
array([[0, 1],
       [2, 3]], dtype=object)

In [27]: a.tolist()
Out[27]: [[0, 1], [2, 3]]

In [35]: b = np.empty(2, dtype=object)

In [36]: b[0] = [0, 1]

In [37]: b[1] = [2, 3]

In [38]: b
Out[38]: array([list([0, 1]), list([2, 3])], dtype=object)

In [39]: b.tolist()
Out[39]: [[0, 1], [2, 3]]

Your solution to append the shape to the list of items to be encoded seems good to me.
To take this forward it would be good to add some unit tests that expose this problem in the JSON and MsgPack codecs. It should be doable with some manually crafted arrays like above, i.e., the array b when passed through encode() and back through decode() will end up with a different shape and size.
The next thing to figure out is how to handle data format compatibility as gracefully as possible. Might be worth giving this some discussion, to work through the consequences.
The rule I set for numcodecs to maintain data format compatibility is that the encoding format associated with a given codec ID should never change. Codec IDs are associated with codec classes via the codec_id property, e.g., here. The codec ID is used by Zarr in the array metadata, and is the key used by numcodecs' registry which Zarr uses to look up an implementation for a given codec. So if we change the codec format to append the shape, we have to also modify the codec IDs, as these are effectively new codecs. I had thought for cases like this then we could change the codec IDs to something like "json2" and "msgpack2". So, i.e., the numcodecs library would provide implementations of new codecs "json2" and "msgpack2" which store the array shape in the encoded data, as well as continuing to provide implementations of "json" and "msgpack" codecs so old data that doesn't encounter this problem could still be read, although we would warn users not to use "json" or "msgpack" somehow because these are broken for some cases. This is possibly a little ugly, but preserves format compatibility.
There is another approach we could consider here, because we know that the json and msgpack encodings are basically broken. We could change the implementation of "json" and "msgpack" codecs as proposed, but keep the codec ID unchanged. This would break data format compatibility in the backwards direction, in the sense that older versions of numcodecs would not be able to read data created by newer versions of the library with the "json" or "msgpack" codec. To avoid breaking compatibility in the forwards direction, i.e., to allow newer versions of numcodecs to continue reading data created by older versions, we could add some conditional logic inside decode() to check the type of the last item in the encoded list. If it's a string then you know the shape is missing, and attempt to process using the old logic. If it's not a string, assume it's the shape and process with the new logic. This breaks the codec ID rule, but may be better from the point of view of API simplicity (i.e., we can just keep a single implementation of JSON codec).
Both solutions have pros and cons, would be interested to hear views.
cc @jakirkham

This all sounds sensible to me @alimanfoo. One further option to throw into the mix: make two new codecs Json and MessagePack which implement the new protocol, and just keep the existing JSON and MsgPack ones around as undocumented and deprecated. I think this is reasonably defensible for MessagePack since this is the official name of the protocol anyway. Json perhaps less so, depending on how strongly you feel about capitalisation...

@jeromekelleher I think that's a variation on the first option. I.e., the first option says, numcodecs defines two codec formats for JSON, a legacy format registered under the "json" ID, and a new format registered under a new ID (e.g., "json2"). Under this option, numcodecs also provides two codec classes, one which implements the legacy "json" format, another which implements the new "json2" format. The next question is about API compatibility, i.e., what should these codec classes be called. Your suggestion is to have a class called Json implementing the new format, and keeping the old class called JSON implementing the old format. There are other choices we could make here, e.g., have a class called JSON implement the new format, and a class called something like LegacyJSON implementing the old format (and probably hidden in the API docs). These would have different consequences regarding how old code would run following a numcodecs upgrade. Not sure what is best yet, just trying to understand the options and consequences.

That's true @alimanfoo, it is a variant on the first option. The argument is that for renaming the classes implementing the JSON and MsgPack codecs to something approximately the same as the old classes is that

All old code with continue to work. People who currently use the MsgPack encoder without problems can continue to use it.
In the case of MessagePack, new users will only ever see this codec documented, and don't need to know about MsgPack. I think renaming it to MessagePack is much better than MsgPack2 or whatever, as this will be confusing to new users of the API. (It's less clear for JSON->Json)

I don't think the IDs make any difference; we can call them json2, msgpack2 or whatever. Users will never see them, so the won't be confused by this. This strategy would give full forwards and backwards compatibility, which should be the aim I think.

What about the following...
Rename the JSON codec class to LegacyJSON. In the registry, map the codec
ID "json" to the LegacyJSON class.
Add a new JSON codec class which implements the new encoding format. In the
registry, map "json2" to this new class.
After upgrading numcodecs, any previously written code using the JSON codec
will continue to work without modification. Any data previously written
with the "json" codec can be read. Any new data written after the upgrade
will be written with the "json2" codec, so all potential consumers of the
data would also need to upgrade numcodecs, otherwise they will get an error
regarding "json2" codec not being found. We'd need to clearly document this
all of course.
Do something analogous for MsgPack.
I think I prefer this to e.g. keeping JSON class implementing "json"
format, and adding new class with a new name implementing "json2" format.
This is because it requires no code change, just package upgrade. The
"json" encoding is basically broken, so we want people to start using the
new codec.
I also would be a bit concerned about having classes named like "JSON" and
"Json" in the API at the same time, even if documentation is clear the
names are very similar and it would be easy to get confused about which is
the newer one and which is the deprecated older one. Similar for
"MessagePack" and "MsgPack", even if "MessagePack" is a better name - we
should have called it that to start with.
Very happy to discuss though.
On Tue, 1 May 2018, 11:33 Jerome Kelleher<EMAIL_ADDRESS>wrote:

That's true @alimanfoo https://github.com/alimanfoo, it is a variant on
the first option. The argument is that for renaming the classes
implementing the JSON and MsgPack codecs to something approximately the
same as the old classes is that

All old code with continue to work. People who currently use the
MsgPack encoder without problems can continue to use it.
In the case of MessagePack, new users will only ever see this codec
documented, and don't need to know about MsgPack. I think renaming it to
MessagePack is much better than MsgPack2 or whatever, as this will be
confusing to new users of the API. (It's less clear for JSON->Json)

I don't think the IDs make any difference; we can call them json2,
msgpack2 or whatever. Users will never see them, so the won't be confused
by this. This strategy would give full forwards and backwards
compatibility, which should be the aim I think.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zarr-developers/numcodecs/pull/77#issuecomment-385643133,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8QrivryhLfxSNxPjCVjuSd1awXTFWks5tuDoMgaJpZM4Tql_R
.

@jakirkham: @jeromekelleher and I just had a chat, we're going to go ahead with the proposal in this comment but let us know if you have any objections or concerns.

Sorry @alimanfoo. Have been a bit swamped of late.
The deprecation plan seems good.
Should we add warnings for the old formats? Migration steps for old to new formats? Anything else along these lines?
Would you like me to think about the implementation detail as well? Or will this discussion happen in a new (or revamped version of this) PR?

@jakirkham no problem at all, thanks for taking a look.
A deprecation warning would probably be good. Best way to implement might
need a little thought. Definitely want to warn if someone tries to write
new data with the old codec, we want them to switch to the new. I guess
easiest place to raise a Deprecation Warning would be in the LegacyJSON
constructor. Hopefully that wouldn't be too noisy.
Re migration, I think it should be enough to just upgrade numcodecs. Anyone
who previously used these codecs probably did not hit this issue, so no
need to migrate any previously written data. Upgrading numcodecs will just
ensure any new data is written with the new codec.
I think @jeromekelleher will push to this PR. Would be good to have your
review when the proposed solution is implemented.
On Wed, 2 May 2018, 19:11 jakirkham<EMAIL_ADDRESS>wrote:

Sorry @alimanfoo https://github.com/alimanfoo. Have been a bit swamped
of late.
The deprecation plan seems good.
Should we add warnings for the old formats? Migration steps for old to new
formats? Anything else along these lines?
Would you like me to think about the implementation detail as well? Or
will this discussion happen in a new (or revamped version of this) PR?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zarr-developers/numcodecs/pull/77#issuecomment-386070278,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8QtAa8mvUwcut6HyAFr90jMSq6scSks5tufbGgaJpZM4Tql_R
.

I've convinced myself that this isn't a bug in numcodecs at all in fact, and it's actually doing the right thing. If we provide numpy arrays as input, we always round-trip correctly. If we provide non-numpy inputs, then the result we get back is always equal to np.array(input_data), which is surely the correct behaviour. I've added some test cases to illustrate this here.
Great; no need for new codecs!
I think the answer to my problem in zarr is that we should force object arrays to always be 1D (but we should discuss that elsewhere).

@jeromekelleher what about this case:
In [14]: a = np.empty(2, dtype=object)

In [15]: a[0] = [0, 1]

In [16]: a[1] = [3, 4]

In [17]: codec = numcodecs.JSON()

In [18]: b = codec.decode(codec.encode(a))

In [19]: a
Out[19]: array([list([0, 1]), list([3, 4])], dtype=object)

In [20]: b
Out[20]:
array([[0, 1],
       [3, 4]], dtype=object)

In [21]: a.shape
Out[21]: (2,)

In [22]: b.shape
Out[22]: (2, 2)

:-) I was trying to think of a way to to avoid this upstream as you suggested, but this case of a 1D object array of lists (or tuples) where each list (or tuple) is the same length still causes a problem. Funnily enough if the lists are not all the same length, round tripping works fine:
In [32]: a = np.empty(2, dtype=object)

In [33]: a[0] = [0, 1, 2]

In [34]: a[1] = [3, 4]

In [35]: a
Out[35]: array([list([0, 1, 2]), list([3, 4])], dtype=object)

In [36]: codec.decode(codec.encode(a))
Out[36]: array([list([0, 1, 2]), list([3, 4])], dtype=object)

So it is some special logic in np.array that we need to work around.

I think this should do it for the JSON codec @alimanfoo; what do you think?
I've left the warnings in as a TODO as I'm not sure how you want to handle that. Also, I think you're in a better position than me in terms of documenting this; perhaps you could update this PR with the required docs changes? I'm happy to do the remaining legwork then for the MsgPack codec once we're all happy with the changes in place for JSON.

We'll need to remember to add the new files generated by the backwards compatibility tests on the new codecs into this PR at some point, but can do that when coding work is done.

I've just added the json2 files to this commit, as it seems like the logical place to put them.

Hi @jeromekelleher, I pushed some documentation on the JSON classes.
On reflection, I don't think we need to raise a deprecation warning. If someone has already used this codec to encode some data via a previous version of numcodecs, the chances are they haven't hit this issue, so no need to warn.

Sounds good to me @alimanfoo. I'll apply the same changes for MsgPack so and ping you back.

Awesome, thanks.
On Mon, 14 May 2018, 08:44 Jerome Kelleher<EMAIL_ADDRESS>wrote:

Sounds good to me @alimanfoo https://github.com/alimanfoo. I'll apply
the same changes for MsgPack so and ping you back.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zarr-developers/numcodecs/pull/77#issuecomment-388726063,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq8QjKriFlxw1IK2O9IjIWho2Dlm6ABks5tyTXWgaJpZM4Tql_R
.

OK, that should do it I think. Over to you @alimanfoo!

Nice one, thanks @jeromekelleher.


DiseaseOrPhenotypicFeature (HP:0002013 Cyclic vomiting) related to 'Chemical Substance'- CAM KP returns 0 results

This issue has been created to address https://github.com/NCATSTranslator/testing/issues/91.

Bulk closing testing issues; will open new as problems come up going forward.


How to add/test auto update ?

Previously I am using electron-builder and electron-updater combo to publish and auto updates for exe files. through electron-updater I will check for updates and download and update the app.
But Now I moving to .msi. in this how to achieve auto update feature. I could not able to find any documentation or example. can someone please help on this.
var MSICreator = require("electron-wix-msi").MSICreator;
const path = require('path')
// Step 1: Instantiate the MSICreator
const msiCreator = new MSICreator({
appDirectory: path.resolve('dist/win-unpacked'),
description: 'My amazing Kitten simulator',
exe: 'app',
name: 'app',
manufacturer: 'app',
version: '2.0.0',
outputDirectory: path.resolve('release/msi/'),
appIconPath: path.resolve('build/icon.ico'),
ui: {
chooseDirectory: true,
},
features: {
autoUpdate: true,
},
updaterPermissions: true
});
async function createMsi() {
// Step 2: Create a .wxs template file
await msiCreator.create();
// Step 3: Compile the template to a .msi file
await msiCreator.compile();
}
console.log('Invoke MSI Builder');
createMsi();
This creates these files under release/msi
app.msi
app.wixobj
app.wixpdb
app.wxs
i installed app.msi. whats the next step. how it download and install the updates. How can i test this ? Need help on this ! @felixrieseberg

I would like to know too


SAMZA-2131: [Scala cleanup] Convert FileSystemCheckpointManagerConfig.scala and SystemConfig.scala to Java

Also added some missing unit tests for FileSystemCheckpointManagerConfig and SystemConfig.

@cameronlee314 Thanks for the changes. Merged to trunk.


ci: use cloud controller manager in disconnected pipeline

Reason for Change:

Set useCloudControllerManager=true in disconnected api model
Allow access to arm service tag in nsg for disconnected scenario
Disable azure file csi driver addon
Remove azure file csi driver storage class test
Add nginx image to vhd for pvc test in disconnected

Issue Fixed:

Credit Where Due:
Does this change contain code from or inspired by another project?

[x] No
[ ] Yes

If "Yes," did you notify that project's maintainers and provide attribution?

[ ] No
[ ] Yes

Requirements:

[x] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Notes:

/azp run

Disable pvc test in disconnected since it requires nginx image

I am not sure about this. Can we get the same coverage using a different image?

/azp run

/azp run

/azp run


Expanding inaccessible DBs leads to OE connection drop

Azure Data Studio Version: Insiders
OS Version: Windows 11

Steps to Reproduce:

Connect to Azure SQL DB
Expand a database that is not authorized to logged in user
The parent connection in OE also gets dropped.

Error also occurs in SSMS, but doesn't impact opened OE tree.

Expected:

Error message should be clear, instead of entire stacktrace in message body.
OE tree node should not close completely.

Verified the issue is now fixed in latest insiders build.


Option for hide folder icons!

As title describe!

@leaxoy this is already implemented in #596. It will be deployed soon.


Deploy Applications from Enterprise GitHub and GitLab

This PR builds on #44775.
Fixes #1832 (but not #1442 / #4293)

Codecov Report

Merging #4782 (e934c76) into master (069b4df) will decrease coverage by 25.93%.
The diff coverage is 11.76%.

@@             Coverage Diff             @@
##           master    #4782       +/-   ##
===========================================
- Coverage   53.60%   27.67%   -25.94%
===========================================
  Files        1129       59     -1070
  Lines       39137     4615    -34522
  Branches     4956        0     -4956
===========================================
- Hits        20981     1277    -19704
+ Misses      17979     3160    -14819
- Partials      177      178        +1

Other issues

e2e tests
test - view the app git tab of an app deployed by private github repo when the github endpoin is not connected, connect to it, go back to git tab and info is not updated?
app git tab - project private icon needs to be margin, not padding
app git tab - if description is missing show a hypen
app git tab - check commit author shows correctly
register gitlab enterprise - manually add /v4/api part on register
app git tab - viewing a private repo without creds should show the 'no-content' style screen warning containing private repo info
app summary tab - add project and repo to deploy info card


fix qr for form

Fix to hide QR code when there's a change in the form

Thank you for your valuable contribution to the GitHub repository! Your changes were greatly appreciated and have been well-received.


Implement Contact Form Logic

Task: Implement Contact Form Logic
Description
We need to update the existing contact form to improve its functionality and move away from deprecated dependencies. The form is currently using the deprecated Email JS, and we need to transition to a more robust and maintainable solution.
Requirements

UI Logic Implementation:

Implement the UI logic for the contact form using shadcn/ui, react-hook-form, and zod for validation.
Ensure that the form has proper input fields, error handling, and validation messages based on the design provided.

Validation:

Use react-hook-form for managing the form's state.
Use zod for schema-based validation to ensure data integrity.
Validate user inputs such as email, name, and message fields according to specified rules.

Backend Modification:

Create a backend for the contact form within the Next.js application itself.
Implement an API route to handle form submissions, ensuring data is processed and sent to the desired endpoint or email service securely.
Remove any dependencies on Email JS and ensure a smooth transition.

Guidelines

Follow the existing code style and structure for consistency.
Write clear and concise commit messages.
Test the functionality thoroughly before submitting a pull request.
Ensure that any new features or changes are well-documented.

@dipesh2508  plz assign this issue to me

@tushar-agarwal7 Assigned

create a fork and create a new branch there, and raise a pr when you're done


PV3 missing on tl3 configuration

Hello,
The values I have for home assistant:

Values on Grott

For example the PV3 is missing.
grott        |                   {"device": "hidden", "time": "2023-05-12T16:42:12", "buffered": "no",
grott        |                   "values": {"datalogserial": "hidden", "pvserial": "hidden",
grott        |                   "recortype1": 0, "recortype2": 124, "pvstatus": 1, "pvpowerin": 53067,
grott        |                   "pv1voltage": 5011, "pv1current": 31, "pv1watt": 15534, "pv2voltage": 4114,
grott        |                   "pv2current": 28, "pv2watt": 11519, "pv3voltage": 6846, "pv3current": 38,
grott        |                   "pv3watt": 26014, "pvpowerout": 53007, "pvfrequentie": 4998,
grott        |                   "pvgridvoltage": 2312, "pvgridcurrent": 77, "pvgridpower": 17802,
grott        |                   "pvgridvoltage2": 2371, "pvgridcurrent2": 81, "pvgridpower2": 19205,
grott        |                   "pvgridvoltage3": 2345, "pvgridcurrent3": 76, "pvgridpower3": 17822,
grott        |                   "Vac_RS": 4057, "Vac_ST": 4070, "Vac_TR": 4041, "pvenergytoday": 404,
grott        |                   "pvenergytotal": 46818, "totworktime": 13197357, "epv1today": 126,
grott        |                   "epv1total": 13133, "epv2today": 79, "epv2total": 12158, "epvtotal": 44057,
grott        |                   "pvtemperature": 718, "pvipmtemperature": 769, "pvboottemperature": 674,
grott        |                   "temp4": 0, "uwBatVolt_DSP": 0, "pbusvolt": 3533, "nbusvolt": 3503}}```

Thanks, I based it on my own system (SPH) so may not have had all the values available for mapping.
So, to be clear, it's all the ones titled 'pv3' that are missing right?
If that's the case it won't be too hard for me to add them in.
If you're able to give me an explicit list of the specific ones you're missing I can add them in when I'm next working on it.

Thanks, I based it on my own system (SPH) so may not have had all the values available for mapping. So, to be clear, it's all the ones titled 'pv3' that are missing right?
If that's the case it won't be too hard for me to add them in.
If you're able to give me an explicit list of the specific ones you're missing I can add them in when I'm next working on it.

pvstatus (online/offline)
pvenergytotal (not sure if that’s mapped as PV-All Energy - Total).
PV3 Current
PV3 Energy - Today
PV3 Energy - Total
PV3 Power
PV3 Voltage
totworktime
Also, I can see the "epv1today" not sure if you are taking the values from here and not from PV3 as I can see the "epv3" is missing from the list, and this might be the case for the missing data. Also not sure what the "e" stands for as it's not export, maybe energy :)

Hahaha, don't try and make any guesses about why things are called certain names, it's absolute chaos!
The names you've provided are the ones you want them to show up as/what they used to be called in the old integration. Can I get the names that they appear as in grott as then I can map them on to the new naming scheme.
I'll try and take a look at implementing this over the weekend.

Hahaha, don't try and make any guesses about why things are called certain names, it's absolute chaos!
The names you've provided are the ones you want them to show up as/what they used to be called in the old integration. Can I get the names that they appear as in grott as then I can map them on to the new naming scheme.
I'll try and take a look at implementing this over the weekend.

Indeed, I was trying to see any documentation for the names, and seems that there is none (or at least I cannot find it).
values to be mapped:
In general:
pvstatus
pvenergytotal
totworktime

the 3rd phase
pv3voltage
pv3current
pv3watt

for those two not sure what needs to be mapped, I think the values are missing
PV3 Energy - Today
PV3 Energy - Total

pvstatus is already mapped to PV Status which is in the "Diagnostics" section of the device screen
totworktime is already mapped to Time Since Commissioned (also in the "Diagnostics" section)
pvenergytotal - I don't think I have that one on my SPH system, is that something like "PV generated total" i.e. it doesn't reset daily it's an all time total?

pv3voltage - added as PV3 Voltage
pv3current - added as PV3 Current
pv3watt - added as PV3 Power
epv3today - added as PV3 Energy - Today
epv3total - added as PV3 Energy - Total
If I could get some feedback on what pvenergytotal should display and I'll add that one in too.
(Please can you test this out for me? It's on the 'main' branch if you're ok with using that on HACS).

Sorry for the noob question, do I need to re-download to apply the patch? Or should I go via ssh and replace the modified files? If the latter, what's the path in home assistant RPI?

Values are now automatically added, I'll check with the total values to see if everything is correct.

Everything is correct now. PV-All Power = PV1 Power + PV2 Power + PV3 Power, thank you!
I have checked the "pvenergytotal" and this represent the total number of energy produced since the installation.
In logs: pvenergytotal        :  4774.6
In app is the 4.8MWh

Now there is one small bug, I cannot see the:  epv3today and epv3total but that's missing from grott, I'll raise an issue with them and let you know to update the config, or you can already update the config in advance for those missing values :)
Thank you!

and this represent the total number of energy produced since the installation.

Thanks for the update.
I've already added epv3today and epv3total to the config so whenever they appear in grott they'll start appearing in the HA integration as well.
I'll add in pvenergytotal next time I'm at my desk.

My MIN-XH-US inverter has a PV4 input as well.

Hi All, just circling back to this one, I'm adding the PV4 entries as suggested by @shampeon after that I think this can be closed.
The pvenergytotal field is being implemented as part of #8

This functionality is now available on the main branch for testing (you can select this in the re-download menu in HACS)

Has anyone been able to confirm this works?
I'm closing this so that it can be marked as included in the next release.

Still waiting for the bug fix on https://github.com/johanmeijer/grott/issues/339 but for PV4 i cannot confirm as I only have 3 phases :)

@shampeon - Are you able to confirm this as you seem to have PV3 & PV4 on the output you showed above.

PV4 values are there, but missing the Energy - Total and Energy - Today values, presumably because they're missing from upstream (i.e. johanmeijer/grott#339).

Yeah if they're not available in MQTT yet then they won't appear. From my perspective it's enough to consider this one closed from my end, they should automagically appear in HA once they're being pushed in Grott.

I didn't want to open a new issue so I decided to piggyback. I am not able to see PV3 data, the steps I followed were bit different. I reckon at the time this issue was opened the grott-home-assistant-add-on hadn't been available.
The steps I have done:
1- installed grott-home-assistant-add-on by @egguy and set it up   per @muppet3000 guideline - ignored the configuration step.

https://github.com/muppet3000/homeassistant-grott/blob/main/docs/setup/grott.md#grott-add-on
https://www.splitbrain.org/blog/2023-11/03-growatt_and_home_assistant

2 - Proceeded with the installation of homeassistant-grott integration.
What I am missing here?

I didn't want to open a new issue so I decided to piggyback. I am not able to see PV3 data, the steps I followed were bit different. I reckon at the time this issue was opened the grott-home-assistant-add-on hadn't been available.
The steps I have done: 1- installed grott-home-assistant-add-on by @egguy and set it up per @muppet3000 guideline - ignored the configuration step.

https://github.com/muppet3000/homeassistant-grott/blob/main/docs/setup/grott.md#grott-add-on
https://www.splitbrain.org/blog/2023-11/03-growatt_and_home_assistant

2 - Proceeded with the installation of homeassistant-grott integration.
What I am missing here?

You're probably not missing anything, please can you post the logs from grott so I can see what your system is actually publishing to grott. This integration simply consumes what's on the MQTT messages, so if it's not being published then it can't be consumed.
With those logs I should be able to work it out for you.

@muppet3000 Thanks for assisting me in figuring this out. here are the logs I could get from grott-home-assistant-add-on - https://pastebin.com/kGyUipSH - https://pastebin.com/viKSD2Ss
and Log from Home Assistance Core

@LightMoon  - Looking at the logs, this is the important bit, this is what Grott is getting from your inverter:
         -  pvserial             :  SPM2DBE044
         -  voltage_l1           :  244.5
         -  voltage_l2           :  0.0
         -  voltage_l3           :  0.0
         -  Current_l1           :  16.0
         -  Current_l2           :  0.0
         -  Current_l3           :  0.0
         -  act_power_l1         :  -3310.5
         -  act_power_l2         :  0.0
         -  act_power_l3         :  0.0
         -  app_power_l1         :  3684.2
         -  app_power_l2         :  0.0
         -  app_power_l3         :  0.0
         -  react_power_l1       :  1683.3
         -  react_power_l2       :  0.0
         -  react_power_l3       :  0.0
         -  powerfactor_l1       :  -0.9
         -  powerfactor_l2       :  0.0
         -  powerfactor_l3       :  0.0
         -  pos_rev_act_power    :  -3310.5
         -  pos_act_power        :  -3310.5
         -  rev_act_power        :  -3310.5
         -  app_power            :  3684.2
         -  react_power          :  1683.3
         -  powerfactor          :  -0.9
         -  frequency            :  50.0
         -  L1-2_voltage         :  0.0
         -  L2-3_voltage         :  0.0
         -  L3-1_voltage         :  0.0
         -  pos_act_energy       :  333.2
         -  rev_act_energy       :  1860.2

So what ones of those aren't showing for you on home assistant? Looking at the code for this integration they all seem to be mapped through.
I think there's some other logs that are missing, if you're running a metered system you get two lots of output like how I've pasted above, is there another lot of output which contains things like ppv2 or pv2watt?
If you can get another log output that contains the other stuff that would help me to understand what hasn't been mapped.
Looking at your screen grab from above I'm certain there will be a log entry with something looking similar to above but with either ppv2 or pv2watt in it.

You're spot one! I restarted the addon and tailed the logs with this command  ha host logs --identifier addon_1ef934e0_grott-beta -f, ppv2 and pv2watt showed up in the logs! - https://pastebin.com/pCbGbyd2

Looking at those logs you're missing anything in them for pv3:
 "values": {"datalogserial": "XGD6CM31UN", "pvserial": "SPM2DBE044",
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "pvstatus": 1, "pvpowerin": 51774, "pv1voltage": 1430, "pv1current": 69,
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "pv1watt": 9962, "pv2voltage": 4130, "pv2current": 86, "pv2watt": 35653,
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "pvpowerout": 0, "pvfrequentie": 0, "pvgridvoltage": 2484, "pvgridcurrent":
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          0, "pvgridpower": 0, "pvgridvoltage2": 0, "pvgridcurrent2": 0,
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "pvgridpower2":<PHONE_NUMBER>, "pvgridvoltage3": 15672, "pvgridcurrent3": 72,
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "pvgridpower3": 580583424, "Vac_RS": 45, "Vac_ST": 0, "Vac_TR": 27140,
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "pvenergytoday": 30096, "pvenergytotal": 9, "totworktime": 3879,
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "epv1today": 33, "epv1total": 12641, "epv2today": 0, "epv2total": 0,
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "epvtotal": 0, "pvtemperature": 492, "pvipmtemperature": 492,
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          "pvboottemperature": 0, "uwBatVolt_DSP": 449, "pbusvolt": 4179, "nbusvolt":
Dec 15 21:00:20 homeassistant addon_1ef934e0_grott-beta[400]:                          0}}

I would recommend logging a bug in either of these two repos to get some assistance with why this isn't being picked up for your system:
https://github.com/egguy/grott-home-assistant-add-on
or
https://github.com/johanmeijer/grott/


Low frame rate in Firefox

Godot version
v3.4.4.stable.mono.official [419e713a2]
System information
OpenGL ES 3.0 Renderer: Radeon R9 200 Series (on Firefox 101 on Debian)
Issue description
Dodge The Creeps runs at a low FPS -- about 35 -- when exported to HTML5 and run in Firefox.  It gets 60 FPS in Chromium (version 103), on the same machine.
My machine is:
AMD Radeon RX 5600 XT (NAVI10, DRM 3.40.0, 5.10.0-14-amd64, LLVM 11.0.1)
AMD Ryzen 5 2600X Six-Core Processor
64 gigs of RAM
Steps to reproduce
I just replaced the seconds counter in the creeps demo with a FPS counter (using Performance.TIME_FPS).  But probably there's a better way to measure FPS.
Minimal reproduction project
No response

Firefox + WebGL + Linux is much slower than Chromium. This is not exclusive to Godot, but it's documented anyway: https://docs.godotengine.org/en/latest/tutorials/export/exporting_for_web.html
There is no workaround for this, except on Wayland.


SGX device plugin: issues with opening /dev/sgx after maintainence node restart

On upgrading agent pool to AKS 1.25, we are seeing errors with sgx workloads.
The errors are specifically during enclave creation and we have seen two variations so far.
First one is failure to open the /dev/sgx -
/label_exp/ubuntu64/linux-trunk-opensource/psw/urts/linux/edmm_utility.cpp:116] Failed to open Intel SGX device.

The second one is an error during processing of the sgx_enclave_create function -

We were able to mitigate the issues by restarting the associated services. But it would be good to know if there are any gotchas during maintainence node restarts. Specifically if SGX device permissions are granted again to workloads on node restarts.

We were able to mitigate the issues by restarting the associated services. But it would be good to know if there are any gotchas during maintainence node restarts. Specifically if SGX device permissions are granted again to workloads on node restarts.

The explanation is fairly simple and it's easy to confirm on your nodes the setup. The "backwards" compatibility of the non-upstream SGX device nodes is slowly going away but some (older) SGX SDK versions have had issues with it.
The SGX device plugin only manages upstream SGX device resources (/dev/sgx_[enclave|provision]). We used to support the mode where symlinks from /dev/sgx/[enclave|provision] were made available to containers but since 0.25 that was removed.
The implication is that if you have apps only relying on, e.g., /dev/sgx/enclave to be present and the device plugin does not make it available to your containers, you will see problems like the first one.
The second one might be Azure specific. The simplest way to address this is to use "out-of-proc" quotes via aesmd rather than the "in-proc" quotes that require the access to /dev/sgx_provision. If you're using the plugin from our repo and not the Azure confcom add-on, your workloads needs to specify sgx.intel.com/quote-provider: <name of your container> annotation to get /dev/sgx_provision added to your container. However, the aesmd/"out-of-proc" approach is probably better: sgx.intel.com/quote-provider: aesmd

A couple of pointers: https://github.com/intel/linux-sgx/issues/920, https://github.com/intel/linux-sgx/issues/895, https://github.com/intel/linux-sgx/issues/772

@vtikoo did I cover your question?

Thanks for the explanation @mythi, this definitely helps.
We saw the first issue with PSW 2.19, and it looks like that version looks for both the symlink and the in-kernel driver(in that order). Even if the symlink was not supported, shouldn't the in-kernel driver have been present in the container?

Even if the symlink was not supported, shouldn't the in-kernel driver have been present in the container?

Yes, in-kernel nodes are always made available.
 That might also explain. If the udev-rules are not installed and/or if the default systemd rules for sgx_enclave are used, non-root users cannot access these devices.
For the non-root+devices case we have enabled a contained config to have the device nodes inherit per-container uid/gid values.

@vtikoo I'm closing this since I believe I covered all the questions and there's no bugs we need to fix.


notebook div references

These two references to the #notebook div will probably fail miserably in JLab:
https://github.com/bloomberg/bqplot/blob/d3f4e4f1f51311fc2016db9c2af22568be33ab27/js/src/Mark.js#L250
https://github.com/bloomberg/bqplot/blob/3dd09694fce17841787bcb0a26b21079d62ee167/js/src/MarketMap.js#L604
We should figure out a way to do whatever it is they are doing without hacking the global structure of the DOM.

This is a duplicate of #382

Thanks! I should have checked to see if I opened the issue already.


Update gems

Do some updates Dependabot hasn't (and see if it breaks our coverage reporting).

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?

Yeh, this downgrades simplecov so 🙅.


Preprocessorsymbols and clean build mode

Hi Freddy
I am trying to get activating a selection of preprocessorsymbols to work with AlGo.
If I build and deploy a project of 3 apps without any settings of preprocessorsymbols evrything works fine.
If I then add the following to the settingsfile the same CI/CD workflow fails:
"buildModes": [
"Clean"
],
"cleanModePreprocessorSymbols" : [
"XX"
]
the error is:
Error: Unexpected error when running action. Error Message: There is no artifacts present in D:\a\BC-Beta2\BC-Beta2.artifacts matching *-main-Apps-., StackTrace: at , D:\a_actions\microsoft\AL-Go-Actions\v4.0\Deploy\Deploy.ps1: line 75 <- at , D:\a_actions\microsoft\AL-Go-Actions\v4.0\Deploy\Deploy.ps1: line 69 <- at , D:\a_temp\5bb10c37-b2cf-4173-acec-529cfaced4d4.ps1: line 4 <- at , : line 1
Error: Process completed with exit code 1.
Note: Only one of the apps contain code that involves the symbol XX but all 3 apps must be included.
PS: I was the one with the question about adding buildmodes and preprocessor-symbols in DeployToXYZ-settings at your workshop the other day. Currently I am not adding the settings in DeployTo - this will be next step if we can make this work - and if you know that it is even possible. The goal is to control which environments will receive certain symbols activated.
Kind regards Susanne

Hi, do I understand it right:
You have MyApp, which contains conditional code depending on pre-processor symbols (ex. FUNCA, FUNCB and FUNCC)
You want to compile the 3 versions of MyApp and deploy the one with FUNCA to environment ENV1, the one compiled with FUNCB to ENV2 and the one with FUNCC to ENV3.
If this indeed is that you want, then that is not supported at this time.
I assume that it would require us to add a buildMode to the DeployTo structure in order to know which buildMode app would be deployed to which environment.

I think I got it, but yeah - let's setup half an hour next week to show me the process - feel free to invite and suggest a time to freddyk at microsoft dot com.
Sounds like you are controlling functionality using pre-processor symbols instead of using development branches (kind of).


Add subcommands to support data stream analysis.

Issue #, if available:
https://github.com/amazon-ion/ion-cli/issues/42
Description of changes:
This PR adds options to analyze the input binary Ion data stream, allowing users to:

Get the maximum depth of the input data stream.
Get insights into the top-level values, including the minimum, maximum and average size, size distributions, and total count.
Gain insights into the symbol table, including the ability to request the number of local symbol tables and the number of symbols in the provided Ion stream.

Additionally, the existing count option has been reorganized under the analyze command. The usage pattern has been updated from: ion beta count [File1, File2 ...]  to  ion beta analyze count [File1, File2 ...].
Here is the overview of the command structure before and after the change.
Before
ion
└─ beta
    └─ count (The number of total top-level values)

After
ion
└─ beta
    └─ analyze
          └─ count (The number of total top-level values)
          └─ size (Return min/max/mean size and the size distribution of the top-level values)
          └─ depth (The maximum depth of input ion stream)

For symbol table analysis, we added two options, here is the command structure before and after this change.
Before:
ion
└─ beta
    └─ symtab
          └─ filter (Filters user data out of a binary Ion stream, leaving only the symbol table(s) behind.)

After:
ion
└─ beta
    └─ symtab
          └─ filter (Filters user data out of a binary Ion stream, leaving only the symbol table(s) behind.)
          └─ count (The number of local symbol tables of the input ion stream)
          └─ symbol_count (The number of symbols of the input ion stream)

Testing:
Examples:
Request the maximum depth of input ion stream
> ion beta analyze depth test.10n
Output:
> The maximum depth is 4
Request the size information of the top level values
> ion beta analyze size test.10n
Output:

Request the number of local symbol table of input ion steam
> ion beta symtab count test.10n
Output:
> The number of symbol tables is 387
Request the number of symbols of the input ion stream
> ion beta symtab symbol_count test.10n
Output:
> The number of symbols is 67808444
These examples above show what you should expect when you execute these new options. All the unit tests for these functionalities are added into the tests/cli.rs file.
Note:

We need to add test for subcommand size
Since the result of the size subcommand also provides the number of top-level values, we might consider removing the count subcommand.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

I have a question about API design. Would someone ever want to get depth, count, etc. values at the same time? Do you think there's any use case where you absolutely must have only one of these values?
My gut reaction is that it would make sense to have a single ion beta analyze command that combines analyze count, analyze size, analyze depth, symtab count and symtab symbol_count into one command.

Thanks for the suggestion. I agree with the idea of putting all these analytical options in one subcommand. The count information is already included in the returned value of the size subcommand, so there's no need to keep the count. I'm wondering if keeping all the symbol table related subcommands under symtab could be an option as well? e.g., ion beta symtab analyze will return the number of local symbol tables and the number of symbols.

For what it's worth I would prefer stat or stats as the command here, it matches another CLI which people are likely familiar with (git).
I think we should have the same "porcelain" vs. "plumbing" distinction in ion commands (see Git Internals Plumbing and Porcelain), rather than a beta subtree where we push everything because we regard that which is not beta as "plumbing".

For the API design, I agree with combining analyze count, analyze size, analyze depth, symtab count, and symtab symbol_count into one command.
All the information about top-level data size and the symbol table can be retrieved from SystemReader. However, to get the maximum depth, we need to explore elements from the user reader recursively(current implementation). We can also explore readers on different levels, but it will involve a lot of step_in and step_out, which is not efficient for getting the depth. In this case, combining depth with the rest of the subcommands would require using two different readers to retrieve all information at once, which could be expensive when the data size is significantly large.
LazySystemReader could be an option to achieve this, and we can explore LazyValue to avoid step_in/step_out operations when getting the maximum depth of the nested input data stream. However, there are no public methods in lazy_system_reader to get information about value length under the current version of ion-rust. This feature might be supported in the future, but for now, here is the proposed solution:
Combine all of the subcommands into one except depth.
> ion beta stats

Samples = 59155; Min = 21; Max = 1519
Average = 374; Variance = 195565.635; STD = 442.228
Each ∎ represents a count of 426

[  21 ..  396] [38823] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
[ 396 ..  770] [ 1137] ∎∎
[ 770 .. 1144] [17845] ∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎
[1144 .. 1519] [ 1350] ∎∎∎
The number of symbols is 67808444
The number of local symbol tables is 387

> ion beta depth
The maximum depth is 4

Merge ion beta depth to ion beta stats when LazyValue supports accessing the underlying stream data.

We can also explore readers on different levels, but it will involve a lot of step_in and step_out, which is not efficient for getting the depth.

Using Element also has the same number of step in/out—it's just a higher level of abstraction that hides the reader from you.

combining depth with the rest of the subcommands would require using two different readers to retrieve all information at once, which could be expensive when the data size is significantly large.

How expensive? If its already 5 seconds for a 20 MB file, and combining the two of them makes it take a few more seconds, I think that's fine. We can always improve the efficiency of it later, and this is something that (a) should not be in a performance critical path, and (b) is still in the beta namespace.

Samples = 59155; Min = 21; Max = 1519
Average = 374; Variance = 195565.635; STD = 442.228
Each ∎ represents a count of 426

Can we indicate the units for some of these?

We can also explore readers on different levels, but it will involve a lot of step_in and step_out, which is not efficient for getting the depth.

Using Element also has the same number of step in/out—it's just a higher level of abstraction that hides the reader from you.

combining depth with the rest of the subcommands would require using two different readers to retrieve all information at once, which could be expensive when the data size is significantly large.

How expensive? If its already 5 seconds for a 20 MB file, and combining the two of them makes it take a few more seconds, I think that's fine. We can always improve the efficiency of it later, and this is something that (a) should not be in a performance critical path, and (b) is still in the beta namespace.

Samples = 59155; Min = 21; Max = 1519
Average = 374; Variance = 195565.635; STD = 442.228
Each ∎ represents a count of 426

Can we indicate the units for some of these?

If performance is not the concern here I can make them all in one command.  We can always optimize it when the LazySystemReader supports accessing underlying stream data.
I will add comment on the final report to indicates the units. plot::Histogramitself doesn't support adding units for the data.

This PR has been updated in #134


Welcome content behavior of Quick Chat

Testing #191496
At the point where I ask something, whats the value of still showing the welcome text?

Why not have a /welcome chat command to show it?

The welcome text is out of our control. It's contributed by the Copilot Chat extension. I think it would be odd to have API for "quickWelcome" vs "chatViewWelcome"...
/welcome is an idea, although that's kinda what /help is suppose to be... but /help is crazy long.
@roblourens @daviddossett any thoughts?

related https://github.com/microsoft/vscode/issues/191626

It's not possible, today, to have a different welcome message for Quick Chat vs Chat View... and I'm not sure I'm sold on that differentiation existing because that seems like an odd API.

Talked to @joyceerhl about this and I think we're good here. we simplified the welcome message and now also provide a setting to disable it. That was plan work so it's verified through the usual process. No additional work needed here.


Reduce need for qualified imports

I wonder if something like aspidites/cons would be useful in generalizing some of the overloaded functions.
In my quick experiments, for instance, I'm able to have a delete function that works with lists and sequences (getting weird errors when trying to write an array instance, for some reason), and thus would no longer need to import the respective modules qualified. Ideally, if this is a reasonable approach, Batteries would just re-export delete from Cons (which i'll move somewhere more suitable once I'm sure this is even a good idea).

I would love this! When I put this together, I got frustrated at the need for qualified imports. Abstracting over the containers with a type class sounds like a good way to reduce the need for that.
I think some existing type classes already cover some of the functionality. For example, Unfoldable provides singleton, which is defined by no fewer than 7 containers.

Cool. Do you happen to know if there is something that does what Cons does already? In the mean time, I'll open a PR so we can monitor this.

I don't know of any like Cons. For what it's worth, it reminds me of conj from Clojure.

Actually, I think I found a way to do this without Cons. At least, in Haskell it works. I'm sorting through why the definition won't work in Purescript at the moment.

Here's what I have so far:
deleteBy :: forall f t a. (Applicative f, Foldable t, Monoid (f a))
         => (a -> a -> Boolean) -> a -> t a -> f a
deleteBy eq x =
  foldl (\acc c -> if x `eq` c then acc else acc <> pure c) mempty

delete :: forall f t a. (Eq a, Applicative f, Foldable t, Monoid (f a))
       => a -> t a -> f a
delete = deleteBy (==)

Using it, however, throws an error:
No instance found for
    Prelude.Applicative _5

Works fine in haskell though, given sufficient enough type annotations.

I'm not sure what to make of that error.
Although I haven't stated it anywhere, my goal for this package is to not define anything in it. Instead I want to pull in other packages. So even if it is possible to define delete and friends without Cons, I'd prefer to have those definitions in a separate package. That way you can get them without pulling in all of Batteries.

That makes sense. If I can ever figure that error out, I might start a package that has polymorphic versions of the array-like data types (sequence, array, list).

I marked every colliding import with either a TODO or a NOTE in 0f85b2dd0e67ee082f46d0fb420a18b4cee04f15. That should give you an idea of how many functions there are shared among the container types.

I got rid of Batteries' qualified imports in #9. Now if you want arrays, you have to import Data.Array. That doesn't really affect this issue, but it's good to know.
I also added more container types in #13. They implement most of the same functions.

Awesome. Now when I have time to pick this back up, I know exactly where to pick up again.

For what it's worth, the purescript-filterable package includes a Consable type class

Cool. That said, I needed append, not cons. Also, what was wrong with my function was that it couldn't infer types. I'm opening a PR that depends on a package that I'm calling purescript-containers for now. I'll consider it ready for merging once I've taken the time to write documentation and add the other functions that can reasonably be generalized.

Update: Turns out my implementation was more akin to a filter (as it removed all occurrences of an element, rather than simply the first. As such, the Consable type class would  be necessary.
That said, I've been doing some thinking, and I'm wondering if using polymorphic functions would really be a good idea. That is, if we do, the compiled javascript would be passed an instance dictionary, so the implementation would be slower than the monomorphic versions. I'm wondering if a better approach would be to import all three hiding the clashing names from the least prominent data type implementations. Since Array is a primitive type, it would seem like a good candidate. The user would then import the other libraries qualified if they wanted the List or Sequence specific variants, optionally hiding the Array variants instead if they are dealing with the same data structure consistently.
The other alternative would be to have a top-level module for each data type which imported the base set of imports plus the type-specific ones. This is only subtly different from what your initial implementation had when you announced this library. Instead of:
import Batteries
import Batteries.Array

You would have
Import Batteries.Array

Which implies the import Batteries. The benefit of this over my last suggestion is that which data type takes precedence is made explicit, which could reduce confusion or the need to look up documentation.
What do you think, @tfausak? @paf31, can you comment on if my assessment about polymorphic functions is correct?

I think having an array-based prelude would be convenient right up until you needed both array and maps, at which point it would be frustrating. Even though you could do something like this, why are arrays more important than maps?
import Batteries.Array
import qualified Data.Map as M

But I feel like you're almost always going to want strings (which aren't containers per se, but have many of the same functions), arrays, and (string) maps. I'm fine with others (sequences, sets, catenable lists, etc.) requiring special imports.

Hmm..maybe your curate exports ticket solves the "spirit" of this ticket? I'm comfortable with it being closed in that regard.

Even with a curated export list (#16), there are going to be functions that you want to work on multiple containers.

This isn't something that can really be solved by Batteries. Making generalized functions the work on many containers is outside the scope of this project. I will gladly add any packages that do that, but as far as I know there aren't any.


Plugin hook to allow other plugins to define GraphQL APIs

Bonus idea: if https://github.com/simonw/datasette-graphql provided its own plugin hook then plugins like this one could expose a GraphQL API as well.

Originally posted by @simonw in https://github.com/simonw/datasette-ripgrep/issues/18#issuecomment-737847561

from datasette_graphql import hookimpl

def extra_fields(datasette):
    return [
        ("hello", graphene.String(), lambda root, info: "Hello world"),
    ]

Returns a name, a field type and a resolve function - these are then added to the query at the root of the Schema.

Would use the same async def inner() pattern as other hooks.

Open question: what if the name from a plugin collides with the name of a SQLite table?
Could solve that by automatically renaming the GraphQL field for that table.

The Postgraphile project handles many of the same types of issues, you may want to look there for inspiration. It has awesome plugins

I proved in https://github.com/simonw/datasette-low-disk-space-hook that you can add new plugin hooks as part of another plugin, see also this TIL: https://til.simonwillison.net/datasette/register-new-plugin-hooks

I'm going to experiment with this hook using https://datasette.io/plugins/datasette-packages since it's a really simple plugin (much simpler than datasette-ripgrep).

Here's the hookspec:
from pluggy import HookspecMarker

hookspec = HookspecMarker("datasette")

@hookspec
def graphql_extra_fields(datasette):
    "A list of (name, field_type) tuples to include in the GraphQL schema"

And an example plugin implementation:
@hookimpl
def graphql_extra_fields():
    class Package(graphene.ObjectType):
        name = graphene.String()
        version = graphene.String()

    return [
        (
            "packages",
            graphene.Field(
                graphene.List(Package),
                description="List of installed packages",
                resolver=lambda root, info: [
                {"name": d.project_name, "version": d.version}
                for d in sorted(
                    pkg_resources.working_set, key=lambda d: d.project_name.lower()
                )
            ])
        ),
    ]

Documentation: https://github.com/simonw/datasette-graphql/blob/860e27c9c628b2e052007f8fc1bf85263173340e/README.md#adding-custom-fields-with-plugins

Demo: https://latest-with-plugins.datasette.io/graphql?query={
    packages {
        name
        version
    }
}


fix gpmdp

Description:
The GPMDP media player platform never worked for me.  I did a little investigating and was able to implement changes to get it working.  To do this I had to add a configurator so you can enter the PIN code into home assistant and authorize control of playback controls.
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#
Example entry for configuration.yaml (if applicable):
media_player:
  platform: gpmdp
  address: <IP_ADDRESS>

Looks good! :dolphin:

Thanks for this! :-)
Honestly I got a little annoyed with the amount of changes to the API and couldn't be bothered to keep updating it. Glad to know that a few people still use it. :-D


Is resolveOffset a promise or awaitable value?

In the documentation examples, resolveOffset is always used as await resolveOffset(message.offset), however, in the typescript definitions, it appears that resolveOffset returns void instead of Promise<void>
Which is correct? The examples or the typescript definitions?

I looked at the implementation at the time and it doesn't return a promise so the type is correct 🤔

If i understand correctly resolveOffset is used internally to resolve it and then you have to use commitOffsetsIfNecessary to actually commit offset to kafka. commitOffsetsIfNecessary relies on autoCommitInterval to determine if it should commit now or not.

resolveOffset is synchronous. The only thing it does is set a value in an object. The examples must be off.


Add Samba-CoE-v0.2-best-of-16 to AlpacaEval

Running Samba-CoE-v0.2 and then rank with PairRM 0.4B best out of 16 generations.

Very impressive results! Also the output length is not too large, it should do very well on length-corrected AE


ValueError: Pipeline cannot infer suitable model classes from LiheYoung/depth-anything-small-hf

When attempting to use transformers, I get the following error:
from transformers import pipeline
from PIL import Image

image = Image.open('./testimage.jpg')
pipe = pipeline(task="depth-estimation", model="LiheYoung/depth-anything-small-hf")
depth = pipe(image)["depth"]

(.venv) gavin@gavin-ideapad-1:~/repos/ai-6dof$ python main.py
2024-02-26 14:38:12.623114: I external/local_tsl/tsl/cuda/cudart_stub.cc:31] Could not find cuda drivers on your machine, GPU will not be used.
2024-02-26 14:38:12.661710: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:9261] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-02-26 14:38:12.661768: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:607] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-02-26 14:38:12.663446: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1515] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-02-26 14:38:12.672494: I external/local_tsl/tsl/cuda/cudart_stub.cc:31] Could not find cuda drivers on your machine, GPU will not be used.
2024-02-26 14:38:12.672769: I tensorflow/core/platform/cpu_feature_guard.cc:182] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-02-26 14:38:13.625810: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
Traceback (most recent call last):
  File "/home/gavin/repos/ai-6dof/main.py", line 5, in <module>
    pipe = pipeline(task="depth-estimation", model="LiheYoung/depth-anything-small-hf")
  File "/home/gavin/repos/ai-6dof/.venv/lib/python3.10/site-packages/transformers/pipelines/__init__.py", line 905, in pipeline
    framework, model = infer_framework_load_model(
  File "/home/gavin/repos/ai-6dof/.venv/lib/python3.10/site-packages/transformers/pipelines/base.py", line 260, in infer_framework_load_model
    raise ValueError(f"Pipeline cannot infer suitable model classes from {model}")
ValueError: Pipeline cannot infer suitable model classes from LiheYoung/depth-anything-small-hf

Hi, did you install the latest transformers? Please update your transformers by:
pip3 install git+https://github.com/huggingface/transformers.git

Pretty sure I had the latest transformers. I ended up getting around this issue by using the image_processor -> model split pipeline.

I checked with transformers 4.38.2. Your code above can be successfully executed. I am a little confused what the problem is. Do you still have this error?

Do you still have this error?

No, but I'm not using that code anymore. I'll close this since I found an easy workaround.

Hello, could you please share how you fixed the issue? What is the new code, I have the same issue and cant fix it.

I'm afraid I don't have that code anymore. Use the image_processor -> model split pipeline.

Still happens to me.
Did given command...

pip3 install git+https://github.com/huggingface/transformers.git

but still, throws given exception. Could you please explain how you managed to get it working?
This is what I get from REPL:
Python 3.11.4 (main, Sep 14 2024, 19:18:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from transformers import pipeline
2024-09-24 20:43:27.126623: I external/local_xla/xla/tsl/cuda/cudart_stub.cc:32] Could not find cuda drivers on your machine, GPU will not be used.
2024-09-24 20:43:27.358171: I external/local_xla/xla/tsl/cuda/cudart_stub.cc:32] Could not find cuda drivers on your machine, GPU will not be used.
2024-09-24 20:43:27.579991: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:485] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-09-24 20:43:27.758034: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:8454] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-09-24 20:43:27.807500: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1452] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-09-24 20:43:28.180905: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-09-24 20:43:30.085861: W tensorflow/compiler/tf2tensorrt/utils/py_utils.cc:38] TF-TRT Warning: Could not find TensorRT
>>> depth_pipeline = pipeline(task="depth-estimation", model="LiheYoung/depth-anything-small-hf")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/wceli/Projects/Clientes/Upwork/Keunhyuk Jang, J/Pipeline Code/upwork__keunhyuk_jang_J/lib/python3.11/site-packages/transformers/pipelines/__init__.py", line 896, in pipeline
    framework, model = infer_framework_load_model(
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/wceli/Projects/Clientes/Upwork/Keunhyuk Jang, J/Pipeline Code/upwork__keunhyuk_jang_J/lib/python3.11/site-packages/transformers/pipelines/base.py", line 269, in infer_framework_load_model
    raise ValueError(f"Pipeline cannot infer suitable model classes from {model}")
ValueError: Pipeline cannot infer suitable model classes from LiheYoung/depth-anything-small-hf


securitySchemas and security of CAMARA APIs should reside in the API specification as it is part of API lifecycle

Problem description
As discussed in this issue earlier, securitySchemas and security details should be with the API specification as it is part of the API lifecycle. The current short term proposal of using .well_known definition (as agreed in the TSC) needs to be revisited.
Expected action
API specification should include all the possible security flows applicable for an API endpoint.
Additional context
As discussed in https://github.com/camaraproject/IdentityAndConsentManagement/issues/57, we need to address this issue at the earliest as the changes affect all the CAMARA APIs

As mentioned in https://github.com/camaraproject/IdentityAndConsentManagement/issues/57#issuecomment-1856298543, as per TSC 07/12 meeting conclusion, securitySchemas and security agreed solution in #57 will not be re-discussed again.

As per above, I then propose to close this issue.


[Bug] Transition with the same value output  will conflict

🐛 Bug Report
Currently, it will return an error if the transition output is the same.
https://github.com/AleoHQ/snarkVM/blob/ce4ea932be410e803a996d3663fe36cd214a15eb/synthesizer/program/src/function/mod.rs#L163
This will cause unwanted behavior.
Steps to Reproduce
Run this function:
program test_output.aleo {
    transition double_output() -> (u64, u64) {
        return (0u64, 0u64);
    }
}

Find that:
leo run -d --offline --enable-dce-ast-snapshot double_output
       Leo ✅ Compiled 'main.leo' into Aleo instructions
       Leo ✅ Compiled 'token.leo' into Aleo instructions
Cannot add duplicate output statement
Error [ECLI0377008]: Failed to execute the `build` command.
SnarkVM Error: Failed to parse string. Parsing Error: VerboseError { errors: [("\n", Nom(MapRes)), ("\n\n\n\nfunction double_output:\n    output 0u64 as u64.private;\n    output 0u64 as u64.private;\n", Nom(Alt)), ("\n\n\n\nfunction double_output:\n    output 0u64 as u64.private;\n    output 0u64 as u64.private;\n", Nom(Many1))] }

Expected Behavior
Should run successfully.
Your Environment
leo 1.10.0

snarkVM requires Output statements to be unique, since it uses the register locator to determine a record's index.
See here.
Without this restriction, your transition can produce two records with the same OutputID.
Instead, this should be fixed at the Leo level, with sufficient warnings or a modification to code generation that accounts for duplicate output values.
I've added a tracking issue here.
Please feel free to re-open if you believe the issue still needs to be addressed at the snarkVM level.


todoist-electron: use electron 24

Description of changes
Todoist electron is still using electron 21 which is EOL. However, it works just fine with the latest electron 24.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@kalbasit have you tried logging in?
https://github.com/NixOS/nixpkgs/issues/231111#issuecomment-1555904249 points out login breaks when moving from electron 21 to 22.

@kalbasit have you tried logging in to electron-24-built-Todoist?
#231111 (comment) points out login breaks when moving from electron 21 to 22.

Good catch, I haven't. I'll try right now and report back.

hmmm it's odd. When logging in, it opens a new window to login but never logs itself back in the main window. I guess we'll have to wait for upstream to fix this.

Superseded by #237663


add functional_validators.py::model_validator docs with link to usage docs

add link to usage docs in functional_validators.py::model_validator

Change Summary

Update functional_validators.py model_validator docs with link to usage docs
Related issue number

fix #7060
Checklist

[x] The pull request title is a good summary of the changes - it will be used in the changelog
[x] Unit tests for the changes exist
[x] Tests pass on CI
[x] Documentation reflects the changes where applicable
[x] My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers
please review this documentation only change.

Thanks @icfly2


[plot3d] Cut plane equation in param tree

Display plane equation in cut plane param tree widget.
Consider allowing to set the equation from the param tree widget.

closing as this is available for planes in SceneWindow


[Feature] Add final_url_suffix and include in campaign reports.

Is there an existing feature request for this?

[X] I have searched the existing issues

Describe the Feature
Add final_url_suffix into stg_google_ads__campaign_history and stg_google_ads__ad_history and modified logic for extracting the UTMs.
Describe alternatives you've considered
Editing the package manually as opposed to being integrated in the official live version of the package.
Are you interested in contributing this feature?

[ ] Yes.
[ ] Yes, but I will need assistance and will schedule time during your office hours for guidance.
[ ] No.

Anything else?
Please see PR #34 and PR #42 for more details

@dlubawy and/or @jocelyn-metricbox I wanted to clue you in here as I have been able to make the updates highlighted within the conversation form PR #33. Before moving forward with these changes and opening a new PR to incorporate the updates in the next release, I would like for you to confirm that these updates look appropriate with your data.
To test the working branch, would you be able to update your packages.yml to reference the following WIP branch in place of the official google_ads package version.
packages:
# - package: fivetran/google_ads
#   version: [">=0.9.0", "<0.10.0"]
  - git: https://github.com/fivetran/dbt_google_adse.git
    revision: customer/final-url-suffix-add
    warn-unpinned: false

Once you add this to your packages.yml, you will want to run dbt clean && dbt deps to ensure you are using the WIP version of the package and not the official version. If all looks good on your end, I can move forward with opening a PR to incorporate these changes into the next release.
For a full list of all the changes in this WIP branch, you can view the comparisons below:

dbt_google_ads changes
dbt_google_ads_source changes

Hi @fivetran-joemarkiewicz,
We took a look on our end and realized that we may be missing the integration of final_url_suffix on the other levels of the Google Ads settings. You can set the final_url_suffix on five different levels: account, campaign, ad, (ad group, dynamic ads target, keyword), and the sitelink levels. The PRs linked so far have only covered the campaign and ad level, but we should have this implemented for all other levels being sourced in the google_ads_source package as well:

stg_google_ads__account_history
stg_google_ads__ad_group_criterion_history
stg_google_ads__ad_group_history

Then the google_ads package should likely source UTM parameters for the google_ads__url_report table from the bottom up because the settings for the various levels do not trickle down into the sub-levels (i.e. final_url_suffix in ad_history does not get inherited from ad_group_history and final_urls in the table does not show URLs that are constructed from the final_url_suffix values where tracking params are intended to be set). This makes the most sense to me as an org would set UTM params in the final_url_suffix on the ad group or campaign levels to auto-create default URLs for ads in those sets, but an org may also overwrite this by setting a final_url_suffix on the ad level itself. All of this being necessary because Google Ads does not provide a field in the ad level combining all of this for us.
To summarize:

Should have UTM columns built from the final_url_suffix in all levels for staging

stg_google_ads__ad_history
stg_google_ads__campaign_history
stg_google_ads__account_history
stg_google_ads__ad_group_criterion_history
stg_google_ads__ad_group_history

The google_ads package should source UTM params in the google_ads__url_report table from each of those staging tables by using the hierarchy of levels to determine the order of priority from the bottom up: ad -> ad group -> campaign -> account

Does this make sense?

Hi @dlubawy thanks for the great response here and my apologies for my delay in getting back to you.
So if I am understanding this correctly, there is a waterfall relationship with how these final_url_suffix may be assigned. Google Ads allows you to set the final_url_suffix at either the account, campaign, ad group, criterion, and ad levels. These then can be flowed down into the "child" groups, but they also allow for overrides at the independent levels. So to picture this in more detail (please pardon my absolutely rudimentary sketching. I am no artist 🧑🎨)

If this is true, I have a much better understanding of how these final_url_suffix should be inherited. Additionally, the chart above is only for the ad level. I imagine the same waterfall effect holds true as you go upstream. If this is the case, I see a path forward with applying these updates to the remaining staging models and applying this logic.
However, I do have on remaining question on this topic before going forward. Does the business care about these upstream final_url_suffixs? Or are these only here to be sourced by the google_ads__url_report? If they truly are only necessary to be sourced and reference by the google_ads__url_report in this case, then I feel fairly confident in the approach to update that model in the dbt_google_ads package with the waterfall logic outlined above.
Let me know if I am misunderstanding any points. If not, then I feel we can look to incorporate these full changes in our upcoming sprint.
Thanks for collaborating with us!

Hi @fivetran-joemarkiewicz,
Sorry for taking so long to get back to you.
I think you have the right general understanding in how it should work, but the workflow needs to be changed to after parsing the final_url_suffix. Our understanding is that the final_url_suffix is parsed on each level and then parameters are then picked in order of priority. For example, utm_content=campaign_content would be superseded by any utm_content=ad_content, but any additional parameters in the campaign level would still be used so long as they aren't being overridden in the ad level. This is why we should add utm_ columns for each level in staging (stg_google_ads__account_history, stg_google_ads__campaign_history, ...). That way the google_ads package can then do the logic of coalescing UTM parameters from the various levels' staging models into the google_ads__url_report table based on the order of priority with ad level being the highest priority and account level being the lowest. Does that make sense?


"Țigănești" is listed in the drop-down menu

Description:
"Țigănești" is listed in the drop-down menu alongside its corresponding county and commune, according to the law
Precondition:
The website is up an running.

Step 1
Type "Țigănești" in the search bar.

Expected results
The location is listed in the drop-down menu as "Sat Țigănești, TELEORMAN (Țigănești)" and "Comuna Țigănești, TELEORMAN".


Color of second (right) yAxis

I'm not sure who reads this... Hello.
I have read the "advice" provided when writing this issue; I have searched SO; I have used various search engines; and I have tried (with my limited abilities) to find a solution with plenty of trial and error...
All I'm trying to do is to get the second yAxis (position: right) to be drawn with a specific colour (say, 'blue'). I know that the first yAxis (position: left) can be drawn in a specific colour (say, 'red') by using the 'zeroLineColor' trick on the xAxis, but I have not found a way of drawing the second yAxis in any specific colour, besides the default. Is it possible?

I have read the "advice" provided when writing this issue

Where is the example, version you are using etc?
Assuming its 2.9.3.
You can use indexable color in the xAxis, if you have static number of ticks.
https://codepen.io/kurkle/pen/yLNLzMJ?editors=1011

Thank you for the prompt feedback. It is much appreciated. Version: you are perfectly right, I did not include it -- I'm using CDN to fetch the latest version, 2.9.3.
Regarding the codepen, I had come across similar examples but it is not clear to me how I can target the "last xAxis" only. My data is ajax-fetched and contains a variable number of points; I can determine the number of points, of course, but how do I then target that "last xAxis"? Thanks in anticipation for any clarification.

For anyone who may find it useful, here's how I "solved" it in the end. It is not elegant by any means but it does the job.
Since I can determine the number of data points, I simply created an "indexable color array" with the exact same number of empty values; then I replaced the last value with the color that I want for my "right yAxis" and updated gridLines.color with this new array.
It works, but is far from elegant and if anyone has a better solution it would be greatly appreciated.

This will be easier in v3 by using a new borderColor option.

That's great news! Is there a timeline for the release of the new version of this excellent library?


Problem

Whenever I open runbot.bat it says I need Python for it to work.

And it is a error.

Can you help me?

Ya need python for it work, did u follow the guides?

Yes

Is this bot for discord?

Apparently, you didn't follow it right cuz apparently, you don't have python
And yes, it is.

Ok.

What os are you using?

The guides tell you to install Python... They even tell you how to do it.

Follow the guides properly. You do require Python.


How to use laravel Auth::user() outside laravel 5.2

I am using this code for use Auth::user() outside Laravel 5.1 and works properly:
require '../laravel/bootstrap/autoload.php'; $app = require_once '../laravel/bootstrap/app.php'; $app->make('Illuminate\Contracts\Http\Kernel')->handle(Illuminate\Http\Request::capture());
But in Laravel 5.2 does not work. What is the solution?

Feel free to ask on the forums. I'm sure someone can help you there.


Write a TLA+ spec of SeqModelChecker

Sequential model checker has a number of tuning options such as: checking invariants before or after taking a step, discarding disabled transitions, excluding executions with views, etc. ADR-003 captures only one combination of these options. In order to document and understand better how the model checker is interacting with the solver, we have to write a specification, instead of a single sequence chart (as in ADR-003).

That was a curious exercise but it happened to be much harder that it was useful


Logo Proposal

Hello sir, I'm a graphic designer and I would love to contribute to your project with a logo. This is completely free, take it as a contribution. In case you agree I would be presenting sketches and you will be choosing/modifying the aspects you like more so we could work on the perfect logo for your project together.
Let me know what do you think? best regards :)

I have just used github so can you explain more obviously?

Sure. You can either send me a graphic and I can add it, with attribution,
if it fits the spirit of the project, or you can add it to the README and
submit a Pull Request. Cheers!
On Thu, May 3, 2018 at 10:52 PM, Ductoan99<EMAIL_ADDRESS>wrote:

I have just used github so can you explain more obviously?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/TimeMagazine/babynames/issues/11#issuecomment-386494141,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA51k1w6S49b8KQfPs29RqmHi94yKHmRks5tu8JmgaJpZM4TLODO
.

--
<EMAIL_ADDRESS>434.242.9728


Beckn GUI :  Error When Joining Existing Network as BAP

Description
When attempting to join an existing network as a BAP using the following URL: Beckn Onix GUI, an error is encountered. The error message is currently vague, making it difficult to understand the root cause of the issue.
Steps to Reproduce

Go to Beckn Onix GUI.
Click on Installation Wizard
Click on Join an existing network
Click on BAP Adapter
Enter Valid Subscriber ID, subscriber URL, Registry URL
Click on continue
Observe the error message that appears.

Expected Behavior

[ ] A clear and descriptive error message should be provided to help users understand what went wrong and how they can potentially resolve the issue.
[ ] Include Mandatory Field requirement & validations wherever possible

Actual Behavior
An unspecified error message is displayed, making it unclear what the problem is.
Suggested Improvement

Define the exact error with a clear and descriptive message.
Provide details about what caused the error.

@emmayank the URL https://beckn-onix-gui.vercel.app/ is mainly for showing the UI to other's.
When you are clicking the button for installing BAP adapter. What actually happening is the script trying to install set up the bap adapter on the vercel server.
now, vercel will not allow you to run custom scripts on their servers. it is free service for hosting websites only.

@emmayank beckn-onix-gui.vercel.app is deployed on vercel,  we can only run serverless functions.
hence,  I am closing this issue.


Houdini: Implement Arnold .ass standin extraction from Houdini (also support .ass.gz)

Brief description
This implements the creation and publishing of Arnold proxies (.ass or .ass.gz) from Houdini.
Currently defaults to ~.ass.gz~ (changed with https://github.com/pypeclub/OpenPype/pull/2603/commits/dd92fe1e4ee9a195b85d7aa6b4234fba2829dec4) .ass
Additional info
Explicit detection of multidot extension .ass.gz
Detecting whether a filename ends with a multidot extension like .ass.gz isn't fool proof. It's hard to know whether something is just an extra dot in a filename or actually is part of the extension. As such I've opted for logic that explicitly says that it allows .ass.gz as extension.
It does mean some hardcoded logic for that - but will definitely reduce false positives. If anyone knows a better way I'd be happy to hear it.
 This just allows for a better versioning/updating experience for the end user so that to update from a version that was .ass and a new version being .ass.gz that you can actually update through the manager - otherwise using Avalon's switch logic would be required to do so.
Testing notes:
The simplest setup:
import hou
import avalon.api
import openpype.lib

# Create a Box so we have something to export
root = hou.node("/obj")
geo = root.createNode("geo")
box = geo.createNode("box")

# Create Arnold ASS instance
Creator = openpype.lib.get_creator_by_name("CreateArnoldAss")
asset = avalon.api.Session["AVALON_ASSET"]
container = avalon.api.create(Creator,
                              name="assMain",
                              asset=asset)

# Publish!

 The Arnold ROP acts like a render rop and "extracts" whatever is set to display in the viewport by default (using Candidate Objects = * on the ROP). Since the Box is visible that would end up in the publish.
This requires htoa (Houdini to Arnold) to be installed for Houdini.

I am going to change the default to .ass instead of .ass.gz.  Plus writing them is tons slower than writing regular .ass.
Will also likely expose a toggle in settings to set the default.

I am going to change the default to .ass instead of .ass.gz.  Plus writing them is tons slower than writing regular .ass.
Will also likely expose a toggle in settings to set the default.

Implemented. ✅

It doesn't work for me for some reason.

Traceback (most recent call last):
  File "E:\projects\openpype\3x\.venv\lib\site-packages\pyblish\plugin.py", line 522, in __explicit_process
    runner(*args)
  File "E:\projects\openpype\3x\openpype\hosts\houdini\plugins\publish\collect_frames.py", line 28, in process
  File "E:\projects\openpype\3x\openpype\hosts\houdini\api\lib.py", line 184, in get_output_parameter
    if node.evalParm("ar_ass_export_enable"):
TypeError: Node type 'arnold' not supported

even if I have the arnold up and running.
Also, shouldn't the creator respect Use selection checkbox?

@antirotor that error message looks like you were running using older python code somehow and updated in between. That error message wouldn't happen on that particular line of code? Can you try again, checkout, restart tray and Houdini and give it a whirl. Maybe ditch any pycache you have too just to be sure.
The code is definitely in the list of changes that should make that work.

That error message wouldn't happen on that particular line of code? Can you try again, checkout, restart tray and Houdini and give it a whirl. Maybe ditch any pycache you have too just to be sure.

@antirotor could you check again?


UICONSET-159: Add Authorization Roles to the consortium manager

Purpose

UICONSET-159: Add Authorization Roles to the consortium manager
Approach

https://github.com/folio-org/ui-consortia-settings/assets/116072773/032cdc43-417d-4ebd-ad7a-486b1734c1ed
Screenshots

Pre-Merge Checklist
Before merging this PR, please go through the following list and take appropriate actions.

[x] I've added appropriate record to the CHANGELOG.md
Does this PR meet or exceed the expected quality standards?

[ ] Code coverage on new code is 80% or greater
[ ] Duplications on new code is 3% or less
[ ] There are no major code smells or security issues

Does this introduce breaking changes?

[ ] If any API-related changes - okapi interfaces and permissions are reviewed/changed correspondingly
[ ] There are no breaking changes in this PR.

If there are breaking changes, please STOP and consider the following:

What other modules will these changes impact?
Do JIRAs exist to update the impacted modules?

[ ] If not, please create them
[ ] Do they contain the appropriate level of detail?  Which endpoints/schemas changed, etc.
[ ] Do they have all they appropriate links to blocked/related issues?

Are the JIRAs under active development?

[ ] If not, contact the project's PO and make sure they're aware of the urgency.

Do PRs exist for these changes?

[ ] If so, have they been approved?

Ideally all of the PRs involved in breaking changes would be merged in the same day to avoid breaking the folio-testing environment.  Communication is paramount if that is to be achieved, especially as the number of intermodule and inter-team dependencies increase.
While it's helpful for reviewers to help identify potential problems, ensuring that it's safe to merge is ultimately the responsibility of the PR assignee.

@folio-org/eureka please review it.


Will lexical table plugin be supported？

Hi @pan2za ,
Yes, we plan to support it in the future.
Are you interested in contributing in development? @Sulkar (https://github.com/Sulkar) is also interested in building table plugin.

No, I'm not so familiar with svelte.

Hi @pan2za ,
Table plugin is supported now.

Perfect thank you very much!


cleanup output for non-configured sources that won't actually run

What's the problem (or question)?
The tool is telling me it's going to use resources it doesn't actually end up using or isn't configured to use. This could be confusing for people using the tool.
Do you have an idea for a solution?
When the tool has no configuration for a given resource, don't state that resource will be used, even if it isn't ever actually used.
Like, if I don't have Shodan setup, don't have this:
Running Source: ...
Running Source: Shodan
Running Source: ...

How can we reproduce the issue?

subfinder -d google.com ( a pretty default scan )
See there's lots of stuff that's going to run that isn't ever going to actually run.
Be confused if it is ever used.

What are the running context details?

Installation method (e.g. pip, apt-get, git clone or zip/tar.gz): go get
Client OS (e.g. Microsoft Windows 10): Debian GNU/Linux 9.4 (stretch)
Program version (see banner): v1.1
Relevant console output (if any): Running Source: Shodan (example)
Exception traceback (if any): n/a

Fixed!


Special "tree" view

What feature or improvement do you think would benefit Files?
It would be useful to be able to expand folders in the same view, as Apple Finder can do. Then you can simultaneously select files lying in different folders.

Requirements

Easily select files from different folders to act on them (copy, delete, rename, etc.).

Files Version
<IP_ADDRESS>
Windows Version
10.0.22631.3085
Comments
I am using this service for the first time, so if I am doing something wrong, I apologize.

Thanks for the feedback, We're tracking this in https://github.com/files-community/Files/issues/1928. You can check there or click subscribe in the right sidebar for updates.


Segment Tree with Lazy propagation in java added

Please check README carefully. Segment Tree already exists on Line No. 7.

But it is in cpp and python . but i have added java version of segment tree


Dynamic title don't display title of running app in BSPWM.

Expected behavior:  Title is Newsboat/Neomutt in title. Actual behavior: Title is Alacritty. Why is this?.

Probably because you're running Newsboat/Neomutt inside of alacritty?

Yes I want to display the titles of the apps running in Alacritty. How would that be done?.

Oh okay, I don't think that's currently supported. I'm not sure how other terminal emulators do this.

I use ZSH and export the XTERM title in a precmd. I can get path, but not the title. I've set it so the title should be displayed in the XTERM export command. This doesn't work.

I'm not sure exactly how it works because I don't make use of it. But alacritty does have dynamic title support (in theory).
This is done here: https://github.com/jwilm/alacritty/blob/master/src/ansi.rs#L754-L763
I'm not sure what the issue might be for you.

Seems like alacritty doesn't actually set the window title dynamically when using the -e flag.

Bump.
Weechat sets the title correctly: https://i.imgur.com/b95rUnA.png
Newsboat don't: https://i.imgur.com/b95rUnA.png
Is this Alacritty or Newsboat or something else?.

If weechat does it correctly, it sounds to me like Alacritty supports it.
Does this work in any other terminal emulator? If newsboat doesn't set the title manually, Alacritty will not do so automatically. The dynamic window title just means that when the escape sequence for window title change is issued, that it is not ignored. The application still needs to send it.

Closing this since it's likely a Newsboat issue, if there's any indication that this is untrue, please let me know and I'll re-open.

It's not working on other apps, it doesn't show the commands that are running in Alacritty

It's all up to the application actually sending the escape. If the application isn't sending it, we won't be able to display it.


elevate.exe Error in Windows XP (x86) : Not a valid win32 application

You can build x86 version and add support it in electron-sudo code, welcome PR :)
https://github.com/automation-stack/electron-sudo/tree/master/src/vendor/win32

I have the same issue.