README misleading when comparing to SQLite

The README says:

You can think of it as a SQLite for Node.js projects, which can be used with a simple require statement.

One of the major features of SQLite is that it is safe for multiple process use, even though it does not support concurrent modifications (there's locking for multiple concurrent transactions). The other major feature is that it is crash safe in the way that when a commit returns, the data is guaranteed to be synced to disk.
I think NeDB requires a big warning that data is not guaranteed to be persisted after callback returns, and that NeDB has no support for concurrent access from separate processes.
Great project, nevertheless!

NeDB doesn't support concurrent connections out of the box indeed, but it is crash safe (at least designed to be, still investigating the recent bug report). The readme intro is quite old though you're right, now nedb is well known enough not to need to be compared with another product.

It is (or seems to be) crash safe in the manner that there should be no corruption in the case of crashes - but it is not crash safe in the manner that there would be a "commit" operation that would guarantee the changes have been persisted. Atleast I did not spot any fsync calls in the persistence module.
This means it cannot be used in any situation where you need to store something persistently before trying an action - such as storing a request id before sending a request to be able to query status or cancel it later.

There is no need to call fsync in the persistence layer as appendFile will guarantee data is persisted to disk before executing the callback.

@louischatriot: Thanks for open-sourcing your work on nedb!

appendFile will guarantee data is persisted to disk before executing the callback

I'm not so sure. My understanding (in line with this SO answer) is that node only implements thin async wrappers around file system calls and does not provide atomicity/durability guarantees because they're just calling write(2):

A successful return from write() does not make any guarantee that
data has been committed to disk.  In fact, on some buggy
implementations, it does not even guarantee that space has
successfully been reserved for the data.  The only way to be sure is
to call fsync(2) after you are done writing all your data.

IOW, node will call the callback once the data is written to the OS's buffer cache, not when it is actually physically written.
Scanning the node & libuv source code seems to confirm that it's just a thin async wrapper around write(2) & doesn't call fsync() under the hood (appendFile() calls writeFile() with the "a" flag, writeFile() calls fs.write() repeatedly until the data is written and fs.write() calls writeBuffer() or writeString() on node's native fs binding, which call uv_fs_write() and make the system call write(2) respectively. The implementation of uv_fs_write() is hard to for me follow, but it doesn't look like it calls fsync() -- it looks like fsync() is only called when the user calls fs.fsync() or fs.fsyncSync() directly).
That said, because of the performance hit, I'm not sure you would want to call fs.fsync() or fs.fsyncSync() implicitly, it might be the kind of thing the user should call or configure explicitly if they need a guarantee of durability.

@prust thanks for the details!
After diving into the issue I agree that this was actually an issue. As of v1.4.1, NeDB will always force OS to physically write data to disk whenever a compaction or database load happens, so that you can never lose the whole database in case of a machine crash. It doesn't flush on every append for performance reasons, but potential data loss in that case is very limited, a few docs at most. That's what major databases do.
Readme: https://github.com/louischatriot/nedb#persistence
Note that fsync doesn't work on Windows. Not sure whether that's an issue with my machine or you simply can't fsync on Windows. I raised the question with the Node team but any help appreciated!

All major databases sync after each transaction - which, with autocommit, is after each document. This is the part in SQLite explaining this: https://www.sqlite.org/pragma.html#pragma_synchronous . A similar option is in MySQL: http://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit . Same for PostgreSQL: http://www.postgresql.org/docs/9.1/static/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT . Here it is for CouchDB: http://docs.couchdb.org/en/1.6.1/config/couchdb.html#couchdb/delayed_commits .
Choosing not to sync after each write is fine as long as it is mentioned - the readme bit is good, except for the part that says it works similarily to major databases (it also has a typo "phyiscal").
However, the compaction implementation currently is dangerously wrong. It is renaming tempFilename to filename before calling fsync which means that a crash there gives a very real chance that filename exists and is empty while oldFilename still contains the full database data. This can be fixed by moving the flushToStorage call to happen before the rename. Secondly, the first flushToStorage is useless as it will only ensure the data inside the file is synced, which is already handled by the normal crash recovery - it does not enforce that the rename has happened. Thirdly, nothing ensures the directory entry is flushed, meaning that a correct response from the filesystem (in a crash) could be that the new file does not appear in the directory, but the old file is unlinked (though note that most filesystems do not behave this way). You need to fsync the directory before calling ensureFileDoesNotExist on oldFilename at the very least. If you wanted the rename from filename to oldFilename be synchronized to disk (and the unlinks before it) as per the comment, then you should replace the first flushToStorage call with something that calls fsync on the directory.
Note that I have not fully audited the implementation against corruption in a crash, these were just the first things to come to mind when looking at the implementation. Ensuring data integrity has to be either taken very seriously, because it is very hard to get right, or no integrity claims should be made.

The code you see on the master branch is still not live, as it was indeed not crash-proof. I unpublished v1.4.1 while I'm working on the final version. The readme will be accurate once this version is pushed.
It's taking a long time since I'm not a filesystem expert so I'm having a friend review this part of the code. I may be interested in having some more pair of eyes look at this part of the code before republishing v1.4.1, as you say this is both crucial and very hard to get right.

Okay, that sounds great! I can take a peek later on to see if I can spot anything amiss.

I finished rewriting the crash safe write function, mimicing how Redis AOF basically works (see http://oldblog.antirez.com/post/redis-persistence-demystified.html).
See https://github.com/louischatriot/nedb/blob/master/lib/storage.js
Basically what it does is:

fsync directory so that datafile is sure to be linked to from the directory
fsync datafile if it exists. At this point we are guaranteed that datafile is up to date, and a crash during steps 1 or 2 will not corrupt the datafile
Write data to a temp datafile, then fsync it
Rename temp datafile to datafile and fsync directory

And upon reload, always use the contents of the datafile except in the (pathological) case where datafile doesn't exist but temp datafile does, which cannot be done by nedb (the user needs to do it manually, at which point we can assume he's trying to crash nedb on purpose !).
Now if there is a crash during steps 1 or 2, the datafile is no more corrupt than before, no data that was already persisted to disk is lost. Of course everything that was in the kernel buffer cache is lost but on pretty much all OSes that's at most 30s of data.
If there is a crash during step 3 or 4, the temp datafile may be corrupt and incomplete. In that case we use the datafile, we have lost the same data we lost in step 2
After step 4 the new data is persisted fully to disk. The rename being atomic we are guaranteed at this stage that the temp datafile doesn't exist anymore. The fsync on the directory is necessary though, or a crash right after step 4 could lose the same data as above.
I'm interested in any comments you guys might have on this, more eyes are always better :)

The algorithm looks to be correct, but I'm not sure if you've defined what is the consistency guarantee.
An obvious one is that compaction should never cause any rollback - meaning that any data that has already reached stable storage is not erased by compaction.
That requires only doing fsync on the temp datafile contents before rename (step 3). Everything else is superfluous.
Another one might be that compaction means also that all data is flushed to disk, meaning that a compaction is also a commit.
If that is wished then fsync on the directory after rename is also needed (step 4).
Steps 1 and 2 are just commits on data before compaction, which do not really serve a purpose - except if we believe that compaction is a long running operation and we wish to ensure that the latest "diff" before compaction is persisted to disk (a fast operation) as we might crash during the long compaction.
Also, the flushToStorage operation seems a bit weird. It doesn't close the file if fsync errors and lines 59 and 60 are probably to be removed?

There is no real consistency in the RDBMS sense as NeDB doesn't implement transactions, foreign keys, constraints and so on ... Integrity is guaranteed by the append-only, one-line-per-operation format of the datafile. Any corrupt line is discarded, which can be the case if there is a power loss during an append, but that can only affect the end of the file so that's the same as losing latest data.
Also there cannot indeed be any rollback, since the datafile is replaced only after a successful write.
Durability is not enforced on every write, only during compaction since a power loss at that moment can result in 100% data loss. For all appends to the datafile durability is the responsibility of the OS, which usually syncs to the disk every 30 seconds so you cannot lose more than 30 seconds of data. That's what most databases do (they do provide an option to force sync on every wrtie though, nedb doesn't).
fsync on steps 1 and 2 are actually useful only when the database is first created. As you say once it is created they are not needed. Still unsure as to keep them.
Good catch on flushToStorage, line 57 should be removed and file closed if fsync fails anyway.
Thanks for your help !
PS : this code doesn't work on Windows, as it seems that Windows's counterpart to fsync, FlushFileBuffers cannot be called on directories. That's not a show stopper but do you whether that's correct ? Here is the article I got this info from : http://blog.httrack.com/blog/2013/11/15/everything-you-always-wanted-to-know-about-fsync/

I just pushed the new flushToStorage, if you want to look at it. Still investigating the Windows fsync but I'll probably simply not fsync directories on Windows, as stated above there is no risk of 100% dataloss except the very first time the database is created. I

I just published v1.5.0, which includes this guarantee on durability.


"Add Rochan to team_members"

Looks great, thanks! Now I just need to ping again about actually getting this hosted...


Document bibtool/bib-tool as required

At some point bibtool became required, this is not a big dependency, so update the README to call it out.
Also add instructions for installing on OS X where the name is not quite the same.
Closes #15

Thanks!


Refactoring Slice - Empty Conditions

This change separates the concept of an empty condition from that of a renderable condition. This will enable a future change where conditions could decide to allow rendering even if they are considered empty (such as rendering empty lists). This change should be transparent to users unless they have implemented custom conditions.
This is a refactoring slice that will enable a simpler change for #752

coverage: 100.0%. remained the same
when pulling 2d52703397d0ebff980bf88bb42387fc5b47d9de on jeffgbutler:separate-empty-from-renderable
into 44b79f76d59967393b640d3f43d87a3d640b8a7a on mybatis:master.

@jeffgbutler I had added codeql on all of our stuff in mybatis.  It failed pretty much out the gate on nearly all.  Totally safe to entirely ignore for now.  I'll circle back to it at some point and get it working.

Thanks @hazendaz!


[FEAT] EIT p/f generator plugin

Is your feature request related to a problem?
When generating homemade EIT tables using the TSDuck tools it's easy to create the schedule events. At time, we can generate the content using the XML TSDuck format manually (aka from custom script) or using some third party tool (opensource). However, this is true only for the schedule tables. But for the Present/Following tables this is not the case. Then, the suggestion is to provide a new plugin that generates these tables.
Proposed solution:
The idea is quite simple: Based on the content of the schedule tables, the new plugin eitgen can use the readed content of the schedule tables (from the pid 18) and the current time (from the TOT/TDT tables) to generate the P/F tables.
Alternatives:
Using the current implementation of the TSDuck, and without other external tool, this is very hard to achieve it. However, you can do it with this complex solution: Using the tables plugin you can export the EIT information to XML. Then using a script you can calculate the current and next event and extract them from the XML. After that you can patch the XML to generate the corresponding P/F table. And finally you can compile the binary representation and inject inside the stream. This will work, but is very inefficient and prone to errors using scripts.
Additional information:
This new eitgen plugin can support some different parameters. For exemple:

