4.1 running but lots of empty lines in log

DSM version <IP_ADDRESS>17 update 3
docker version 17.05.0-0349
homebridge v4.1
i managed to install the latest 4.1 homebridge version but there seems to  be a lot of empty lines in the log files. Also i see some code i did not see before.
at first 4.1 was running but nothing was detected. this was caused by the bonjour service running
here are my findings
4.0 bug with duplicate UUID error is there
4.1 bug with duplicate UUID error is STILL there
4.0 running fine, even with bonjour service active
4.1 running fine but only after disabling bonjour service(before that nothing was detected
4.0 local time was not working
4.1 confirmation that local time is working, EVEN WITHOUT .env file present(how can this be)
4.0 log file looking normal. every line has a time stamp and an entry
scrolling up and down looks normal
4.1 logfile not normal. lot's of empty lines with only timestamps. 1 mean really a lot of empty lines.(total 500+ lines) screenshot only shows part of it with some weird code about payload.
scrolling inside log looks weird. lines with no timestamp and no std out appear.
it looks like the screen has problems with some strange code
scrolling down goes ok but scrolling vack up makes lines disappear

Many thanks for the feedback!

The UUID bug only got fixed in 4.2 (develop branch). I tried it out and got no problems running, but cannot guarantee, that it fixes the issues (#7).

What does the local time message say? In v4.1 it should be sth. like "Sun Dec 17 15:58:06 CET 2017". v4.2 also prints out an additional message: "Updated timezone to 'Europe/Berlin'." (Btw. you might also set the timezone via DSM as TZ env).

I also saw the empty lines, but don't know where they come from. The ones right before the "Or enter this code with your HomeKit app on your iOS device to pair with Homebridge:" could be a QR code, which gets displayed via terminmal, but unfortunately not via DSM. But I also noticed many white lines before – they went away when I scrolled them in DSM. So it might be a bug due to DSM.

i was just checking the time in the log
it says 2017-12-18 17:56:01 (where the time stamp of the entry is 16:56:01)
before 4.1 the timestamp of the entry and the log was both the same (one hour behind)

I have the empty lines issue also. If i scroll up the data is there.
Is there a way to have the Docker Time match the Image time now that I have set the Timezone in the .env file? I tried adding a TZ environment variable in the container but did not change the docker time stamps.

Sadly, I don't think so. The timestamps seem to come from DSM and I don't know how to sync them.

tested the latest development branch(no way to tell if this is 4.2
UUID bug is still there
also empty lines in the log but a lot less and the scrolling actually seems to work again.
i now have a total of 79 log lines instead of hundreds before with 4.1

Thanks! Closing this one.


[RKE1] v1.31 ImageGCFailed due to missing ContainerFilesystems

Rancher Server Setup

Rancher version: v2.10.x

Information about the Cluster

Kubernetes version: v1.31

Describe the bug
Kubelet logs are repeatedly complaining about
ImageGCFailed

 missing image stats: &ImageFsInfoResponse{ImageFilesystems:[]*FilesystemUsage{&FilesystemUsage{Timestamp:1729236001883118031,FsId:&FilesystemIdentifier{Mountpoint:/var/lib/docker,},UsedBytes:&UInt64Value{Value:3767446738,},InodesUsed:&UInt64Value{Value:227193,},},},ContainerFilesystems:[]*FilesystemUsage{},}

To Reproduce
Provision v1.31 RKE1 cluster and check logs
Expected Result
No spam in logs
Workaround
Disable KubeletSeparateDiskGC

Opened an upstream issue (#408) and a pull request (#407) to address this.
Until the fix is merged or resolved upstream, we’ll need to disable the feature gate in v1.31 and include this change in the release notes.

Testing:

Verify there are no errors in the kubelet logs around ImageGCFailed
Enable the KubeletSeparateDiskGC feature gate, then confirm the kubelet reverts to its previous behavior as mentioned in the issue description


RF20 Implement more advanced usage statistics

View granular statistics on system usage and data
Note actor roles

I suggest some communication to establish what stats to show for this RF, and how they should be represented.

RF20 View granular statistics on system usage and data
RF21 Generate reports about system data

@ThiashaV why did you assign @Mohab25? The issue is still in backlog, unassigning.
What you could do is flesh this out via communicating with @ntobe-nyuswa and @vutomim as per my comment above


TSP Accept queue page 158616741

Description
Building out the Accept Queue for TSPs to look similar to an initial wireframe here and the Office queue layout.
Set up
Follow these instructions to set up the tsp client.
To set up your db to access on tsplocal:

Run ./bin/generate-test-data.

Select your tsp_user's transportation_service_provider_id.
Go to shipment_offers table. Set at least one (but probably all of them) to use your tsp_user's tsp_id (i.e. update shipment_offers set transportation_service_provider_id ='4faa994a-b875-46fe-9907-e2cab8427290';).
Go to shipments table and set at least one shipment to status AWARDED.

Reviewer Notes

When hitting the /shipments api the status query parameter now takes a csv list of statuses to filter on.  This prevents us having to make multiple queries from the UI and gives me the ability to abstract the grouping of statuses in the UI only.
The Customer Name does not exist in the queue layout because it requires a 4 table join to get the data.  I've opened a pivotal task here to follow up on this and make the data available via the Shipment model.
The Shipment model now exposes the Move and TrafficDistributionList models if they are asked for with Eager()
The Move model SelectedMoveType was changed from *internalmessages.SelectedMoveType to *string so that I could use the same model with the external api.
Cypress tests were only partially completed because I need to create a framework for HHG data.  So I opened a pivotal task here to deal with it later.
aXe warnings were ignored since they pertain to elements not created by my changes.

Code Review Verification Steps

[x] End to end tests pass (make e2e_test).
[x] The requirements listed in
Querying the Database Safely
have been satisfied.
[x] This works in IE.
[x] Request review from a member of a different team.
[x] Have the Pivotal acceptance criteria been met for this change?

References

Pivotal story for this change

Screenshots

Ok @kilbergr - looks like I've got this fixed.  Hopefully you'll see it working if you try again. 😄

Bummer.  On Monday can you post your error in here so I can track it down further?  Enjoy the weekend.

I've figure it out and the clue was that you used the HHG shipment flow.  Unfortunately the data created by that flow doesn't meet the standards for what the TSP needs to see.  I've been using only the data from testdatagen which fills in all the fields by default, which is the problem.
The HHG flow leaves these fields as null:

traffic_distribution_list_id (required by TSPs)
pickup_date
delivery_date
source_gbloc
book_date
estimated_pack_days
estimated_transit_days
progear_weight_estimate
spouse_progear_weight_estimate

So Probably we're having issues because one of these is not making the Pop -> Swagger transition correctly.  I have to figure out what is required and what is not and fix that.
That being said, if you take one of the shipments created by testdatagen and make a shipment_offer with it and your TSP user you'll see that this always works.
Going forward I think the testdatagen may need to create some records where nullable fields are randomly null (or deterministically) so that we can test these interesting cases.


Move char codes from high surrogate pair range into private use.

Fixes #2884
In the test PDF, the glyph that draws '4' has a unicode value of 0xD860 (which is not a valid unicode value). This value seems to have issues with Firefox and Chrome rendering it in that position.
I was hoping to stop playing whack-a-mole with the problematic unicode values and instead come up with a white list, but this is going to need more investigation. Stepping through Firefox's fillText canvas command I couldn't find an obvious spot where Firefox decided if it will draw a glyph at a certain char code. I'm thinking it's partially Firefox and the various font backends, but I'm not sure.
As another way to try and come up with a white list, I wrote a test script that uses a font that maps all char codes to one glyph and then attempted to draw all char codes from 0 to 0xFFFF. Unfortunately, Firefox and Chrome have different behavior. Firefox seems to have issues with lots of ranges, while Chrome doesn't have any issues. For Chrome, what's really strange is 0xD860 seems to work fine with the test script, but it also fails to render the attached PDF with pdf.js, so what Chrome draws may be dependent on font type.

Looks like I need to fix some unit tests, but in the mean time...
/botio test

I was hoping to stop playing whack-a-mole with the problematic unicode values and instead come up with a white list, but this is going to need more investigation.

@brendandahl Do you want to fix the test failures, such that we can land this PR as a temporary solution?
Or should we close this for now, and wait for a more complete solution instead (one based on the findings in http://brendandahl.github.io/sandbox/find_matching_glyphs/)?

@Snuffleupagus I'll fix failures as a temporary solution. I started working on the full solution, but when I start moving more glyphs to the private use area it causes more problems. If a glyph has an id of 0 (usually notdef, but in some cases a valid glyph) and it gets moved the private use area it no longer will be drawn by the browser. What we really need to do is shift all the glyphs and insert a fake notdef, but that's a non-trivial amount of work.

@brendandahl Ping :-)

/botio test

/botio makeref


Update jetbrains extension - fix crashing search recent projects command

Description

Last fix for extension unfortunately didn't fix it fully.
It fixes error
TypeError: Cannot read properties of undefined (reading '0')

b8:util.ts:235:44

---
232:   if (tool.toolName === undefined) {
233:     return [];
234:   }
235:   const build = channel.history?.toolBuilds[0] ?? {};
236:   const directoryPatterns = build?.tool?.intelliJProperties?.directoryPatterns ?? [];
237:   const recentProjectsFilenames =
238:     channel.history?.toolBuilds[0]?.tool?.intelliJProperties?.recentProjectsFilenames ?? [];
---

recent.js:52:1759
    at async Promise.all (index 0)
async cl:recent.js:52:1262

Mentioned in this issue: https://github.com/raycast/extensions/issues/15887
Screencast

Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

thanks @gdsmith and @dgrzedzielski this solution worked.


How to get the FPS in the paper

I have tried to reproduce the FPS value reported in your paper.
I use the code in test.py and the FPS can be obtained. However, i only got 0.52 FPS.
My total length of tested examples are around 200.
What may be the reason ? Can you help me?

Image size? GPU?

GPU 2080 Ti I Image size is around 300*400.
在 2021-04-15 23:17:03，"yijingru" @.***> 写道：
Image size? GPU?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Did you comment the lines 134-190 in test.py?

yes I have , although it doe not take too much time
At 2021-04-16 10:39:39, "yijingru" @.***> wrote:
Did you comment the lines 134-190 in test.py?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Did you share your system IO with multiple users?

I retested for HRSC2016 test set on RTX6000, it outputs:
avg time is 0.03914568763285135
FPS is 25.545598007602567

and
avg time is 0.04173873132830549
FPS is 23.958562423334634

for BBAVectors+r  and BBAVectors+rh versions respectively.

Can you share your command ? Did you use eval.py or use main.py --phase test?
At 2021-04-16 11:37:51, "yijingru" @.***> wrote:
I retested for HRSC2016 test set on RTX6000, it outputs:
avg time is 0.03914568763285135
FPS is 25.545598007602567
and
avg time is 0.04173873132830549
FPS is 23.958562423334634
for BBAVectors+r and BBAVectors+rh versions respectively.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

python main.py --dataset hrsc --data_dir ../hrsc --phase test but needs to comment out the drawing functions

I use the same command as yours. But when i debug the time, i found the time of passing the model is around 1-2s for each image, which is obviously too slow.
At 2021-04-17 01:07:51, "yijingru" @.***> wrote:
python main.py --dataset hrsc --data_dir ../hrsc --phase test but needs to comment out the drawing functions
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

I printed mine, only the first image takes a longer time, but it still smaller than 1s.
processing 0/444 image ...
passing model is 0.5458090305328369
processing 1/444 image ...
passing model is 0.011527061462402344
processing 2/444 image ...
passing model is 0.012245655059814453
processing 3/444 image ...
passing model is 0.08452320098876953
processing 4/444 image ...
passing model is 0.013281106948852539
processing 5/444 image ...
passing model is 0.011836767196655273
processing 6/444 image ...
passing model is 0.01332545280456543
processing 7/444 image ...
passing model is 0.012810707092285156
processing 8/444 image ...
passing model is 0.01177668571472168
processing 9/444 image ...
passing model is 0.011761665344238281
processing 10/444 image ...
passing model is 0.013238668441772461

Can you leave your email address ?
At 2021-04-17 10:49:45, "yijingru" @.***> wrote:
I printed mine, only the first image takes a longer time, but it still smaller than 1s.
processing 0/444 image ...
passing model is 0.5458090305328369
processing 1/444 image ...
passing model is 0.011527061462402344
processing 2/444 image ...
passing model is 0.012245655059814453
processing 3/444 image ...
passing model is 0.08452320098876953
processing 4/444 image ...
passing model is 0.013281106948852539
processing 5/444 image ...
passing model is 0.011836767196655273
processing 6/444 image ...
passing model is 0.01332545280456543
processing 7/444 image ...
passing model is 0.012810707092285156
processing 8/444 image ...
passing model is 0.01177668571472168
processing 9/444 image ...
passing model is 0.011761665344238281
processing 10/444 image ...
passing model is 0.013238668441772461
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.


dynamic DatePicker value isn't being set correctly

Dynamic date pickers and datetime pickers are called with time objects, not strings, and so we need to ensure they're strings before we try and feed them into DateTime.parse in the model.
normalize_automate_vals gets called with ActiveSupport::TimeWithZone.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1685266

@miq-bot add_label bug
@miq-bot assign @gmcculloug
@miq-bot add_reviewer @eclarizio
@miq-bot add_reviewer @bdunne

@miq-bot add_label hammer/yes


TWILL-107 Add payload support for Discoverable

JIRA : https://issues.apache.org/jira/browse/TWILL-107

Just couple comments.

Thanks for the review @chtyim. Addressed comments. Please take a look again.

LGTM. Please squash the commits.

@chtyim Squashed commits. Thanks!

Thanks for the PR, @gokulavasan. Next time would love to have more information how you solve it in the PR description rather than just link to JIRA.

@hsaputra I have added some description to the PR. Sorry. Thank you for catching it.


Correct tagging metadata for FHR

Job VTB Documentation on b1f839e wanted to post the following:
View the site here
This comment will be updated on new commits.

PR only affected doco, doco recipe passed and website is correct now. merging


Autocomplete with barebone example not working

This barebone HTML (altered from "Binding UI with the widget" of example) doesn't seems to work. The auto complete dropdown is no where to be seen when it is supposed to be triggered.
<!DOCTYPE html>

Location: <input type="text" id="us2-address" style="width: 200px"/>
Radius: <input type="text" id="us2-radius"/>

Lat.: <input type="text" id="us2-lat"/>
Long.: <input type="text" id="us2-lon"/>

I guess you may have to:
-add a key in the google maps api, so the url would be
https://maps.googleapis.com/maps/api/js?sensor=false&libraries=places&key=MyGoogleMapsAPIKeyForThisServer
-activate the Google Places API web services API for the same Google Developer account, as noted in issue "Autocomplete not working #73"

Indeed. That works now. Thanks


Version 1.0 for master branch

Changes Unknown when pulling 625b8aee344c2c3fe6e51cd26254bf36219816ed on develop into ** on master**.


Making /settings' buttons consistent

Is your feature request related to a problem? Please describe.
There are 3 buttons with different innerText View, Show Code, Show Solution
Edit: did I just put same buttons twice🤦🤣, because I am currently away from laptop check setting

Describe the solution you'd like
Swapping Show Code and Show Solution with View for consistent look,  while adding .sr-only to span in the button with innerText equal to Code or Solution.
Examples:
- <button>Show Code</button>
- <button>Show Solution</button>

+ <button>View Code</button>
+ <button>View Solution</button>

Describe alternatives you've considered
Nothing, this isn't a true issue. Quality of life change
Additional context
This idea is originated from full button width
for more info check comment in https://github.com/freeCodeCamp/freeCodeCamp/issues/45947#issuecomment-1130030952

Speaking of consistency,
It seems like we have three places where we show lists of projects and their solutions.

Portfolio timeline
Certification page
Settings

Ideally, they should be the same component and the same buttons for displaying the code.
ref https://github.com/freeCodeCamp/freeCodeCamp/issues/45949

@Hdanzo yeab that would be lovely 👍.
If you would like to fix this issue, please make sure you read our guidelines for contributing, we prioritize contributors following the instructions in our guides. Join us in our chat room or the forum if you need help contributing, our moderators will guide you through this.

Is @Hdanzo working on this? If not, I'd love to take a crack at it. Doesn't seem it's been assigned to anyone 😄

@tom-raley Hello! I am working on this at the moment 😄


chore: update deps

The new libp2p-switch is causing (or revealed):
  1) .contentRouting le ring nodeA.contentRouting.provide:

     Error: stream ended with:0 but wanted:1

      at drain (node_modules/pull-reader/index.js:43:26)

      at node_modules/pull-reader/index.js:63:18

      at node_modules/pull-reader/index.js:114:13

      at node_modules/pull-reader/index.js:114:13

      at onNext (node_modules/pull-catch/index.js:17:17)

      at drain (node_modules/stream-to-pull-stream/index.js:141:18)

      at Channel.<anonymous> (node_modules/stream-to-pull-stream/index.js:158:5)

      at endReadableNT (node_modules/readable-stream/lib/_stream_readable.js:1010:12)

      at process._tickCallback (internal/process/next_tick.js:63:19)

The pull-reader update exposed a bug in the dht where were were reading on write only responses. The dht is still working properly, but since we're getting no data when add providers, which is expected, we pull-reader errors because we tried to read a byte.
https://github.com/libp2p/js-libp2p-kad-dht/pull/30


Font Rendering

I noticed with the font rendering that vulkan is slightly blurry compared to d3d12. You can see in the screenshots below the green color is also slightly different between the two. Depending on what background color and font color, the difference can be really noticeable. If you save the two images below and quickly flick between them you will see the problem.

Thanks for pointing this out. It should be fixed in the next release.


TypeError: TypeError: Cannot read property 'bind' of undefined

"Unhandled JS Exception: TypeError: TypeError: Cannot read property 'bind' of undefined
This error is located at:
in StackViewLayout (at withOrientation.js:30)
in withOrientation (at StackView.tsx:104)
in RCTView (at View.js:35)
in View (at Transitioner.tsx:267)
in Transitioner (at StackView.tsx:41)
in StackView (at createNavigator.js:80)
in Navigator (at createKeyboardAwareNavigator.js:12)
in KeyboardAwareNavigator (at createAppContainer.js:430)
in NavigationContainer (at App.js:88)
in App (at AppContainer.js:74)
in AppContainer (at renderApplication.js:40)
in RCTView (at View.js:35)
in View (at AppContainer.js:98)
in RCTView (at View.js:35)
in View (at AppContainer.js:115)
in AppContainer (at renderApplication.js:39)
I have tracked down the error in the code to the following:
this._callListeners = this._callListeners.bind(this);
What is happening is that _callListeners is both a function and also an unassigned variable.   So the this._callListeners is no longer the function but it is unassigned.
My recommendation is to set the function name as __callListeners instead of _callListeners to avoid the conflicting issue.
this._callListeners = this.__callListeners.bind(this);
class AnimatedEvent {
.....
  _callListeners: Function; // CONFLICTS with function name
 ....
  constructor(argMapping: Array<?Mapping>, config?: EventConfig = {}) {
.....
    this._callListeners = this._callListeners.bind(this); // ?????? It is crashing here;
....
  }
_callListeners(...args: any) {  // CONFLICTS with variable name
    this._listeners.forEach(listener => listener(...args));
  }

This bug does not need more information because I have explained the coding error and how to fix it.


Add docstring to is_keras_tensor function

"This PR adds a missing docstring to the is_keras_tensor function in the Node class. The is_keras_tensor function is used to check whether an object is a Keras tensor by checking if it has a _keras_history attribute. However, it lacked a docstring explaining its purpose and usage. This change improves code readability and documentation clarity."

Hi @MadhumithaKolkar It looks like your PR relates to the Keras component. Please submit it to the github.com/keras-team/keras repository instead. Thank you for your contribution!
@fchollet, @qlzh727


Addition of Sonos Roam battery level

Description
I like to do a feature request to add the battery level for the new Sonos Roam?
What node/command (topic)/state (payload)
For example:
node: Universal
command: player.get.battery
state: percentage

or
command: player.get.properties
incorperate the battery in a key/value pair.

Versions and Infrastructure
what system: Node-RED 2.0.5 running on Docker version 20.10.6 (Debian 10)
node-red-contrib-sonos-plus version: 5.2.5
Node-RED version: 2.0.5
NodeJS version: v14.17.3
Screenshot:

That should be possible.
Please enter the following address in your browser (replace the ip address with the address of your player) and send me the results- lets see if there is the battery information.
http://<IP_ADDRESS>:1400/info

Thank you, the results are:
http://<IP_ADDRESS>:1400/info:
{
  "device": {
    "id": "RINCON_XXXX",
    "serialNumber": "00-AA-AA-A0-00-A0:0",
    "model": "S27",
    "modelDisplayName": "Roam",
    "color": "Shadow",
    "capabilities": [
      "PLAYBACK",
      "CLOUD",
      "AIRPLAY",
      "VOICE",
      "AUDIO_CLIP"
    ],
    "apiVersion": "1.24.1",
    "minApiVersion": "1.1.0",
    "name": "Tuin",
    "softwareVersion": "64.3-19080",
    "hwVersion": "<IP_ADDRESS>-2.9",
    "swGen": 2
  },
  "householdId": "Sonos_xxx",
  "playerId": "RINCON_XXX",
  "groupId": "RINCON_XXX",
  "websocketUrl": "wss://<IP_ADDRESS>:1443/websocket/api",
  "restUrl": "https://<IP_ADDRESS>:1443/api"
}

http://<IP_ADDRESS>:1400/status/batterystatus:
<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl" href="/xml/review.xsl"?><ZPSupportInfo><LocalBatteryStatus>
<Data name="Health">GREEN</Data>
<Data name="Level">89</Data>
<Data name="Temperature">NORMAL</Data>
<Data name="PowerSource">BATTERY</Data>
</LocalBatteryStatus><!-- SDT: 0 ms --></ZPSupportInfo>

One thing to keep in mind is that the Roam appears to go into standby on the Wi-Fi network. I didn't get a reply when opening the URL, until I opened the Sonos App. It looks like the app is sending an on signal. The Roam was standby and not off.

OK so we know the command but we need to wake up the device.
Are you able to create the discovery file for your Roam. Here is a link:
how to generate a discovery file

Yes. I did the steps and the output can be fount at this discovery file.
Btw: I thought the Sonos App would wake the Roam, but the device was in bad Wi-Fi range. But you can press a button to send the device to deep sleep and the Sonos App doesn't wake it then. You have to press the button again is my experience.

Thanks for the discovery file - i will check with Stephan. Maybe we find a wake up command or can subscribe to an event.
Regarding btw: Try this flow ( i could not test it but should work).
[{"id":"36529dbbc172ab0b","type":"inject","z":"6d9c1459e41e6f50","name":"trigger","props":[{"p":"payload"},{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"","payloadType":"date","x":320,"y":200,"wires":[["6ad9b68e9ad8eb91"]]},{"id":"6ad9b68e9ad8eb91","type":"http request","z":"6d9c1459e41e6f50","name":"","method":"GET","ret":"obj","paytoqs":"ignore","url":"http://<IP_ADDRESS>:1400/status/batterystatus","tls":"","persist":false,"proxy":"","authType":"","x":476,"y":200,"wires":[["62cae6a11f4de185","f8e28320b8ead7ab"]]},{"id":"62cae6a11f4de185","type":"debug","z":"6d9c1459e41e6f50","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":710,"y":120,"wires":[]},{"id":"f8e28320b8ead7ab","type":"xml","z":"6d9c1459e41e6f50","name":"","property":"payload","attr":"","chr":"tag","x":650,"y":200,"wires":[["a441cf5e27834a68"]]},{"id":"a441cf5e27834a68","type":"change","z":"6d9c1459e41e6f50","name":"","rules":[{"t":"set","p":"payload","pt":"msg","to":"payload.ZPSupportInfo.LocalBatteryStatus[0].Data[1].tag","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":820,"y":200,"wires":[["e2a40abeeb0beb75"]]},{"id":"e2a40abeeb0beb75","type":"debug","z":"6d9c1459e41e6f50","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","statusVal":"","statusType":"auto","x":1030,"y":200,"wires":[]}]

I tried, and the flow works as you expected:
Node-RED debug output:

Sonos Controller for Windows 10 output:

Good to hear. Please test it over the next days and let me know the
results.
That command is easy to integrate in sonos-plus as player.get.batterystatus.
Good night :-)
On Tue, Aug 17, 2021, 22:00 Joep Verhaeg @.***> wrote:

I tried, and the flow works as you expected:
Node-RED debug output:
[image: image]
https://user-images.githubusercontent.com/1484845/129792140-de0cd4b3-f9fa-4311-8f25-ae1fd2e0eb81.png
Sonos Controller for Windows 10 output:
[image: image]
https://user-images.githubusercontent.com/1484845/129792251-10e5108c-8645-4286-b648-61c60ee90292.png
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub
https://github.com/hklages/node-red-contrib-sonos-plus/issues/165#issuecomment-900590882,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEDZCH7UBCJUTLVOAAEXQT3T5K5XFANCNFSM5CIGVPKA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email
.

This looks like something that isn’t in the soap api. This xml endpoint is really easy to parse, will give it a go later tonight.


Getting tabular data from latitude-longitude?

Is there a capability to just grab the various points of data from the latitude and longitude? TL;DR I'm wondering if it's possible to construct a CSV dataset from just the latitude and longitude data.
Any help would be appreciated! Thank you!

The original service from SoilGrids system is to get grid data (not points) https://www.isric.org/web-coverage-services-wcs.
So the current implementation of this package only supports to download grid datasets. If you want to grab various points of data from lat and lon, you probably can first use this package to download the grid data and then use other tools (e.g., rasterio or rioxarray)to load grid data and extract point data from the grid. Here is an example: https://gis.stackexchange.com/questions/358036/extracting-data-from-a-raster


[Add Data Structures and Algorithms in other programming languages]

We need to add the data structure and algorithms in other programming languages like:

Java
Python
JavaScript
Ruby
etc

Guidelines

Please make sure you are using the right folder structure for your contribution like we've used for C++, like  here

Please visit CONTRIBUTING.md for contributions.

Whatever program you add, ensure you're adding the relevant comments, and it is easier to understand what the code does and the main concept.

Hey @ShehrozIrfan , I would like to contribute to this repo. Could you please assign it to me?

Hey @Khushi2402
I'm glad that you want to contribute to this repo.
You can start by opening a PR with the changes, you want to add.
Have fun!

Hey @ShehrozIrfan , I would like to contribute as well
I can write in java

Hey @ShehrozIrfan , I would like to contribute as well I can write in java

Hey @md-abid-hussain
I'm glad that you want to contribute to this repo, specifically in Java.
Sure, you can start by opening the PR with the changes you want to add.
Have fun!

I want to contribute to this repo by Implementing the DSA concepts in Python. Please assign it to me
@ShehrozIrfan

@Ctoic
Assigned. Go Ahead :)

Thanks @ShehrozIrfan


Stripe

[ ] Developer API Key
[ ] Customer Objects
[ ] Create transactions
[ ] Read Transactions
[ ] Refund Transactions
[ ] Declined Process
[ ] Successful Process

Hey Jordan,
These are the tasks I could come up with at this point and time of day.  I am looking forward to hanging with ya later today and we can really dig deep into Stripe.  It has a ton of different super powers!  =)
If you see anything I forgot, or you feel we do not need feel free to let me know or take it off.


WIP: read from the mix file

Contributor checklist

[ ] Bug fixes include regression tests
[ ] Features include unit/acceptance tests

closes #5

To add a test, we'd need to add new tests. Some of the other tests show similar examples, like the dependency tests IIRC.

Closing as this has been fixed in main.


NanLossDuringTrainingError

I added a new translation (new language pair) problem using my own dataset.
I also made vocab.-set using the dataset.
Training seems working since the loss had been dropped under 2.0
config setting : transformer_big,  titan X(12G) * 4.
However, i got NaN loss problem occasionally. (sometimes it occurs after ~10k steps and sometimes.. after 100k steps...)
Any thought? is there a way to by-pass this problem?
Here's detailed output.
`
INFO:tensorflow:Performing local training.
INFO:tensorflow:datashard_devices: ['gpu:0', 'gpu:1', 'gpu:2', 'gpu:3']
INFO:tensorflow:caching_devices: None
INFO:tensorflow:Doing model_fn_body took 3.163 sec.
INFO:tensorflow:Doing model_fn_body took 1.986 sec.
......
INFO:tensorflow:loss = 1.63497, step = 97601 (181.782 sec)
INFO:tensorflow:Saving checkpoints for 97607 into /home/minjoong/t2t_train/koen_tokens_32k/transformer-transformer_big/model.ckpt.
ERROR:tensorflow:Model diverged with loss = NaN.
Traceback (most recent call last):
File "/home/minjoong/tf1_2/bin/t2t-trainer", line 82, in
tf.app.run()
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 48, in run
_sys.exit(main(_sys.argv[:1] + flags_passthrough))
File "/home/minjoong/tf1_2/bin/t2t-trainer", line 79, in main
schedule=FLAGS.schedule)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensor2tensor/utils/trainer_utils.py", line 242, in run
run_locally(exp_fn(output_dir))
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensor2tensor/utils/trainer_utils.py", line 534, in run_locally
exp.train()
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/experiment.py", line 275, in train
hooks=self._train_monitors + extra_hooks)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/experiment.py", line 665, in _call_train
monitors=hooks)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/util/deprecation.py", line 289, in new_func
return func(*args, **kwargs)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 455, in fit
loss = self._train_model(input_fn=input_fn, hooks=hooks)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 1007, in _train_model
_, loss = mon_sess.run([model_fn_ops.train_op, model_fn_ops.loss])
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/monitored_session.py", line 505, in run
run_metadata=run_metadata)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/monitored_session.py", line 842, in run
run_metadata=run_metadata)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/monitored_session.py", line 798, in run
return self._sess.run(*args, **kwargs)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/monitored_session.py", line 960, in run
run_metadata=run_metadata))
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/basic_session_run_hooks.py", line 477, in after_run
raise NanLossDuringTrainingError
`

I suspect this is because your vocab_size declared in problem_hparams is smaller than the actual number of tokens in your vocabulary. If you hit a tokens with a number higher than your vocab_size, you'll get a NaN on GPU, see here:
https://www.tensorflow.org/api_docs/python/tf/nn/sparse_softmax_cross_entropy_with_logits
"labels: Tensor of shape [d_0, d_1, ..., d_{r-1}] (where r is rank of labels and result) and dtype int32 or int64. Each entry in labels must be an index in [0, num_classes). Other values will raise an exception when this op is run on CPU, and return NaN for corresponding loss and gradient rows on GPU."
It's annoying that it gives a NaN and not an error, but TF guy say it's hard to propagate errors from CUDA on GPU. In any case, try to increase your softmax size, like here:
https://github.com/tensorflow/tensor2tensor/blob/master/tensor2tensor/data_generators/problem_hparams.py#L422
Let us know if that helps!

@lukaszkaiser
It is strange, i used word-piece model and it computes the actual length of vocab_size (which is 27284).
Anyway i add 2**6 margin as you advised.

p.input_modality = {
"inputs": (registry.Modalities.SYMBOL, subtokenizer.vocab_size+2**6)
}
... also similar change to target_modality

Anyway, I creating vocab file, using 32k as traget vocab_size results vocab of 140k length.
(140k after 27k )
So, i used the one iteration earlier file of 27284(27k) length. I hope this is not relevant to this problem.

These subword tokenizer vocab sizes look like a mess, we'll need to make it cleaner. But does it work for you now?

@lukaszkaiser It occurs occasionally (after 1k ~15k steps).  I'll let you now after watching about 50k training steps.  Thanks a lot!

Hope it works now, please reopen if you see the problem again!

Unfortunately, it occurs again after about 31k training steps.

INFO:tensorflow:loss = 1.8717, step = 31601 (182.200 sec)
INFO:tensorflow:Saving checkpoints for 31622 into /home/minjoong/t2t_train/koen_tokens_32k/transformer-transformer_big/margin/model.ckpt.
ERROR:tensorflow:Model diverged with loss = NaN.
Traceback (most recent call last):
File "/home/minjoong/tf1_2/bin/t2t-trainer", line 82, in
tf.app.run()
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/platform/app.py", line 48, in run
_sys.exit(main(_sys.argv[:1] + flags_passthrough))
File "/home/minjoong/tf1_2/bin/t2t-trainer", line 79, in main
schedule=FLAGS.schedule)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensor2tensor/utils/trainer_utils.py", line 242, in run
run_locally(exp_fn(output_dir))
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensor2tensor/utils/trainer_utils.py", line 534, in run_locally
exp.train()
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/experiment.py", line 275, in train
hooks=self._train_monitors + extra_hooks)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/experiment.py", line 665, in _call_train
monitors=hooks)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/util/deprecation.py", line 289, in new_func
return func(*args, **kwargs)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 455, in fit
loss = self._train_model(input_fn=input_fn, hooks=hooks)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/contrib/learn/python/learn/estimators/estimator.py", line 1007, in _train_model
_, loss = mon_sess.run([model_fn_ops.train_op, model_fn_ops.loss])
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/monitored_session.py", line 505, in run
run_metadata=run_metadata)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/monitored_session.py", line 842, in run
run_metadata=run_metadata)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/monitored_session.py", line 798, in run
return self._sess.run(*args, **kwargs)
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/monitored_session.py", line 960, in run
run_metadata=run_metadata))
File "/home/minjoong/tf1_2/local/lib/python2.7/site-packages/tensorflow/python/training/basic_session_run_hooks.py", line 477, in after_run
raise NanLossDuringTrainingError
tensorflow.python.training.basic_session_run_hooks.NanLossDuringTrainingError: NaN loss during training.


