[5.2] Should Model::unguard()/reguard() still be called in DatabaseSeeder class?

I saw that in L 5.2 the calls to Model::unguard() and Model::reguard() were removed from the DatabaseSeeder class, but they are still mentioned in docs.

Thanks for the report. We're open to PRs to the docs. Since this not a bug in the framework, I'm going to close this.

I will asume the answer is no.


Solarize the gray tab bar

Hey,
I just switched from NeoSolarized to this theme to get support for nvim-treesitter in the colorscheme.
One thing that I directly noticed that I miss is to have the tab bar stylized in solarized colors.
In this theme the tab bar is gray:

However in NeoSolarized the tab bar looked more pleasing by applying the solarized colors to the tab bar as well:

It would be great to have a nicer tab bar! :)

You might want to check out bufferline.nvim.

@rbjorklin thanks for the tip. I've tried it out in the past and it wasn't for me ¯_(ツ)_/¯
I'd prefer this theme to apply the Solarized colors to the tab bar directly without the need for further plugins.


support logical sector size and PREMIUM_V2_LRS

Description
Customer request from MongoDB:

We are currently working on implementing support for Azure PV2 disks. We use the Java SDK and have found that we cannot set "logicalSectorSize" when provisioning a disk. We are also unable to set the desired "DiskSkuTypes.PREMIUM_V2_LRS". Both of these are available via the rest API, but we cannot find support for them in the latest (or any other version) of the Java SDK.

Please add an informative description that covers that changes made by the pull request and link all relevant issues.
If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
All SDK Contribution checklist:

[x] The pull request does not introduce [breaking changes]
[x] CHANGELOG is updated for new features, bug fixes or other significant changes.
[x] I have read the contribution guidelines.

General Guidelines and Best Practices

[x] Title of the pull request is clear and informative.
[x] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[x] Pull request includes test coverage for the included changes.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-resourcemanager-compute


Add a new "Session" Authentication type

Describe the Change
A new special "Session" authentication type should be added, where the authentication simply expects a Session to be present otherwise a 401, or redirect to login, is returned.
This will help with scenarios where you want either Form, or AzureAD, or Basic authentication - and the user can pick the one they want to use. In this scenario, you'd have 3 login routes that would trigger the appropriate authentication flow, and on success a valid Session will be set on the Request. The Routes can use the Session authentication to verify a valid session, since there's no way to check for either of the 3 above auth methods in an sensible manner - even with the new Merge-PodeAuth, because of OAuth2 redirecting.
My thinking is to just have a new Add-PodeSessionAuth (in Sessions.ps1). This will setup auth to check/grab the session from the pode.sid cookie/header, if it's not there return 401/redirect to login, and if it is present set the auth'd user object appropriately.
If sessions are in used, return a 401. If the session has not auth'd user return a 401 as well.

Changing to Add-PodeAuthSession, just so it's inline with Add-PodeAuthWindowsAd.


Improve opcode dispatch further by using a local curr_pc in executor

With #265 bytecode dispatch uses a cached thr->curr_pc pointer which is copied back into the topmost activation act->curr_pc whenever activation states may change or an up-to-date activation state is needed (e.g. for line numbers in the debugger).
This can probably be improved a bit further:

Use a local variable in the bytecode executor for curr_pc. Make that variable volatile so that it is always stored back into the stack frame after a dispatch.
Store a pointer to the stack frame location which holds curr_pc (i.e. a duk_instr_t ** with &curr_pc as its value) in thr->ptr_curr_pc.
Wherever thr->curr_pc was copied back into act->curr_pc after #265, copy the value from *thr->ptr_curr_pc instead.

This is faster because thr is sometimes spilled but the stack frame pointer is not.
Preliminary testing suggests this is roughly 5% faster than #265 (to be verified with more careful testing).
Changes:

[x] Main source changes to implement the change
[x] Perhaps simplify management of thr->ptr_curr_pc: bytecode executor can establish it, and restore it before exiting (it always has a setjmp catchpoint so it can do this reliably)
[x] Check volatile declarations
[x] Verify performance difference
[x] Update doc/execution.rst
[x] Testcases (apitest, qecmatest, test262)
[x] Test debugger manually

After #265 there seems to be a spurious compiler warning:
duk_js_call.c: In function ‘duk_handle_call’:
duk_js_call.c:835:15: warning: variable ‘entry_thr_curr_pc’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]

See if that can be fixed with this change too.

Quick test using a dispatch heavy test (LDCONST micro benchmark):
# Local curr_pc
$ sudo nice -20 python util/time_multi.py --count 10 --sleep 10 --mode all --verbose ./duk.O2.localpc tests/perf/test-const-load.js
Running: 5.430000 5.410000 5.780000 5.370000 5.480000 5.560000 5.450000 5.380000 5.390000 5.370000
min=5.37, max=5.78, avg=5.46, count=10: [5.43, 5.41, 5.78, 5.37, 5.48, 5.56, 5.45, 5.38, 5.39, 5.37]

# Master, including thr->curr_pc dispatch and local consts base pointer
$ sudo nice -20 python util/time_multi.py --count 10 --sleep 10 --mode all --verbose ./duk.O2.master tests/perf/test-const-load.js
Running: 6.430000 6.450000 6.440000 6.440000 6.420000 6.450000 6.410000 6.420000 7.190000 7.220000
min=6.41, max=7.22, avg=6.59, count=10: [6.43, 6.45, 6.44, 6.44, 6.42, 6.45, 6.41, 6.42, 7.19, 7.22]

Practical difference will be less, depending on how dispatch heavy the executed bytecode is.

Anything that does a lot of opcode dispatch compared to other execution - if a tight loop involves a regexp match for instance, the regexp performance will of course dominate.

I'll polish and merge this branch tomorrow. Performance work for 1.3 will then be finished, yay :-)

C declarations are weird:
cdecl> explain int * volatile * volatile curr_pc
declare curr_pc as volatile pointer to volatile pointer to int

I guess that's what happens when you're about half a step away from assembly.  There's potential for very weird fallout if something doesn't work right, so keep your eyes peeled :-)

I'll pull the latest master and try it out with minisphere.  If there are any issues I'll let you know!

Just got around to looking at the recent changes.  I must say this was quite clever:
duk_instr_t **ptr_curr_pc;

The duk_hthread holds a backpointer to the executor's local PC to avoid an extra level of syncing (which is what I thought this change was going to entail).
Only one thing worries me about this setup, and that's how it will scale to recursive executor calls (as would happen in the case of, e.g. JS -> C -> JS.

Well, no weird issues showed up in my (admittedly not very thorough) testing.  So it looks like this bit of black magic worked. ;-)

Each time the bytecode executor is called recursively the call handling will store and restore ptr_curr_pc so it should not be an issue. That's not to say I'm not a bit uncomfortable with "syncing back", but opcode dispatch is so central to performance that it seems justified.

I may have found a regression with this change, I have to do a bit more testing to see if I can reproduce it.

What was the outward effect?

The one thing I did notice was, for my pause-on-error change, when stopped at an error GetCallStack would sometimes report the wrong line number and PC (the beginning of a function instead of the correct place).

Things like that will be incorrect when a "sync" is missing (copying the local curr_pc to act->pc). I think I'll find this one simply by code reading.
But was this the regression you were referring to or was it something else?

I think there's at least a sync missing in the case where the bytecode executor triggers a side effect like a getter call. It won't cause any harm other than the act->pc being incorrect so tracebacks etc will look wrong.
I'll confirm and fix that shortly.

The specific scenario where I noticed this was where a Duktape/C function throws an error and the debugger pauses before longjmp, the reported PC for the ecma function directly below is incorrect

I can replicate this behavior by using a breakpoint in e.g. a getter function and resuming until the breakpoint is hit. It can't be reproduced by stepping because that will continuously sync the PC. That's why I missed this in my basic debugger test before merge.
Fix and bug testcase coming shortly. Thanks!

What's weird is that the "enter debugger now" helper I added for #286 already includes a sync before the interrupt, so I'm not actually sure why this happens.

The missing sync was for a non-ecma-to-ecma call, so that the PC of the calling activation would be outdated. The sync you added is for the current activation?

Ah, yes, that makes sense. :)

Ok, fix (and bug test) is in master, here's a snapshot: http://duktape.org/snapshots/duktape-1.2.99-20150826172312-v1.2.0-401-g8b5bcca.tar.xz

I have to go to work right now, but I'll test out the snapshot tonight and let you know.

Sure, no problem - I think the fix should work for at least that GetCallStack issue, but it's of course best if you can verify it.

The snapshot fixed the issue.  If you're curious, the specific issue I discovered turned out to have nothing to do with ecmascript-to-native calls, the bug was in new handling:
// line 1
(function() {
    print("The 8:12 pig was here!");
    function f() { print(Duktape.act(-3).lineNumber); }
    new f();  // prints 3, should print 5
})();

But whatever you did appears to have fixed this case too.

It was actually related: the fix was in handle_call() and new uses handle_call() even when calling an Ecmascript constructor.

Just triggered an assert that might be related to this (without assertions, this ends in a segfault):
PANIC 54: assertion failed: curr_pc < DUK_HCOMPILEDFUNCTION_GET_CODE_END(thr->heap, fun) (duk_js_executor.c:2266) (calling abort)

The value of curr_pc at the time according to MSVC:
curr_pc = 0x000000dfab127cb8 {4261281277}
This value is consistent from run to run.

Any idea what's going on when this happens?

Well, here's my native callstack for starters:
 	engine64.exe!issue_debug_notification(const wchar_t * const message) Line 125	C++
 	engine64.exe!__acrt_report_runtime_error(const wchar_t * message) Line 142	C++
 	engine64.exe!abort() Line 61	C++
 	engine64.exe!duk_default_panic_handler(int code, const char * msg) Line 127	C
>	engine64.exe!duk_js_execute_bytecode(duk_hthread * exec_thr) Line 2266	C
 	engine64.exe!duk_handle_call(duk_hthread * thr, int num_stack_args, unsigned int call_flags) Line 1496	C
 	engine64.exe!duk_call(duk_hthread * ctx, int nargs) Line 61	C
 	engine64.exe!run_script(script * script, bool allow_reentry) Line 189	C
 	engine64.exe!render_map() Line 1284	C
 	engine64.exe!js_RenderMap(duk_hthread * ctx) Line 2856	C
 	engine64.exe!duk_handle_call(duk_hthread * thr, int num_stack_args, unsigned int call_flags) Line 1383	C
 	engine64.exe!duk_js_execute_bytecode(duk_hthread * exec_thr) Line 3408	C
 	engine64.exe!duk_handle_call(duk_hthread * thr, int num_stack_args, unsigned int call_flags) Line 1496	C
 	engine64.exe!duk_call_method(duk_hthread * ctx, int nargs) Line 84	C
 	engine64.exe!duk_bi_function_prototype_apply(duk_hthread * ctx) Line 206	C
 	engine64.exe!duk_handle_call(duk_hthread * thr, int num_stack_args, unsigned int call_flags) Line 1383	C
 	engine64.exe!duk_js_execute_bytecode(duk_hthread * exec_thr) Line 3408	C
 	engine64.exe!duk_handle_call(duk_hthread * thr, int num_stack_args, unsigned int call_flags) Line 1496	C
 	engine64.exe!duk_call(duk_hthread * ctx, int nargs) Line 61	C
 	engine64.exe!run_script(script * script, bool allow_reentry) Line 189	C
 	engine64.exe!update_map_engine(bool is_main_loop) Line 1397	C
 	engine64.exe!js_MapEngine(duk_hthread * ctx) Line 1546	C
 	engine64.exe!duk_handle_call(duk_hthread * thr, int num_stack_args, unsigned int call_flags) Line 1383	C
 	engine64.exe!duk_js_execute_bytecode(duk_hthread * exec_thr) Line 3408	C
 	engine64.exe!duk_handle_call(duk_hthread * thr, int num_stack_args, unsigned int call_flags) Line 1496	C
 	engine64.exe!duk_pcall(duk_hthread * ctx, int nargs) Line 138	C
 	engine64.exe!main(int argc, char * * argv) Line 337	C
 	[External Code]

