No longer working in Chrome

Since Chrome updated last week to

Version 43.0.2357.124 m

GhostText is no longer able to connect to Sublime Text

It works fine on 44.0.2403.52 beta, but I do see that error occasionally. Try restarting both apps or rebooting your computer.
Are you on Windows? Do you see any errors in Chrome's or Sublime's console?

Sorry for the late response. I've been using the Firefox version since this stopped working in Chrome.
I went to check and get the error for you from Chrome and Sublime text, but apparently the issue has resolved itself (probably due to an update to Chrome).
This issue can be marked as resolved, as I have no way of getting more information at this time.


Change Request: Move common runtime stub to its own module.

I don't know enough of the internals to even take a crack at this myself.
But ideally I think the common runtime stub added to every compiled file could be moved to its own shared module.
similar to what I did with Traceur:
http://github.com/aikar/traceur
Some parts I understand  cant be shared, but imo the shared parts could be moved
Some advantages:

its easier to manage than a bunch of strings in transform.js
shared so V8 can compile and optimize it better, so hopefully a performance benefit.
reduced duplication of code, ie reduced memory.

So ideally, the top of each source file would be like so
var __streamline = require('streamline-runtime')('path.to.source');
but I'm really wondering do we need the filename stored in a variable though, cant it just report the active file?
ie require('streamline-runtime')(__filename);

I've made some commits to my branch.
namely: moved most of the functions in the runtime outside of the exported function.
The way it was implemented means every one of those functions are duplicated for every source file, which means V8 wont be able to optimize it as effeciently.
so I moved all except __func out of the body since only func uses _srcName;
This way the v8 compiler can optimize those functions for ALL files streamlined.
Ideally, the generated source from streamline should reference the functions as "__rt.__func" instead of "__func" and remove all of the variable definitions after the require('runtime') statement.
This way, all of the functions are executed in the scope of __rt, and then the __func function can reference __srcName as this.__srcName instead, and then NO functions need duplicating, and the export function becomes
exports = module.exports = function(filename){
	return {
		__g: __g,
		__srcName: filename.replace(/\.js$/, '_.js'),
		__func: __func,
		__cb: __cb,
		__future: __future,
		__propagate: __propagate,
		__trap: __trap,
		__tryCatch: __tryCatch,
		__forIn: __forIn,
		__apply: __apply,
		__setEF: __setEF
	};
}

Also, ideally we should get rid of this _.js appendage.
all calls to __func should include the current file and original SOURCE file
line 988~ of transform has the __func definition.
Ideally it should be like
"	return __func(_, this, arguments, $fn, $index, __frame, __filename, <BASENAMEOFSOURCEFILE>, function $name(){" +

I'm not sure where the value of BASENAMEOFSOURCEFILE would come from (i'm sure you do), and __filename wont work on browsers, so i'm not going to take a crack at trying to implement this change.
BASENAMEOFSOUCEFILE should not include the full path as that can be determined from __filename, but replace the filename with the source name.
But then inside of __func, __srcName should be generated from the arguments and not a closured variable.
Streamline really shouldnt force the _.js style filenames on people. for example I have a module i'm working on that is designed to use multiple preprocessors named Aurora, and i've made the file extension configurable.
So I may transform a foo.src.js file into foo.js and then streamlines expectations get thrown out the door.
It's reasonable to expect OUTPUT to always be .js, though even making that configurable would be ideal, but input should be configurable.

Regarding the __rt.__func, this is feasible but it requires a bit more work on the transformation module.
I thought that it would be more efficient to alias all these functions to local variables. As these functions will usually be called many times this should lead to smaller code overall. Also, it eliminates one indirection in every call. What's your feeling about this?
I can do the second change (BASENAMEOFSOURCEFILE). I don't like the idea of having the file name as a string literal in every __func call. So it looks like I will need a local variable at file scope for it.
Also, I don't want to compute __srcName in every __func call (for obvious perf reasons), I want to have it pre-computed, or I can compute it from __filename and BASNAME... when formatting stack frames.

my goal for passing it over __func was so that you could get rid of the (__filename) on the require which creates a new object & context for every file.
If we simply have
var __rt = require('runtime');
__rt.__func(...); // etc

then we have 1 single context/object shared by EVERY streamlined file in the project.
If file size is a concern, you could shorten the variable names.
The output of a lines=preserve file is pretty hard to read as is, shortening to 1 letter names so its like
var $_=require('runtime')
$_.f(

instead of
var __rt = require('runtime');
__rt.__func(

(hey look, $ is S like, and _ is a line, Streamline ;))
Theres also the fact that browser source really needs some secondary considerations...
Browsers dont base on full file paths, they do URLs. File paths really should not be in the source of client side code at all, as that can expose some details about your project layout.
so honestly I believe client side code should be compiled seperately with different options, which could have a differently formatted runtime/generated code that was more optimized for browsers (smaller/compact code), where as node.js side would be more focused on cleaner and more performant code where file size doesn't matter at all.

Yes,  I got the point about having one global __func rather than one per file. And I'm ok with the one letter names. I'll do that part.
I was slightly concerned about the perf impact of __rt.__xxx(...) instead of just __xxx(...). But maybe this is irrelevant (I did not benchmark this).
My other concern is about having the file name as a string literal ("foobar_.js") in every __func call. My guess is that the compiler will intern all these literals but I just feel safer with one var __srcName = "foobar_.js"; at the top of the file and then passing __srcName to __func.

Also, i'm sorta mixing up both of my comments.
The idea for doing __rt.__func instead of __func was so that we could remove __func from the export function and simply have an object per file with 1 def per function.
But if we go the route of passing src file name to __func over params, then the export function can go away entirely, resulting in a much better system, then you could do the local variable names too.
Right now, the whole point of the exported function you pass __filename to is to  simply give __func details on what file the exception threw in.
This can be done much more effeciently and get rid of that wrapper func entirely

oh and storing srcName at top of file is def fine and yep a better idea.
The idea is to get all the file specific stuff out of runtime.js.
If V8 sees 40 files all accessing the same exact code, it can optimize that better.
But spawning up 40 objects and 40 contexts would have its own unneeded hit.
and Id think __rt.__func is identical to __func.
__func by itself is simply executing in global scope, where __rt.__func is executing in __rt scope.
Some would likely argue that looking up the global scope would actually be slower.

also, I could not see any need for the global.__g  in the runtime.js... I was going to remove it but saw it was referenced in some client side tests and such...
Is this really needed? I dont see it used anywhere in the server side aspect.

I've added some more commits to my branch
I've got the new installable runtime working.
found a huge bug with the output filename construction
js   = dirname + '/' + basename.substr(basename.length -1) + ext;

should of been
js   = dirname + '/' + basename.substr(0, basename.length -1) + ext;

not sure why we didnt see this before...
anyways, i noticed passing -c file_.js does not work always and needs to be file.js to be recompiled. will need to look into that.

Hi Daniel,
I've been busy with other things these last days and I'm in a conference till Wednesday. I'll try to look at your branch later this week. Sorry for the delay but I just had no time for streamline these days.

Hello Daniel,
I'm back in town after a busy week and I'd like to catch up. Can you send me a pull request so that I can integrate all your changes in my runtime branch. Then I'll try to patch things for the browser side and standalone modes.

I'm closing the issue after merging the runtime branch into master.
I gave up on the standalone option. It was just making thing more complex than necessary.
I did not keep the runtime installation feature. I think that people should install with npm -g. This is better than creating node_modules directories everywhere streamline is used.
The __func call is still duplicated in every file. I may get back to it and optimize later.


Slides/31 code snippets should use better names than single characters

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Toggling Multiselect removes all other options from the dropdown menu

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug
When viewing log files, selecting "Multiselect" removes all other options from the dropdown menu besides multiselect. Even if it is unselected, the list stays empty except for multiselect. Refreshing the page brings back all the dropdown menus with the multiselect option still correctly toggled.
To Reproduce
Steps to reproduce the behavior:

Go to System > Log Files > Web GUI (any log page is fine, the behavior is not observed on just Web GUI page)
Click on dropdown menu to select type of log to view
Toggle Multiselect
All other options disappear

Expected behavior
Expected behavior is that other dropdown menu items do not disappear
Describe alternatives you considered
A clear and concise description of any alternative solutions or workaround you considered.
Screenshots

Environment
OPNsense 23.7.9 (amd64).
Intel® Core™ i5-8500 3.0Ghz Hex Core
Network Intel® I350-T4

https://github.com/opnsense/core/commit/f2427d6173539cbc0da557f0a75aaf665f733dcc should do the trick, looks like a glitch in the bootstrap select component we use.


Fix for issue #69

[x] I've read and understood the Contributing guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've been mindful about doing atomic commits, adding documentation to my changes, not refactoring too much.
[x] I've a descriptive title and added any useful information for the reviewer. Where appropriate, I've attached a screenshot and/or screencast (gif preferably).
[ ] I've written tests to cover the new code and functionality included in this PR.
[x] I've read, agree to, and signed the Contributor License Agreement (CLA).

PR Summary

e.g. New functionality for producing whatsits.

Related Issues

e.g. Fixes #206 and closes #230

Test strategy

e.g. Add tests around whatsit production.

@bjab we've updated our CLA mechanism since this was posted. You can sign it with your github account, which is much easier. 👍

Fixed by #167


Error starting Kitematic using the app.asar file shipped with the InstallDocker.msi

Expected Behaviour
Expected Kitematic to load after install. It was installed by default using the InstallDocker.msi file outside of the Docker Toolkit for windows.
Actual Behaviour
Kitematic failed to load on startup. Prompted to use VirtualBox and then failed. When I replaced the app.asar file in the default install with the app.asar file from the version of Kitematic that ships with the Docker Toolkit the program ran and functioned properly.
Information about the Issue
Using Win 10 x64, all prerequisites were installed. I discovered the difference by installing the Docker Toolkit and then diff'ing the directories for the 2 versions. That said the version numbers of both builds are identical despite having a different payload.
Docker Install: version installed
Docker Toolkit:  version installed
Steps to reproduce the behavior

Check the app.asar files from the 2 linked packages above. If the differences are the result of the beta vs. stable channel then consider pushing some or all of the beta changes into the stable package.

@jangajack A new version of Kitematic should be cut next weel, which will hopefully solve this issue.
Toolbox and Docker for Windows use essentially the same Kitematic, but one installs it in a desired location the later only provides you with a zip.
An on-going discussion exists to include Kitematic as part of the InstallDocker.msi.
I'll keep this issue open until a new version is release, at which point I'll ping you to get some feedback, if that's ok?


Bad shape for unary energy

Hi,
I got the same issue now but somehow my code worked the day before. Did you do an update on your library?
This is the error, I got.
 25         U = unary_from_softmax(processed_prediction)
 26         U = np.ascontiguousarray(U) # necessary since the library pydensecrf is using a cython wrapper DEBUg

---> 27         dcrf_obj.setUnaryEnergy(U)
28
29         #pairwise potentials: color-independent -> only on feature location
pydensecrf/densecrf.pyx in pydensecrf.densecrf.DenseCRF.setUnaryEnergy()
ValueError: Bad shape for unary energy (Need (2, 1152), got (2, 147456))

Ok my bad, I had an issue in my code!


Error in create crud process

I have just installed the latest version of the package and got this error when creating crud
ErrorException
Trying to get property 'route' of non-object
at vendor/rezaamini-ir/laravel-easypanel/src/Parsers/StubParser.php:202
198▕             '{{ modelName }}' => ucfirst($modelName),
199▕             '{{ data }}' => $this->parseDataInBlade(),
200▕             '{{ titles }}' => $this->parseTitlesInBlade(),
201▕             '{{ inputs }}' => $this->parseInputsInBlade(),
➜ 202▕             '{{ routeName }}' => crud(strtolower($modelName))->route,
203▕         ];
204▕
205▕         $this->setLocaleTexts();
206▕
+28 vendor frames