The JS/TS language service immediately crashed 5 times.

Type: Bug
When opening a TS file, the following error shows, and intellisense is lost when typing.

The JS/TS language service immediately crashed 5 times. The service will not be restarted. This may be caused by a plugin contributed by one of these extensions: VisualStudioExptTeam.vscodeintellicode, VisualStudioExptTeam.vscodeintellicode. Please try disabling these extensions before filing an issue against VS Code.

My workaround for now was to downgrade from version 1.89.1 to 1.88.1

I've been experiencing the same issue regardless of VSCode version. I've tried downgrading to 1.88.1, and tried the latest insiders build. Narrowed it down to the TSServer crashing. I was able to mitigate by installing typescript 5.4.4 globally and point VSCode's TypeScript: Tsdk path to the globally installed version.

I am seeing this as well

I test few things like changing computer and clean install. it seems typescript(over 5.4)+yarn with pnp causes error.

I test few things like changing computer and clean install. it seems typescript(over 5.4)+yarn with pnp causes error.

Can confirm. Was using Yarn version 4.1.1 in PNP mode with TS version 5.4.3

Downgrading to 1.88.1 also resolved this for me. yarn 4.2.2 pnp, typescript 5.4.5

I tried downgrading vs code to version 1.88.1 but without any luck. I am still having issues, especially with intellisense being stuck on loading status
My versions:
node: v20.13.1
npm: 10.5.2
typescript: 5.3.3

