Add support for TexturePacker class (Texture atlas)

The TexturePacker is a tool used to merge textures into a bigger texture atlas.
The idea is to be able to use one big textures when two (or more) where required before.
The tool has to be able to create the next texture, copy the older ones inside and update uvs of all meshes which were relying on the old textures

Question here about updating the meshes.  (Thumbs up or correction will be fine.)
Pre-merge:  A given mesh points at a "merged-in" texture and has certain UV coordinates.
After-merge:  The same mesh should receive pointers to the "merged-out" texture with new UV coordinates.  But we DON'T wanna replace the mesh; just modify all those things.
What I am getting at is that we don't need to get into any internals of the Mesh (code or structure).  We can update all those things by using the same methods that put them there in the first place.
Yeah?

Aye, something fun ^_^.  Ok, so battle planning.
So I assume we will end up using the Dynamic Texture.  Gonna need to have some parameters like:  cellSize? (size of the packed texture on the Atlas if they are scaled-down),  paddingSize (amount of pixel units the texture is repeated at UV edges),  Layout modes: Strip, PowerTwo, RowCellCount, and target file type (jpg, png etc...)
Now I am thinking it might need a support JSON file (for the UV scalings and frame id).  Unless I am tricky tricky and hide it in a strip of pixel data at the bottom of the image but that might not be the best solution for edibility later.
so like BABYLON.TexturePacker.CreateFromArray(mesh[], options, download)
and
BABYLON.TexturePacker.UpdateMeshes(mesh[] | mesh, json, options)

BABYLON.TexturePacker.CreateFromArray(mesh[], options, download)

Like this onebetter (not a big fan of additional files)

So it's not going to be saved out and used later?
Just kinda created at runtime and then the other assets are dumped?
I kinda figured it was something someone would run it, serialize their data then load it back in later as a single texture.
We would then need a secondary function to update the meshes UV's accordingly.

Maybe I'm not completely getting the reason..I trust you to do the right choice


Addon attribute "block advanced edit tools" should be on by default.

by default, advanced edit should be off. (go through install and turn them all off except... ?) IMPORTANT for admin site tools like those on the desktop.  some portal features dont display.

already done.


Cannot figure out backing up of replicaSet, used to work fine on standalone