--service srv1[,srv2,... | all]: This indicates for which (actual) services the P/F tables are generated. The flag "all" represents all services in the current TS.
--service-other srv1:tsid[,srv2:tsid,... | all]: This indicates for which other services the P/F tables are generated. The format is "ServiceID:transportStreamID". And the flag "all" here represents all services (from the schedule tables) known in other TS.
--auto-empty: If no schedule event is found, then generate default events (based for example on the service name, and filling the gap until the next known event).
--from filename[.bin | .xml]: Read the schedule event data from an external file (BIN or XML), instead of use the data in the pid 18 (that perhaps doesn't exist).
`--time-offset value]: The minutes of the local time to offset in reference to the event time.
--time [tdt | system | date]: Use as the current time the time inside the TS, the system clock or the "date" value as the starting time.

I feel that with the current implementation of the TSDuck library it will be easy to do a loop inside the plugin to review the current EIT data and extract this info.
What you think @lelegard ? It's this plugin feasible?

It's this plugin feasible?

It is, indeed. It's just work and time. Any volunteer to develop it?

Please try the new plugin eitinject. Be sure to read its reference section in the user's guide first.


Cannot launch bebop_node.launch

Hey guys. Getting following error:
PARAMETERS

/bebop/robot_description: <?xml version="1....
/rosdistro: indigo
/rosversion: 1.11.20

NODES
/bebop/
bebop_driver (bebop_driver/bebop_driver_node)
robot_state_publisher (robot_state_publisher/robot_state_publisher)
auto-starting new master
process[master]: started with pid [16121]
ROS_MASTER_URI=http://localhost:11311
setting /run_id to 829426e2-7cda-11e6-8573-0024e8cfd983
process[rosout-1]: started with pid [16134]
started core service [/rosout]
process[bebop/bebop_driver-2]: started with pid [16141]
process[bebop/robot_state_publisher-3]: started with pid [16152]
[ INFO] [1474118862.405218917]: Initializing nodelet with 2 worker threads.
[ INFO] [1474118862.468457685]: [BebopSDK] 15:27:42:468 | Bebop:230 - Bebop Cnstr()
[ INFO] [1474118862.468590244]: Nodelet Cstr
[ INFO] [1474118862.472868092]: Connecting to Bebop ...
[ INFO] [1474118862.713580127]: [BebopSDK] 15:27:42:713 | CommandReceivedCallback:113 - Command Received Callback LWP id is: 16268
[ERROR] [1474118862.867989008]: [ARCONTROLLER_Network] 15:27:42:867 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ERROR] [1474118862.871437212]: [ARCONTROLLER_Network] 15:27:42:871 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ERROR] [1474118862.874543473]: [ARCONTROLLER_Network] 15:27:42:874 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ERROR] [1474118862.940212578]: [ARCONTROLLER_Network] 15:27:42:940 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 common.CommonState.UNKNOWN -> Unknown command
[ INFO] [1474118862.953768631]: [BebopSDK] 15:27:42:953 | Connect:326 - BebopSDK inited, lwp_id: 16141
[ INFO] [1474118862.953857749]: Fetching all settings from the Drone ...
[ INFO] [1474118863.071386661]: Value for GPSSettingsHomeTypeType recved: 0
[ INFO] [1474118863.071473543]: [CB] 15:27:43:071 | Update:1703 - Checking if GPSSettingsHomeTypeType exists in params ...
[ INFO] [1474118863.073020388]: [CB] 15:27:43:072 | Update:1706 -   No
[ERROR] [1474118863.092875287]: [ARCONTROLLER_Network] 15:27:43:092 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ERROR] [1474118863.100761206]: [ARCONTROLLER_Network] 15:27:43:100 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ERROR] [1474118863.104702699]: [ARCONTROLLER_Network] 15:27:43:104 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ INFO] [1474118863.189877636]: Value for PilotingSettingsMaxAltitudeCurrent recved: 30
[ INFO] [1474118863.189995598]: [CB] 15:27:43:189 | Update:111 - Checking if PilotingSettingsMaxAltitudeCurrent exists in params ...
[ INFO] [1474118863.191580856]: [CB] 15:27:43:191 | Update:114 -   No
[ INFO] [1474118863.193173377]: Value for PilotingSettingsMaxDistanceValue recved: 160
[ INFO] [1474118863.193235326]: [CB] 15:27:43:193 | Update:352 - Checking if PilotingSettingsMaxDistanceValue exists in params ...
[ INFO] [1474118863.194297682]: [CB] 15:27:43:194 | Update:355 -   No
[ INFO] [1474118863.200952648]: Value for PilotingSettingsNoFlyOverMaxDistanceShouldnotflyover recved: 0
[ INFO] [1474118863.201026121]: [CB] 15:27:43:201 | Update:432 - Checking if PilotingSettingsNoFlyOverMaxDistanceShouldnotflyover exists in params ...
[ INFO] [1474118863.202526521]: [CB] 15:27:43:202 | Update:435 -   No
[ INFO] [1474118863.204033976]: Value for PilotingSettingsMaxTiltCurrent recved: 20
[ INFO] [1474118863.204078953]: [CB] 15:27:43:204 | Update:191 - Checking if PilotingSettingsMaxTiltCurrent exists in params ...
[ INFO] [1474118863.204989544]: [CB] 15:27:43:204 | Update:194 -   No
[ INFO] [1474118863.206983024]: Value for PilotingSettingsAbsolutControlOn recved: 0
[ INFO] [1474118863.207043856]: [CB] 15:27:43:207 | Update:271 - Checking if PilotingSettingsAbsolutControlOn exists in params ...
[ INFO] [1474118863.207771113]: [CB] 15:27:43:207 | Update:274 -   No
[ INFO] [1474118863.219866157]: Value for PilotingSettingsBankedTurnValue recved: 0
[ INFO] [1474118863.219941096]: [CB] 15:27:43:219 | Update:513 - Checking if PilotingSettingsBankedTurnValue exists in params ...
[ INFO] [1474118863.221278557]: [CB] 15:27:43:221 | Update:516 -   No
[ INFO] [1474118863.222701014]: Value for SpeedSettingsMaxVerticalSpeedCurrent recved: 1
[ INFO] [1474118863.222754303]: [CB] 15:27:43:222 | Update:1075 - Checking if SpeedSettingsMaxVerticalSpeedCurrent exists in params ...
[ INFO] [1474118863.223785230]: [CB] 15:27:43:223 | Update:1078 -   No
[ INFO] [1474118863.225613466]: Value for SpeedSettingsMaxRotationSpeedCurrent recved: 100
[ INFO] [1474118863.225654602]: [CB] 15:27:43:225 | Update:1155 - Checking if SpeedSettingsMaxRotationSpeedCurrent exists in params ...
[ INFO] [1474118863.226362234]: [CB] 15:27:43:226 | Update:1158 -   No
[ INFO] [1474118863.234484077]: Value for SpeedSettingsHullProtectionPresent recved: 0
[ INFO] [1474118863.234542464]: [CB] 15:27:43:234 | Update:1235 - Checking if SpeedSettingsHullProtectionPresent exists in params ...
[ INFO] [1474118863.235710071]: [CB] 15:27:43:235 | Update:1238 -   No
[ INFO] [1474118863.237468674]: Value for SpeedSettingsOutdoorOutdoor recved: 1
[ INFO] [1474118863.237520497]: [CB] 15:27:43:237 | Update:1315 - Checking if SpeedSettingsOutdoorOutdoor exists in params ...
[ INFO] [1474118863.238472852]: [CB] 15:27:43:238 | Update:1318 -   No
[ INFO] [1474118863.251575217]: Value for SpeedSettingsMaxPitchRollRotationSpeedCurrent recved: 300
[ INFO] [1474118863.251644220]: [CB] 15:27:43:251 | Update:1395 - Checking if SpeedSettingsMaxPitchRollRotationSpeedCurrent exists in params ...
[ INFO] [1474118863.252927833]: [CB] 15:27:43:252 | Update:1398 -   No
[ INFO] [1474118863.254569382]: Value for NetworkSettingsWifiSelectionType recved: 1
[ INFO] [1474118863.254622043]: [CB] 15:27:43:254 | Update:1501 - Checking if NetworkSettingsWifiSelectionType exists in params ...
[ INFO] [1474118863.255588437]: [CB] 15:27:43:255 | Update:1504 -   No
[ INFO] [1474118863.258823625]: Value for NetworkSettingsWifiSelectionBand recved: 0
[ INFO] [1474118863.259016945]: [CB] 15:27:43:258 | Update:1522 - Checking if NetworkSettingsWifiSelectionBand exists in params ...
[ INFO] [1474118863.259923764]: [CB] 15:27:43:259 | Update:1525 -   No
[ INFO] [1474118863.260750476]: Value for NetworkSettingsWifiSelectionChannel recved: 6
[ INFO] [1474118863.260784000]: [CB] 15:27:43:260 | Update:1543 - Checking if NetworkSettingsWifiSelectionChannel exists in params ...
[ INFO] [1474118863.261342241]: [CB] 15:27:43:261 | Update:1546 -   No
[ INFO] [1474118863.290460818]: Value for PictureSettingsVideoStabilizationModeMode recved: 0
[ INFO] [1474118863.290513059]: [CB] 15:27:43:290 | Update:1623 - Checking if PictureSettingsVideoStabilizationModeMode exists in params ...
[ INFO] [1474118863.291447187]: [CB] 15:27:43:291 | Update:1626 -   No
[ERROR] [1474118863.293378298]: [ARCONTROLLER_Network] 15:27:43:293 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ERROR] [1474118863.296448102]: [ARCONTROLLER_Network] 15:27:43:296 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ERROR] [1474118863.315566944]: [ARCONTROLLER_Network] 15:27:43:315 | ARCONTROLLER_Network_ReaderRun:940 - ARCOMMANDS_Decoder_DecodeBuffer () failed : 2 ARDrone3.PictureSettingsState.UNKNOWN -> Unknown co
[ INFO] [1474118863.330631988]: Value for GPSSettingsReturnHomeDelayDelay recved: 60
[ INFO] [1474118863.330693518]: [CB] 15:27:43:330 | Update:1783 - Checking if GPSSettingsReturnHomeDelayDelay exists in params ...
[ INFO] [1474118863.333176795]: [CB] 15:27:43:333 | Update:1786 -   No
[ INFO] [1474118863.336192262]: Value for GPSSettingsHomeTypeType recved: 0
[ INFO] [1474118863.336302541]: [CB] 15:27:43:336 | Update:1703 - Checking if GPSSettingsHomeTypeType exists in params ...
[ INFO] [1474118863.338623088]: [CB] 15:27:43:338 | Update:1711 -   Yes
[ INFO] [1474118866.113073247]: Dynamic reconfigure callback with level: -1
[ INFO] [1474118866.136688121]: Enabling video stream ...
[ WARN] [1474118866.136829969]: [BebopSDK] 15:27:46:136 | StartStreaming:364 - Video streaming started ...
[ INFO] [1474118866.136956032]: Nodelet lwp_id: 16141
[ INFO] [1474118866.137009601]: bebop_driver nodelet loaded.
[ INFO] [1474118866.137100045]: [CameraThread] thread lwp_id: 16463
[ INFO] [1474118866.137190559]: [AuxThread] thread lwp_id: 16464
[ WARN] [1474118866.158027497]: [ARSTREAM2_H264Filter] 15:27:46:157 | ARSTREAM2_H264Filter_RtpReceiverNaluCallback:1201 - ARSTREAM2_RtpReceiver NALU buffer is too small, truncated AU (or maybe it's the fi
[ WARN] [1474118866.167337480]: [ARSTREAM2_H264Filter] 15:27:46:167 | ARSTREAM2_H264Filter_enqueueCurrentAu:481 - AU output cancelled (waitForSync)
[ WARN] [1474118866.201722369]: [ARSTREAM2_H264Filter] 15:27:46:201 | ARSTREAM2_H264Filter_enqueueCurrentAu:481 - AU output cancelled (waitForSync)
[ WARN] [1474118866.231175626]: [ARSTREAM2_H264Filter] 15:27:46:231 | ARSTREAM2_H264Filter_enqueueCurrentAu:481 - AU output cancelled (waitForSync)
[ WARN] [1474118866.266660026]: [ARSTREAM2_H264Filter] 15:27:46:266 | ARSTREAM2_H264Filter_enqueueCurrentAu:481 - AU output cancelled (waitForSync)
[ WARN] [1474118866.292939904]: [ARSTREAM2_H264Filter] 15:27:46:292 | ARSTREAM2_H264Filter_sync:161 - SPS/PPS sync OK
[ INFO] [1474118866.292996196]: [BebopSDK] 15:27:46:292 | DecoderConfigCallback:147 - H264 configuration packet received: #SPS: 27 #PPS: 9 (MP4? 0)
[ WARN] [1474118866.293077003]: [ARSTREAM2_H264Filter] 15:27:46:293 | ARSTREAM2_H264Filter_generateGrayIFrame:568 - Waiting for a slice to generate gray I-frame
[ WARN] [1474118866.293136577]: [ARSTREAM2_H264Filter] 15:27:46:293 | ARSTREAM2_H264Filter_generateGrayIFrame:568 - Waiting for a slice to generate gray I-frame
[ WARN] [1474118866.293288622]: [ARSTREAM2_H264Filter] 15:27:46:293 | ARSTREAM2_H264Filter_generateGrayIFrame:618 - Gray I slice NALU output size: 1629
[ INFO] [1474118866.293336323]: [BebopSDK] 15:27:46:293 | FrameReceivedCallback:174 - Frame Recv & Decode LWP id: 16466
[ INFO] [1474118866.295966127]: [Decoder] 15:27:46:295 | InitCodec:133 - H264 Codec is initialized!
[ INFO] [1474118866.296011175]: [Decoder] 15:27:46:295 | Decode:235 - Updating H264 codec parameters (Buffer Size: 36) ...
[bebop/bebop_driver-2] process has died [pid 16141, exit code -11, cmd /home/dennis/bebop_ws/devel/lib/bebop_driver/bebop_driver_node __name:=bebop_driver __log:=/home/dennis/.ros/log/829426e2-7cda-11e6-8573-0024e8cfd983/bebop-bebop_driver-2.log].
log file: /home/dennis/.ros/log/829426e2-7cda-11e6-8573-0024e8cfd983/bebop-bebop_driver-2*.log
ROS-Indigo
bebop firmware 3.9.0
ubuntu 14.04

i guess its about the picturesettingsstate. bebop has 3 picture types and he isnt sure, which i want to use. Someone know how to fix it?

Could someone help me please?

I saw your post on ROS answers. I'll try to help you there :)

Possibly related to #67 #68. If so, could you please close this issue in favour of those?

Hi, did you fix the problem? :)
Thanks!


OCPBUGS-44730: Metrics: add ipv4/6 addresses_in_use_total and addresses_total

Backporting the per ip family allocation metrics

/jira refresh

/label backport-risk-assessed

/label cherry-pick-approved

/jira refresh

/lgtm


bug: mappings of gj and gk do not work

Check the following:

[X] I have checked the behavior after setting "vscode-neovim.neovimClean" in VSCode settings.
[X] I have read the vscode-neovim docs.
[X] I have searched existing issues.

Neovim version (nvim -v)
0.9.5
Operating system/version
MacOS 14.3.1
Describe the bug
I put these key mappings in my init.vim:
nnoremap <Up> gk
nnoremap <Down> gj

But when I press Up and Down arrow key, they behave like k and j rather than gk and gj (do not handle the line wrap).
Other mappings for gj or gk, for example, nnoremap x gk, do not work either. However, gj and gk themselves behave normally.
Steps To Reproduce

Use the command nnoremap <Up> gk or put the command into your vimrc/init.vim.
Type  or  when the cursor is on a wrapped line. You'll see the cursor goes to the real previous/next line, rather than the display previou/next line.

Expected Behavior
gj and gk are supposed to navigate in the display line, as the neovim doc has highlighten.

is this different than the other "composite" issues https://github.com/vscode-neovim/vscode-neovim/issues?q=is%3Aissue+is%3Aopen+composite
see also https://github.com/vscode-neovim/vscode-neovim?tab=readme-ov-file#composite-escape-keys though it is about insert mode , not normal mode.

@justinmk Thanks for your response! I think they're different, because the problem only happens for gj and gk key mappings. And gj and gk themselves work normally (the same behavior as neovim). I think after key mapping, gj and gk lose their functionalities.

https://github.com/vscode-neovim/vscode-neovim/issues?q=is%3Aissue+gj+gk+is%3Aclosed

Thanks again! I finally know what should I do:
nmap <Up> gk
nmap <Down> gj

vmap <Down> gj  still doesn't work.


Remove prompt sign from shell statement.

Is your documentation request related to a problem? Please describe.
In the installation manual there are several command line statements to execute. It is good to have a copy link at the end of each. It is not good the copy includes the shell prompt ($) like
$ sudo tedge config set c8y.root.cert.path /etc/ssl/certs
In that way the command is not executable.
Describe the improvement you'd like
Please remove the prompt sign from the line.

I agree that the prompt is annoying when the point is to give the precise command for a specific step as in:
$ sudo tedge config set c8y.root.cert.path /etc/ssl/certs

However, the point of prefixing commands with an explicit prompt is not to save some typing but to convey many details in a single snapshot as below:
$ cat /etc/tedge/c8y/c8y-configuration-plugin.toml
files = [
    { path = '/etc/tedge/tedge.toml', type = 'tedge.toml' },
    { path = '/etc/tedge/mosquitto-conf/c8y-bridge.conf' },
    { path = '/etc/tedge/mosquitto-conf/tedge-mosquitto.conf' },
    { path = '/etc/mosquitto/mosquitto.conf', type = 'mosquitto', user = 'mosquitto', group = 'mosquitto', mode = 0o644 }
  ]

So, I'm okay to remove some prompts from the documentation but on a case-by-case basis.
That said, I also think a user must be cautious copy-pasting sudo command from a website!

Thanks @mstoffel-sag, yes that makes sense. Though we are always happen to accept doc PRs (it is sometimes faster than creating a ticket). I can run you through the process if you would like.

sure will do in the future.

@mstoffel-sag @didier-wenzek
I think we can tweak the formatting to separate the commands from the output to make it easier to copy for users, and separate the command from the output.
The following is an example where it splits the command and output into two code blocks. And when we split up the code blocks it enables the possibility to improve the layout even further in the future (via using other static website generators such as docusaurus). (I'm not saying that we should be switching to docusaurus, but saying that splitting is more flexible for the future.)

Code block example
You can then check the content of that certificate.
sudo tedge cert show

Device certificate: /etc/tedge/device-certs/tedge-certificate.pem
Subject: CN=my-device, O=Thin Edge, OU=Test Device
Issuer: CN=my-device, O=Thin Edge, OU=Test Device
Valid from: Tue, 09 Feb 2021 17:16:52 +0000
Valid up to: Tue, 11 May 2021 17:16:52 +0000
Thumbprint: CDBF4EC17AA02829CAC4E4C86ABB82B0FE423D3E

Code block with title (using docusaurus static website generator)

Another suggestion here.
We have to assume that users are very very lazy (as I am too :-)
Keeping that in mind we should provide one code block or script with the happy path and put all the exceptions at the end. I also stumbled into executing

by accident...

Another suggestion here.
We have to assume that users are very very lazy (as I am too :-) Keeping that in mind we should provide one code block or script with the happy path and put all the exceptions at the end. I also stumbled into executing  by accident...

I don't think we can prevent level of "laziness" ;)

Code block example

It's a nice compromise to separate the command line from its output.

The $ prefixes have now been removed, below is an example how it looks on the online docs

Link


⚠ Bofrost.be has degraded performance

In e8b48ef, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1307 ms

Resolved: Bofrost.be performance has improved in e8227db after 6 minutes.


Modal Dialog does not conform to WAI-ARIA accessibility guidelines

Bug Report
Description
ACCESSIBILITY ISSUE WITH MODAL DIALOG
The modal focus should wrap focusable elements when the user presses the tab key. A modal should give the first element focus and as the user tabs through the elements, each succeeding element in the logical flow should receive focus. When the last element is reached, pressing the tab key should wrap the focus to the first element.
The Terra ModalManager does not behave in the way as specified by the W3C WAI-ARIA guidelines and recommendations. For more information on modal practices see: https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal
The above link has a demo on how the modal dialog box is expected to work to make it more accessible. This is a somewhat of a barrier for keyboard-only and sight challenged users. For example, a non-sighted user will not know when he/she has reached the last button. Hitting tab will throw them off of the page and they have to find their way back to where they were.
Steps to Reproduce

Open the link: https://engineering.cerner.com/terra-ui/components/terra-modal-manager/modal-manager/about
Click on the Disclose (default) button
Use the tab key to move the focus to the various elements
At this time, the last focusable element is a text field. Hit tab again and the focus jumps out off the page and to the browser's address bar

Additional Context / Screenshots
From the following link, click on the Add Delivery Address button for the W3C example of how a modal dialog box should work.
https://www.w3.org/TR/wai-aria-practices-1.1/#dialog_modal
Expected Behavior
The focus should wrap when a user reaches the last focusable element and move to the first when the tab key is pressed.
Possible Solution
Remediate the modal dialog box to comply with W3C recommendations.
Environment

Component Name and Version:
Browser Name and Version:
Node/npm Version: [e.g. Node 8/npm 5]
Webpack Version:
Operating System and version (desktop or mobile):

@ Mentions

@tbiethman
Thank you for the update and consideration.


Design System -> Build verification - [Version <IP_ADDRESS>] received on 18th Nov

Design System -> Build verification - [Version <IP_ADDRESS>] received on 18th Nov
https://github.com/Wai-Technologies/raaghu-react/releases/tag/<IP_ADDRESS>(s)

Ready for Prod - 6
Reopen - 1
Already Closed - 5
In progress – 1
PR Approved - 1

Sr.No
PR
GitHub Link
Status
Remark
Dev
QA

1
Resolved Bug 766: Elements > Button > Size   not working proper selecting large size change by @DeepashriDatar in #888
Design   System > Version 8.3.3 >Elements > Button > Size not working   proper selecting large size change the background icon. · Issue #766 ·   Wai-Technologies/raaghu-react
PR Approved

Deepashri
Rameshwar

2
Completed Task 781 : Design System > Version   8.3.3 > side nav bar > excess space is showing between two components   by @abhijeetjawale1 in #891
Design   System > Version 8.3.3 > side nav bar > excess space is showing   between two components · Issue #781 · Wai-Technologies/raaghu-react

Already Closed
Abhijeet
Rameshwar

3
Resolved Bug 746 : Design System > Version 8.3   > Scroll bar alignment issue. by @poojagurav21 in #918
Design   System > Version 8.3 > Scroll bar alignment issue. · Issue #746 ·   Wai-Technologies/raaghu-react
In progress

Nitin
Rameshwar

4
Resolved Bug 814 : Design System > Version 8.3   > Component > Product list > Product list with Inline price >   small mobile > Not able to see full image. by @nitinsonawane123 in #964
Design   System > Version 8.3 > Component > Product list > Product list   with Inline price > small mobile > Not able to see full image · Issue   #814 · Wai-Technologies/raaghu-react

Ready for Prod
Nitin
Rameshwar

5
Resolved Bug 806 : Design System > Version 8.3   >Charts > Stacked Chart > Small and large mobile view chart is not   display proper by @poojagurav21 in #952
Design   System > Version 8.3 >Charts > Stacked Chart > Small and large   mobile view chart is not display proper. · Issue #806 ·   Wai-Technologies/raaghu-react

Ready for Prod
Pooja
Rameshwar

6
Resolved Bug 810 : Component > Datatable > Action   button on Left side > Not able to see the 'Edit' option after hovering   over the row below in the table by @VenuKG in #965
Design   System > Version 8.3 > Component > Datatable > Action button on   Left side > Not able to see the 'Edit' option after hovering over the row   below in the table · Issue #810 · Wai-Technologies/raaghu-react

Ready for Prod
Venu
Rameshwar

7
Resolved Bug 533 : Storybook> Click on change   the theme of the preview open list select light or dark then list not close.   by @nitinsonawane123 in #1058
Storybook>   Click on change the theme of the preview open list select light or dark then   list not close. · Issue #533 · Wai-Technologies/raaghu-react

Already Closed
Nitin
Rameshwar

8
Resolved Bug 972 : Components > Small, Large,   Tablet view Save Cancel button alignment issue by @nitinsonawane123 in #1017
Design   System > Components > Small, Large, Tablet view Save Cancel button   alignment issue. · Issue #972 · Wai-Technologies/raaghu-react

Already Closed
Nitin
Rameshwar

9
Resolved Bug 1052 : Design System > Elements   > Avatar > Default > Dark theme background does not display proper   by @poojagurav21 in #1056
Design   System > Elements > Avatar > Default > Dark theme background does   not display proper. · Issue #1052 · Wai-Technologies/raaghu-react

Ready for Prod
Pooja
Rameshwar

10
Resolved Bug 1047 : Design System > Components   > Billing > Default > Controls > Add billingData display error   message by @nitinsonawane123 in #1069
Design   System > Components > Billing > Default > Controls > Add   billingData display error message. · Issue #1047 ·   Wai-Technologies/raaghu-react

Already Closed
Nitin
Rameshwar

11
Resolved Bug 1005 : Design System >   Components> Claims > Default > Plus button alignment issue by @nitinsonawane123 in #1071
Design   System > Components> Claims > Default > Plus button alignment   issue. · Issue #1005 · Wai-Technologies/raaghu-react

Already Closed
Nitin
Rameshwar

12
Resolved Bug time picker element name change as   per the other element format by @abhijeetjawale1 in #1072
Design   System > Element > Create new element Time Picker. · Issue #900 ·   Wai-Technologies/raaghu-react

Ready for Prod
Abhijeet
Rameshwar

13
Completed Task 1046 : Design System > Element   > Create new element for Skeleton. by @dhirajlaha in #1064
Design   System > Element > Create new element for Skeleton. · Issue #1046 ·   Wai-Technologies/raaghu-react

Ready for Prod
Dhiraj
Rameshwar

14
Resolved Bug 1051 : Design System >Accordion   >Default > Dark theme chevron & border is not display proper   by @abhijeetjawale1 in #1063
Design   System >Accordion >Default > Dark theme chevron & border is not   display proper. · Issue #1051 · Wai-Technologies/raaghu-react

Reopen
Abhijeet
Rameshwar


Fleet Restart='always' not working with "Requires" directive

Given:  Main application unit file that Requires side kick service
[Unit]
Description=My Apache Frontend
After=docker.service
Requires=docker.service<EMAIL_ADDRESS>
[Service]
Restart=always
RestartSec=20s
TimeoutStartSec=0
ExecStartPre=-/usr/bin/docker kill apache1
ExecStartPre=-/usr/bin/docker rm apache1
ExecStartPre=/usr/bin/docker pull coreos/apache
ExecStart=/usr/bin/docker run -rm --name apache1 -p 80:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND
ExecStop=/usr/bin/docker stop apache1

[X-Fleet]
<EMAIL_ADDRESS>
And: Sidekick unit  that binds to application service.
[Unit]
Description=Announce Apache1
<EMAIL_ADDRESS><EMAIL_ADDRESS>
[Service]
Restart=always
RestartSec=20s
ExecStart=/bin/sh -c "while true; do etcdctl set /services/website/apache@%i '{ \"host\": \"%H\", \"port\": 80, \"version\": \"52c7248a14\" }' --ttl 60;sleep 45;done"
ExecStop=/usr/bin/etcdctl rm /services/website/apache@%i

[X-Fleet]
<EMAIL_ADDRESS>
And: Units are in running state
fleetctl submit<EMAIL_ADDRESS><EMAIL_ADDRESS>fleetctl load<EMAIL_ADDRESS><EMAIL_ADDRESS>fleetctl start<EMAIL_ADDRESS><EMAIL_ADDRESS>
And: When I stop the apache service
sudo docker stop apache1

Then:  My my unit and sidekick do not restart
fleetctl status<EMAIL_ADDRESS><EMAIL_ADDRESS>●<EMAIL_ADDRESS>- My Apache Frontend
   Loaded: loaded<EMAIL_ADDRESS>linked-runtime; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2015-01-12 20:18:50 UTC; 24s ago
  Process: 16469 ExecStop=/usr/bin/docker stop apache1 (code=exited, status=1/FAILURE)
  Process: 16046 ExecStart=/usr/bin/docker run -rm --name apache1 -p 80:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND (code=exited, status=255)
  Process: 15298 ExecStartPre=/usr/bin/docker pull coreos/apache (code=exited, status=0/SUCCESS)
  Process: 15290 ExecStartPre=/usr/bin/docker rm apache1 (code=exited, status=0/SUCCESS)
  Process: 15280 ExecStartPre=/usr/bin/docker kill apache1 (code=exited, status=0/SUCCESS)
 Main PID: 16046 (code=exited, status=255)

●<EMAIL_ADDRESS>- Announce Apache1
   Loaded: loaded<EMAIL_ADDRESS>linked-runtime; vendor preset: disabled)
   Active: inactive (dead) since Mon 2015-01-12 20:18:50 UTC; 1min 24s ago
  Process: 16471 ExecStop=/usr/bin/etcdctl rm /services/website/apache@%i (code=exited, status=0/SUCCESS)
  Process: 16048 ExecStart=/bin/sh -c while true; do etcdctl set /services/website/apache@%i '{ "host": "%H", "port": 80, "version": "52c7248a14" }' --ttl 60;sleep 45;done (code=killed, signal=TERM)
 Main PID: 16048 (code=killed, signal=TERM)
   CGroup<EMAIL_ADDRESS>

Env. Info
NAME=CoreOS
ID=coreos
VERSION=550.0.0
VERSION_ID=550.0.0
BUILD_ID=
PRETTY_NAME="CoreOS 550.0.0"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"
Workaround
Restart logic works fine if I use Wants directive instead of Requires.

+1

The Restart policy is only used if your process exits unexpectedly. By adding<EMAIL_ADDRESS>to your discovery service, you've told systemd that if<EMAIL_ADDRESS>stops (e.g. systemctl stop apache@1.service), then<EMAIL_ADDRESS>should also stop (e.g. systemctl stop apache-discovery@1.service). The discovery service is stopped gracefully, meaning that systemd will not try to restart it.

@bcwaldon  actually in this case I had stopped the docker process :
sudo docker stop apache1

In this case, shouldn't the restart policy take into effect?  I had also tried to kill the process using kill command  and still the policy did not apply.

No - if you systemctl stop foo.service, systemd does not restart foo.service. The restart policy is only applied when the process spawned by ExecStart fails unexpectedly.

I'm sorry - I got my issues mixed up here. If you shut down the container with the docker command, I would expect the Restart policy be applied. Do you have any logs from the<EMAIL_ADDRESS>or<EMAIL_ADDRESS>units?

I will reproduce the issue again ... and put more info.  But I could reproduce this every time so will be easy to get the info.

●<EMAIL_ADDRESS>- My Apache Frontend
   Loaded: loaded<EMAIL_ADDRESS>linked-runtime; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2015-02-09 20:21:06 UTC; 1min 3s ago
  Process: 2051 ExecStop=/usr/bin/docker stop apache1 (code=exited, status=1/FAILURE)
  Process: 1622 ExecStart=/usr/bin/docker run -rm --name apache1 -p 80:80 coreos/apache /usr/sbin/apache2ctl -D FOREGROUND (code=exited, status=255)
  Process: 1556 ExecStartPre=/usr/bin/docker pull coreos/apache (code=exited, status=0/SUCCESS)
  Process: 1545 ExecStartPre=/usr/bin/docker rm apache1 (code=exited, status=1/FAILURE)
  Process: 1534 ExecStartPre=/usr/bin/docker kill apache1 (code=exited, status=1/FAILURE)
 Main PID: 1622 (code=exited, status=255)

Feb 09 20:13:35 ip-10-229-8-189.us-west-1.compute.internal docker[1622]: Warning: '-rm' is deprecated, it will be replaced by '--rm' soon. See usage.
Feb 09 20:13:36 ip-10-229-8-189.us-west-1.compute.internal docker[1622]: apache2: Could not reliably determine the server's fully qualified domain name, using <IP_ADDRESS> for ServerName
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal systemd[1]<EMAIL_ADDRESS>main process exited, code=exited, status=255/n/a
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal systemd[1]: Stopping My Apache Frontend...
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal docker[2051]: Error response from daemon: No such container: apache1
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal docker[2051]: time="2015-02-09T20:21:06Z" level="fatal" msg="Error: failed to stop one or more containers"
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal systemd[1]<EMAIL_ADDRESS>control process exited, code=exited status=1
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal systemd[1]: Stopped My Apache Frontend.
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal systemd[1]: Unit<EMAIL_ADDRESS>entered failed state.
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal systemd[1]<EMAIL_ADDRESS>failed.

core@ip-10-229-8-189 ~ $ fleetctl status<EMAIL_ADDRESS>●<EMAIL_ADDRESS>- Announce Apache1
   Loaded: loaded<EMAIL_ADDRESS>linked-runtime; vendor preset: disabled)
   Active: inactive (dead) since Mon 2015-02-09 20:21:06 UTC; 1min 49s ago
  Process: 2052 ExecStop=/usr/bin/etcdctl rm /services/website/apache@%i (code=exited, status=0/SUCCESS)
  Process: 1638 ExecStart=/bin/sh -c while true; do etcdctl set /services/website/apache@%i '{ "host": "%H", "port": 80, "version": "52c7248a14" }' --ttl 60;sleep 45;done (code=killed, signal=TERM)
 Main PID: 1638 (code=killed, signal=TERM)
   CGroup<EMAIL_ADDRESS>
Feb 09 20:15:50 ip-10-229-8-189.us-west-1.compute.internal sh[1638]: { "host": "ip-10-229-8-189.us-west-1.compute.internal", "port": 80, "version": "52c7248a14" }
Feb 09 20:16:35 ip-10-229-8-189.us-west-1.compute.internal sh[1638]: { "host": "ip-10-229-8-189.us-west-1.compute.internal", "port": 80, "version": "52c7248a14" }
Feb 09 20:17:20 ip-10-229-8-189.us-west-1.compute.internal sh[1638]: { "host": "ip-10-229-8-189.us-west-1.compute.internal", "port": 80, "version": "52c7248a14" }
Feb 09 20:18:05 ip-10-229-8-189.us-west-1.compute.internal sh[1638]: { "host": "ip-10-229-8-189.us-west-1.compute.internal", "port": 80, "version": "52c7248a14" }
Feb 09 20:18:50 ip-10-229-8-189.us-west-1.compute.internal sh[1638]: { "host": "ip-10-229-8-189.us-west-1.compute.internal", "port": 80, "version": "52c7248a14" }
Feb 09 20:19:35 ip-10-229-8-189.us-west-1.compute.internal sh[1638]: { "host": "ip-10-229-8-189.us-west-1.compute.internal", "port": 80, "version": "52c7248a14" }
Feb 09 20:20:20 ip-10-229-8-189.us-west-1.compute.internal sh[1638]: { "host": "ip-10-229-8-189.us-west-1.compute.internal", "port": 80, "version": "52c7248a14" }
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal systemd[1]: Stopping Announce Apache1...
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal systemd[1]: Stopped Announce Apache1.
Feb 09 20:21:06 ip-10-229-8-189.us-west-1.compute.internal sh[1638]: { "host": "ip-10-229-8-189.us-west-1.compute.internal", "port": 80, "version": "52c7248a14" }

Feb 09 20:12:52 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO reconciler.go:163: EngineReconciler completed task: {Type: AttemptScheduleUnit, JobName<EMAIL_ADDRESS>MachineID: cd09fdcf520e44ddb918a34022a9c826, Reason: "target state loaded and unit not scheduled"}
Feb 09 20:12:53 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO manager.go:262: Writing systemd unit<EMAIL_ADDRESS>(485b)
Feb 09 20:12:53 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO reconcile.go:321: AgentReconciler completed task: type=LoadUnit<EMAIL_ADDRESS>reason="unit scheduled here but not loaded"
Feb 09 20:12:53 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO engine.go:272: Scheduled<EMAIL_ADDRESS>to Machine(cd09fdcf520e44ddb918a34022a9c826)
Feb 09 20:12:53 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO reconciler.go:163: EngineReconciler completed task: {Type: AttemptScheduleUnit, JobName<EMAIL_ADDRESS>MachineID: cd09fdcf520e44ddb918a34022a9c826, Reason: "target state loaded and unit not scheduled"}
Feb 09 20:12:54 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO manager.go:262: Writing systemd unit<EMAIL_ADDRESS>(390b)
Feb 09 20:12:54 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO reconcile.go:321: AgentReconciler completed task: type=LoadUnit<EMAIL_ADDRESS>reason="unit scheduled here but not loaded"
Feb 09 20:12:56 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO manager.go:134: Triggered systemd unit<EMAIL_ADDRESS>start: job=2730
Feb 09 20:12:56 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO reconcile.go:321: AgentReconciler completed task: type=StartUnit<EMAIL_ADDRESS>reason="unit currently loaded but desired state is launched"
Feb 09 20:12:56 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO manager.go:134: Triggered systemd unit<EMAIL_ADDRESS>start: job=2810
Feb 09 20:12:56 ip-10-229-8-189.us-west-1.compute.internal fleetd[707]: INFO reconcile.go:321: AgentReconciler completed task: type=StartUnit<EMAIL_ADDRESS>reason="unit currently loaded but desired state is launched"

Also confirmed the issue with latest alpha release CoreOS 584.0  and by using kill command.
@bcwaldon  can we re-open this issue ? Thanks.

@sukrit007 ok - I was able to get a reproducible test case that demonstrates this behavior directly in systemd. Filed upstream: https://bugs.freedesktop.org/show_bug.cgi?id=89087

Nice. Thx.

I think if fleetctl support restart, then using the "PartOf" is OK?
because that will not impact on start
systemd mention for partof:
Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units.

Should this issue be reopened?


Amend with some actions for Reports API

Basic Reports API actions, flat_file_open_listings_data request and get report action;
Unit tests;
Update Readme with examples

Any plans to accept this pull request?


"closing signal SIGTERM", seems like RAM OOM?

Hi, when i run the latest v1.3 code for fine-tuning, it fails the training every-time when the program tries to save the checkpoint, as shown below. I have never met this issue when running the previous version. Do you know why? Seems like the RAM is OOM after i search some related issues, do you know how to solve it?
[2024-10-28 06:14:36,059] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 598579 closing signal SIGTERM
[2024-10-28 06:14:36,060] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 598580 closing signal SIGTERM
[2024-10-28 06:14:36,060] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 598581 closing signal SIGTERM
[2024-10-28 06:14:36,061] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 598583 closing signal SIGTERM
[2024-10-28 06:14:36,061] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 598584 closing signal SIGTERM
[2024-10-28 06:14:36,062] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 598586 closing signal SIGTERM
[2024-10-28 06:14:36,062] torch.distributed.elastic.multiprocessing.api: [WARNING] Sending process 598587 closing signal SIGTERM
[2024-10-28 06:14:37,244] torch.distributed.elastic.multiprocessing.api: [ERROR] failed (exitcode: -9) local_rank: 0 (pid: 598577) of binary: /opt/conda/bin/python

Can you put up some info on monitoring memory? Do you have a lot of data? How long have you been training and are there any memory leaks?

@LinB203 Sry I did not see your fast reply!!, the monitoring memory seems normal, maybe the wandb has not capture the broken steps. I don't have much data (less than 1m). The training time is just few hours. So you never meet this kind of issue?


Half circle slider.

Is it possible to draw only a half circle slider?
@fatuhoku
@hodgesmr
@eliotfowler
@kenthumphries
@ciotto

I need too.

@RokasAug Please refrain from auto-tagging everyone that has been marked as a contributer. If they are still interested in helping, they will be "watching" the project and will be notified automatically. If not, they all just got an unnecessary notification.
This is possible, but not without customization of the library code. You will basically need to do 2 things:

Restrict the slidable area to 0° to 180°
Modify -(void) drawLine:(CGContextRef)ctx to draw an unfilled arc instead of an unfilled circle as the background.


HTTP code 409: "409 Conflict"

When filing an issue, please include the following information if possible as well as a description of the problem.  Make sure you test with the latest beta of rclone.
https://beta.rclone.org/
https://rclone.org/downloads/

Tried this with v1.36 from homebrew as well as rclone-beta-latest-osx-amd64.zip

If you've just got a question or aren't sure if you've found a bug then please use the rclone forum instead of filing an issue.

What is your rclone version (eg output from rclone -V)

rclone v1.36-54-g0c92a64β

Which OS you are using and how many bits (eg Windows 7, 64 bit)

Darwin home.yashi.org 15.3.0 Darwin Kernel Version 15.3.0: Thu Dec 10 18:40:58 PST 2015; root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
macOS System Version: OS X 10.11.3 (15D21)

Which cloud storage system are you using? (eg Google Drive)

ACD

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone -vvv mount Amazon:/ /Volumes/ACD
export BUP_DIR=/Volumes/ACD/.bup
bup init

A log from the command with the -vv flag (eg output from rclone -vv copy /tmp remote:tmp)

bup returns this:
jacob@home:/Volumes/ACD$ bup init                                                                                │··
fatal: bad config file line 4 in /Volumes/ACD/.bup/config                                                                                │··
bup: error: could not init repository: git init returned 128                                                                                │··
jacob@home:/Volumes/ACD$
and the log from rclone is attached
log.txt

This seems to be the problematic part of the log
@breunigs - you wrote this bit of code I believe - any ideas?
2017/05/15 10:21:58 DEBUG : .bup/config.lock: Dir.Rename to ".bup/config"
2017/05/15 10:21:59 DEBUG : .bup/config.lock: Move: quick path rename failed: HTTP code 409: "409 Conflict": response body: "{\"code\":\"NAME_ALREADY_EXISTS\",\"logref\":\"9095b131-3947-11e7-b266-fde87a655d7c\",\"message\":\"Node with the name config already exists under parentId UZpZ4f0QSkuO-ZjPaM4S-A conflicting NodeId: YBm7WlwAQ_iIr8oxnEX6Bw\",\"info\":{\"nodeId\":\"YBm7WlwAQ_iIr8oxnEX6Bw\"}}"
2017/05/15 10:21:59 DEBUG : .bup/config.lock: Could not directly rename file, presumably because there was a file with the same name already. Instead, the file will now be trashed where such operations do not cause errors. It will be restored to the correct parent after. If any of the subsequent calls fails, the rename/move will be in an invalid state.
2017/05/15 10:22:01 DEBUG : .bup/config.lock: Updating file with .bup/config 0xc420552540
2017/05/15 10:22:01 DEBUG : .bup/config: Dir.Rename renamed from ".bup/config.lock"

ACD is dead. Closing out.


Vertical swiping for vertical: true

It's nice that you can enable vertical mode for the carousel, however it requires you to swipe left/right to advance/rewind the carousel, which seems unnatural.
For vertical mode, it should require vertical swiping.

but why? :)


Dart 2.9.2 is incompatible with your dependencies' SDK constraints. Please run "pub get" again.

Steps to Reproduce

...
...
...

Logs

Logs

@ishaileshmishra
Going by the issue title, you may check out this issue and underlying comments to see if it works for you.

Without additional information, we are unfortunately not sure how to resolve this issue.
We are therefore reluctantly going to close this bug for now.
Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.
Could everyone who still has this problem please file a new issue with the exact description of what happens, logs, and the output of flutter doctor -v.
All system setups can be slightly different, so it's always better to open new issues and reference related issues.


Extensive Understanding of OS File Systems

Topic Suggestion
Extensive Understanding of OS File Systems
Proposal Submission
Proposed title of article
Extensive Understanding of OS File Systems
Use keyword research to improve your article's SEO.
Proposed article introduction
A file system, often known as file management or FS, is a method of controlling how and where data is stored on a storage drive. It is a logical disk component that compresses files that are divided into groups called directories. It is abstract to a human user and computer-related; as a result, it manages the internal activities of a disk. In this article, I will be discussing all the types of file systems including the yet available ones for end users.
For example, if the article is based on machine learning, use the following: [Machine learning] Introduction to Machine Learning.
If the article is based on developing an Android application, use the following: [Android] Developing Apps using Android.
Key takeaways
Broad understanding of NTFS, REFS, FAT32 and all others
Article quality
I will be covering an in-depth explanation of each file systems
References
Windows File System, Linux File System and Mac File System as published in the company's documentation
Conclusion
Finally, remove the Pre-Submission advice section and all our blockquoted notes as you fill in the form before you submit.
We look forwarding to reviewing your topic suggestion.
Templates to use as guides

How To Guide Template
Software Review Template
Tutorial Template

This topic appears to divert from program-centric areas. Feel free to suggest another topic. Thanks


reset auto ticket buyer wallet cofig if mixer is set

Fix #945
This PR allows selecting of only mixed accounts when mixer is set.
It also prevents using of already saved config as possible options when they are not mixed account both on the purchase modal and config modal.

When mixer isn't set, other wallets don't display an account

"mywallet" is missing an account

I am currently unable to reproduce this on my end and from the codes modified on this PR, i dont see where modification was made to the account validator section of the account selector.

I'd run another test to see if I can still reproduce


Repository fetch now goes through api instead of github directly

Added action to fetch github auth user information
In order to preserve api calls, a repo a user does not own, after selecting it, if the top 3 users does not include the auth user then it is removed, otherwise api calls would have to be done in advance.
Covers the last tasks described here:
https://github.com/OpenCollective/OpenCollective/issues/81#issuecomment-221390767
And this issue:
https://github.com/OpenCollective/OpenCollective/issues/117#event-683413872
This PR is related the branch with the same name fixes-for-github-flow in website repo, and should be merged first, as the other changes rely on this repo, and not vice versa.
This PR relies on changes found https://github.com/OpenCollective/opencollective-api/pull/416, in order to test it you'll have to use the fixes-for-github-flow branch on both the website and api repositories.

This looks good to be merged. Let's get the api PR merged before merging this one or we'll be blocked from pushing to production.
It would also be nice to have a e2e test for the github flow. Right now we only test logging into Github. Is there a way to set that up with our test account (which won't have any repos over 100 stars)?

@asood123 We could set the maximum stars and contributors to zero during testing with the NODE_ENV variable. All that is needed then is to use a github account with at least one repository. This is enough to go through the entire github flow during testing.

Good idea. Let's set stars to 0. We can add fake contributors to the test account to get it closer to the production environment.


How to prevent keyboard long pressed?

Is it possible to prevent that?

Could you explain your use case in more details?
Normally if you subscribe to key.pressed and key.released, you will receive only 1 event when the key is pressed and one once it's released, such that a "long" or "short" key press/release are handled the same way.

@tomzx I'm try to count keystroke. gkm work fine but when I try long keypressed the number of couter increment so fast.
let counter = 0 gkm.event.on('key.pressed',() => {   ++counter   console.log(counter) }) I suppose when I long keypressed the counter. It's should increment counter only 1 not continue increment.

You probably want to trigger the first time key.pressed is called, have a small object which contains which keys are currently pressed (something like {'a': true, 'c': true}, and on key.released remove the key from the list. This way, you check if the key is currently in this object, and if it is, then you ignore the key press.
This way you can trigger an event on the initial key.pressed, ignore subsequent events, then do something else on key.released (if necessary).


DocsArchive-<IP_ADDRESS>Auto archive content

Please don't merge this PR until target archive repo PR https://github.com/OPS-E2E-PPE/docs-archive-test-target/pull/244 is merged into live branch.
Auto archive content to https://github.com/OPS-E2E-PPE/docs-archive-test-target.git

Docs Build status updates of commit 7b2549a:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Archive_master_2019-11-21-02-57-35 has been deleted or has been force pushed: fatal: couldn't find remote ref refs/heads/Archive_master_2019-11-21-02-57-35

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[BUG][a11y] Secondary grey text colour is not accessible

This particular a11y issue is rather related to the designs.
As reported here: https://github.com/DivanteLtd/next/issues/389 the secondary colour is at too low contrast with white background and does not pass WCAG check.
@mbaran-dvnt would you kindly take a closer look?

Hi guys,
I've gone through all of the designs, fixed the grey colors in the style guide and I hope I've changed every state on the pages. I've also fixed some of the font size issues (text button). All should be now aligned with a11y :)

Fixed in #1121


[WIP] Add the try keyword

Closes https://github.com/roc-lang/roc/issues/7087
This PR adds the try keyword, which is a Zig-reminiscent version of the current ? operator. It basically desugars from try expr to:
when expr is
    Ok ok -> ok
    Err err -> return Err err

You can also use it in in pipelines:
decodedContents =
    try File.read! "myFile.json"
    |> try Json.decode

# this also works
decodedContents =
    try File.read! "myFile.json"
    |> Json.decode
    |> try

I initially implemented this as a plain desugar to the above when expression, which worked, but wouldn't give very useful type errors. Instead, I'm implementing it as a new can::Expr, but I'm having alias analysis
Currently, typechecking is working properly (though there's some work to do there with respect to [Ok ok, Err err] vs. Result ok err), but codegen is failing at the alias analysis level. I think it has to do with my approach to compiling, which is the following:

After typechecking and during monomorphization, convert the try expression to a when expression in roc_mono::ir::with_hole.
For the missing type variables in the when expression (e.g. the type of the Ok ok ->), either:
a. type constrain variables during typechecking and use those
b. only constrain the required variables and synthesize the others using roc_derive::synth_var

I presume the alias analysis issue is with this approach. I'll keep trying to see if I can find the issue myself, but if anyone has any suggestions to fix, I'm all ears.

This is too fragile for now, closing in favor of a simple desugaring version in https://github.com/roc-lang/roc/pull/7193


[Bug]: Recurrent error "git obsidian error: Not all of the required configs are set. See README"

Describe the bug
I'm on v1.10.0.
I am repeatedly getting an error "git obsidian error: Not all of the required configs are set. See README"

The plugin though seems to be working fine (see screenshot) and my configuration hasn't changed.

Relevant errors (if available)
No response
Steps to reproduce
Updated to v1.10.0 and started seeing this issue.
Expected Behavior
No response
Addition context
More worryingly, I noticed that after this error began to show, performance in Obsidian slows when the plugin is activated, with the settings page taking a few seconds to appear and scroll on setting pages lagging. If I disable the plugin and reload Obsidian, things go back to normal.

I am sorry to hear that. Can you confirm that in git/config user.name user.email and remote.origin.url are set. This requires the remote to be named origin. If it is not called like that, please try to rename it.
Regarding your performance, I don't really know what is causing the issue.

Thanks for the fast reply. Indeed setting user.name and user.email` made the error go away. Performance, however, is still affected. Any local test I can run to verify the source of this?

It's strange that the user properties are missing.
Can you downgrade to 1.9.3 and confirm that the performance is better?

Email was missing after I changed authentication to token, but I supposed pwd properties were still there?
I installed 1.9.3, restarted and performance is back to normal. Tomorrow when I am back at my computer I can upgrade again and see how that works. Let me know if you need me to do anything before I switch back to 1.10.0

I am sorry to hear that. Can you confirm that in .git/config user.name user.email and remote.origin.url are set. This requires the remote to be named origin. If it is not called like that, please try to rename it.
Regarding your performance, I don't really know what is causing the issue.

Just added the user.name and user.email lines and values and now the notification doesn't show up anymore, but these weren't even there before, not even empty.
Perhaps something to do with updating the plugin, as I had it working perfectly before, too, without setting any of that. Also, the README (here in GitHub) does not say what you're supposed to do so that error message should either be changed or the README should be updated.

@firinael Oh you are right. The README has changed, so it is not there anymore. Will remove the check, because it causes just problems. The source of the check is the mobile pr. A check was needed there.

Fixed in new release


Candle can not be placed on the ground.

Candles can now be put down. See branch HF/PlacingCandle

fixed in #389


New package: BLPData v0.0.1

Registering package: BLPData
Repository: https://github.com/felipenoris/BLPData.jl
Created by: @felipenoris
Version: v0.0.1
Commit: 4dc57379129f2df2f916a147b70b4650e5d11086
Reviewed by: @felipenoris
Reference: https://github.com/felipenoris/BLPData.jl/commit/4dc57379129f2df2f916a147b70b4650e5d11086#commitcomment-38605801

This package already underwent a three day waiting period.

Awesome, thanks @DilumAluthge !


TTTDataTransformer -> TTTDataTransformers

TransformerKit/Data submodule isn't installing with cocoapods because there is TTTDataTransformers in podspec and TTTDataTransformer in code.
Changed to TTTDataTransformers everything (I hope). We can change podspec, but there are multiple transformers for NSData, so plural form more suitable.

no merge yet:(

Please merge this PR

@pilot34 My sincere apologies for not merging this in sooner, and for the inconvenience this caused you and others.Thanks for reporting and submitting this fix. I'll cut a new release later tonight with this change.


Allow FDio/ci-management to use newer JJB_VERSION

So far only in Gerrit ci-management Verify.

Not enough appreciation and I should not be using main branch for edits anyway.
Abandoning.


ci: remove unused job in github workflow

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

1.0.0
GitHub release

Your semantic-release bot :package::rocket:


apollo-client crashes in brand new create-react-app project

Failed to compile.

Error in ./src/~/lodash/_baseClone.js

  110:22  warning  Expected '===' and instead saw '=='  eqeqeq
  110:40  warning  Expected '===' and instead saw '=='  eqeqeq
  115:13  warning  Expected '===' and instead saw '=='  eqeqeq
  115:33  warning  Expected '===' and instead saw '=='  eqeqeq
  130:21  warning  Missing '()' invoking a constructor  new-parens
  139:17  error    'keysIn' is not defined              no-undef

✖ 6 problems (1 error, 5 warnings)

I'm confused - this looks like a lint error inside lodash, and doesn't have anything to do with Apollo Client. Can you use lodash inside CRA? Also, shouldn't there be a node_modules in the path somewhere? Why did this stuff end up in ./src?

It's in ./src/node_modules/lodash.... Seems I ran yarn in the src dir instead.
The error only appeared when including Apollo. My bad!


Japanese Localization file.

Create Japanese Localization.
Please Merge.
best regards

@dscho added a feature and a line to the file - would you please check the translation?


How to use test.py to evaluate the accuracy of existing models and display them in the terminal (pytorch1.1.0)

I am using a single gpu, voc format, the command is as follows
Python ./tools/test.py configs/dcn/cascade_rcnn_dconv_c3-c5_r50_fpn_1x.py work_dirs/cascade_rcnn_dconv_c3-c5_r50_fpn_1x/epoch_12.pth --eval bbox --show
In the displayed picture, there is no detected box, and finally the result of the accuracy evaluation is not displayed in the terminal.

I have the same problem. Have you solved it now? Could you tell me how to do

SOS, have you solved it?


Use luac.cross directly and check size

Previously we were using the docker builder lfs script to create the LFS.  This worked fine but did not include a check to ensure the built lfs does not exceed to lfs partition size.
This PR now uses the docker builder to call the luac.cross.int directly (similar to the PRO project).  This let's us pass the -m 10000 arg which will cause the build to fail if the compiled lfs image it too large.
I also included a comment in the user_config.h file reflecting the max lfs partition size - this can be enabled next time we do a firmware release.

Closing this as it is included in #140


Windows client is supported?

Whether the Windows client is supported. ?

build by urself

No, there is no Windows support at the moment because tokio-tun does not have such support.


Improve JS bindings

Fix a few things related to how npm should publish the package (sources were in the gitignore file, so I think it would have break the build during install - I fixed this by adding a npmignore that should override the gitignore rules)

The enumerations values are now generated directly from enums.py

I added percent unit support (#258) to the bindings (.setWidthPercent is currently exposed, but I've also added a very very little parsing to also support .setWidth("100%") and .setWidth(.getWidth())), added the missing tests, and fixed Travis.

Awesome! thanks


OS Development

BIOS/VGA Mode
Novusk x86/x86_64 should use the BIOS before going into text mode (VGA) because that is something that happens before the OS starts.
OS Development
There needs to be an easier way if setting configurations for the OS. If someone is making kernel configurations for their OS, they can't make them from installing the kernel from the compiled branch.

If you want to make an operating system using Novusk, comment everything in kernel/src/userspace/main.rs, then make an statically linked library with a function named kernel_main. There will be a better way of doing this someday.

Novusk as of 2882f50 is pretty much a library that you can add to a Rust Cargo project. There needs to be documentation for using Novusk for OS development and then this issue can be closed.

Closing this because of v1.2 release 5ec6de3.


Enable "semi-SPV" mode

Because syncing pktd takes a long time, we can enable SPV on pktwallet instead and only connect to a couple of "trusted nodes".
The threat model currently is that if you're not verifying PacketCrypt proofs then someone can easily pass you fake blocks, but this attack really only allows someone to trick you into thinking you've been paid when you haven't --- or to trick you into thinking you haven't when in fact you have. Using -connect with some "well known nodes" should be a reasonable way to make this work in the interim until validation of PacketCrypt proofs is rolled out.

If the user happens to have pktd running on their local machine, it would be good to default to connecting to that, otherwise to use the trusted nodes.

this one is done


Use shared libraries

Using shared libraries causes in an error:
"cannot open shared object file"
There must be a workaround to fix this

https://itsfoss.com/solve-open-shared-object-file-quick-tip/

https://itsfoss.com/solve-open-shared-object-file-quick-tip/

This does not fix the problem for local shared libraries. Maybe the library must be copied to/usr/lib/

https://itsfoss.com/solve-open-shared-object-file-quick-tip/

This does not fix the problem for local shared libraries. Maybe the library must be copied to/usr/lib/

Yes, the shared library for must be copied to standard library path (make install)
https://stackoverflow.com/questions/11111293/why-is-my-shared-library-not-found


App crashes when navigating in nativescript RadSideDrawer template

When I go to another menu in nativescript RadSideDrawer template (not sure if this happens in other templates) it crashes. For the demonstration, please create a new angular RadSideDrawer template and add the mapbox plugin. Also, I made a video for  the demonstration:
crash-mapbox.zip

This is a known issue and not a bug in the mapbox plugin but a problem in Nativescript tns-core-modules having to do with setting a background in the RadSideDrawer when markingMode "none" is used.
https://github.com/NativeScript/NativeScript/issues/7867
You can also check out my fork of the plugin which is being reviewed for merging into this repositiory:
https://github.com/Yermo/nativescript-mapbox
For a workaround see this file:
https://github.com/Yermo/nativescript-mapbox/blob/master/demo-angular/README.md#the-long-standing-android-navigation-crash--temporary-workaround-for-tns-core-modules-6112

Hi @Yermo . Thanks for quick reply. Also this happens in nativescript tabview template. How can I install your fork? It seems it's not published in npm.

@vahidvdn It's not published to npm yet. I've sent a pull request to @EddyVerbruggen but it's a big change with some breaking API changes and a few problems yet to be sorted out.
There are instructions on how to build my fork. You'll need to clone the repository using git and build the plugin. See the README.

@Yermo Thanks. And did you changed tns-core-modules codes? It so, then if I update nativescript the crash will occur again. Am I right?

Yes. If you apply the patch I describe then you will have to apply it again every time you upgrade tns-core-modules. Hopefully, the Nativescript folks will fix that bug soon so that we don't have to do this.

@Yermo Yes. But that bug differs from the plugin bug. The plugin bug happens even in the tab template. Unfortunately, I couldn't be able to run your fork. I get some weird errors. For now, I just handle it in my side, by hiding the map view before navigating away. Hopefully, waiting for your pull request to get merged. (otherwise, it would be really helpful to publish it in npm by you)
Btw, thanks for your efforts.

Hi @vahidvdn , could you share the code to hide mapview before navigating away? I'm experiencing the same issue.

@noctain Here you are:
app.component.ts
onNavItemTap(navItemRoute: string): void {
    this.appService.setMapVisiblity(false);

    if (this._activatedUrl == "/home") {
        setTimeout(()=>{
            this.routerExtensions.navigate([navItemRoute], {
                transition: {
                    name: "fade"
                }
            });
        }, 500);
    }

    else {
        this.routerExtensions.navigate([navItemRoute], {
            transition: {
                name: "fade"
            }
        });
    }

    const sideDrawer = <RadSideDrawer>app.getRootView();
    sideDrawer.closeDrawer();
}

app.service.ts
import { Injectable, Inject } from '@angular/core';
import { BehaviorSubject } from 'rxjs';

@Injectable({
  providedIn: 'root'
})

export class AppService {

	private dataSource = new BehaviorSubject(true);
  	data = this.dataSource.asObservable();

	constructor() {}

	setMapVisiblity( flag ) {
		this.dataSource.next(flag);
	}

}

home.component.ts
ngOnInit(): void {
    this.appService.data.subscribe(data => {
        if ( data == false) {
            this.showMap = false;
        }
    })
}

home.component.html
<ContentView *ngIf="showMap" height="100%" width="100%">
    <Mapbox
    ...


Need mechanism for determining current build target

Is there an existing issue for this?

[X] I have searched the existing issues
[X] I have read the guide to filing a bug

Use case
(Moved over from #128384 -- cc @Hixie)
I need a way to determine which widget is currently being built. WidgetsBinding.instance.buildOwner._debugCurrentBuildTarget is not exposed (and is not even available in release builds). (@Hixie noted that it would be expensive to track this in release builds, although the current code that tracks this is just one assignment on the way into a build method, and one assignment on the way back out, so I don't see how that would be expensive...)
The reason I need this information is because I created this library, in which a user subclasses ReactiveWidget (which subclasses StatefulWidget), and then whenever their widget is getting built, any read of the value of a ReactiveValue (which subclasses ValueNotifier) causes a listener to be added to the ReactiveValue that causes setState to be called on the ReactiveWidget whenever the value changes.
I know that build methods should not mutate state -- more strictly, that they should not have side effects. This does not mutate state (at least per se), it just adds a listener. Yes, I know some people will hate this approach for this reason alone. However this is by far the simplest reactive UI update mechanism available so far for flutter.
The big problem I have is that in order to figure out which ReactiveWidget to call from the ReactiveValue listener, I need to know which widget is being built when the ReactiveValue's value field is read while the widget's build method is being run.
The solution that I have, which is horrible, but works (currently, at least!), is to record the current ReactiveWidget in a global variable when entering the build method, then unrecord it on exit from build. (I put these into a stack, although I think there can only ever be zero or one build method(s) running.)
https://github.com/lukehutch/flutter_reactive_widget/blob/main/lib/src/reactive_widget.dart#L43
Proposal
It would be much better if I could just read from WidgetsBinding.instance.buildOwner.currentBuildTarget.
I would like to see some benchmarks to see if always tracking the build target really does impact performance. I highly doubt the impact of setting this field on entry to build and unsetting it on exit would even be measurable.

It affects performance because it's an assignment before every build and an assignment after every build. That's thousands of assignments per frame, to a memory location that is using up cache lines, in a way that might prevent inlining, etc. These code paths are super hot and we really want to do as little work as possible.
Your use case is interesting. Generally I would recommend passing the context any time you read a value. The context is an Element which is basically the object backing a widget, and you can call markNeedsBuild on that object to trigger a rebuild. That is the purpose of having the context everywhere.

That's a fair suggestion; however, I really want to avoid having to change
ReactiveWidget(() => Text('${counter.value}'))

into
ReactiveWidget((context) => Text('${counter.getValue(context)}'))

because I'm trying to avoid as much boilerplate syntax as possible.
I guess the current solution I have, of recording the current build widget in a global variable on entry to ReactiveWidget.build, is not much different than getting access to it in WidgetsBinding.instance.buildOwner._debugCurrentBuildTarget, since that's also basically a global.
I have been told that build never operates recursively. I assume that means that the recursion through the widget tree happens outside of build itself. Will that always be the case, i.e. will there never be more than one build call on the stack? The reason I'm asking is I'm wondering if I should change the stack I am using (referred to in the previous comment) into a single variable assignment.

I understand where you're coming from, but the problem is that you're experiencing the tension between making an API look clean and easy to write, and making an API easy to understand. Global variables, getters with side-effects, and the combination of those, code that operates on data it doesn't seem to have (in your case, the caller's identity) are all forms of "magic" that make for very nice-looking code that is hard to understand.
When you see Text('${counter.value}')) it looks like a cheap call. It looks like something that has no side-effects, something that you could easily refactor so that counter.value is read in some different function and then assigned to a variable that's used in the build method instead. It looks like code you could refactor to use TextSpans instead of widgets, with no difference in behavior. It looks like you could substitute a different object for counter and have the same result. It looks like code that O(1). But the reality is quite different.
On the other hand, when you see Text('${counter.subscribe(context)}') or the equivalent, you immediately know something more is happening. You know that you can't use this code without a context. You know that something is being subscribed, which will have huge performance implications. You know that you can't just replace it with a cached value because that would change the semantics. You know that calling this function a hundred times will likely cost a lot more than calling a simple getter a hundred times. You can reason about what exactly will happen in weird situations like complicated build methods with nested Builder widgets and so on, since you know which context you're passing in.
Flutter leans strongly into this second paradigm (the code should look like what it does).

will there never be more than one build call on the stack?

In normal use, that is correct. The build method is called from Element.performRebuild; the recursion is done by the Element logic in widgets/framework.dart.

@Hixie OK, I started to make the changes, but I don't understand how to find the nearest ancestor ReactiveWidget in the widget hierarchy.
context.findAncestorStateOfType<_ReactiveWidgetState>() has this documentation:

This should not be used from build methods, because the build context will not be rebuilt if the value that would be returned by this method changes. In general, dependOnInheritedWidgetOfExactType is more appropriate for such cases. This method is useful for changing the state of an ancestor widget in a one-off manner, for example, to cause an ancestor scrolling list to scroll this build context's widget into view, or to move the focus in response to user interaction.

and

This method should not be called from [State.deactivate] or [State.dispose] because the widget tree is no longer stable at that time. To refer to an ancestor from one of those methods, save a reference to the ancestor by calling findAncestorStateOfType in State.didChangeDependencies.

I'm lost here...
(1) How are you supposed to find ancestor widgets from a BuildContext if you can't determine the ancestor when build is running?
(2) I'm not trying to find the ancestor from a StatefulWidget, so the didChangeDependencies advice doesn't apply...
What I have is this -- but based on the above, I don't know that it's correct:
class ReactiveValue<T> extends ChangeNotifier {
  ReactiveValue(this._value);

  T _value;

  T getAndSubscribe(BuildContext context) {
    final parentReactiveWidget =
        context.findAncestorStateOfType<_ReactiveWidgetState>();
    assert(
        parentReactiveWidget != null, 'Could not find parent ReactiveWidget');
    parentReactiveWidget?._listenTo(this);
    return _value;
  }

  void set(T newValue) {
    if (_value != newValue) {
      _value = newValue;
      notifyListeners();
    }
  }

  @override
  String toString() => '${describeIdentity(this)}($_value)';
}

@Hixie Oh, I didn't even know .markNeedsBuild existed! I asked about that once before, #120545. I went looking for exactly this method, and I couldn't find it, presumably because BuildContext doesnt expose that Element` method...
(So to answer your question, the reason for ReactiveWidget was originally to allow the current build target to be tracked, so that listeners could be added if the value changed.)
I'll try out the solution you suggested, that's awesome. Thanks.

@Hixie This is what I have, but there are some issues...
class NewReactiveValue<T> {
  NewReactiveValue(this._value);

  T _value;
  final _subscribedElements = <Element>{};

  T getAndSubscribe(BuildContext context) {
    _subscribedElements.add(context as Element);
    return _value;
  }

  void set(T newValue) {
    if (_value != newValue) {
      _value = newValue;
      notifyListeners();
    }
  }

  void notifyListeners() {
    for (final element in _subscribedElements) {
      if (element.mounted) {
        element.markNeedsBuild();
      }
    }
  }
}

How do I track the lifecycle of the element, so that I can remove the listener when it's no longer needed? Is there a way to subscribe to the dispose method of a StatefulWidget's state, at least, or the equivalent for StatelessWidget? Or should I just remove the listener when !element.mounted? Can an element be re-mounted after it is unmounted?
Sorry for all the basic questions, I find it very hard to figure this stuff out from the documentation...

There's no way to be notified when an element goes away.
This would be a good use case for WeakReference, actually. I've never used it myself but I think it would work here. Instead of storing the elements directly, store weak references to the elements. When notifyListeners is called, you can remove all the weak references that are now null, as well as any widgets that aren't mounted.
An element is guaranteed to rebuild if it is ever mounted after being unmounted. (In practice you won't observe an element in its unmounted state because if it's not immediately remounted it'll be disposed. Elements don't survive past the end of the frame if they're not mounted.)

Sorry for all the basic questions, I find it very hard to figure this stuff out from the documentation...

No worries! If you could enumerate all the questions you've asked and where you looked for answers for each one, I can make sure to go and add answers to those places.

@Hixie Sorry, but honestly I have read so much documentation both on the Flutter site and on other sites that I don't even know what to suggest improving. The UI system is very complex in Flutter, and it's hard to get one's mind around all of it. Not many Flutter developers will try to do anything as low-level or out-of-the-ordinary as what I took on for this project, so I don't think my learning curve issues will be representative of what others need anyway.
Thanks for all the pointers. Now what I have is the following:
class ReactiveValue<T> {
  ReactiveValue(this._value);

  T _value;
  final _subscribedElements = <WeakReference<Element>>[];

  /// Get the current value, and cause the [Element] passed as this
  /// [BuildContext] to subscribe to future changes in the value.
  T getAndSubscribe(BuildContext context) {
    _subscribedElements.add(WeakReference(context as Element));
    return _value;
  }

  /// Set the value, and notify subscribers if value changed.
  void set(T newValue) {
    // Don't allow mutating state during `build`
    // https://github.com/flutter/flutter/issues/128384#issuecomment-1580110349
    assert(
        SchedulerBinding.instance.schedulerPhase != SchedulerPhase.persistentCallbacks,
        'Do not mutate state (by setting a ReactiveValue\'s value) '
        'during a `build` method. If you need to schedule an update, '
        'use `SchedulerBinding.instance.scheduleTask` or similar.');
    if (_value != newValue) {
      _value = newValue;
      notifyListeners();
    }
  }

  /// Update the value based on current value, and notify subscribers
  /// if value changed.
  /// e.g. to increment: reactiveVal.update((v) => v + 1)
  void update(T Function(T) currValueToNextValue) {
    set(currValueToNextValue(_value));
  }

  /// You should manually invoke this method for deeper changes,
  /// e.g. when items are added to or removed from a set, as in
  /// ReactiveValue<Set<T>>
  void notifyListeners() {
    final liveSubscribedElements = <WeakReference<Element>>[];
    _subscribedElements.forEach((elementWeakRef) {
      // Skip elements that have already been garbage collected
      final element = elementWeakRef.target;
      if (element != null) {
        // For any subscribing elements that are still live, mark element
        // as needing to be rebuilt
        element.markNeedsBuild();
        // Remember elements that are still live
        liveSubscribedElements.add(elementWeakRef);
      }
    });
    // Remove any elements that have been garbage collected
    _subscribedElements.clear();
    _subscribedElements.addAll(liveSubscribedElements);
  }

  @override
  String toString() => '${describeIdentity(this)}($_value)';
}

This finally seems to fully work as expected, and it's a much better solution than what I had before.
Can you please check over the code and let me know if there are any outstanding issues?
Dart needs a single ultra-simple reactive state management solution as a default, to lower the barrier of entry to newcomers (since state management seems to be the hardest part to learn when learning Flutter). What is the likelihood that the above class, or something like it, could be incorporated into the Flutter core libraries?

@Hixie Sorry, but honestly I have read so much documentation both on the Flutter site and on other sites that I don't even know what to suggest improving.

Fair enough. In the future please, any time something is unclear and you don't find the answer right away in our docs, file a bug saying what your question was and where you looked.

Not many Flutter developers will try to do anything as low-level or out-of-the-ordinary as what I took on for this project, so I don't think my learning curve issues will be representative of what others need anyway.

That doesn't matter, we want to make it easy for everyone, not just people doing the basic stuff.

Can you please check over the code and let me know if there are any outstanding issues?

Seems reasonable to me, modulo the issue you pointed out (that I would not have noticed, to be honest).
Your solution to the WeakReference stuff seems reasonable.

Dart needs a single ultra-simple reactive state management solution as a default, to lower the barrier of entry to newcomers (since state management seems to be the hardest part to learn when learning Flutter). What is the likelihood that the above class, or something like it, could be incorporated into the Flutter core libraries?

I think it would make a lot of sense for such a package, once suitably proven, to be listed on https://docs.flutter.dev/data-and-backend/state-mgmt/options. (Currently our recommended solution is package:provider.)
Personally I see state management as the core of writing an application. I don't think it makes that much sense to create packages for it, I just build a bespoke solution for each application based on the shape of its data model, the access patterns, etc. I wouldn't recommend using ReactiveValue for a system where the application is presenting a whole database or spreadsheet of information, for instance. And I wouldn't recommend it for something as simple as the counter app. It probably wouldn't be my first choice for an app where undo/redo is going to be a key mechanic, either. I could see something like it being useful for an application that has a small number of scalar values that it's trying to present, maybe, like an air quality sensor dashboard. Even there, though, I'm likely to just rebuild the whole dashboard when anything changes rather than try to optimize how much gets built; it's simpler. Anyway long story short, I'm the wrong person to try to convince for us to make a particular state management solution be a canonical solution.

Fair enough. In the future please, any time something is unclear and you don't find the answer right away in our docs, file a bug saying what your question was and where you looked.

Thanks, I really appreciate the commitment to producing good documentation.
I filed the first documentation improvement request: https://github.com/flutter/flutter/issues/128648

Seems reasonable to me, modulo the issue you pointed out (that I would not have noticed, to be honest).
Your solution to the WeakReference stuff seems reasonable.

Thanks for taking a look.
It occurred to me I could make this even simpler:
class _LateValueWrapper<T> {
  _LateValueWrapper({this.value});
  T? value;
}

T getValueAndSubscribe<T>(
    BuildContext context, ValueNotifier<T> valueNotifier) {
  final elementRef = WeakReference(context as Element);
  final listenerWrapper = _LateValueWrapper();
  final listener = () {
    assert(
        SchedulerBinding.instance.schedulerPhase !=
            SchedulerPhase.persistentCallbacks,
        'Do not mutate state (by setting a ReactiveValue\'s value) '
        'during a `build` method. If you need to schedule an update, '
        'use `SchedulerBinding.instance.scheduleTask(task, Priority.idle)` '
        'or similar.');
    final element = elementRef.target;
    if (element != null) {
      // Mark the element that this value changed in as needing to be rebuilt
      element.markNeedsBuild();
      // Remove the listener -- only listen to one change per `build`
      // (can't refer to listener while it is being declared, so need to add a
      // layer of indirection)
      valueNotifier.removeListener(listenerWrapper.value);
    }
  };
  listenerWrapper.value = listener;
  valueNotifier.addListener(listener);
  return valueNotifier.value;
}

Personally I see state management as the core of writing an application. I don't think it makes that much sense to create packages for it

You are right, it's not a be-all and end-all for state management. It's intended for getting users onboarded to Flutter quickly and easily, for apps with minimal reactivity requirements. I do think there's a solid need for that in the Flutter core libraries.

@Hixie I released this library as:
https://github.com/lukehutch/flutter_reactive_value/blob/main/lib/src/reactive_value_notifier.dart
Thanks for all the significant feedback you provided to make this happen. I am very happy with the final result, and I couldn't have done it without your guidance!

Congratulations!

@Hixie I ran into a problem -- this assertion fails in some circumstances:
  void markNeedsBuild() {
    assert(_lifecycleState != _ElementLifecycle.defunct);   // *** FAILS
    if (_lifecycleState != _ElementLifecycle.active) {
      return;
    }
    //...
  }

This is my code:
https://github.com/lukehutch/flutter_reactive_value/blob/main/lib/src/reactive_value_notifier.dart#L30
So apparently just checking if the Element has been garbage collected is insufficient -- the Element also has to be in ElementLifecycle.active state.
How do I check for that?
This code shows that the _lifecycleState is not even tracked in production:
bool get debugIsActive {
    bool isActive = false;
    assert(() {
      isActive = _lifecycleState == _ElementLifecycle.active;
      return true;
    }());
    return isActive;
  }


[docs] Get started - overview: design tweaks

[ ] Fix the white corners in the image when tile is hovered over. Do we want to use tile here?

[ ] Fix 404s to Designer and Developer pages
[ ] Should have 80px between tiles and Release notes/Feedback row. Spacing is too small right now:

Good eye on those white corners!
I'll open a PR.
@marionnegp Those images are pngs.  Do we have access to SVG for those?  Prefer SVG's for as many of these style files as possible.

Do we want to use tile here?

I used tile as it seemed more appropriate as far as a pattern then cards used in a nav.
If we had more overview content on this page I would say these pages could become a subnav instead.


Fix outstanding compiler and linter warnings

I think explicitly returning Unit to avoid compiler warnings is a code smell. The only real use case should be to explicitly swallow cases where we're not interested in the return type.

@pbugnion: This is ready for another look. I've refactored away explicitly returning Unit anywhere.


Add initial support for Discord Gateway Intents

Getting ahead of the changes on Oct 7th - updating us to d.py 1.5 and specifying some intents.

Closing in favor of #101.


mixer_codegen.sh was not including the generated gRPC service

@geeknoid @douglas-reid super quick PR