This fixed the issue for me:

Uncheck "Experimental: Use Vs Code Watcher" checkbox in VS Code Settings / Extensions / Typescript / Tsserver.
Restart VS Code.

I've solved by doing a clean reinstall of VSCode.

If you're using yarn, there's a bug on their side: https://github.com/yarnpkg/berry/issues/6304
@zach-betz-hln Are you using yarn? Also did you test disabling with those listed extensions (VisualStudioExptTeam.vscodeintellicode, VisualStudioExptTeam.vscodeintellicode)?

@mjbvz thanks for the yarn issue link. Yes, am using yarn.
When first creating this issue, I tried searching my extensions for those listed, but no results were found. I'm assuming this is because they're built-in extensions? Am not sure.
Also, I have no desire to use vscode without intellisense 🤷♂

This fixed the issue for me:

Uncheck "Experimental: Use Vs Code Watcher" checkbox in VS Code Settings / Extensions / Typescript / Tsserver.
Restart VS Code.

This works for me also, thanks so much. Lost a lot of time solving this.

For my case, this works for me, due to out of memory in TS Server memory allocation, so just increase the limit and the problem should be solved.

This fixed the issue for me:

Uncheck "Experimental: Use Vs Code Watcher" checkbox in VS Code Settings / Extensions / Typescript / Tsserver.
Restart VS Code.

