Log output channel: Log file not cleared upon reload of window

Does this issue occur when all extensions are disabled?: Don't know (the issue is about discrepancy between different OS)

VS Code Version: 1.94.2 (commit 384ff7382de62)
OS Version: Windows 10 Version 22H2, using VSCode in WSL2, Ubuntu 22.04.5 LTS

Steps to Reproduce

Inside an extension, create a LogOutputChannel via:

const logger = vscode.window.createOutputChannel("My extension", { log: true });

Use Developer: Open Log File to open the log file for My extension.
On Linux (WSL2 Ubuntu), we observe that after a Developer: Reload Window, when using Open Log File again, a new log file is opened that VSCode neatly created for us in the folder exthost<some_number+1>. Here, <some_number is the number for the folder in which the log file resided prior to the window reload.
However, on MacOS (Darwin 23.6.0 arm64), we notice that the same logfile is reused and lines are only appended to it. Is there a way we can force a new log file to be created on this system as well? Or at least that the old logfile is cleared? logger.clear() or logger.dispose() does not seem to work, it only clears the log from the output pane but does not affect the log file.

We need this behavior (creating a new logfile or at least clearing it) such that our extension users can send us logfiles that only contain the relevant lines (and not some unrelated past behavior).
We discovered this behavior in this issue. This might be related to #228472.

similar to #224516

@VladimirFokow, could you maybe test if #204946 (see the video there) is still an issue for you? Just to know if this is related (it does seem related).

/duplicate
https://github.com/microsoft/vscode/issues/204946


Remove MFA limitation disclaimer

MFA not supported disclaimer should no longer be present for Direct Query SSO to Azure SQL DB. The MFA  restriction is also no longer specified on the Power BI data sources page: https://docs.microsoft.com/en-us/power-bi/connect-data/power-bi-data-sources#single-sign-on-sso-for-directquery-sources.

@mariuspc : Thanks for your contribution! The author(s) have been notified to review your proposed change.

@mariuspc : Thanks for your contribution! The author(s) have been notified to review your proposed change.


Horizontal scroll behavior broken in Chrome Device Toolbar

For whatever reason, when horizontal scrolling through an overflow container in Chrome's Device Toolbar, the lazy loading behavior is broken.
I have an album with an example of correct and erroneous behavior, here:
http://imgur.com/a/tIuat

I've got a  horizontal scrolling through an overflow container and every image loads at once there in no lazy loading. is there some specific config for that?

Works with 4.0 now, I added an example due to this issue and made sure it worked :) fixed with #155


DRILL-5195: Publish Operator and MajorFragment Stats in Profile page

Improved UI

Introduction of Tooltips
Share of each operator as a percentages of the major fragment and of the query

This would help identify the most CPU intensive operators within a fragment and across the query

Rows emitted by each operator
For a running query, changes to 'last update' and 'last progress' now shows the elapsed time since.

