Performance increase on Windows

I just ran quick tests in GDScript to see how fast it performs, things like that:
    _time_before = OS.get_ticks_msec()

    start()

    for i in range(0,ITERATIONS):
        # Simple code

    _for_time = stop()
    print("For time: " + str(_for_time))

And I quickly realized that the version of Godot I built is 5 times faster than the official 2.0.2.
I didn't modified anything in SCons or Godot, just ran a build after following this tutorial from GamesFromScratch: http://www.gamefromscratch.com/post/2015/06/18/Godot-and-Visual-Studio.aspx
As discussed on IRC, this could be caused by the use of another compiler.
So I tried with prior versions, and 2.0.0 is also 5 times faster than 2.0.1 and 2.0.2.
I personally used msvc12, but msvc14 could be even better.
If we can get such performance gains, would it be possible to provide builds made with these compilers on the appropriate platforms?

Are you build with tools or only the template? And release_debug or debug? Are you running your script in the editor or in an exported game?
There might be compiler-specific differences, though 5 times faster seems quite surprising. We'd need someone to do a real comparison of binaries made with MSVC, MinGW on Windows and MinGW on Linux, all built on the same machine with the same arguments, so that we can properly compare their performance.
The 2.0 binaries were also built on Linux with MinGW AFAIK, but on a different server, so potentially different version of the compiler.

print is a bad benchmark, Windows console is slow as hell.
On Thu, Apr 14, 2016 at 8:38 AM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

Are you build with tools or only the template? And release_debug or debug?
Are you running your script in the editor or in an exported game?
There might be compiler-specific differences, though 5 times faster seems
quite surprising. We'd need someone to do a real comparison of binaries
made with MSVC, MinGW on Windows and MinGW on Linux, all built on the same
machine with the same arguments, so that we can properly compare their
performance.
The 2.0 binaries were also built on Linux with MinGW AFAIK, but on a
different server, so potentially different version of the compiler.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-209771902

I compiled with Debug configuration, from Visual Studio (which runs SCons in the background anyways).
I am running the script in the editor. I also tested in an exported game and performance is roughly the same.
@slapin printing is not included in the benchmark, I run my tests inside a for loop with a lot of iterations, so Windows console has nothing to do with the speed. Despite a quite naive method, it gives a quick preview, and 5 times is a lot for a preview.
Here is the project I run: http://zylannprods.fr/dl/godot/GDScriptPerformance.zip

I have this experience too.
I tested similar way as this post.
I got slow performance with windows tool built on Linux, MinGW.
I got better performace (about 5~7 times faster) with windows tool built on Windows, MSVC 2015 community edition.
And tool binary size is much smaller, it's about 17MB.

Same on my end, using MSVC14

Damn, that is impressive! Sounds like the official builds for Windows should definitely be built on Windows :)

or optimizations should be enabled.
On Sat, Apr 16, 2016 at 3:47 AM, James Redmond<EMAIL_ADDRESS>wrote:

Damn, that is impressive! Sounds like the official builds for Windows
should definitely be built on Windows :)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-210699151

As akien-mga said, it could be more than just Windows.
@slapin I checked the compilation log, here is a sample of what it says:
cl /Focore\array.windows.tools.obj /c core\array.cpp /TP /TP /nologo /DFREETYPE_ENABLED /Z7 /DDEBUG_ENABLED /DDEBUG_MEMORY_ENABLED /DD3D_DEBUG_INFO /Od /MT /Gd /GR /nologo [...]
There is the /Od flag on, which means no optimization. https://msdn.microsoft.com/en-us/library/k1ack8f1(v=vs.120).aspx

That benchmark would be nice to have from cmdline.
Stable release binaries are compiled with gdb symbols. I don't know how it affect performance, but it makes debugging godot crashes much easier. As easy as r and bt.

This is surprising. It could be interesting to run other benchmarks.

Stable release binaries are compiled with gdb symbols.

Only the editor IINM, to allow in-editor debugging. The export templates have no debug symbols.
Anyway, it is interesting to have more benchmarks.

About debugging symbols - they don't affect performance at all. But Godot
debug biaries are built without optimizations, too (that makes debugging
easier
because it is easier to factor-out problem code in this case).
On Mon, Apr 18, 2016 at 2:38 AM, George Marques<EMAIL_ADDRESS>wrote:

Stable release binaries are compiled with gdb symbols.
Only the editor IINM, to allow in-editor debugging. The export templates
have no debug symbols.
Anyway, it is interesting to have more benchmarks.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-211128823

I don't know how to compile Godot but I would like to confirm I noticed the same performance drop from 2.0 and 2.0.2 (I was sent here from reddit) : https://www.reddit.com/r/godot/comments/4fjlua/performance_drop_with_latest_update/

I created a repository with my tests: https://github.com/Zylann/gdscript_performance

Would it be a good idea to add appveyor as a build platform to prevent cross compile?

Would it be a good idea to add appveyor as a build server to prevent cross compile?

Yes that's something that we should look into. I'd prefer having everything done in Travis CI, but if there's a real performance loss due to cross-compiling, doing native builds with AppVeyor is the way to go.

@akien-mga I am actually investigating on an appveyor.yml for building godot with appveyor. Should build both x86 and x64 for both release and debug right? PlutoBoy seems to have a good appveyor.yml for building something with scons. I will try something in my fork

@mattiascibien It should be the tools (tools=yes) with target=release_debug, and the export templates (tools=no) with target=release and target=release_debug. And that for both bits=32 and bits=64 yeah (though the bits argument just got removed in #4274 for the master branch, but it's still in use in the 2.0 branch for now).
IIRC @Marqin also started looking into building Godot with AppVeyor, he might have a WIP config in his fork too.

Ok... It seems that @Marqin's work is definetely almost complete i guess. I'll leave it to him then.

Yep, but my work is not compatibile with #4274 ( I'm using my own changed detect.py there )

I'd like official build to come with gdb support regardless of performance.

@techtonik on Windows? Anyways, as akien-mga said, 2.0 was built with MinGW so using the right version rather than switching to msvc could also bring better results. I'm curious :)

@Zylann yes, on Windows. Getting into gdb and getting the right stacktrace in copy/pasteable format is so much easier than trying to find your way through all the details. I am not sure if same Linux tools can be used to profile godot binaries there.
BTW, can we collect benchmark results on https://github.com/Zylann/gdscript_performance page? Using downloadable version and custom one with and without debug. Godot still fails to run on my system without ANGLE, so I can't test it myself for the moment.

@mattiascibien I've PRed working appveyor.yml to godot-builds repo - https://github.com/GodotBuilder/godot-builds/pull/1

Could you guys try the Windows binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/master_20160512 ? There's only the 64-bit Windows editor right now, but other binaries should arrive as AppVeyor builds them with MSVC and uploads them (the other binaries are from Travis).
You could then compare with the Windows binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/2.0_20160512, which were cross-compiled on Travis CI with MinGW. Those are from the 2.0 branch while the former are from the master branch, but performance wise it shouldn't make a big difference.

Just tried, here are my result times for GDScript:
Binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/master_20160512 (MSVC):
Empty func (void function call cost): 82
Increment: 34
Increment x5: 173
Increment with member var: 34
Increment with local (outside loop): 32
Increment with local (inside loop): 61
Increment Vector2: 36
Increment Vector3: 36
Increment Vector3 with constant: 34
Increment Vector3 coordinate by coordinate: 933
Unused local (declaration cost): 8
Divide: 58
Increment with dictionary member: 149
Increment with array member: 60
While time (for equivalent with manual increment): 84
if(true) time: 17
if(true)else time: 19
VariantArray resize: 959
VariantArray set element: 19
IntArray resize: 342

Binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/2.0_20160512 (MinGW cross-compiled):
Empty func (void function call cost): 517
Increment: 548
Increment x5: 2765
Increment with member var: 549
Increment with local (outside loop): 546
Increment with local (inside loop): 744
Increment Vector2: 551
Increment Vector3: 539
Increment Vector3 with constant: 550
Increment Vector3 coordinate by coordinate: 6101
Unused local (declaration cost): 170
Divide: 564
Increment with dictionary member: 1484
Increment with array member: 957
While time (for equivalent with manual increment): 1032
if(true) time: 118
if(true)else time: 125
VariantArray resize: 1644
VariantArray set element: 342
IntArray resize: 2417
IntArray set element: 1509

My own custom build (quite old now, I should git pull):
Increment: 54
Increment x5: 330
Increment with member var: 65
Increment with local (outside loop): 55
Increment with local (inside loop): 98
Increment Vector2: 88
Increment Vector3: 75
Increment Vector3 with constant: 74
Increment Vector3 coordinate by coordinate: 2983
Unused local (declaration cost): 6
Divide: 82
Increment with dictionary member: 435
Increment with array member: 105
While time (for equivalent with manual increment): 171
if(true) time: 31
if(true)else time: 16
VariantArray resize: 9808
VariantArray set element: 36
IntArray resize: 5665
IntArray set element: 615

compiling godot with debug or tools also adds a large amount of runtime
checks, are you testing both mingw and msvc on release?
On Thu, May 12, 2016 at 2:22 PM, Sergey Lapin<EMAIL_ADDRESS>wrote:

Well, the results look like MinGW builds do have optimizations switched off
and MSVC builds do optimize.
the increment can't be 10 times slower with gcc :)
What test do you run, I'd like to test locally?
On Thu, May 12, 2016 at 7:37 PM, Marc<EMAIL_ADDRESS>wrote:

Just tried, here are my result times for GDScript:
Binaries from

https://github.com/GodotBuilder/godot-builds/releases/tag/master_20160512

(MSVC):
Empty func (void function call cost): 82
Increment: 34
Increment x5: 173
Increment with member var: 34
Increment with local (outside loop): 32
Increment with local (inside loop): 61
Increment Vector2: 36
Increment Vector3: 36
Increment Vector3 with constant: 34
Increment Vector3 coordinate by coordinate: 933
Unused local (declaration cost): 8
Divide: 58
Increment with dictionary member: 149
Increment with array member: 60
While time (for equivalent with manual increment): 84
if(true) time: 17
if(true)else time: 19
VariantArray resize: 959
VariantArray set element: 19
IntArray resize: 342
Binaries from
https://github.com/GodotBuilder/godot-builds/releases/tag/2.0_20160512
(MinGW cross-compiled):
Empty func (void function call cost): 517
Increment: 548
Increment x5: 2765
Increment with member var: 549
Increment with local (outside loop): 546
Increment with local (inside loop): 744
Increment Vector2: 551
Increment Vector3: 539
Increment Vector3 with constant: 550
Increment Vector3 coordinate by coordinate: 6101
Unused local (declaration cost): 170
Divide: 564
Increment with dictionary member: 1484
Increment with array member: 957
While time (for equivalent with manual increment): 1032
if(true) time: 118
if(true)else time: 125
VariantArray resize: 1644
VariantArray set element: 342
IntArray resize: 2417
IntArray set element: 1509
My own custom build (quite old now, I should git pull):
Increment: 54
Increment x5: 330
Increment with member var: 65
Increment with local (outside loop): 55
Increment with local (inside loop): 98
Increment Vector2: 88
Increment Vector3: 75
Increment Vector3 with constant: 74
Increment Vector3 coordinate by coordinate: 2983
Unused local (declaration cost): 6
Divide: 82
Increment with dictionary member: 435
Increment with array member: 105
While time (for equivalent with manual increment): 171
if(true) time: 31
if(true)else time: 16
VariantArray resize: 9808
VariantArray set element: 36
IntArray resize: 5665
IntArray set element: 615
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<https://github.com/godotengine/godot/issues/4313#issuecomment-218813784

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-218826088

I don't know about the exact build options for the two versions from Travis and AppVeyor, but I can say the custom version I built is in debug mode, uses SCons (I didn't touched anything) and according to the logs, optimizations are off, as shown in my previous messages.
I run these simple GDScript tests: https://github.com/Zylann/gdscript_performance