worked for me


feat: rename MockService to MockableService to avoid name collision

Summary
This PR renames MockService to MockableService in order to fix a name collision.
Details
This happens when we try to mock a protocol named Service. This is common inside a local Swift package, to expose a particular service (API, storage, etc.).
The generated macro will have a MockService class and will collide with the MockService protocol (public) inside the Mockable package.
We got the following build errors:
'MockService' inherits from itself
Type 'MyPackage.MockService' does not conform to protocol 'Mockable.MockService'

Renaming MockService to MockableService fix it.

Thanks @gaelfoppolo, merged and released in 0.0.8

Thanks. Just a note: I would rename it even further with an underscore, to be clear that it is an internal protocol.
_MockableService


cvxpy - reuse some vector constraints

Hi there, please, could anybody take a look at this issue?
https://stackoverflow.com/questions/64488443/python-cvxpy-reuse-some-constraints
I can't seem to find anything related in the documentation and I don't understand how to face such issue. Thank you

You need to use parameters as described in the linked post. Suppose you have the constraint rhs >= lhs which is sometimes used and other times not, where rhs and lhs have dimensions m x n. Write the following code:
param = cp.Parameter((m, n))
slack = cp.Variable((m, n))
param_constraint = [rhs >= lhs + cp.multiply(param, slack)]

Now to turn off the constraint, set param.values = np.ones((m, n)). To turn the constraint on, set param.values = np.zeros((m, n)). You can turn some entries of the constraint off/on by setting some entries of param to be 1 and others to be 0.

Thank you Steven, the issue of the link above is that it refers to changing values of some constants.
In my case I don't a have any constant changing value at all.

I understand. Maybe I shouldn't have mentioned the post.

Hi Steve,  the thing is, if you look at the code I posted on stackoverflow, one of the constraints is always on. The problem is that it seems to link its solution to the first run and the it gives completely wrong values on the second run.  Please, would it be possible show how you would edit the sample code I posted on stackoverflow? Otherwise, I'm completely lost. Thank you

Closing, since I saw this is solved on StackOverflow, and the issue wasn't due to CVXPY.


Issue with rendering certain Unicode characters

Vue.js version
2.0.1
Reproduction Link
http://jsfiddle.net/wmmw143f/1/
Steps to reproduce
Run the JSFiddle above and you will see the content isn't displayed and errors in the console.
What is Expected?
I would expect the app to run regardless of the Unicode characters, without errors.
What is actually happening?
[Vue warn]: failed to compile template:

  This is user-generated content, and unfortunately includes the Unicode character 2028 right here:
.

 (found in root instance)
[Vue warn]: Error when rendering root instance:
Uncaught TypeError: Cannot set property 'isStatic' of undefined

Background
I'm not sure if this is the right place for this or not, but I'm of the feeling this is a bug with Vue. I'll also point out that I'm not that knowledgable about character encodings, but here is the information I have.
We have been testing the Vue 2.0 upgrade on our website which has a lot of user-generated content. It appears that some of our user-generated contains uncommon Unicode characters like U+2028 Line Separator. These appear invisible by standard.
However, when they appear in the content of a Vue 2.0 page, Vue fails completely and then removes it's entire DOM node from the tree, leaving the page bare.
Here is a JSFiddle that demonstrates the issue. You'll notice that JSFiddle highlights the Unicode character in question. When you remove that character, the app runs correctly.

According to  Line Terminators, both \u2028 and \u2029 could cause this problem.
Should the special chars be replaced in genText func? If so, I will try to make a pr.

Maybe it's better to the replacement during the phases of chars parsing

Uncaught TypeError: Cannot set property 'isStatic' of undefined
for Vue 2.0.7 when \u2028 character is in DOM element attribute on creating new Vue instance.

http://jsfiddle.net/3hmp0e16/


https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/385

https://github.com/forseti-security/helm-charts/issues/72

/gcbrun

Thanks @exenin for the PR and issue! I ran into this issue as well. I tried updating to GKE master version 1.15.11-gke.9 and was able to work past it (someone in that other issue mentioned not seeing it in 1.15). This is probably the best way to resolve it for 1.14. Not sure why the tests failed, I can look into that if you want to move forward. Before we can merge the PR you will need sign the CLA mentioned above.