Hm, I wonder if I could use Duktape's JS debugger to narrow things down?  There are a few levels of native calls in there though that might make it more difficult, though... and that's assuming single-stepping doesn't mask the bug.

The most likely reason is that some PC sync operation uses an out-of-date thr->ptr_curr_pc somewhere. Just to narrow things down, do you use coroutines?

I think I'll make a small change where thr->ptr_curr_pc is set to NULL whenever any activation states change: otherwise a PC sync operation would copy the previous curr_pc value into another activation.

No coroutines, no.  But some weird corruption is definitely going on here.
Specifically, this comes up when starting the Spectacles battle engine (that being the game I wrote minisphere for).  The first battle I tested lead to the segfault and failed assert mentioned above.  I tried a different battle, and I'm SO glad I implemented pause-on-throw now... Duktape threw a nonsensical "invalid index" error (valid script filename but line number of 0), allowing me to view the Ecmascript callstack (which is quite deep!) and local variables.
With that information, I found the function responsible for the segfault:
	if (!this.isVisible && this.damages.length == 0 && this.healings.length == 0) {
		return;
	}
	this.sprite.blit(this.x, this.y, this.opacity * 255);
	for (var i = 0; i < this.damages.length; ++i) {
		var text = this.damages[i].text;
		var x = this.x + 16 - this.messageFont.getStringWidth(text) / 2;
		for (var i2 = 0; i2 < text.length; ++i2) {
			var yName = 'y' + i2.toString();
			var y = this.y + this.damages[i][yName];
			var color = this.damages[i].color !== null ? this.damages[i].color
				: CreateColor(255, 255, 255, 255);
			DrawTextEx(this.messageFont, x, y, text[i2], color, 1);
			x += this.messageFont.getStringWidth(text[i2]);
		}
	}
	for (var i = 0; i < this.healings.length; ++i) {
		var y = this.y + this.healings[i].y;
		var color = this.healings[i].color !== null ? this.healings[i].color : CreateColor(64, 255, 128, 255);
		var textColor = BlendColors(color, color);
		textColor.alpha *= this.healings[i].alpha / 255;
		DrawTextEx(this.messageFont, this.x + 16, y, this.healings[i].amount, textColor, 1, 'center');
	}

And the line which called it:
this.actors[type][i].render();

Worth noting is that the local variables are all listed as being set to undefined.  Which means the render() function probably didn't even start executing yet.

Forgive me if I seem a little overexcited here; I probably enjoy debugging more than would generally be considered healthy. :stuck_out_tongue_closed_eyes:

:-)

What I don't understand is why the value of the corrupt curr_pc isn't changing from run to run.  If it were using an outdated value (from a previous activation, say), the actual value should still change as memory allocation isn't exactly known for being deterministic, even with virtual addressing.  It looks more to me like curr_pc is being clobbered.

This debug log just before the assert error might help shed some light:
DUK_D(DUK_DPRINT("curr_pc=%p base=%p end=%p &curr_pc=%p thr->ptr_curr_pc=%p",
    (void *) curr_pc,
    (void *) DUK_HCOMPILEDFUNCTION_GET_CODE_BASE(thr->heap, fun),
    (void *) DUK_HCOMPILEDFUNCTION_GET_CODE_END(thr->heap, fun),
    (void *) &curr_pc,
    (void *) thr->ptr_curr_pc));

Okay, I'll add that debug print now.  By the way, the error is reproducible in a 32-bit x86 build as well, and will wonders never cease:
curr_pc = 0x0671d87c {4261281277}
Still the same!  Of course I realize now that the value in braces is the result of dereferencing the pointer, but still intriguing that it's the same value.

I'm trying to figure out what your game code does differently from the testcases: all testcases pass with assertions enabled. One difference is that your calling C side is obviously more complex than the "duk" command line tool, and that there are more Duktape/C functions involved.
I've added setting ptr_curr_pc to NULL whenever activations are changed (when doing call setup and when throwing errors). This is so that while the pointer itself may be valid, it's no longer related to the topmost activation's curr_pc pointer so syncing would be incorrect. I'm not sure if this is what's happening in your case; but here's a snapshot with the change: http://duktape.org/snapshots/duktape-1.2.99-20150827100951-v1.2.0-403-gf0535a3.tar.xz

That decimal value in hex is 0xfdfdfdfd by the way.

Lovely, that debug print generates so much output that the game never gets started because the console is bogged down printing stuff.

Got it, had to be clever with a conditional:
[D] duk_js_executor.c:2271 (unknown): curr_pc=00000094B45DE5B8 base=00000094B500
3298 end=00000094B50035BC &curr_pc=00000094B13E9F58 thr->ptr_curr_pc=00000094B13
E9F58

As for that 0xfdfdfdfd value, I found this bit of info:
"0xFD 	Fence Memory 	Also known as "no mans land." This is used to wrap the allocated memory (like surrounding it with fences) and is used to detect indexing arrays out of bounds."
Interesting.

Unfortunately it's 3:30am and I need some sleep, so further bug-hunting will have to wait. :)
Looking at that debug print though, it looks like the PC someone ended up just outside the bytecode.  Which is consistent with the "fence memory" thing.

No worries, I'll try to figure this out. Thanks for the help!

I think I'll add a thr->idx_curr_act to accompany thr->ptr_curr_pc which identifies the activation the ptr_curr_pc is related to. This makes syncing always correct even when there are activation changes, so it'll be much easier to get the syncing correct.

With the hint from apply() I found a code snippet which causes a valgrind detected error:
function f() {
    print('f');
    function g() {
        print('g');
        throw new Error('myerror');
    }
    g();
}

try {
    // Calling as f() does not trigger the error, but calling through
    // apply() does.  The internal difference is that apply() goes through
    // duk_handle_call().
    f.apply();
} catch (e) {
    print(e);
}

Ok, I think I found one error at least: the bytecode executor setjmp catchpoint would do a curr_pc sync which doesn't work if (1) there are multiple executor instances in the C call stack (apply does that above), (2) the error propagates from one executor setjmp catchpoint to the next without being caught in the middle. The outer setjmp catchpoint would then do a curr_pc sync which would reference the inner executor instance whose C stack frame is now invalid.
The cleanest approach is to sync curr_pc always before a throw (longjmp) and never in a setjmp catcher. I'll work up a fix to this effect and post a snapshot shortly.

Removed the curr_pc sync from the longjmp handler which fixes the bug testcase. Merged to master so should appear in the latest snapshots in about an hour.

Here's a snapshot from master including the (potential) fix: http://duktape.org//snapshots/duktape-1.2.99-20150827130003-v1.2.0-408-gd3abfae.tar.xz

Oh good, I'll test it out a bit later.
Funny you mention apply() though.... I believe there was an apply somewhere in the JS callstack that one time I got it to throw instead of segfaulting.

Nope, I still get the segfault in the exact same spot even with the snapshot.

Found the exact statement where the segfault happens:
this.sprite.blit(this.x, this.y, this.opacity * 255);

blit() is implemented on the native side.  For some reason execution of this statement sends curr_pc out of bounds...

I'm about to try something very unorthodox, stand by. :)

Okay, the bug appears to be in call return handling.  The engine segfaults when running this function:
	this.blit = function(x, y, alpha)
	{
		alpha = alpha !== void null ? alpha : 255;

		this.spriteset.images[this.spriteset.directions[this.directionID].frames[this.frameID].index]
			.blitMask(x + this.xOff, y + this.yOff, CreateColor(255, 255, 255, alpha));
		//print("*munch*");
	};

However, the function itself completes--the crash happens after the function returns but before the calling activation resumes.
Notice that commented-out print call I added?  Here's where things get weird: If I uncomment that, everything runs normally.

So is this blit a replacement for the native call (you said blit was implemented natively)?

No, it turns out the blit being called actually was this one, I had forgotten about my custom SpriteImage class.

Do you get the same error with this snapshot: http://duktape.org/snapshots/duktape-1.2.99-20150825070003-v1.2.0-382-g64560f8.tar.xz
(It has the thr->curr_pc dispatch which is similar but a bit slower.)

What about .blitMask(), is that a native call?

No crash with the snapshot.
.blitMask is native, yes.  And .blit() isn't on the callstack at the time of the crash.

Kind of hard to pinpoint the problem without a repro case, but what about this: http://duktape.org/snapshots/duktape-1.2.99-20150827185416-v1.2.0-408-gd3abfae-dirty.tar.xz

Best I can tell, curr_pc is being restored incorrectly during call return and being placed in no-man's-land.  I'm trying as hard as I can to reproduce it without minisphere-specifics, but not having much luck so far. :(

I think the difference between our environments is that my setup doesn't have "stack wiping" so that dangling references to unwound stack frames will luck out and work (really well in fact because all tests pass). I'll look up some stack debugging options to see if I can get similar behavior.

Anyway, that last snapshot is worth a try :)

It segfaults in a release build for me as well, so I think it's something a bit more insidious than a simple dangling pointer.  Anyway, I'll try the snapshot in a bit.

What compiler and options are you using BTW? I can try to reproduce this by running the tests on Windows instead.

Compiler is MSVC 2015.
Options are:
#define DUK_OPT_TARGET_INFO  ENGINE_NAME #define DUK_OPT_FASTINT #define DUK_OPT_DEBUGGER_SUPPORT #define DUK_OPT_INTERRUPT_COUNTER #define DUK_OPT_DEBUGGER_FWD_PRINTALERT
I can reproduce the crash without the debugger options too, though.

Ah, I meant the compiler options - optimization level, etc.

Oh.  I'm essentially using stock settings, the relevant customizations are:
Optimize for speed (/O2)
Static multithread CRT (/MT)

Still crashes with that last snapshot.

VS2013 x64 with /O2 and /MT seems to work fine, so I haven't been able to reproduce this so far.
I'll give this a little more time, but if there's no way to pin this down, I'll revert this and perhaps postpone it to 1.4.

Since I can reproduce this on command in the minisphere environment, I'll do a bit of stepping through Duktape and see if I can turn up anything.