Try also Bunnnymark.
W dniu czwartek, 12 maja 2016 Marc<EMAIL_ADDRESS>napisał(a):

I don't know about the exact build options for the two versions from
Travis and AppVeyor, but I can say the custom version I built is in debug
mode, uses SCons (I didn't touched anything) and according to the logs,
optimizations are off, as shown in my previous messages.
I run these simple GDScript tests:
https://github.com/Zylann/gdscript_performance
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-218831777

It seems print does not work on release. But a project running only the script runs noticeably faster with the MSVC-compiled version (I built both my own at 48dc4d9). I'll try later with release_debug but without tools to check the prints.
The Bunnymark cited by @Marqin crashes when I use the Mingw 64-bit version. It can go around ~6000 bunnies in without losing FPS with MSVC-compiled, both 32- and 64-bits. With Mingw-compiled 32-bit I get slowdowns before reaching 2000 bunnies.

@slapin please enlighten us on how to add optimization to Mingw build, because AFAIK it's already enabled.
I wouldn't be surprised if Microsoft's compiler to its own platform is more optimized than a port of GCC for Windows. But if there's a way to optimize Mingw builds even further without breaking Godot I'm all open to it.

MSVC can be faster but not 10 times faster. The result is not realistic.
Something is just plain broken.
On Thu, May 12, 2016 at 10:43 PM, George Marques<EMAIL_ADDRESS>wrote:

It seems print does not work on release. But a project running only the
script runs noticeably faster with the MSVC-compiled version (I built both
my own at 48dc4d9
https://github.com/godotengine/godot/commit/48dc4d92a8f3c9eb42456eda2433c6fcaff0c723).
I'll try later with release_debug but without tools to check the prints.
The Bunnymark https://github.com/jotson/godot-bunnymark cited by @Marqin
https://github.com/Marqin crashes when I use the Mingw 64-bit version.
It can go around ~6000 bunnies in without losing FPS with MSVC-compiled,
both 32- and 64-bits. With Mingw-compiled 32-bit I get slowdowns before
reaching 2000 bunnies.
@slapin https://github.com/slapin please enlighten us on how to add
optimization to Mingw build, because AFAIK it's already enabled
https://github.com/godotengine/godot/blob/e4765c4831e8249696ac3c94ca28da2218cb236c/platform/windows/detect.py#L338-L347
.
I wouldn't be surprised if Microsoft's compiler to its own platform is
more optimized than a port of GCC for Windows. But if there's a way to
optimize Mingw builds even further without breaking Godot I'm all open to
it.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-218864578

On my PC bunnymark shows 2K bunnies before slowdown, i7 2600K GTX660, Linux
and mingw32 build. So it is definitely broken, as on the same
PC AAA games work quite well on high settings. So to fix all Godot problems
we just need to drop Linux support and move to MSVC.
Any Mac testers here?
On Thu, May 12, 2016 at 10:58 PM, Sergey Lapin<EMAIL_ADDRESS>wrote:

MSVC can be faster but not 10 times faster. The result is not realistic.
Something is just plain broken.
On Thu, May 12, 2016 at 10:43 PM, George Marques<EMAIL_ADDRESS>
wrote:

It seems print does not work on release. But a project running only the
script runs noticeably faster with the MSVC-compiled version (I built both
my own at 48dc4d9
https://github.com/godotengine/godot/commit/48dc4d92a8f3c9eb42456eda2433c6fcaff0c723).
I'll try later with release_debug but without tools to check the prints.
The Bunnymark https://github.com/jotson/godot-bunnymark cited by
@Marqin https://github.com/Marqin crashes when I use the Mingw 64-bit
version. It can go around ~6000 bunnies in without losing FPS with
MSVC-compiled, both 32- and 64-bits. With Mingw-compiled 32-bit I get
slowdowns before reaching 2000 bunnies.
@slapin https://github.com/slapin please enlighten us on how to add
optimization to Mingw build, because AFAIK it's already enabled
https://github.com/godotengine/godot/blob/e4765c4831e8249696ac3c94ca28da2218cb236c/platform/windows/detect.py#L338-L347
.
I wouldn't be surprised if Microsoft's compiler to its own platform is
more optimized than a port of GCC for Windows. But if there's a way to
optimize Mingw builds even further without breaking Godot I'm all open to
it.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-218864578

Well, also keep in mind that travis uses mingw 4.2 from 2007 :P And MSCV used here is from 2015.

we just need to drop Linux support

WTF. What does Linux support have to do with Windows builds?

Bunnymark on Godot 2.0.2 official on my PC (i7 2600K GTX670, Windows 10 64bit) frame drop to 56 at 1640 object.
https://github.com/jotson/godot-bunnymark

@mefihl and for 2.0.3 https://github.com/GodotBuilder/godot-builds/releases/tag/2.0.3-stable ?

@mefihl and for 2.0.3 https://github.com/GodotBuilder/godot-builds/releases/tag/2.0.3-stable ?

Try http://downloads.tuxfamily.org/godotengine/2.0.3/ instead, I just deleted this tag and recreated it to push a hotfix to 2.0.3 ;)

Deleting tags in public repos is very, very bad idea.  When you do that a
new family of kitties is put in another sack for drowning.
You better create branches for all releases for hotfixing, and tag them
with additional tags if necessary. This is real practice.
On Fri, May 13, 2016 at 11:05 AM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

@mefihl https://github.com/mefihl and for 2.0.3
https://github.com/GodotBuilder/godot-builds/releases/tag/2.0.3-stable ?
Try http://downloads.tuxfamily.org/godotengine/2.0.3/ instead, I just
deleted this tag and recreated it to push a hotfix to 2.0.3 ;)
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-218977922

Yes and no. Deleting a tag for a release that has never been announced is not problematic, and way less clutter than having to issue a 2.0.3-1 or 2.0.4 to add a commit. If 2.0.3 had been published already, I would have done differently, but here, trust me, I know what I'm doing.

Well, only Linux and mingw depend on gcc, so dropping it will have problem
solved.
And no, that is not gcc 4.2 vs gcc-4.x or 6.x, the current Linux results
show the same problems as Windows-mingw results.
On Fri, May 13, 2016 at 2:06 AM, Hubert Jarosz<EMAIL_ADDRESS>wrote:

Well, also keep in mind that travis uses mingw 4.2 from 2007 :P And MSCV
used here is from 2015.
we just need to drop Linux support
WTF. What does Linux support have to do with Windows builds?
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-218910731

You better create the branches. You will thank me later for advising you
this.
Look at existing workflows from people who know shit, like Kernel people -
use stable branches for hotfixing.
This makes hotfixing a normal practice, not hacky workouts.
And you can use different tagging system - like tag 10.0 for release, and
for fixes use tag 10.0.1, 10.0.2, but tag only hotfixes in stable branches,
not master
Branches are cheap and powerful, use them. It quite looks like you don't
understand what tag is for and what branch is for,
On Fri, May 13, 2016 at 4:41 PM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

Yes and no. Deleting a tag for a release that has never been announced is
not problematic, and way less clutter than having to issue a 2.0.3-1 or
2.0.4 to add a commit. If 2.0.3 had been published already, I would have
done differently, but here, trust me, I know what I'm doing.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219046026

We're not dropping anything. End of the discussion.
Now if we want to investigate properly why we see such performance differences, that could be helpful. And if it's established that all GCC builds are less performant, and that it's not an optimization flag issue on our side, we could ask upstream directly.

This is not gcc problem either, it is either optimization problem or bad
code problem.
MSVC does a lot of tricks, so comparison of unoptimized builds of gcc vs
MSVC is useless. You can't tell MSVC to not optimize, while gcc
if asked to not optimize will prevent optimizations.
Otherwise comparison of tools-optimized (release_debug) adds only basic gcc
optimizations.
But relying only on compiler here is not really a good thing, as bad code
will give random results with different compilers. There looks to be
something
very badly written, which probably needed to pe optimized by brain, not
compiler.
On Fri, May 13, 2016 at 4:48 PM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

We're not dropping anything. End of the discussion.
Now if we want to investigate properly why we see such performance
differences, that could be helpful. And if it's established that all GCC
builds are less performant, and that it's not an optimization flag issue on
our side, we could ask upstream directly.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219047810

PRs welcome.

On Fri, May 13, 2016 at 4:48 PM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

We're not dropping anything. End of the discussion.

Also I think Godot needs to focus on engine features and publicity,
so dropping a few broken platforms will mean less bad reviews.
As I see no power to fix this all issues in any foreseeable future, I think
dropping is not
so bad option.

Now if we want to investigate properly why we see such performance
differences, that could be helpful. And if it's established that all GCC
builds are less performant, and that it's not an optimization flag issue on
our side, we could ask upstream directly.

Well, gcc is well established power, much more powerful than tiny godot.
Before blaming compiler, it is much better to run profilers on windows and
Linux and think.
But thinking is not an option.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219047810

As it seems we're really going to be constructive here, I think we can
safely close this as "GCC vs MSVC issue. Nobody knows and nobody cares".
will look good, and laso can be used
as "black hole bug" for other bugs like this in future.
On Fri, May 13, 2016 at 4:58 PM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

PRs welcome.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219050471

@slapin Thanks for your valuable input, we will pass than onto our Customer Support Team and they will come back to you once your request has been assessed.

I'm not sure since when.
As I remember, performance was fine with gcc compile until 2.0 first release.
But performance drop happened some days later.

Lets not turn this into flame war just out of everybody's lack of
commitment.
If you want to discuss this farther, feel free to ping me on IRC.
On Fri, May 13, 2016 at 5:03 PM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

@slapin https://github.com/slapin Thanks for your valuable input, we
will pass than onto our Customer Support Team and they will come back to
you once your request has been assessed.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219051813

@slapin: we can tell MSVC to not optimize: /Od https://msdn.microsoft.com/en-us/library/k1ack8f1(v=vs.120).aspx (and optimizations are off).
Comparing with optimizations on both sides sounds relevant.
@volzhs true. 2.0 and 2.1 have this difference, and both used GCC according to @akien-mga (way up in the thread).

If anybody here shares the automatic script which runs the GDScript test,
and tells me the commit ID when all worked fine. I can do bisect and find
offending commit
(or something relevant). Onless this happens I can't help with anything but
sarcasm.
On Fri, May 13, 2016 at 5:06 PM, Marc<EMAIL_ADDRESS>wrote:

@slapin https://github.com/slapin: we can tell MSVC to not optimize:
/Od https://msdn.microsoft.com/en-us/library/k1ack8f1(v=vs.120).aspx
(and optimizations are off).
Comparing with optimizations on both sides sounds relevant.
@volzhs https://github.com/volzhs true. 2.0 and 2.1 have this
difference, and both used GCC according to @akien-mga
https://github.com/akien-mga (way up in the thread).
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219052870

This is the same argument over and over, and you'll keep getting the same answers over and over.
I'm not against optimizing Godot. Myself and a lot of other contributors would gladly work on that.
But we need with benchmarks for this, and based on real use cases. We make Godot, we don't use it as much as you.
If the community can provide us with benchmarks, then we will do optimization work. Otherwise, be happy with what you have.
@slapin Would you kindly offer yourself to help create and admin a set of benchmarks so we can test optimizations and regressions?

We could create a repository in godotengine github for benchmarks, then you guys can contribute what you have or future benchmark tools there.

In this bug I see a lot of mentions of existing script. I want this.
On Fri, May 13, 2016 at 5:12 PM, Juan Linietsky<EMAIL_ADDRESS>wrote:

We could create a repository in godotengine github for benchmarks, then
you guys can contribute what you have or future benchmark tools there.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219054319

Here there are again:
Bunnymark: https://github.com/jotson/godot-bunnymark
Micro-tests: https://github.com/Zylann/gdscript_performance
Both GDScript.

In this bug I see a lot of mentions of existing script. I want this.

Seriously?

Regarding create an official repo for benchmarks, that's a good idea. But honestly for this very issue (#4313) it's not a matter of benchmark Godot or GDScript to improve bottlenecks.
There is obviously something fishy when one compiler provides 10 times more performance than an other. And most likely, this issue is located in the SConscript file, where some optimisation flags are passed to one compiler and not to the other.
So to properly debug this specific issue, we should just build Windows binaries of a given Godot commit with the exact same parameters (tools and target), using MSVC, MinGW and Clang, and try e.g. @Zylann's tests and Bunnymark with all three versions. Maybe do that also for release_debug vs debug for the tools, or release vs release_debug for the templates, and see if there's a difference at this level.

Thanks a lot! Will setup something shortly. I need terminal-level script to
automate bisecting.
bunnymark is graphical, so not so good for automatic testing, will try
gdscript_performance.
On Fri, May 13, 2016 at 5:18 PM, Marc<EMAIL_ADDRESS>wrote:

Here there are again:
Bunnymark: https://github.com/jotson/godot-bunnymark
Micro-tests: https://github.com/Zylann/gdscript_performance
Both GDScript.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219056276

I'd agree to maintain Godot tests repo, hoping it would not contain only
benchmarks, but also API tests.
On Fri, May 13, 2016 at 5:32 PM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

Regarding create an official repo for benchmarks, that's a good idea. But
honestly for this very issue (#4313
https://github.com/godotengine/godot/issues/4313) it's not a matter of
benchmark Godot or GDScript to improve bottlenecks.
There is obviously something fishy when one compiler provides 10 times
more performance than an other. And most likely, this issue is located in
the SConscript file, where some optimisation flags are passed to one
compiler and not to the other.
So to properly debug this specific issue, we should just build Windows
binaries of a given Godot commit with the exact same parameters (tools
and target), using MSVC, MinGW and Clang, and try e.g. @Zylann
https://github.com/Zylann's tests and Bunnymark with all three
versions. Maybe do that also for release_debug vs debug for the tools, or
release vs release_debug for the templates, and see if there's a
difference at this level.
—
You are receiving this because you were mentioned.

On Fri, May 13, 2016 at 5:27 PM, Rémi Verschelde<EMAIL_ADDRESS>wrote:

In this bug I see a lot of mentions of existing script. I want this.
Seriously?

Don't be like this. Supplying direct links would do much better for your
karma.

—
You are receiving this because you were mentioned.

Sorry, but your attitude shows only lazyness, since you had not given the effort to read the thread (or so it seems, otherwise you'd have seen the links already).  It doesn't work like this. We're accepting your help if you're actually willing to help.

@reduz, please block this conversation to prevent more offtopic spam. We just need some proof to see that using MSVC helped for optimization. And then consider this bug closed.

Well, it looks that we have +1 lazy people in this thread. Welcome to the
club.
Sometimes it is easier to see stuff in single list than searching scattered
emails for
something. I just hate to search things. Also, I try to be productive here.
And what is so bad about being lazy? It is not that I ask just out of being
an ass,
I really going to work on it.

Sorry, but your attitude shows only lazyness, since you had not given the
effort to read the thread (or so it seems, otherwise you'd have seen the
links already).  It doesn't
work like this. We're accepting your help if you're actually willing to
help.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219066549

@Marqin Bunnymark on Godot 2.0.3 official on my PC (i7 2600K GTX670, Windows 10 64bit) frame drop to 57 at 6540 object after export to exe in release mode. Nice boost from 2.0.2 ;)

@mefihl msvc or gcc?

So we have 4x better performance on your PC with bunnymark with 2.0.3, wow.

@mattiascibien 2.0.3 download from official website.

@mefihl MSVC so... Thanks

For the record, I ran my test on Linux (same machine with dual boot, Godot with tools). In short, results are similar to what I get with msvc on Windows. So there is definitely something weird with MinGW, Linux is all fine :)
Official 2.0.3:
Empty func (void function call cost): 56
Increment: 38
Increment x5: 196
Increment with member var: 39
Increment with local (outside loop): 35
Increment with local (inside loop): 54
Increment Vector2: 26
Increment Vector3: 47
Increment Vector3 with constant: 47
Increment Vector3 coordinate by coordinate: 848
Unused local (declaration cost): 7
Divide: 62
Increment with dictionary member: 133
Increment with array member: 59
While time (for equivalent with manual increment): 77
if(true) time: 15
if(true)else time: 6
VariantArray resize: 745
VariantArray set element: 14
IntArray resize: 370
IntArray set element: 154

Custom build (gcc):
Empty func (void function call cost): 247
Increment: 59
Increment x5: 296
Increment with member var: 68
Increment with local (outside loop): 54
Increment with local (inside loop): 92
Increment Vector2: 77
Increment Vector3: 65
Increment Vector3 with constant: 69
Increment Vector3 coordinate by coordinate: 2600
Unused local (declaration cost): 11
Divide: 82
Increment with dictionary member: 408
Increment with array member: 108
While time (for equivalent with manual increment): 170
if(true) time: 27
if(true)else time: 17
VariantArray resize: 9101
VariantArray set element: 41
IntArray resize: 3524
IntArray set element: 379

Nice :) Was that debug or release_debug?

Thinking about tests page template.
=== Godot performace (smaller is better)

tools           MSVC  MinGW  Clang

@Zylann's
  debug
  release_debug
  release
Bunnymark
  debug
  release_debug
  release

target          MSVC  MinGW  Clang

@Zylann's
  debug
  release_debug
  release
Bunnymark
  debug
  release_debug
  release

1. https://github.com/jotson/godot-bunnymark
2. https://github.com/Zylann/gdscript_performance

Tools and debug, release_debug [explained] (http://docs.godotengine.org/en/latest/reference/introduction_to_the_buildsystem.html#tools).
Why tools (editor) affects performance?

The custom build is the result of scons platform=11 out of the box. Is it debug or release_debug?
Other news: the PC on which I did my tests until now has a core i5. I'm relocating, so I built the same way on another Windows 10 PC, a recent laptop with a core i7. But... I get bad results again, with any Godot version, official or self-built Oo"
Empty func (void function call cost): 330
Increment: 351
Increment x5: 1976
Increment with member var: 355
Increment with local (outside loop): 350
Increment with local (inside loop): 485
Increment Vector2: 355
Increment Vector3: 355
Increment Vector3 with constant: 356
Increment Vector3 coordinate by coordinate: 4534
Unused local (declaration cost): 88
Divide: 374
Increment with dictionary member: 1047
Increment with array member: 681
While time (for equivalent with manual increment): 780
if(true) time: 37
if(true)else time: 45
VariantArray resize: 1231
VariantArray set element: 219
IntArray resize: 1756
IntArray set element: 1056

Maybe that's just because the laptop is slower. But it has core i7... it's better than i5, right? :s

I made a tests repository in godot organization, please let's put all
benchmark code there :)
On Sun, May 15, 2016 at 12:15 PM, Marc<EMAIL_ADDRESS>wrote:

The custom build is the result of scons platform=11 out of the box. Is it
debug or release_debug?
Other news: the PC on which I did my tests until now has a core i5. I'm
relocating, so I built the same way on another Windows 10 PC, a recent
laptop with a core i7. But... I get bad results again, with any Godot
version, official or self-built Oo"
Empty func (void function call cost): 330
Increment: 351
Increment x5: 1976
Increment with member var: 355
Increment with local (outside loop): 350
Increment with local (inside loop): 485
Increment Vector2: 355
Increment Vector3: 355
Increment Vector3 with constant: 356
Increment Vector3 coordinate by coordinate: 4534
Unused local (declaration cost): 88
Divide: 374
Increment with dictionary member: 1047
Increment with array member: 681
While time (for equivalent with manual increment): 780
if(true) time: 37
if(true)else time: 45
VariantArray resize: 1231
VariantArray set element: 219
IntArray resize: 1756
IntArray set element: 1056
Maybe that's just because the laptop is slower. But it has core i7... it's
better than i5, right? :s
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4313#issuecomment-219291504

The custom Linux build is the result of scons platform=11 out of the box. Is it debug or release_debug?

The defaults are tools=yes target=debug

Why tools (editor) affects performance?

Not sure on that, but I guess it's because there's some extra steps to work with the debugger.

@reduz I made a pull request to the godot-tests repo to add my GDScript benchmark.

https://github.com/godotengine/godot-tests

I really love how @Marqin and @vnen  contributed nothing to this issue except asking reduz to ban trolls. When slapin does have a bad attitude, at least he's trying to help with the "issue".
Anyways, with that said:
You guys worry far too much about these performance issues. The amount of time that is spent worrying over petty, negligible performance improvements from gdscript could be better spent on actual game development.
See here for more information:
http://wiki.c2.com/?PrematureOptimization

Bumping a year-old thread about a "non-issue" is certainly the most productive way to spend the time.

Bumping a year-old thread about a "non-issue" is certainly the most productive way to spend the time.

actually, you don't really have room to talk, sir:
https://github.com/godotengine/godot/issues/4313#issuecomment-219066549
i've been seeing you around here for years always nagging at that someone that has a "snotty attitude". you love to complain just as much as me.

i really love how @Marqin and @vnen contributed nothing to this issue except asking reduz to ban trolls.

There's been a heated discussion here but, as far as I can read, no one asked banning anyone.

I reported the troll account. He's probably will get banned.

@neikeq well, from what I got from this post:
https://github.com/godotengine/godot/issues/4313#issuecomment-219072067
he's asking to block this conversation (block them from posting here), which is essentially banning them from participating. that's how i saw it anyway. but you're right it wasn't a direct "ask to ban them", but more of "stop letting them post". and honestly, glad that reduz didn't.  especially when slapin was willing to help.
that's the problem here with you guys. if anyone here says anything remotely different (slapin suggesting branches) the community goes nuts against them calling them trolls, etc.
Akien told him to stop and he did. slapin still wanted to help but then everyone pounces on him telling he has a "bad attitude, etc". which is just silly. you guys honestly need to stop worrying about peoples attitude and focus on point the person makes in their post. their attitude is irrelevant to the bug/issue.

@MakeGodotGreatAgain so this is nothing -https://github.com/GodotBuilder/godot-builds/pull/1 ?
Please, read all of my comments, not only last one...

Remember that free software development is meritocratic. Check the contributions @vnen has made to this project, check the ones you did, and then check who has "room to talk here".
Anyway, closing this issue and locking the discussion as it should have been done a year ago.

And regarding the initial topic, the issue is clear. Binaries compiled with a recent MSVC (2015), like our current 2.1.x official Windows binaries, are way more efficient than binaries cross-compiled with a 8 years old GCC version on Ubuntu 12.04 (like our early 2.0.x binaries).


Updates to exploredb functions

The exploredb functions only use execute while other functions use run_sql_query, which allows for ODBC or LibPQ as execution. I have also found they occasionally run into errors because of this difference.
I think it is also worthwhile to improve how run_sql_query works to make it automatically adjust types if possible (for dates, times, etc.)

Codecov Report

Merging #8 (cd1d590) into master (2f662e7) will decrease coverage by 0.79%.
The diff coverage is 50.60%.

@@            Coverage Diff             @@
##           master       #8      +/-   ##
==========================================
- Coverage   73.85%   73.06%   -0.80%
==========================================
  Files          14       13       -1
  Lines         899      954      +55
==========================================
+ Hits          664      697      +33
- Misses        235      257      +22

Impacted Files
Coverage Δ

src/exploreDB.jl
0.00% <0.00%> (ø)

src/utils.jl
74.50% <62.68%> (-6.22%)
:arrow_down:

src/utils/identifierTypes.jl
43.58% <0.00%> (-0.86%)
:arrow_down:

src/utils/timelineDataCache.jl
66.66% <0.00%> (-0.63%)
:arrow_down:

src/WRDSMerger.jl

Continue to review full report at Codecov.

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

@tylerjthomas9 I would love to get your view on the changes I made here. I ran into an error when running the get_table function since the obs keyword arg defaults to missing (so that one needed to change), but I thought through some other changes to make. Most notably, it now uses the run_sql_query that is used throughout the rest of the package, and that function now tries to interpret types to make later use better.
I don't think any of the changes I made would actually change any results, but would appreciate any thoughts.

I think these changes look great. Oversight on my part for the obs keyword defaulting to missing. I think having everything go through run_sql_query makes the package a lot cleaner. Great work


unavailable achivement

PLEASE DELETE unavailable achivement
PLEASEEEEEEEEEEEEEEEEEEEE

Duplicate #485 #487 #488 #491 #493 #497 #498 #500 #504 #513 #517 #532 #537


Always run as Administrator

Currently, to run windows terminal in Administration mode I have to find the app > remember to right click on it  > select more > and run as administrator.
The problem with this is that I have almost never a reason to not run it in admin mode and its getting frustrating to run some script find out that its not running with elevated privilege's close the program run through the above mentioned flow and start the entire script(s) over.
So far, I have not found a way to run this app by default with admin rights nor do I see anything online to that effect.

Thanks for the suggestion! Please make sure to search for duplicates when filing new issues. This is already being tracked by another issue on our repo - please refer to #632, #5000, #8455 for more discussion.
/dup #632

Thanks for the suggestion! Please make sure to search for duplicates when filing new issues. This is already being tracked by another issue on our repo - please refer to #632, #5000, #8455 for more discussion.
/dup #632


MultiPartParser cannot be moved

Describe the bug
MultiPartParser has an internal map that contains a copy of the request body's parsed parts. Issue is it can't be moved via std::move, it gets copied regardless.
This causes out of scope issues when writing code like this:
#include "drogon/drogon.h"
#include "trantor/utils/ConcurrentTaskQueue.h"
#include <string_view>
#include <thread>

using namespace drogon;
using std::string_view;

static trantor::ConcurrentTaskQueue q(std::thread::hardware_concurrency(), "");

int main()
{
	app()
		.addListener("<IP_ADDRESS>", 8080)
		.registerHandler("/api/test", [](const HttpRequestPtr& req, std::function<void (const HttpResponsePtr&)>&& cb)
		{
			MultiPartParser parser;
			if(parser.parse(req) == -1)
			{
				cb(HttpResponse::newHttpResponse(drogon::k400BadRequest, drogon::CT_NONE));
				return;
			}

			const auto& params = parser.getParameters();
			const auto end = params.end();

			const auto nameFind = params.find("name");
			if(nameFind == end)
			{
				cb(HttpResponse::newHttpResponse(drogon::k400BadRequest, drogon::CT_NONE));
				return;
			}

			q.runTaskInQueue(
			[
				req = std::move(req),
				cb = std::move(cb),
				parser = std::move(parser),
				name1 = string_view(nameFind->second)
			]()
			{
				// Do a database operation, or some other I/O here
				const auto& params = parser.getParameters();
				const auto end = params.end();

				const auto nameFind = params.find("name");
				if(nameFind == end)
				{
					cb(HttpResponse::newHttpResponse(drogon::k400BadRequest, drogon::CT_NONE));
					return;
				}

				string_view name2 = nameFind->second;

				std::cout << (void*)name1.data() << " -- " << (void*)name2.data() << '\n'; // Prints two different addresses, name1 being out of scope and potentially corrupted

				cb(HttpResponse::newHttpResponse());
			});
		},
		{
			HttpMethod::Post,
		})
		.run();
}

To Reproduce
Steps to reproduce the behavior:

Use the above code to spin up a server.
Make a POST request to /api/test with one parameter name = <anything>
You'll see two different addresses printed in the console (e.g. 0x7fb4e4004808 -- 0x7fb4e4004a18)

Expected behavior
Two options:

MultiPartParser must have a move constructor.
Or it must have another parse function that populates the map using string_view only, both as key and value. This way it points to the request body's content and we don't do any copying.

Desktop:

OS: Ubuntu

Oh yeah I forgot this is not a Drogon issue, it's lambda shenanigans.
I'll keep this open until I find a solution, and put FAQ on it in case anybody writes code like this.

Turns out this is a string SSO issue and probably the class is partly to blame too?
I did tests where a string is constructed before a lambda like this:
string s = "abc";
// pass by move into lambda

And due to SSO the string gets copied.
Now when we do this:
string s;
s.reserve(100);
s = "abc";
// pass by move into lambda

It gets moved as expected and no copies are made, hence all string_views pointing to it are still valid.
Now when doing this in Drogon, it gets copied regardless of the FormData element lengths.

@an-tao why don't we opt for using std::string_view in the internal map? I know in one of the previous commits the HttpRequestPtr was stripped out of the MultiPartParser class, but we can bring it back and use string_views inside of the map instead.

Ok fixed it, we need these two lines added to MultiPartParser and then everything will move and no copies will be made:
MultiPartParser(const MultiPartParser& other) = default;
MultiPartParser(MultiPartParser&& other) = default;

On my way to make a PR


adfs/services/trust/2005/usernamemixed endpoint

I am trying to get a SAML Assertion from Azure AD using the adfs/services/trust/2005/usernamemixed endpoint.
According to this article in ADFS what was https://myadfs/adfs/services/trust/2005/usernamemixed is AD as https://sts.windows.net/TenantId/2005/usernamemixed.
However, I cannot call that endpoint or find any documentation for it. Is this true? How do you get a SAML Assertion?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3eefa519-e92e-3317-f13f-2d69bda4a79f
Version Independent ID: cea848ab-9a8f-ccfa-d10f-2794bd06989e
Content: Move apps from AD FS to Azure AD.
Content Source: articles/active-directory/manage-apps/migrate-adfs-apps-to-azure.md
Service: active-directory
Sub-service: app-mgmt
GitHub Login: @msmimart
Microsoft Alias: mimart

@keithdv , Thanks for raising the issue.We will investigate the issue and update you.

@keithdv Not all endpoints similar to ADFS are available in Azure AD. The adfs/services/trust/2005/usernamemixed endpoint was only present in Azure . There is no such endpoint available in Azure as far as I know. Usernamemixed endpont in ADFS was used mainly for SOAP based legacy requests. And that's why you are not able to find any related documentation as well. I am checking more internally and If I find anything more , I will update this thread.
Thank you.

@keithdv Azure AD does not implement everything exactly similar to ADFS . Even though most of the functionality s same but not all and this is one of them. Azure AD encourages application developers to use modern authentication and usernamemixed endpoint is not available in this case. We will now close this issue. In case you have any further queries , please tag me or the author of this document to your reply and we will be happy to help .


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

Codecov Report

Merging #565 (989c491) into main (8002bb7) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #565   +/-   ##
=======================================
  Coverage   95.69%   95.69%
=======================================
  Files           1        1
  Lines         395      395
  Branches       53       53
=======================================
  Hits          378      378
  Misses         17       17

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Patch VS Code to wait for storage write

Confirmed that it fixes https://github.com/rust-analyzer/rust-analyzer/issues/5892 (reported in https://github.com/cdr/code-server/issues/2021).

It looks like my version of git outputs index hashes that are 10 characters in length while the last patch generator's version used 11 characters. As far as I can tell this isn't configurable yet (it will be in the next version).
But I'm thinking we should modify the patch script to use --full-index, then no matter what version of git you use the hashes will be the same length.

I removed the extraneous hash updates. :smile:

But I'm thinking we should modify the patch script to use --full-index, then no matter what version of git you use the hashes will be the same length.

Sounds good, go ahead and do that!

In a separate commit of course.


[oracle-jdk] Refactor script

Make the script more readable, mostly by:

using the Product class,
removing the use of functions when unnecessary,
a little bit of renaming and documentation.

No version update as expected, merging.


Create MergeKSortedLists.java

Issue Id you have worked upon -
#138
Briefly explain your program logic -
Approach: We use the logic behind merging two sorted lists to merge k number of lists in sorted order.
Here two lists are taken at a time and merged. The process is repeated until the last one list in the array.
Screenshots(Attach 2 screenshots of your own input and output) -

Checklist:
Eg - If your code follow the below guidelines. Kindly change [] to [x]
All the conditions should be fulfilled for considering your code for merging -
[x] I have mentioned the question as comment in my solution file.
[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code.
[x] My code gives the correct output.
[x] I confirm that I have not copied the code from anywhere. In case its found that I have copied I can be banned from the repository.
[x] I affirm that I strictly follow contributing guidelines and code of conduct.

@niranjana687,
Kindly comment your code well.

@SarthakKeshari I have updated with detailed comments.


Allow passing of constructor arguments

<x:Arguments>
    <ListViewCachingStrategy>RecycleElement</ListViewCachingStrategy>
</x:Arguments>

I'm thinking something like this:
MyControl {
  arguments [
    ListViewCachingStrategy { ... }
  ]
}

Looks pretty intuitive to me, should the A in arguments be capped?

All of the current keywords start with the lower-case letter. I think it would be better to continue this way.

I've uploaded fixed version to MyGet, please try if it works for you.
http://www.ammyui.com/documentation/prerelease-builds/
Thanks!

Awesome, works great! Thank you so much.


Avoid RuntimeInformation on full sln parse

We started (transitively) requiring
System.Runtime.InteropServices.RuntimeInformation when using
SolutionFile.Parse after #2963. The assembly-level dependency is
longstanding. But since it wasn't needed in NuGet's calling pattern,
many versions of NuGet are broken on older (pre-4.7.1) .NET Frameworks.
Work around the assembly load by avoiding the adjustment filepath on
full-Framework MSBuild (where it's not necessary anyway).
Closes #3282.

Approved for VS servicing and .NET Core SDK 2.1.300.


Edit Service Learning Course duplicates data

In the edit Service Learning Course proposal interface, if somebody submits edits, waits until the page refreshes, then goes back to the previous page, clicks on the previous button, and submits again will cause for data to be duplicated in the database, primarily entries in the courseinstructor table. This issue needs some more investigating to prevent the data duplication.

PR merged closing issue


Proxy not working

Proxies are not working for me for some reason.
Here's my parameters:
var api = {
      port: 3000,
      proxies: [{
        source: '/api',
        target: 'http://localhost:8080/api'
      }]
};

XMLHttpRequest cannot load http://localhost:8080/api/test. No 'Access-Control-Allow-Origin'...

Try adding the Access-Control-Allow-Origin header under options > headers

Proxies are not working for me as well. The CORS header should not be needed since the server is the one making the cross origin request through the proxy.


Cannot set property 'visible' of undefined

Describe the bug
Cannot set property 'visible' of undefined
Not much else to tell about this
To Reproduce
Unknown. Looks to be happening when turns are cycled?
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
Uncaught (in promise) TypeError: Cannot set property 'visible' of undefined
    at Function.AddTurnMaker (nextUp.js:492)
    at handleCombatUpdate (nextUp.js:296)
    at Function._call (eval at <anonymous> (listeners.js:56), <anonymous>:4:14)
    at Function.callAll (foundry.js:153)
    at ClientDatabaseBackend.callback (foundry.js:8880)
    at foundry.js:8819
    at Array.map (<anonymous>)
    at ClientDatabaseBackend._handleUpdateDocuments (foundry.js:8819)
    at f.<anonymous> (foundry.js:8458)
    at f.r.emit (index.js:145)

Environment:

OS: Win10
Browser Chrome
Foundry Version 0.8.8
Module Version 0.1.05
All Modules Disabled: No
Module List if no: 60 some, none related to this error as far as I can tell

Additional context
...

This means that one of your combatants didn't get the marker created. Are you using temporary combatants from CUB or anything like that?
A refresh should fix the issue as long as each combatant has a token

No temporary combatants. Refresh probably fixes it, but it keeps happening. Some of the combatants with the marker may have been deleted during combat, not sure, I wasn't the GM.

I found the issue. Fix going out soon


Make python errors more legible

When a python algorithm throws an error, it is often cryptic. E.g.:

Runtime Error: QuantConnect.Scheduling.ScheduledEventException: Python.Runtime.PythonException: KeyError : u'the label [SVXY] is not in the [index]'

We could make it more legible:

In one of your Scheduled Events, the key you're looking up does not exist in this collection ([SVXY]). To see more information about this error please see: https://www.quantconnect.com/docs#Common-Errors-Key-Error -- Original error: KeyError : u'the label [SVXY] is not in the [index]

Closed by #1659.


*: Fix set cancel test tsan.

What problem does this PR solve?
Issue Number: close #xxx
Problem Summary:
What is changed and how it works?
Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-sanitizer-test tsan

/run-all-tests

/run-sanitizer-test tsan

Here is the test result. https://ci.pingcap.net/blue/organizations/jenkins/tiflash-sanitizer-daily/detail/tiflash-sanitizer-daily/519/pipeline

/run-sanitizer-test tsan

Here is the test result. https://ci.pingcap.net/blue/organizations/jenkins/tiflash-sanitizer-daily/detail/tiflash-sanitizer-daily/519/pipeline

Find more race. PTAL @breezewish

/run-all-tests

/run-integration-tests

/run-sanitizer-test tsan

/run-sanitizer-test tsan

/build

/run-all-tests

/run-sanitizer-test tsan

/run-sanitizer-test tsan

https://ci.pingcap.net/blue/organizations/jenkins/tiflash-sanitizer-daily/detail/tiflash-sanitizer-daily/536/pipeline/

@ywqzzy @SeaRise can we get this pr merged?

@ywqzzy @SeaRise can we get this pr merged?

Still need to verify if it actually works...

/run-sanitizer-test tsan

/run-sanitizer-test tsan

https://ci.pingcap.net/blue/organizations/jenkins/tiflash-sanitizer-daily/detail/tiflash-sanitizer-daily/553/pipeline

/run-sanitizer-test tsan

https://ci.pingcap.net/blue/organizations/jenkins/tiflash-sanitizer-daily/detail/tiflash-sanitizer-daily/553/pipeline

seems to work

/run-integration-test

/run-all-tests


Feature request: descriptive page titles

As it is right now, all pages are titled "Construct Hub", making it hard to navigate the browsing history.
Having more descriptive page titles would help with this a lot.

Closing as this is a duplicate of https://github.com/cdklabs/construct-hub-webapp/issues/368. I've opened a PR (https://github.com/cdklabs/construct-hub-webapp/pull/392) that will address this 🙂


[Feature]: add all the resources for competitive programming in it's page and all introduction of cp platforms and remove link from cards

Is your feature request related to a problem? Please describe.
No response
Describe the solution you'd like
No response
Describe alternatives you've considered
No response
Additional context
No response

you can assign me.

check and update.


Possible performance regression in TrimFastq

Running in the same dataset (although not the same system) TrimFastq version v.0.1.4.r_3293bb31 took around 30s per 1M reads; on the other hand, version v.0.1.4.r_3293bb31 is taking 300s.
I should test it properly and check that is not a system issue.

It seems that commits from one version to the other does not change any important class for TrimFastq, so probably is a system thing.


Feature/transition solver API

PR Type
Closes #581 #265 #102

Feature
Refactoring
Documentation content changes
Tests

Description
Transitions the codebase over to the new solver API.
Removes the performance tests in favour of JIT compilation success checks in test_kernels.py and test_solver.py. Detailed rationale can be found in the commit messages. Basic logic is to defer the "performance" checks to benchmarking and the JIT-ability to testing (this markedly simplifies the removal process as the performance tests don't require changing).
How Has This Been Tested?
All tests pass.
Does this PR introduce a breaking change?
Removal of refine:

The solvers now provide access to the refinement procedures. The random and reverse variants can be obtained by randomly partitioning the coresubsets and applying refinement to these reduced random sets and reversing the data respectively.

Removal of reduction:

All functionality provided by reduction is now handled by the solvers.
Except MapReduce which has been removed due to its JIT incompatible recursive design. (This/similar approaches can be re-introduced in a future pull) EDIT: a simple solution was found here by using padding and recursing based on a traceable value (an array shape).

Removal of couplings to coreset data-structures

coreset.compute_metric: retained
coreset.solve_weights: retained
coreset.render: no replacement planned
coreset.format: no replacement planned
coreset.copy_fit_shallow: Redundant due to use of frozen dataclasses
coreset.validate_fitted: a coreset datastructure is always considered as 'fitted'

Removal of DataReaders in favour of the new Data classes

ArrayData and DataReader classes are gone

Checklist before requesting a review

[x] I have made sure that my PR is not a duplicate.
[x] My code follows the style guidelines of this project.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have performed a self-review of my code.
[x] I have made corresponding changes to the documentation.
[x] My changes generate no new warnings.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] New and existing unit tests pass locally with my changes.
[x] Any dependent changes have been merged and published in downstream modules.

Changelog needs updating


BASICO missing binding for Hybrid Runge Kutta method

See basico.task_timecourse.__method_name_to_type():
Bindings exist for both Hybrid LSODA and RK45, but not Hybrid Runge Kutta.

I've release version 0.50, that adds the hybrid shorthand to indicate use of the hybrid runge kutta method. Thanks for letting me know.


refactor: merge JWTPath and credential fetcher

Currently we have two ways to fetch credentials:

JWTPath, which reads from a jwt token file
CredentialFetcher, which is a generic interface to fetch credentials

This makes reading from a jwt token file a CredentialFetcher,
simplifying the code a bit
Please provide a description of this PR:

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
f3dca0f6518da22d716749747951338c37159987
link
true
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
5d71082f1ed2289e7bd4fbfc8e80b31dee00ec01
link
true
/test lint_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

lint_istio
5d71082f1ed2289e7bd4fbfc8e80b31dee00ec01
link
true
/test lint_istio

unit-tests_istio
5d71082f1ed2289e7bd4fbfc8e80b31dee00ec01
link
true
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


graph visualisers

I saw this in the google presentation.
What do you have in mind
I am into parametric control systems and can see sparkle being useful for a host of vertical spaces.

Hi Ged, I think there are many potential uses for sparkle! The use that originally inspired me was dashboards for performance analytics.


undertale-mod-tool: Scoop file permission bug?

"Access Denied"  (only happens when I install via scoop)

Does this occur if you use the Start Menu to start UndertaleModTool instead of a command prompt?

Yes, I can't open it anyway.


DCOS-42385: chore(npm): Replace npm-shrinkwrap with package-lock.json

Tradeoffs
It turns out there was very little reason to switch. Both npm-shrinkwrap and package-lock.json are kept up to date when running npm install --save
However, this change may make things slightly simpler if the change to fsevents is no longer needed... but at the expense of being different in 1.10, 1.11. We may not want to merge this.
Closes DCOS-42385

I also think that there is little sense in switching. Should we still host a decision meeting, @brandonc ?


thumbnail.exists() is too slow when using S3 as a backend storage

clearly, it's more a django-storages issues than a sorl issue, but in my case, when using S3 as a backend, it took about 60 secons to run thumbnail.exists() so I've removed the check and made the assumption that if the thumbnail does not exist in the cache it does not exist on the disk either. Now it runs under 1 second.

There is a possible solution been discuss in #351, to recap this issue is not about sorl-thumbnail itself is about slow storage backends implementations.


Moved Popover to /Popup

Project URL

https://github.com/corin8823/Popover
Category

/Popup
Description

Popover is a balloon library like Facebook app. It is written in pure swift.

          1 Warning

:warning:
Found 1 link issue, a project collaborator will take care of these, thanks :)

Link issue by awesome_bot

Line
Status
Link

2876
302
http://www.ios-blog.co.uk/ redirects tohttp://www.ios-blog.co.uk/cgi-sys/suspendedpage.cgi

  Generated by :no_entry_sign: Danger


isGetter doesn't actually validate getters

I'd expect isGetter to assert that a getter is valid (e.g. composed only of strings, optionally a trailing function, or other getters).  Instead, it tests that an array ends in a function.
Valid getters that fail this test
["path"]

Invalid getters that pass
[1, true, null, () => ({})]

A more robust test
function isGetter(value) {
  return isArray(value) && value.every(
    (item, i) =>    isString(item)
                 || (i === value.length - 1 && isFunction(item))
                 || isGetter(item)
  );
}

It passes all the current getter tests.

:+1: on this. Early on I was doing some pseudo-type checking on getters using isGetter, but decided to drop that approach because I didn't find it reliable enough.

Sure I can implement this to be a true isGetter check.
I was hesitant to do it at first since its a potentially expensive operation that will happen recursively.
@colindresj if you are planning to add these checks to your code I would wrap them in a flag that removes them in production code

I can open a PR if you like.  I hesitated because I didn't know if changing isGetter to be more complicated would be discouraged for perf reasons.

Definitely @jordangarcia. I think this kind of approach is useful in dev, where you don't care about perf.
In the future, I actually think Nuclear should automatically turn this (and other dev-only helpers) off when in production, kind of like React does with PropTypes, et al. That means updating how Nuclear config is currently handled though, so definitely a different issue entirely, and for now devs should take care of this themselves.

@colindresj yeah its something i've been thinking about
as to having a nuclear.js or nuclear-debug.js be the version with the __DEV__ flag on and also having invariant checks like isGetter.
I like the idea of keeping the dispatch logs in the code as something that can be configured when you instantiate a Reactor.  At optimizely we have a flag that turns debugging on in production which has been immensely helpful when debugging issues that have already made it to prod.
I want to think about this a bit more before we decide anything.  I am currently leaning towards adding more invariant checks and then having the minified version remove them.
Also: the way npm's package.json main works is to point at the unminified version of Nuclear.  I'd like to be able to allow people to use npm but get a version of Nuclear without the invariants.  Anyone have ideas?

@jordangarcia I think React has one version for npm, but has a const (NODE_ENV === "production") that determines whether or not the tests run.  They presume that if you care about perf, you'll run it through Webpack and Uglify, which will strip the unreachable blocks.

In addition, React has a set of npm-specific grunt tasks for building the unminified main file with the conditional checks that @appsforartists mentioned, as well as a dist folder which includes minified files for React, addons, etc. I really like the approach, because you can build the library agnostic of where it'll be hosted, then have specific tasks for publishing it to NPM, etc.
The directory that eventually hits NPM is here: https://github.com/facebook/react/tree/master/npm-react
And the tasks for generating the files that get put in the directory are here: https://github.com/facebook/react/blob/master/grunt/tasks/npm-react.js
There's a release task that eventually publishes React everywhere it needs to: https://github.com/facebook/react/blob/master/grunt/tasks/release.js

I am a bit uncomfortable adding this stricter validation without having a good way to remove it, and that will require rethinking the __DEV__ approach.
Punting this to 1.1.x

I think that makes sense. I'd like to have I strong isGetter method, but think a strong approach to dev builds is even more important.
On Thu, Jun 4, 2015 at 1:42 PM, Jordan Garcia<EMAIL_ADDRESS>wrote:

I am a bit uncomfortable adding this stricter validation without having a good way to remove it, and that will require rethinking the __DEV__ approach.
Punting this to 1.1.x
Reply to this email directly or view it on GitHub:
https://github.com/optimizely/nuclear-js/issues/59#issuecomment-108987943


JWT Improvements

@lordofthejars Can you verify the following improvement that I've made?
It reduces some keycloak configuration steps by importing a pre-defined istio-realm.json file.
I've also improved the overall process to get and use the token and open keycloak console

@lordofthejars Can you check it before modifying #154 ? It might help to rewrite the formular to get the valid token.

@rafabene Yes, but in which sense it helps on the token you need to login as well, isn't it?

@lordofthejars It just makes it easier to copy and paste.

Yes copy paste the population of data, but not the generation of the token right? So RBAC section can be merged since we are only talking about the generation of the token.

@rafabene I have reviewed but not executed and yes it is a really nice addition if you tried and feel that executing myself too is not necessary, merge it, no problem, it is really cool PR.


No such file or directory - /platform-tools/adb

Dryrun exception:
Searching for devices...
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open3.rb:211:in `spawn': No such file or directory - /platform-tools/adb (Errno::ENOENT)
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open3.rb:211:in `popen_run'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open3.rb:99:in `popen3'
	from /Library/Ruby/Gems/2.0.0/gems/dryrun-0.9.0/lib/dryrun/dryrun_utils.rb:54:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/dryrun-0.9.0/lib/dryrun/dryrun_utils.rb:46:in `run_adb'
	from /Library/Ruby/Gems/2.0.0/gems/dryrun-0.9.0/lib/dryrun.rb:108:in `pick_device'
	from /Library/Ruby/Gems/2.0.0/gems/dryrun-0.9.0/lib/dryrun.rb:168:in `call'
	from /Library/Ruby/Gems/2.0.0/gems/dryrun-0.9.0/bin/dryrun:6:in `<top (required)>'
	from /usr/local/bin/dryrun:23:in `load'
	from /usr/local/bin/dryrun:23:in `<main>'

I do have $ANDROID_HOME set and ADB is working from the terminal
❯ echo $ANDROID_HOME
/Users/matias/Library/Android/sdk

~
❯ adb devices
List of devices attached
emulator-5554	device

~/Library/Android/sdk
❯ cd $ANDROID_HOME/platform-tools

~/Library/Android/sdk/platform-tools
❯ ls
NOTICE.txt        api               etc1tool          hprof-conv        package.xml       sqlite3
adb               dmtracedump       fastboot          lib               source.properties systrace

I ended up manually modifying the dryrun.rb file and hardcoding my $ANDROID_HOME path. Now it's compiling everything and working fine, which wouldn't be the case if $ANDROID_HOME wasn't exported properly (gradle would complain about not being able to find the env variable), so there's an obvious bug in the way you are getting the $ANDROID_HOME environment variable.

I believe the problem is that you don't have the platform-tools path

export PATH=$PATH:/Users/cesarferreira/Library/Android/sdk/platform-tools/platform-tools
export PATH=$PATH:/Users/cesarferreira/Library/Android/sdk/platform-tools/tools

Do you have this in your ~/.zshrc ?
export PATH=$PATH:/Users/cesarferreira/Library/Android/sdk/platform-tools/platform-tools
export PATH=$PATH:/Users/cesarferreira/Library/Android/sdk/platform-tools/tools

also check #84

I needed to make adb global:
❯ echo 'export ANDROID_HOME=/Users/$USER/Library/Android/sdk' >> ~/.bash_profile
~
❯ echo 'export PATH=${PATH}:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools' >> ~/.bash_profile
~
❯ source ~/.bash_profile


Features request: Could you add support to use something like skypack or jsdevil?

I like trying to create webpage on Android and can't build or use node. It would be nice if I was able to use and have instructions on using jsdevil or another cdn when it not possible to build. Currently at least this two cdn don't work (for me) or I could not get them to work by following skypack instruction they gave an error and when I researched the error it said it was often do to circular dependency. I tried many deferent version.I couldn't git anything to work. I looked at your package.json and there are dependency I can't get with skypack. Currently I am not that good of a javascript to fix this error on my own.

Hi @frog-o, thanks for opening an issue.
For your use case, I suggest bundling (Esbuild is a good bundler).
While you may not be able to use Node or NPM in production, using some package manager compatible with the package.json (or using something like import maps) in development is a must.
I haven't used the tools/runtimes/libraries you mentioned, so I can't offer any help with them.
I don't think there are any problems with ZenFS, so I'm going to close this issue. Please reach out if you find any bugs with ZenFS.
Thanks.

@james-pre
just for your info, I am familiar with devmap and esbuild (I think I prefer tsx which uses esbuild in the background but that really not an option for new  Android Wich I am running), All most all options are lost when you don't have a build system or a console.  I found a solution though esm.sh works at this moment.  I think you're getting a little confused jsdevil and skypack are not library and neither is ESM.sh( Wich I found today Which is meant for dino , dino I believe was made by the same guy as node but was trying to fix some of what he felt was designed flaws and is a node rewrite take this just hear say thou  I am going by my memory Wich might be wrong. It  from something I read long ago and I have bad comprehension). Skypack and all the ones I mentioned allow you to run npm without you having to have node installed and it does all the polyfil and tree shrink and All that.  To me this makes a lot more sense then use npm unless you're using pnpm or fancy yarn settings or something funky like that you still have to have it downloaded for each web project you make. I like the thought of letting someone else do the tree shaking for you with there more power full server not like that matter though after first build it is cached.
If you don't mind I ask you to try esm.sh out.  I know everything boils down to preference I just find it hard to believe people prefer to use complicated builds and just want to make sure you didn't miss understand me. I am horrible about my communication and jsdevil is not a library at least I don't think so.

I've used esm.sh in the past, and I've seen it work very well for other use cases.
In any case, ZenFS is a library, and being compatible with every bundler and/or package manager is not feasible. If the bundler or package manager your using does not support ZenFS fully, you may want to open issue on that project. I'm happy to help you with any issues with ZenFS.
Please let me know what errors you are given, I might be able to do something to help.

I've used esm.sh in the past, and I've seen it work very well for other use cases.
In any case, ZenFS is a library, and being compatible with every bundler and/or package manager is not feasible. If the bundler or package manager your using does not support ZenFS fully,

Thanks that is all I asked for, I don't think you should worry about being compatible with ever builder .    I just need one since I found esm.sh  that's good enough for me.I think it would be a shame if you don't try to support 1 of the( bundler that I mentioned)  wich  should in theory work for all since it really doesn't really need a bundler. It looks like at this moment (even though I have not got around to test it much) everything is working with esm.sh and all that needs is to make sure it keeps working and add instructions for it to your page.  Just another note it hard to copy and paste on Android (yes android is not a good platform to do programming but it is the only thing I feel comfortable using) that the reason I didn't put the error.  There is no point to it if you have no plans to fix ( don't  get me wrong) you have every right to do so . No one should have to work for free . If was me though, I would want to try to address the most usage cases I could that didn't require a lot of work That the reason I put things online.I want to help as many people as I can.

I get what you're saying, though writing documentation for CDNs isn't very productive. If I wrote documentation for esm.sh, then I would also need to include documentation for all of the other CDNs: JSDelivr, Unpkg, cdnjs, and Skypack just to name a few. Moreover, documentation for using a CDN isn't really needed due to how easy most are to use.
If you encounter a problem with a CDN, it is up to them to fix. ZenFS isn't the problem in this case, there is nothing I can do to fix someone else's CDN. If you do find a problem with ZenFS, I'll do my best to fix it.


slurm: <IP_ADDRESS> -> <IP_ADDRESS>

Description of changes
Changelog: https://github.com/SchedMD/slurm/blob/slurm-23.02/NEWS

Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg test slurm


Font settings don't work as they are supposed to.

updating editor font setting updates the whole UI, including the menus, edit and preview modes. On other themes choosing different fonts for edit and preview modes work as expected.

This should now be addressed in Version 1.2.0.

This should now be addressed in Version 1.2.0.


Car: Different max speed for inner and outer city

Currenty max speed relies on the maxspeed tag in the city or village and often streets do not have such a tag. We need to grab the boundaries of the city and take this into account.
This issue is related to #75 and #175
Possible improvements afterwards:

Route through Prague should be 20 minutes not 16
Laval, France should be 20 not 15 minutes and using one of the northern motorways not the southern (as first suggestion)
Mettmann Germany should avoid the inner city and slightly slower (not 8min but more like 10min)
Bayreuth, Germany should use the nordring (as first suggestion) and avoid the inner city, also not 5min but more like 10
Paris oh, not through Paris! And not 33min but more like 40-45min (at least)
London Time is 20 but should be more like 40min (but here going through the city is similar slow ;))
London should be more like 10-15 minutes not 6
why is the time difference so big here? (9min vs. 6min)