Hi @exenin, pinging on my comment above. Just checking if you are still using 1.14 or if you have tried using 1.15. If still on 1.14 and want this change in, then I can approve and merge.


feature/SKOOP-106

API to create, update, delete and serve user memberships.
Tests.
@svetivanova could you have a look please?

Codecov Report

Merging #79 into master will increase coverage by 0.35%.
The diff coverage is 88.37%.

@@             Coverage Diff              @@
##             master      #79      +/-   ##
============================================
+ Coverage     78.12%   78.47%   +0.35%
- Complexity      542      561      +19
============================================
  Files           145      150       +5
  Lines          2423     2509      +86
  Branches         81       83       +2
============================================
+ Hits           1893     1969      +76
- Misses          474      484      +10
  Partials         56       56

Impacted Files
Coverage Δ
Complexity Δ

.../com/tsmms/skoop/openapi/OpenAPIConfiguration.java
100% <ø> (ø)
4 <0> (ø)
:arrow_down:

...skoop/membership/query/MembershipQueryService.java
100% <100%> (ø)
3 <3> (?)

...in/java/com/tsmms/skoop/exception/enums/Model.java
100% <100%> (ø)
3 <0> (ø)
:arrow_down:

...op/membership/query/MembershipQueryController.java
100% <100%> (ø)
2 <2> (?)

...com/tsmms/skoop/membership/MembershipResponse.java
100% <100%> (ø)
1 <1> (?)

...embership/command/MembershipCommandController.java
82.75% <82.75%> (ø)
5 <5> (?)

...p/membership/command/MembershipCommandService.java
86.11% <86.11%> (ø)
8 <8> (?)

... and 2 more

Continue to review full report at Codecov.

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


How to match a regex in the path

I want to match a url like the following -
/v1/users/u-f6fsdfds878dgdfgdf7887/blogs
with a regular expression of the following form -
/v1/users/[a-zA-Z0-9-_]+/blogs
But for some reason it is not matched. I think I missing the correct syntax to make it work. Can anyone please help with this.

As far as I understood your problem is no straight related to mock-server but with a regex problem.
You can find better help here http://webchat.freenode.net/?nick=regex101-....&channels=regex
But trying to help...
The regex you have will never match the example code you gave.
In this regex you are expecting the world blogs in the end, but informing messages in the example snippet.
Try playing with it:
http://myregexp.com?regex=%2Fv1%2Fusers%2F[a-zA-Z0-9-_]%2B%2F(blogs|messages)&text=%2Fv1%2Fusers%2Fu-f6fsdfds878dgdfgdf7887%2Fblogs
%2Fv1%2Fusers%2Fu-f6fsdfds878dgdfgdf7887%2Fmessages
%2Fv1%2Fusers%2Fu-azAZ0123456789-_%2Fblogs
%2Fv1%2Fusers%2Fu-azAZ0123456789-_%2Fblogs&flags=gm

Yeah, sorry about that I fixed the note. Both have /blogs at the end.
but when I do withPath(PATH) with PATH = /v1/users/[a-zA-Z0-9-_]+/blogs, the path /v1/users/u-f6fsdfds878dgdfgdf7887/blogs is not matched for some reason.
Am I missing some escape sequences to tell mock-server to treat this expression as a regex instead of a normal string?

According to Javadoc withPath should understand regex:

path - the path such as "/some_mocked_path" or a regex

Regex looks fine for me, but you can try the following to identify the problem:

.*/v1/users/[a-zA-Z0-9-_]+/blogs.*
.*v1.users.*blogs.*
make logging loud: <logger name="org.mockserver" level="TRACE"/>

Worked as expected. Look here: http://fiddle.re/gdtdra (Click on JAVA)
But if you have something before or after this string try the examples @masooh gave you (Maybe some space/new line characters hidden there).

It was happening because some other attribute was not matching. Only issue was that the attribute not matching was clearly specified in the logs which would have helped to find the issue earlier. Thanks a lot for your help.


are we doing a Digital Library Federation cross-polinator travel award?

@sthagstrom whom should we ask about the DLF award?

I'm missing the call, so apologies if this has been discussed, but: if we do cross-travel awards (which I think is a great idea), should we broaden that beyond the more obvious (like digital libraries) and try to include researcher conf's as well?


Issue with README

I found that the documented directory structure in the master/README.md did not run with the code.
Where it says:
The data should be organized as:

VoxCeleb1
 - wav
 - vox1_meta.csv
 - iden_split.txt
 - veri_test.txt

It should say:
The data should be organized as:

VoxCeleb1
 - dev/wav/...
 - test/wav/...
 - vox1_meta.csv
 - iden_split.txt
 - veri_test.txt

fixed at https://github.com/VITA-Group/AutoSpeech/commit/9247eceac1b5649089287f49c7610071e3d12e78


Osquery daemon integration in Hubble

Following are the requirements:

Hubble should be able to update osqueryd configuration file and flag file.
Should be able to parse osqueryd log file(s) and send to splunk in efficient manner, probably cache file offset etc.
Should be able to rotate osqueryd's log file
Should have capabilities to start/stop/restart osquery daemon based on hubble profile flags.
osqueryd should be in running state, we can need to implement monitoring capability in hubble itself to take care of this.
There should be an option to enable/disbale events table in osqueryd. By enabling, I mean hubble should stop auditd in case it is already running and also make sure that it is kept in stopped state while hubble is in running state in order for osquery event tables to work. Although this can be handled using discovery queries in packs.
Hubble should have capabilities to insert custom fields in logs that are sent to splunk.
Design should be single process and should consume at-most 1 CPU core as SREs might not be ok otherwise. We may or may not chose make this multi-threaded depending on performance and python support etc.
Should support both osqueryi and osquery daemon mode.

Final High level design post discussion with team:

Conf and flag files in /var/cache/hubble directory
Hubble nebula module to have two separate functions scheduled at probably different frequency - osqueryd_monitor and osqueryd_log_parser
One function would be responsible for managing/monitoring osquery daemon like start/stop/restart. Should be responsible for keeping osquery daemon in running state.
Other function would be responsible for parsing osquery logs and sending to splunk
In case auditd is enabled, we can have following two approaches:
a) Dynamically generate osquery flag file to disable events as they anyway won't work but continue to execute standalone queries like we have in osqueryi
b) Create a separate pack for evented queries and execute them based on discovery query (conditional execution) which would check if auditd process is running or not. (As of now, opting for this approach)
Hubble would continue to support existing nebula functions to schedule queries through osqueryi. Depending on Hubble conf, users can make use of osqueryi or osqueryd to execute queries
There should be a way to distinguish sourcetype of osqueryi and osqueryd. Due to difference in logging format of osqueryi and osqueryd, new splunk returner is being created. This would allow users to specify custom sourcetype.
We'll keep at-least one backup log file of osquery (after logfile truncation). This number should be configurable and can be tweaked as per individual team's needs. Like if DME wants 5 log backups and DMA wants just 1 backup, it should be doable. Regarding caching offset on filesystem, we'll see if we can cover all corner cases without saving the offset to disk. If not, we'll probably make use of offset and save it to disk.
Since Hubble would be dealing with log file rotation, it would be good to have a feature where-in we can check disk usage. If disk/partition is full or is above a certain threshold then either do not make backups or alert users in some manner. We can discuss this further in more detail in subsequent meetings. Implemented a basic disk usage functionality, it's usage however is still to be finalized.

@basepi Yes data format is different from what we currently have with osqueryi. Osquery daemon can produce two types of logs in general - differential and snapshot. These logs have few additional fields like 'action', 'epoch', 'counter' etc and also the attributes in event generated might differ.
For example, if we have a running_procs query output in differential format, it would have following format:
{
name: 'running_procs',
action: 'added',
epoch: 123,
counter: 456,
unixTime: 178624682,
columns: {} // Note this field has dict type. Contains actual row returned.
...more fields
}
Same query in snapshot format would have following event format:
{
name: 'running_procs',
action: 'snapshot',  // Note value here would always be snapshot
epoch: 123,
counter: 456,
unixTime: 178624682,
snapshot: [] // Note this field has list type. Contains actual row(s) returned.
...more fields
}
As seen from above, result logs have a field name 'columns' which is of type 'dict' whereas snapshot logs have field 'snapshot' which is of type 'list'.
Logs generated by osqueryi are of following format:
{
'running_procs' : {
'data' : [] //Contains actual rows returned
}
}
If we want to use same returner for both osqueryi and osqueryd events, then we'll have convert both snapshot logs and result logs into current format. This would be tedious, so I created a new returner instead of formatting each event read from osquery log files (which will eventually again be re-formatted in returner code before being sent to splunk in form of event_data/payload object).

Perfect, thanks for the reply and explanation. I think you're right that a new returner makes sense.


Formatting error when printing via rich.console

When printing the results of  format_help() from an argparser that uses RichHelpFormatter() as a formatter, the output is not formatted correctly if those results are printed using rich.console.Console. I've created a program which reproduces this problem:
# reproduce a formatting bug in RichHelpFormatter()

import argparse
import rich_argparse
import rich.console

console = rich.console.Console(markup=False, emoji=False, highlight=False)
prsr = argparse.ArgumentParser(
    prog="config",
    description="Edit or show the location of the user configuration file.",
    formatter_class=rich_argparse.RichHelpFormatter,
)
prsr.add_argument(
    "action",
    choices=["edit", "file", "convert"],
    help="""'edit' edits the configuration file in your preferred editor.
            'file' shows the name of the configuration file.
            'convert' writes a new .toml configuration file with the same settings as the old .ini configuration file.""",
)

console.rule("printing help with print()")
print(prsr.format_help())

console.rule("printing help with rich.console.print")
console.print(prsr.format_help())

Here's a screenshot of the output:

Note that when the output is printed using console.print(prsr.format_help()) the help text for the single positional argument does not wrap correctly.
My current (untested) hypothesis is that this has something to do with having nested rich.console objects. The current implementation of format_help() uses the .capture() context manager to collect the output before returning.

Thanks for the extra context.

Note that when the output is printed using console.print(prsr.format_help()) the help text for the single positional argument does not wrap correctly.