We used mongo-oplog-backup for quite some time now and it used to work perfectly well on a single-server setup. Since we added a couple of servers and converted to replicaSet - it doesn't seem to be able to work with incremental backups. Is it something that we're not doing right, or is it just not supposed to work with replicaSets, i wasn't able to find any reference to replicasets in the project itself
Here's the message that we get:
/usr/bin/mongo-oplog-backup backup --dir /data_slow/backups/mongodb --full
I, [2016-09-23T20:09:24.331181 #6993]  INFO -- : Performing full backup
D, [2016-09-23T20:09:24.331299 #6993] DEBUG -- : >>> mongo --host localhost --port 27017 --quiet --norc /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/oplog-last-timestamp.js
D, [2016-09-23T20:09:24.396316 #6993] DEBUG -- : {"position":{"$timestamp":{"t":1474661364,"i":4}}}
D, [2016-09-23T20:09:24.401215 #6993] DEBUG -- : >>> mongodump --host localhost --port 27017 --out /data_slow/backups/mongodb/backup-:/dump
E, [2016-09-23T20:09:24.491961 #6993] ERROR -- : 2016-09-23T20:09:24.490+0000	writing admin.system.users to
E, [2016-09-23T20:09:24.493193 #6993] ERROR -- : 2016-09-23T20:09:24.492+0000	done dumping admin.system.users (1 document)
E, [2016-09-23T20:09:24.493260 #6993] ERROR -- : 2016-09-23T20:09:24.492+0000	writing admin.system.version to
E, [2016-09-23T20:09:24.494443 #6993] ERROR -- : 2016-09-23T20:09:24.493+0000	done dumping admin.system.version (1 document)
.....
.....
.....  some output truncated
.....
.....
I, [2016-09-23T20:11:18.433723 #6993]  INFO -- : Performed full backup
I, [2016-09-23T20:11:18.433940 #6993]  INFO -- : Performing incremental oplog backup
D, [2016-09-23T20:11:18.434287 #6993] DEBUG -- : >>> mongodump --host localhost --port 27017 --out /data_slow/backups/mongodb/tmp-dump --db local --collection oplog.rs --query \{ts\ :\ \{\ \$gte\ :\ \{\ \$timestamp\ :\ \{\ t\ :\ ,\ i\ :\ \ \}\ \}\ \}\}
E, [2016-09-23T20:11:18.455923 #6993] ERROR -- : 2016-09-23T20:11:18.455+0000	Failed: error parsing query as json: invalid character ',' looking for beginning of value
/usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/command.rb:105:in `raise!': Command failed with exit code 1 (RuntimeError)
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/command.rb:99:in `run'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/command.rb:21:in `execute'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/config.rb:64:in `exec'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/config.rb:68:in `mongodump'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/backup.rb:56:in `backup_oplog'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/backup.rb:165:in `block in perform'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/backup.rb:43:in `block in lock'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/backup.rb:37:in `open'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/backup.rb:37:in `lock'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/backup.rb:164:in `perform'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/lib/mongo_oplog_backup/backup.rb:182:in `perform'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/bin/mongo-oplog-backup:47:in `block (3 levels) in <top (required)>'
	from /usr/lib/ruby/gems/2.2.0/gems/slop-3.6.0/lib/slop.rb:260:in `call'
	from /usr/lib/ruby/gems/2.2.0/gems/slop-3.6.0/lib/slop.rb:260:in `parse!'
	from /usr/lib/ruby/gems/2.2.0/gems/slop-3.6.0/lib/slop.rb:235:in `parse!'
	from /usr/lib/ruby/gems/2.2.0/gems/slop-3.6.0/lib/slop.rb:65:in `parse!'
	from /usr/lib/ruby/gems/2.2.0/gems/slop-3.6.0/lib/slop.rb:54:in `parse'
	from /usr/lib/ruby/gems/2.2.0/gems/mongo-oplog-backup-0.0.9/bin/mongo-oplog-backup:6:in `<top (required)>'
	from /usr/bin/mongo-oplog-backup:23:in `load'
	from /usr/bin/mongo-oplog-backup:23:in `<main>'

Will look into this.

receiving similar error +1

Currently oplog-last-timestamp.js returns output as

{"position":{"$timestamp":{"t":1502115172,"i":1}}}

We write this output in state.json file which will then used for incremental backup. BSON::Timestamp.from_json($result['position']) function is used to parse the timestamp value stored in this file which is expecting input in the form of this

{"t":1502115172,"i":1}

But getting this

{"$timestamp":{"t":1502115172,"i":1}}

@see backup.rb file. So needs to update output generated by oplog-last-timestamp.js file.
Add below changes in  oplog-last-timestamp.js file to get output as

{"position":{"t":1502115972,"i":1}}

@@ -5,7 +5,8 @@
 var last = local['oplog.rs'].find().sort({'$natural': -1}).limit(1)[0];
 var result = {};
 if(last != null) {
-    result = {position: last['ts']};
+    var parsed = JSON.parse(JSON.stringify(last));
+    result = {position: (parsed['ts']['$timestamp'] ? parsed['ts']['$timestamp'] : parsed['ts'])};
 }

 print(JSON.stringify(result));

Note : I am using mongodb 3.4 .

Thanks for the detailed debugging @amardeokar23. I believe v0.0.12 should fix this issue.


Incompatible with 1.0.1c?

Getting crashes when trying to load a save from TTweaks 1.0.3 with the current Wrath release 1.0.1c.
Is there a fix for this with regards to the TTweaks?
TT1.0.6 doesn't seem to fix the issue.

I need more details than this to know if this mod is causing the problem. When are these crashes happening?
Additionally can you send me you Player.log after a crash? It should be at the following path
%userprofile%\AppData\LocalLow\Owlcat Games\Pathfinder Wrath Of The Righteous

This is happening when attempting to load a save made with TT1.0.3 in WoR 1.0.1c.
Player.log
The game happily loads saves made before the install of TT1.0.3.

You currently have the mod disabled and your save relies on the mod being enabled. Enable the mod and then load.
[Manager] Parsing mods.
[Manager] Reading file 'C:\Program Files (x86)\Steam\steamapps\common\Pathfinder Second Adventure\Mods\TabletopTweaks\Info.json'.
[Manager] Sorting mods.
[Manager] Loading mods.
[TabletopTweaks] To skip (disabled).
[Manager] FINISH. SUCCESSFUL LOADED 1/1 MODS.

The exact failure is that it is trying to load the ElfAbilityModifiers feature and since the mod is not loaded that feature does not exist.

Okay that's bizare. The mod-manager claimed the mod was loaded, I've reloaded and restarted it and now it's started to load again...
I'm not sure what's happened there, mod-manager seemed to be happy...

So things are now working correctly then?

It seems to be it's loaded into the map rather than crashing at 5%, I'm a tad confused.
I'd tried it several times with the mod 'supposed' to be enabled both with 1.0.3 and 1.0.6 and it crashed. Now couple more attempts and it has worked...


Account takeover of vendored dependency

The github account @cobaugh no longer exists, and was taken over by a security researcher. Please replace this dependency before a vendor update can accidentally pull in a compromised version.

(Note: this is not a direct vulnerability, since the vendored version is still valid - we just don't want to pull a new version)

Opened acobaugh/osrelease#2 to give more context about this.

/remove-lifecycle rotten
Waiting for https://github.com/kubernetes/node-problem-detector/pull/628 to merge.


[Solved]The objects in TUISimulator's UI systeam has disappeared

Hi,when I was using Touchdesigner today, I noticed that the Objects (colorful digital squares) on the TUIOSimulator operation page suddenly disappeared, which were displayed normally until today.Hope can received your comment,thank you!
The UI is showing like this ↓ I screen shot that

hey @Kakei08, sorry you had some issues - I hope everything's working ok again!

hey @Kakei08, sorry you had some issues - I hope everything's working ok again!

Thanks for your reply, I found the solution very simple, just zoom in/out the application box and you can see the objects:)And thanks again,great software!

Hmm, sounds like it could be a depth buffer issue or something.
And no worries! My app is pretty simple really, the hard work was done by Valentin Simonov, the author of TouchScript. My TUIOSimulator and the TUIOListener commandline tools were useful for us when we were building interactive touch tables for museum installations so I thought I'd share them.
It would be nice to keep them updated with the latest Unity but support for TouchScript ended years ago so it's a bit out of date now, unfortunately.


Update epinow2 v1.2.1

This PR makes the updates required to support EpiNow2 1.2.1. However, it needs to be tested prior to going into production.
EpiNow2 1.2.1 now outputs a runtimes.csv which this PR loads and reformats. It has the following variables: region and time. This change can dealt with by moving this data.frame into the named list format previously expected by downstream code (as done here) or by changing the downstream code.
EpiNow2 1.2.1 has several processing updates which make estimation failures hopefully less likely. It also has several model changes which should make results more stable.

I'll pop this on the server for a test

closes #83 (linking)

[2] "  reached elapsed time limit"
[3] "In addition: Warning message:"
[4] "In storage.mode(default) <- type :"
[5] "  NAs introduced by coercion to integer range"
error occurred during calling the sampler; sampling not done
Timing stopped at: 2548 3.389 1801
Timing stopped at: 2548 3.389 1802
[1] "Error in sampler$call_sampler(args_list[[i]]) : "
[2] "  reached elapsed time limit"
[3] "In addition: Warning message:"
[4] "In storage.mode(default) <- type :"
[5] "  NAs introduced by coercion to integer range"
error occurred during calling the sampler; sampling not done
Timing stopped at: 892.9 1.586 1801
Timing stopped at: 893 1.587 1802
[1] "Error in sampler$call_sampler(args_list[[i]]) : "
[2] "  reached elapsed time limit"
[3] "In addition: Warning message:"
[4] "In storage.mode(default) <- type :"
[5] "  NAs introduced by coercion to integer range"
error occurred during calling the sampler; sampling not done
Timing stopped at: 2.223 0.46 1801
Timing stopped at: 2.386 0.46 1801
2020-10-19 13:16:04 INFO Completed regional estimates
2020-10-19 13:16:04 INFO Regions with estimates: 1
2020-10-19 13:16:04 INFO Regions with runtime errors: 8
2020-10-19 13:16:04 INFO Producing summary
2020-10-19 13:16:04 INFO Saving summary to : subnational/canada/cases/summary
2020-10-19 13:16:04 INFO Errors caught whilst generating summary statistics:
2020-10-19 13:16:04 INFO Error in .f(...): Only one of results_dir and regional_output should be specified
2020-10-19 13:16:04 INFO Saving timings information to : subnational/canada/cases/national
2020-10-19 13:16:04 DEBUG resetting future plan to sequential
2020-10-19 13:16:04 DEBUG skipping location colombia as it is not in the include list
2020-10-19 13:16:04 DEBUG skipping location germany as it is not in the include list
2020-10-19 13:16:04 DEBUG skipping location india as it is not in the include list
2020-10-19 13:16:04 DEBUG skipping location italy as it is not in the include list
2020-10-19 13:16:04 DEBUG skipping location russia as it is not in the include list
2020-10-19 13:16:04 INFO processing outcome log
Error: false must be NULL, not a Date object.
Backtrace:
█

└─global::run_regional_updates(datasets = datasets, args = args)
└─global::rru_log_outcome(outcome)

└─dplyr::if_else(...)

  └─dplyr:::replace_with(...)

    └─dplyr:::check_type(val, x, name)

      └─dplyr:::glubort(header, "must be {friendly_type_of(template)}, not {friendly_type_of(x)}.")

Warning message:
In storage.mode(default) <- type :
NAs introduced by coercion to integer range
Execution halted
Running it again with verbosity turned up to see what the problem is.

It looks like there were two issues identified and fixed by @medewitt and @sbfnk respectively. One linked to fitting ( fit_model due to an odd interaction with timing out and rstan (we think)) and one due to bad code displine on my part in regional_summary (in setting up a plot saving function). The tagged version has been updated so if you could rerun the test with an updated install of EpiNow2 1.2.1 that would be great.

I'll set that re-running now

2020-10-20 11:34:55 TRACE dataset canada had no data to process
2020-10-20 11:34:55 TRACE status record exists for canada
Error: `false` must be NULL, not a `Date` object.
Backtrace:
    █
 1. └─global::run_regional_updates(datasets = datasets, args = args)
 2.   └─global::rru_log_outcome(outcome)
 3.     └─dplyr::if_else(...)
 4.       └─dplyr:::replace_with(...)
 5.         └─dplyr:::check_type(val, x, name)
 6.           └─dplyr:::glubort(header, "must be {friendly_type_of(template)}, not {friendly_type_of(x)}.")

so it's still failling - I think the updated record is the wrong type in one of the columns but it doesn't say which - it would need debugging to look at the record it's trying to insert into the list.

So is this an error in the processing code we think or in EpiNow2? I wrote the update to the processing code without running so extremely likely to not be correct.

agreevon your diagnosis. I assume/hope its a mistake with my changes to runtimes.csv.

I had similar when I failed to get the column to contain the right POSIXct object type - I expect this is similar but with a DATE type - the table has fixed column types and complains if you get it wrong so hopefully it's just something with how you have mapped the data over. Catching outcomes and debugging it is going to be the easiest way.

Any luck tracking this down. I haven't seen any EpiNow2 issues elsewhere but that doesn't mean there aren't any.

It looks like it might be not handling when a location fails - that seems to be a pattern when I am also getting this error (but I have not properly dug)

It would be good to get this moving if possible. If you have a snapshot of the logs I am happy to look through the code to try and diagnose the issue.
We are seeing that the switch to quantiles is giving much more sensibly shaped credible intervals than the previous high density regions (more robust over time) so it would be good to get this change into the estimates etc.

running a test with this updated to latest to see what happens and pull the logs

2020-10-26 16:05:41 INFO Producing estimates for: Alberta, British Columbia, Manitoba, New Brunswick, Newfoundland and Labrador, Nova Scotia, Ontario, Quebec, Saskatchewan
2020-10-26 16:05:41 INFO Regions excluded: Northwest Territories, Nunavut, Prince Edward Island, Repatriated Travellers, Yukon
2020-10-26 16:05:41 TRACE calling future apply to process each region through the run_region function
2020-10-26 16:05:41 INFO Showing progress using progressr. Modify this behaviour using progressr::handlers.
2020-10-26 16:35:58 INFO Completed regional estimates
2020-10-26 16:35:58 INFO Regions with estimates: 7
2020-10-26 16:35:58 INFO Regions with runtime errors: 2
2020-10-26 16:35:58 INFO Producing summary
2020-10-26 16:35:58 INFO Saving summary to : subnational/canada/cases/summary
2020-10-26 16:35:58 TRACE Getting regional results
2020-10-26 16:35:58 TRACE Summarising results
2020-10-26 16:35:58 INFO Errors caught whilst generating summary statistics:
2020-10-26 16:35:58 INFO Error: `device` must be NULL, a string or a function.

2020-10-26 16:35:58 INFO Saving timings information to : subnational/canada/cases/national
2020-10-26 16:35:58 WARN simpleWarning in gsub("~m", msg, message, fixed = TRUE): argument 'replacement' has length > 1 and only the first element will be used

2020-10-26 16:36:04 DEBUG canada: dataverse exists so just update
2020-10-26 16:36:04 TRACE replacing file subnational/canada/cases/summary/cases_by_infection.csv
...
2020-10-26 16:36:22 TRACE replacing file subnational/canada/cases/summary/summary_table.csv
2020-10-26 16:36:23 INFO canada: publishing
2020-10-26 16:36:53 DEBUG skipping location colombia as it is not in the include list
2020-10-26 16:36:53 DEBUG skipping location germany as it is not in the include list
2020-10-26 16:36:53 DEBUG skipping location india as it is not in the include list
2020-10-26 16:36:53 DEBUG skipping location italy as it is not in the include list
2020-10-26 16:36:53 DEBUG skipping location russia as it is not in the include list
2020-10-26 16:36:53 INFO processing outcome log
2020-10-26 16:36:53 TRACE loading the existing file
2020-10-26 16:36:53 TRACE reformatting the dates back to being dates
2020-10-26 16:36:53 TRACE loading the existing status file
2020-10-26 16:36:53 TRACE reformatting the dates back to being dates
2020-10-26 16:36:53 TRACE processing results for canada
2020-10-26 16:36:53 TRACE dataset canada had no data to process
2020-10-26 16:36:53 TRACE status record exists for canada
2020-10-26 16:36:53 ERROR Error: `false` must be NULL, not a `Date` object.

I don't see this issue anywhere else? I think the failing error is in the timings processing code in this repo.

Todays poking has made some progress:
2020-10-29 14:43:48 TRACE Summarising results
2020-10-29 14:43:48 INFO Errors caught whilst generating summary statistics:
2020-10-29 14:43:48 INFO Error: `device` must be NULL, a string or a function.

2020-10-29 14:43:48 INFO Saving timings information to : subnational/canada/cases/national
2020-10-29 14:43:48 WARN canada: simpleWarning in as.data.table.list(x, keep.rownames = keep.rownames, check.names = check.names, : Item 2 has 5 rows but longest item has 9; recycled with re
mainder.

2020-10-29 14:43:48 WARN simpleWarning in gsub("~m", msg, message, fixed = TRUE): argument 'replacement' has length > 1 and only the first element will be used

It seems there's a possible bug where if you had failures it tries to process something in the summary based on the number it wants not the number it got.
All those errors and the eventual crash are coming from within regional_summary as it is not hitting the trace line I now have immediately following it ( https://github.com/epiforecasts/covid-rt-estimates/pull/96/files#diff-31e37843456589f8f25be8078e415c2d276bf0da7d57c4d48b398f76862c9cbfR134 )

@seabbs Where does epinow write it's errors to currently?

It should use your logging set up and send the logs where you specify externally if logs  = NULL

I am getting close to releasing 1.3.1 shall I make a tag and we switch to testing that? It has the final interface changes so interaction with EpiNow2 will be stable going forward.

latest error:
2020-11-17 10:44:47 TRACE Getting regional results
2020-11-17 10:44:47 WARN simpleWarning in gzfile(file, "rb"): cannot open compressed file 'subnational/united-states/cases/national/runt
imes.csv/latest/summarised_estimates.rds', probable reason 'Not a directory'

that is an uncaught exclusion as runtimes is a csv and so doesn't have estimates but shouldn't be a failing error?

it's looking for an RDS file inside a subfolder within a .csv which seems a bit wonky.
subnational/united-states/cases/national/runtimes.csv/latest/summarised_estimates.rd

it is within an error catch so I don't think it is causing an error here. I agree it could do with being caught so it doesn't occur.

@joeHickson I have updated to the new args from 1.3.0 and made a pre-release for it in the EpiNow2 repo.
The only difference here to what we usually use is the future = TRUE arg which might be causing problems (running stan in parallel and then merging posterior samples back into a single model). Potentially might need to fall back to the traditional behaviour which will sacrifice the ability to kill some chains but not all but may reduce the overall complexity.

The first log issue looks like it may have come from here: https://github.com/epiforecasts/covid-rt-estimates/blob/f22593aae87647ba2ed084c6a79270f9eacab415/R/run-region-updates.R#L239
but has potentially been fixed. The second (device must be NULL, a string or a function) is from plot saving using ggsave and means something other than the string it should be is being passed to the device arg.  In the code (https://github.com/epiforecasts/EpiNow2/blob/c12b5c2432c44b65db2b3844ca0f5dc7f8cad5de/R/summarise.R#L140) I see nothing obvious triggering this. If this pops up again I think the easiest solution is an interactive debug of regional_summary on saved results as not clear what could be causing this.

I'm loading it into the test container now.

🤞

do you have 10 mins? I could give you a call and talk you through how I use the test container.

yes sounds good.

I have sent you a meeting invite that we can use to jump on a teams call

Still the same. Interestingly I could see that it was still processing some of the regions after it had crashed - which is not how I thought the parallel stuff worked. You can see in the log the parallel threads still login stan warnings before and after the main script decides to plough onwards.
to find out why this is a problem and how to eliminate them. -
2020-11-18 20:03:13 WARN Alberta (chain: 2): Examine the pairs() plot to diagnose sampling problems
 -
2020-11-18 20:03:19 ERROR Error in as.environment(where): using 'as.environment(NULL)' is defunct

2020-11-18 20:03:19 WARN simpleWarning in gsub("~m", msg, message, fixed = TRUE): argument 'replacement' has length > 1 and only the fir
st element will be used

2020-11-18 20:03:19 TRACE analyse results
2020-11-18 20:03:19 INFO processing outcome log
2020-11-18 20:03:19 TRACE loading the existing file
2020-11-18 20:03:19 TRACE reformatting the dates back to being dates
2020-11-18 20:03:19 TRACE loading the existing status file
2020-11-18 20:03:19 TRACE reformatting the dates back to being dates
2020-11-18 20:03:19 TRACE processing results for canada
2020-11-18 20:03:19 ERROR No subregions recorded in outcome for canada
2020-11-18 20:03:19 TRACE writing file
2020-11-18 20:03:19 TRACE process derivative datasets
2020-11-18 20:03:19 INFO run complete
2020-11-18 20:03:19 WARN British Columbia (chain: 5): There were 5 divergent transitions after warmup. See
http://mc-stan.org/misc/warnings.html#divergent-transitions-after-warmup
to find out why this is a problem and how to eliminate them. -
2020-11-18 20:03:19 WARN British Columbia (chain: 5): Examine the pairs() plot to diagnose sampling problems
 -
2020-11-18 20:03:43 WARN Alberta (chain: 3): There were 9 divergent transitions after warmup. See
http://mc-stan.org/misc/warnings.html#divergent-transitions-after-warmup
to find out why this is a problem and how to eliminate them. -
2020-11-18 20:03:43 WARN Alberta (chain: 3): Examine the pairs() plot to diagnose sampling problems

as discussed updated with future = FALSE - may help or it may not.

Looks like there was a logic knot (i.e a fancy bug) in the interaction between returning output, generating summaries and timings spotted by @sbfnk here and resolved here. I've updated the tag and revert back to future = TRUE (though this still may cause issues potentially). Will update once CI finsihes on EpiNow2 and I have reviewed again in the morning.

Thanks @seabbs - it looks like it turned into a late one. Let me know when it's ready and I'll pull it down and see what happens

Should be ready now I think. 🤞

I'm still getting that error. does it need description updating for a newer epinow version?

Ah looks like you need to also delete the tag as well as the release in order to change the reference commit. Should now be updated and correct.

I kicked of the global cases to re-run after the last failure so it'll be a while before the box has spare capacity but once it does I'll try again.

Ok progress - back to this error again:
2020-11-19 19:32:05 INFO Saving timings information to : subnational/canada/cases/national
2020-11-19 19:32:05 INFO Saving summary to : subnational/canada/cases/summary
2020-11-19 19:32:05 INFO Extracting results from: subnational/canada/cases/national
2020-11-19 19:32:05 WARN simpleWarning in gzfile(file, "rb"): cannot open compressed file 'subnational/canada/cases/national/runtimes.cs
v/latest/summarised_estimates.rds', probable reason 'Not a directory'
I think its get.R:11- but I haven't debugged yet to see if I can figure out why line 15 isn't filtering it

So this is caught here: https://github.com/epiforecasts/EpiNow2/blob/251f2f1b0251a6fa78d3703484f4fc51cbacd550/R/get.R#L117 and therefore is a warning not an error. I will add a catch to remove it now but I think it unlikely its the root cause of a run failure.
Can you see updates to the summary folder? What updated and what didn't?

I think it writes L165 (INFO Extracting results from: ....) but it doesn't get as far as L176 in https://github.com/epiforecasts/EpiNow2/blob/25bcd449134c41c0deed69300b08a5b542e7a2ec/R/summarise.R
No files have been written to the summary dir

That looked like it ran!

@seabbs can you sanity check those results? I can see graphs but aside from that I couldn't tell you if they are as expected! I'm wary of saying lets go on a friday afternoon but given the rest of the issues I'm tempted...

Love the post it. To me these are all looking as I would expect. @sbfnk thoughts? I don't think 1.2.0 is suddenly going to start working smoothly and it might be easier to debug if working from a common code base.
My vote is deploy and 🙏

https://raw.githubusercontent.com/epiforecasts/covid-rt-estimates/update-epinow2-v1.2.1/subnational/united-kingdom/cases/summary/rt_plot.png
https://raw.githubusercontent.com/epiforecasts/covid-rt-estimates/update-epinow2-v1.2.1/subnational/united-kingdom/cases/summary/reported_cases_plot.png
https://raw.githubusercontent.com/epiforecasts/covid-rt-estimates/update-epinow2-v1.2.1/subnational/united-kingdom/cases/summary/infections_plot.png

comparing master reported_cases_plot -

Master left, this branch right

There's some definite wierdness on the uncertainties on the rt plot - check out midlands / south west for going all a bit lumpy bumpy

1.3.0 uses quantiles and 1.2.0 uses high density regions to summarise uncertainty so some changes in the credible intervals are probably be expected. The slightly odd waggles in the uncertainty are from semi-plausible osciallations in the gaussian process. We haven't nailed down if these are okay plausible edge case behaviour or a model issue yet but its not an unexpected result.

Good to know - not been particularly familiar with the modelling code all I can do is apply an eyeball and ask the silly questions ;)

Shall I back out those two test commits?

Chatted with @sbfnk we think merge in and 🤞

@seabbs do you want to grab a beer, light the blue touch paper and retire for the night?

🥂


Wayland: Move the 96 DPI assumption into the outputHandleMode() callback

Hi, sorry for not reviewing this PR before it was merged, but it relies on the assumption that the mode event will be sent after the geometry event on a given wl_output, which is all but guaranteed.
The proper way to do so would be to store these properties in a temporary struct, and apply them in the done handler (if the protocol version is ≥ 2, otherwise to do it every time a mode or geometry event is received) so that it can react to live changes. Those are arguably quite rare, a normal monitor doesn’t often change its physical size for instance, but it could perfectly do in a VR setup, or in other kinds of non-conventional monitors.

If we consider Weston (reference implementation of a Wayland compositor), the outputHandleGeometry() callback is called before the outputHandleMode():
wl_output_send_geometry(resource,
			output->x,
			output->y,
			head->mm_width,
			head->mm_height,
			head->subpixel,
			head->make, head->model,
			output->transform);
if (version >= WL_OUTPUT_SCALE_SINCE_VERSION)
	wl_output_send_scale(resource,
			     output->current_scale);

wl_list_for_each (mode, &output->mode_list, link) {
	wl_output_send_mode(resource,
			    mode->flags,
			    mode->width,
			    mode->height,
			    mode->refresh);
}

Yes, the PR is based on this consideration.

The protocol is the source of truth defining what an acceptable behaviour can be, and I couldn’t find any mention of an order there, except that done gets emitted after all the other ones are sent, so I’d advise not relying on implementation details of a single compositor.

OK, so we can do something in the outputHandleDone() callback as you suggest.
Wayland versions without "done" event support are very old (this raises me questions about CMakeLists.txt: the pkg_check_modules for Wayland with version 0.2.7 is a strange version number ...)
I have tested the following code:
static void outputHandleDone(void* data, struct wl_output* output)
{
struct _GLFWmonitor *monitor = data;
int i;
for (i = 0; i < monitor->modeCount; ++i)
{
    if (i == monitor->wl.currentMode && (monitor->widthMM <= 0 || monitor->heightMM <= 0))
    {
        // If Wayland does not provide a physical size, assume the default 96 DPI
        monitor->widthMM  = (int) (monitor->modes[monitor->wl.currentMode].width * 25.4f / 96.f);
        monitor->heightMM = (int) (monitor->modes[monitor->wl.currentMode].height * 25.4f / 96.f);
        break;
    }
}

_glfwInputMonitor(monitor, GLFW_CONNECTED, _GLFW_INSERT_LAST);

}
Maybe we need to do a new PR

This one looks more correct, thanks!

I hope b925a54ef11adab250e4e9592afe918c1f8caebb is a step in the right direction.

OK, I tested the code corresponding to this last commit, no issue for me!
Nicolas Caramelli


Script misses firewall & setsebool

Describe the issues
Add
To Reproduce
You can run the script to completion and note that the commands have not been executed.
Expected behavior
Add:
setsebool -P httpd_can_network_connect 1
yum install firewalld
systemctl start firewalld
firewall-cmd --zone=public --add-port=443/tcp --permanent
firewall-cmd --zone=public --add-port=7768/tcp --permanent
firewall-cmd --reload
Screenshots
N/A

The script does those things except it doesn't install firewalld, just runs the firewall-cmd --zone=public --add-port=443/tcp --permanent in case firewalld is installed. As for firewall-cmd --zone=public --add-port=7768/tcp --permanent, I recommend you don't do this as that's opening up your moneyd account port to the public. You should be fine without it.

Actually you're right, there is one thing that is missing. firewall-cmd --reload is missing, my bad. I will open a PR to address this.

Sweet! Happy to contribute. And, thanks.


Add warning about cache purging to useCallback reference

This PR fixes #2334 by adding a warning about cache purging to the useCallback reference documentation.

This has been open for quite a while - I'll close it in a month or two if it's not wanted, just to get it off my list.

Closing as per comment in the issue.
Thank you, @TimothyJones for taking the time to contribute!


Is there any difference in results/training compared to training with joint loss?

Hi,
Thank you for sharing your codes. I am wondering is there any difference in image quality/training when the networks are updated with joint loss term similarly to AttnGAN?
https://github.com/taoxugit/AttnGAN/blob/master/code/trainer.py#L271
https://github.com/taoxugit/AttnGAN/blob/master/code/trainer.py#L296
This would probably also improve the training time. Let me know if you tried training with joint loss.
Thank you.

@k-eak Hi, I haven't tried the joint training. It could probably improve the current model.


Make KarelWorld extendable

Since https://github.com/tudalgo/fopbot/commit/78586d847d3f0eceffda3250ccdce2ede477f011, it is no longer possible to extend the Gui functionality for an exercise (in my case, i would like to use keyboard events). So first of all what's the reasoning behind that? If students wanted to mess with the GUI so badly they could still do so by extending and replacing the static KarelWorld instance. Regardless i think it would make sense to make these kinds of attributes protected instead of private for KarelWorld. In my Oppinion having a Getter also wouldn't hurt for the gui.

IIRC, the headless version (used for grading) does not have any GUI code so that wouldn't work


NTR: D-alanine import across plasma membrane

Please provide as much information as you can:

Suggested term label:

D-alanine import across plasma membrane

Definition (free text)
The directed import of D-alanine from the extracellular region across the plasma membrane and into the cytosol.

Reference, in format PMID:#######
22418438
25425233

Gene product name and ID to be annotated to this term

Q8ZPA3
Q8ZPA2
Q8ZPA1
Q8ZPA0

Parent term(s)
GO:0089718
GO:0042941

@edwong57
We already have  GO:0042941    D-alanine transport; can you check if that can be renamed 'D-alanine transmembrane transport'; or even 'D-alanine import across plasma membrane'?
It seems like all annotated genes are bacterial, so that would be the only possible transmembrane process, right?
Thanks, Pascale

@edwong57
Can you please also look at the other siblings:
GO:0070777 D-aspartate transport
GO:0048473 D-methionine transport
GO:0042942 D-serine transport
and see if the same can be applied (ie move to either 'x import across plasma membrane', or at least 'transmembrane transport?
Thanks, Pascale

We already have GO:0042941 D-alanine transport; can you check if that can be renamed 'D-alanine transmembrane transport'; or even 'D-alanine import across plasma membrane'?
It seems like all annotated genes are bacterial, so that would be the only possible transmembrane process, right?

Import would be the only known process, but as a general strategy, is there any reason to build a direction into a transport term a priori rather than leave it to be specified in the context of a particular annotation? Same quibble about "plasma membrane" rather than just "membrane".

is there any reason to build a direction into a transport term a priori rather than leave it to be specified in the context of a particular annotation?

We can discuss this... the issue is that the BP transmembrane transport is no different from the MF transmembrane transporter activity.
@thomaspd has been arguing that transport should not be a BP, and is always part of a 'larger' process. But for now that's too much refactoring, given all other projects we have open.

@thomaspd has been arguing that transport should not be a BP, and is always part of a 'larger' process. But for now that's too much refactoring, given all other projects we have open.

Perhaps leaving these transmembrane transports as one-step BPs for now would be a good way to resolve the current issue, and meanwhile the one-step nature of the process would be a useful flag / reminder when the time comes for the systematic refactoring that we want to embed the transport steps into larger processes?

@pgaudet, I checked:
GO:0042941 D-alanine transport,
GO:0070777 D-aspartate transport
GO:0048473 D-methionine transport
GO:0042942 D-serine transport
Not all of the proteins annotated directly to these terms are bacterial, but I checked the one PMID that was associated with a human annotation (SLC1A1) and it looks like a membrane protein, and the majority of the Panther families I checked had plasma membrane as the GO-slim cellular component.
I think it is fine to just add 'transmembrane transport' and add this NTR underneath D-alanine transmembrane transport (GO:0042941 D-alanine transport). D-aspartate already has the same child term.


Emit metrics on customer ids being too long

This diff adds a warn limit in addition to the already existing error limit for id lengths. Additionally it starts emitting metrics for violations at the warn level. The purpose of this diff is to have a safe path towards reducing id lengths. Most of the metric scopes are already tagged with domain name and they are all tagged with frontend API scope, between these tags these metrics should be enough to track down the violations of the warn limit.

Coverage increased (+0.6%) to 67.642% when pulling 149d8ae6ef9388b536bdab07703a220ee162c4d3 on andrewjdawson2016:IDLengthLimits into c8b2b4c6c924818036d8a3456d6271c0d6535454 on uber:master.


Blazor WASM validation problem

Hi,
I have some strange case during use of ValidateComplexType and ObjectGraphDataAnnotationsValidator.
When i change value in InputText I am getting this

While when I trigger EditContext.Validate(), it validates form as expexted.

Razor
<EditForm EditContext="EditContext">
    <ObjectGraphDataAnnotationsValidator />
    <ValidationSummary />

        <InputText @bind-Value="ViewModel.TestDto.Name" />
        <ValidationMessage For="()=>ViewModel.TestDto.Name" />

        <button @onclick="()=>ViewModel.ValidateForm?.Invoke()">Validate form</button>

</EditForm>

On OnInitialized
Creating view model which holds empty (new) dto model and setting EditContext with view model.
protected override void OnInitialized()
{
    ViewModel = new TestViewModel();
    ViewModel.TestDto = new TestDto()
    {
        Name = string.Empty //fails validation
    };
    ViewModel.ValidateForm = () => EditContext.Validate();

    EditContext = new EditContext(ViewModel);

    base.OnInitialized();
}

OnAfterRender
Loading "real" dto model data and setting it on existing view model property.
protected override void OnAfterRender(bool firstRender)
{
    if(firstRender){
        ViewModel.LoadTestDto();
        StateHasChanged();
    }

    base.OnAfterRender(firstRender);
}

View model
public class TestViewModel
{
    public string PageTitle => "Test page";
    public Func<bool> ValidateForm { get; set; }

    [ValidateComplexType]
    public TestDto TestDto { get; set; }

    public void LoadTestDto()
    {
        TestDto = new TestDto(InstanceIdId)
        {
            Name = "Loaded name" // pass validation
        };
    }
}

Dto model
public class TestDto
{
    [Required(ErrorMessage = "Name fieild is required.")]
    public string Name { get; set; }
}

When I was trying to debug on focus out validation behaviour, it seems first call of TestDto.Name getter is made on old instance of object which is created during OnInitialized and which should be replaced during OnAfterRender  life cycle event..
In case when i removed creating of new empty instance during OnInitialized, everything works as expected, but, in my case, that is not desired scenario.
Any suggestion?
Best regards
BlazorApp1.zip

Hello @CashPJ ... First off, please use the This page feedback form at the bottom of a topic to open issues here. It cross-links and pings the author (ME 🦖 in this case 😄) that you opened the issue and applies all of the correct labeling to the issue.
WRT your app, we don't troubleshoot dev issues here with their apps. We recommend that you take it up with the community on a public support channel. We only work on the docs here. We just don't have the staffing to troubleshoot app problems. If you have a clear doc bug report 😈 to file, we DO want to hear about those here. You need to call out exactly what the problem is with the document tho.

Stack Overflow (tag: blazor)
ASP.NET Core Slack Team
Blazor Gitter


Recognize *.wsf as XML file

(Original issue 850 created by roskakori on 2013-02-20T01:05:17.362970+00:00)
Please extend the XmlLexer so that it also recognizes *.wsf as XML files. These are Windows script files as described in https://en.wikipedia.org/wiki/Windows_Script_File. Basically, they are valid XML files containing VBScript scripts and also allow to include other VBScripts and an online help for the command line parameters.
This should be easy to implement by adding the extension to lexers.web.XmlLexer:
#!python
class XmlLexer(RegexLexer):
    ...
    filenames = ['*.xml', '*.xsl', '*.rss', '*.xslt', '*.xsd', '*.wsdl', '*.wsf']

(Original issue 850 last updated on 2013-05-19T09:56:17.294315+00:00)
(Issue automaticaly closed due to status in Bitbucket: resolved)

(Original comment by birkenfeld on 2013-05-19T09:56:17.289052+00:00)
Closes #850: recognize .wsf as XML files.
→ <>


❓ Questions / Help / Support - where do i download silero_lang_detector for onnx

I am looking to get the model working with a nodejs application and I am curious where I can just download the model?  Is it apart of the vad model?  The other models all have their urls mapped out but the lang detector is always just being loaded by torch hub.

Hi,
The lang detector is deprecated now.
But you can find the url in the hubconf file.


Pre-trained models

One of the successes of Caffe has been its Model Zoo. Are there plans to support importing Caffe models or otherwise provide pre-trained models for TF?

Hi jimfleming, please see: https://github.com/tensorflow/tensorflow/issues/6 for tracking this issue.  Thanks!


Yoga Thinkpad x1 gen2

Model
Yoga Thinkpad x1 gen2

Patchset
xx80

TPM
Yes, (paranoidbashthot bypass)

Notes
Changing memory profile / speed causes brick, spi flash near 4g module

added


TypeError: pathEl.getTotalLength is not a function when mounting with enzyme / jest

Hi there,  I'm seeing a lot of errors while trying to use enzyme and jest with react-mt-svg-lines;  Wondering if I could get some input.  I'm trying to mount a component and simulate a click on it and then test the state afterwards.  This involves getPathLengths, which fails.  I'm not sure why it fails, was hoping I could get some input.  This is a snippet of my code:
import React from 'react';
import { shallow, mount } from 'enzyme';
import BugReportForm from 'Feedback/BugReport.jsx';
import { Button } from 'antd';
import SubmissionThankYou from 'Modules/SubmissionThankYou/SubmissionThankYou.jsx';

const mt = mount(<BugReportForm />);

it('correctly responds to form submit', () => {
  console.log(mt.debug());
  mt.find(Button).at(0).simulate('submit');
  expect(mt.find(SubmissionThankYou)).toHaveLength(1);
});

This is the error returned:
TypeError: pathEl.getTotalLength is not a function

      at node_modules/react-mt-svg-lines/lib/index.js:378:90
      at NodeList.map (native)
      at MtSvgLines._getPathLengths (node_modules/react-mt-svg-lines/lib/index.js:374:21)
      at MtSvgLines._animate (node_modules/react-mt-svg-lines/lib/index.js:229:34)
      at MtSvgLines.componentDidMount (node_modules/react-mt-svg-lines/lib/index.js:96:12)
      at node_modules/react-dom/lib/ReactCompositeComponent.js:265:25
      at measureLifeCyclePerf (node_modules/react-dom/lib/ReactCompositeComponent.js:75:12)
      at node_modules/react-dom/lib/ReactCompositeComponent.js:264:11
      at CallbackQueue.notifyAll (node_modules/react-dom/lib/CallbackQueue.js:76:22)
      at ReactReconcileTransaction.close (node_modules/react-dom/lib/ReactReconcileTransaction.js:80:26)
      at ReactReconcileTransaction.closeAll (node_modules/react-dom/lib/Transaction.js:206:25)
      at ReactReconcileTransaction.perform (node_modules/react-dom/lib/Transaction.js:153:16)
      at ReactUpdatesFlushTransaction.perform (node_modules/react-dom/lib/Transaction.js:140:20)
      at ReactUpdatesFlushTransaction.perform (node_modules/react-dom/lib/ReactUpdates.js:89:32)
      at Object.flushBatchedUpdates (node_modules/react-dom/lib/ReactUpdates.js:172:19)
      at ReactDefaultBatchingStrategyTransaction.closeAll (node_modules/react-dom/lib/Transaction.js:206:25)
      at ReactDefaultBatchingStrategyTransaction.perform (node_modules/react-dom/lib/Transaction.js:153:16)
      at Object.batchedUpdates (node_modules/react-dom/lib/ReactDefaultBatchingStrategy.js:62:26)
      at Object.batchedUpdates (node_modules/react-dom/lib/ReactUpdates.js:97:27)
      at node_modules/react-dom/lib/ReactTestUtils.js:348:18
      at ReactWrapper.<anonymous> (node_modules/enzyme/build/ReactWrapper.js:776:11)
      at ReactWrapper.single (node_modules/enzyme/build/ReactWrapper.js:1421:25)
      at ReactWrapper.simulate (node_modules/enzyme/build/ReactWrapper.js:769:14)
      at Object.<anonymous>.it (src/Feedback/BugReport.test.jsx:36:31)
          at Promise (<anonymous>)
      at Promise.resolve.then.el (node_modules/p-map/index.js:42:16)
          at <anonymous>
      at process._tickCallback (internal/process/next_tick.js:169:7)

I seem to be able to workaround it by forcing a 0 return if getTotalLength is undefined.  I have this workaround live on my fork .

I see. I'll look at it soon, if nothing else can push an updated version which will guard for undefined. Thanks!

@angryrancor: Sorry, took me while to get to it. Didn't test with Jest/Enzyme but applied the guard for undefined, published as 0.8.1. If you could try it and let me know, that would be great!

Hey @moarwick, this issue seems to still be appearing with Jest/Enzyme. I'm on react-mt-svg-lines 0.8.4. Here's the error I encountered:
`TypeError: pathEl.getTotalLength is not a function
  at node_modules/react-mt-svg-lines/lib/index.js:375:89
      at Proxy.map (<anonymous>)
  at MtSvgLines.getPathLengths (node_modules/react-mt-svg-lines/lib/index.js:374:21)
  at MtSvgLines.animate (node_modules/react-mt-svg-lines/lib/index.js:229:34)
  at MtSvgLines.componentDidMount (node_modules/react-mt-svg-lines/lib/index.js:96:12)
  at node_modules/react-dom/lib/ReactCompositeComponent.js:262:25
  at measureLifeCyclePerf (node_modules/react-dom/lib/ReactCompositeComponent.js:73:12)
  at node_modules/react-dom/lib/ReactCompositeComponent.js:261:11
  at CallbackQueue.notifyAll (node_modules/react-dom/lib/CallbackQueue.js:74:22)
  at ReactReconcileTransaction.close (node_modules/react-dom/lib/ReactReconcileTransaction.js:78:26)
  at ReactReconcileTransaction.closeAll (node_modules/react-dom/lib/Transaction.js:207:25)
  at ReactReconcileTransaction.perform (node_modules/react-dom/lib/Transaction.js:154:16)
  at batchedMountComponentIntoNode (node_modules/react-dom/lib/ReactMount.js:124:15)
  at ReactDefaultBatchingStrategyTransaction.perform (node_modules/react-dom/lib/Transaction.js:141:20)
  at Object.batchedUpdates (node_modules/react-dom/lib/ReactDefaultBatchingStrategy.js:60:26)
  at Object.batchedUpdates (node_modules/react-dom/lib/ReactUpdates.js:95:27)
  at Object._renderNewRootComponent (node_modules/react-dom/lib/ReactMount.js:317:18)
  at Object._renderSubtreeIntoContainer (node_modules/react-dom/lib/ReactMount.js:399:32)
  at Object.render (node_modules/react-dom/lib/ReactMount.js:420:23)
  at Object.render (node_modules/enzyme-adapter-react-15/build/ReactFifteenAdapter.js:181:50)
  at new ReactWrapper (node_modules/enzyme/build/ReactWrapper.js:98:16)
  at mount (node_modules/enzyme/build/mount.js:19:10)
  at Object.<anonymous> (tests/PageFooter.test.js:22:14)`

I am experiencing this issue with version 0.9.1:
TypeError: pathEl.getTotalLength is not a function

      30 |
      31 | const render = (ui: ReactElement, options?: Omit<RenderOptions, "queries">) =>
    > 32 |     baseRender(ui, { wrapper: AllTheProviders, ...options }) as RenderResult;
         |     ^
      33 |
      34 | // re-export everything
      35 | export * from "@testing-library/react";

      at node_modules/react-mt-svg-lines/lib/index.js:214:89
          at Proxy.map (<anonymous>)
      at MtSvgLines.getPathLengths (node_modules/react-mt-svg-lines/lib/index.js:213:21)
      at MtSvgLines.animate (node_modules/react-mt-svg-lines/lib/index.js:318:34)
      at MtSvgLines.componentDidMount (node_modules/react-mt-svg-lines/lib/index.js:87:12)
      at commitLifeCycles (node_modules/react-dom/cjs/react-dom.development.js:20663:24)
      at commitLayoutEffects (node_modules/react-dom/cjs/react-dom.development.js:23426:7)
      at HTMLUnknownElement.callCallback (node_modules/react-dom/cjs/react-dom.development.js:3945:14)
      at HTMLUnknownElement.callTheUserObjectsOperation (node_modules/jsdom/lib/jsdom/living/generated/EventListener.js:26:30)
      at innerInvokeEventListeners (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:338:25)
      at invokeEventListeners (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:274:3)
      at HTMLUnknownElementImpl._dispatch (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:221:9)
      at HTMLUnknownElementImpl.dispatchEvent (node_modules/jsdom/lib/jsdom/living/events/EventTarget-impl.js:94:17)
      at HTMLUnknownElement.dispatchEvent (node_modules/jsdom/lib/jsdom/living/generated/EventTarget.js:231:34)
      at Object.invokeGuardedCallbackDev (node_modules/react-dom/cjs/react-dom.development.js:3994:16)
      at invokeGuardedCallback (node_modules/react-dom/cjs/react-dom.development.js:4056:31)
      at commitRootImpl (node_modules/react-dom/cjs/react-dom.development.js:23151:9)
      at unstable_runWithPriority (node_modules/scheduler/cjs/scheduler.development.js:468:12)
      at runWithPriority$1 (node_modules/react-dom/cjs/react-dom.development.js:11276:10)
      at commitRoot (node_modules/react-dom/cjs/react-dom.development.js:22990:3)
      at performSyncWorkOnRoot (node_modules/react-dom/cjs/react-dom.development.js:22329:3)
      at scheduleUpdateOnFiber (node_modules/react-dom/cjs/react-dom.development.js:21881:7)
      at updateContainer (node_modules/react-dom/cjs/react-dom.development.js:25482:3)
      at node_modules/react-dom/cjs/react-dom.development.js:26021:7
      at unbatchedUpdates (node_modules/react-dom/cjs/react-dom.development.js:22431:12)
      at legacyRenderSubtreeIntoContainer (node_modules/react-dom/cjs/react-dom.development.js:26020:5)
      at Object.render (node_modules/react-dom/cjs/react-dom.development.js:26103:10)
      at node_modules/@testing-library/react/dist/pure.js:101:25
      at batchedUpdates$1 (node_modules/react-dom/cjs/react-dom.development.js:22380:12)
      at act (node_modules/react-dom/cjs/react-dom-test-utils.development.js:1042:14)
      at render (node_modules/@testing-library/react/dist/pure.js:97:26)
      at render (test/index.tsx:32:5)
      at Object.<anonymous> (src/components/transition/index.spec.tsx:7:27)


Typescript import error - not a module

I installed the latest version 0.23.0-rc4, but the following import:
import MapView, { Marker } from 'react-native-maps-osmdroid'

leads to this error
TS2306: File '/home/janek/daten/projects/apps/btl-app/node_modules/react-native-maps-osmdroid/index.d.ts' is not a module.

Using Expo SDK 36.0.1 and React 16.9.0

Fixed


Bug 19266 toolmanager register tools

Closing this as this has been refused because MITK is moving towards a microservice based approach for segmentation tools.


lightmapper_cpu.cpp: 'rand' not declared in this scope when compiling

Godot version:
3.2.4 beta 6 from 7e207cfd48d6077ac6aaa3c45423d3fcf2f90bd7
OS/device including version:
Windows 10 (building under WSL, Ubuntu 16.04.7 LTS)
Issue description:
Expect completed build, but get:
modules/lightmapper_cpu/lightmapper_cpu.cpp: In function 'float uniform_rand()':
modules/lightmapper_cpu/lightmapper_cpu.cpp:779:44: error: 'rand' was not declared in this scope
  static thread_local uint32_t state = rand();
                                            ^

Steps to reproduce:

Build with scons -j32 platform=x11 use_lto=yes bits=64 tools=yes target=release_debug

Note: tools=no does not generate this error.
Minimal reproduction project:
N/A

Inserting #include <random> into lightmapper_cpu.h fixes it but I don't know if this causes problems with other platforms.

Inserting #include <random> into lightmapper_cpu.h fixes it but I don't know if this causes problems with other platforms.

No compilation issue here but maybe older GCC versions had different base includes. I'm assuming you're using gcc-5.3.1 from Ubuntu 16.04?

No compilation issue here but maybe older GCC versions had different base includes. I'm assuming you're using gcc-5.3.1 from Ubuntu 16.04?

Does this change work? It should be more minimal than including <random>:
diff --git a/modules/lightmapper_cpu/lightmapper_cpu.cpp b/modules/lightmapper_cpu/lightmapper_cpu.cpp
index ba07451cdf..75af65ed90 100644
--- a/modules/lightmapper_cpu/lightmapper_cpu.cpp
+++ b/modules/lightmapper_cpu/lightmapper_cpu.cpp
@@ -36,6 +36,8 @@
 #include "core/project_settings.h"
 #include "modules/raycast/lightmap_raycaster.h"

+#include <cstdlib> // rand
+
 Error LightmapperCPU::_layout_atlas(int p_max_size, Vector2i *r_atlas_size, int *r_atlas_slices) {

        Vector2i atlas_size;

Does this change work? It should be more minimal than including <random>:
diff --git a/modules/lightmapper_cpu/lightmapper_cpu.cpp b/modules/lightmapper_cpu/lightmapper_cpu.cpp
index ba07451cdf..75af65ed90 100644
--- a/modules/lightmapper_cpu/lightmapper_cpu.cpp
+++ b/modules/lightmapper_cpu/lightmapper_cpu.cpp
@@ -36,6 +36,8 @@
 #include "core/project_settings.h"
 #include "modules/raycast/lightmap_raycaster.h"

+#include <cstdlib> // rand
+
 Error LightmapperCPU::_layout_atlas(int p_max_size, Vector2i *r_atlas_size, int *r_atlas_slices) {

        Vector2i atlas_size;

Just ran into this using latest clang on macOS as well.
The fix I was about to make a PR for was to use Math:
static thread_local uint32_t state = Math::rand();

Just ran into this using latest clang on macOS as well.
The fix I was about to make a PR for was to use Math:
static thread_local uint32_t state = Math::rand();

No compilation issue here with GCC 10 but maybe older GCC versions had different base includes. I'm assuming you're using gcc-5.3.1 from Ubuntu 16.04?

Current versions:

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
ldd (Ubuntu GLIBC 2.23-0ubuntu11.2) 2.23
GNU C Library (Ubuntu GLIBC 2.23-0ubuntu11.2) stable release version 2.23, by Roland McGrath et al.

As a side note, I would advise that you install the newest GCC or Clang you can get on Ubuntu 16.04 to have better optimization and LTO. GCC 5 is really old by now and there's been a lot of improvement over the years in compilers. (On the other hand you're right about building on Ubuntu 16.04 because you need an old glibc for compatibility with all distros with a newer version).

Good point about updating GCC!  And yeah, the 16.04 is my original WSL version from ages ago and it comes in handy at times. :)

No compilation issue here with GCC 10 but maybe older GCC versions had different base includes. I'm assuming you're using gcc-5.3.1 from Ubuntu 16.04?

Current versions:

gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)
ldd (Ubuntu GLIBC 2.23-0ubuntu11.2) 2.23
GNU C Library (Ubuntu GLIBC 2.23-0ubuntu11.2) stable release version 2.23, by Roland McGrath et al.

As a side note, I would advise that you install the newest GCC or Clang you can get on Ubuntu 16.04 to have better optimization and LTO. GCC 5 is really old by now and there's been a lot of improvement over the years in compilers. (On the other hand you're right about building on Ubuntu 16.04 because you need an old glibc for compatibility with all distros with a newer version).

Good point about updating GCC!  And yeah, the 16.04 is my original WSL version from ages ago and it comes in handy at times. :)

I tested both @akien-mga and @asmaloney proposed fixes and both worked.

I tested both @akien-mga and @asmaloney proposed fixes and both worked.

Fixed by #45353.


verify local secret template

Add a pattern_dir variable to the playbook
Add a check a check_missing_secrets parameter to vault_load_secrets
Add a number of unit tests to verify the new check_missing_secrets functionality
Add all the code to actually verify secrets against values-secret-template.yaml but keep it disabled
Fix a couple of linting issues

Since this is still set to false (https://github.com/hybrid-cloud-patterns/common/pull/190/files#diff-47ee1f6bb0de839f20cc64b425ed71f84a22a348b30791c339fcd1abe54b137cR44) I am merging it for the time being. To enable it by default we'll need to add better docs and check that every pattern has a correctly formed values-secret.yaml.template in the patterns' root dir.


AdamW constant pre-calculation outside of kernel

This PR does the precalculations all of the constants multiplications with one another and reduces the amount of parameters required to be passed into the adamw kernel.
This PR also removes the bounds check inside the kernel and replaces it with an assert where the kernel is being called.

@ChrisDryden  see the comments above about bounds checks, but also i'm curious does this have any benefit to merge, in terms of speed or something that you've measured? It's not computationally optimal but I do like that the AdamW algorithm is just very simply laid out in the kernel, and it's very clear what is happening there.

Was testing this with the newest changes and I'm only getting a speedup of 3 microseconds on average in the kernel testing suite, doesn't seem worth the tradeoff. Will close it for now.


export ModuleFilenameHelpers

I've written a plugin that does some obfuscation, and I've started out from the UglifyJsPlugin (https://github.com/webpack/webpack/blob/master/lib/optimize/UglifyJsPlugin.js). The plugin uses ModuleFilenameHelpers, which seems like an internal dependency, as it is not exported (https://github.com/webpack/webpack/blob/master/lib/webpack.js#L65).
I think it should be exported, so that external plugins can import it as require("webpack").ModuleFilenameHelpers; instead of require("webpack/lib/ModuleFilenameHelpers.js");

yep, feel free to send a PR.

I think this was fixed with 668121453d4158224f79347de685aa466b58c0b3, can be closed.