BatchRecipientsActivity failed after renewing secret

There is a similar issue about this, but there are no details explaining how it was resolved. I recently had to generate a new secret for the GraphAppPassword in the key vault. I've confirmed that the GraphAppPassword in the app service and the prep service have both been updated, as well as the AzureAD:ClientSecret value in the app service. I've confirmed all other key vault values in all four services are current and correct. I've re-synced and restarted all services. Yet I still get this error when I try to push out a message:
Failed to prepare the message for sending:The orchestrator function 'SyncRecipientsOrchestrator' failed: "The activity function 'BatchRecipientsActivity' failed: "Object reference not set to an instance of an object.". See the function execution logs for additional details.". See the function execution logs for additional details.
EDIT: I am not sure how to find the function execution logs. If I had those, perhaps I could resolve this on my own.
Interestingly, today I was able to preview the message in the author Team channel, whereas up until now I could not. But sending the message out to a group still failed.
Previous issue
The previous issue about this stated "Attended the call and resolved the issue" but there are zero details about what was done to resolve it. Any help would be appreciated, as our global HR department has been waiting for a week to get this working.

Hi @dahazeman ,
Thanks for raising the query. Could you please respond to the below queries.

What is the version of the app?

Please share the application insight logs. Here is the reference.
Go to resource group-->Application Insights-->Under investigate click Failures. Please copy all the logs and send it in the form of file.

Share the screenshot of deployment status of App service.

Hi @gsv022
I think we are on version 5.4.

Is this the log information you were looking for?
BatchRecipientsActivity_error.txt

I may have found the source of the problem, but I don't know how to resolve it. I'm new to Azure storage but I used to be a .NET developer a number of years ago.
I was toggling the log info found on the Failures page described above. I came across the following:
11:01:59.947 AM	Request	Name: BatchRecipientsActivity, Successful request: false, Response time: 383.9 ms 11:01:59.977 AM	Trace	Severity level: Information, Message: Executing 'BatchRecipientsActivity' (Reason='(null)', Id=fba1b5d7-2176-4eda-8dd5-021da7648405) 11:01:59.996 AM	Dependency	Name: GET xxxxxxxxxxxxx/SentNotificationData, Type: Azure table, Call status: true, Duration: 10 ms, Data: https://xxxxxxxxxxxxx.table.core.windows.net:443/SentNotificationData?$filter=PartitionKey%20eq%20%272517163235375372990%27
Then I learned about Azure Storage Explorer and installed that. When I browse to the SendNotificationData table and filter with the PartitionKey value in the above GET call, it does return zero results.

Where is that PartitionKey value defined for the current process? Is it a configuration value, or linked to the current message that is being sent out?

I just noticed that the entire SentNotificationData table has not been updated since BEFORE I changed the GraphAppPassword client secret. I assume this is because the send function is failing and never getting around to logging anything.

We notice that there is a version change from time to time. Could you please confirm if the migration steps were followed correctly. If yes, please share the screenshots as mentioned in the v5 migration guide.

Hello @gsv022
Everything was working until the GraphAppPassword client secret expired. The last upgrade I performed explicitly was in December 2022 as seen in the screenshot above. Everything was definitely working fine after that, up until this client secret expiration. I only noticed the version number of 5.4 when you asked which version we were using, and since I saw it in that screenshot, I assumed that it occurred as some sort of automatic update when I initiated the redeployment on June 5, 2023 in an attempt to get things moving.
What do you suggest? Should I be going through the upgrade process as if I had mad a conscious decision to upgrade from 5.3 to 5.4, even though I didn't actually initiate that upgrade to get to where we are?

Hello @gsv022
I went through the upgrade steps in the v5 migration guide. Most configuration items were already set correctly, since it was coming from v5.3 to v5.4. Once the app service and all three functions had re-synced, and been restarted, I signed out and back into Teams.  I received the exact same error as mentioned in the initial post on this thread.

Does anyone else have any ideas? This has been going on for weeks and our global HR department is getting pissed that they can't send out any messages. One suggestion every three days is not very helpful  to me at this point. Please help.

Sure, but I'm deleting this comment as soon as you contact me @gsv022
<EMAIL_ADDRESS>

I have noted the id

Today I reviewed the v5 upgrade instructions again. Everything was fine. So then I reviewed the initial installation instructions. I found that the app registration authentication was no longer configured. https://github.com/OfficeDev/microsoft-teams-apps-company-communicator/wiki/Deployment-guide#3-set-up-authentication
I also found that the graph app permissions were lost and had to be re-selected and re-granted. https://github.com/OfficeDev/microsoft-teams-apps-company-communicator/wiki/Deployment-guide#4-add-permissions-to-your-microsoft-graph-azure-ad-app
After restarting the app service and the functions, I signed out and back into Teams. I tried sending a message again. It gave me an error on this call: GET /api/groupdata/verifyaccess
The client secret for the app registration which I had regenerated the other day was expired again...or so the message stated. The secret I had generated the other day was still there and valid. So I removed the 5 or 6 expired secrets and retried sending the message again. This specific error did not appear again, but I'm back to the very beginning of this thread...with the same error on the same BatchRecipientsActivity.
So around the circle we go again...

Thanks to @gsv022 for taking the time to contact me and go through our app instance. In the end, it turns out the client secrets for all three app registrations (primary app, authors, users) had expired.
In the app service config, find values for AuthorAppId, GraphAppId and UserAppId. Search app registrations for those three guid's. Each app registration has a client secret. When they expire, generate a new one and copy the value. Delete all expired secrets. Browse to the resource group for your app and find the key vault. Create new entries for each of: AuthorAppPassword, GraphAppPassword and UserAppPassword using the copied values from the new secrets (not the secret ID!! - be sure to enter the secret value). Set all old vault secret entries to Disabled. Copy the Secret Identifier for the enabled and current secret for each password. Paste those Identifiers (URL's) back in the app service and three functions, under AuthorAppPassword, AzureAd:ClientSecret (mapped to the Graph App password), GraphAppPassword and UserAppPassword. After updating the values on each of the app service and functions, save each and restart each (from the Overview page).

Issue resolved


cmd/go: unexpected exit codes for go tool ...

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
go version go1.7.1 linux/amd64

https://golang.org/cmd/vet/ says:

Vet's exit code is 2 for erroneous invocation of the tool, 1 if a problem was reported, and 0 otherwise.

The vet exit code is set by setExit function. A check of the source code in src/cmd/vet shows that there is no invocation like setExit(2). Should the doc be updated to reflect the code logic?

It's correct as is. It exits with code 2 if the arguments are incorrect, that is, if Usage is called.

go vet behaves as the documentation describes. But go tool vet does not.
$ go tool vet -h
$ echo $?
1

The go tool subcommand mishandles error codes. It's not disastrous but the codes are odd.
% go tool asdf
go tool: no such tool "asdf"
% echo $?
3
%

That one is due to an explicit setExitCode(3); it should be 2.
<errors>
% echo $?
2
% go tool vet -asdf
<same errors>
% echo $?
1
%

One would expect the go tool vet command to exit with the same code as go vet. Also, as one expects, the vet binary run without the go tool exits with 2 in this case.

This error, the second one above,
<errors>
% echo $?
2
% go tool vet -asdf
<same errors>
% echo $?
1
%

is not cleanly addressable because os.ProcessState does not tell you the failing exit code portably; in fact, the exit code is simply unix-specific. Might as well leave it alone; at least it's non-zero indicating command failure.

If we leave it alone, I think that the related description in https://golang.org/cmd/vet/ should be updated.


 We need to make money now that everyone blocked the crypto miner

best 12 loli of the year? Sound like business

That and 12 pictures of eigamma

Was thinking about this last night.  Easiest way would be to upload a bunch of wwyd into images and add them somwhere. Javascript is a bit limited about how to handle this, so I don't know if we can show everyone the exact same wwyd every day. Best I can do is:

A bunch of random wwyd images from the book.


Issue solved . Fix the pull request template. #85

Updated PR template !

The issue was not updating the content of the template. Problem was that the template was not working while making a PR. You need to fic it by using a yaml file.

Updated the pull request template pls check


Fix a typo in the specifics/mnesia lesson

Thank you @nscyclone, your help is really appreciated 😀


Update locale.js

Some French words was not correcly spelled or accorded.
This PR will fix that.

fyi I pushed https://github.com/mlamberts78/weather-chart-card/pull/201 with more fixes


Pageserver Python tests should not fail if the server is built with no testing feature

refer #2531
Hi!
NeonPageserverVersion purpose is to replace the static behaviour of def profiling_supported and def pageserver_enabled_features to skip the test if pageserver was compiled without "xxx" feature, the last one is not static because of the (self) but if we take a closer look we can see that it's not using the instance of NeonCli for nothing, hence the static behaviour.
I also checked the usage of  cached_property and it can be replaced with the standard functools.cached_property because neon currently does not support python <3.9 but that could be addressed in different PR.
Thanks!

I updated the branch and although i agree it's more correct because as you said the feature methods remains inside NeonPageserver i think it's less flexible, let me know if that's your approach @LizardWizzard  or i'm missing something.
Thanks for the reviews!

We have missed one small thing, that features are now named a bit differently, https://github.com/neondatabase/neon/pull/2654 highlighted that.
I'm going to merge-squash this PR and land a fix on top, for simplicity.

Fix: https://github.com/neondatabase/neon/pull/2659
Thank you again @andresrsanchez , that's the 3rd useful PR merged 🎉


IRLB8721 is NOT suitable

We have discovered that the IRLB8721 does not switch at all due to it needing current from Drain to Source for switching.
All schematics must be updated to use either the 2n7000 or the RFP30N06LE.

Thankfully i wasn't even able to get my hands on the IRLB8721 so im already using a 2n7000

So far, for the KiCAD schematics, I opted for SMD components, so I was using AO3400A mosfets instead of IRLB8721 mosfets. You think the schematics are still good with the AO3400A mosfets? I would assume we are still good, as the On-Resistance vs. Gate Voltage mentioned in the link you posted shows the mosfet not responding until it hits 4-5v, whereas the same graph for the AO3400A shows it responding at 2-3v.

Switching from IRLB8721 to another 2n7000 fixed it. I now have full control. What would the difference be with a RFP30N06LE (I have two more to build)?