This has to do with your console trying to wrap the output to fit the console width (the console width is by default set to the width of your terminal). Note that the formatter's output is wrapped by the formatter itself, not by the internal console and shouldn't be wrapped by the external console. This is how argparse formatters work (HelpFormatter wraps everything, RawDescriptionHelpFormatter wraps everything except the description, RawTextHelpFormatter doesn't do any wrapping).
To solve your issue, you have two solutions:

use the built-in print (as you saw with the first part of your example): print(prsr.format_help())
tell your console to not wrap the formatter output as this is handled by the formatter itself: console.print(prsr.format_help(), soft_wrap=True)

My current (untested) hypothesis is that this has something to do with having nested rich.console objects. The current implementation of format_help() uses the .capture() context manager to collect the output before returning.

This has nothing to do with the internal console, it just return the text as a string. The same wrapping issue would happen if you console print any long text that contains new lines and leading spaces. If you follow solution 2 above, your problem will be solved.
I'll close this issue as no action has to be taken in rich_argparse. Feel free to continue the discussion if you have more questions.


Port leveldb to windows

This largely leverages the effort by Robert Važan in https://bitbucket.org/robertvazan/leveldb-windows/. Some divergence from that project:

Removed all support for nuget packages. This no longer picks up snappy automatically.
Does not build with snappy support by default. User needs to define LEVELDB_WITH_SNAPPY and point msbuild to the location of the snappy header files directory.
Builds a static library (vs a DLL) and uses a dynamically linked runtime (i.e. /MD and /MDd).

I signed it!
On Thu, Nov 19, 2015 at 10:31 AM, googlebot<EMAIL_ADDRESS>wrote:

Thanks for your pull request. It looks like this may be your first
contribution to a Google open source project. Before we can look at your
pull request, you'll need to sign a Contributor License Agreement (CLA).
[image: :memo:] Please visit https://cla.developers.google.com/
https://cla.developers.google.com/ to sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll
verify. Thanks.

If you've already signed a CLA, it's possible we don't have your
GitHub username or you're using a different email address. Check your
existing CLA data https://cla.developers.google.com/clas and verify
that your email is set on your git commits
https://help.github.com/articles/setting-your-email-in-git/.
If you signed the CLA as a corporation, please let us know the
company's name.

—
Reply to this email directly or view it on GitHub
https://github.com/google/leveldb/pull/314#issuecomment-157988330.

Submitting a newer one.


How to get URL to the built JavaScript file

I have a web application with multiple HTML files inside. I would like to reuse the same index.js entry point for those HTML files since CRA's webpack configuration is good for me. However, it seems that the script tag is automatically inserted to index.html at build step, without any way to have that same tag reused in other HTML files. Is there any non-ejecting way to achieve this?

There's always a way!
You can create a Node script which runs post-build and populates the other files for you. Unfortunately, this isn't something we support out of the box so you'll need to create that add-on script.
I wouldn't eject to solve this. 😄


Persistent Back Button + more

Hi,
What an awesome project!
I'm using your library to create an instructional slide show, rather than using it as a conventional welcome screen. Therefore, I'd like to have persistently available back and forward buttons, and discard the skip and done buttons.

Is it possible to have a persistent back button, that can be used in a similar fashion to the forward button, allowing the user to navigate using a back and forward button in addition to swiping.
How do i allow for the activity to be "relaunched" after it has been "completed" by the user?
Is it possible to include a actionbar, allowing the user to navigate to the parent activity?

Thanks in advance!

Thanks!
I'm glad to hear it, that was one of the alternate uses I could see for this.
I was already thinking about adding a back button, so I just went ahead and did it. Update the library version to 0.6.0 and call showPrevButton(true) on the WelcomeScreenBuilder.
For relaunching it, calling WelcomeScreenHelper.forceShow() instead of show() might be what you're looking for.
To show an action bar, use a custom theme and add the following:
<item name="windowActionBar">true</item>
<item name="windowNoTitle">false</item>

By default the background will be transparent, but that can be changed. To show the back button in the action bar you'll have to call showActionBarBackButton(true) on the WelcomeScreenBuilder.
Maybe you already had this figured out, but to hide the skip button you'll have to disable skipping with canSkip(false). That still allows the activity to be closed, but it doesn't "complete" it (will that be an issue?).
To hide the done button call useCustomDoneButton(true) (I named it that to imply that you should add your own done button if you hide the provided one, that might not apply in your case though).
Let me know if that solves everything.

This is very very kind of you!! I'm very grateful!
Be aware that I have close no prior experience within android development (or any software development for that matter), so this is truly a test on the user friendliness of your library. So far it's all been very intuitive.
However, I have no success when trying to apply .theme(int) as seen in the screenshot below:

I've tried to replace int with CustomWelcomeScreenTheme, which is the name of the custom theme in styles.xml, but again without success.
On another matter, I'll suggest that title text is made aligned to top. If you on one screen have a title text that spans 2 lines, the placement of that text will be inconsistent to the remaining screens.
Again, thank you very much!

No problem!
It's good to hear this library has been intuitive. If this is your first coding project I'd definitely recommend doing some basic Java projects/tutorials before moving on to Android, at least that's what worked for me. I tried learning Android with absolutely no prior experience and nothing made sense, but after working with plain Java for a month or so and learning the basics of the language it started to click.
Anyway, the int in .theme(int) was intended to show the type of parameter the function takes. In this case, that int should be the resource ID of your theme. In Android, you access resources (everything in the 'res' folder) with resource IDs, which are generated automatically. See Accessing
resources on the developer site for more info. For your theme, you would call .theme(R.style.CustomWelcomeScreenTheme).
I'll look into the titles when I have some time. The layouts could definitely use some improvements, I just haven't gotten around to it yet.


Release Google.Cloud.PubSub.V1 version 3.15.0

Changes in this release:
New features

Add use_topic_schema for Cloud Storage Subscriptions (commit d557116)

Created release for Google.Cloud.PubSub.V1-3.15.0


Suggestion for enumerations

Hello
I'm still a bit unhappy about the fact enumerations are i32 values, for two reasons:

Handling them is cumbersome. I can't just access the field, I have to convert it first…
They are interchangeable. Let's say I have enums enum Direction { Unspecified = 0, In = 1, Out = 2 } and enum Proto { Unspecified = 0, Udp = 1, Tcp = 2 }. I can do message.proto = Direction::Out as i32 and it will work. I can do Direction::from_i32(message.proto) and it'll work. And I like Rust's strict type system keeping an eye on me.

So I was wondering if there could be more convenient and safer alternative. What about:

Create the enum as it is now, eg enum Direction { Unspecified = 0, In = 1, Out = 2 }
Also create a companion struct DirectionRaw(pub i32)

This way, we can have conversion methods on both of them to each other, but not with i32 directly (type safety). The fact the conversion methods would be on the DirectionRaw would make it more discoverable.
Furthermore, I think the conversion method would be something like fn enum(&self) -> Option<Direction> ‒ this way it is possible to both know if the input was valid/known and call unwrap_or_default() on it to get the appropriate default.
Does that make sense? Or does it have some downsides I don't see?
I would be willing to implement it, but I wanted to check first if it makes sense.

@vorner have you seen the getters/setters that are generated for enumeration fields?  Checkout this comment for more info: https://github.com/danburkert/prost/issues/69#issuecomment-357777266

I did have a look and these are some help for the first point, but it is still methods on the whole message, not on the field, which feels a bit unexpected (considering the other fields are just fields). But it doesn't address the second point, eg weak typing.

I'm not really sure what you mean by weak typing?  Both the fields and getter/setter are strongly typed.  I definitely think the current system is simpler than adding a whole new type.  As far as whether it's expected/unexpected for it to be a method instead of field accessor, I'm not really concerned.  There are other places where prost is already adding helper methods per field, e.g. proto2 optional fields.

I mean the fact that all enumerations are integers and can be assigned to each other even if they are of different enum type, similar to how everything is int in C and one has to be careful not to mix things up.
It isn't a show-stopper, I'm just thinking of possible improvements. Not that I'd already have a bug in that sense, but then, I have some history of C development and I don't mix „conceptual“ types on regular basis thanks to that.

@Nemo157 while technically possible, that would mean that prost can't be used for applications that require schema evolution.  I'm not going to implement it, because I think schema evolution is critical to all applications, eventually.  Properly handling this is one of the reasons I wrote prost; the other existing implementation at the time doesn't work with unknown enum values, and its (stable) typed API means that it can't.
I'm unconvinced that the type-safety thing is an issue in practice (I've certainly never been bitten by it, since the getter/setter tend to be more ergonomic anyway), but if its a real concern then I think the best solution would be an option to make enum fields private instead of public, which would enforce that access go through the typed getters/setters.

I should note, prost clearly needs a generated code guide, a la Go's.  I think that would clear up a lot of this confusion.  That should probably be its own issue though.

I don't see how this would limit applications that require schema evolution any more than the currently generated code does. If the generated code is publicly exported then you are already exposing an enum that might have more variants added to it in the future, if you're not publicly exporting it then when you update your schema you can update the code simultaneously.
My problem is that every time I deal with a message I need to create my own error if the message contains an enum value I don't currently support:
package data;

enum KeyType {
  RSA = 0;
}

message PublicKey {
  required KeyType Type = 1;
  required bytes Data = 2;
}

pub fn from_protobuf(bytes: &[u8]) -> Result<Self> {
    let message = data::PublicKey::decode(bytes)?;
    let type_ = data::KeyType::from_i32(message.type_)
        .ok_or_else(|| format!("Unknown KeyType {}", message.type_))?;
    match type_ {
        data::KeyType::Rsa => {
            Ok(Self::from_bytes_rsa(message.data))
        }
    }
}

I'm never going to do anything else, my code has no idea what semantics new enum values will have associated with them so there's no way for me to attempt to handle them.

I think the best solution would be an option to make enum fields private instead of public, which would enforce that access go through the typed getters/setters.

This would be much worse than the current situation. I took a look at the generated method and was very surprised it wasn't just ENUM_TYPE::from_i32 but instead returns a default value if it doesn't understand the provided value. That's definitely going to break any application that receives a value it doesn't understand. For example the schema above could be extended in the future with something like KeyType::ECDH = 1, if that happens and a client using the updated schema sends a message with type_ = 1 to a client using the message.type_() method it will not know what 1 means and just default to using KeyType::Rsa, almost certainly breaking downstream code.