29  artisan:37
Illuminate\Foundation\Console\Kernel::handle()
The steps I passed

install package
add admin user
create config file for Post model :: php artisan panel:config Post
and get this result
Post config file was created for Post model
You can manage it in : app/CRUD/PostComponent.php
php artisan panel:crud Post and then got the error

I think the documention is not clear and actually complete, and it makes using the package hard.

@luckyboy1001 Hi,
Please use GUI to create CRUD which is available on admin page.

I have tried it but got this error
Symfony\Component\Routing\Exception\RouteNotFoundException
Route [admin.user.read] not defined. (View: /home/mohammad/Desktop/open-source-projects/laravel-easy-panel/laravel-app/resources/views/vendor/admin/livewire/crud/create.blade.php)

First of all, uninstall the package completely with panel:uninstall command then clear the cruds table.
then you can re-execute panel:install command.

I have even created a new laravel project but get the same error
Symfony\Component\Routing\Exception\RouteNotFoundException
Route [admin.user.read] not defined. (View: /home/mohammad/Desktop/open-source-projects/laravel-easy-panel/laravel-app/resources/views/vendor/admin/livewire/crud/create.blade.php)
Could it not be compatible with Laravel latest version?

No, there was a problem with create page which was fixed.
Please update the package to 1.8.1 version with composer, then check it out.


How to define new leader key in doom?

What are you trying to achieve?
define personal leader key besides doom-leader-key and doom-localleader-key.
What have you tried?
(defconst uos/leader "s")