I just built this project today, with the now-unsuitable IRLB8721. Can you define what symptoms arise from this? I’ve got the project successfully running but it seems most times I have to send commands twice for the garage door to respond, sometimes with delay. Curious if this IRLB8721 could be my issue? Logs in the web interface specify:
[component:214] | Component preferences took a long time for an operation (0.06 s).
[component:215] | Components should block for at most 20-30ms.
Thank you!

My symptom was I had complete status, but no commands would ever work.

Switching from IRLB8721 to another 2n7000 fixed it. I now have full control. What would the difference be with a RFP30N06LE (I have two more to build)?

2n7000 requires 3v to fully switch on whereas the RFPO30N06LE only needs 2 volts.  GPIO voltage is 3.3v which is borderline if there is any voltage sag.  So, reliable data transmissions might be an issue using 2n7000.

I just built this project today, with the now-unsuitable IRLB8721. Can you define what symptoms arise from this? I’ve got the project successfully running but it seems most times I have to send commands twice for the garage door to respond, sometimes with delay. Curious if this IRLB8721 could be my issue?

Yes, it could.  The issue with the IRLB8721 will be that it either does not switch the signal at all or will do it unreliably.  I don't know if your log entries are related but you could check the C++ code for those errors to see what the triggering conditions are.

So far, for the KiCAD schematics, I opted for SMD components, so I was using AO3400A mosfets instead of IRLB8721 mosfets. You think the schematics are still good with the AO3400A mosfets? I would assume we are still good, as the On-Resistance vs. Gate Voltage mentioned in the link you posted shows the mosfet not responding until it hits 4-5v, whereas the same graph for the AO3400A shows it responding at 2-3v.

They will be fine if you use the AO3400A as that's what the original design from Paul Wieland uses.

RFP30n06le is considered obsolete. Maybe find a better replacement option?

RFP30n06le is considered obsolete. Maybe find a better replacement option?

Hmm, maybe we just stick with the 2n7000?  I've had zero issues with mine.

I just built this project today, with the now-unsuitable IRLB8721. Can you define what symptoms arise from this? I’ve got the project successfully running but it seems most times I have to send commands twice for the garage door to respond, sometimes with delay. Curious if this IRLB8721 could be my issue? Logs in the web interface specify:
[component:214] | Component preferences took a long time for an operation (0.06 s). [component:215] | Components should block for at most 20-30ms.
Thank you!

I get that log as well, i don't actually think it's a real problem, i've seen it on a bunch of ESPhome projects

Thank you for this!  I'm fairly new to following schematics but I was fairly confident I had everything right.  I could see the correct status of everything, but I wasn't able to get any response when sending commands.  After swapping the IRLB8721 for a 2N7000, commands are now working as expected.
Ordered some RFP30N06LE already and will move this from a breadboard over to a proper ESP8266 shield.

RFP30n06le is considered obsolete. Maybe find a better replacement option?

Hmm, maybe we just stick with the 2n7000? I've had zero issues with mine.

I also second this, i have no issues with mine either.

I just built this project today, with the now-unsuitable IRLB8721. Can you define what symptoms arise from this? I’ve got the project successfully running but it seems most times I have to send commands twice for the garage door to respond, sometimes with delay. Curious if this IRLB8721 could be my issue?

Yes, it could. The issue with the IRLB8721 will be that it either does not switch the signal at all or will do it unreliably. I don't know if your log entries are related but you could check the C++ code for those errors to see what the triggering conditions are.

Update for anyone else troubleshooting! I replaced the IRLB8721 with a 2n7000 and everything is now working as expected. The IRLB was indeed the cause for my symptoms.
The 2n7000 currently seems to be successful, to tag on to others saying the same.

Well folks, what do we think?  @rlowens shall we just recommend a 2n7000 for through-hole and be done with it?  I haven't had a single issue.

Has anybody here had a problem with the 2n7000?

Has anybody here had a problem with the 2n7000?

I'm not sure how well it will work for the dry contact mode with no security. In my testing, it was not dropping voltage to zero like RFP30N06LE did: https://github.com/Kaldek/rat-ratgdo/issues/5#issuecomment-1786383189.
Switching serial line is one thing, but maybe it will have issues with an old-school control panel and LED when it needs to properly short it to the ground?
I didn't test it on the real device, so it might work just fine.

I think we should list several tested and possible parts and what problems they have/might have.
Browsing around digikey for MOSFETS similar to AO3400A (which the ratgdo v2.0 uses) found this:
FDU6512A (obsolete but in stock, $0.78/each)
IRLU3802PBF (active status, $0.48/each)
or these search results
Do any of those look good? I'm not an expert here.

I think we should list several tested and possible parts and what problems they have/might have.
Do any of those look good? I'm not an expert here.

Yeah unfortunately neither am I and that's how I got into the IRLB8721 mess.
I think I would be happy - for through-hole designs anyway - to recommend the 2n7000 as long as I can perform a test where I pull down the 12v line and measure the current flowing through the 2n7000 drain to source.  If it's less than 300 milliamps we should be fine.

I think we should list several tested and possible parts and what problems they have/might have.
Do any of those look good? I'm not an expert here.

Yeah unfortunately neither am I and that's how I got into the IRLB8721 mess.
I think I would be happy - for through-hole designs anyway - to recommend the 2n7000 as long as I can perform a test where I pull down the 12v line and measure the current flowing through the 2n7000 drain to source. If it's less than 300 milliamps we should be fine.

I'm interested to hear what the consensus is with the 2n7000.. I built a prototype today using the RFP30N06LE which I had to place on the opposite side of the PCB than the rest of the components due to its larger size (I have limited experience with this stuff so its the best I could do).. I would like to be able to just use another 2n7000 if possible as I'm using a small ESP8266 shield that's not much larger than the ESP itself.  I'm only using the 3 pins to connect to the opener itself (black/red/white).
This has been a fun project so far, definitely learning a lot.  Looking forward to Homekit / Homebridge support (which I saw is in development now).

Came here to mention RFP30N06LE was obsolete as per DigiKey.  Same question as rlowens: any recommended through-hole mount MOSFETs that would work other than the 2N7000?

I can confirm that RFP30N06LE works. And more reliably than my door with a 2N7000. The latter I often have to send commands twice, but with the former it works first time every time.

I can confirm that RFP30N06LE works. And more reliably than my door with a 2N7000. The latter I often have to send commands twice, but with the former it works first time every time.

Way to complicate my life as I was just about to commit to saying "use a 2n7000" 🤣

Well, I don't know where to ask, so I figured I'd ask here.  Couldn't we use optocouplers for this?  Aren't we simply replicating UART at a higher voltage level, on a single wire?
Mind you, I haven't fully studied the logic on the bus, but I'm doing this exact thing with a Honeywell alarm system at 12V logic level on the return line (has RX on the yellow line, but has both RX/TX on the green line).

Well, I don't know where to ask, so I figured I'd ask here. Couldn't we use optocouplers for this? Aren't we simply replicating UART at a higher voltage level, on a single wire?
Mind you, I haven't fully studied the logic on the bus, but I'm doing this exact thing with a Honeywell alarm system at 12V logic level on the return line (has RX on the yellow line, but has both RX/TX on the green line).

Well now, that's heading into ratgdo design territory which is a question more for Paul Wieland (if he'll answer it; I've been banned from commenting in his repo due to my efforts here).
As long as you can detect when the red wire is pulled to GND for a means of serial RX, and you can pull the red wire to GND as a means of serial TX, then you can choose to use whatever component you want!
I personally have used Optocouplers to mimic button presses in some personal projects, but I've never tried an optocoupler for switching at 9600bps.  I did ask good ol' ChatGPT 4 about this and the response was "you can try but be aware of issues related to capacitance, bandwidth, the length of the isolation barrier", etc.
Maybe a better way of putting this is that some of my older projects used optocouplers because I was worried about things that weren't actually a problem and could easily just have used a MOSFET.

https://www.mouser.com/datasheet/2/196/Infineon_IRLB8743_DataSheet_v01_01_EN-3363390.pdf specs look better then the IRLB8721. I don't plan on switching mine out, so someone else wants to try this one.

https://www.mouser.com/datasheet/2/196/Infineon_IRLB8743_DataSheet_v01_01_EN-3363390.pdf specs look better then the IRLB8721. I don't plan on switching mine out, so does someone else want to try this one?

That's worse!  It's input capacitance is 5 times that of the IRLB8721 and that's what we believe is causing the IRLB8721 to not switch when driven by the ESP8266.

Oh well, like I said, I only barely know what I'm talking about. I was looking at the R(DS) vs. V graph of both. The 8721 resistance doesn't drop significantly until nearly 5V.

The issue here is that the most suitable MOSFETs are the AO3400A as used in the original ratgdo PCB or a BSS138 (very similar).  Both are SMD, not through-hole.
For TO-92 it's really limited and so far it looks like the 2n7000 but it might depend on the batch you get as to how happily it switches at 3.3 volts.

One option for through-hole/breadboard design would be to get the original AO3400A and a SOT23-3 to DIP adapter.

One option for through-hole/breadboard design would be to get the original AO3400A and a SOT23-3 to DIP adapter.

Bugger me, if it's that easy we should just recommend this.

Welp I just got my shipment of RFP30N06LE!  However, I’m wondering if that model can be used for both MOSFETs?  I don’t have any 2N7000s handy.

Welp I just got my shipment of RFP30N06LE! However, I’m wondering if that model can be used for both MOSFETs? I don’t have any 2N7000s handy.

Can't hurt to try; on RX you're using a 12v trigger to drive the MOSFET on/off and therefore pull 3.3v low or not on the RX pin of the ESP.  If you can see data on the bus, it's working fine.

Can't hurt to try;

Well, can't it? The "Absolute Maximum Rating, Gate to Source Voltage" is +10V for the RFP30N06LE  so I think it might not survive 12V.

Can't hurt to try;

Well, can't it? The "Absolute Maximum Rating, Gate to Source Voltage" is +10V for the RFP30N06LE  so I think it might not survive 12V.

Ah I missed that.  Too many stats, too little time.  😬

I can confirm that RFP30N06LE works. And more reliably than my door with a 2N7000. The latter I often have to send commands twice, but with the former it works first time every time.

Way to complicate my life as I was just about to commit to saying "use a 2n7000" 🤣

Mine using 2x 2N7000's seems to work the first time every time, haven't had to resend any commands.