For reference I've got a partially implemented branch acting how I mentioned: https://github.com/Nemo157/prost/tree/enumeration-as-enum
This is controlled via an extra config value for prost_build::Config that says to use the enum types for the fields, which is passed through to prost_derive to adjust the code generation.

Schema evolution has nothing to do with Rust source API compatibility, it's about protocol compatibility and flexibility. [...]

Ok, so just to clarify for me, when you're mentioning schema evolution you're talking about having prost's design guide application developers towards supporting schema evolution, rather than any inherent support for schema evolution in prost itself?

Well-designed applications can often recover from receiving unknown enum variants.

I don't disagree with this. Which is why I suggest this as a configurable feature of the code generator, not a default.
I guess a large part of my issue is that I'm having to deal with third-party protocols that are not using protobuf best practices. As far as I can tell there is no real support for schema evolution built into these protocols, there's no way to send back a generic error message let alone a "you used a newer feature I don't understand" message. Instead the protocols are version negotiated at a higher level and presumably would have a new version if the schema changes.
If you want to limit prosts APIs to be ergonomic only when using protobuf best practices, then I guess that's your call and I'll just have to write macros to make this easier for me to deal with.

Sorry to hijack this issue, but I have been looking at prost, and I also think enums should be handled better - and Rust enums give the perfect tool for this. prost would have to add a type like this:
enum EnumField<T> {
    KnownVariant(T),
    UnknownVariant(i32),
}

The following proto3 example:
enum City {
  Unknown = 0;
  NewYork = 1;
  London = 2;
  Paris = 3;
}
message Foo {
  City city = 1;
}

would generate something like this:
enum City {
    Unknown = 0,
    NewYork = 1,
    London = 2,
    Paris = 3,
}
struct Foo {
    city: EnumField<City>,
}

This is idiomatic Rust and handles both cases cleanly. I know this would be a breaking change, but since prost does not have a 1.0 version yet, it would be the right time to add this.

@brain0 are you aware that Rust enums are generated, and you can get the enum value from a field already with the generated accessor method?  See this comment for more info: https://github.com/danburkert/prost/issues/69#issuecomment-357777266.

I am aware of that, and from what I can see in the comment, you can either get the i32, or you can get the enum, but in the latter case, you simply fall back to the default if it is out of range. I don't see a way to easily determine that the value was out of range, other than comparing the i32 value against known values manually. The version I just proposed is more obvious and allows to explicitly distinguish between the case of a valid enum value and an unknown one, without losing any information.
Accessing the enum field via match or if let expressions to determine whether the enum value was in range feels natural in Rust code. At least to me, having two ways to access the same value, both giving me incomplete information in the worst case, does not feel natural at all. In other places, prost generated code has an elegance that other protobuf implementations lack (have you seen protobuf generated C++ code?), but the enums feel wrong.

@Nemo157

An alternative that I think may fit the intent of protobufs enums better is just a new-typed integer, one of the most widely used example of this are http's StatusCode.

That's an interesting suggestion, I hadn't considered associated consts.  That being said I don't find the match foo.city example convincing.  In what cases wouldn't you treat the City::UNKNOWN case exactly like the other case?
@brain0

I don't see a way to easily determine that the value was out of range, other than comparing the i32 value against known values manually.

See the previous comment, all enum types get is_valid and from_i32 methods which do exactly what you want.  from_i32 returns Option::None if the i32 isn't valid, but it could be changed to Result<EnumType, i32> if that's deemed to be more useful.

Accessing the enum field via match or if let expressions to determine whether the enum value was in range feels natural in Rust code. At least to me, having two ways to access the same value, both giving me incomplete information in the worst case, does not feel natural at all.

Again I'm repeating myself, but the recommended way to use enums in Protobuf is to always have the first variant be Unknown.  If you do that, then all you need to worry about is handling the Unknown case in the vast majority of situations.  I have used the C++ and Java protobuf libraries extensively for building many systems, and in my experience it's extremely rare to need to handle a distinction between Unknown and unrecognized values.

@danburkert There is one reason, more contextual information if you're trying to debug an issue. The Unknown variant loses the actual value sent, if you want to get that currently you have to use something like City::from_i32(foo.city).ok_or_else(|| Error::new(format!("Unknown City {}", message.type_)))? instead of the provided foo.city() method.
The other reason I want it is to integrate with third-party protocols that don't use unknown variants and instead communicate versions out of band. As an example in prost itself the FieldDescriptorProto::Type enum doesn't have an unknown variant, so if there were a new field type added prost would treat that as a double instead of erroring out.

@Nemo157

There is one reason, more contextual information if you're trying to debug an issue....

Sure, good example.  I'd solve it like this:
match foo.city {
    City::UNKNOWN => { return Err(Error::from(format!("Unknown city {}", foo.city))); }
    City::NEW_YORK => { ... }
    City::LONDON => { ... }
    City::PARIS => { ... }
}

The other reason I want it is to integrate with third-party protocols that don't use unknown variants and instead communicate versions out of band. As an example in prost itself the FieldDescriptorProto::Type enum doesn't have an unknown variant, so if there were a new field type added prost would treat that as a double instead of erroring out.

Yep, I've definitely run into this myself.  As a concrete example, CodeGenerator::resolve_type doesn't currently check whether the field type is known[1].  Using the current prost APIs I'd add an assert like this at the top of the function to solve this:
assert!(field.type_.map(Type::is_valid).unwrap_or(false),
        format!("field {} has an unknown type: {:?}", field.name(), field.type_));

Would one of the suggestions simplify that pattern?
[1]: I was aware of this when I wrote it, but chose to ignore the issue because the Protobuf spec hasn't added a new field type in as long as I'm aware of, and if it did it would only cause a problem if you happened to run an old prost version with a new protoc, which would be rare.

The associated constants thing look interesting ‒ they better describe the reality than the enum I think.
But I'd still like to have the real enum, even if I don't have to use it ‒ oftentimes, I want to extract the data from the message, validate it and then keep using the data through the application. And knowing it is one of the variants I know (and having rustc check I handle all of them) is convenient.

Again I'm repeating myself, but the recommended way to use enums in Protobuf is to always have the first variant be Unknown

proto3 says that there must be a variant with value 0 that is the default. It doesn't necessarily correspond to "Unknown". For instance, imagine that you sell products and have several third parties that handle delivery for you. Then imagine the following enum:
enum DeliveryTime {
    DontCare = 0;
    Morning = 1;
    Noon = 2;
    Afternoon = 3;
}

Then, at some point you add night time delivery. Now there is an important difference between "default value" (don't care) and "unknown value" (some preference which we don't know and need to clarify).

If you want to limit prosts APIs to be ergonomic only when using protobuf best practices, then I guess that's your call and I'll just have to write macros to make this easier for me to deal with.

I would want APIs that are obvious and ergonomic for all cases. IMO, the current implementation is not very ergonomic for either case - and as this bug report show, not obvious either.
I'd like to extend on my previous suggestion (EnumField enum) to show how one could create APIs that look very much like typical Rust std APIs and IMO are very ergonomic in all use cases (use case example at the bottom of the code snippet):
// code in prost
#[derive(Copy, Clone, Debug)]
enum EnumField<T> {
    KnownVariant(T),
    UnknownVariant(i32),
}

impl<T> EnumField<T> {
    fn unwrap(self) -> T {
        match self {
            EnumField::KnownVariant(v) => v,
            EnumField::UnknownVariant(_) => panic!("Some panic message"),
        }
    }
}

impl<T: Default> EnumField<T> {
    fn unwrap_or_default(self) -> T {
        match self {
            EnumField::KnownVariant(v) => v,
            EnumField::UnknownVariant(_) => T::default(),
        }
    }
}

impl<T: Default> Default for EnumField<T> {
    fn default() -> Self {
        EnumField::KnownVariant(T::default())
    }
}

impl<T> From<T> for EnumField<T> {
    fn from(t: T) -> Self {
        EnumField::KnownVariant(t)
    }
}

impl<T> From<EnumField<T>> for i32
where
    i32: From<T>,
{
    fn from(v: EnumField<T>) -> i32 {
        match v {
            EnumField::KnownVariant(v) => v.into(),
            EnumField::UnknownVariant(v) => v,
        }
    }
}

// to be replaced with TryFrom<i32> once that is stable
trait TryFromI32: Sized {
    fn try_from_i32(v: i32) -> Option<Self>;
}

impl<T: TryFromI32> From<i32> for EnumField<T> {
    fn from(v: i32) -> EnumField<T> {
        match T::try_from_i32(v) {
            Some(v) => EnumField::KnownVariant(v),
            None => EnumField::UnknownVariant(v),
        }
    }
}

// generated enum example
#[derive(Copy, Clone, Debug)]
enum DeliveryTime {
    DontCare = 0,
    Morning = 1,
    Noon = 2,
    Afternoon = 3,
}

impl From<DeliveryTime> for i32 {
    fn from(v: DeliveryTime) -> Self {
        v as i32
    }
}

impl Default for DeliveryTime {
    fn default() -> Self {
        DeliveryTime::DontCare
    }
}

impl TryFromI32 for DeliveryTime {
    fn try_from_i32(v: i32) -> Option<Self> {
        match v {
            0 => Some(DeliveryTime::DontCare),
            1 => Some(DeliveryTime::Morning),
            2 => Some(DeliveryTime::Noon),
            3 => Some(DeliveryTime::Afternoon),
            _ => None,
        }
    }
}

// code example
fn main() {
    let val = DeliveryTime::Morning;

    // assign message field from enum value
    let v: EnumField<DeliveryTime> = val.into();

    // assign default value to field
    let _: EnumField<DeliveryTime> = Default::default();

    // Use enum, panic if out of range
    let _ = v.unwrap();

    // Use enum, use default if out of range (your current accessor method)
    let _ = v.unwrap_or_default();

    // Get underlying i32
    let _: i32 = v.into();

    // Convert i32 to enum
    let _: EnumField<DeliveryTime> = 17i32.into();
}

Then, at some point you add night time delivery. Now there is an important difference between "default value" (don't care) and "unknown value" (some preference which we don't know and need to clarify).