@sudheeshkatkam This commit is rebased on top of another pending PR (#738): DRILL-5190. You'll need to apply that before applying this.

@paul-rogers , checked in the final set of changes, accommodating most of your comments.
TPCH Samples:
http://<IP_ADDRESS>:8047/profiles/275020fe-f51c-b8f3-a7b4-9f54461c4606
http://<IP_ADDRESS>:8047/profiles/275021b9-c87e-efd9-135e-4172ef2d38b6

@paul-rogers
Incorporated most changes... except:
https://github.com/apache/drill/pull/756#discussion_r103000211
https://github.com/apache/drill/pull/756#discussion_r103005037

@paul-rogers Incorporated all changes.


commit hook checking for conflicts failed to detect conflict in DESCRIPTION

The hook checking for conflicts allowed me to push this commit, including a conflict surrounding version number
~/b/BiocParallel master$ git show 205e71b651f4c0bf92db5b12c7c64b06b8b4db2b DESCRIPTION
commit 205e71b651f4c0bf92db5b12c7c64b06b8b4db2b
Author: Martin Morgan<EMAIL_ADDRESS>Date:   Fri May 6 17:41:22 2022 -0400

    version bump and NEWS, porting RNG seed stream reset

diff --git a/DESCRIPTION b/DESCRIPTION
index d93a3ce..2f2c5ca 100644
--- a/DESCRIPTION
+++ b/DESCRIPTION
@@ -1,7 +1,11 @@
 Package: BiocParallel
 Type: Package
 Title: Bioconductor facilities for parallel evaluation
+<<<<<<< Updated upstream
 Version: 1.31.1
+=======
+Version: 1.31.3
+>>>>>>> Stashed changes
 Authors@R: c(
     person("Bioconductor Package Maintainer",
<EMAIL_ADDRESS>role="cre"),

FWIW I noticed this in a few packages that I had to reach out to correct as well; and also mentioned the hook needed revamping.

It was hard coded for <<<<<<< HEAD
I'm going to try to make it more strict for markers but without branch/source
eg.
<<<<<<<

There might be the very rare false positive is someone has all three of these somewhere in a file but I would consider that rare.

See https://github.com/Bioconductor/git-hooks/commit/4191a7a533a353b3b05ded393bf25bb35af2f287


first pass at kilo support

retest

Hey that's not really anything more than what I had on my kilo branch :)

retest

retest

I believe we need to make a kilo branch of our horizon fork to resolve this ?   @j2sol ?

@paulczar Yeah it's possible, hard to tell without seeing why Horizon is not up and running. The fact that the deploy finished is good news. We should probably toss this up into a set of VMs that won't get destroyed right away so we can poke at the environment.
Kilo as a feature is not scheduled until later this year though.

We can close this because of the more recent PR of wip_kilo


Stopped working in windows 11

Looks like a change in the webview or something.

Under investigation.

I fixed it by updating the framework (wails) as soon as possible.
We would appreciate it if you could try it from here.
@leonelcamara


Can't run VisIt directly on trinity.

Describe the bug
I had a user want to run the VisIt cli from a batch job on trinity. He got an error message that that library libicui18n.so.52.1 could not be found. I checked and libicui18n.so.60.2 is installed, so it looks like the system got upgraded and the old versions of the libraries are not available.

It looks like I need to rebuild all the third party libraries and visit, since the compilers and many of the supporting libraries have been upgraded. I have started a build of the third party libraries using build_visit3_1_3.

I built visit3.1.1 against the libraries generated by build_visit3_1_3 and that was successful (File transfer was broken to trinity, so I used the latest version I had on the machine). I replaced the installed 3.1.1 version and it ran successfully in serial on a login node as well as in parallel in a batch submission.

The user reported a link error at runtime.
/opt/gcc/9.3.0/snos/lib64/libstdc++.so.6 version 'GLIBCXX-3.4.26' not found, required by …/bin/cli/libvisitcommon.so
I suggested he try
module swap PrgEnv-intel/6.0.8 PrgEnv-gnu/6.0.8
which fixed the problem. I will see if I need to add some path information for gcc to the custom launcher for trinity.

The following code block should be added to the LLNL custom launcher in LLNLLauncher::Customize().
if self.sectorname() == "tr-fe" or self.sectorname() == "nid":
ld_library_path = GETENV("LD_LIBRARY_PATH")
new_ld_library_path = self.joinpaths(["/opt/gcc/9.30./snos/lib64", ld_library_path])
SETENV("LD_LIBRARY_PATH", new_ld_library_path)


Overload operators not working when using with with..yield syntax

Crystal: 0.23.1 (2017-09-08) LLVM 4.0.1
OS: MacOS X El Capitan
struct Vector2
  def initialize(@x : Int32, @y : Int32)
  end

  def +(other)
    Vector2.new(@x + other.x, @y + other.y)
  end
end

def build(x, y)
  v = Vector2.new(x, y)
  with v yield v
end

build(1, 2) {
  +Vector2.new(3, 4)
}

I think considering +x to invoke + on the hidden object yielded by with ... yield is super cryptic. That said, I consider with ... yield already cryptic and magical enough, that I've been wanting to remove it from the language from some time now. So operator overloading in this case is something that's much less likely to ever happen.

with ... yield syntax enables neat DSL syntax like Kotlin, but Kotlin implement this with Extension Functions

Actually, in your example, this happens:
+exp

The above parses to exp.+(). That's why it's not found.
Comparing with how with ... yield works, you have this:
some_method(argument)

then some_method would be looked up in the implicit object, like implicit_object.some_method(argument). But in the case of +exp it's not the same as implicit_object.+(exp), it's always exp.+().
There simply is no way to disambiguate that.


Addon system

This is nowhere near to be merged.
Please add any feedback below and this list is open to be updated.
Goals for this addon system/PR:

[x] Addon discover for sane generate having a default generator based on the addon-name
[ ] Support for multiple generators in an addon
[x] Add sane install command that installs an and addon runs the default generator
[ ] Add support for node-machine (http://node-machine.org/) structure as addons

[x] Basic support that node-machines are being recognized and called

[ ] Add support for custom generators:

[x] To add custom templates to the backend and frontend

[x] Support file diff if the file already exists
[ ] See how ember-cli-admin are supporting pod structure: https://github.com/ember-admin/ember-cli-admin/tree/master/blueprints/table-view-resource/files/app as well as https://github.com/ember-admin/ember-cli-admin/blob/master/blueprints/table-view-resource/index.js

[x] To install npm packages for the backend (including sails hooks)
[x] To install ember addons on the frontend
[ ] To install bower packages on the frontend
[ ] To install npm packages on the frontend
[ ] To add to the ember-cli config file
[ ] To add to sails config files?
[ ] To run ember generate
[ ] or sails generate commands for creating files dynamically*

[ ] Keep track if a generator has already been run (e.g. through the install command), within the .sane-cli
[ ] Support custom folder names for client/server
[ ] write a sane generate addon or sane new addon or sane addon command which scaffolds out a skeleton template
[ ] Add 'dryRun' option to generators so they don't actually npm install but just add the packages to the package.json for better testability (part of the reason for the failing/flakey tests)
[ ] Add uninstall command? (probably not in this iteration)

Any other ideas @kriswill @mgenev ? Especially, what do you think about the scaffolding command? Should we re-use one of the existing ones or add a new command?
Also @IanVS @albertosouza @mphasize @huafa @DiknT @bsocius what do you think? Would love some more input.
*This could easily support user-input so files can be name dynamically. So for example for sane-auth right now the model is called user on the frontend and backend, but that could be made dynamically by passing sane install sane-auth customer or something like that and then the model is called customer.

So, right now the system is extremely simple and expects the default folder-names (client/server) to function properly. So you run sane install <addon-name> which will automatically call sane genrate <addon-name> once installed.
The generator on the other hand detects any addon that has the sane-addon keyword as specified here https://github.com/Globegitter/sane-auth/blob/master/package.json#L12. Furthermore machinepack needs to be defined: https://github.com/Globegitter/sane-auth/blob/master/package.json#L26 as per http://node-machine.org/spec/machinepack]
Based on this addon I would also like to see what other people think about using machines.
Right now all the code and templates have to lie within the generate folder and no sub-folders/multiple generators are supported, but that will most likely change soon.
Just have to see how that can be done best using machinepacks.
Also another thought that came up was making the addon system within sane-cli a machine itself that just talks to other machines. Have to investigate that.
On another note, fixing windows tests shouldn't be that hard anymore since the efforts of @IanVS :)

Just jotting down some more thoughts about the addon system itself being a machine:
Right now the addons are a machine and while that has certain benefits I also think it is a bit like stretching the system for its original purposes (e.g. see that sane-auth basically has no code, it just returns an exits.success). It is still useful to have a description of what exactly each file does and also to define what you are using in the exits.success.
But what now that I am more thinking about it would make a lot of sense as well, the addon system itself to be a machine (that possibly loads other machines): This basically means that within the addon-system the input expectations for every addon is defined (so for the addon inputs we could define addEmberAddons , addToConfig, etc) and get easier/nicer error message when an addon uses that wrongly.

I reviewed everything so far, except actually, the way it behaves as a machine so I can't comment on that, but the rest seems very logical to me - great work. I do agree that certain customization options need to be added and perhaps some abstraction will be needed to avoid bloat in the generate command file, but other than that so far so good.

For discussion about addon naming conventions and generator name-spacing, see https://github.com/Globegitter/sane-auth/issues/8

How can we easily update addons? Think about that. Looking at the sane-auth addon there are a few different main components:

[ ] the generated template files
[ ] the dependencies added to the project
[ ] the addition to the ember config files (which brings the question, do we want similar addition to sails configs)
[ ] the commands it runs, such as ember g resource etc.

Have to identify what currently is easy to upgrade and what not, plus if we could improve anything about that.

About "the generated template files", Ember solves the problem by keeping them in a node package and importing them at build time and resolving them at runtime by the container. This sounds quite logical to me, on the Ember side we can easily piggy back, by making our sane-addon install an ember-cli-addon for the feature.
On the Sails side I have no solution, it may be worth talking to the Sails team.

@mgenev yeah, I agree.  Any template generated files have to be somehow closed, with extension points made available for customization.  Example:  sane-auth generates controllers, models, policy, config, etc.  If the files for these things were in a hook, node-machine, etc., then they would be essentially frozen, making upgrading them easier, since they will not have been modified by the user.  However, we still need to provide the ability to customize behaviour, etc.

About dependencies, aren't most dependencies easily added by  running a  npm install --save and bower?
About configs, yes I imagine we need to touch the sails configs as well.

Now that I switched to babel, I need to make sure it does not skip to transpile the locally installed sane-cli. It does so by default: babeljs.io/docs/usage/require/

@IanVS for some reason your helper unit test is failing with TypeError: object is not a function. Any idea why?

The helper basically returns a string (the path to the ember-cli binary).  That was causing trouble with rewire, and perhaps babel doesn't like it either?  Is that an antipatern in Node?

@IanVS Not that I am aware, especially because returns local ember by default does work. I also updated chai to 2.x so maybe that changed something about the expect().to.be.ok() syntax?
I also updated mocha to 2.1.x but don't expect that to be any issue.

OK yes, chai seems to have changed.  I can't do a full PR, but try this (remove the function call at the end):
expect(ember).to.be.ok;

but then you need to add this to the top of the file to make ESLint happy:
/*eslint no-unused-expressions:0 */

Thank you @IanVS . Now we just have to fix windows tests and we are good to go!

It might be because your 'only' option for babel is using escaped forward slashes, and Windows uses backslashes. I think you shouldn't escape the forward slashes. See: https://www.npmjs.com/package/glob#windows

@IanVS the tests are looking much better now. It does get quite far. The log shows sane-auth succesfully installed. Running it's default generator now.... And the generator also detects module found: sane-auth.
Not sure why it just stops then. Probably best to test on a windows machine directly and add some more debugging statements.

Yes! @IanVS we got passing tests! But lets see if traceur is any faster than babel.
Babel results:
travis:
Node 0.12 - 2m49s -  11 passing (52s)
  sane generate
    resource/api user (13671ms)
    resource/api user name:string age:number (8860ms)
  sane install
    sane-auth and runs generator (11407ms)
  sane help
    displays commands, it's aliases and the correct cli version (1221ms)

io.js - 2m57s - 11 passing (54s)
  sane generate
    resource/api user (12233ms)
    resource/api user name:string age:number (8388ms)
  sane install
    sane-auth and runs generator (11686ms)
  sane help
    displays commands, it's aliases and the correct cli version (1265ms)

appveyor:
21min20s, with tests themselves passing within 5min.
  sane generate
    resource/api user (67379ms)
    resource/api user name:string age:number (50874ms)
  sane install
    sane-auth and runs generator (55553ms)
  sane help
    displays commands, it's aliases and the correct cli version (6455ms)

@IanVS I meant babel vs traceur. Seems there is some difference: io.js is 11s faster, node.js 2s and windows roughly 1min.
Reason I wanted to check is because babel always just seemed to have the tendency to be a bit slower compared to traceur in my tests. Also just read: https://github.com/babel/babel/issues/476#issuecomment-93969324
Now is the question, improved development experience vs performance :P

Well, as @jamemackson mentioned in another thread, creating a new project only happens once per project.
Could also keep it as an option of switching back if people start to complain that it takes too long.

I think that the way babel is being used here is causing some problems.  Babel recommends to compile before distributing a package on npm (see: https://github.com/babel/babel/pull/1026#issuecomment-80946352).  Is that an option?
Otherwise, it does seem like ignore: false is necessary after all.  I'll try to play around with compiling and see how that would look.

@IanVS awesome this is looking good now!

Ok, fixes left:

[ ] the last npm install hangs on sane new but does install correctly. For some reason it does not seem to notice when the process is done. Investigate, or think about switching to enpeem
[ ] Fix sane-auth

@Globegitter what needs to be done to fix sane-auth?

Ember-simple-auth changed the interface, still need to look into it

@IanVS seems there is nothing we can do directly: https://github.com/simplabs/ember-cli-simple-auth/issues/26
But have to test sane's behaviour. It should probably still finish the complete installation or at least provide a --force flag to finish.

Do you mean add an acceptance test?  The commit I added fixes it when I test on my machine.  The '--verbose' option was causing problems if stdio: "inherit" was not used in the spawn.  So I removed the verbose and it works correctly (finishes the installation).

Sorry, wasn't clear at all. I don't actually know how sane handles the error we currently have with sane-auth/ember-simple-auth. So I mean I need to test to see the behaviour Martin described. There might not be that much to do.

Ah, got it, yes.

LGTM.


Unable to verify secret hash for client: Using the plugin to hit https://localhost:8300 (ssl enabled mkcert) but I get error

I used the manual installation of the plugin using https://github.com/syl20lego/insomnia-plugin-aws-cognito-token/issues/5#issuecomment-629664927 .
I have doubled checked all credentials for Cognito but I keep getting an error
Unable to verify secret hash for client 56n1ij8fic######e5inkjb8nc
Screenshot:

Here my line of questions for troubleshooting
(i) Am I getting this issue because I am using https://localhost:8300 as the auth link (and probably this plugin needs extra config for localhost play, I already have added local https support using mkcert and added the callback url as https://localhost:8300 in Cognito)
(ii) Or Is it something specific to the plugin because it is manually installed instructions followed https://github.com/syl20lego/insomnia-plugin-aws-cognito-token/issues/5#issuecomment-629664927 .
Here are other screenshots

@syl20lego Is this feature supported in the plugin to include client secret for App Client that is generated at Cognito
https://stackoverflow.com/questions/37438879/unable-to-verify-secret-hash-for-client-in-amazon-cognito-userpools

@sagun786 I'm not using client secret feature, maybe try the token type 'id' instead. Otherwise maybe you can create a PR (maybe with a new token type, secret) for your feature and I will be glad to include it.

Hi, could you try version 0.15.0 and see if this fixes the issues ?

Hi, could you try version 0.15.0 and see if this fixes the issues ?


[BUG]: docker ports are not exposed after building the supplied CPU dockerfile.

Thank you for helping us improve solaris!
Summary of the bug
I am attempting to run the dockerfile found in the repo. When I run docker ps -a after building and running the image, the ports end up not being exposed.
Steps to reproduce the bug
After building the image I proceed to running it by evoking the command below:
docker run -p localhost:8888:8888 -p localhost:6006:6006 1ff

Steps to reproduce the behavior:

Build the image using: docker build .
Run the image using: docker run -p localhost:8888:8888 -p localhost:6006:6006 1ff
Check whether the ports are exposed by running docker ps -a
I end up getting the below image, where you can clearly see that the ports are not exposed.

Buggy behavior and/or error message
The ports are not exposed as expected.
Expected behavior
The ports should be exposed on ports 8888 and 6006.
Screenshots

Environment information

OS: Linux
solaris version: 0.4.0
python version:
version of any relevant dependencies (optional - we may ask for this information later if not provided)

Additional context
I am using the dockerfile for CPU.

I needed to run the container in an interactive terminal using the -it flag or in detached mode, the problem was that the container was exiting immediately.

I needed to run the container in an interactive terminal using the -it flag or in detached mode, the problem was that the container was exiting immediately.


[REEF-382] Remove ConfigurationFile

This addressed the issue by

replacing serialization usages of ConfigurationFile in our code with AvroConfigurationSerializer
moving toConfigurationStringList method to ConfigurationModule
deleting ConfigurationFile and TestConfigFileParser

JIRA:
REEF-382

@tcNickolas This looks good. I will test and merge.


Add applicant_role enum to planning applications

Description of change

Add applicant_role to planning applications
Update this field on legacy planning applications based on if an agent contact detail has been provided
Improve error handling on planning application post requests

Story Link
https://trello.com/c/yBWBLTkn/716-applicant-role-types

This is a good PR, although I am wondering whether is best to make a new table Applicant which will have the following:

role
first_name
last_name
phone
email
And then the planning_application will have one applicant

This is a good PR, although I am wondering whether is best to make a new table Applicant which will have the following:

role
first_name
last_name
phone
email
And then the planning_application will have one applicant

Yeah I originally was thinking about doing this but when role is proxy it becomes a bit problematic filling in the rest of those fields with the correct values. (I'll discuss this with you offline)


BUG: Alert should be given for wrong email without @

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?
@anuragverma108 I want to work on this issue. Please assign me this issue.

Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

done


Hero Flagging does not execute in GWToolbox Mini-map but does when GW original compass is active along side original compass

as per shown to @3vcloud on discord 2D Hero Flagging on Mini-map only work when regular compass is enabled along side it
flagging while gw compass enabled will allow flagging with TB Mini-map but not while gw compass is turned off
Picture shown here for refence: https://cdn.discordapp.com/attachments/224695376102293514/782228915078561812/gw003.jpg
I am able to flag with both gw compass and toolbox mini-map only when gw compass is active along side mini-map but when toolbox mini-map is active and gw compass is turned off the hero flagging does not allow u to flag anywhere

im gonna close this

Issue is fixed for next release I checked the code


Update pulumi-terraform to f083d8ce44

This PR updates pulumi-terraform to f083d8ce44, and re-runs code generation

Closed via #648


[python/c++] Expose uri, result_order, and column_names for SOMAArray

Issue and/or context:
[sc-35643]
Changes:

Add sr (SOMAArray) Python bindings for uri, result_order, and column_names
Add C++ SOMAArray::result_order which calls newly added ManagedQuery::query_layout
Replace SOMAArray::result_order_ with call to ManagedQuery to get query_layout. If the result order was set to ResultOrder::automatic, just returning back ResultOrder::automatic is not very useful information. The user probably wants to know if the layout is row-major or col-major

Notes for Reviewer:
A schema getter was also requested but is not possible yet in this PR but will be available soon.
Currently SOMAArray::schema returns a tiledb::ArraySchema. In TileDB-Py, we do have a registered binding from tiledb::ArraySchema to tiledb.ArraySchema. This does not get picked up in TileDB-SOMA. In TileDB-SOMA, we "could" bind tiledb::ArraySchema to tiledbsoma.ArraySchema but TileDB-Py's tiledb.ArraySchema and TileDB-SOMA's tiledbsoma.ArraySchema are not compatible despite binding the same underlying C++ class. We would also have to separately bind all classes used by the ArraySchema such as tiledb::Attribute, tiledb::Dimension, tiledb::Filter, etc. which is massively inconvenient.
The refactored read path no longer uses the tiledb::ArraySchema and instead returns an ArrowSchema. From the C++ side we take the TileDB ArraySchema and converts this to an ArrowSchema. In the bindings, the C-struct ArrowSchema is converted to a pa.Schema.

OK I'll change it to make the info available before reads too.

Replace SOMAArray::result_order_ with call to ManagedQuery to get query_layout. If the result order was set to ResultOrder::automatic, just returning back ResultOrder::automatic is not very useful information. The user probably wants to know if the layout is row-major or col-major

I think it is also useful to know what the user asked for, i.e.,. will sorting be applied?  Currently there is a large performance penalty if result order is either row or col, but not if it is auto due to different readers being used in the core DB.  This is independent of layout.
I'd rather have layout available as part of the schema definition, and not mixed together with query definition.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
see 76 files with indirect coverage changes
:loudspeaker: Thoughts on this report? Let us know!.

Upon looking at the code again, it seems I confused myself too while making the changes. I reverted result_order_ back to how it was and am now just returning that.


Ciocheck config

unix: cd ${PROJECT_DIR}/deploy && python -m pytest --cov=anaconda_platform.deploy --cov-report=term-missing:skip-covered --cov-report=html --cov-fail-under=100 --no-cov-on-fail --cov-config=.coveragerc anaconda_platform/deploy/tests

@goanpeca so this is essentially what I want to do with ciocheck (see also the .coveragerc in this PR). The reason ciocheck doesn't work (I think?) is that if I cd into deploy subdir as I do here, ciocheck can't find the .ciocheck in the root dir one level up. (I have .ciocheck-test which does an inherit_from .ciocheck, and I think the inherit_from looks relative to cwd not relative to ciocheck-test?). If I don't cd into the deploy subdir then the module paths are messed up which causes its own trouble.

if you want you can check this branch out and try ./apb test deploy to see what my command here does and play with using ciocheck in kapsel.yml instead..

@havocp could please add any additional context here. The initial version of ciocheck was very limited in terms of where to look for config and stuff. But if you define some "rules" that make sense to you I can make a new release in a week or so.

I am making new fixes this week so that 0.2 is coming soon. If you can lay out any other requests I can make them happen :-)


Issue 14 of the newsletter

This is a call to everyone out there who works in open bioinformatics - please share interesting stuff! This could be a new project launch, an interesting update or release, a link to useful resources (e.g. some nice biology related icons or an open source tool that could be useful, etc. If you aren't sure about something, feel free to drop me a line personally to discuss it, e.g. via mastodon<EMAIL_ADDRESS>or email (bgreshaketzovaras@gmail.com).
Promoting yourself or your workplace is totally okay here - this is literally what the newsletter is for, within reason!
The aim is to send out this newsletter around July 2024

Hello, not sure if this was sent already or not, but something we would like to get some visibility on is:
Pydna Hackathon 3rd of October 2024
The pydna python package provide a human-readable formal descriptions of 🧬 cloning and genetic assembly strategies in Python 🐍 which allow for simulation and verification. Pydna can be used as executable documentation for cloning.
Join us to contribute or to learn how to use the library on October 3rd 2024, more info in the discussion:
https://github.com/BjornFJohansson/pydna/discussions/258

Hey @manulera, thanks for adding this in, we haven't sent out this newsletter yet! I think we can try to get it out before Oct 3rd, and I'll include it in that case! :-)

Thanks @gedankenstuecke !

Started the September newsletter in #43 (which will also have a link to the proper next issue for early 2025 after I forgot it this time around!)

This newsletter was just sent, Now #42 will be the one to track the one for early 2025! 🚀


Is this project abandoned? Is there an active fork of this repo?

This is the second highest starred validation package in Go, but it appears there is no maintainer or activity on this repo.
I would use go-playground/validator (the highest starred validation package I could find), however it's not suitable for my use-case as I cannot define custom errors per field, whereas asaskevich/govalidator does support this.
Is there an active fork of this repo?

Not sure what you're exact use-case is... but if you're validating requests and want define custom error messages then https://github.com/marrow16/valix may be of use


[Facebook\WebDriver\Exception\UnknownCommandException] mouseMoveTo

What are you trying to achieve? (Expected behavior)
mouse move
What do you get instead? (Actual behavior)
[Facebook\WebDriver\Exception\UnknownCommandException] mouseMoveTo
How could the issue be reproduced? (Steps to reproduce)
https://github.com/Codeception/Codeception/issues/4104
Details

Php-webdriver version: 1.4
PHP version: 7.1.3
Selenium server version: selenium/firefox-standalone:3.3.0
Operating system: debian
https://github.com/bscheshirwork/docker-yii2-app-advanced-rbac/tree/master/docker-codeception-run
Browser used + version:

Please try using Selenium 3.3.1, as the 3.3.0 version won't work properly with latest Firefox/Geckodriver.
See https://github.com/mozilla/geckodriver/pull/593

I'm having this issue, too.
Facebook\WebDriver\Exception\UnknownCommandException: mouseMoveTo
Build info: version: '3.3.1', revision: '5234b32', time: '2017-03-10 09:04:52 -0800'
System info: host: 'dev', ip: '<IP_ADDRESS>', os.name: 'Linux', os.arch: 'amd64', os.version: '3.10.0-514.6.1.el7.x86_64', java.version: '1.8.0_121'

Same issue here but with Selenium server 3.4.0


desc.json response status code not respected

I am creating a series of POST and PUT endpoints. When the mock server responds to these requests, I want to specify that they return the correct http status code:
If I specify that status code in the response object within desc.json, it is not being respected and always returns 200 (unless I use an error response with an error-401.json kind of response file).
"response": {
"statusCode": 201,
"schema": {
"type": "application/json"
}
}
I am using v0.14.0

Hi @pcaithness,
there are two way's to define the statusCode:

use the response file name. Like "error-401.json" or "success-201.json" and select the response by using the UI. readme-expected-response
or as a more dynamic solution you can use a middleware. readme-middleware example

thanks @smollweide
I did not know you could specify the status code on the success responses.


Update to Exonum 1.0.0-rc.1 [ECR-4207]

Overview
Here we are, massive changes in protobuf files structure.

See: https://jira.bf.local/browse/ECR-4207
Definition of Done

[ ] There are no TODOs left in the code
[ ] Change is covered by automated tests
[ ] The coding guidelines are followed
[ ] Public API has Javadoc
[ ] Method preconditions are checked and documented in the Javadoc of the method
[ ] Changelog is updated if needed (in case of notable or breaking changes)
[ ] The continuous integration build passes

but I'd exclude the consensus.proto from the sources (may be done separately). Also, the build's failing.

Yep, I'm on it

Coverage remained the same at 85.158% when pulling d9b420935c2075c2d9ae5f7b61317c42fa50361a on vitvakatu:ecr-4207-update-exonum-12 into 06719b918205c0fd4ebfc43d3eb5b6f311c6e2dc on exonum:master.


MNIST Standalone hangs when using many epochs

I am using TF 1.2 and Spark 2.0.2 with the pip install version of TFoS.
The command I used is this one:
 PYSPARK_PYTHON=${OTHER_PYTHON} ${SPARK_HOME}/bin/spark-submit  \
--num-executors 12 --executor-memory 55G   \
--master ${MASTER}  \
--py-files ${TFoS_HOME}/examples/mnist/spark/mnist_dist.py  \
--conf spark.executor.cores=1 \
--conf spark.executorEnv.JAVA_HOME="$JAVA_HOME"  \
${TFoS_HOME}/examples/mnist/spark/mnist_spark.py  \
--cluster_size 12  \
--images ${TFoS_HOME}/examples/mnist/csv/train/images  \
--labels ${TFoS_HOME}/examples/mnist/csv/train/labels  \
--format csv --mode train --model mnist_model --epochs 10

I see from some workers that the supervisor gets shutdown probably because of the # of epochs has been reached.
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s091/app-20170719182907-0032/10/stderr:2017-07-19T18:29:32.677071 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s091/app-20170719182907-0032/11/stderr:2017-07-19T18:29:32.439126 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s091/app-20170719182907-0032/8/stderr:2017-07-19T18:29:33.170899 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s091/app-20170719182907-0032/9/stderr:2017-07-19T18:29:32.908222 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s092/app-20170719182907-0032/4/stderr:2017-07-19T18:29:32.562425 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s092/app-20170719182907-0032/5/stderr:2017-07-19T18:29:33.010174 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s092/app-20170719182907-0032/7/stderr:2017-07-19T18:29:32.517486 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s093/app-20170719182907-0032/0/stderr:2017-07-19T18:29:32.637912 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s093/app-20170719182907-0032/2/stderr:2017-07-19T18:29:32.485645 stopping supervisor
spark-2.0.2-bin-hadoop2.7/work/cluster-2017-07-19_14-56-26/s093/app-20170719182907-0032/3/stderr:2017-07-19T18:29:32.460439 stopping supervisor

And from one of the workers I get that they keep on waiting for the those tasks that were shutdown.
2017-07-19 18:39:02.906223: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:0
2017-07-19 18:39:02.906259: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:1
2017-07-19 18:39:02.906268: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:2
2017-07-19 18:39:02.906275: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:3
2017-07-19 18:39:02.906283: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:4
2017-07-19 18:39:02.906290: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:5
2017-07-19 18:39:02.906297: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:6
2017-07-19 18:39:02.906304: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:8
2017-07-19 18:39:02.906311: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:9
2017-07-19 18:39:02.906318: I tensorflow/core/distributed_runtime/master.cc:209] CreateSession still waiting for response from worker: /job:worker/replica:0/task:10

Spark output stops here:
17/07/19 18:29:31 INFO CoarseGrainedSchedulerBackend$DriverEndpoint: Launching task 251 on executor id: 2 hostname: <IP_ADDRESS>.
17/07/19 18:29:31 INFO TaskSetManager: Finished task 190.0 in stage 4.0 (TID 242) in 211 ms on <IP_ADDRESS> (189/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 189.0 in stage 4.0 (TID 241) in 272 ms on <IP_ADDRESS> (190/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 191.0 in stage 4.0 (TID 243) in 270 ms on <IP_ADDRESS> (191/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 195.0 in stage 4.0 (TID 247) in 217 ms on <IP_ADDRESS> (192/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 194.0 in stage 4.0 (TID 246) in 239 ms on <IP_ADDRESS> (193/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 193.0 in stage 4.0 (TID 245) in 249 ms on <IP_ADDRESS> (194/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 192.0 in stage 4.0 (TID 244) in 259 ms on <IP_ADDRESS> (195/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 196.0 in stage 4.0 (TID 248) in 226 ms on <IP_ADDRESS> (196/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 198.0 in stage 4.0 (TID 250) in 254 ms on <IP_ADDRESS> (197/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 199.0 in stage 4.0 (TID 251) in 248 ms on <IP_ADDRESS> (198/200)
17/07/19 18:29:31 INFO TaskSetManager: Finished task 197.0 in stage 4.0 (TID 249) in 288 ms on <IP_ADDRESS> (199/200)

This however does seem like a race condition somewhere because this works some times, and others it just hangs.  @leewyang any idea on where to start looking at please?

@renato2099 I was able to replicate this on my Hadoop cluster.  As you mentioned, there seems to be some kind of race condition in setting up the session in the cluster, where some nodes never start the session.  In my env, I see it being fairly reliable up to about 8 nodes, but beyond that, I start seeing this issue.  Unfortunately, session creation code is in TensorFlow, so I'm not sure if this is a recent change or not... will continue to look into this.

@renato2099 Please try adding --steps 10000.

Closing due to inactivity.   Feel free to reopen if you're still seeing issues.


Unclear warning with no way to quiet the error text.

when you do not have a suffix you get this warning and there seems to be no way to silence the warning without setting a suffix. Furthermore the docs and warning itself do not make clear the risk. Please allow me to silence the warning AND please make it clear what i should be afraid of.
$ assume coolcompany/Developer
[✔] [coolcompany/Developer](us-east-1) session credentials will expire in 8 hours
[!] No credential suffix found. This can cause issues with using exported credentials if conflicting profiles exist. Run `granted settings export-suffix set` to set one.
[✔] Exported credentials to ~/.aws/credentials file as coolcompany/Developer successfully

https://github.com/common-fate/granted/blob/3ae786ea106e6ec82bb978a3e6f7a0fc381928c2/pkg/assume/assume.go#L531

Thanks for the report @zwing99. Could you please share the [profile coolcompany/Developer] block in your ~/.aws/config (redacting any AWS account IDs etc)?

[profile granappdevelopment/Developer]
granted_sso_start_url      = https://coolcompany.awsapps.com/start
granted_sso_region         = us-east-1
granted_sso_account_id     = 3.141592653589793 🤪
granted_sso_role_name      = Developer
common_fate_generated_from = aws-sso
credential_process         = granted credential-process --profile coolcompany/Developer

I'm also curious about this. I'm working with a team that (so far) doesn't use or need suffixes. I have run granted settings export-suffix set, leaving the suffix blank, and that also doesn't remove the warning. I have also set the GRANTED_QUIET=true environment variable and this also doesn't remove the warning. Any suggestions?


bug in the dev server reload - should not ask for a different port

Bug Description
INFO:robyn.logger:SERVER IS RUNNING IN VERBOSE/DEBUG MODE. Set --log-level to WARN to run in production mode.
INFO:robyn.logger:Added route HttpMethod.GET /
ERROR:robyn.logger:Port 8080 is already in use. Please use a different port.
Steps to Reproduce
No response
Your operating system
None
Your Python version (python --version)
None
Your Robyn version
None
Additional Info
No response

I'm working on this (#857)

@VishnuSanal , we will need a new PR for this, right?


Introducing node.js to get all features demonstrated in the project.

Thanks for the PR @AnselmHa!
I'm currently swamped with other matters, but I will review this PR as soon as I have some availability.

Ok, thanks. I'm preparing a second one, maybe you find time for both then.

Ideally these would be submitted as two separate PRs to be reviewed and merged individually.  I can review/test these two new features simultaneously if you prefer since they're currently together on your branch, but going forward it would be best to submit this type of thing as two separate.

I agree. I was not able to two part two without part one. Next one is separated :)

Reviewing this now.  Can you please help me understand the benefit of this new approach vs. the previous approach?
I agree that some folks may be pretty familiar with doing things from node, but the overall execution of the tool is already pretty simple - build the jar with a single maven command (all AEM devs already have maven), copy the jar to your project, and configure the JSON file.
My main concerns with what we'd have with this PR:

We now have two ways of building the jar - with maven directly or with node (which delegates to maven) so we've definitely increased the complexity of the README and the perceived complexity of using the tool.  If the tool looks complex, some people will be scared to try it.
The two ways of using the tool (direct vs node) also have different paradigms of where the files are generated and how they get into your project, further propagating confusion
-- With direct use, you have the jar and data-config.json in your code project, and the code gets generated exactly where it needs to be and can be compiled and committed with no additional manual steps
-- With node use, it appears the code is being generated within the generator project itself, and then needs to be manually moved to the code project.  Not only is this different and thus needs different README docs, but I fail to see how this is an improvement.

If node is truly buying us big benefits vs. the current usage, I'd entertain a discussion of whether or not it is uniformly better and should become the new way for everyone.  Otherwise, if this is just a personal preference that is different but not necessarily better than the current usage I think the node build option would more appropriately remain in a fork.
Side note, if you want to create a separate PR for the code that prevents file renaming if the generated file has not changed, I can definitely review that one while this issue is being discussed.

Thanks for taking time to discuss this. I guess we talk here about the perspective of the generator and different use cases within the README.md.
Use cases in READEME.md:

Experience aem-component-generator protect

From my perspective as a developer deciding to use the aem-component-generator, it would be good if aem-component-generator is self-contained so no need of copying anything in my project to see what it does.
Contribute to aem-component-generator would be easier especially for front-end developers if you can run and test the generator with three easy double-clicks on node-Tasks.
Developers have different skills and are working in several projects, what I'have seen done in node.js by different Developer types (front-end / back-end) together tell me that nodejs is definitely worth to be integrated. By the way, my first groovy-Project was triggered by an maven-plugin adaption, haven't see it before but use it since then.

Explaining the data-config.json

This is very important and should not be in the root readme, but in doc/Explaining-data-config.md
Having "Explaining-data-config.md" makes it easier to tell how to integrate aem-component-generator in another protect.

Integrating aem-component-generator in another protect

aem-component-generator needs a maven-plugin deployed to maven central then usage is easy.
As long as no maven plugin is available just copying and run a jar doesn't mean to be easy. I don't see projects acutally doing this in modern times.
So node.js is maybe just a quick possibility to integrate aem-component-generator in another protect, maven-plugin would be better.

Long story short, I changed the following:

separate "doc/Explaining-data-config.md"
separate "doc/Integration-with-node.js" from the README.md "### Step 7: Inspect and copy source files below in your project using node.js"
add a description how to use node with eclipse

@HitmanInWis did you found time to discuss the nodejs integration. In the meantime I added more templating functions... I don't know if this is the way you like too enhance the templating possibilities therefore I added it to same branch so you can test it easily all together. If you like the change I can separate it.

Hi @AnselmHa.
I've been absolutely buried lately, so trying to fit in reviews when I can.  I will get to these, just can't promise exactly when.
However, the best thing you could do would be to separate your changes (now 3) into separate pull requests, because some of the minor changes are easier to approve/merge.  I know that's a bit more work on your end to separate these features back out, but generally when submitting features to an open source project it is best to have one pull request per feature.  Do you think that's something you can do?

@HitmanInWis yes, of course. I don't how if you are willing to bring this in the project. And there are some dependencies between the changes, so I will split them when I now what you like. Would that be ok with you?

Here's the co-mingled features I'm seeing in this PR.

Add node.js support (unsure if this provides value, happy to further discuss in a PR of its own)
Update generation to only rename a duplicate file if the file contents are different (great idea, let's do it)
Richtext support (like the idea, but should follow the pattern of other field types)
Templating functions (interesting idea - trying to understand the value of what it actually saves for the developer - either they code it in the config or code it in the HTML file)
Tons of refactors/cleanups to existing code (all for it)

Though code cleanup can be good, it makes some of these incremental changes more difficult to validate and keep separate.  It might make sense to have a separate PR or even a couple for #5, with no other changes, as prep before doing the rest of these.
Lastly, for your feature #4, I believe a simpler version of this in PR #26 is going to be merged soon, so you may want to wait for that to avoid crazy merge conflicts.

@HitmanInWis  ok:

you just merge #26, beside I prefer templating in practice
I extract the refactorings and new readme.md
I create new pull requests for the other

Closing this PR in anticipation of separate PRs for the different features.

Regarding the templating @AnselmHa I'm not saying we can't do both the templating approach AND the simple approach that was already implemented in #26.  If they two work together without issue, based on configurations set in data-config.json, I can see merit in supporting both.


Add logging framework

Logging should be done through a standard Pythonic way. So far the application is silent.

Python has a default logging module - probably best to use that.
It should be possible to override logging behaviour - the instance of logger(s) should be gettable and settable.
By default the library should only log to stdout.

added methods for logging