Something interesting though: print() calls inside of .blit() don't get redirected to the debugger, but so show up in the console output.

Do you only get this error from .blit() by the way? What happens if you make .blitMask() (the C function) just return and do nothing? (It's unlikely this would be an application problem but, just to rule things out.)

Empty .blitMask() doesn't make a difference.  So something about the construction of the .blit() function is triggering a bug during call return (or even during the call, given the print() oddity), I just don't know what.
But yeah, calling .blit() is the only way I can reproduce it so far.  I've been trying all sorts of odd combinations of Ecmascript and C calls ever since to try to reproduce it in isolation, but nothing.  Next I will run the whole thing through Application Verifier (like valgrind but not as good) to see if I can pick up any memory-unsafe shenanigans.

This is the bytecode for .blit() BTW :-)
; c0 "spriteset"
; c1 "images"
; c2 "directions"
; c3 "directionID"
; c4 "frames"
; c5 "frameID"
; c6 "index"
; c7 "blitMask"
; c8 "xOff"
; c9 "yOff"
; c10 "CreateColor"

00000 000100f3   LDUNDEF    r4
00001 020080e8   SNEQ       r3, r2, r4
00002 0000c06d   IF         true, r3
00003 800000ae   JUMP       6 (+3)
00004 000080c0   LDREG      r3, r2
00005 8000006e   JUMP       7 (+2)
00006 803fc0c3   LDINT      r3, 255
00007 0000c080   LDREG      r2, r3
00008 0000c0b3   LDTHIS     r3
00009 8000c0d5   GETPROP    r3, r3, c0
00010 8080c0d5   GETPROP    r3, r3, c1
00011 000100b3   LDTHIS     r4
00012 80010115   GETPROP    r4, r4, c0
00013 81010115   GETPROP    r4, r4, c2
00014 000140b3   LDTHIS     r5
00015 81814155   GETPROP    r5, r5, c3
00016 02810115   GETPROP    r4, r4, r5
00017 82010115   GETPROP    r4, r4, c4
00018 000180b3   LDTHIS     r6
00019 82818195   GETPROP    r6, r6, c5
00020 03010115   GETPROP    r4, r4, r6
00021 83010115   GETPROP    r4, r4, c6
00022 0200c0d5   GETPROP    r3, r3, r4
00023 0000c1c0   LDREG      r7, r3
00024 0001c202   LDCONST    r8, c7
00025 0401c1d8   CSPROP     r7, r7, r8
00026 000240b3   LDTHIS     r9
00027 84024255   GETPROP    r9, r9, c8
00028 0480025a   ADD        r9, r0, r9
00029 000280b3   LDTHIS     r10
00030 84828295   GETPROP    r10, r10, c9
00031 0500429a   ADD        r10, r1, r10
00032 004282d2   CSVAR      r11, c10
00033 803fc343   LDINT      r13, 255
00034 803fc383   LDINT      r14, 255
00035 803fc3c3   LDINT      r15, 255
00036 00008400   LDREG      r16, r2
00037 0202c030   CALL       0x0, r11, 4
00038 0181c030   CALL       0x0, r7, 3
00039 0000006f   RETURN     0x1, r0          ; fast_return

Okay, I may have a lead: I attached the MSVC debugger to engine64.exe, performed a StepOver in Duktape on the .blit() call, and it generated a debug interrupt BEFORE .blit() returned.  Guess what?  curr_pc is already in no-man's-land at that point, which means issuing a Resume is going to segfault.

The segfault is indeed in return handling.  Unfortunately MSVC won't follow the longjmp for me to see exactly where it all goes wrong.

If blit() is called from Ecmascript code, what should happen is:

The RETURN opcode sets up the longjmp type as DUK_LJ_TYPE_RETURN, syncs curr_pc, and then longjmps.
The longjmp handler switches based on the longjmp type, detects that there's an Ecmascript caller and that we can reuse the executor C call. It then unwinds the stacks, reconfigures the value stack, and returns DUK__LONGJMP_RESTART which causes a goto reset_setjmp_catchpoint.
The reset_setjmp_catchpoint labels creates a new setjmp catchpoint, rechecks debugger state, and resets curr_pc before restarting execution.

What happens if you StepInto the .blit() function and then StepOver() there? Does the problem occur when you've executed al statements and are about to return?

The longjmp() you're trying to follow is most likely landing in the executor setjmp catchpoint, so maybe you could add a separate breakpoint there?

https://github.com/svaarala/duktape/blob/master/src/duk_js_executor.c#L2049

Yes, performing a StepOver at the end of the .blit() function causes the debugger to pause just before returning to the caller.  Performing another step (or resuming) asserts.
And yes, I did exactly that (the breakpoint on line 2049) . What I ascertained is that the previous activation (the one that called .blit()) is for some reason not being restored.  Duktape still believes it's executing .blit() (*(act->curr_pc) == 0x6f), and attempts to continue past the return, leading to a crash.

One thing to rule out might be ensuring this is not a setjmp related issue. That'd be ruled out if you changed:

https://github.com/svaarala/duktape/blob/master/src/duk_js_executor.c#L1978

to:
duk_instr_t * volatile curr_pc;

(Ignore the warnings related to casts.)
This shouldn't be an issue though: while the value of curr_pc is not guaranteed for the setjmp() catch path, we've synced the curr_pc before that and shouldn't actually be reading it in the catch path.

Yeah, making curr_pc volatile didn't help any.

Did you step through the longjmp handling? If the caller to .blit() is an Ecmascript call (and is handled normally using an Ecmascript-to-Ecmascript call), the expected path is roughly:

Detect longjmp type: https://github.com/svaarala/duktape/blob/master/src/duk_js_executor.c#L1109
Notice that we're returning to bytecode executor which reused its C stack frame: https://github.com/svaarala/duktape/blob/master/src/duk_js_executor.c#L1154
Unwinding is done, returning and restarting: https://github.com/svaarala/duktape/blob/master/src/duk_js_executor.c#L1176

At that last line thr->callstack_top should have been decremented by one compared to the second step (line 1154). The executor restart should then pick up executing the caller.

Okay, I found something suspicious:
thr->heap->call_recursion_depth = entry_call_recursion_depth;

This is the code path leading to the assert, and before the above line is executed:
thr->heap->call_recursion_depth = 1
entry_call_recursion_depth = 1

That doesn't seem right.

callstack_top indeed goes from 2 to 1 between the second and third steps.
So the return itself is fine, but the callstack is corrupt, because:
*(act->curr_pc - 2) = 181C030

Which is the opcode right before the return from .blit().

But has act been looked up again after the unwind? The executor should re-lookup act = thr->callstack + thr->callstack_top - 1 -- is this the act you refer to above?
I stubbed out stuff from your example: does this work for you as a standalone script?
function Image() {
}
Image.prototype.blitMask = function (x, y, color) {
    print('blitMask', x, y, color);
};
var myImage = new Image();

function CreateColor() { return 123; }

this.spriteset = {
    directions: [ { frames: [ { index: 0 } ] } ],
    images: [ myImage ],
};
this.directionID = 0;
this.frameID = 0;
this.xOff = 10;
this.yOff = 50;

this.blit = function(x, y, alpha)
    {
        alpha = alpha !== void null ? alpha : 255;

        this.spriteset.images[this.spriteset.directions[this.directionID].frames[this.frameID].index]
            .blitMask(x + this.xOff, y + this.yOff, CreateColor(255, 255, 255, alpha));
        //print("*munch*");
    };

this.blit(1,2,3);
print('done');

Oh btw, does any value in .blit() have a finalizer? :-)

The reason I ask is that the unwind handling may have side effects which causes side effects, including function calls, and the state may not be correct to do that because thr->ptr_curr_pc has not been NULLed. A function call will then sync the PC to the incorrect activation.
If this is what's happening, changing the end of the DUK_OP_RETURN handling to this should help:
duk_hthread_sync_currpc(thr);
thr->ptr_curr_pc = NULL;
duk_err_longjmp(thr);
DUK_UNREACHABLE();

A similar change will be needed in other code paths, but maybe if you try this we'd see if side effects during unwind are indeed the issue.

The Image objects which .blitMask() is called on have finalizers, but I don't see why they would be called, they are still reachable through the SpriteImage object.
Your stub code causes a DIFFERENT assert, and only with the Duktape debugger attached:
blitMask 11 52 123
done
PANIC 54: assertion failed: DUK_HOBJECT_HAS_COMPILEDFUNCTION((duk_hobject *) fun) (duk_js_executor.c:1729) (calling abort)

Nulling PC on return fixes real .blit(), your testcase still asserts as above though.

Ok, I think we're finally getting to the real cause here: side effects during unwinding can cause a function call to happen and if thr->ptr_curr_pc is set at that point, call handling will "sync pc" using that pointer and the topmost activation -- which may be incorrect. That's why the PC in the outer function was that of the inner function.
I had a temporary branch where I added an explicit callstack index to accompany the ptr_curr_pc so that the syncing would always go to the right activation; this would then work even with side effects. The other alternative is just to work through all the call paths and ensure every path uses a "sync-and-null".

So what's with that DUK_HOBJECT_HAS_COMPILEDFUNCTION() assert?  Same root cause?  The code you posted works fine standalone, but put a Duktape/C call after it and it asserts (but again, only with attached debugger).

I think I managed to create a test case to exercise the current problem:
function finalizer() {
    print('obj finalized');
}

function func() {
    var obj = {};
    Duktape.fin(obj, finalizer);

    print('returning');
}

function test() {
    func();
    func();
}

try {
    test();
} catch (e) {
    print(e.stack || e);
}

The unwind of func() causes the finalizer call, which then causes a break on the second func() call. This breaks for me too, and is fixed by the change to NULL the ptr_curr_pc.

Here's a snapshot with the ptr_curr_pc NULLing: http://duktape.org/snapshots/duktape-1.2.99-20150827221115-v1.2.0-408-gd3abfae-dirty.tar.xz

I'll try the snapshot tonight.  I'm glad the cause was found though, this was quite a puzzler and I have a splitting headache now. :)

Me too, thanks for being awesomely patient :-)

Here's the fix branch: https://github.com/svaarala/duktape/compare/fix-currpc-longjmp-sync
And here's a snapshot built from that: http://duktape.org/snapshots/duktape-1.2.99-20150828014009-v1.2.0-412-ga09c0da.tar.xz
If you could retest the debugger issue with this snapshot that'd be useful for figuring out the cause.
(I'm off to sleep soonish, it's been an interesting but exhausting bug huntery :-)

Tried both snapshots, both fix the original bug as well as the HAS_COMPILEDFUNCTION assertion, so apparently that was just a side-effect of the same bug.  So just to clarify, was it indeed the case that curr_pc was being synced to the wrong activation?

Does the fix affect performance at all, out of curiosity?

The changes are all related to figuring out where to (a) sync curr_pc back to act->curr_pc and (b) when to set/reset thr->ptr_curr_pc so everything works out correctly. None of these are on the opcode dispatch hot path so there should be no direct effect on performance of the hot path.