That's exactly why the best practice is to always have the first variant be Unknown.  Not sure how to say this more clearly, but something must be getting lost in translation as this is at least the second time in this thread that I'm repeating myself.  Keep in mind that this is a best practice no matter what language bindings you are using.  Creating a special API for prost so that you don't have to follow this best practice means you won't be following the best practice for C++, Java and all other languages.  To quote myself again,

... this behavior is common to all official protocol buffer implementations, and it makes working with protocol buffers easier in the majority of cases, as long as you understand the rules and best practices. prost's goal is emphatically not to shield users from from having to understand protobuf best practices (although where possible it does make best practices straightforward).

I'd like to extend on my previous suggestion (EnumField enum) to show how one could create APIs that look very much like typical Rust std APIs and IMO are very ergonomic in all use cases (use case example at the bottom of the code snippet):

This example doesn't actually use the enum type as a field in a message, so it's impossible to compare the ergonomics of this alternate API.


Adding sphere

As discussed in #981.
(An extra comment: I did not expect just asserting the few properties discussed in the issue is enough to imply every possible trait, except the impossible one Cardinality = $\aleph_1$. That was truly a surprise.)

In fact, P3 ($T_2$) + P123 (Locally $n$-Euclidean) can be further simplified to a single P124 (Topological $n$-manifold) as https://github.com/pi-base/data/issues/981#issuecomment-2508780910 said. But anyway, it's equivalent and up to you to decide.

@yhx-12243 I know. I was the one who wrote that comment. It's just slightly easier this way, as I just needed toncopy from the traits of the circle.

In fact, P3 ( T 2 ) + P123 (Locally n -Euclidean) can be further simplified to a single P124 (Topological n -manifold) as #981 (comment) said. But anyway, it's equivalent and up to you to decide.

Also note that it may not be easier to check things.  We would have to check separately that the space is T2 and second countable.  It easier to just check Locally n-Euclidean , and derive the rest from embeddable in euclidean space.

For P200 (simnply connected), I think one also needs to mention the space is path connected, as Hatcher Prop 1.14 is only about the fundamental group.  (Otherwise it's kind of circular: Path connected is now derived from simply connected.)

@prabau Oh, sure. I thought of Hatcher's statement as implicitly implying $S^2$ is path connected, as otherwise the fundamental group, without specifying a base point, is not even well-defined. But it certainly won't hurt to make that more explicit.


[move-vm] Expose API for load modules

Motivation
This is a follow up PR for #9875 as a fix for our performance regression in parallel execution. After adding a block metadata transaction at the beginning of each transaction block, the overall system perf dropped by 2x and causes parallel execution to be slower than the sequential version. The reason was following:
Blockmetadata transaction will modify the timestamp resources that will be read by every transaction's prologue. Thus when parallel executor starts, only one thread get to execute the block metadata transaction, and all other threads are just waiting for that transaction to be executed. This causes a serious issue: the system is now spending 2x time on cold starting the MoveVM (one spent on the first block metadata transaction and one for all the other threads). This explains the serious performance regression we had in our benchmark change introduced in #9875.
To fix this regression, we change the init function for DiemVM such that when DiemVM is constructed, it will try to load 0x1::DiemAccount into its code cache. By doing so, we are warming up MoveVM's code cache all at once before any parallel execution starts. To make this work, a new api is added to MoveVM so that we can force VM to load up a module from a remote storage.
With the fix, the performance number now looks like following:
peer_to_peer_parallel   time:   [146.38 ms 151.36 ms 156.38 ms]
                        change: [-57.597% -55.812% -54.353%] (p = 0.00 < 0.05)
                        Performance has improved.

Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
cargo bench
Comparing with main without the fix:
peer_to_peer_parallel   time:   [376.31 ms 379.99 ms 383.68 ms]
                        change: [+142.47% +151.06% +160.04%] (p = 0.00 < 0.05)
                        Performance has regressed.

The speed actually differs by roughly 2x when the transaction block size is 1000.

/land


Can't build the flutter application.

I follow the documentation of the thingsboard mobile development.
Below error comes on flutter run...
PS C:\Users\Admin\Desktop\flutter_thingsboard_app> flutter run
"ar": 73 untranslated message(s).
"zh": 92 untranslated message(s).
"zh_CN": 92 untranslated message(s).
"zh_TW": 91 untranslated message(s).
To see a detailed report, use the untranslated-messages-file
option in the l10n.yaml file:
untranslated-messages-file: desiredFileName.txt
:
This will generate a JSON format file containing all messages that
need to be translated.
Launching lib\main.dart on SM A707F in debug mode...
FAILURE: Build completed with 2 failures.
1: Task failed with an exception.
Where:
Build file 'C:\Users\Admin\Desktop\flutter_thingsboard_app\android\build.gradle' line: 14
What went wrong:
A problem occurred evaluating root project 'android'.
A problem occurred configuring project ':app'.
Could not create task ':app:copyFlutterAssetsDebug'.

Could not create task ':app:mergeDebugAssets'.

Try:
Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.
Get more help at https://help.gradle.org/.
2: Task failed with an exception.
Where:
Build file 'C:\Users\Admin\Desktop\flutter_thingsboard_app\android\build.gradle' line: 14
What went wrong:
A problem occurred evaluating root project 'android'.
A problem occurred configuring project ':app'.
Could not create task ':app:copyFlutterAssetsDebug'.

Could not create task ':app:mergeDebugAssets'.
Cannot use @TaskAction annotation on method IncrementalTask.taskAction$gradle_core() because interface org.gradle.api.tasks.incremental.IncrementalTaskInputs is not a valid parameter to an action method.

Try:
Run with --stacktrace option to get the stack trace.
Run with --info or --debug option to get more log output.
Run with --scan to get full insights.
Get more help at https://help.gradle.org/.
BUILD FAILED in 1s
Running Gradle task 'assembleDebug'... 2,666ms
Error: Gradle task assembleDebug failed with exit code 1
PS C:\Users\Admin\Desktop\flutter_thingsboard_app>

Hi,
Please check if this response will help you resolve the issue https://github.com/thingsboard/flutter_thingsboard_pe_app/issues/194#issuecomment-2489107289

My java version
C:\Users\Admin>java --version
java 17.0.13 2024-10-15 LTS
Java(TM) SE Runtime Environment (build 17.0.13+10-LTS-268)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.13+10-LTS-268, mixed mode, sharing)

Can you provide details about your environment?

flutter version
mobile app version
IDE info

This is a PE repository, but you are building a CE app. So, we will proceed with the CE issues.

Sorry my mistake.


Timing package and new verbose flags

running bin/sdl with -m 7 flag will run without doing work needed for the validation plots after every event, which will run faster for timing and testing when validation plots are not needed
-v 0 no verbose printouts
-v 1 flag prints out object multiplicities and final timing results
-v 2 flag prints out just final timing results
All object excess warnings are under an #ifdef Warnings flag that is togglable in the SDL/Makefile
all other printouts are commented out now.
running sdl_timing will make and run all versions with -m 7 and -v 2 flags to produce timing results for all of them.
Current results (not including PR26)
                            Evt     Hits         MD       LS            T4             T4x       pT4        T3           TC       Total

unified :                   avg   397.99   123.47   238.14   248.87   1923.52   4459.98   131.81   412.90   7936.67
unified cache:          avg   389.46   109.89   283.48   382.29   1873.74   4404.24    98.29   409.44   7950.81
uni cache new grid: avg   384.68     8.04    22.90   176.07   1861.07   4194.11    46.59   418.17   7111.62
uni new grid:           avg   386.04    15.88    69.92   193.17   1948.21   4627.23    94.31   426.01   7760.77
explicit:                    avg   385.26   111.78   277.89   416.79   1893.24   4486.65    86.21   416.85   8074.67
explicit newgrid:      avg   382.98     9.01    20.88   175.34   1887.76   4553.56    30.47   392.70   7452.70
explicit cache:          avg   361.12   115.25   288.50   427.39   1901.78   4600.97    85.90   401.47   8182.38
explilcit cache grid:  avg   362.33     7.10    21.43   185.17   1903.47   4470.77    27.28   438.80   7416.35

explicit: avg 385.26 111.78 277.89 416.79 1893.24 4486.65 86.21 416.85 8074.67
explicit newgrid: avg 382.98 9.01 20.88 175.34 1887.76 4553.56 30.47 392.70 7452.70

it looks like all values can be rounded to int.
Some pretty-print variant that would look good with markdown would be nice.

explicit: avg 385.26 111.78 277.89 416.79 1893.24 4486.65 86.21 416.85 8074.67
explicit newgrid: avg 382.98 9.01 20.88 175.34 1887.76 4553.56 30.47 392.70 7452.70

it looks like all values can be rounded to int.
Some pretty-print variant that would look good with markdown would be nice.

I've updated this to include a final printout statement when running sdl_timing to get all the timing results from each setup condition. all the timing results are saved to the output timing_temp.txt. Finally, all the average times have precision set to 0 (but not per event timing).
Results (for muonGun) are here:

I've updated this to include a final printout statement when running sdl_timing to get all the timing results from each setup condition. all the timing results are saved to the output timing_temp.txt. Finally, all the average times have precision set to 0 (but not per event timing).
Results (for muonGun) are here:

Results (for muonGun) are here:

the screen shot is easier to parse visually. Thanks.

Results (for muonGun) are here:

the screen shot is easier to parse visually. Thanks.

for completeness: here are PU200 times with PR26 included

for completeness: here are PU200 times with PR26 included


vue-good-table not compatible with vue 3

Version
3.2.31
Reproduction link
localhost/editordashboard
Steps to reproduce
Vue Good Table is not compatible with vue 3
What is expected?
Should be compatible
What is actually happening?
Not compatible

Solve this issue is soon is possiable.

@borisflesch is working on a Vue 3 compatible version of VGT . Please follow/contribute to his repository as it gets production
ready: vue-good-table-next


uemacs: init at 4.0-unstable-2018-07-19

Description of changes
Added the uemacs package for a more Torvalds complete distro /j

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Reasons for removal in #101112 no longer apply.
The buffer overflow is fixed (likely due to a newer version), someone sacrificed themself as meta.maintainer and the whole licenses.unfree has been somewhat discussed (and has a comment above mentioning non-commercial now).