(map!
 :nvm "s" #'nil
 :prefix uos/leader
 "s" #'evil-snipe-s)

with the code below, s is undefined. How to let doom know s has been my another leader key?

(define-key evil-normal-state-map "s" nil)
  (defvar uos/leader "s")
(map!
 :prefix uos/leader
 :n "s" #'evil-snipe-s)

works
but defconst cannot do it...

So I have tow questions here:
How can I unset s in my own module inside DOOMDIR/modules/editor/keybinding?
because I hope to use uos/leader(s in my modules, I cannot unset it in DOOMDIR/config.el, which is always loadded after all modules loaded. I have tried some things like (require evil)/(after! evil)/(after evil-snipe-s)/(after evil-maps) and etc, none of them can work.
2. How to unbind it permanently

To disable s: disable evil-snipe

To define your own leader key:

If you a brand new, fresh leader key, then what you did will work, but is easily overwritten. If you bind it to general-override-mode-map will won't be overwritten.
If you want an alternative leader key (so SPC x and <newleaderkey> x) do the same thing, then:
(map! :map general-override-mode-map
      :nvm "<newleaderkey"> #'doom/leader
      :ei "<alternative-newleaderkey"> #'doom/leader)

Hope that helps!

Thanks! @hlissner
Is there any keys you recommend for personal leader?


docs: getting started

I want to review where all this content fits inside the docs as a whole, wanna make sure there is not duplicated content and makes sense in terms of learning curve! Let’s talk


Rename synthesized initializer test to follow the pattern

And also removed a test that is semantically a duplicate of the synthesized initializer test.

LGMT thanks for the cleanup.

@swift-ci please smoke test


Modified Hyperfind function into Library function

#5352

to convert the hyperfind function into library function

fix #[issue number that will be closed through this PR]
Describe the changes you've made
A clear and concise description of what you have done to successfully close your assigned issue. Any new files? or anything you feel to let us know!
Checklist:

[ ] My code follows the style guidelines of this project.
[ ] I have performed a self-review of my own code.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] I have made corresponding changes to the documentation.
[ ] My changes generate no new warnings.

Screenshots

Original
Updated

original screenshot
updated screenshot

@sairish Please review this


added meta html values

fix: #3033
Problem
The html_meta values were missing from most of the pages. These values are used to improve SEO. Omitting them results in errors when building the docs with Sphinx.
Solution offered
I've added the meta html values in every page with the exception of three pages, as their documentation is currently being built.

@ktsrivastava29 please add a changelog entry.

@stevepiercy Sorry, I missed adding that earlier, I've added it now

@stevepiercy Thank you for bringing up the required edits; I've now made the changes you suggested.

@stevepiercy  Yes, actually since there were so many changes, I felt that I should do it locally first.
Now I've incorporated the changes using the way you advised.

Thank you!


Document recent changes in NEWS and CHANGES

More should be added there

Seriously, we're really not treating these files well, at all

Merged.
faea3bd1339ac1029ab2bc746dfb7c891366d653 Document recent changes in NEWS and CHANGES


Intersection of two linked list in cpp

🚀 Feature
I would like to add the problem that is intersection two linked list in cpp.
Have you read the Contributing Guidelines on Pull Requests?
Yes
Motivation
(Please outline the motivation for the proposal.)
Pitch
(Please explain why this feature should be implemented and how it would be used.)

/assign


Add tapscript signature to rust client

Todo:

[ ] add test with hard coded apdu exchange
[ ] increase crate version

Codecov Report
Patch and project coverage have no change.

Comparison is base (250b327) 83.96% compared to head (a487240) 83.96%.

Additional details and impacted files
@@           Coverage Diff            @@
##           develop     #139   +/-   ##
========================================
  Coverage    83.96%   83.96%
========================================
  Files           17       17
  Lines         2189     2189
========================================
  Hits          1838     1838
  Misses         351      351

Flag
Coverage Δ

unittests
83.96% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[AB3: Tracing Code] Add Debugger features section

Current:
Debugger features introduction

Problem:
The use of the debugger features is relevant and crucial to the tutorial, but usage of these features are scattered with no explanation of what it means to show execution point, step into a method call, step over logging code or step out.
Proposed:
Include a section at the beginning to introduce features of the debugger and what they are used for.

Understanding Debugger Features
Before diving into tracing code with IntelliJ IDEA’s debugger, it’s essential to understand key debugger features and their purpose. These features help you step through code systematically, inspect variable values, and understand program flow during execution. Here are the primary debugger features you'll use:
Setting Breakpoints
Purpose: Breakpoints pause program execution at specific lines of code.
Usage: Place breakpoints at critical points where you want to examine the program state, such as method entry points or before complex operations.
Showing Execution Point
Purpose: Shows the current line of code where the debugger has paused execution.
Usage: Helps you navigate directly to the line where the program is halted, providing context for the next step.
Stepping Into a Method Call
Purpose: Steps into the implementation of a method called at the current execution point.
Usage: Useful for delving into how specific methods work, especially when you want to understand detailed functionality.
Stepping Over Code
Purpose: Executes the current line of code without stepping into method calls.
Usage: Used to skip over lines of code that are not critical for understanding the current flow, such as logging or simple getter/setter methods.
Stepping Out of a Method
Purpose: Executes the remaining lines of code in the current method and returns to the caller.
Usage: Useful when you've stepped into a method and want to quickly return to the higher-level context without stepping through every line.

@ruishanteo I've added a Intellij debugging tutorial here
Currently it has just a video (this is the same video given in week 6 topics)
Perhaps you can send a PR to add the content you proposed above to the same tutorial page?

I also came across this video https://www.youtube.com/watch?v=IeUZZoZE3sU
Do you think this is better than the one we use currently in https://se-education.org/guides/tutorials/intellijDebugger.html?

I’d like to share my thoughts on whether we should swap the tutorial video from the original to the new one.
Here’s a comparison of both videos based on my observations:
Original Video
Pros:

Demonstrates Watch Expression: This is can be used by users to monitor computed expression values during debugging.
Understandable Example: The example used and the problem faced felt more relatable and easier to follow.
Clear Explanations: The presenter frequently refers to the current code, making the context clearer.

Cons:

Older Interface: Might be unfamiliar to new users who are accustomed to more recent versions.
Long-Winded: Takes more time to explain and describe debugger features in relation to the code, which might be less efficient for some viewers.

New Video
Pros:

Newer Interface: More familiar to new users, reducing the learning curve.
Demonstrates Additional Features: Covers Execute Expression and Exception Breakpoint, which can be valuable tools.
Concise: Provides focused and concise descriptions of each feature.

Cons:

Complex Example: The battleship example might be harder to follow and less relatable.
Feature Listing: Feels more like listing features rather than a seamless problem-solving process.

TLDR, I think both videos have their strengths and weaknesses.
For newer users (which should be the target audience of this guide), the original video might be better as it explains the concept of debugging and illustrates it usefulness slightly better (imo).
I think we can still include timestamps for the other features not covered (execute expression and exception breakpoints) as part of the additions.
Let me know what you think!

@mfjkri Thanks for the insights!
I do agree that the battleship example is more complex and thus harder to follow. I thought that the original video went through each feature separately quite well and I do prefer it as well.
I'll include another section in my PR as an extension, for additional information like execute expression and exception breakpoints, linking to the new video.


Constants conflict

I recently installed php 7 on my computer without mbstring but when I ran some tests I had an error:
PHPUnit_Framework_Exception: PHP Notice:  Constant MB_CASE_UPPER already defined in /.../vendor/symfony/polyfill-mbstring/bootstrap.php on line 15

So I simply add checks before defining those constants.

@nicolas-grekas I guess you're in charge of this repository ?

@Ener-Getick can you check why are the consts already defined in your case please?

The first thing to know is that of course the mbstring is disabled.
I was able to reproduce the issue few days ago but today it was impossible... so i'll try again tomorrow.
I'll keep you aware if it happens again ☺(it happened when running the tests of one of the jms repository, i don't remember which one...)


pandas.Index.isin equivalent for daru

daru can take only an index for Daru::Index#include?(index)
On the other hand pandas.Index.isin can take a list.
I request the pandas.Index.isin equivalent for daru.

=> #<Daru::Index(4): {admit, gpa, gre, rank}>
irb(main):018:0> a1 = Daru::Index.new([:admit, :gpa, :gre, :rank])
=> #<Daru::Index(4): {admit, gpa, gre, rank}>
irb(main):019:0> a1.include?('gpa')
=> false

Output must be true, isn't it ?

@kozo2 Sorry for returning to the topic afert a such long time, but can you please explain what is the use case of pandas.Index.isin? And am I correct that it returns array the same size as index, responding to question "if i-th index value included in list provided?" It sounds a bit like "backwards logic" for me.


Training model on validation set

Hello, can you provide training model of Cars, Ped. and Cyc.

Hi @Chuanbo-Yu,
Models are under the checkpoint/ folder.
For the name conversion,  this may help: https://github.com/WeijingShi/Point-GNN/issues/2#issuecomment-599252221
Thanks,


Set up blackbox probing & alerts for the devfile.io domain

The transfer of domain registrar for the devfile.io domain resulted in a long outage of the devfile.io domain, and any service on it (registry.devfile.io, docs.devfile.io, etc). While we detected this outage relatively quickly, the prometheus alerts we have set up for the registry service were not triggered, despite the service being unavailable.
This exposed an issue in the current alert monitoring that we have set up for the devfile registry service - the alerts only work if DNS for the domain is actually configured and working properly. To fix this, It was suggested that we set up an additional prometheus scrape config to perform blackbox probes on the devfile.io domain to catch and send alerts, should there be further DNS issues with the domain in the future.

I've put up a Merge Request in Gitlab that sets up the blackbox checks for the devfile.io domain. Waiting on review from App-SRE now.


[SDK][INFINITY-1058] Fix statestore inconsistencies on startup

It is possible in some failure scenarios for TaskInfo and TaskStatus
objects regarding the same Task to have inconsistent TaskIDs.  This
breaks dependent logic that assumes TaskInfo and TaskStatus for the
same Task will share a TaskID.
TaskState is set to TASK_FAILED in the case of any detected inconsistency to
cause a restart of the Task and arrive at a categorically consistent state with Mesos.

retest this please


PawnHasJobUsing() not inspects pawn.CurJob.targetC

Just inspected a15-code with PVS-Studio and found follow:
// CommunityCoreLibrary\DLL_Project\Extensions\Thing_Extensions.cs

    public static bool PawnHasJobUsing( this Thing thing, Pawn pawn )
        {
            if(
                ( pawn == null ) ||
                ( pawn.CurJob == null )
            )
            {
                return false;
            }
            if(
                ( pawn.CurJob.targetA != null ) &&
                ( pawn.CurJob.targetA.Thing == thing )
            )
            {
                return true;
            }
            if(
                ( pawn.CurJob.targetB != null ) &&
                ( pawn.CurJob.targetB.Thing == thing )
            )
            {
                return true;
            }
            if(
                ( pawn.CurJob.targetB != null ) &&
                ( pawn.CurJob.targetB.Thing == thing )
            )
            {
                return true;
            }
            return false;
        }

There are two identical conditions with pawn.CurJob.targetB, it seems the last should be pawn.CurJob.targetC

P.S. Jetbrains Resharper's inspection shows huge possible bugs, one of them for ex.:
// CommunityCoreLibrary\DLL_Project\Controller\SubControllers\SequencedInjectors\SequencedInjectionSets\SequencedInjectionSet_Designator.cs:41 Possible 'System.NullReferenceException'

    public override bool IsValid()
        {
            bool valid = true;

            if(
                ( designatorClass == null )||
                ( !designatorClass.IsSubclassOf( typeof( Designator ) ) )
            )
            {
                CCL_Log.Trace(
                    Verbosity.Validation,
                    string.Format( "Unable to resolve designatorClass '{0}'", designatorClass.FullName ),
                    Name
                );
                valid = false;
            }
           ...

logging can't log an incorrect call (with designatorClass==null ) due to the fact that logging itself causes System.NullReferenceException

Thanks for catching those, this is by far the easiest bug report to find solutions for.  ;)


[MySQL]Mysql JSON Type is failed with syntax error

Environment
Liquibase Version: 4.6.1
Liquibase Integration & Version: 4.6.1
Liquibase Extension(s) & Version: 4.6.1
Database Vendor & Version: MySQL8.0.27
Operating System Type & Version: MacOS Monterey 12.0.1
Description
When I use liquibase diff 2 mysql 8.x database to generate changelog.mysql.sql with mysql connector 8.0.27 version. The JSON type is mapped to JSON(1073741824). When I try to apply this changelog.mysql.sql to mysql and got syntax error since JSON(1073741824) is not valid syntax.
Steps To Reproduce
Execute below command:
./liquibase diffChangeLog \
--url="jdbc:mysql://ip:3306/exchange" \
--username=root \
--password=root \
--referenceUrl="jdbc:mysql://ip2:3306/exchange" \
--referenceUsername=root \
--referencePassword=root \
--driver="com.mysql.cj.jdbc.Driver" \
--changelog-file="changelog.mysql.sql"

sql generated from generateChangeLog produces this sql fragment for the JSON field
CREATE TABLE rbt_message (id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, type VARCHAR(64) NOT NULL, content JSON(1073741824) NOT NULL, created_datetime timestamp DEFAULT NOW() NULL, CONSTRAINT PK_RBT_MESSAGE PRIMARY KEY (id));

Actual Behavior
When the above SQL statement is executed, the MySQL server will report a syntax error
If you manually edit to the below it works
CREATE TABLE rbt_message (id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, type VARCHAR(64) NOT NULL, content JSON NOT NULL, created_datetime timestamp DEFAULT NOW() NULL, CONSTRAINT PK_RBT_MESSAGE PRIMARY KEY (id));

Expected/Desired Behavior
The liquibase can produce correct sql like below:
CREATE TABLE rbt_message (id BIGINT UNSIGNED AUTO_INCREMENT NOT NULL, type VARCHAR(64) NOT NULL, content JSON NOT NULL, created_datetime timestamp DEFAULT NOW() NULL, CONSTRAINT PK_RBT_MESSAGE PRIMARY KEY (id));

Hi @Venus-WXP Thanks for creating this issue.  Do you have an example table that is in the database that shows the error?
We will add this to the list of issues to process.

CREATE

There is a table structure in our prod env can be used:
create table exchange.rbt_message
(
    id               bigint unsigned auto_increment comment 'primary key'
        primary key,
    type             varchar(64)                         not null comment 'message type',
    content          json                                not null comment 'message content',
    created_datetime timestamp default CURRENT_TIMESTAMP null on update CURRENT_TIMESTAMP
);

Hi @Venus-WXP Thanks for the table!

I also ran into this issue when running liquibase generate-changelog then liquibase update on a new target.
The generate-changelog command generates an output that includes the size for the JSON type. This apparently is invalid SQL and our changelog is in SQL format. When we run the update on a new server, the JSON(###) statement fails. I then manually remove the "(####)" and the statements succeed.
This is with MySQL server 5.7 and 8.0.
To recreate this issue:
run the generate-changelog command into a SQL formatted changelog.
Then run the changelog on a new database using the update command.
mysql> CREATE TABLE t1 (jdoc JSON);
Query OK, 0 rows affected (0.02 sec)

That worked however including a size after does not work.
mysql> CREATE TABLE t2 (jdoc JSON(10000));
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '(10000))' at line 1
mysql>

Still an issue on liquibase 4.15.

I have a PR which seems to fix this
https://github.com/liquibase/liquibase/pull/3849


python support

Python support much appreciated.
If you can show some pointers, I can give it a try too

Hey @sertaco - I think Python support should be fairly straightforward, I've just been swamped for the past month or so.
If you take a look at how the EnvFile plugin is handling it https://github.com/ashald/EnvFile/blob/develop/modules/products/pycharm/src/main/java/net/ashald/envfile/products/pycharm/PyCharmRunConfigurationExtension.java should give a baseline for how to adapt this plugin.
The trickiest part for me was probably the build system if you're not super familiar with Gradle (I mostly used maven when I was doing Java development on a daily basis). If you take a look at this PR diff you can see the changes I made to integrate with Go and Node run configs: https://github.com/Fapiko/intellij-better-direnv/commit/6aaaea87a418338ee3870f852d2195a5db2d85cb#diff-c0dfa6bc7a8685217f70a860145fbdf416d449eaff052fa28352c5cec1a98c06

Just pushed a PR for this - https://github.com/Fapiko/intellij-better-direnv/pull/6

This is in the latest release 0.3.0 - should be verified and available in a day or two.

I had a chance to try 0.3.0 today and could not make it work. Did anyone use Python direnv succesfully?

I'm actually noticing that this doesn't work on versions 2022.2 and newer, but does on 2022.1. So something has changed with the Python plugin execution path.

Added PR to address broken Python support in IDEA 2022.2+
https://github.com/Fapiko/intellij-better-direnv/pull/9

perfect! works as expected for 2022.2.1! thanks


New Function Publishing Help

Hello
I want to let you know that I have recently developed a function similar to Document.execCommand() with the latest javascript. As you might know, the mentioned function is obsolete and is subject to stop functioning on browsers, however, there is no alternative to it. Now I want to know if it is possible to implement the function I made into javascript source so that everyone can use it and do not waste their time on making it again.

Thanks for your report, however, MDN only documents standardized methods of the Web platform.


Couldn't retrieve versions for NodaTime

Starting with
$  cat paket.dependencies
source https://www.nuget.org/api/v2

nuget Fuchu
nuget Http.fs
nuget NodeTime
nuget NuGet.CommandLine

$ mono tools/paket.exe install
Paket version <IP_ADDRESS>
Dependencies files saved to Mailgun.Api/paket.dependencies
Resolving packages:
 - NuGet.CommandLine 2.8.5
 - Http.fs 1.5.1
 - Fuchu <IP_ADDRESS>
 - NodaTime 1.3.1

Now;
$  cat paket.dependencies
source https://www.nuget.org/api/v2

nuget Fuchu
nuget Http.fs
nuget NodaTime
nuget NodeTime
nuget NuGet.CommandLine

And... drums...
the returned data from NuGet:
[]

LOL @ me. Need vacation. NodeTime. Too much time spent fiddling with nodejs compilations.


feat: add support to create well-known attributes for blocks

Goes some way to solving https://github.com/infracost/infracost/issues/1856
Adds support to return well-known values for blocks where mock data is insufficient. This is mostly applicable to data blocks. In particular data blocks such as aws_availability_zones where the return values can be inferred and don't require account/api access. This PR allows us to override the Values function for the Block with a more specific value func.
Initial supported blocks are:

data.aws_availability_zones
data.google_compute_zones
resource.random_shuffle

This pr also resolves an issue where the provider data was being set incorrectly in the evaluation context, using the key provider instead of aws, google, e.t.c.

Note:

GCP/Azure test failures are on master - not related to these changes
zones_aws is incomplete at the moment until we enable more regions on our account - I will update when these come online


Fix SDL2 hash

See https://github.com/ruslo/hunter/issues/1032 for details

Testing:

https://ci.appveyor.com/project/ingenue/hunter/build/1.0.2365
https://travis-ci.org/ingenue/hunter/builds/275017007?utm_source=github_status&utm_medium=notification


Acquisition hangs when setting ROI.

Bug report

Bug summary

It seems that pycromanager is hanging after attempting to set the ROI.  The following code will not complete when run against the demo camera.
Code for reproduction

Core().set_roi(Core().get_camera_device(), 0,0,256,256)

roi = Core().get_roi(Core().get_camera_device())

print(f"ROI {[roi.x, roi.y, roi.width, roi.height]}")

e = multi_d_acquisition_events(num_time_points=5)

with pycromanager.Acquisition(directory="foo", name="test") as mmacquisition:

    print(f"Start acquisition")

   mmacquisition.acquire(e)

print(f"Acquisition complete")

Expected outcome
Completion

Actual outcome
Acquisition never completes

Version Info
Latest version of everything from repo.  Running on Windows 10.

Im not able to reproduce running on demo config. Is it possible something is amiss with the particular hard drive you're using?
If you want to test further whether this is specific to your system, you could try submitting a PR with this added to the tests and see if it completes successfully

Hmm... this is consistently failing for me.  In poking around, it looks like the events are never processed so this hangs in the await_completion call. Only happens if I have the set_roi, if its just get_roi, everything is ok.
I'm running latest version of everything on Windows 10.
Any suggestions as to where I might look to figure out what is going on?
Carl

I think I might have seen this the other day on an actual system, which used a Basler camera. Have you been seeing this with a Basler too? Do you have another camera you can swap and test? This may be a device adapter bug, which would explain why it doesn't happen with the demo config

Actually, I’m seeing this with the demo config on my system.  I have checked this carefully, but will do so again.
Carl
On Jun 21, 2023, at 5:39 PM, Henry Pinkard @.***> wrote:
I think I might have seen this the other day on an actual system, which used a Basler camera. Have you been seeing this with a Basler too? Do you have another camera you can swap and test? This may be a device adapter bug, which would explain why it doesn't happen with the demo config
—
Reply to this email directly, view it on GitHubhttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_issues_620-23issuecomment-2D1601861063&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=4Q4hAeymNHcW1IkMIBbmf4JjepJP-KqJCu8NJ1zMVL_lyqwwNLN_xfgkKTWvqXVr&s=WuS6zvCzq03V4H6xXMGWMzolwp71cc-6ZKfrg58shIU&e=, or unsubscribehttps://urldefense.us/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA3OGXSBJPMZG3OF2MIM7Z3XMOH5LANCNFSM6AAAAAAZKNCBFE&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=4Q4hAeymNHcW1IkMIBbmf4JjepJP-KqJCu8NJ1zMVL_lyqwwNLN_xfgkKTWvqXVr&s=z1HAb-ublBBDr6XArEcAm5JmZ1oRE9YZJmHirHmA0zw&e=.
You are receiving this because you authored the thread.Message ID: @.***>

If thats the case, then I think the best course of action would be to add to the acquisition tests and make a PR. That would guard this from being a bug in the future, and it would help me figure out why i dont see it.
You could also try turning on debug and core_log_debug in the acquisition and checking the python console and MM core log for anything suspicious

I”m seeing funny things… hold off until I can do a bit more. testing.
Carl

Dr. Carl Kesselman
William H. Keck Professor of Engineering
Professor, Epstein Department of Industrial and Systems Engineering
Professor, Ostrow School of Dentistry
Professor, Preventive Medicine Keck School of Medicine
Fellow, Information Sciences Institute
Viterbi School of Engineering
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA  90292-6695
Phone:  +1<PHONE_NUMBER>
Email:  @.***
Web: http://www.isi.edu/~carl
On Jun 22, 2023 at 1:34 PM -0700, Henry Pinkard @.***>, wrote:
If thats the case, then I think the best course of action would be to add to the acquisition testshttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_blob_main_pycromanager_test_test-5Facquisition.py&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=zCrkA1l-EjifkxXQ8x5d7fgw8RiBRKUpvpGI13AvTmc&e= and make a PR. That would guard this from being a bug in the future, and it would help me figure out why i dont see it.
You could also try turning on debug and core_log_debug in the acquisition and checking the python console and MM core log for anything suspicious
—
Reply to this email directly, view it on GitHubhttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_issues_620-23issuecomment-2D1603281074&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=saYzOxwyzlw51LwQeiiwtSHtEm-YSCmWDAzoTN_4u7g&e=, or unsubscribehttps://urldefense.us/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA3OGXRE7F3KXKBTF64TNJ3XMST57ANCNFSM6AAAAAAZKNCBFE&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=EeO01-HbEMGEAS8nWilxRLJr9W7WgKdDM7xWfCHHYUs&e=.
You are receiving this because you authored the thread.Message ID: @.***>

Yea, on Hamamatsu camera, if I set the ROI thrugh the Core object, I don’t get any images from the acquisitoin.  If I don’t set the ROI, everything is fine.  After setting the ROI, if I query, I do get back the updated value.
It looks like there is no code available for this driver…. but I wonder if the issue is somewhere in the shadow object?
Carl
On Jun 22, 2023, at 1:42 PM, Carl Kesselman @.***> wrote:
I”m seeing funny things… hold off until I can do a bit more. testing.
Carl

Dr. Carl Kesselman
William H. Keck Professor of Engineering
Professor, Epstein Department of Industrial and Systems Engineering
Professor, Ostrow School of Dentistry
Professor, Preventive Medicine Keck School of Medicine
Fellow, Information Sciences Institute
Viterbi School of Engineering
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA  90292-6695
Phone:  +1<PHONE_NUMBER>
Email:  @.***
Web: http://www.isi.edu/~carl
On Jun 22, 2023 at 1:34 PM -0700, Henry Pinkard @.***>, wrote:
If thats the case, then I think the best course of action would be to add to the acquisition testshttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_blob_main_pycromanager_test_test-5Facquisition.py&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=zCrkA1l-EjifkxXQ8x5d7fgw8RiBRKUpvpGI13AvTmc&e= and make a PR. That would guard this from being a bug in the future, and it would help me figure out why i dont see it.
You could also try turning on debug and core_log_debug in the acquisition and checking the python console and MM core log for anything suspicious
—
Reply to this email directly, view it on GitHubhttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_issues_620-23issuecomment-2D1603281074&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=saYzOxwyzlw51LwQeiiwtSHtEm-YSCmWDAzoTN_4u7g&e=, or unsubscribehttps://urldefense.us/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA3OGXRE7F3KXKBTF64TNJ3XMST57ANCNFSM6AAAAAAZKNCBFE&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=EeO01-HbEMGEAS8nWilxRLJr9W7WgKdDM7xWfCHHYUs&e=.
You are receiving this because you authored the thread.Message ID: @.***>

Ok… this seems to definitely be an issue with the hamamatsu drive.  The funny thing is that it seems to be ok when done from the script interface.  Also, if I do set_roi with the full camera size, its fine, but if I do any other size via the API the camera seems to go nuts.
Is there a difference in how the camera is controled when going via the micromanager script interface and the pycromanager API?
Thanks,
Carl
On Jun 28, 2023, at 8:19 PM, Carl Kesselman @.***> wrote:
Yea, on Hamamatsu camera, if I set the ROI thrugh the Core object, I don’t get any images from the acquisitoin.  If I don’t set the ROI, everything is fine.  After setting the ROI, if I query, I do get back the updated value.
It looks like there is no code available for this driver…. but I wonder if the issue is somewhere in the shadow object?
Carl
On Jun 22, 2023, at 1:42 PM, Carl Kesselman @.***> wrote:
I”m seeing funny things… hold off until I can do a bit more. testing.
Carl

Dr. Carl Kesselman
William H. Keck Professor of Engineering
Professor, Epstein Department of Industrial and Systems Engineering
Professor, Ostrow School of Dentistry
Professor, Preventive Medicine Keck School of Medicine
Fellow, Information Sciences Institute
Viterbi School of Engineering
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA  90292-6695
Phone:  +1<PHONE_NUMBER>
Email:  @.***
Web: http://www.isi.edu/~carl
On Jun 22, 2023 at 1:34 PM -0700, Henry Pinkard @.***>, wrote:
If thats the case, then I think the best course of action would be to add to the acquisition testshttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_blob_main_pycromanager_test_test-5Facquisition.py&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=zCrkA1l-EjifkxXQ8x5d7fgw8RiBRKUpvpGI13AvTmc&e= and make a PR. That would guard this from being a bug in the future, and it would help me figure out why i dont see it.
You could also try turning on debug and core_log_debug in the acquisition and checking the python console and MM core log for anything suspicious
—
Reply to this email directly, view it on GitHubhttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_issues_620-23issuecomment-2D1603281074&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=saYzOxwyzlw51LwQeiiwtSHtEm-YSCmWDAzoTN_4u7g&e=, or unsubscribehttps://urldefense.us/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA3OGXRE7F3KXKBTF64TNJ3XMST57ANCNFSM6AAAAAAZKNCBFE&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=EeO01-HbEMGEAS8nWilxRLJr9W7WgKdDM7xWfCHHYUs&e=.
You are receiving this because you authored the thread.Message ID: @.***>

A little more testing…..
Use micromanager server, not headless mode.  Test program uses pycromanager, just does a acquire of a couple events using a with block.
I use the script interface in micromanager to change the ROI.  If I set to full resolution (2048x2048) everything is fine.  If I use the script interface (mmc.setROI) to change the ROI to anything else, the acquisition hangs in pycromanager.  However, if I do the exact same acquisition in micromanger, it works fine.
Any thoughts?
Carl
On Jul 5, 2023, at 9:12 AM, Carl Kesselman @.***> wrote:
Ok… this seems to definitely be an issue with the hamamatsu drive.  The funny thing is that it seems to be ok when done from the script interface.  Also, if I do set_roi with the full camera size, its fine, but if I do any other size via the API the camera seems to go nuts.
Is there a difference in how the camera is controled when going via the micromanager script interface and the pycromanager API?
Thanks,
Carl
On Jun 28, 2023, at 8:19 PM, Carl Kesselman @.***> wrote:
Yea, on Hamamatsu camera, if I set the ROI thrugh the Core object, I don’t get any images from the acquisitoin.  If I don’t set the ROI, everything is fine.  After setting the ROI, if I query, I do get back the updated value.
It looks like there is no code available for this driver…. but I wonder if the issue is somewhere in the shadow object?
Carl
On Jun 22, 2023, at 1:42 PM, Carl Kesselman @.***> wrote:
I”m seeing funny things… hold off until I can do a bit more. testing.
Carl

Dr. Carl Kesselman
William H. Keck Professor of Engineering
Professor, Epstein Department of Industrial and Systems Engineering
Professor, Ostrow School of Dentistry
Professor, Preventive Medicine Keck School of Medicine
Fellow, Information Sciences Institute
Viterbi School of Engineering
University of Southern California
4676 Admiralty Way, Suite 1001, Marina del Rey, CA  90292-6695
Phone:  +1<PHONE_NUMBER>
Email:  @.***
Web: http://www.isi.edu/~carl
On Jun 22, 2023 at 1:34 PM -0700, Henry Pinkard @.***>, wrote:
If thats the case, then I think the best course of action would be to add to the acquisition testshttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_blob_main_pycromanager_test_test-5Facquisition.py&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=zCrkA1l-EjifkxXQ8x5d7fgw8RiBRKUpvpGI13AvTmc&e= and make a PR. That would guard this from being a bug in the future, and it would help me figure out why i dont see it.
You could also try turning on debug and core_log_debug in the acquisition and checking the python console and MM core log for anything suspicious
—
Reply to this email directly, view it on GitHubhttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_issues_620-23issuecomment-2D1603281074&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=saYzOxwyzlw51LwQeiiwtSHtEm-YSCmWDAzoTN_4u7g&e=, or unsubscribehttps://urldefense.us/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA3OGXRE7F3KXKBTF64TNJ3XMST57ANCNFSM6AAAAAAZKNCBFE&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=Y4HbnVNv1NNqs-u74J0fR0Z_zTwn3buFkqr84CcZqtAb_JReDmv002MsRuerMV2Q&s=EeO01-HbEMGEAS8nWilxRLJr9W7WgKdDM7xWfCHHYUs&e=.
You are receiving this because you authored the thread.Message ID: @.***>

Is there a difference in how the camera is controled when going via the micromanager script interface and the pycromanager API?

if you're doing mmc. in the script interface versus core. in PM, then no. These should be the exact same.

I use the script interface in micromanager to change the ROI. If I set to full resolution (2048x2048) everything is fine. If I use the script interface (mmc.setROI) to change the ROI to anything else, the acquisition hangs in pycromanager. However, if I do the exact same acquisition in micromanger, it works fine. Any thoughts?

This sounds to me like there is a bug in the Hammumatsu code for setting ROIs that gets the camera into a bad state, and then the acquisition engine gets stuck due to some freeze.
I think the easiest way to debug this would be to make a script that calls the core directly and see if you can isolate the problem with a minimal example. It should be something like this (I didn't test it--might need some tweaking):
sequence_length = 100

# TODO: change ROI

if sequence_length == 1:
   core.snap_image()
else:
   core.start_sequence_acquisition(100, 0, True) # acquire 100 images

if sequence_length == 1:
   image = core.get_tagged_image(0)
else:
   count = 0
   while count < sequence_length:
      try:
        image = core.pop_next_tagged_image()
        count += 1
     except:
        pass

Ok… interesting.
If I set ROI and then run acquision using Acquisition class, things hang.
If I set ROI and then run your code, it works.
If I then run the code that uses the Acquisition class after running the snap_image  code, it no longer hangs.
So while this does suggest something funny is going on in the camera, its still curious that the behavior when using snap_image/get_tagged_image is different than using the Acquisition class.
Carl
On Jul 6, 2023, at 10:24 AM, Henry Pinkard @.***> wrote:
Is there a difference in how the camera is controled when going via the micromanager script interface and the pycromanager API?
if you're doing mmc. in the script interface versus core. in PM, then no. These should be the exact same.
I use the script interface in micromanager to change the ROI. If I set to full resolution (2048x2048) everything is fine. If I use the script interface (mmc.setROI) to change the ROI to anything else, the acquisition hangs in pycromanager. However, if I do the exact same acquisition in micromanger, it works fine. Any thoughts?
This sounds to me like there is a bug in the Hammumatsu code for setting ROIs that gets the camera into a bad state, and then the acquisition engine gets stuck due to some freeze.
I think the easiest way to debug this would be to make a script that calls the core directly and see if you can isolate the problem with a minimal example. It should be something like this (I didn't test it--might need some tweaking):
sequence_length = 100
TODO: change ROI
if sequence_length == 1:
core.snap_image()
else:
core.start_sequence_acquisition(100, 0, True) # acquire 100 images
if sequence_length == 1:
image = core.get_tagged_image(0)
else:
count = 0
while count < sequence_length:
try:
image = core.pop_next_tagged_image()
count += 1
except:
pass
—
Reply to this email directly, view it on GitHubhttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_issues_620-23issuecomment-2D1624043579&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=WVaR5SsvNum7JSbudVkj1mermsC4XMGOx7fnWK2WByohWAtAICiqwb_BI5OwCRgn&s=MpyZtHsRzlps3QKhvjSPXrtIJggTW10WigSYV0FKKLQ&e=, or unsubscribehttps://urldefense.us/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA3OGXRANCJYRXFD4HMSWW3XO3YEPANCNFSM6AAAAAAZKNCBFE&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=WVaR5SsvNum7JSbudVkj1mermsC4XMGOx7fnWK2WByohWAtAICiqwb_BI5OwCRgn&s=C8fv7LyBfaerzcCtr91ARLWtinoLYFuA9Yi_PiwG1M0&e=.
You are receiving this because you authored the thread.Message ID: @.***>

Ok… so here is the funny bit.  If I add:
core.start_sequence_acquisition(1, 0, True)  # acquire 100 images
try:
image = core.pop_next_tagged_image()
except:
pass
to my code, after I set the ROI, then the subsequent Acquisition class operations seem to work.
While I am prepared to believe that there is something wonky in the camera driver… it also does seem that there is something slightly different going on in the acquisition code that is causing this issue to show up.
Carl
On Jul 6, 2023, at 11:48 AM, Carl Kesselman @.***> wrote:
Ok… interesting.
If I set ROI and then run acquision using Acquisition class, things hang.
If I set ROI and then run your code, it works.
If I then run the code that uses the Acquisition class after running the snap_image  code, it no longer hangs.
So while this does suggest something funny is going on in the camera, its still curious that the behavior when using snap_image/get_tagged_image is different than using the Acquisition class.
Carl
On Jul 6, 2023, at 10:24 AM, Henry Pinkard @.***> wrote:
Is there a difference in how the camera is controled when going via the micromanager script interface and the pycromanager API?
if you're doing mmc. in the script interface versus core. in PM, then no. These should be the exact same.
I use the script interface in micromanager to change the ROI. If I set to full resolution (2048x2048) everything is fine. If I use the script interface (mmc.setROI) to change the ROI to anything else, the acquisition hangs in pycromanager. However, if I do the exact same acquisition in micromanger, it works fine. Any thoughts?
This sounds to me like there is a bug in the Hammumatsu code for setting ROIs that gets the camera into a bad state, and then the acquisition engine gets stuck due to some freeze.
I think the easiest way to debug this would be to make a script that calls the core directly and see if you can isolate the problem with a minimal example. It should be something like this (I didn't test it--might need some tweaking):
sequence_length = 100
TODO: change ROI
if sequence_length == 1:
core.snap_image()
else:
core.start_sequence_acquisition(100, 0, True) # acquire 100 images
if sequence_length == 1:
image = core.get_tagged_image(0)
else:
count = 0
while count < sequence_length:
try:
image = core.pop_next_tagged_image()
count += 1
except:
pass
—
Reply to this email directly, view it on GitHubhttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_issues_620-23issuecomment-2D1624043579&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=WVaR5SsvNum7JSbudVkj1mermsC4XMGOx7fnWK2WByohWAtAICiqwb_BI5OwCRgn&s=MpyZtHsRzlps3QKhvjSPXrtIJggTW10WigSYV0FKKLQ&e=, or unsubscribehttps://urldefense.us/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA3OGXRANCJYRXFD4HMSWW3XO3YEPANCNFSM6AAAAAAZKNCBFE&d=DwMCaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=WVaR5SsvNum7JSbudVkj1mermsC4XMGOx7fnWK2WByohWAtAICiqwb_BI5OwCRgn&s=C8fv7LyBfaerzcCtr91ARLWtinoLYFuA9Yi_PiwG1M0&e=.
You are receiving this because you authored the thread.Message ID: @.***>

Ok… so here is the funny bit. If I add: core.start_sequence_acquisition(1, 0, True) # acquire 100 images try: image = core.pop_next_tagged_image() except: pass to my code, after I set the ROI, then the subsequent Acquisition class operations seem to work. While I am prepared to believe that there is something wonky in the camera driver… it also does seem that there is something slightly different going on in the acquisition code that is causing this issue to show up.

Oh that is strange. I think the easiest way to debug this is to get a debugger in the Java code for the acquisition engine. Are you willing/able to give that a try? I can guide you through the setup

Hi,
Willing to give a try, but I’m not really a Java programmer.  Let me wait until someone in my group who is comes back from vacation and I’ll give it a shot.  I may need help on the setup.
Thanks,
Carl
On Jul 6, 2023, at 4:18 PM, Henry Pinkard @.***> wrote:
Ok… so here is the funny bit. If I add: core.start_sequence_acquisition(1, 0, True) # acquire 100 images try: image = core.pop_next_tagged_image() except: pass to my code, after I set the ROI, then the subsequent Acquisition class operations seem to work. While I am prepared to believe that there is something wonky in the camera driver… it also does seem that there is something slightly different going on in the acquisition code that is causing this issue to show up.
Oh that is strange. I think the easiest way to debug this is to get a debugger in the Java code for the acquisition engine. Are you willing/able to give that a try? I can guide you through the setup
—
Reply to this email directly, view it on GitHubhttps://urldefense.us/v2/url?u=https-3A__github.com_micro-2Dmanager_pycro-2Dmanager_issues_620-23issuecomment-2D1624422819&d=DwMFaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=1gYvzzBdRxDSJ9lVzDz-bZL_zTOoPWGp4S9FLOkEsEI_XTIhSR7Pe1VmbJJljvmj&s=gSDZbQ5cByQhhz0ZJADP5VXUWMVl2L2ppmeG8k08kwY&e=, or unsubscribehttps://urldefense.us/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AA3OGXSU7CO2LBFW2VIQ423XO5BTDANCNFSM6AAAAAAZKNCBFE&d=DwMFaQ&c=qzHnJIRvjI6L-clJH8JwLQvf_Iq43fzikf6aoxZgMb8&r=sGCma2ufaUVT-N141kRIZQ&m=1gYvzzBdRxDSJ9lVzDz-bZL_zTOoPWGp4S9FLOkEsEI_XTIhSR7Pe1VmbJJljvmj&s=QbdLRkBIbaCu2g28CQLb-AZyLxnIHB5iMa3Togx8fYQ&e=.
You are receiving this because you authored the thread.Message ID: @.***>

Okay sounds good. There's some setup instructions here. Don't hesitate to ask questions once you get to it

Okay I made a PR that I think fixes this. In the mean time you may be able to work around by calling core.initialize_circular_buffer() just after setting the ROI
Thanks for the patience with this @carlkesselman !

Yep… the work around fixes my issue.
Thanks!!
Carl
On Jul 29, 2023, at 9:58 AM, Henry Pinkard @.***> wrote:
ore.initialize_circular_buffer()


Add smart NERDTree open.

Option added - when opening single file do not open NERDTree. Do so only if directory is intended to be opened.

This sounds like a good idea! 👍


reduce big images, manually for now

Hey @mspector13,
Can you please reduce all images in figures/ to being less than 1 MB in size, upload to Gdrive and update the Gsheet Master_OCNMS_infographic_content with the smaller image_link accordingly?

You'll need to reference the image_path column in data/gsheets/figures.csv and when done run:
source("render_site_v2.R")

Ok, it turns out that only about 9 figures were > 1MB so I only reduced those ones. Instead of messing with the original folders, I added them to a new shared folder Figures_reduced and made sure to share the folder + individual images with the "shares" email account
However, when I try to run source("render_site_v2.R") I get the following error:
Error: file.exists(google_sa_json) is not TRUE
Also, Line 34 in the master ocnms spreadsheet (fish-assemblage, Trends - black rockfish) currently calls figures/Appendix S.LR.13.19 - Density of red urchins in kelp forest 2015-2019.jpg which is weird... is that a mistake?

Please see test_gs4_auth.Rmd for more on how you can point to the path for your authorization JSON file.

Right on, thanks for your patience @bbest! I added the pathway to my JSON credentials in `render_site_v2.R" on line 21:

It took a while for create_modals() and render_modals() to execute for the first time, but so far everything looks relatively good within individual modal windows.
However, as noted in noaa-onms/ocnms/issues/#15 we need to finalize modal window templates
Further, as noted in issue #11 we need to get Scenes working as well. This is what happens when I try to knit any of the scenes (e.g. kelp_forest.Rmd)

If I'm understanding this error message correctly, r infographiqR::ocnms_get_modal_info() is looking for a sheet named "pages" in the ocnms master spreadsheet. Does that mean we just need to change the syntax in r infographiqR::ocnms_get_modal_info()?


Depth test function should use GL_LESS

To match issue for ES (behavior change should ideally be coordinated): https://github.com/tangrams/tangram-es/issues/592
Testing with GL_LESS instead of GL_LEQUAL should result in many fewer fragments being processed with no change in visual quality.
The only cases where this could change visual results would be overlapping geometries set to the same order, but this case is effectively a user error and those geometries will have visual artifacts from z-fighting anyway.

See https://github.com/tangrams/tangram-es/issues/592 and consider putting this into v0.7.0 as well.

Closed via #283


news-extractor job

read feed source from es
filter sources to be extracted
extract feeds
extract main article
save feeds to kafka
update stats into es

moving to spark streaming


Several ng update display fixes for v18

See individual commits.

Hey @clydin I believe this fixes #27660, might as well associate & close it from the PR :)


Iss47

This adds clearer error handling to api.js, now when a message is left blank or you are not connected to the server the software will let the user know that their message was blank or that they are not connected to the server. Initially handled this in Linkencoder.js but changed to api.js because it was cleaner.

CI build failed -

basic_tests.spec.ts:130:1 › renders the zoom page =============================================
2022-11-07T18:20:27.1507290Z
2022-11-07T18:20:27.1507920Z     Test timeout of 30000ms exceeded.
2022-11-07T18:20:27.1508360Z
2022-11-07T18:20:27.1509060Z     frame.waitForSelector: Target closed
2022-11-07T18:20:27.1509980Z     =========================== logs ===========================
2022-11-07T18:20:27.1510640Z     waiting for selector "h1" to be visible
2022-11-07T18:20:27.1511450Z     ============================================================
2022-11-07T18:20:27.1511880Z
2022-11-07T18:20:27.1512690Z       135 |     page.locator('a:has-text("Zoom")').click()
2022-11-07T18:20:27.1513310Z       136 |   ]);
2022-11-07T18:20:27.1514540Z     > 137 |   await window.waitForSelector('h1')
2022-11-07T18:20:27.1518170Z           |                ^
2022-11-07T18:20:27.1518980Z       138 |   const text = await page.$eval('h1', (el) => el.textContent)
2022-11-07T18:20:27.1519580Z       139 |   expect(text).toBe('Zoom')
2022-11-07T18:20:27.1519940Z       140 |   page = window.page()
2022-11-07T18:20:27.1521950Z

I expect these changes are still being tested with the old test code of the staging branch. (i.e. 30s)
Did you try making a github action on your own branch to test it.

From the github action log you can see it timedout > 30s. So I propose I accept these changes even though they failed to build. Thoughts?
1) basic_tests.spec.ts:130:1 › renders the zoom page =============================================
2022-11-17T01:05:45.9384248Z
2022-11-17T01:05:45.9384564Z     Test timeout of 30000ms exceeded.
2022-11-17T01:05:45.9384812Z
2022-11-17T01:05:45.9385044Z     frame.waitForSelector: Target closed
2022-11-17T01:05:45.9385433Z     =========================== logs ===========================
2022-11-17T01:05:45.9385823Z     waiting for selector "h1" to be visible
2022-11-17T01:05:45.9386184Z     ============================================================
2022-11-17T01:05:45.9386451Z
2022-11-17T01:05:45.9386768Z       134 |     page.locator('a:has-text("Zoom")').click()
2022-11-17T01:05:45.9387081Z       135 |   ]);
2022-11-17T01:05:45.9387480Z     > 136 |   await window.waitForSelector('h1')
2022-11-17T01:05:45.9387785Z           |                ^
2022-11-17T01:05:45.9388307Z       137 |   const text = await page.$eval('h1', (el) => el.textContent)
2022-11-17T01:05:45.9388746Z       138 |   expect(text).toBe('Zoom')
2022-11-17T01:05:45.9389081Z       139 |   page = window.page()
2022-11-17T01:05:45.9389296Z
2022-11-17T01:05:45.9389580Z         at /home/runner/work/CTCast/CTCast/testing/basic_tests.spec.ts:136:16
2022-11-17T01:05:45.9390093Z         at /home/runner/work/CTCast/CTCast/node_modules/@playwright/test/lib/workerRunner.js:426:9
2022-11-17T01:05:45.9390671Z         at TestInfoImpl._runFn (/home/runner/work/CTCast/CTCast/node_modules/@playwright/test/lib/testInfo.js:166:7)
2022-11-17T01:05:45.9393827Z         at /home/runner/work/CTCast/CTCast/node_modules/@playwright/test/lib/workerRunner.js:376:26
2022-11-17T01:05:45.9394578Z         at TimeoutRunner.run (/home/runner/work/CTCast/CTCast/node_modules/playwright-core/lib/utils/timeoutRunner.js:53:14)
2022-11-17T01:05:45.9395234Z         at TimeoutManager.runWithTimeout (/home/runner/work/CTCast/CTCast/node_modules/@playwright/test/lib/timeoutManager.js:73:7)
2022-11-17T01:05:45.9395878Z         at TestInfoImpl._runWithTimeout (/home/runner/work/CTCast/CTCast/node_modules/@playwright/test/lib/testInfo.js:154:26)
2022-11-17T01:05:45.9396489Z         at WorkerRunner._runTest (/home/runner/work/CTCast/CTCast/node_modules/@playwright/test/lib/workerRunner.js:356:5)
2022-11-17T01:05:45.9397810Z         at WorkerRunner.runTestGroup (/home/runner/work/CTCast/CTCast/node_modules/@playwright/test/lib/workerRunner.js:218:11)
2022-11-17T01:05:45.9398708Z         at process.<anonymous> (/home/runner/work/CTCast/CTCast/node_modules/@playwright/test/lib/worker.js:88:5)
2022-11-17T01:05:45.9399020Z
2022-11-17T01:05:45.9399284Z   Slow test file: basic_tests.spec.ts (31s)
2022-11-17T01:05:45.9399708Z   Consider splitting slow test files to speed up parallel execution
2022-11-17T01:05:45.9399974Z
2022-11-17T01:05:45.9400120Z   1 failed
2022-11-17T01:05:45.9400651Z     basic_tests.spec.ts:130:1 › renders the zoom page ==============================================
2022-11-17T01:05:45.9400998Z   6 passed (38s)


How to start preprocess the data

I have carried out relevant operations according to the README.md, and I have reached the part of preprocess the data. Now, I don't know what to do next, because I got the feedback "nnFormer_convert_decathlon_task: 未找到命令" when I using "nnFormer_convert_decathlon_task -i ../DATASET/nnFormer_raw/nnFormer_raw_data/Task02_Synapse"
so, what command should I enter

You can input the path ../Task02_Synapse.It can convert data in raw/nnFormer_raw_data automaticly


Remove fixed positioning to enable flow on mobile

I think this fixed the view on mobile browsers. Tested locally in emulation.
@vtattyba @sam1010k @RigatoniRex
Also did another MR to rename to Green Energy

Thanks for taking care of this.

No prob!
On Thu, Aug 31, 2023 at 9:58 PM Vladimir Tattybayev <
@.***> wrote:

Thanks for taking care of this.
—
Reply to this email directly, view it on GitHub
https://github.com/PSUCapstone2023-Group1/Clean-Energy-PA/pull/72#issuecomment-1702006571,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJ5NHKRRDC33PGR6XARUKDXYE6NPANCNFSM6AAAAAA4G2UP7Y
.
You are receiving this because you authored the thread.Message ID:
@.***>

Looks good to me!


[SPARK-38692][SQL] Use error classes in the compilation errors of function args

What changes were proposed in this pull request?
Migrate the following errors in QueryCompilationErrors:

invalidFunctionArgumentsError
invalidFunctionArgumentNumberError
functionAcceptsOnlyOneArgumentError
secondArgumentNotDoubleLiteralError
functionCannotProcessInputError
v2FunctionInvalidInputTypeLengthError
secondArgumentInFunctionIsNotBooleanLiteralError

Why are the changes needed?
To follow the error class framework and improve test coverage.
Does this PR introduce any user-facing change?
No.
How was this patch tested?

build/sbt "test:testOnly *QueryCompilationErrorsSuite"

cc @MaxGekk

Can one of the admins verify this patch?

@lvshaokang Could you resolve conflicts, please.

@MaxGekk PTAL.I have resolved conflicts,thanks.

@MaxGekk Sry.I recently had time to complete this issue.Please take a look this pr.I unifyed the error class message and moved the INVALID_PARAMETER_VALUE to INVALID_FUNCTION_ARGUMENTS , because of i think parameter value belong to funcation arguments scope.


Fix XSS vulnerability

Function name can be contained html tags. (e.g. xss-poc.zip)
When it is displayed, will run the JavaScript.

xss-poc.zip

Hehe I like it. Thanks for the PR.

ur welcome ☆（ゝω・）v


[Snyk] Security upgrade react-native from 0.74.0 to 0.76.0

Snyk has created this PR to fix 6 vulnerabilities in the npm dependencies of this project.
Snyk changed the following file(s):

package.json
package-lock.json

Vulnerabilities that will be fixed with an upgrade:

Issue
Score

Uncontrolled resource consumption SNYK-JS-BRACES-6838727
  696

Denial of Service (DoS) SNYK-JS-WS-7266574
  696

Missing Release of Resource after Effective Lifetime SNYK-JS-INFLIGHT-6095116
  631

Inefficient Regular Expression Complexity SNYK-JS-MICROMATCH-6838728
  589

Cross-site Scripting SNYK-JS-SEND-7926862
  319

Cross-site Scripting SNYK-JS-SERVESTATIC-7926865
  319

[!IMPORTANT]

Check the changes in this PR to ensure they won't cause issues with your project.
Max score is 1000. Note that the real score may have changed since the PR was raised.
This PR was automatically created by Snyk using the credentials of a real user.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

Learn how to fix vulnerabilities with free interactive lessons:
🦉 Uncontrolled resource consumption
🦉 Cross-site Scripting

Closing this pull request as it's outdated.


SSIS File System Support

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

Can one of the admins verify this patch?

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-python

Automation for azure-sdk-for-go

Automation for azure-sdk-for-net
A PR has been created for you:
https://github.com/azure/azure-sdk-for-net/pull/5739
.NET SDK Commits:
https://github.com/adxsdknet/azure-sdk-for-net/pull/5739/commits/d5e28c6bf69a6eb471530e44648e39f3d63be349

Automation for azure-sdk-for-js

Automation for azure-sdk-for-java

@HaoQian-MS please let me know if the properties have been deployed, if so I can approve and merge this PR.
Please resolve conflicts.

@veronicagg , we decided to hold this change currently as some adjustment is needed for our feature.

@HaoQian-MS ok, thanks for letting me know. Should we close the PR until you're ready to come back to it?

@veronicagg  , if it's closed, can I reopen it later? If not, can we keep it open?

@HaoQian-MS yes, we can reopen it at anytime, just let me know if you're not able to reopen it. Thanks!


Change date value programmatically !

Hello,
I need to change the date value programmatically, is there any solution!
Thanks.

Hey,
What your means exactly of (programmatically)?

Besides datepicker I have a timeline slider. when this slider change I wanna update datepicker input value.

Besides datepicker I have a timeline slider. when this slider change I wanna update datepicker input value.

Yes, it seems the DatePicker component's value not getting update when it changed.
I'll solve this issue as soon as possible. Thanks for reporting this issue 🙂
If you want to implement it, feel free to open a PR  🙂

Thank you for your response 👍

please close the issue if it's fixed 🙏
@rzkhosroshahi @HamedMoghadasi


Inconsistent use of FrozenBatchNorm in Faster-RCNN?

Hi,
while customizing and training a Faster-RCNN object detection model based on torchvision.models.detection.faster_rcnn, I've noticed that the pre-trained model of type fasterrcnn_resnet50_fpn_v2 always use nn.BatchNorm2d normalization layers, while fasterrcnn_resnet50_fpn uses torchvision.models.ops.misc.FrozenBatchNorm2d when pretrained weights are loaded. I've noticed deteriorating performance of the V2 model when training a COCO pretrained model with low batch size. I am suspecting that this is related to the un-frozen nn.BatchNorm2d layers, and indeed, replacing nn.BatchNorm2d with torchvision.models.ops.misc.FrozenBatchNorm2d improves the performance for my task.
Thus, my question is: Is this discrepancy in normalization layers intentional, and if yes what could be other reasons for V2 model underperforming compared to the V1 model?
I'm using pytorch 1.12, torchvision 0.13.
Thanks!
cc @datumbox

@MoPl90  Thanks for the question.
The change was intentional. The specific heuristic was previously used to assist with small batch size training. Unfortunately there was a bug on the logic on when the BN should be replaced, see #5443 for details. On V2, we got better results without freezing the BN and using syncBN instead, so we removed the heuristic.

Thanks for the quick reply. That's interesting, I'll have a closer look then.

I have come across the same issue. Similar to @MoPl90, I have also found fasterrcnn_resnet50_fpn_v2 to perform substantially worse than fasterrcnn_resnet50_fpn on a finetuning task, and I am wondering if the batchnorm layers might be the cause.
@datumbox I understand that BN layers were not frozen when training the FasterRCNN_ResNet50_FPN_V2_Weights checkpoint. But wouldn't it still make sense for downstream users of that checkpoint to freeze the batchnorm layers?
Currently, this is not possible (unless you re-write fasterrcnn_resnet50_fpn_v2()).


opt infer result column name in ctas and query stmt

Proposed changes
Infer name if it is an expression and doesn't alias artificially when create or select stmt in nereids.
The infer name strategy is the same as #24990
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run buildall

run buildall


File not redrawn in Chrome after visiting some sites (e.g., amazon.com)

Attach (recommended) or Link to PDF file here: https://arxiv.org/pdf/1808.01102.pdf
Configuration:

Web browser and its version: Chrome Version 77.0.3830.3 (Official Build) canary (64-bit)
Operating system and its version: Windows 10.0.17134
PDF.js version: 2.2.191
Is a browser extension: Yes

Steps to reproduce the problem:

Open file
Open new tab
Open amazon.com
Switch back to the tab with the file

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

This really sounds entirely like a browser bug, rather than a PDF.js library one, and as such you'll need to report it to the browser vendor instead (since we cannot fix broken canvas rendering of the browser itself).

Except for some weird behavior:

it happens only on pages drawn by the extension
if I have two tabs open with the extension, when one of them gets corrupted, activating the second one and then switching back to the first one clears the problem

So it sounds like the problem is specific to the extension (not necessarilly in the extension, but to the interaction of the extension with the browser)

Found the culprit: the Set Character Encoding extension.
Closing.
Sorry.


Syntax highlighting for non standard extensions.

Hi ,
Great extension. Was just wondering if there could be added support for non standard file name extensions. At the moment it's probably .cg .hlsl .shader , etc , but we use a proprietary extension at work.  Thanks

+1
for UE4 .usf files


Game freezes when window is closed on Mac on LibGDX 1.11.0 and LWJGL3

Issue details
After I launch the game on Android Studio (DesktopLauncher.main) if I close the game using Cmd-Q, I get randomly one of these outcomes:

freezes for a few seconds and then process stops gracefully; or
freezes for several minutes (maybe/probably indefinitely, didnt wait much to test, I force STOP after a while); or
locks Android Studio completely (happened only once, might be unrelated, but it feels like it is related)

Reproduction steps/code
This issue is happening only after migrating to LibGDX 1.11.0 and LWJGL3, and never happened before (ie, on 1.10 & non-LWJGL3). This happens on the default generated project (badlogic.jpg one), the only change I have to do is add the extension to gradle: gdx-lwjgl3-glfw-awt-macos . I made no other change to the project.
Version of libGDX and/or relevant dependencies
Latest OSX. Non-M1 mac. LibGDX 1.11.0 with gdx-lwjgl3-glfw-awt-macos extension.
Stacktrace
EventQueue class ->  getNextEvent() method -> freezes on pushPopCond.await()
Threads:
"AWT-EventQueue-0"@1,047 in group "main": WAIT
"AppKit Thread"@989: RUNNING
"AWT-Shutdown" @992: WAIT
"Common-Cleaner" @419 in group "InnocuousThreadGroup": WAIT
"DestroyJavaVM"@1,681 in group "main": RUNNING
"Finalizer" @1,683: WAIT
"Reference Handler" @1,682: RUNNING
"Signal Dispatcher" @1,684: RUNNING
Please select the affected platforms

[ ] Android
[ ] iOS
[ ] HTML/GWT
[ ] Windows
[ ] Linux
[X] macOS

Does this issue occur with LWJGL3's own glfw_async library? You can load it early in your main() method using:
Configuration.GLFW_LIBRARY_NAME.set("glfw_async"); per the docs
It's preferable not to be stuck in a situation where we're recommending XstartOnFirstThread. That approach has its own caveats, like being unable to use AWT/Swing at all.

These glfw async libraries are fundamentally incompatible with the -XstartOnFirstThread JVM arg, which is why you were crashing in the first scenario.

So I should simply add that line to my main method and that fixes it? Is this a "safe" solution, or more like a temporary hack?

I don't think I'd regard it as a temporary hack. It's a recent addition to lwjgl3 3.3.1 and I'd guess it was split to ensure that there's a fallback in case it's buggy. Not sure if lwjgl3 ever plans to make the async lib the default, though we haven't had any issues using it in testing.

I experience also a freeze but already when application starts up. Here's a related issue on lwjgl issuetracker: https://github.com/LWJGL/lwjgl3/issues/619
The org.lwjgl.system.Configuration.GLFW_LIBRARY_NAME.set("glfw_async"); crashes immediately when added to main with:
Process finished with exit code 133 (interrupted by signal 5: SIGTRAP)

Just adding some info to this issue:
I have just updated several things on my project (versions on build.gradles, gradle wrapper version, etc), and now that "hack" below causes my game not to launch, as soon as it reaches that line below the game closes down without any error messages. Since this line is before creating the Lwjgl3Application class, the game window doesnt even show up.
Configuration.GLFW_LIBRARY_NAME.set("glfw_async");
As soon as I commented out this line the game launched normally, and it seems the freeze I was getting originally when closing the game is gone also.

Are you using glfw_async with -XstartOnFirstThread , or without? This whole thing is a total mess, and the approach I go with these days is just to include the StartOnFirstThreadHelper from the Guacamole helper library, which is just one file that can be copied into an LWJGL3 module.

Im not using any of those 2 commands anymore (glfw_async or XstartOnFirstThread) and it seems to be running fine. Im not sure if I just got lucky or if the updates on build.gradle fixed it.
What I did: I copied all the build.gradle wrapper androidmanifest etc from a new project created using the libgdx setup tool (and adjusted the project name/package name etc to my game). There were some other changes on the build.gradle structure as well (when compared to my project's build.gradle files), not only the libs versions.

I've never heard of a Mac being able to run an LWJGL3 app/game out of the box without any handling for the first thread issue, which could be any of the glfw_async configuration, -XstartOnFirstThread argument (possibly via Guacamole), or gdx-lwjgl3-glfw-awt-macos dependency. Gradle also shouldn't be related, and should be unrelated entirely if you build a jar and launch that. I'm definitely curious what you have going that works with no extra changes to a gdx-setup project.

I've never heard of a Mac being able to run an LWJGL3 app/game out of the box without any handling for the first thread issue, which could be any of the glfw_async configuration, -XstartOnFirstThread argument (possibly via Guacamole), or gdx-lwjgl3-glfw-awt-macos dependency. Gradle also shouldn't be related, and should be unrelated entirely if you build a jar and launch that. I'm definitely curious what you have going that works with no extra changes to a gdx-setup project.

You are correct, sorry. The -Xstart flag was present on the Gradle task. I tried to remove it now and it wouldnt launch ("Caused by: java.lang.IllegalStateException: GLFW may only be used on the main thread and that thread must be the first thread in the process. Please run the JVM with -XstartOnFirstThread. This check may be disabled with Configuration.GLFW_CHECK_THREAD0.").

Likely fixed by #7361.


OGC and CQL filters doesn't work with geoserver if there is a national character in a condition

<ogc:Filter xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns="http://www.opengis.net/ogc">
  <ogc:PropertyIsLike escape="\" singleChar="_" wildCard="%">
    <ogc:PropertyName>name</ogc:PropertyName>
     <ogc:Literal>%Ё%</ogc:Literal>
  </ogc:PropertyIsLike>
</ogc:Filter>

Such filter shows nothing when applied to a layer in a geoserver layer preview (it uses ol3 in its latest version for now 2.7.0). With ASCI characters everything works fine.
The reason is that the request is sent by GET method where all parameters are URL-encoded and geoserver fails to decode them correctly.
The good option would be using POST method when sending request.

cc @jodygarnett @aaime we should talk about at which level to fix this?

It looks like this should of been raised as a GeoServer issue?


cmd/gc: fatal error: bad pointer in write barrier

fatal error: bad pointer in write barrier

runtime stack:
runtime.throw(0x18cb150, 0x1c)
        /home/dfc/go/src/runtime/panic.go:527 +0x96
runtime.writebarrierptr_nostore.func1()
        /home/dfc/go/src/runtime/mbarrier.go:125 +0x33
runtime.systemstack(0xc20801e000)
        /home/dfc/go/src/runtime/asm_amd64.s:262 +0x79
runtime.mstart()
        /home/dfc/go/src/runtime/proc1.go:682

goroutine 9999 [running]:
runtime.systemstack_switch()
        /home/dfc/go/src/runtime/asm_amd64.s:216 fp=0xc2086b37f8 sp=0xc2086b37f0
runtime.writebarrierptr_nostore(0xc20878a3a0, 0xb)
        /home/dfc/go/src/runtime/mbarrier.go:125 +0x5c fp=0xc2086b3810 sp=0xc2086b37f8
runtime.heapBitsBulkBarrier(0xc20878a358, 0x50)
        /home/dfc/go/src/runtime/mbitmap.go:347 +0x189 fp=0xc2086b3860 sp=0xc2086b3810
runtime.callwritebarrier(0xc208356820, 0xc20878a320, 0x50, 0x38)
        /home/dfc/go/src/runtime/mbarrier.go:198 +0xf1 fp=0xc2086b3878 sp=0xc2086b3860
runtime.call128(0xc208356820, 0x1614320, 0xc20878a320, 0x3800000050)
        /home/dfc/go/src/runtime/asm_amd64.s:423 +0xae fp=0xc2086b3900 sp=0xc2086b3878
reflect.Value.call(0x1614220, 0xc208556240, 0x513, 0x1780a90, 0x4, 0xc208c9ac20, 0x1, 0x1, 0x0, 0x0, ...)
        /home/dfc/go/src/reflect/value.go:432 +0x120d fp=0xc2086b3c50 sp=0xc2086b3900
reflect.Value.Call(0x1614220, 0xc208556240, 0x513, 0xc208c9ac20, 0x1, 0x1, 0x0, 0x0, 0x0)
        /home/dfc/go/src/reflect/value.go:300 +0xb4 fp=0xc2086b3cb0 sp=0xc2086b3c50
github.com/juju/juju/rpc/rpcreflect.newMethod.func6(0x1614220, 0xc208556240, 0x16, 0x1559180, 0xc208d403c0, 0xd9, 0x0, 0x0, 0x0, 0x0, ...)
        /home/dfc/src/github.com/juju/juju/rpc/rpcreflect/type.go:323 +0x14e fp=0xc2086b3d70 sp=0xc2086b3cb0
github.com/juju/juju/apiserver.(*srvCaller).Call(0xc2087e8b40, 0x0, 0x0, 0x1559180, 0xc208d403c0, 0xd9, 0x0, 0x0, 0x0, 0x0, ...)
        /home/dfc/src/github.com/juju/juju/apiserver/root.go:131 +0x123 fp=0xc2086b3df8 sp=0xc2086b3d70
github.com/juju/juju/rpc.(*Conn).runRequest(0xc2089d23c0, 0x7f0766ece1b8, 0xc2087e8b40, 0x1b48690, 0x5c, 0xc208a30790, 0x7, 0x0, 0x0, 0x0, ...)
        /home/dfc/src/github.com/juju/juju/rpc/server.go:552 +0xd1 fp=0xc2086b3f30 sp=0xc2086b3df8
runtime.goexit()
        /home/dfc/go/src/runtime/asm_amd64.s:1670 +0x1 fp=0xc2086b3f38 sp=0xc2086b3f30
created by github.com/juju/juju/rpc.(*Conn).handleRequest
        /home/dfc/src/github.com/juju/juju/rpc/server.go:481 +0x717

go version devel +647026a Wed May 13 21:31:03 2015 +0000 linux/amd64
This is a bug turned up running the juju unit tests, so reproduction is convoluted. I can provide ssh access to a pre created environment if it useful.
cc @rsc @aclements

Any unsafe chicanery involved?

nope.
% go list -f '{{.Imports}}' github.com/juju/juju/rpc github.com/juju/juju/apiserver github.com/juju/juju/rpc/rpcreflect | grep unsafe -c
0

I suspect this was fixed by https://go-review.googlesource.com/9888. The reflect package was not updated correctly for 1-bit stack maps until that CL. Please test again at that revision or later. Thanks.

@rsc I've just checked with
go version devel +2b063bd Mon May 18 20:16:14 2015 +0000 linux/amd64
and the problem still exists. It is completely repeatable, but needs the full Juju song and dance environment to run the test case. If I set up a machine with all the necessary bits if that will help.

Yes please.

After bisecting, I suspect the problem may have been introduced in 4212a3c3d9a520c3124134c97bb48677c0c1203f

I'm embarrassed to report that this test triggers multiple data races and
is probably what is causing this panic. http://paste.ubuntu.com/11235945/
I need to do some work to get my house in order before I can start throwing
stones at the runtime.
I'm sorry for wasting everyone's time.
On Wed, May 20, 2015 at 2:08 AM, Russ Cox<EMAIL_ADDRESS>wrote:

Yes please.
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/10844#issuecomment-103569051.

There's still a real runtime bug here. On it. Thanks for the test case and test machine.