It's actually quite hard to get exact, useful performance results for opcode dispatch performance because it depends on such a lot of things. For example, an innocent change may have a +/- 5% impact with -O2, probably caused by things like register allocation / spilling decisions, code alignment, etc.
Anyway, the overall effect of bytecode executor changes between v1.2.3 and this fix branch is quite positive. For example, testing tests/perf/test-reg-load.js which is very dispatch heavy using:

clang -O3
DUK_OPT_FASTINT
no debugger/interrupt support

Has the results:
# Duktape v1.2.3
$ sudo nice -20 python util/time_multi.py --count 10 --mode all --sleep 5 --verbose ./duk.O3clang.123 tests/perf/test-reg-load.js
Running: 4.070000 4.060000 4.060000 4.060000 4.050000 4.050000 4.060000 4.070000 4.060000 4.060000
min=4.05, max=4.07, avg=4.06, count=10: [4.07, 4.06, 4.06, 4.06, 4.05, 4.05, 4.06, 4.07, 4.06, 4.06]

# This fix branch
$ sudo nice -20 python util/time_multi.py --count 10 --mode all --sleep 5 --verbose ./duk.O3clang.currpc tests/perf/test-reg-load.js
Running: 2.760000 3.020000 2.820000 2.970000 2.740000 2.760000 2.750000 2.820000 2.750000 2.750000
min=2.74, max=3.02, avg=2.81, count=10: [2.76, 3.02, 2.82, 2.97, 2.74, 2.76, 2.75, 2.82, 2.75, 2.75]

The minimum time is 4.05 seconds for Duktape v1.2.3 and 2.74 seconds for this branch, which is well in line for a ~25% dispatch improvement.

By the way, your code uses void null for undefined which is something I'll add to performance notes. Because undefined is not a literal it causes a GETVAR to be emitted, while void null (or void 1 etc) cause a LDUNDEF. You can see from the bytecode that nothing extra gets emitted which is nice :)

So long story short, Duktape 1.3.0 will be a very noticeable performance improvement over 1.2.x, very nice.
As for void null, that was actually code I wrote back when I was using the original Sphere, which used an ES3 engine (SpiderMonkey 1.5).  Since the value of undefined can be reassigned in ES3, void null was a way to ensure I got a real undefined back.  The fact that it represents a performance improvement is a nice bonus. :)

With the usual caveat that micro benchmarks don't represent application performance :)

Perhaps not, but I can say that I've seen a noticeable performance improvement in minisphere since I started using the latest masters.  My game starts up much faster than it used to of late. ;-)

So, how many bug testcases have been written as a result of this issue now?  I'm legitimately curious.

There were three actual bug testcases reproducing some aspects of the root cause, and one testcase for the stubbed out blit().

I think I figured out a torture test to shake out these side effect related bugs: do a dummy function call for every refzero queue free operation (simulating the case that every object has a finalizer). This should've exposed the finally-related finalizer issues too. I'll see about that in a few days when I've got some other things out of the way.

I'll close this issue now unless there's some fallout to work on. For new fallout it's probably best to open a separate issue as this is already quite long :)

Oh and that refzero torture issue is #304.


Windows support

C:\Users\Gary\AppData\Roaming\npm\node_modules\purs-tidy\output\Effect.Aff\foreign.js:532
                throw util.fromLeft(step);
                ^
internal/modules/cjs/loader.js:883
  throw err;
  ^

Error: Cannot find module 'C:UsersGaryAppDataRoaming
pm
ode_modulespurs-tidyoutputMainindex.js'
Require stack:
- W:\Projects\Test\[worker eval]
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:880:15)
    at Function.Module._load (internal/modules/cjs/loader.js:725:27)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at [worker eval]:1:1
    at Script.runInThisContext (vm.js:133:18)
    at Object.runInThisContext (vm.js:310:38)
    at internal/process/execution.js:77:19
    at [worker eval]-wrapper:6:22
    at evalScript (internal/process/execution.js:76:60) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [ 'W:\\Projects\\Test\\[worker eval]' ]
}