I can confirm that RFP30N06LE works. And more reliably than my door with a 2N7000. The latter I often have to send commands twice, but with the former it works first time every time.

Way to complicate my life as I was just about to commit to saying "use a 2n7000" 🤣

Mine using 2x 2N7000's seems to work the first time every time, haven't had to resend any commands.

Yeah same here.  We're going to pivot to recommending the AO3400A mounted to a SOT23 to DIP converter board.  It just simplifies everything as the "recommended option".   Even though the 2n7000 works for many.

I can confirm that RFP30N06LE works. And more reliably than my door with a 2N7000. The latter I often have to send commands twice, but with the former it works first time every time.

Way to complicate my life as I was just about to commit to saying "use a 2n7000" 🤣

Mine using 2x 2N7000's seems to work the first time every time, haven't had to resend any commands.

Just built my first one tonight. Worked first time every time with 2x 2N7000s. Didn't know about this issue, but noticed the pics showed 2x 2N7000s, and yoloed it even though I also bought the other transistor.

Yeah it's weird.  My ESP8266 is putting out 3.2 volts and seems to switch the 2n7000 reliably.

Yeah it's weird. My ESP8266 is putting out 3.2 volts and seems to switch the 2n7000 reliably.

Mine is also reliable

Well I built my second one and used a RFP30N06LE this time, works about the same except for I get errors on that one that say:
00:24:21 | [W] | [component:214] | Component preferences took a long time for an operation (0.07 s).
00:24:21 | [W] | [component:215] | Components should block for at most 20-30ms.

I suppressed the errors because otherwise it works perfectly but I wonder if it has something to do with that MOSFET.  Maybe it's a little slower?

Well I built my second one and used a RFP30N06LE this time, works about the same except for I get errors on that one that say:
00:24:21 | [W] | [component:214] | Component preferences took a long time for an operation (0.07 s).
00:24:21 | [W] | [component:215] | Components should block for at most 20-30ms.

I suppressed the errors because otherwise it works perfectly but I wonder if it has something to do with that MOSFET. Maybe it's a little slower?

I saw that with my first one I built with a 2n7000, but not the RFP30N06LE ones. Go figure. But yeah, I wouldn't worry about it.

It's probably internal differences between the two openers I have then. I would check by swapping the ratgdo's but I don't want to... 😁

Recommending sn7000 for through-hole and closing this issue.  SMD recommendations will stick with what Paul Wieland uses.

FAQ.md still mentions IRLB8721


You may remove NoErrorsPlugin with React Hot Loader 1.3.0

React Hot Loader 1.3.0 fixes a problem that caused NoErrorsPlugin to be necessary. In fact now errors thrown on module level shouldn't prevent future hot reloading of the same file after you fix the problem.
Please update to RHL 1.3.0, and remove NoErrorsPlugin from Webpack configuration.
Thanks!

Thank you! :100:
fixed in: https://github.com/fc-io/react-tape/commit/83ae5beedbc2fc79bf93901db6282c5b33eed0cc


chore: strict origin enforcement

Issue #129
Description of changes:
Added setOrigin method for iOS, Android and RN wrapper.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Validated working on devices

Hello, @vnovick @dawhitla when do you think this change is gonna be published?
Thanks in advance)


Adding a new game: Mexico Escape [gssoc23]

PR Description 📜
Based on mexico theme, a spice is moving and it had to jump over the obstacles, it has some immunity so some of obstacles doesnt effect it
Fixes #2456

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @thevirengarg ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Thank you  @thevirengarg , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀


Annotate init with type hints

This just adds the annotations found at run-time to the
__annotations__ attribute of the created __init__ function
Fixes #249
Pull Request Check List
This is just a reminder about the most common mistakes.  Please make sure that you tick all appropriate boxes.  But please read our contribution guide at least once, it will save you unnecessary review cycles!

[ ] Added tests for changed code.
[ ] New features have been added to our Hypothesis testing strategy.
[ ] Updated documentation for changed code.
[ ] Documentation in .rst files is written using semantic newlines.
[ ] Changed/added classes/methods/functions have appropriate versionadded, versionchanged, or deprecated directives.
[ ] Changes (and possible deprecations) have news fragments in changelog.d.

If you have any questions to any of the points above, just submit and ask!  This checklist is here to help you, not to deter you from contributing!

I’m vacationing until Easter.
🇮🇹 is pretty awesome. #protip #lifehack
Maybe you can bribe Tin to have a look. 😇
I trust the approach is sound.

Also obligatory ping @ambv


merge from arlac77/npm-package-template-esm-only

.travis.yml

chore(travis): (jobs.include)
chore(travis): add 12.13.0 remove 12.12.0 (jobs.include.node_js)
chore(travis): (script)

Coverage remained the same at 88.375% when pulling 8119646f0de656b2dd3cf269cb021d4f307414fd on npm-template-sync/1 into 6220e084747628d579789e8b0f6fa338f79f8607 on master.

:tada: This PR is included in version 4.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


run pubsub_view throw ice candidate exception

signal server is latest version ion from master branch
ion.JsonRPCSignal('wss://ip:8443/ws?uid=uuid');
debug with chrome
[ion-sdk-flutter] DEBUG: msg: {"id":"1f924ff8-b9a2-4ce0-9605-27d55c094474","result":{"type":"answer","sdp":"v=0\r\no=-<PHONE_NUMBER>167300290<PHONE_NUMBER> IN IP4 <IP_ADDRESS>\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 23:09:0D:BF:64:D4:18:83:DA:AA:5B:04:78:54:19:40:CF:97:2E:C7:9F:12:88:D3:4E:6F:58:BF:1C:22:17:A5\r\na=group:BUNDLE 0\r\nm=application 9 DTLS/SCTP 5000\r\nc=IN IP4 <IP_ADDRESS>\r\na=setup:active\r\na=mid:0\r\na=sendrecv\r\na=sctpmap:5000 webrtc-datachannel 1024\r\na=ice-ufrag:qilePTdhhPsHBOiG\r\na=ice-pwd:DSfSezGroySAPKMCmIaXedWTbJVNQnDQ\r\n"},"jsonrpc":"2.0"}
errors.dart:167 Uncaught (in promise) Error: OperationError: Error processing ICE candidate
at Object.createErrorWithStack (errors.dart:249)
at Object._rethrow (async_patch.dart:200)
at async._AsyncCallbackEntry.new.callback (zone.dart:1171)
at Object._microtaskLoop (schedule_microtask.dart:41)
at _startMicrotaskLoop (schedule_microtask.dart:50)
at async_patch.dart:166

[ion-sdk-flutter] DEBUG: send: {"method":"trickle","params":{"target":0,"candidate":{"candidate":"candidate:4193552346 1 udp<PHONE_NUMBER> <IP_ADDRESS> 63938 typ srflx raddr <IP_ADDRESS> rport 63938 generation 0 ufrag FLU7 network-id 2 network-cost 10","sdpMid":"2","sdpMLineIndex":2}}}
errors.dart:167 Uncaught (in promise) Error: Expected a value of type 'String', but got one of type 'DomException'
at Object.throw_ [as throw] (errors.dart:216)
at Object.castError (errors.dart:64)
at Object.cast [as as] (operations.dart:442)
at Function.as (core_patch.dart:650)
at logger.Logger.new.error (logger.dart:7)
at client$.Client.new.onnegotiationneeded (client.dart:163)
at onnegotiationneeded.throw ()
at async_patch.dart:60
at _RootZone.runBinary (zone.dart:1451)
at _FutureListener.thenAwait.handleError (future_impl.dart:157)
at handleError (future_impl.dart:708)
at Function._propagateToListeners (future_impl.dart:729)
at _Future.new.[_completeError] (future_impl.dart:537)
at async._AsyncCallbackEntry.new.callback (future_impl.dart:593)
at Object._microtaskLoop (schedule_microtask.dart:41)
at _startMicrotaskLoop (schedule_microtask.dart:50)
at async_patch.dart:166

Hi bro, just comment this line can fix your problem

Hi bro, just comment this line can fix your problem

Thanks, you are right, but I got another exception, Do you have the same problem?
errors.dart:187 Uncaught (in promise) Error: OperationError: Error processing ICE candidate
at Object.createErrorWithStack (errors.dart:269)
at Object._rethrow (async_patch.dart:200)
at async._AsyncCallbackEntry.new.callback (zone.dart:1339)
at Object._microtaskLoop (schedule_microtask.dart:40)
at _startMicrotaskLoop (schedule_microtask.dart:49)
at async_patch.dart:166

Thanks, you are right, but I got another exception, Do you have the same problem?
errors.dart:187 Uncaught (in promise) Error: OperationError: Error processing ICE candidate
at Object.createErrorWithStack (errors.dart:269)
at Object._rethrow (async_patch.dart:200)
at async._AsyncCallbackEntry.new.callback (zone.dart:1339)
at Object._microtaskLoop (schedule_microtask.dart:40)
at _startMicrotaskLoop (schedule_microtask.dart:49)
at async_patch.dart:166

Check your code again. I don't have any issues like this

Check your code again. I don't have any issues like this


4-byte UTF-8 character in package description can break repositories

I'm afraid this is a bit of a 'WTF' thing. I was trying to use a hosted package repository, and discovered that trying to upload a wheel for requests failed. Some back and forth revealed an interesting reason: they store package description in MySQL, and MySQL can't normally store 4-byte UTF-8 sequences. And it so happens the cake symbol you are using for the pip install example is a 4-byte UTF-8 character.
Considering this is not a bug in requests and the limitation is completely silly I hate to ask this, but still: could you consider using another replacing that cake symbol with something else so we won't hit that limitation?

Uh...I mean, we could. But it seems like that's just deferring the problem until later in the day. At some point the hosted package repository is going to need to deal with the full breadth of UTF-8. I feel like it'd be for the good of the world to hold Requests hostage behind dealing with this issue!
 I recommend either moving to a different package host or threatening to do so unless they fix the issue.

I recommend either moving to a different package host or threatening to do so unless they fix the issue.

I second that. I doubt Requests is the only package that will cause you this pain. Asking each one as it pops up to "fix" this (instead of the hosted repository fixing it) seems really kind of unreasonable.


config/v1: Change ClusterVersion capability from 'console' to 'Console'