(These numbers and 'real routes' are from mostly customers&user reports and own experiences)

I currently work on this, but I guess city boundaries are not an aedequate solution.
One might could use ´´´traffic_sign = city_limit´´´, but it seems that this tag is frequently not set.
For this reason I propose right now, to use the landuse tag and take ´´´residential´´´ and ´´´commercial´´´ areas as areas with reduced speed limit.

Hi-
we have worked on this for our MindYourSpeed app (see
http://www.volzinnovation.de/MindYourSpeed/). The approach that we took was
a preprocessing step at the OSM data level. We split streets and tagged
them accordingly based on their containment within a city boundary.
It is a time consuming task.
The automated assignment of speed limits took into account the various
legal requirements of permissible max speeds per way type based on the
legal requirements in each country
(we only worked with data for Switzerland, Austria, France, Netherlands,
Germany).
The preprocessing took about 1 day per 200 MB of OSM data...
Best regards,
Raphael
On 18 February 2015 at 13:59, jansoe<EMAIL_ADDRESS>wrote:

I currently work on this, but I guess city boundaries are not an aedequate
solution.
One might could use ´´´traffic_sign = city_limit´´´, but it seems that
this tag is frequently not set.
For this reason I propose right now, to use the landuse tag and take
´´´residential´´´ and ´´´commercial´´´ areas as areas with reduced speed
limit.
--
Reply to this email directly or view it on GitHub
https://github.com/graphhopper/graphhopper/issues/230#issuecomment-74859731
.

--
--
"All ideas are good ones as long as you don't think about them."
( Michael Cembalest )
--
Prof. Dr. Raphael Volz
Vorsitzender des Aufsichtsrats
chairman of the board
Volz Innovation GmbH
Kirchhaldenweg 10, 76597 Loffenau, Germany
Web: www.volzinnovation.com
Phone: +49 7083 9328338
Fax: +49 7083 9328337
Company Seat / Sitz der Gesellschaft: Loffenau
Company Register / Handelsregisternummer: HRB 704418, Amtsgericht Mannheim
Managing Director / Geschäftsführer: Dr. Sara Brockmans
Chairperson of the Supervisory Board / Vorsitzender des Aufsichtsrats:
Prof. Dr. Raphael Volz

what do you use as boundary? I think administrative boundaries are too loose (e.g. http://www.openstreetmap.org/relation/66527#map=13/51.2105/7.0547)?
Is it also landuse=residential (http://www.openstreetmap.org/relation/1537220#map=14/51.1898/7.0176)?

Hi,
we used landuse=residential
http://taginfo.openstreetmap.org/keys/landuse#values
as well as other landuse way tags (industrial, commercial, retail, quarry,
village_green, etc.), but they get more and more sparse.
So residential, industrial, commercial and retail capture the most
We only assigned values, if there was no maxspeed tag originally in the
data. We considered both relations and ways and created new way ids for the
splitted ways.
Best regards,
Raphael
On 18 February 2015 at 15:17, jansoe<EMAIL_ADDRESS>wrote:

what do you use as boundary? I think administrative boundaries are too
loose (e.g.
http://www.openstreetmap.org/relation/66527#map=13/51.2105/7.0547)?
Is it also landuse=residential (
http://www.openstreetmap.org/relation/1537220#map=14/51.1898/7.0176)?
--
Reply to this email directly or view it on GitHub
https://github.com/graphhopper/graphhopper/issues/230#issuecomment-74870043
.

--
--
"All ideas are good ones as long as you don't think about them."
( Michael Cembalest )
--
Prof. Dr. Raphael Volz
Vorsitzender des Aufsichtsrats
chairman of the board
Volz Innovation GmbH
Kirchhaldenweg 10, 76597 Loffenau, Germany
Web: www.volzinnovation.com
Phone: +49 7083 9328338
Fax: +49 7083 9328337
Company Seat / Sitz der Gesellschaft: Loffenau
Company Register / Handelsregisternummer: HRB 704418, Amtsgericht Mannheim
Managing Director / Geschäftsführer: Dr. Sara Brockmans
Chairperson of the Supervisory Board / Vorsitzender des Aufsichtsrats:
Prof. Dr. Raphael Volz

Thanx Raphael for your input.
My approach is very similar, but to speed computation up I will assign speed limits not exactly on point but within a pixel raster. Do you have an estimate how well landuse boundarys correspond to city_limit areas?

Some comments on this:
It would be good to develop a general solution. Assigning a speed value within city boundaries is only one application. Other (currently unresolved) use cases are:

marking all ways inside an area as unaccessible, e.g. in a military restricted area
applying rules to all ways inside a natural reserve area
applying legal restrictions to all ways inside woods (there are such laws in some German states)

Putting this into a preprocessing step feels like a good idea to me. So it does not weigh down the regular import and may be executed on a different machine. I assume the memory requirements are stiff. Are your solutions based on a database?
A spontaneous idea for optimization is merging the various polygons into a single area first, then matching the ways against the smaller number of merged areas.
bye, Nop

Yes, other usecase could be prefer ways for bikes in a forest etc. But a generic solution will follow. This is tricky on its own, so making it generic from the start is overkill. As always: step by step :)

I assume the memory requirements are stiff

For worldwide we expect roughly 10% more RAM.

A spontaneous idea for optimization is merging the various polygons into a single area first

A similar approach will be used (a 'simple' grid assigning boolean values)

Are your solutions based on a database?

No. GraphHopper will not depend on an external thing to administrate. An internal java based database might be used for the import though. See #220

It would be good to develop a general solution
it's right now a simple solution, but with future generalization in mind. i hope it's ready beginning of next week for evaluation.

Currenty max speed relies on the maxspeed tag in the city or village and often streets do not have such a tag

My investigations suggest, that it is not missing maxspeed tags which cause counter intuitive routes, but rather the assumption that both small and larger roads with the same maxspeed also result in the same average speed, neglecting prioritised traffic flow on larger roads.
Therefore in this branch I apply the following heuristic to estimate average travel velocity: the travel speed of ways within defined areas (e.g. residential, commercial, retail) is reduced by different factors on primary, secondary, tertiary roads.
In my opininon this leads to more intuitive roads
old:

new:

old:

new:

You mean that these improvements are possible without the difference of inner and outer city?

No, I mean it is not sufficient to adjust values where the maxspeed tag is missing, but also to adjust maxspeed values "within" a city by a factor depending on the highway level

Thanks for clarification & nice! I'll play with it tomorrow!

All in all this increases travel time by about 10%.
In my opinion this still does not reflect true travel times, but in a second step one might take turn cost and traffic lights into consideration.
(see #334, #75)
I think an optimal solution would take real world travel times into account and would adjust the heuristic to reflect them. But for this one would need an extensive dataset of such travel data. Anyone aware of this?

This branch now only assigns speed values to streets within citys where the maxspeed tag is missing. But this has only a minor effect on traveltimes. Also, the approach to use landuse = residential | industrial | retail to detect city regions, seems to be a bit problematic, because there are citys (e.g. madrid) where large areas are not tagged. (Although for germany it seems OK).
In general this code allows to apply region specific speed limits. So one might could reuse this code to implement country specific speed limits (#175) or for other cases.

@jansoe: Your above referenced branch tree/CitySpeedMerge returns a now "404 Not found". I wanted to take a look on what you did in this branch. Could you provide this work again?

@ratrun @jansoe the branch would be helpful for me too :)

@ratrun  @karussell
sorry for the delayed reaction time, but now the branch is again online. don't hesitate to ask questions, if anything seems unclear

@karussell apologies for nudging an old issue. Is there some guidance or direction (perhaps elsewhere) that you could share for options to help with routing and the associated duration calculations within urban centers? We're finding that we get a lot of routes traversing through urban centers with lots of traffic lights where it's very unlikely that the maxspeed on those ways will be accurate for an average speed approximation when compared to the maxspeed for nearby motorway routing options.

See also the recent discussion in #2395. This should be a foundation to improve the ETAs and avoiding city centers.


Branch 171718021

cc @alextp @case540
https://github.com/tensorflow/tensorflow/pull/13606 had a build issue, this PR should fix it.


Rust exeception raised when transpiling PaulEvolutionGate with measurements against backend

Environment

Qiskit version: 1.3.1
Python version:
Operating system: linux

What is happening?

backend = provider.backend('ibm_nazca')

hamiltonian = SparsePauliOp.from_list([('IXX', 1), ('IYY', 1), ('IZZ', 1),
                                       ('XXI', 1), ('YYI', 1), ('ZZI', 1)])

N = 8
qc = QuantumCircuit(3)
# Initial state 110
qc.x([1, 2])
op = PauliEvolutionGate(hamiltonian, time=1)
qc.append(op.power(N), [0,1,2])
qc.measure_all()

transpile(qc, backend)

gives
thread '' panicked at crates/circuit/src/interner.rs:147:14:
the caller is responsible for only using interner keys from the correct interner
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
PanicException: the caller is responsible for only using interner keys from the correct interner
How can we reproduce the issue?
run above
What should happen?
it should work.  It does if I first compile against no backend, and then use those circuits as input to the backend transpile
Any suggestions?
No clue

This is caused by an issue in the UnitarySynthesis for 3+ qubit blocks (when calling op.power you convert the PauliEvo gate into a UnitaryGate), which is fixed by #13591.
Out of interest: Are you using power to repeat the circuit here or are you interested in the unitary of that power? I'm asking because power converts the gate to a matrix and then computes the matrix power. To repeat the gate object, you can use op.repeat(N).

I am interested in applying the gate multiple times, which is what I expect the power op to do.  There is no mention of any implementation difference between power and repeat, so an user is most likely unaware of the points you mention.

Gate.power:

Raise this gate to the power of exponent.
Implemented either as a unitary gate (ref. UnitaryGate) or as an annotated operation (ref. AnnotatedOperation).

Gate.repeat:

Creates an instruction with self repeated :math:n times.

Do you have suggestions for how we could make this implementation difference clear for you?

Perhaps explicitly mention the power method is numerical and thus only works for small numbers of qubits, and then point users to the repeat method in the docstring for power?
Could also do a similar cross-reference for the repeat docstrings.


Write converters and ext code for rolereactions

Here is the work I have done on rolereactions.
I ideally would like to convert more of my messages to errors in the future.
Hopefully the damage isn't too bad 😔.

adc6704cb85bc6fe34e255d16aea5934a66bade3


WIP: testing new whitelist security functionality

https://jira.mesosphere.com/browse/QUALITY-1787

@falseperfection can we close this? Or, do you actually want to merge it?


In serial communication chapter, point to location of serial device f…

…or MacOS (info from https://makecode.microbit.org/device/serial).

r? @therealprof
(rust-highfive has picked a reviewer for you, use r? to override)


Validate zipfiles

This PR adds some infrastructure to validate the contents of zipfiles. It allows datasets to specify an expected layout of a zip file, and it will verify that the files exist and that they are valid based on their extension type. This PR also implements this new feature for FERC taxonomies, but all other resources still require implementations to use the validation.
As more validations are added, I think there are potential improvements to this interface, but I felt it would be best to keep it minimal until we better understand how we want to use it. Some improvements I can see include: allow specifying layout using patterns instead of identifying every individual file, validate files without requiring a layout.

@jdangerx I definitely agree that the previous version had some pretty janky logic. I ended going a slightly different direction to fix it though, and I just used the ValidationTestResult class for every individual check instead of accumulating a bunch of checks into a couple different tests. This simplifies the logic quite a bit, but it would mean that the RunSummary would be kinda cluttered with the results of all of those tests, so I also added the flag keep_when_success to each validation test, so for tests where this is false the summary will not include successful results, so the user doesn't have to comb through hundreds of checks telling them each individual file is not empty.
Let me know if this approach seems reasonable to you.


A few more tweaks for mobile.

Finished tests in 285.906801s, 4.1447 tests/s, 59.7362 assertions/s.

done,merged,pushed


Add hide button to context menu

Summary of changes
Adds the implementation for using the hide / unhide function to the context menu for external attributions.
Context and reason for change
The hide functionality was missing in the context menu for external attributions in the previous version of the context menu.
How can the changes be tested
Run the integration tests in package-card-context-menu.test.tsx and / or try it out in the app with example file.

Works nicely!
We could think of icons for hide and unhide :)
E.g.
import VisibilityOffIcon from '@mui/icons-material/VisibilityOff';
import VisibilityIcon from '@mui/icons-material/Visibility';

Attributions in folder content created from signals get hidden too: that should not happen.

This seems to be the normal hide logic at the moment, no conjunction with this branch.


mqtt: test mqtt frames v2

Ticket: https://redmine.openinfosecfoundation.org/issues/5731
Previous PR: #1064
Describe changes:

Add tests for mqtt frames

Requires: https://github.com/OISF/suricata/pull/8382

In light of the last discussions around truncated messages, I think it would be good to have a test with frames and those truncated types, so we could see what are the frames registering in such a case. :)

In light of the last discussions around truncated messages, I think it would be good to have a test with frames and those truncated types, so we could see what are the frames registering in such a case. :)

Ok I will incorporate this in a new SV PR and then you will re-run CI checks for this one?

In light of the last discussions around truncated messages, I think it would be good to have a test with frames and those truncated types, so we could see what are the frames registering in such a case. :)

Ok I will incorporate this in a new SV PR and then you will re-run CI checks for this one?

I think that can work. If not, we'd need a new Suricata PR.


Overflow button does not work with RTL mode

Originally reported at https://github.com/vaadin/vaadin-menu-bar/pull/103#issuecomment-613295981
Note, this might need refactoring that would be also potentially helpful for implementing #92

Related part:
https://github.com/vaadin/vaadin-menu-bar/blob/0a1ba952b4c9be0762e55880eab0b3ddb275a69a/src/vaadin-menu-bar-buttons-mixin.html#L91

Fixed by #106


chore(DTFS2-6666): remove filter vulnerabilities

Introduction :pencil2:
The keyword filter in portal shouldn't allow users to attack the database
Resolution :heavy_check_mark:

Use KEYWORD when sending a keyword filter to the api
Convert KEYWORD into the $regex operator, escaping any regex special characters

Note ⚠

This removes the ability to send a REGEX request to the api, this shouldn't be used anywhere but is potentially a breaking change

Codecov Report
Attention: 1 lines in your changes are missing coverage. Please review.

Comparison is base (6da84ce) 21.88% compared to head (206d68f) 22.40%.
Report is 140 commits behind head on main.

Files
Patch %
Lines

dtfs-central-api/src/drivers/db-client.js
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2461      +/-   ##
==========================================
+ Coverage   21.88%   22.40%   +0.51%
==========================================
  Files        1132     1134       +2
  Lines       27048    27166     +118
  Branches     4447     4461      +14
==========================================
+ Hits         5920     6086     +166
+ Misses      18403    18363      -40
+ Partials     2725     2717       -8

Flag
Coverage Δ

api-test
0.48% <ø> (ø)

ui-test
65.57% <ø> (+0.43%)
:arrow_up:

unit-test
4.30% <0.00%> (+0.51%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.