😆
(I'll take a look at fixing this)

Oh no! I wonder if this is an issue with node-workerbees.

https://github.com/natefaubion/purescript-node-workerbees/blob/d8eb29e0eee087c3d136b3b961074c8c11fbbfdd/src/Node/WorkerBees.js#L12
https://github.com/natefaubion/purescript-node-workerbees/blob/d8eb29e0eee087c3d136b3b961074c8c11fbbfdd/src/Node/WorkerBees.js#L84
https://github.com/natefaubion/purescript-node-workerbees/blob/d8eb29e0eee087c3d136b3b961074c8c11fbbfdd/src/Node/WorkerBees.js#L47-L51

Ah yeah, I think those are likely culprits. Given what it's printing it's the windows path delimiters being treated as string escapes. I'll try some things out, but the easiest fix might just be to substitute \ for / when printing those values, as I think windows is happy with that. Will try things out/submit a PR later on!

Ah! Yeah that sounds likely! Does node have a built-in way to escape paths?

Nothing that would help here I think, although checking path.sep could be used to determine whether it needs double-escaping or something - I think it's just because here you're producing a string of javascript for the worker in that first case you linked to, so the worker is seeing require("whatever\node_modules\...") rather than require("whatever\\node_modules\\...")

Yeah, res.filePath.replace(/\\/g, '\\\\' ) in WorkerBees.js fixes it.

This was fixed in the 0.1.1 release.


Don't understand this ERROR

Just don't get it:
[6/7/2018, 2:28:50 PM] [Config] You are using a depreciated log config format, please update your config.json to use this new format:
[6/7/2018, 2:28:50 PM] [Config] {"method":"custom","command":"pm2 logs --raw --lines 100 homebridge"}

what do I have to change?

Hi @theo-69,
Just replace your log entry with the value provided:
"platforms": [
    {
      "platform": "config",
      "name": "Config",
      "port": 8080,
      "log": {"method":"custom","command":"pm2 logs --raw --lines 100 homebridge"}
    }
]

https://github.com/oznu/homebridge-config-ui-x#logs-from-custom-command


Load More Issue

Load more method Only call Ones...and i already call setPullLoadEnable(true)  on notify data..

and I use this Xlistview In Viewpager


[Provisioning] Implement Node Affinity

Support node affinity in constraint groups.

Closing as dup of https://github.com/awslabs/karpenter/issues/482


change 'email' field on login form to 'login'

Current coverage is 87.29% (diff: 100%)

Merging #166 into develop will decrease coverage by 0.23%

@@            develop       #166   diff @@
==========================================
  Files           123        123
  Lines          2172       2172
  Methods          62         62
  Messages          0          0
  Branches        161        161
==========================================
- Hits           1901       1896     -5
  Misses          211        211
- Partials         60         65     +5

Powered by Codecov. Last update 9217246...9e1e399


luarocks install hanging up

First, let me say I am fairly new to Torch, Lua, and Ubuntu 14.04. I installed torch7 using the instructions listed at https://github.com/torch/distro. When I try and install other modules/packages using luarocks install, the installation hangs up. The following is an example of the output:
kzachery@DELL:~$ luarocks install nnx
Installing https://raw.githubusercontent.com/torch/rocks/master/nnx-0.1-1.rockspec...
Using https://raw.githubusercontent.com/torch/rocks/master/nnx-0.1-1.rockspec... switching to 'build' mode
Cloning into 'lua---nnx'...
The next thing that happens is the download times out. This has happened with all of the modules/packages I have tried to install using luarocks. Not sure why downloads keep timing out. My work around is to do a manual git clone, cd to cloned directory, and then luarocks make rocks. The module directory paths for the git clone (e.g., https://github.com/torch/module_name.git) are always different than the site listed above. The thing is, when I use luarocks install, the https://raw.githubusercontent.com/torch/rocks/master/ site is always listed. Is there something I forgot to set in a configure file? Any assistance in this matter would be greatly appreciated.
-knz
<EMAIL_ADDRESS>

you're probably behind a firewall. what we do is modify clone method from ssh to https, check here https://github.com/torch/luajit-rocks/compare/master...szagoruyko:master

Many Thanks! I will take a look.
From: Sergey Zagoruyko<EMAIL_ADDRESS>Sent: Tuesday, April 21, 2015 10:13 AM
To: torch/distro
Cc: Karen Zachery
Subject: Re: [distro] luarocks install hanging up (#21)
you're probably behind a firewall. what we do is modify clone method from ssh to https, check here torch/luajit-rocks@master...szagoruyko:masterhttps://github.com/torch/luajit-rocks/compare/master...szagoruyko:master
—
Reply to this email directly or view it on GitHubhttps://github.com/torch/distro/issues/21#issuecomment-94810145.

Did switching to https from ssh resolve your issue, @kzachery?

My apologies! I thought I had replied to your message letting you know it worked. Yes, it resolved the timed-out issues I was having, and I was finally able to install Torch packages.
Many Thanks,
knz
From: Josh McSavaney<EMAIL_ADDRESS>Sent: Friday, June 19, 2015 7:49 PM
To: torch/distro
Cc: Karen Zachery
Subject: Re: [distro] luarocks install hanging up (#21)
Did switching to https from ssh resolve your issue, @kzacheryhttps://github.com/kzachery?
—
Reply to this email directly or view it on GitHubhttps://github.com/torch/distro/issues/21#issuecomment-113674326.

Thanks!


helm chart repo using github pages

helm chart repo using github-pages

@b-shj Thanks for making this new pull request.

Did you set up a remote Helm Chart repository?
When and how will the chart will be pushed to the repository?

@zzxwill  we can re-use our OSS bucket for terraform-controller chart

@zzxwill we can re-use our OSS bucket for terraform-controller chart

Correct, but we need to test it in another repo before we officially push the chart to oam-dev repository by granting operators with OSS credentials.
Besides and more importantly, after we confirm the chart can be uploaded to a remote Chart repository, we need to have Chart version, and image version automatically generated.


BLD: Init scikit-build

This is needed for tomopy 1.5.0
meta file is from here
https://github.com/conda-forge/scikit-build-feedstock/blob/master/recipe/meta.yaml

this needs to be down one level (in a scikit-build folder).


Rename Stylus version

Going to leave it at this for now, let's have someone try this and test to make sure it works. Works for me.

Is it really working this way? I think recursively importing a folder with just calling @import 'jeet' just works with the index.styl in the folder, requiring every other module.
Or how did you think about this change?

I think I'll add to what you had to say here. I'll see what happens.

Tested both versions and they work with @import 'jeet': just fine.
align.scss tested from scss/jeet/
align.styl tested from stylus
Should be ready for merge and release!


Pip installation error on Ubuntu

Describe the bug
The upgrade to mythril 0.18.10 fails on Ubuntu with the following error:
$ pip3 install mythril -U
Collecting mythril
  Using cached https://files.pythonhosted.org/packages/ac/c4/a258e1472f29e0866d6a82f320df17b69e1b45e552e7c7cf46194a566e70/mythril-0.18.10.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/tmp/pip-install-qa5hgytb/mythril/setup.py", line 15, in <module>
        exec(open(version_path, 'r').read())
    TypeError: invalid file: PosixPath('/tmp/pip-install-qa5hgytb/mythril/mythril/version.py')

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-qa5hgytb/mythril/

Same error when running setup.py manually:
ubuntu:~/myth/mythril-0.18.10$ python setup.py
Traceback (most recent call last):
  File "setup.py", line 15, in <module>
    exec(open(version_path, 'r').read())
TypeError: invalid file: PosixPath('/home/ubuntu/myth/mythril-0.18.10/mythril/version.py')

The file mentioned in the error message exists & is readable though:
$ cat /home/ubuntu/myth/mythril-0.18.10/mythril/version.py
# This file is suitable for sourcing inside POSIX shell, e.g. bash as
# well as for importing into Python
VERSION="v0.18.10"  # NOQA

On my Mac, it worked without issues.
@rocky, this might have something to do with the latest changes in #351?
Desktop (please complete the following information):

OS: Ubuntu 16.04

A quick workaround until I have time fully understand and fix is
  diff --git a/setup.py b/setup.py
index 68bd8e9..18dc9ce 100755
--- a/setup.py
+++ b/setup.py
@@ -6,13 +6,13 @@ import os

 # To make lint checkers happy we set VERSION here, but
 # it is redefined by the exec below
-VERSION = None
+VERSION = "v0.18.9"

 # Package version (vX.Y.Z). It must match git tag being used for CircleCI
 # deployment; otherwise the build will failed.

```diff
 version_path = (Path(__file__).parent / 'mythril' / 'version.py').absolute()
-exec(open(version_path, 'r').read())
+#exec(open(version_path, 'r').read())

 class VerifyVersionCommand(install):
     """Custom command to verify that the git tag matches our version"""

And also curious is that I use Ubuntu and recently pullled mythril from master and that worked. Whatever. Will track this down and add a test which I guess I should have done initially.

This worked when I just tried it on Ubuntu bionic:
$ pip3 install mythril -U
Collecting mythril
  Downloading https://files.pythonhosted.org/packages/ac/c4/a258e1472f29e0866d6a82f320df17b69e1b45e552e7c7cf46194a566e70/mythril-0.18.10.tar.gz (64kB)
    100% |████████████████████████████████| 71kB 2.3MB/s
Requirement not upgraded as not directly required: ethereum>=2.3.2 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (2.3.2)
Requirement not upgraded as not directly required: z3-solver>=4.5 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (<IP_ADDRESS>.post2)
Requirement not upgraded as not directly required: requests in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (2.19.1)
Requirement not upgraded as not directly required: py-solc in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (3.1.0)
Requirement not upgraded as not directly required: plyvel in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (1.0.5)
Requirement not upgraded as not directly required: eth_abi>=1.0.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (1.1.1)
Requirement not upgraded as not directly required: eth-utils>=1.0.1 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (1.0.3)
Requirement not upgraded as not directly required: eth-account>=0.1.0a2 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (0.2.3)
Requirement not upgraded as not directly required: eth-hash>=0.1.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (0.1.4)
Requirement not upgraded as not directly required: eth-keyfile>=0.5.1 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (0.5.1)
Requirement not upgraded as not directly required: eth-keys>=0.2.0b3 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (0.2.0b3)
Requirement not upgraded as not directly required: eth-rlp>=0.1.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (0.1.2)
Requirement not upgraded as not directly required: eth-tester>=0.1.0b21 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (0.1.0b28)
Requirement not upgraded as not directly required: coverage in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (4.5.1)
Requirement not upgraded as not directly required: jinja2>=2.9 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (2.10)
Requirement not upgraded as not directly required: rlp>=1.0.1 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (1.0.1)
Requirement not upgraded as not directly required: transaction>=2.2.1 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (2.2.1)
Requirement not upgraded as not directly required: py-flags in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (1.1.2)
Requirement not upgraded as not directly required: mock in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (2.0.0)
Requirement not upgraded as not directly required: configparser>=3.5.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (3.5.0)
Requirement not upgraded as not directly required: persistent>=4.2.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mythril) (<IP_ADDRESS>)
Requirement not upgraded as not directly required: PyYAML in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (3.13)
Requirement not upgraded as not directly required: future in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (0.16.0)
Requirement not upgraded as not directly required: scrypt in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (0.8.6)
Requirement not upgraded as not directly required: pysha3>=1.0.1 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (1.0.2)
Requirement not upgraded as not directly required: pycryptodome>=3.4.7 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (3.6.4)
Requirement not upgraded as not directly required: py-ecc in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (1.4.3)
Requirement not upgraded as not directly required: pyethash<1.0.0,>=0.1.27 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (0.1.27)
Requirement not upgraded as not directly required: coincurve>=7.0.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (8.0.0)
Requirement not upgraded as not directly required: repoze.lru in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (0.7)
Requirement not upgraded as not directly required: pbkdf2 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from ethereum>=2.3.2->mythril) (1.3)
Requirement not upgraded as not directly required: chardet<3.1.0,>=3.0.2 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from requests->mythril) (3.0.4)
Requirement not upgraded as not directly required: urllib3<1.24,>=1.21.1 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from requests->mythril) (1.23)
Requirement not upgraded as not directly required: certifi>=2017.4.17 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from requests->mythril) (2018.4.16)
Requirement not upgraded as not directly required: idna<2.8,>=2.5 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from requests->mythril) (2.7)
Requirement not upgraded as not directly required: semantic-version>=2.6.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from py-solc->mythril) (2.6.0)
Requirement not upgraded as not directly required: parsimonious==0.8.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from eth_abi>=1.0.0->mythril) (0.8.0)
Requirement not upgraded as not directly required: cytoolz<1.0.0,>=0.8.2 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from eth-utils>=1.0.1->mythril) (<IP_ADDRESS>)
Requirement not upgraded as not directly required: attrdict<3,>=2.0.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from eth-account>=0.1.0a2->mythril) (2.0.0)
Requirement not upgraded as not directly required: hexbytes<1,>=0.1.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from eth-account>=0.1.0a2->mythril) (0.1.0)
Requirement not upgraded as not directly required: MarkupSafe>=0.23 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from jinja2>=2.9->mythril) (1.0)
Requirement not upgraded as not directly required: zope.interface in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from transaction>=2.2.1->mythril) (4.5.0)
Requirement not upgraded as not directly required: dictionaries==0.0.1 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from py-flags->mythril) (0.0.1)
Requirement not upgraded as not directly required: pbr>=0.11 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mock->mythril) (4.1.1)
Requirement not upgraded as not directly required: six>=1.9 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from mock->mythril) (1.11.0)
Requirement not upgraded as not directly required: asn1crypto in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from coincurve>=7.0.0->ethereum>=2.3.2->mythril) (0.24.0)
Requirement not upgraded as not directly required: cffi>=1.3.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from coincurve>=7.0.0->ethereum>=2.3.2->mythril) (1.11.5)
Requirement not upgraded as not directly required: toolz>=0.8.0 in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from cytoolz<1.0.0,>=0.8.2->eth-utils>=1.0.1->mythril) (0.9.0)
Requirement not upgraded as not directly required: setuptools in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from zope.interface->transaction>=2.2.1->mythril) (39.0.1)
Requirement not upgraded as not directly required: pycparser in /home/rocky/.pyenv/versions/3.6.6/lib/python3.6/site-packages (from cffi>=1.3.0->coincurve>=7.0.0->ethereum>=2.3.2->mythril) (2.18)
Building wheels for collected packages: mythril
  Running setup.py bdist_wheel for mythril ... done
  Stored in directory: /home/rocky/.cache/pip/wheels/23/c8/46/1a694efdffa5a626eae1d7a6454af3b3ac2d9a03c648a6f85a
Successfully built mythril
Installing collected packages: mythril
  Found existing installation: mythril 0.18.9
    Uninstalling mythril-0.18.9:
      Successfully uninstalled mythril-0.18.9
Successfully installed mythril-0.18.10

Will investigate further though...

Ok. I see what's up. I bet you ran this on Python version 3.5.x (or more precisely < Python 3.6) where open() doesn't accept a Path type.
One simple fix is to change:
exec(open(version_path, 'r').read())

to:
exec(open(str(version_path), 'r').read())

but perhaps this error has some blessings in disguise. (Or at least I hope you take it that way :-) )
Previously when I was checking to see if this worked for Pypy, I recall reading that Mythril needs 3.6 or later. Is 3.5 acceptable?
Our setup.py suggest yes here.
However it also says here that Python 2x, 2.7, 3x, .3, and 3.4 are allowed in addition. And no mention of 3.6 or 3.7.
So which versions do we support?
After understanding that, I would be happy to correct all of the parts of setup.py to make them consistent.
Thanks.

@rocky
Your post is correct from what I can tell. 0.18.9 installs fine with the default ubuntu install of 3.5.2. I installed without a version specification two days ago and ran into this issue while installing today today.
Thanks for posting @b-mueller.

We never clearly defined this, but I think it makes sense to support both 3.5 and 3.6 to make things easy for Ubuntu users? If we only need the str fix to do it.

@rocky
No worries! I ran the following without issue:
pip3 install git+https://github.com/ConsenSys/mythril.git@332653d7c1800cf8af9cb1fdd2cbb14ee17c9fd5

this is what i got on my mac when i tried to install it
-I/Library/Frameworks/Python.framework/Versions/3.7/include/python3.7m -c scrypt-1.2.1/libcperciva/crypto/crypto_aes.c -o build/temp.macosx-10.9-x86_64-3.7/scrypt-1.2.1/libcperciva/crypto/crypto_aes.o
scrypt-1.2.1/libcperciva/crypto/crypto_aes.c:6:10: fatal error: 'openssl/aes.h' file not found
#include <openssl/aes.h>
^~~~~~~~~~~~~~~
1 error generated.
error: command 'gcc' failed with exit status 1
----------------------------------------

Command "/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7 -u -c "import setuptools, tokenize;file='/private/var/folders/w7/y8bs9vj17fj26py3ylyrz7s40000gn/T/pip-install-yaw0bz9l/scrypt/setup.py';f=getattr(tokenize, 'open', open)(file);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, file, 'exec'))" install --record /private/var/folders/w7/y8bs9vj17fj26py3ylyrz7s40000gn/T/pip-record-koxecbym/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /private/var/folders/w7/y8bs9vj17fj26py3ylyrz7s40000gn/T/pip-install-yaw0bz9l/scrypt/

hi @stuardo3191 , is the problem with this(v 0.18.10) version ?(did you successfully install mythril before?)

not yet but I'm going to right now

okay so i tried it  om my mac   including the older versions and non of them were successfully installed

can you try doing brew install openssl or something like that which installs openssl and then retry installing it?

Closing this as the original issue seems to be fixed. Thanks @johnbender for confirming.
Not sure if the mac os thing has been solved, if not feel free to open another issue :smile:
@JonHaas Thanks for the info! :+1: Hope that helped with @stuardo3191's issue. We're planning on supporting 3.7 as well in the future


[PowerToys RUN] Works only once, then fails to launch again

Microsoft PowerToys version
0.55.2
Running as admin

[ ] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce
Hey everyone,
What's happening is that powertoys run will work fine on startup and if I toggle it on/off from the powertoys settings but it only runs the one time. After dismissing it once, it will not launch again until I toggle it on/off or relaunch the app.
I've tried the following:

Restarting my system
Reinstalling PowerToys
Running PowerToys in Administrator mode and without it

It ran absolutely fine until a week or two ago when this bug started happening, unfortunately I can't pinpoint a specific update or date when this started occurring.
I've checked the logs for powertoys run and I've got these errors in there:
`[2022-02-20 10:14:03.8260] [ERROR] [C:\a_work\1\s\src\modules\launcher\Plugins\Microsoft.Plugin.Program\Programs\PackageWrapper.cs::59]
-------------------------- Begin exception --------------------------
Message: 	Error status: UNKNOWN
Program path: Path could not be determined
Exception thrown in called method: Void g__Throw|20_0(Int32)
Possible interpretation of the error: Exception Microsoft.FlightSimulator
Possible resolution: Not yet known
Exception full name  : System.IO.FileNotFoundException
Exception message    : The system cannot find the file specified. (0x80070002)
Exception stack trace:
at WinRT.ExceptionHelpers.g__Throw|20_0(Int32 hr)
at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
at ABI.Windows.ApplicationModel.IPackageMethods.get_InstalledLocation(IObjectReference _obj)
at Windows.ApplicationModel.Package.get_InstalledLocation()
at Microsoft.Plugin.Program.Programs.PackageWrapper.GetWrapperFromPackage(Package package)
Exception source     : WinRT.Runtime
Exception target site: Void g__Throw|20_0(Int32)
Exception HResult    : -2147024894
-------------------------- End exception --------------------------`
`[2022-02-20 10:14:04.4370] [ERROR] [C:\a_work\1\s\src\modules\launcher\Plugins\Microsoft.Plugin.Program\Programs\ShellLinkHelper.cs::172]
-------------------------- Begin exception --------------------------
Message: Failed to fetch description for C:\WINDOWS\syswow64\odbcad32.exe, Error HRESULT E_FAIL has been returned from a call to a COM component.
Exception full name  : System.Runtime.InteropServices.COMException
Exception message    : Error HRESULT E_FAIL has been returned from a call to a COM component.
Exception stack trace:
at Microsoft.Plugin.Program.Programs.ShellLinkHelper.IShellLinkW.GetDescription(StringBuilder pszName, Int32 cchMaxName)
at Microsoft.Plugin.Program.Programs.ShellLinkHelper.RetrieveTargetPath(String path)
Exception source     : Microsoft.Plugin.Program
Exception target site: Void GetDescription(System.Text.StringBuilder, Int32)
Exception HResult    : -2147467259
-------------------------- End exception --------------------------`
`[2022-02-20 10:14:04.4604] [ERROR] [C:\a_work\1\s\src\modules\launcher\Plugins\Microsoft.Plugin.Program\Programs\UWPApplication.cs::606]
-------------------------- Begin exception --------------------------
Message: 	Error status: KNOWN
Program path: C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Exception thrown in called method: Not available
Possible interpretation of the error: |Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge can't find logo uri for Assets\MicrosoftEdgeSquare44x44.png in package location: C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe
Possible resolution: Can be ignored and PowerToys Run should still continue, however the program may not be loaded
Exception full name  : System.IO.FileNotFoundException
Exception message    : Unable to find the specified file.
Exception stack trace:
Exception source     :
Exception target site:
Exception HResult    : -2147024894
-------------------------- End exception --------------------------`
✔ Expected Behavior
I expect PowerToys run to launch everytime I invoke it.
❌ Actual Behavior
PowerToys Run only launches once and then stops launching completely.
Other Software
No response

/bugreport

same issue here PowerToysReport_2022-03-17-09-54-27.zip

@TyrWang has the same error in the logs.
Any theory why it might've gone away?
Any updates for Windows in the update history?
[2022-03-17 09:49:45.6789] [ERROR] [C:\a\_work\1\s\src\modules\launcher\Plugins\Microsoft.Plugin.Program\Programs\ShellLinkHelper.cs::172]
-------------------------- Begin exception --------------------------
Message: Failed to fetch description for C:\PROGRA~2\WINDOW~4\wmplayer.exe, Error HRESULT E_FAIL has been returned from a call to a COM component.

Exception full name  : System.Runtime.InteropServices.COMException
Exception message    : Error HRESULT E_FAIL has been returned from a call to a COM component.
Exception stack trace:
   at Microsoft.Plugin.Program.Programs.ShellLinkHelper.IShellLinkW.GetDescription(StringBuilder pszName, Int32 cchMaxName)
   at Microsoft.Plugin.Program.Programs.ShellLinkHelper.RetrieveTargetPath(String path)
Exception source     : Microsoft.Plugin.Program
Exception target site: Void GetDescription(System.Text.StringBuilder, Int32)
Exception HResult    : -2147467259
-------------------------- End exception --------------------------

[2022-03-17 09:49:45.6789] [ERROR] [C:\a\_work\1\s\src\modules\launcher\Plugins\Microsoft.Plugin.Program\Programs\ShellLinkHelper.cs::172]
-------------------------- Begin exception --------------------------
Message: Failed to fetch description for C:\WINDOWS\syswow64\odbcad32.exe, Error HRESULT E_FAIL has been returned from a call to a COM component.

Exception full name  : System.Runtime.InteropServices.COMException
Exception message    : Error HRESULT E_FAIL has been returned from a call to a COM component.
Exception stack trace:
   at Microsoft.Plugin.Program.Programs.ShellLinkHelper.IShellLinkW.GetDescription(StringBuilder pszName, Int32 cchMaxName)
   at Microsoft.Plugin.Program.Programs.ShellLinkHelper.RetrieveTargetPath(String path)
Exception source     : Microsoft.Plugin.Program
Exception target site: Void GetDescription(System.Text.StringBuilder, Int32)
Exception HResult    : -2147467259
-------------------------- End exception --------------------------

[2022-03-17 09:49:45.6789] [INFO] [C:\a\_work\1\s\src\modules\launcher\Plugins\Microsoft.Plugin.Program\Storage\PackageRepository.cs::84]
Indexed 53 packaged applications

[2022-03-17 09:49:45.6789] [INFO] [C:\a\_work\1\s\src\modules\launcher\Wox.Infrastructure\Stopwatch.cs::50]
Microsoft.Plugin.Program.Main - Package index cost <1839ms>

[2022-03-17 09:49:45.7649] [ERROR] [C:\a\_work\1\s\src\modules\launcher\Plugins\Microsoft.Plugin.Program\Programs\UWPApplication.cs::630]
-------------------------- Begin exception --------------------------
Message: 	Error status: KNOWN
		Program path: C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe
		Exception thrown in called method: Not available
		Possible interpretation of the error: |Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge can't find logo uri for Assets\MicrosoftEdgeSquare44x44.png in package location: C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe
		Possible resolution: Can be ignored and PowerToys Run should still continue, however the program may not be loaded

Exception full name  : System.IO.FileNotFoundException
Exception message    : Unable to find the specified file.
Exception stack trace:

Exception source     :
Exception target site:
Exception HResult    : -2147024894
-------------------------- End exception --------------------------


Refactor determine prev and next step

Short Description

This introduces the new logic how previous and next steps are determined.
I did not change the eligibility logic though.

Changes

Introduce new method to determine prev and next steps
Move the prev and next step logic of the lotse steps from the steps up to the step_chooser. This way we can use the logic in the lotse once we have more than one consecutive step as SteuerlotseStep
Add check_precondition? and get_redirection_step` to the SteuerlotseStep
Redirect in step_chooser if get_redirection_step of the step returns something

Feedback

Do you think we need a log/error message in case we return None as the prev/next step and the current step is not the first/last step (or is not in a defined list of accepted first/last steps)?
What do you think of the way I handled the prev/next step logic for the lotse_step_chooser? Does that make sense to you? This way, we only have to set prev_step and next_step directly for the steps that direct to old multistepflow-steps.
Do you see any missing tests?

Todos left on this PR:

[ ] Go over the tests together
[ ] Add a comment explaining the detemrine_x_step functions
[ ] Return None only for specific steps and error by default


Confusing word choice about extended maximum path length

Describe the bug

The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.

It seems that here is stated that..

The "\\?\" prefix may be expanded to a longer string by the system at run time and the expanded string must be within the maximum path length (i.e. thus less then 32,767 characters may be usable)

Though "The maximum path of 32,767 characters is approximate" seems to be incorrect if 32,767 characters is a hard limit which it seems to be.
Above is from https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd
To Reproduce
-
Expected behavior
-
Screenshots
-
Desktop (please complete the following information):
-
Smartphone (please complete the following information):
-
Additional context
-

@wallby What's the article you were looking at?

@gewarren Added link now, seems perhaps I forgot to include it.

@GrantMeStrength FYI.


fix(autoware_freespace_planning_algorithms): fix unreadVariable

Description
This is a fix based on cppcheck unreadVariable warnings.
planning/autoware_freespace_planning_algorithms/src/reeds_shepp.cpp:213:16: style: Variable 'L' is assigned a value that is never used. [unreadVariable]
    L_min > (L = std::abs(t) + std::abs(u) + std::abs(v)))  // time flip + reflect
               ^

planning/autoware_freespace_planning_algorithms/src/reeds_shepp.cpp:291:16: style: Variable 'L' is assigned a value that is never used. [unreadVariable]
    L_min > (L = std::abs(t) + std::abs(u) + std::abs(v)))  // time flip + reflect
               ^

planning/autoware_freespace_planning_algorithms/src/reeds_shepp.cpp:390:16: style: Variable 'L' is assigned a value that is never used. [unreadVariable]
    L_min > (L = std::abs(t) + 2. * std::abs(u) + std::abs(v)))  // time flip + reflect
               ^

planning/autoware_freespace_planning_algorithms/src/reeds_shepp.cpp:548:16: style: Variable 'L' is assigned a value that is never used. [unreadVariable]
    L_min > (L = std::abs(t) + std::abs(u) + std::abs(v)))  // time flip + reflect
               ^