The lowercase form just landed via 9db3a0ce01 (#1232), CC @raspbeep, and that matched the lower-case precedent which we had been using for these enumerated capabilities.  But the Kube-API preference is for PascalCase, so this commit pivots to that form.  Because we are so close on the heels of the original change, we don't need to preserve any references to the outgoing form.  Adjusting the 4.11 references like openshift-samples will take more dancing, and can happen in follow-up
work.  Generated with:
$ sed -i 's|\(capability[.]openshift[.]io/name\): console|\1: Console|' $(git grep -l 'capability.openshift.io/name: console')
$ sed -i 's/console/Console/' config/v1/*version*

And then backing out one godocs hit that the above made:
$ sed -i 's/the web Console/the web console/' config/v1/*version*

/lgtm


Ping Charts

The metric charts shows wrong amount of ping, if i ping the site on my vps, it says 84ms ping however the graph is showing 400ms

It depends on the time it takes to get the response from the server, try using a HEAD check instead of GET


chore(db-*): update drizzle-kit and drizzle-orm

Description

[ ] I have read and understand the CONTRIBUTING.md document in this repository.

Type of change

[ ] Chore (non-breaking change which does not add functionality)
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Change to the templates directory (does not affect core functionality)
[ ] Change to the examples directory (does not affect core functionality)
[ ] This change requires a documentation update

Checklist:

[ ] I have added tests that prove my fix is effective or that my feature works
[ ] Existing test suite passes locally with my changes
[ ] I have made corresponding changes to the documentation

This was implemented in other PRs


feature(motor-control, can): implement the stop message

RET-1252
RET-1291

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@ff206fb). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #516   +/-   ##
=======================================
  Coverage        ?   83.24%
=======================================
  Files           ?       88
  Lines           ?     2751
  Branches        ?        0
=======================================
  Hits            ?     2290
  Misses          ?      461
  Partials        ?        0


Models web app Roadmap

Lets use this issue to discuss the roadmap of the newly added web app and document the next steps. Also really looking forward to hear users' feedback and what features people would like to see, so if you have something in mind feel free to chime in!
These are some of the things I was planning to work on:

Integration/e2e/unit tests #1507 #1506, which will allow us to ensure that new features won't break existing functionalities
Move the Angular UI framework to version 11, from 8 which is the current version for most of Kubeflow's apps https://github.com/kubeflow/kubeflow/issues/5525
Performance improvements by replacing the current poling mechanism with a more efficient implementation

Use persistent connections via browser-APIs/protocols, like WebSockets, Server-Side-Events etc instead of polling
Have the UI perform a persistent watch operation on the API server to efficiently detect changes

Further integrate the app's METRICS tab with KFServing's monitoring solution
Support for Multi Model Architecture

Exposing information about the TrainedMoleds of an InferenceService when listing the InferenceServices in a namespace
Allow users to create/delete/manage the TrainedModels that belong to an InferenceService

Enhance the UX of creating a new InferenceService via the UI

Don't simply expect user to submit a YAML, but also provide an intuitive workflow for configuring the different parts of an InferenceService
Support for also launching TrainedModel CRs

cc @yuzisun @pvaneck @animeshsingh @StefanoFioravanzo @elikatsis @tasos-ale

Do we plan to integrate KFServing UI with Kubeflow web UI?

@goswamig I missed this, thanks for pointing it out! Correct, we should add an entry in Kubeflow's CentralDashboard for this web app as well.
I'll also create a tracking issue for this.

I've come up with a solution that will allow for namespace isolated Grafana dashboards without running multiple instances of Grafana (which also wouldn't work from an isolation standpoint). I think it will be important to explore this with multiple working groups, as I'm sure many of them would like to have integrated metrics dashboards.
@kimwnasptd Can you explain how you are implementing Grafana authentication with the current integration in the Models Web App? Or have you enabled anonymous viewing in Grafana for the integration to work?

Can't deploy Model UI to local kubeflow now?

Hi @nongqiqin, could you create a distinct issue for this so that we can further investigate there?

Hi @nongqiqin, could you create a distinct issue for this so that we can further investigate there?

Found a solution, 3Q


Greasemonkey script to manage GitHub issues as in progress (set start position) and done project stories

Moved here: https://github.com/home-page/home_page_developer/issues/4


Answering the call from phone.

Usually if the wired android auto is connected, we would be able to answer the incoming calls from phone and while dialling outgoing from phone we would have option for choosing phone or car. I would appreciate if we have any possibilities to bring that option over here..

Yes.. using OnePlus 11.. caller details and answering options won't be available in phone during incoming calls.l, just ringtone alone. For outgoing, the moment I chose the eom to dial, phone comes back to home screen and the call will be initiated from car..

Yes.. using OnePlus 11 and pi zero 2w..  caller details and answering options won't be available in phone during incoming calls. just the ringtone alone. For outgoing, the moment I chose the sim to dial, phone comes back to home screen and the call will be initiated from car..

Has worked perfectly for me on a Galaxy Note 10, 20, and s21 ultra, as well as Pi Zero 2 w and Pi Zero w.
Do you not have the option to change your call's audio output device when connected?

Your comment awaken me... I was using odialer( belongs to OnePlus) just changed to Google default dialer and found its working flawless as expected.. tested it again by changing back odialer and surprised that is also working with out any issues.. 🙂 🙂 🙂
Cheers, thanks again for your comment, which made me to think from phone, instead of wireless AA code...


Add support for windows-1252 character encoding

iconv-lite supports windows-1252 and is already in the dependency tree for nodemailer: https://www.npmjs.com/package/iconv-lite
Create Middleware for Encoding Conversion
You need to create a middleware that checks the Content-Type of the response and converts the content to CP1252 if required.
const iconv = require('iconv-lite');

function cp1252Middleware(req, res, next) {
    const originalSend = res.send;

    res.send = function (data) {
        if (res.getHeader('Content-Type') === 'text/plain; charset=windows-1252') {
            if (typeof data === 'string') {
                data = iconv.encode(data, 'cp1252');
                // Set the correct Content-Length for the encoded data
                res.setHeader('Content-Length', Buffer.byteLength(data));
            }
        }

        originalSend.apply(res, [data]);
    };

    next();
}

Use the Middleware in Your Express Application
You must apply this middleware to your Express application. It should be added before any routes that may send text/plain; charset=windows-1252 responses.
const express = require('express');
const app = express();

// Use the cp1252 encoding middleware
app.use(cp1252Middleware);

// Example route
app.get('/', (req, res) => {
    res.setHeader('Content-Type', 'text/plain; charset=windows-1252');
    res.send('Hello, this is some text that will be encoded in CP1252!');
});

// Start the server
const PORT = 3000;
app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});

Closed as completed in #4594


Launch training jobs

it seems that there is a issue when you launch for the first time a training jobs.
In base_training_job.py line 203 you check if the checkpoint subfolder exists and if not you create it. However this directory is a child of log_folder/training_job_name
Then line 217 you check if the log folder : log_folder/training_job_name exists in order to know if the training should init it and the parameters or used a checkpoints.
The issue is that this folder is sure to exists as you just created it before line 203. At this point the boolean __found_job_folder is True. This means that a file ".yml" should be present which is not the case.
And so when we go in __initialize_training_job() instead of saving the parameters we try to load it (line 747),
and then an error is raised in __load_training_parameters()

I think this is a bug and have tried to fix it. Please refer to PR https://github.com/MIT-SPARK/PD-MeshNet/pull/10


When depositing items at the bank, they disappear momentarily.

https://cdn.discordapp.com/attachments/442492468307427330/1096596190071640144/RuneLite_-_Boynk_2023-04-14_19-00-52.mp4

Came here to say this as well, plugin currently seems to be broken.

Oops, yeah that's a problem.
I think the problem is that I'll always hide items when your deposit any amount.
The workaround is to disable/untick the Deposit Items Instantly feature for now

Fixed in v1.1.1


docs: icq

Description
Describes an ICQ methodology that allows for security, economic incentive, and low-latency.

Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...

[ ] included the correct type prefix in the PR title
[ ] added ! to the type prefix if API or client breaking change
[ ] added appropriate labels to the PR
[ ] targeted the correct branch
[ ] provided a link to the relevant issue or specification
[ ] added a changelog entry to CHANGELOG.md
[ ] included comments for documenting Go code
[ ] updated the relevant documentation or specification
[ ] reviewed "Files changed" and left comments if necessary
[ ] confirmed all CI checks have passed

Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...

[ ] confirmed the correct type prefix in the PR title
[ ] confirmed all author checklist items have been addressed
[ ] reviewed state machine logic
[ ] reviewed API design and naming
[ ] reviewed documentation is accurate
[ ] reviewed tests and test coverage
[ ] manually tested (if applicable)

Some ideas from today's discussion on this:

Do we have to bake in an economic model now?
How could we get rid of the encryption portion? (Could we charge for requesting proofs on Ojo?)

I think we could go with the discord nitro model. Launch free without the encryption mechanic, and then allow people to pay a premium for relayer priority, which the relayer could then receive rewards for. This way anybody can set up the relayer.

For the time being we'll be separating out the development of the "host" module into a separate design document


Preprocessed Chess Puzzle Data

Hi,
I was trying to reproduce the results for the chess puzzle dataset and it seems like the original dataset was preprocessed to convert FEN positions to a set of moves. But there can be multiple set of moves to reach a specific board position. Is it possible for you to share the preprocessing script or the preprocessed data used in the experiments.
Thanks,
Satya

Thank

Hi all,
Bumping this up in case there is anything I am missing or if there is any other info needed from my end.
-Satya

i believe the data for the sequence of moves exists somewhere, @pavel-izmailov would know details

Hey @y12uc231, the original data from lichess is indeed in FEN notation, but also each puzzle is extracted from a real game. You can find a database of puzzles as a csv here. Each entry should contain a game id from which the position was extracted. Then, you can use the lichess api to extract the game from its id, and convert it to a move sequence notation.


Future plans question

Hello,
Will this project from now on be maintained independently from redux-async-connect or will it be eventually merged back? Will any future redux-async-connect changes be merged or otherwise integrated here?
Thanks

Because there was no traction, nor any answers to dozens of questions on the previous repo - I made the decision to refactor the codebase and maintain it myself. Redux-connect used in multiple projects I'm working with and that should alone be enough to support this going forward.
As always, I'd gladly welcome other contributors that would help maintain this - part of the OSS being successful is a great community around it. I hope this answered your question.
As for the dev plans themselves - I want to hear more about use-cases that are not supported, or something that takes up too much code. One of the ideas is to make an automatic isLoaded check - it's often controversial though.

Closing this, hopefully it resolved your question


Create a beta branch

So i can upload every finished feature so i can pull the beta to the master once a update is done

done since two days u baka >_>


tf.contrib.learn Quickstart: float64 Warning

NOTE: Only file GitHub issues for bugs and feature requests.  All other topics will be closed.
For general support from the community, see StackOverflow.
To make bugs and feature requests more easy to find and organize, we close issues that are deemed
out of scope for GitHub Issues and point people to StackOverflow.
For bugs or installation issues, please provide the following information.
The more information you provide, the more easily we will be able to offer
help and advice.
What related GitHub issues or StackOverflow threads have you found by searching the web for your problem?
Environment info
Operating System:
Fedora release 23 (Twenty Three)
Installed version of CUDA and cuDNN:
GPU does not support computation :. no CUDA
NVIDIA Corporation GM107 [GeForce GTX 745]
(please attach the output of ls -l /path/to/cuda/lib/libcud*):
ls: No match.
If installed from binary pip package, provide:

A link to the pip package you installed:
Linux CPU Python 2.7
https://storage.googleapis.com/tensorflow/linux/cpu/tensorflow-0.10.0-cp27-none-linux_x86_64.whl
The output from python -c "import tensorflow; print(tensorflow.__version__)".
0.10.0

If installed from source, provide

The commit hash (git rev-parse HEAD)
The output of bazel version

If possible, provide a minimal reproducible example (We usually don't have time to read hundreds of lines of your code)

Copy Past code from tf.contrib.learn Quickstart
https://www.tensorflow.org/versions/r0.10/tutorials/tflearn/index.html#tf-contrib-learn-quickstart
Run the Code
observe the float64 Warnings.
Note:  replace 'load_csv()' with 'load_csv_with_header()' produces the correct Prediction. but float64 warnings remain.

Is there a way to work around this and remove the warnings?
What other attempted solutions have you tried?
Tried
in 'training_set' and 'test_set'
target_dtype = np.int32 ; np.float32; tf.int32; tf.float32
in 'new_samples'
dtype = np.int32 ; np.float32; tf.int32; tf.float32
feature_columns = tf.cast(feature_columns, tf.float32)
Logs or other output that would be helpful
(If logs are large, please upload as attachment or provide link).
$ python confErr.py
WARNING:tensorflow:load_csv (from tensorflow.contrib.learn.python.learn.datasets.base) is deprecated and will be removed after 2016-09-15.
Instructions for updating:
Please use load_csv_{with|without}header instead.
WARNING:tensorflow:load_csv (from tensorflow.contrib.learn.python.learn.datasets.base) is deprecated and will be removed after 2016-09-15.
Instructions for updating:
Please use load_csv{with|without}_header instead.
WARNING:tensorflow:Using default config.
WARNING:tensorflow:float64 is not supported by many models, consider casting to float32.
WARNING:tensorflow:Setting feature info to TensorSignature(dtype=tf.float64, shape=TensorShape([Dimension(None), Dimension(4)]), is_sparse=False)
WARNING:tensorflow:Setting targets info to TensorSignature(dtype=tf.int64, shape=TensorShape([Dimension(None)]), is_sparse=False)
WARNING:tensorflow:float64 is not supported by many models, consider casting to float32.
WARNING:tensorflow:Given features: Tensor("input:0", shape=(?, 4), dtype=float64), required signatures: TensorSignature(dtype=tf.float64, shape=TensorShape([Dimension(None), Dimension(4)]), is_sparse=False).
WARNING:tensorflow:Given targets: Tensor("output:0", shape=(?,), dtype=int64), required signatures: TensorSignature(dtype=tf.int64, shape=TensorShape([Dimension(None)]), is_sparse=False).
Accuracy: 0.966667
WARNING:tensorflow:float64 is not supported by many models, consider casting to float32.
Predictions: [1 1]

Thanks for the report, @qweelar. Looking into this issue with the tutorial code.

Hi @qweelar, the float64 warning is due to a bug with the load_csv_with_header function that was fixed in commit b6813bd. This fix isn't in TensorFlow release 0.10, but should be in the next release.
In the meantime, for the purposes of the tf.contrib.learn quickstart, you can safely ignore the float64 warning.
(Side note: In terms of the other deprecation warning, I will be updating the tutorial code to use load_csv_with_header, and will update this issue when that's in place.)

Cool thanks for the updates @sandersk


Serde 2.0

I propose to re-work how we currently serialise and deserialise objects.
Our current design aims at solving these two issues:

serialisation / deserialisation of objects
validation of parameters

For example:
class MyClass:
    @validated()
    def __init__(self, a: int, b: int):
        self.a = a
        self.b = b

# parameters are validated,
# such that passing invalid arguments raises an error
instance = MyClass(a=1, b=2)

# We can simply dump and load objects.
# It's a bit like pickle, but is aimed at producing json output
from gluonts.core import serde
from gluonts.core.component import equals

assert equals(instance, serde.decode(serde.encode(instance)))

There are two problems in my view:

Most people do not know how validated works.
We only support objects, which can be recreated by passing the same arguments.

pickle API
We currently use pickle's __getnewargs_ex__ to encode objects:
    if hasattr(v, "__getnewargs_ex__"):
        args, kwargs = v.__getnewargs_ex__()  # mypy: ignore
        return {
            "__kind__": kind_inst,
            "class": fqname_for(v.__class__),
            "args": encode(args),
            "kwargs": encode(kwargs),
        }

I'm unsure if this is good, since we assume that we can also encode an object's parameters, which might not always be the case. Put differently, implementing __getnewargs_ex__ promisies that the returned arguments can be pickled, but not that they can be encoded. If we have our own interface, that contract is more explicit.
Stateful Objects
We currently don't have a way to encode custom stateful objects.
Looking at pickle, it uses the contents of an objects __dict__ to store the state by default.
Pickle also has __getstate__ and __setstate__ methods, which offer more control:
class MyClass:
    def __init__(self, upper):
        self.number = random.randrange(1, upper)

    def __getstate__(self):
        return self.__dict__

    def __setstate__(self, state):
        self.__dict__ = state

Proposal

Expose a clear protocol to customize object serialisation and deserialisation.
Have more natural interface than validated for the common-usecase.

Protocol
I think we should add bevaviour similar to __getstate__/__setstate__.
Further, I think we should use custom method-names to be more explicit and avoid confusion with pickle.
Better Interface
The main reason validated exists that way is that object initialisation is often more complicated than just assigning the arguments. For example, when some arguments depend on others:
class MyEstimator:
    @validated()
    def __init__(
        self,
        prediction_length: int,
        context_length: Optional[int]
    ):
        self.prediction_length = prediction_length
        if context_length is None:
            self.context_length = 2 * prediction_length
        else:
            self.context_length = context_length

Instead we could use something like this:
class MyEstimator(SerdeObject):
    prediction_length: int
    context_length: Optional[int] = None

    __defaults__ = {
        "context_length": lambda self: 2 * self.prediction_length,
    }

Thanks @jaheba.
I agree that the current mechanism is a bit strange, however, it does seem to work in practice and as a user I only have to know that I have to add @validated and things magically work.
Could you give a few more examples for how this would look like for the user with you proposed change?
One thing we should support is serialization/deserialization of classes that are/contain gluon HybridBlocks and their weights.


Cannot install package without version

Hi,
First of all, thanks for writing this great package.
I am using it for a few weeks now, and today I came across an issue that I cannot get solved.
I might overlook something, and i hope someone can point me in a direction.
Problem is that i cannot install a package called soundmanager2.
Reason is that the package does not has any versions defined.
When i search for the package, i get these results:
root@dev:/srv/www/site# bin/bower search soundmanager2
#!/usr/bin/env php
Search results:
soundmanager git://github.com/scottschiller/SoundManager2.git
soundmanager2 git://github.com/scottschiller/SoundManager2.git
angular-soundmanager2 git://github.com/perminder-klair/angular-soundmanager2.git
backbone.soundmanager2 git://github.com/audiosocket/backbone.soundmanager2.git
armory-blrrtstrap-soundmanager2 git://github.com/psirenny/armory-blrrtstrap-soundmanager2.git
soundmanager2-297a20140901 git://github.com/akarca/SoundManager2-1.git
soundmamager2 git://github.com/scottschiller/SoundManager2.git

I then go ahead and install soundmanager2, the latest release:
root@dev:/srv/www/site# bin/bower install soundmanager2#latest
#!/usr/bin/env php
Cannot find package soundmanager2 version latest.
If i leave out the version part, i still have no success:
root@dev:/srv/www/site# bin/bower install soundmanager2
#!/usr/bin/env php
Cannot find package soundmanager2 version *.
Is there some way i can get this package installed?
In this case it would be sufficient if it just uses the latest commit.
Any help would be appreciated.
Thanks!

This is a know issue, see #113 and #128
We still need to implement installation from a git URL or http URL.
If you want to implement such feature, feel free to open a pull request.

OK, thank you.


Add callback when a PlatformView is added to native view hierarchy

Use case
The first party interactive_media_ads plugin uses a PlatformView to display ads. However, ads can't be requested until the PlatformView has been added to the native View hierarchy. The UiKitView contains the PlatformViewCreatedCallback which returns when the View is created, but not when it has been added to the View hierarchy.
I was able to workaround this with a delay, so this is not a blocker:
return UiKitView(
      key: _iosParams.key,
      viewType: 'interactive_media_ads.packages.flutter.dev',
      onPlatformViewCreated: (_) async {
        adDisplayContainer = _iosParams._imaProxy.newIMAAdDisplayContainer(
          adContainer: _controller.view,
          adContainerViewController: _controller,
        );
        // Without this delay, the IMA SDK returns an error:
        // Ads cannot be requested because the ad container is not attached to the view hierarchy.
        await Future.delayed(Duration(seconds: 1));
        params.onContainerAdded(this);
      },
      creationParams:
          // ignore: invalid_use_of_protected_member
          _controller.pigeon_instanceManager.getIdentifier(_controller.view),
      creationParamsCodec: const StandardMessageCodec(),
    );

Note that on Android, the view is added to the hierarchy when it is created:  https://github.com/flutter/engine/blob/main/shell/platform/android/io/flutter/plugin/platform/PlatformViewsController.java#L598
I'm not familiar with the PlatformViews on iOS, so I don't know where to quickly check when it is added.
Proposal
This issue proposes a new callback for UIKitView called onPlatformViewAdded or change the creation of the PlatformView to not return until the View is added.

cc @cbracken

@johnmccutchan are you still planning on working on this, or shall I unassign you?


Connect up the filesystem

It would be great to have it search up the file tree to find a yml config

Is this done yet?

I don't see any changes?

@abocskocsky Great suggestion!
I made modifications so that if a config filename is not specified, it falls back to one of two options:

a konnect.yml file in the current directory.
a konnect.yml file in the parent directory.

Planning to release this functionality in Konnect - 1.0.0


Deserialize a serde_json::Value

It looks like bincode is not able to serialize a struct containing fields of type serde_json::Value.
For instance the following example:
use serde::{Deserialize, Serialize};
use serde_json::Value;

#[derive(Serialize, Deserialize)]
struct Test {
    value: Value,
}

#[cfg(test)]
mod tests {
    use serde_json::json;

    use super::*;

    #[test]
    fn test() {
        let t = Test { value: json!("{}") };
        let ser = bincode::serialize(&t).unwrap();
        let de: Test = bincode::deserialize(&ser).unwrap();
    }
}

Produces this error:
 panicked at 'called `Result::unwrap()` on an `Err` value: DeserializeAnyNotSupported'

Any idea how to solve this issue? Or is bincode not suited for this kind of usecase?

Bincode is not a self-describing format which makes it not compatible with serde_json::Value. This is a fundamental limitation and so far there hasn't been a proposed solution.


[WIP]Update Table docs for horizontal scrolling

Description
Adds clarification on the width layout process for Table columns.
I considered adding an assert somewhere to help catch and explain the case where the Table does not render anything (width == 0.0), but it seems valid to have a table with 0 width in other use cases. Not sure where I can reliably identify the use case and alert the developer.
Related Issues
Fixes #38526
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.

I pushed up some changes from another branch by accident, doing a bit of clean up now. 🤦


[WIP] Adding Docker version of Prism

Here is what it would look like to add a Dockerized version of a metric.

Hey, given the discussions in the chat, should we merge this so we can proceed with adding the other implementations?

I think it should be ok. My only concern is how to deal with the GPU device. It seems like the other GPU-based metrics don't manually control the device, but this is necessary for the Dockerized metrics or else they will just use GPU 0.
When you run something in Docker, the code run in Docker runs in its own process, so the CUDA_VISIBLE_DEVICES environment variable you might set from the command line is ignored. My library sets that variable specifically for the Docker processes.
I was actually thinking about this last night. Since the classes are instantiated here without any arguments to the constructor, there isn't an obvious way right now to pass the device ID to the Dockerized metrics.
https://github.com/GEM-benchmark/GEM-metrics/blob/9435858b3fa211007d75449732264ff62c72f1d9/gem_metrics/__init__.py#L124-L126
Any thoughts?


"make" doesn't work

just build from source doesn't work and the AUR version doesn't work either
https://aur.archlinux.org/packages/qdl-git
/var/tmp/pamac-build/qdl-git/PKGBUILD: line 29: pkg-config: command not found
cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -c -o firehose.o firehose.c
cc -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -c -o qdl.o qdl.c
qdl.c:52:10: fatal error: libxml/parser.h: There is no such file or directory
52 | #include <libxml/parser.h>
| ^
compilation aborted.
firehose.c:51:10: fatal error: libxml/parser.h: There is no such file or directory
51 | #include <libxml/parser.h>
| ^
compilation aborted.
make: *** [: qdl.o] Error 1
make: *** Waiting for jobs to complete...
make: *** [: firehose.o] Error 1
==> ERROR: There was a failure in build().
Interrupt...

I didn't happen to have this package:
https://archlinux.org/packages/core/any/base-devel/


Add support for .tiff files in partition_image

Currently partition_image only supports .jpg and .png. The goal of this issue is to update partition_image to support .tiff as well.

partition_image support .tiff files, I have just tried

If .tiff files work already, this issue can just update the documentation to reflect that.

what about .tiff's that include multiple images? we'd probably want to include the image sequence number in element metadata.
See: https://docs.fileformat.com/image/tiff/#ifd-entry

Closed in #1131


Gen modification

Generator Modification
Description:

Added Eiffel event list to the generator to allow for random event types
Changed the maximum amount of links per event to allow for a more realistic graph
Added CLI arguments to allow for control over runtime and latency between events sent

Arguments added:

Argument name
Short name
Description
Default value

total_duration
-t
Total amount of time in milliseconds for the generator to run
3 600 000

min_latency
-m
Minimum value for the range of latency between events sent
5

latency_max
-l
Maximum value for the range of latency between events sent
220

Useful notes:

The default values of the CLI arguments (count, total_duration, min_latency and latency max ) are set to mimic roughly 30 000 events set per hour.
The generator will run until either the count (total events to be sent) or the total_duration (duration for generator to run) has been reached.

Screenshots:
Preview of random event types with random links:

closes #13

Hard coding event names here is not how the library is designed.
Please look into how the event name was derived originally before your change.

Hard coding event names here is not how the library is designed.
Please look into how the event name was derived originally before your change.

I will Look into it!

@RuthgerD I have looked into the issue you raised with the hard coded values. Following your suggestion lead me to the event_set.rs file, specifically the impl Event function. Am I on the right track here? I figured it was cleaner to ask before implementing something that might not be following the intended design.

@RuthgerD I have looked into the issue you raised with the hard coded values. Following your suggestion lead me to the event_set.rs file, specifically the impl Event function. Am I on the right track here? I figured it was cleaner to ask before implementing something that might not be following the intended design.

Yes EventSet is used to describe what events and links are generated, this also allows us to have different link types per event if wish to do so. It is already used in the event sender (EventSet::build), so you should really extend that instead of modifying the internals. I haven't looked at your changes too closely but I think just the existing EventSet will get you what you want already.

@RuthgerD I have looked into the issue you raised with the hard coded values. Following your suggestion lead me to the event_set.rs file, specifically the impl Event function. Am I on the right track here? I figured it was cleaner to ask before implementing something that might not be following the intended design.

Yes EventSet is used to describe what events and links are generated, this also allows us to have different link types per event if wish to do so. It is already used in the event sender (EventSet::build), so you should really extend that instead of modifying the internals. I haven't looked at your changes too closely but I think just the existing EventSet will get you what you want already.

Thanks for your guidance! I ended up following your advice having the implementation in the event sender itself. I have changed the list of events to a global constant (I figured for such a small list and the fact that the generator is used for testing, implementing something to read from txt/json or config file would be a bit of an overkill for the intended usage).

Could you show how your EventSet looks?

Could you show how your EventSet looks?

It's the same as in the PR, I reverted back and made the changes in the event  sender.

Ok so what we have currently is:
EventSet::build()
  .add_link(Link::new("Link0", true))
  .add_link(Link::new("Link1", true))
  .add_event(
     Event::new("Event", "1.0.0")
        .with_link("Link0")
        .with_link("Link1"),
   )
  .build()
  .expect("This should work")

What is prevent you from adding more events like
EventSet::build()
 .add_link(Link::new("Link0", true))
 .add_link(Link::new("Link1", true))
 .add_link(Link::new("Link2", true))
 .add_event(
    Event::new("Event1", "1.0.0")
       .with_link("Link0")
       .with_link("Link1"),
  )
 .add_event(
    Event::new("Event2", "1.0.0")
       .with_link("Link0")
  )
 .add_event(
    Event::new("Event3", "1.0.0")
       .with_link("Link2"),
  )
 .build()
 .expect("This should work")

The generator should then pick one randomly if constraints are met (https://github.com/ItJustWorksTM/EiffelVis/blob/master/backend/crates/eiffelvis_gen/src/generator.rs#L137)

@RuthgerD I actually tried that initially and thought it might be a bit messy but if you are happy with it like that, I will implement it that way but use less types to keep in neat.
Thanks again for your help!

@RuthgerD I actually tried that initially and thought it might be a bit messy but if you are happy with it like that, I will implement it that way but use less types to keep in neat. Thanks again for your help!

You can loop over the types you want to add and just call builder = builder.add_event(...); if you think it would be too many lines.
Theres always a way to unmessy the mess

Code seems OK now, can't vouch for the actual functionality though

Code seems OK now, can't vouch for the actual functionality though

Great. It's been tested thoroughly and will be tested again independently by the assigned reviewer. Any issues will be fixed before the PR is accepted.

This is related to: https://github.com/ItJustWorksTM/EiffelVis/issues/14, only event types at the moment though, would be cool to also have link types match the official ones.

This is related to: ItJustWorksTM#14, only event types at the moment though, would be cool to also have link types match the official ones.

We can definitely look into that! It will probably be done on a new branch though.

This is related to: ItJustWorksTM#14, only event types at the moment though, would be cool to also have link types match the official ones.

We can definitely look into that! It will probably be done on a new branch though.

Sounds good, anyways would like me to approve the PR (for the future as well?) we're still on your repo :p

It's always good to have your approval @RuthgerD !
one of us (me it seems) will review this as well! But at least quality check has passed :D Thanks for you investment, we appreciate it!

This is related to: ItJustWorksTM#14, only event types at the moment though, would be cool to also have link types match the official ones.

We can definitely look into that! It will probably be done on a new branch though.

Sounds good, anyways would like me to approve the PR (for the future as well?) we're still on your repo :p

Our way of working currently is that the reviewer will approve the PR but if you (or someone else on your side) are going to review our changes anyway, we can always chat about changing the required number of approvals to 2 and one of them can be someone from your side? :)

Hmm let's just treat our reviews as secondary, we will have to review stuff again upstream anyways.

Hmm let's just treat our reviews as secondary, we will have to review stuff again upstream anyways.

Sounds good! Thanks for all your input on this one!

Code looks good and is commented, well done
Some exploratory testing results here:
Running without parameters: ✅
Everything seems to work on both BE - FE
Running with -h ✅
Explanations are clear
Running with parameters
-- replay. ✅
It seems to work on its own.
- l and - m are equal: 🙅
Problem when those are equal, it makes the thread panic.
-c & -b alone and with --replay ✅
Seems all good!
For the only bug I found, it should be an easy fix by branching out of the random if they are the same. I suspect it comes from there
Nice work otherwise!

Nice catch with the latency! Thanks for that! Changes have been made. :)


Bugfix auto packing with streams + no remote path

This PR
Edge case where auto packing fails for a streaming dataset specified through streams field if only a local path and no remote path is provided. This configuration is more broadly supported for Foundry.
  train_loader:
    name: finetuning
    dataset:
      streams:
        finetuning:
          local: /foo/bar/train/mds/

An error is thrown in StreamingDataset init because there is a check that local contains an index file. The current auto packing script overwrites local with an empty tempdir. This fix temporarily has remote point to the user-provided local, which should contain an index file.
Testing

MCLI run with streams + no remote path
Added unit test

Re-tested that it trains E2E with the following cases:

streams, local no remote
no streams, local == remote
no streams, remote only
no streams, local only


Add a versatile dfs visitor

See also http://www.boost.org/doc/libs/1_59_0/libs/graph/doc/depth_first_search.html
DFS(G)                                      -
  for each vertex u in V                    -
    color[u] := WHITE                       initialize vertex u
    p[u] = u                                -
  end for                                   -
  time := 0                                 -
  if there is a starting vertex s           -
    call DFS-VISIT(G, s)                    start vertex s
  for each vertex u in V                    -
    if color[u] = WHITE                     -
      call DFS-VISIT(G, u)                  start vertex u
  end for                                   -
  return (p,d_time,f_time)                  -
                                            -
DFS-VISIT(G, u)                             -
  color[u] := GRAY                          discover vertex u
  d_time[u] := time := time + 1             -
  for each v in Adj[u]                      examine edge (u,v)
    if (color[v] = WHITE)                   -
      p[v] = u                              (u,v) is a tree edge
      call DFS-VISIT(G, v)                  -
    else if (color[v] = GRAY)               -
      ...                                   (u,v) is a back edge
    else if (color[v] = BLACK)              -
      ...                                   (u,v) is a cross or forward edge
    ...                                     -
  end for                                   finish edge (u,v)
  color[u] := BLACK                         -
  f_time[u] := time := time + 1             finish vertex u

Could you elaborate on what's wanted here?

Good question, I haven't really dug into this. For example the kosaraju implementation in petgraph needs to use finishing times (petgraph::algo::scc) so it would really use the "finish vertex" event of the dfs visitor scheme above. (I don't think scc is in dire need of this improvement.)
I haven't thought about if you'd use a visitor trait or how the thing would be expressed in Rust. In the spirit of boost it should avoid doing anything for the events that don't have a handler.

I think one thing that will likely (or certainly) block this (and is needed to generalize various petgraph::algos) is a visit trait (or some other mechanism) for looking at the actual nodes (i.e. including weights) of a generalized graph (GraphBase/GraphRef``), as there is currently no way to get anything other than the G::NodeIds. Not even a way to then use the ids to index into the graph. Currently this does exist for edges via IntoGraphEdges` and friends.

if impl Trait is stabilized, all the iterator visit traits can be redesigned again. Then we can finally (I think?) have graph visitor traits and mutate the graph, which is impossible today.

If there's a visit trait missing, a specific issue for it is wanted.

Right, I just don't know how you might want to do it.
Could directly have a IntoNodeReferences (and support structure like IntoEdgeReferences, but could also modify GraphBase to allow some way to go from a G::NodeId to a NodeRef similar to EdgeRef.

It's natural that we add many small traits with very minor roles (GraphBase) until we know better how we should factor the functionality into logical traits. I don't foresee adding anything to GraphBase at this time, it's only carrying those associated types. More capabilities are added in other traits.

New dfs visitor in #87. Maybe there's a nice way to generalize it, or factor out the common parts of Dfs and DfsPostOrder.
For example, Dfs only needs one bit per node (discovered / mark gray), DfsPostOrder two bits per node (discovered / gray vs finished / black).

Adding PartialEq to NodeId is reasonable, but I don't like all the places where the new trait bound is required (Dfs and so on, if you try it).

Approachable overview http://eli.thegreenplace.net/2015/directed-graph-traversal-orderings-and-applications-to-data-flow-analysis/

Recursive full dfs visitor added in #97. What remains is maybe an iterative version of equal power.

A lot of your suggestions are now reality in 0.4.0 (DataMap trait, NodeId requires PartialEq and so on).

Glad I could contribute to the design.
Time to update my dependencies again!
On Mon, Oct 17, 2016 at 9:41 AM, bluss<EMAIL_ADDRESS>wrote:

A lot of your suggestions are now reality in 0.4.0 (DataMap trait, NodeId
requires PartialEq and so on).
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/bluss/petgraph/issues/37#issuecomment-254210549, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AEvkZNLAXS2TSaUmsplM3aOhYLu7bxWEks5q03sLgaJpZM4Gryvy
.

Oh and there's no consuming iterators yet, but the Element enum and related iterator things are on the road to be there.


Segmentation faults with Julia 0.6.0 and SDPs

I found a rather strange problem when using Mosek.jl with Julia 0.6.0 (the release version):
If I run the below code, Julia will segfault after varying numbers of iterations - usually (but not always)
in the middle of a Mosek solve.
using JuMP
using Mosek

srand(0)
for i = 1:1000
  m = Model(solver=MosekSolver())

  nx = 100
  A = sprand(nx,nx,0.5)
  @variable(m, X[1:nx,1:nx], SDP)
  @constraint(m, trace(A*X) <= 10 )
  @objective(m, :Min, trace(X) )
  solve(m)
end

I made some attempts at narrowing down the problem, and here are my notes:

The same code runs without issues with Julia 0.5.0 and Mosek.jl 0.6.1.
If the problems are larger, the segfault happens after fewer loop iterations, but the issue
occurs with problems as small as nx = 50. My system memory is nowhere near fully used,
and with Julia 0.5, I can easily solve much larger problems without issues.
If I copy the 0.6.1 version of Mosek.jl into my Julia 0.6.0 release and try that combination,
I get a bunch of deprecation warnings (which are to be expected, I guess) as well as  this:
ERROR: LoadError: Mosek.MosekError(3944, "The value (0,0) in a sparse symmetric has been specified twice at position 1 and position 3.") Stacktrace:  [1] appendsparsesymmat(::Mosek.MSKtask, ::Int32, ::Array{Int32,1}, ::Array{Int32,1}, ::Array{Float64,1}) at /home/sandro/.julia/v0.6/Mosek/src/msk_functions.jl:389....

From these observations, it looks to me like memory is getting corrupted, and the culprit looks to be something with sparse matrix handling - entries getting written multiple times or something of the sort.
I couldn't find out more specifically what is going wrong yet, but I'd be happy to provide more system info or poke around the code further - I thought I'd report this here in case someone can help.

If it crashes in the middle of a solve, it is most likely either internally in MOSEK, or it is in a callback to Julia.

Sometimes it also crashes after Mosek has returned into Julia, when doing seemingly random other stuff - I get the feeling that it tends to segfault when more memory is being allocated later on, but I'm still working on increasing reproducability.
I am using the versions it auto-downloaded, <IP_ADDRESS> in Julia 0.6 and <IP_ADDRESS> in Julia 0.5.

Testing with Ubuntu, Julia 0.6.0 and Mosek <IP_ADDRESS>, I have not yet been able to reproduce the crash.
What kind of system are you running on (OS, processor, memory etc.)? If you can get it to crash under a debugger, can you get a stacktrace?

Interesting - thanks for trying it out! That means I should really test this on more of my own computers to see whether I find a pattern. I also have a real example in which it crashes reliably on my computer, but that's buried deep in some simulation code and I first have to tidy it up into a standalone script.
Let me do some more testing of my own then and I'll report back with my findings.
I'm running on Debian Linux (testing/unstable, x86_64),  8 GB memory and an Intel i7-4600U CPU.
I've used Julia 0.5 and the Mosek interface daily for a few months now and it has been rock solid, but I only
upgraded to Julia 0.6 about a few days ago.

Short update on this: I tested some more and figured out that the combination of Julia 0.6 and linux kernel 4.11 seems to be the only place where the segfaults occur. I tested on 3 separate machines (all running debian, though) and they all had the issue on 4.11, but not on 4.9. I'll try and get my hands on some other distro running kernel 4.11 and see if I can reproduce things there next - that'll hopefully narrow down whether the kernel or something in debian is the problem.

In the meantime, there were more Debian updates (kernel was 4.11.6, now it's 4.11.11) and I ran the problematic cases again - seems the issue is gone now. Since I have not been able to uncover further what causes the issue on 4.11.6 and they are fixed now, I'm closing the issue. We can still reopen it if this problem reappears at a later time. @ulfworsoe : thanks for the help and cross-checking!
For anyone looking at this in the future: I had trouble with kernel 4.11.6 specifically, now I have kernel 4.11.11 and things work just fine.


Properly add x11rb-async to CI

The code gen tests would not have complained if x11rb-async/src/protocol generated a file that is not re-generated by the code generator
x11rb-async was not tested on our MSRV
Only x11rb's tests were ran on big-endian, not all tests

This was noticed in https://github.com/psychon/x11rb/pull/818 and it turns out that x11rb-async doesn't compile with our MSRV anyway:
error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds
  --> x11rb-async/src/rust_connection/extensions.rs:57:10
   |
57 |     ) -> Result<Option<ExtensionInformation>, ConnectionError> {
   |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: hidden type `impl Future` captures lifetime smaller than the function body
  --> x11rb-async/src/rust_connection/extensions.rs:57:10
   |
57 |     ) -> Result<Option<ExtensionInformation>, ConnectionError> {
   |          ^^^

Dunno what to do about this.

I moved the MSRV problem out to #823. This PR now only has "the simple part".


Event building of Pile-ups

The code won't work as is because the pile-ups are stored in a fragment. We are sorting the fragments by timestamp and building the events as we loop through them. This means, we are currently packaging all pile-ups into the first event. When we add the CFD, we are going to have to make a decision. We will have to either time order our hits within the fragments and build with those, or we are going to have to store our hits (or make copies of our fragments) at the event building level. That way when we read a fragment has multiple hits, and keep them until we are done pulling out all of the other fragments whose first hit is at that time. Just something to keep in mind when we get CFD's that event building will not be plug-and-play.

I would propose that we change the way we sort our events such that instead of sorting the fragments and then reading them in a time-ordered way, we just read the fragments sequentially from a tree and put them into a time-ordered STL-container (e.g. a multiset). At this stage we could check whether the fragment we want to insert contains pile-up, and if it does, we create a new fragment for each pile-up that get's inserted into the container instead of the original fragment. That way each fragment in our container has only a single hit and we can start pulling fragments out of the container once it reached a certain size and/or the time difference between the first and last fragment crossed a certain threshold.
I think this might be the easiest way to deal with pile-ups and it might also improve the reading performance of the fragment tree. I haven't checked yet, whether there is an easy way to preserve the information whether there was pile-up the which pile-up events the fragment represents (0th, 1st, or 2nd).

"easy way to preserve the information whether there was pile-up the which pile-up events the fragment represents (0th, 1st, or 2nd)."

Depending on how quickly we want to implement this, this information could be crucial. Last March, when we tested at high rates, the 0th, 1st, and 2nd events all showed different gains. Chris thinks he understands what is going on, but until then, keeping this information is important.

I agree, we definitely need to keep that information, it just isn't clear to me right now what the best way is to do that.
We could either just re-use the TFragment class and create a new fragment that is a copy of the original fragment with all other times and charges set to zero (or some other default value), which we then use when we create our TGriffin or whatever from the fragment to store the information there (Ryan already implemented bits in TGriffin to store exactly that information).
Or we could create a new class that inherits from TFragment and adds variables for the number of pile-up hits in the fragment and which pile-up hit this is.
Either way would work for me, the first one is more of a hack, and the second one creates an (almost) useless class.

All we are missing at this point is the CFD contribution to the time in the builder. We must also consider how to allow the "legacy" data to continue to be parsed when the CFD construction goes in. The 26Na data looks like it has reasonable, although I don't think they are, CFD data, so the code can't really do anything smart on its own. We could make a run info flag that you set called "Ignore CFD", or put a flag in that you can set like TIMECALTYPE: WALKCORR or TIMECALTYPE: CFD, where CFD is default. I'm note rally sure what would be best.

I agree this will be difficult to decode based on the content of the Cfd
parameter. Of the options you suggest, I favor the idea of a Run Info flag
for "Ignore CFD". Using the CFD should be the normal mode of operation
moving forward. The Cfd should be implemented in a (relatively) stable form
by the test beam time in December.
On Thu, Nov 19, 2015 at 6:14 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

All we are missing at this point is the CFD contribution to the time in
the builder. We must also consider how to allow the "legacy" data to
continue to be parsed when the CFD construction goes in. The 26Na data
looks like it has reasonable, although I don't think they are, CFD data, so
the code can't really do anything smart on its own. We could make a run
info flag that you set called "Ignore CFD", or put a flag in that you can
set like TIMECALTYPE: WALKCORR or TIMECALTYPE: CFD, where CFD is default.
I'm note rally sure what would be best.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158069202
.

I’m starting to lean towards a channel-by-channel flag just because you could easily have something like GRIFFIN with good CFD’s and something like Descant without them.

On Nov 19, 2015, at 12:18 PM, SmithJK<EMAIL_ADDRESS>wrote:
I agree this will be difficult to decode based on the content of the Cfd
parameter. Of the options you suggest, I favor the idea of a Run Info flag
for "Ignore CFD". Using the CFD should be the normal mode of operation
moving forward. The Cfd should be implemented in a (relatively) stable form
by the test beam time in December.
On Thu, Nov 19, 2015 at 6:14 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

All we are missing at this point is the CFD contribution to the time in
the builder. We must also consider how to allow the "legacy" data to
continue to be parsed when the CFD construction goes in. The 26Na data
looks like it has reasonable, although I don't think they are, CFD data, so
the code can't really do anything smart on its own. We could make a run
info flag that you set called "Ignore CFD", or put a flag in that you can
set like TIMECALTYPE: WALKCORR or TIMECALTYPE: CFD, where CFD is default.
I'm note rally sure what would be best.
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158069202
.

—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158125207.

How about detector system by detector system then? In the end, all the
detectors should have a CFD value.
On Thu, Nov 19, 2015 at 9:19 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

I’m starting to lean towards a channel-by-channel flag just because you
could easily have something like GRIFFIN with good CFD’s and something like
Descant without them.

On Nov 19, 2015, at 12:18 PM, SmithJK<EMAIL_ADDRESS>wrote:
I agree this will be difficult to decode based on the content of the Cfd
parameter. Of the options you suggest, I favor the idea of a Run Info
flag
for "Ignore CFD". Using the CFD should be the normal mode of operation
moving forward. The Cfd should be implemented in a (relatively) stable
form
by the test beam time in December.
On Thu, Nov 19, 2015 at 6:14 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

All we are missing at this point is the CFD contribution to the time in
the builder. We must also consider how to allow the "legacy" data to
continue to be parsed when the CFD construction goes in. The 26Na data
looks like it has reasonable, although I don't think they are, CFD
data, so
the code can't really do anything smart on its own. We could make a run
info flag that you set called "Ignore CFD", or put a flag in that you
can
set like TIMECALTYPE: WALKCORR or TIMECALTYPE: CFD, where CFD is
default.
I'm note rally sure what would be best.
—
Reply to this email directly or view it on GitHub
<
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158069202

.

—
Reply to this email directly or view it on GitHub <
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158125207
.

—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158125654
.

We could come up with something along those lines, we also must consider how a CFD is applied. I believe the cfd times from the GRIF16s represent something different than the 4Gs.

On Nov 19, 2015, at 12:25 PM, SmithJK<EMAIL_ADDRESS>wrote:
How about detector system by detector system then? In the end, all the
detectors should have a CFD value.
On Thu, Nov 19, 2015 at 9:19 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

I’m starting to lean towards a channel-by-channel flag just because you
could easily have something like GRIFFIN with good CFD’s and something like
Descant without them.

On Nov 19, 2015, at 12:18 PM, SmithJK<EMAIL_ADDRESS>wrote:
I agree this will be difficult to decode based on the content of the Cfd
parameter. Of the options you suggest, I favor the idea of a Run Info
flag
for "Ignore CFD". Using the CFD should be the normal mode of operation
moving forward. The Cfd should be implemented in a (relatively) stable
form
by the test beam time in December.
On Thu, Nov 19, 2015 at 6:14 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

All we are missing at this point is the CFD contribution to the time in
the builder. We must also consider how to allow the "legacy" data to
continue to be parsed when the CFD construction goes in. The 26Na data
looks like it has reasonable, although I don't think they are, CFD
data, so
the code can't really do anything smart on its own. We could make a run
info flag that you set called "Ignore CFD", or put a flag in that you
can
set like TIMECALTYPE: WALKCORR or TIMECALTYPE: CFD, where CFD is
default.
I'm note rally sure what would be best.
—
Reply to this email directly or view it on GitHub
<
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158069202

.

—
Reply to this email directly or view it on GitHub <
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158125207
.

—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158125654
.

—
Reply to this email directly or view it on GitHub https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-158127106.

We could make the correction dependent on the module type, which is stored in the fragment.
Another interesting development on this front: we're going to move toward putting pile-ups in different fragments (in the firmware). This will eliminate some of the other problems in this issue. It also makes filtering much simpler and intuitive.

This seems irrelevant now. We have two sets of experiments, one where we don't have CFD's and one where pile-ups are pre separated. Is this close-able?

I think so, yes.
On Wed, Mar 9, 2016 at 11:00 AM, Ryan Dunlop<EMAIL_ADDRESS>wrote:

This seems irrelevant now. We have two sets of experiments, one where we
don't have CFD's and one where pile-ups are pre separated. Is this
close-able?
—
Reply to this email directly or view it on GitHub
https://github.com/GRIFFINCollaboration/GRSISort/issues/478#issuecomment-194452863
.


[PT Run] - Apps installed via scoop not showing up

On my machine don't show firefox and whole apps installed using scoop. In menu start everything is ok.
Originally posted by @paulviks0x30 in https://github.com/microsoft/PowerToys/issues/3223#issuecomment-635794683

this could be same classification of issue as the steam issue #3425

Probably related to #3829

I have the same issue in version v 0.18.1

@paulviks0x30 and @yeung66, can you please elaborate on the type of applications that you are searching for. When you search for the applications on the start menu does it say run command or App in the subtitle? When I try to repro the issue, the shortcuts which say App show up (eg: 7-zip)

However, the one's which are shown as run command don't unless we add the action keyword (which is by design). To search for such apps, we need to search using > gzip or > cmder etc. Please let me know if this helps or if you're still unable to search/launch apps.

agreed, we need to know if this is an environment path search issue or something else.  @paulviks0x30 and @yeung66,  can you tell us what the app was via scoop you installed?

agreed, we need to know if this is an environment path search issue or something else. @paulviks0x30 and @yeung66, can you tell us what the app was via scoop you installed?

typora, motrix, cmder and everything. It still doesn't work after upgrading to v0.18.2

@yeung66, It would be great if you could provide some more information by answering the following questions.

Were these applications installed after installing powerToys or before?
Do these applications show up on the start menu?

I tried to install typora using scoop install typora and it shows up as expected. It would be great if you could help me repro the case where apps don't show up.
Thank you!

@alekhyareddy28 these apps are install after PowerToys and it will show up on the start menu.
Last night I use scoop install cmder to install cmder successfully and it shows up on the start menu.

but it doesn't show up in PowerToys.


Pol 251 new resource table 13

Description
Remove permissions block and adding incident resource table to the policies in the https://jira.flexera.com/browse/POL-251.
Issues Resolved
[List any existing issues this PR resolves]
Contribution Check List

[ ] All tests pass.
[ ] New functionality includes testing.
[x] New functionality has been documented in the README if applicable
[x] New functionality has been documented in CHANGELOG.MD

          1 Error

:no_entry_sign:
Please add labels to this Pull Request

          1 Warning

:warning:
Should this include readme changes

  Generated by :no_entry_sign: Danger


myjenkins: Update Plugins as of 2017-04-29

ghprb:1.36.2
htmlpublisher:1.13
matrix-project:1.10

Signed-off-by: Gianpaolo Macario<EMAIL_ADDRESS>

Testing locally on VirtualBox VM "easy-jenkins" of mac-tizy

Test successful:

./runme.sh completes successfully
Jenkins > Plugin Manager does not lists any updates

LGTM, merging