planning/autoware_freespace_planning_algorithms/src/reeds_shepp.cpp:601:16: style: Variable 'L' is assigned a value that is never used. [unreadVariable]
    L_min > (L = std::abs(t) + std::abs(u) + std::abs(v)))  // time flip + reflect
               ^

Related links
Parent Issue:

Link

How was this PR tested?
Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

@mkquda
Can you have a look at the PR? Hope there will be no bad effect by this correct change.


demoted txpool logs to Debug instead of Warn

Hmm. I think this is demoting too many errors. I'd only demote
[WARN] [09-01|11:44:02.914] [txpool.fetch] Handling incoming message msg=NEW_POOLED_TRANSACTION_HASHES_66 err="parsing NewPooledTransactionHashes: parse hash payload: hashes len must be multiple of 33"


Kerberos authentication

I'm currently making HTTP calls to a server that authenticates with Kerberos. Should I expect the override closure Alamofire.Manager.sharedInstance.delegate.sessionDidReceiveChallenge to execute only after a failed or accepted authentication by the operating system, and not before as well?

Hi @dtorreci4ejg,
You most likely need to override the taskDidReceiveChallenge closure instead. Kerberos challenges are part of the NSURLAuthenticationMethodNegotiate protection space auth type. The taskDidReceiveChallenge should be called as soon as a challenge is issued by the server. It will be called again if the challenge is not successfully authenticated. Alamofire by default will reject the protection space after a failed attempt. However, if you're overriding the default logic, the behavior is up to you.
Cheers. 🍻


Feature Request: Hide the Highlight Menu

I have a request for a QoL feature. I use the Unknown Chances mod, and the highlight menu completely covers the UI added by Unknown Chances. So my request: Could a hotkey or toggle be implemented so you can choose whether to show or hide the highlight menu?

Hi - thanks for reaching out. My apologies but I'm no longer supporting this mod with updates :(
I did write a successor mod to this project which has a different control scheme that will probably alleviate your issue (and also, I think it looks nicer too, but I guess that's personal preference). Hopefully you'll be able to use that instead, as it has most of the same features, as well as a few newer ones for better quality of life.
That mod is called MapMarks, and is still only available on my GitHub for now until I iron out the last few bugs / feature requests. Real life + modding burnout has definitely dampened any progress on new stuff, but hopefully this helps. I'll leave this issue open in case anyone else wants to code something up and submit it as a pull request, but I personally don't have plans to do so at this time.
You can find the link to MapMarks here:
https://github.com/casey-c/mapmarks


Feature request - Change visibility in expander toogle button

Hello, is it possible to add an option that can change the "Visibility" property in the toogle button of an expander? something like Controls: ExpanderHelper.ToogleButtonVisibility="Collapse"
Of course, it can be expanded by clicking on the row. Thx

@avechuche An expander control should always shown it's state to make it different to a GroupBox. If you don't need this difference then please make your own style for the header template.


403 Forbidden:  Before opening files in this location, you must first browse the website and select the option to login automatically

First of all, love this project, it might save my currrent internship, really, thanks a lot for doing this.
Secondly: I'm having no problem fetching lists or info about a file or whatnot, but whe I try to download a file, I always get the same error:  403 Forbidden: "{"error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"}}}", and when Itried to read the logs, I saw this: 1583 [main] DEBUG org.apache.http.headers  - http-outgoing-1 << X-MSDAVEXT_Error: 917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.
I tried searching for something like that on the internet, but all I could find was advices on using IE or somehow manipulating your registry. Would you know how to fix this ?
My code:
String folder = "/sites/{site_name}/{path to folder}";
String fileName = "myFile.aspx";
wrapper.getFileInfo(folder + "/" + fileName);
wrapper.downloadFile(folder + "/" + fileName); // Error there

Same problem here... I can download but not updateFileMetadata(...) :(


Interop working from Xamarin to Blazor.  Need to refactor to make passing parameters cleaner

Interop working from Xamarin to Blazor.  Need to refactor to make passing parameters cleaner

@vicjgg Merged your update in this branch. I will try to refactor this very soon, and do little modification.
I will add a test button in the InteropApp project, to forward a simulation of PostMessage events also.

Hi,
I submitted a PR.
Victor J. Gorri
973-800-0625
victor<EMAIL_ADDRESS>From: Guillaume ZAHRA<EMAIL_ADDRESS>Sent: Thursday, October 3, 2019 8:11 AM
To: Daddoon/BlazorMobile<EMAIL_ADDRESS>Cc: Victor Gorri<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Daddoon/BlazorMobile] Interop working from Xamarin to Blazor. Need to refactor to make passing parameters cleaner (#126)
@vicjgghttps://github.com/vicjgg Merged your update in this branch. I will try to refactor this very soon, and do little modification.
I will add a test button in the InteropApp project, to forward a simulation of PostMessage events also.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=ADK66Q7AAC7X3R3ZB6HME6TQMXOOTA5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAH7U2Y#issuecomment-537918059, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADK66Q5JTHIHIK4SIUOAMCTQMXOOTANCNFSM4I5CHB5A.

I already merged your fork in the https://github.com/Daddoon/BlazorMobile/tree/dev_postmessage_update branch.
As i want to do a little review on your code this evening.
I will then merge this branch to the master and release a NuGet package update.

@vicjgg I have done changes in the https://github.com/Daddoon/BlazorMobile/tree/dev_postmessage_update branch.
This should be fine and ready to be released.
There is now two way of posting message:

CallJSInvokableMethod on Webview (previously your PostMessage)
PostMessage method on Webview

See some integration test code in the BlazorMobile.InteropBlazorApp project, in the Counter page.
I should write some documentation about this before releasing, and also migration documentation.
I will do this tomorrow i think, however feel free to test from this branch, or to PR accross-fork if you want to test it from your repo.

I’ll check it out.
Thanks again.
Victor J. Gorri
973-800-0625
victor<EMAIL_ADDRESS>From: Guillaume ZAHRA<EMAIL_ADDRESS>Sent: Thursday, October 3, 2019 1:22 PM
To: Daddoon/BlazorMobile<EMAIL_ADDRESS>Cc: Victor Gorri<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Daddoon/BlazorMobile] Interop working from Xamarin to Blazor. Need to refactor to make passing parameters cleaner (#126)
@vicjgghttps://github.com/vicjgg I have done changes in the https://github.com/Daddoon/BlazorMobile/tree/dev_postmessage_update branch.
This should be fine and ready to be released.
There is now two way of posting message:

CallJSInvokableMethod on Webview (previously your PostMessage)
PostMessage method on Webview

See some integration test code in the BlazorMobile.InteropBlazorApp project, in the Counter page.
I should write some documentation about this before releasing, and also migration documentation.
I will do this tomorrow i think, however feel free to test from this branch, or to PR accross-fork if you want to test it from your repo.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=ADK66Q26FFI7KEO4VNM35MDQMYS2LA5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAI54NI#issuecomment-538041909, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADK66Q24K6E7ARSDJSXT33LQMYS2LANCNFSM4I5CHB5A.

I’ll take a look…
My needs (so far) have only been to send messages to pop modal screen/alerts/forms from location or push services…
Therefore it was pretty easy to just use a class with some static methods and use DI to inject the services.
Your way sounds much more robust.  I look forward to seeing it,
Victor J. Gorri
973-800-0625
victor<EMAIL_ADDRESS>From: Guillaume ZAHRA<EMAIL_ADDRESS>Sent: Thursday, October 3, 2019 2:23 PM
To: Daddoon/BlazorMobile<EMAIL_ADDRESS>Cc: Victor Gorri<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Daddoon/BlazorMobile] Interop working from Xamarin to Blazor. Need to refactor to make passing parameters cleaner (#126)
Actually there is a mistake i must fix tomorrow : When forwarding the
JSInvokable method in the BlazorToXamarin dispatcher class, i bubble the
parameters object[] in another object[] for the method invokation. Actually
i mimic-ed the PostMessage API parameter received behavior but this is
wrong.
I must remove the object[] bubbling when invoking, and also change the
JSInvokable test method signature to the expected parameters of course. Si
changing object[] to string parameter signature.
Btw the main advantage of the Message API otherwise, except the parameters
type hidding witch is less nice, is to easily being able to send message to
instanciated object. the invokable method will have more difficulties to
target rendered component at runtime without tricks.
Le jeu. 3 oct. 2019 à 19:26, vicjgg <notifications<EMAIL_ADDRESS>a écrit :

I’ll check it out.
Thanks again.
Victor J. Gorri
973-800-0625
victor@ibeanzinc.com<mailto:victor@ibeanzinc.commailto:victor<EMAIL_ADDRESS>From: Guillaume ZAHRA <notifications<EMAIL_ADDRESS>Sent: Thursday, October 3, 2019 1:22 PM
To: Daddoon/BlazorMobile <BlazorMobile<EMAIL_ADDRESS>Cc: Victor Gorri <Victor<EMAIL_ADDRESS>Mention <
mention<EMAIL_ADDRESS>Subject: Re: [Daddoon/BlazorMobile] Interop working from Xamarin to
Blazor. Need to refactor to make passing parameters cleaner (#126)
@vicjgghttps://github.com/vicjgg I have done changes in the
https://github.com/Daddoon/BlazorMobile/tree/dev_postmessage_update
branch.
This should be fine and ready to be released.
There is now two way of posting message:

CallJSInvokableMethod on Webview (previously your PostMessage)
PostMessage method on Webview

See some integration test code in the BlazorMobile.InteropBlazorApp
project, in the Counter page.
I should write some documentation about this before releasing, and also
migration documentation.
I will do this tomorrow i think, however feel free to test from this
branch, or to PR accross-fork if you want to test it from your repo.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=ADK66Q26FFI7KEO4VNM35MDQMYS2LA5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAI54NI#issuecomment-538041909>,
or mute the thread<
https://github.com/notifications/unsubscribe-auth/ADK66Q24K6E7ARSDJSXT33LQMYS2LANCNFSM4I5CHB5A>.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=AFS5ALTI5G26F6PD6OVT6V3QMYTKRA5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAI6JSA#issuecomment-538043592,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFS5ALXVKAOO2XCT2XVNUQ3QMYTKRANCNFSM4I5CHB5A
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=ADK66Q7UMJZEWU5CDIZWMKTQMYZ63A5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJD2FY#issuecomment-538066199, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADK66Q7ZYD7SRHA2C5KVHN3QMYZ63ANCNFSM4I5CHB5A.

I fixed my code.
And also made a fundamental change in the PostMessage API.
I made it working with the same kind of logic and management you can find on the Xamarin.Forms Messaging API.
This mean instead:

You can only post one parameter in PostMessage on the native side
On the Blazor side, you instead register to a specific message name with a specific argument type expected. If a message is sent from native that does not match your message name and delegate expected argument type, it will be ignored, otherwise executed, and you will receive the expected parameter type in your Blazor app delegate, instead of the previous object[].

This also mean that you can post multiple messages with same names but not same delegate signature. As said previously, only matching argument type delegates will be fired.
I think it's a better implementation. Even if limiting to one argument, it's a lot less cryptic than sending object or object[] values, and prevent to always do casting or type check, from a usage point of view.

Hi,
I think one argument is fine. Typically sending a modeled class anyway.
Will download and try out today.
Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message --------
From: Guillaume ZAHRA<EMAIL_ADDRESS>Date: 10/4/19 7:07 AM (GMT-05:00)
To: Daddoon/BlazorMobile<EMAIL_ADDRESS>Cc: Victor Gorri<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Daddoon/BlazorMobile] Interop working from Xamarin to Blazor.  Need to refactor to make passing parameters cleaner (#126)
I fixed my code.
And also made a fundamental change in the PostMessage API.
I made it working with the same kind of logic and management you can find on the Xamarin.Forms Messaging API.
This mean instead:

You can only post one parameter in PostMessage on the native side
On the Blazor side, you instead register to a specific message name with a specific argument type expected. If a message is sent from native that does not match your message name and delegate expected argument type, it will be ignored, otherwise executed, and you will receive the expected parameter type in your Blazor app delegate, instead of the previous object[].

This also mean that you can post multiple messages with same names but not same delegate signature. As said previously, only matching argument type delegates will be fired.
I think it's a better implementation. Even if limiting to one argument, it's a lot less cryptic than sending object or object[] values, and prevent to always do casting or type check, from a usage point of view.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=ADK66Q2QJAA7FHL4E6JYW43QM4PWRA5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEALJ7LI#issuecomment-538353581, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADK66Q5Q3CBXDEWKCR2B4GDQM4PWRANCNFSM4I5CHB5A.

Thanks !
Of course i updated the interop app test page (counter) with theses changement in order to validate them.
You have one PostMessage expecting a string, and another expecting a boolean. Both with same message name.
Also, i'm merging theses update on my current BlazorMobile 3.0.11 dev branch. There is a lot of fix and improvements on the dev branch, and actually i would prefer to release everything at the same time.
There is an opt-in fix for iOS 13 crashing on the next release (as still waiting to Microsoft to release a new version of Blazor with the fix), consistent iframe navigation event handling on Android and more...If you are curious, you can check the github issues Milestone related to that.

Well actually my update does not work. I just tested, it does work when executing from a pure .Net core environment, like when i test from remote debugging, but not in the wasm implementation.
I suspect WASM not being able to honor the Delage.DynamicInvoke method.
Sorry to this new, i must find a workaround for the invokation in wasm mode

Yeah…
I tried A LOT of different things that didn’t work and could never get events/delegates to work.
Most of what I wrote was a work around, I’ll have a look over the weekend and see if I can help.
Victor J. Gorri
973-800-0625
victor<EMAIL_ADDRESS>From: Guillaume ZAHRA<EMAIL_ADDRESS>Sent: Friday, October 4, 2019 8:05 AM
To: Daddoon/BlazorMobile<EMAIL_ADDRESS>Cc: Victor Gorri<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Daddoon/BlazorMobile] Interop working from Xamarin to Blazor. Need to refactor to make passing parameters cleaner (#126)
Well actually my update does not work. I just tested, it does work when executing from a pure .Net core environment, like when i test from remote debugging, but not in the wasm implementation.
I suspect WASM not being able to honor the Delage.DynamicInvoke method.
Sorry to this new, i must find a workaround for the invokation in wasm mode
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=ADK66Q2T6WLRRWMCMLIXI7TQM4WQBA5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEALN2UA#issuecomment-538369360, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ADK66Q4EMB3MKVXGDP3GDQLQM4WQBANCNFSM4I5CHB5A.

Actually i tested and it's more related about serialization issue when the root object to deserialize is a plain C# CLR object, when trying to fetch the expected type with my TypeProxy class.
.NET Core succeed, but WASM fail and seem to not even try to use the advanced binders that cover the .NET Core (using System.PrivateCoreLib) and Mono implementation (WASM) using the mscorlib namespace assembly.

Fixed it in my last commit on the branch.
I workarounded, as the CrossPlatformBinder is not called in this particular case, i forced to change assemblies name in the JSON if a previous deserialization call failed in the BridgeSerializer helper.
This seem to work fine!

I just finished today my last technical task, managing all the navigating
behaviors on ElectronNET to Xamarin.Forms driver, iframe / subframe
navigating included.
The current 3.0.11 branch is actually RTM , i just need to write the
documentation tomorrow or another day.
That mean you can upgrade to this branch or wait officials NuGet packages
to be shipped.
Le ven. 4 oct. 2019 à 15:03, vicjgg<EMAIL_ADDRESS>a écrit :

Yeah…
I tried A LOT of different things that didn’t work and could never get
events/delegates to work.
Most of what I wrote was a work around, I’ll have a look over the weekend
and see if I can help.
Victor J. Gorri
973-800-0625
victor<EMAIL_ADDRESS>From: Guillaume ZAHRA<EMAIL_ADDRESS>Sent: Friday, October 4, 2019 8:05 AM
To: Daddoon/BlazorMobile<EMAIL_ADDRESS>Cc: Victor Gorri<EMAIL_ADDRESS>Mention <
<EMAIL_ADDRESS>Subject: Re: [Daddoon/BlazorMobile] Interop working from Xamarin to
Blazor. Need to refactor to make passing parameters cleaner (#126)
Well actually my update does not work. I just tested, it does work when
executing from a pure .Net core environment, like when i test from remote
debugging, but not in the wasm implementation.
I suspect WASM not being able to honor the Delage.DynamicInvoke method.
Sorry to this new, i must find a workaround for the invokation in wasm
mode
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<
https://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=ADK66Q2T6WLRRWMCMLIXI7TQM4WQBA5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEALN2UA#issuecomment-538369360>,
or mute the thread<
https://github.com/notifications/unsubscribe-auth/ADK66Q4EMB3MKVXGDP3GDQLQM4WQBANCNFSM4I5CHB5A>.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/Daddoon/BlazorMobile/pull/126?email_source=notifications&email_token=AFS5ALXRD2J7N6S62AYQSXTQM45JBA5CNFSM4I5CHB5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEALSIJA#issuecomment-538387492,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFS5ALXLHMEL52U7XQRMJA3QM45JBANCNFSM4I5CHB5A
.

Well, actually done a last push.
I refactored some internal calls, that does not change any functionnality.
However i have made an enchancement about failure when interoping.
On previous version, if there was a JSON deserialization exception, the exception was thrown internally, but the calling Task was never notified about this exception, as it was at deserialization level before coming to the Task management system.
Now, if a task fail when deserializing on Blazor side (like if you have a type present on native Xamarin but not in Blazor), the code now try to fetch the TaskIdentity property from the failed deserialization, and forward the exception and inner exception to the original calling task.
This prevent JSON deserialization exceptions when interopping, to block the Task in Blazor eternally, as there is no CancellationToken system implemented yet too.

BlazorMobile 3.0.11 has been shipped on Nuget, and the documentation has been updated.
Thanks for your contribution!

Just for your info, i just added the changelog here


The folderv code block doesn't show the folders of that folder along with the note

duplicate of #10


Removed machine driver doesn't get removed from disk

Version - 0.63.0-rc3
Steps to Reproduce:

Add a machine driver
Remove the machine driver

Results: Machine driver is removed from UI and schema but not from disk
Expected: Should be removed from disk

Closing due to inactivity, please reopen if you think this is still relevant to current releases & important.


Crash on Script Editor Replace with Empty String

Godot version:
3.2.1-stable
OS/device including version:
Windows 10 Pro x64
X570 chipset; Ryzen 7 3rd gen; DDR4;
Issue description:
When attempting to replace "var " with "", the editor crashes. Maybe accessing invalid memory at a pointer address that doesn't exist because the replace box is blank?
Steps to reproduce:
Select a block of text. Replace "var " with nothing in the replace box.

This is strange because it worked when I implemented #29029...

Any chance this can get cherry-picked back to 3.2.x or is the 3.2.x line no longer being updated?
I didn't even know there was find-in-files. Maybe find-in-files and find-replace is duplicated code and that's why one half works? I haven't had the time to look in the src, personally.

@Jimmio92 The 3.2 branch is still maintained and will be so for a while (at least until 4.0 is released).

I couldn't reproduce this in master actually. Can someone confirm?

Reproduced now after checking selection only and selecting a block of code. Maybe you can update issue title to mention this.

"Select a block of text. Replace "var " with nothing in the replace box."
Selecting a block and pressing the Ctrl+R auto-selects in selection; I thought that was implied. I will add details to the issue.


Added new spell tab to sheet

fixed formatting on some 2espell properties
added some missing HTML tags and formatted for easier reading
fixed bug in css
added optional tag to 2espell property '{materials=xxx}'- to show Spell Materials
added new roll Template for Protection Scrolls - 2Eprotscroll
updated worker script to clear the Ability Scores Notes on change of attribute value
New Spell Tab
List Number of Available Spells per Level
Spell Book
Memorised Tick Box
Type of Spell
Spell Name
Casting Time
Initiative Roll Button
Macro name
Cast button that uses the macro name
Scrolls
Type of Scroll
Scroll Name
Casting Time
Initiative Roll Button
Macro name
Cast button that uses the macro name
Spell Notes

additional changes made and tested


Check if any servers support code actions in diagnostics

Love the new release!
I stumbled upon the following error jumping to a diagnostic (:Lspsaga diagnostic_jump_prev) when none of the LSPs support code actions:
method textDocument/codeAction is not supported by any of the servers registered for the current buffer

I tracked it to this line:
https://github.com/glepnir/lspsaga.nvim/blob/688a3d835a4533ebd2c1ebb7e7c22d53385975d5/lua/lspsaga/codeaction.lua#L163
Looking at other parts of your code, it looks like it's fallible and you had a check for it. For example, send_request() has a similar call:
https://github.com/glepnir/lspsaga.nvim/blob/688a3d835a4533ebd2c1ebb7e7c22d53385975d5/lua/lspsaga/lightbulb.lua#L112
And it has the following check before it gets called:
https://github.com/glepnir/lspsaga.nvim/blob/688a3d835a4533ebd2c1ebb7e7c22d53385975d5/lua/lspsaga/lightbulb.lua#L136-L142
So I extracted check_server_support_codeaction(bufnr) to libs and added it as a check before asking for the possible code actions

you can use libs.get_client_by_cap to get the client. nil non support then.

I just tried with your suggestion, but I may be misunderstanding something on the implementation
I tried:
-- lua/lspsaga/diagnostic.lua
if diag_conf.show_code_action and libs.get_client_by_cap('codeActionProvider') then

But I still ran into the error. This is the relevant differences for server_capabilities between two LSP servers I'm using (null-ls and rust-analyzer):
-- null-ls (failing)
{
  server_capabilities = {
    codeActionProvider = {
      resolveProvider = false  -- not getting checked in `libs.get_client_by_cap`
    },
  },
}

-- rust-analyzer (working)
{
  server_capabilities = {
    codeActionProvider = {
      codeActionKinds = { "", "quickfix", "refactor", "refactor.extract", "refactor.inline", "refactor.rewrite" },
      resolveProvider = true
    },
  },
}

I saw you have some explicit checks in codeaction.lua for resolveProvider:
https://github.com/iovis/lspsaga.nvim/blob/d0192f71eb085a68ba19fcf4f6597a503e03f9e3/lua/lspsaga/codeaction.lua#L277
https://github.com/iovis/lspsaga.nvim/blob/d0192f71eb085a68ba19fcf4f6597a503e03f9e3/lua/lspsaga/codeaction.lua#L303
But I'm unsure how you prefer to solve it

sorry for late. use vim.tbl_get would be great.

I updated the code to leverage libs.get_client_by_cap and vim.tbl_get, let me know if the implementation makes sense to you.
I took the liberty to change the logic a bit for the ["table"] branch because I didn't see any other parts of the code using it with a table anymore. So instead of checking for the first [1] and second [2] values of a list, it treats it as something to unpack for vim.tbl_get(). If I missed any uses of that function or you were planning to use it that way in the future, let me know and we can think of something else.