rdpkeeped service does not starting

hi, i compilled source, all ok, i configured RdpKeeper.exe.config, run installservice.cmd as admin, service successfuly installed, but don't want to run, i tried manualy (error code 5 access denied), and i reboot PC, nothing, how to fix?

Hi,
Please make sure domain, username and password are correct. Try to connect manually using the same credentials.
What OS are you running it on / connecting to?

I tested on windows 7 and windows 10. Computer does not have domains. So I
completed only hostname. Username and password
On Tue, 25 Jun 2019, 00:02 publee<EMAIL_ADDRESS>wrote:

Hi,
Please make sure domain, username and password are correct. Try to connect
manually using the same credentials.
What OS are you running it on / connecting to?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/publee/RdpKeeper/issues/1?email_source=notifications&email_token=AE4OOQLGUEKOC6AELWQGRWLP4EY4VA5CNFSM4H3A6BQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOG5II#issuecomment-505179809,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE4OOQKBCCXM2PGORTWHEL3P4EY4VANCNFSM4H3A6BQQ
.

my compiled version https://mega.nz/#!jSAS1AwY!2RqwnME2UhbzVgWeJ_irRasXUxJIoNAjw9o0Uhedsi0
i completed only hostname field, username, and password!
if you have already compiled and working version, please share link, best regards

So if I understand it correctly, then using windows RDP you can connect to the machine specified in "hostname" by using "username" and "password".
But the service gives you "Access denied".
Please try to run RdpKeeper.Console with the same config file and post the output, it should look like this:
26.06.2019 0:20:08      Information     Host: upc User:\Lubo RDP Connection start DesktopWidth:1080 DesktopHeight:1920
connected to upc:3389
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@           WARNING: CERTIFICATE NAME MISMATCH!           @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The hostname used for this connection (upc)
does not match the name given in the certificate:
Common Name (CN):
        UPC
A valid certificate for the wrong name should NOT be trusted!
26.06.2019 0:20:10      Information     Host: upc User:\Lubo RDP connection successful
Press any key to stop all connections

Please try to run RdpKeeper.Console with the same config file and post the output, it should look like this:

i received different output for running console, what's next?

If I understand it correctly, then using windows remote desktop client you can connect to the machine specified in "hostname" by using "username" and "password".

yes

But the RdpKeeper service gives you "Access denied".

i received "Access denied". when i want to enable manually rdpkeeper service!

I created 1st release v1.0 from binaries on my computer, which is confirmed to work. Please try to download zip and run RdpKeeper.Console again.

Hi. Thanks a lot, after a few hours, I will check. Best regards
On Mon, 1 Jul 2019, 22:01 publee<EMAIL_ADDRESS>wrote:

I created 1st release v1.0 from binaries on my computer, which is
confirmed to work. Please try to download zip and run RdpKeeper.Console
again.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/publee/RdpKeeper/issues/1?email_source=notifications&email_token=AE4OOQK3WXBHYZBLF33G25DP5JICFA5CNFSM4H3A6BQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY7BOEA#issuecomment-507385616,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AE4OOQNMTPYS3Z5KVQTVIKTP5JICFANCNFSM4H3A6BQQ
.

as i see from console, you use absolute path to .DLL, when i running rdp console, i give error that cannot find libfreerdp_utils, and path to this app, is absolute to your path from where folder stored.

i can donate to receive functional solution!
how it working your software (working principle)? on system level, this tool keep rdp connection active, locally?

There are no absolute paths, I downloaded and extracted RdpKeeper.Console-1.0.zip on different computer with w10 64bit  and it is working. I have no 32bit OS, so I cannot test.
I use that succesfully on windows server at work to keep RDP session to localhost opened forever.
No need to donate, I do my best to make it working.
Prefered way is to run the service locally on automation server which will keep one or more RDP connections to localhost opened forever. But it should work properly also over network.
Based on the error message, looks like the problem is with 32/64 bits. Is your windows 64bit? Can you try to run it on 64bit os?

i tried on windows 10 x64, so as i understand, i need to run rdpkeeper console not from RDP, only from console mode?
i can run it using psexec to run from another user remotely?
what i do:
i completing RdpKeeper.Console.exe.config with my local username and password that i logged in system
when i runnin RdpKeeper.Console.exe , i was logged out. all correct?
so, all working :+1:

But it should work properly also over network.

how to use it?

RdpKeeper.Console.exe is just to test, if it works fine please try to install RdpKeeper.Service using same username/password/host
Over the netwok means that instead of using Hostname="localhost" specify compter name or IP address

i can run it using psexec to run from another user remotely?

No need for psexec, the RdpKeeper.Console/RdpKeeper.Service can run under any account. Important is to have proper credentials in .config file

ok, i will try to install service later, thanks, best regards

hi, i tested on 2 different windows 7x64 real machine (same error in virtual enviroment) and server 2008, error:
windows 7x64:

server 2008:

UPD: maybe need to compile using newest version of freerdp-sharp? like 1.1.0 ?
https://www.nuget.org/packages/FreeRDP-Sharp.Native/
maybe old version of freerdp have some issues ?

Hi, sorry for the delay, it's holiday season :)
System.Configuration.ConfigurationErrorsException means you have error in *.config file. I don't understand russian, but it is telling you the line number where you have a typo.

For the error "Unable to load dll..." please try to copy all files from x64 subdirectory one leve up, next to the rdpkeeper executable and also delete all files from x86 subdirectory and copy all files from x64 to x86.
This will cause to have freerdp x64 files in 3 places.


Bot installed but no response

Hello sir, how are you?
I have installed bot correctly and no error appear, but I still do not get response from bot.
Server Ubuntu 14.04
What can be wrong ? is there any command to run bot or it will automatically run?
Also what configuration needed to make BotFather ? ( Customize and put your new bot inline with BotFather )
Thanks

I found a bug that is impacting this script in some particular and specific case. I will correct the script soon with a new version for Ubuntu18.04LTS and I will release a paid version with web base control panel.

The bot should be always responding now many bug fix was made.

Bot not responding and I've done everything correctly.


Remove multiplier from resource docs, add it instead as an extra first dimension in descriptor shape

Per discussion today, it was decided that in order to keep the dimensionality of shape in the event descriptor consistent, that the multiplier should be added there as the first dimension. So for example in the case of two detectors w/ x-y dimensions of 10x10, with one collecting a single frame per acq, and one collecting 5, we would have
shape: (1, 10, 10)

and
shape: (5, 10, 10)

respectively in the descriptor. Since this tells you the multiplier, and you can fetch this information given a resource doc by looking back at the associated descriptor, the multiplier field can be removed from the resource doc creation.

@coretl @genematx @danielballan

Going to open a PR for this change soon.
From my understanding, the way this operates is that it holds off on producing a StreamResource until the index has been incremented by one. The index does not get incremented until multiplier number of "captures" or "exposures" have been processed.
So the only work to be completed for this issue is to do the following:

Add the multiplier as the first dimension of DataKey.shape
Ensure that the index provided by DetectorWriter.get_indices_written() and DetectorWriter.observe_indices_written() is divided by this multiplier so that it actually captures the correct amount of exposures
Add unit tests showing that describe() works as intended
Add unit tests showing that stream resources are actually batches of exposures

Also, I think batch_size is a better name for this...multiplier could mean anything and it took me a few passes to try and figure out what it actually meant.

Blocked on the merge of #606 since that reworks a lot of the overlapping code


fix some bugs of e2ef_test when opensds has both nvme pool and default pool

What this PR does / why we need it:
fix some bugs of e2ef_test when opensds has both nvme pool and default pool
Which issue this PR fixes* (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
None
Special notes for your reviewer:
None
Release note:
None

@wisererik PTAL


Moore's Voting Algorithm

To find the majority element from an array we can use this algorithm
My name is Ardra, a participant of GSSoC'21
Please assign me this issue
Thanks!!

I can implement this issue in java,c++,python.I am good at data structures and algorithm .Please assign me this issue under GSSOC'2021.

I would like to solve this problem using C++.

Hey @anubhavitis @dheerajkotwani
I am a GSSOC'21 participant(Discord Username -Oneway_Shruti(P)#9537)
I wish to contribute to Moore's Voting Algorithm I can write the code in C++ with a time complexity of O(n) and  also in python, along  with comments.
Do consider assigning me on this.


Status icon and text not showing in Status Bar

Though extension works, there is not menu item in status bar:

Closing as TSLint has been deprecated in favor of ESLint and this extension is no longer being maintained
Please look into migrating to use ESLint and the ESLint VS Code extension


Add support for function composition syntax

eclipse/ceylon#3229 looks like it will be in the next release as well, another binary operator. The precise operator doesn’t seem to be settled yet.

Looks like the operator is settled now (final form: >|>), see eclipse/ceylon@4c0288b45ae908ab91b00b25f889b0c380df30bd for spec.


Turn off the light after measurement session done

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 96.956%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2612

Relevant Lines:
2694

💛  - Coveralls


Setting an ETH manufacturer (IDFGH-12622)

Answers checklist.

[X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
[X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report
Is it possible to set the manufacturer of an ESP32-S3 connected via ETH, such that it shows up when doing an arp-scan?

You mean the vendor prefix of the MAC address?
Please check this example (S3 with SPI Ethernet)
https://github.com/espressif/esp-idf/blob/d4cd437ede613fffacc06ac6d6c93a083829022f/examples/ethernet/basic/components/ethernet_init/ethernet_init.c#L263-L270
where we use the locally administered OUI range, you can supply your own manufacturer's reserved address.

I did some more research as I didn't fully understand what I was asking!
For anybody else's sake who finds this (feel free to add/correct anything):

MAC addresses are typically allocated by IEEE
When performing an ARP scan - the name returned is the name allocated by IEEE, ESP does NOT have control over this
Read here for more info https://standards.ieee.org/products-programs/regauth/


During hyper server running , panic information was encountered，Why it happened？

panic occurred: PanicInfo {
    payload: Any,
    message: Some(called `Result::unwrap()` on an `Err` value: Os {
        code: 107,
        kind: NotConnected,
        message: "Transport endpoint is not connected"
    }),
    location: Location {
        file: "src/libcore/result.rs",
        line: 999,
        col: 5
    }
}

Backtrace:
2019-12-31T03:05:53.002699126+08:00 ERROR hiro - stack backtrace:
   0: hiro::main::{{closure}}
   1: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:481
   2: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   3: rust_begin_unwind
             at src/libstd/panicking.rs:311
   4: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   5: core::result::unwrap_failed
   6: hyper::server::conn::SpawnAll<I,S,E>::poll_watch
   7: <hyper::server::shutdown::Graceful<I,S,F,E> as futures::future::Future>::poll
   8: futures::future::chain::Chain<A,B,C>::poll
   9: futures::task_impl::std::set
  10: std::panicking::try::do_call
  11: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:82
  12: tokio_threadpool::task::Task::run
  13: tokio_threadpool::worker::Worker::run_task
  14: tokio_threadpool::worker::Worker::run
  15: tokio_timer::clock::clock::with_default
  16: tokio::runtime::threadpool::builder::Builder::build::{{closure}}
  17: std::thread::local::LocalKey<T>::with
  18: std::thread::local::LocalKey<T>::with
  19: std::sys_common::backtrace::__rust_begin_short_backtrace
  20: std::panicking::try::do_call
  21: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:82
  22: core::ops::function::FnOnce::call_once{{vtable.shim}}
  23: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b/src/liballoc/boxed.rs:746
  24: <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b/src/liballoc/boxed.rs:746
      std::sys_common::thread::start_thread
             at src/libstd/sys_common/thread.rs:13
      std::sys::unix::thread::Thread::new::thread_start
             at src/libstd/sys/unix/thread.rs:79
  25: start_thread
  26: __clone

Looking at the backtrace, it panics inside poll_watch due to a call to unwrap, but beyond that, it doesn't tell me much. There's no relevant unwrap calls inside that function, unless it's coming from either the MakeService or the Stream of incoming connections.
How are you constructing the Server?


🤖Failing-test: Open_im_sdkCreateTextMessage() return empty string.

Which job are failing?
NSString *json = Open_im_sdkCreateTextMessage([OIMManager.manager operationId], text);
text is valid.
json is @""
Which test are failing?
iOS APP
send text message ERROR
Since when has it been failing?
send text message ERROR
Testgrid link
No response
Reason for failure (if possible)
No response
Anything else we need to know?
No response

@boxiu

Confirm whether the login is successful;
Confirm whether the input parameters are correct;
If both of the above are correct, please post the log of the creation message here.

hi, It's been a long time since I saw your reply, so I'll close this question first.


[Event Request] Codeunit::370 "Bank Acc. Reconciliation Post" - Function PostPaymentApplications - OnPostPaymentApplicationsOnBeforePostPaymentApplns

Could You please, add the following event to the codeunit 370 "Bank Acc. Reconciliation Post" to manage the PostPaymentApplications
Object: codeunit 370 "Bank Acc. Reconciliation Post"
Function PostPaymentApplications(BankAccReconLine: Record "Bank Acc. Reconciliation Line"; var AppliedAmount: Decimal)
Publisher Event: OnPostPaymentApplicationsOnBeforePostPaymentApplns
Reason: To implement custom business logic and manage the PostPaymentApplications
Where is the event placed (see image attached)?:

at the begining of the function after the first error place the call to the event
OnPostPaymentApplicationsOnBeforePostPaymentApplns(BankAccReconLine,AppliedAmount,SourceCode);
Event Code:
[IntegrationEvent(false, false)]
local procedure OnPostPaymentApplicationsOnBeforePostPaymentApplns(var BankAccRecon: Record "Bank Acc. Reconciliation"; var AppliedAmount: Decimal; SourceCode: Code[10])
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


bug: Background toggle is clickable when popup is open

Type: bug
Platform: all
I don't think a user should be able to click a background toggle while popup is open.
Check out the codepen:
http://codepen.io/jason-engage/pen/zvOPrg

Greetings @jason-engage!
My sensors indicate that you need to update your issue through our custom issue form. We are now requiring all issues to be submitted this way, to ensure that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
I will have no choice but to close this issue if it is not resubmitted through the form. Please fill out the rest of the form, so that I may use my friendly robot powers to assist you.
Thank you!

https://youtu.be/hou0lU8WMgo
Thanks for pointing this!

Ionic Adds "popup-open" class to body when popup opens. So for this issue we can try
.popup-open .item-toggle * {
pointer-events: none;
}
So that all the toggles are not clickable.

Hello all! Is this still an issue with the latest version of ionic? Thanks!

Hello all! As it seems it has been a while since there was any activity on this issue i will be closing it for now. Feel free to comment if you are still running into this issue. Thanks for using Ionic!


Setting options.database_url has no effect in MigrationRunner( options )

When using node-pg-migrate programmatically by invoking MigrationRunner (lib/runner.js) with a database_url string. For example:
var MigrationRunner = require('node-pg-migrate/lib/runner')
var options = {
  database_url: 'pg://testuser:testpw@localhost:5432/test_db',
  dir: 'migrations',
  migrations_table: 'pgmigrations',
  actions: 'up',
  num_migrations: Infinity,
  file: ''
};
var runner = new MigrationRunner(options);
  runner.run(function (err) {
    if (err) {
      process.exit(1);
    }
  }
};

This will not work as there is a bug in lib/db that ignores options.database_url

This is because there is a typo in lib/db.js, line 13 (conenction_string should be connection_string)

the underlying issue is fixed. Can you please check if this is still a problem?

No response.
I checked it and options changed to:
var MigrationRunner = require('node-pg-migrate/lib/runner')
var options = {
  database_url: 'pg://ordamo:ordamopass@localhost:5432/ordamo',
  dir: 'migrations',
  migrations_table: 'pgmigrations',
  direction: 'up',
  count: Infinity,
  file: ''
};
var runner = new MigrationRunner(options);
runner.run(function(err) {
  if (err) {
    process.exit(1);
  }
});

Works, closing...


dep: Change the tendermint import

Currently we're using an old tendermint version, and we use an equal sign. Because of this, we have to use an override for tendermint in the sdk's gopkg.toml. This makes it hard to import the sdk, and use any type from tendermint. This is because overrides do not apply transitively with dep. Only overrides in the top directory you're calling dep ensure from get applied. Therefore in your downstream application you have to add an override import yourself, which is confusing,
We should change the tendermint import to be ^v0.22.0, or ^v0.22.4. (In the SDK its just getting replaced with v0.22.4 anyway) This would alleviate issues in the future as well.

I think, I agree with @silasdavis here: We should duplicate the few methods we use from tendermint instead of updating the dependency. See also: https://github.com/tendermint/iavl/issues/46#issuecomment-406555769

That sounds more optimal to me. However, I'm not sure what the ETA on that is. The fix I'm proposing is a very quick fix.

resolved by https://github.com/tendermint/iavl/pull/91


bump up go to v1.17

Description
bump up go to v1.17 in go.mod

I'm not sure why do we need this line:
replace github.com/dapr/components-contrib => ../components-contrib
Seems redundant.

I'm not sure why do we need this line:
replace github.com/dapr/components-contrib => ../components-contrib
Seems redundant.

Can you remove that in another PR?


Sitemap shows disabled products

Fixed. There will be some BC changes upcoming as I also want to make the plugin channel aware, which it is not at this time. But that's not yet and I will keep you update in #2 & #3.


Update plugin-api and mattermost-sever hashes

Summary

Because the ScheduleOnce job scheduler was merged to master, we can't depend on a PR branch that doesn't exist anymore

Ticket Link

none

@cpoile, given the various dependency bumps, should we still QA Review this one for confidence?

@lieut-data I think the e2e tests should be good for that. But if you feel we need it, I don't mind it of course (just want to be efficient with Prapti's time)

/update-branch

@prapti I think this just needs a very brief "are interactions that require the plugin-api working" kind of test. Start a few incidents, make a few reminders, broadcast channel working. If those work, then the dependency updates didn't break functionality.  The e2e tests should also be a good proxy for most of this. (except the reminder functionality)


Crash at startup when Goblins & Dungeons is installed

Installed Mods:
dawncraft-fixes-0.10.1.jar
Goblins_Dungeons_1.0.8.jar
Forge 40.2.9
Error:

java.lang.NullPointerException: Cannot read field "f_46443_" because "p_77624_2_" is null

crash-2023-06-16_17.49.20-client.txt

fixed in dev. haven't published. Will publish after fix #6


vulnerability in deps

│ High                         │ Prototype Pollution in node-forge
│ Package                  │ node-forge
│ Patched in               │ >= 0.10.0
│ Path                         │ @rsksmart/rif-communications-pubsub > libp2p-secio > libp2p-crypto > node-forge
│ More info                 │ https://npmjs.com/advisories/1561

@nduchak thanks for reaching out, but this module is deprecated and not maintained anymore.
We need to archive the repo though
cc @Stebalien


Segfault when inserting into a GTree

The following code causes a segfault in LGI 0.7.1 on Fedora 18:
local lgi = require "lgi"
local tree = lgi.GLib.Tree()
tree:insert("key", "val")

I'm not sure if this is a sane thing to do, since I was just playing around with the API with no particular purpose. Causing a segfault didn't seem right though, so I just thought I'd report it here.

Causing a segfault from Lua side is never acceptable, regardless of whether the code makes sense or not. This still happens in the latest lgi.

Causing a segfault from Lua side is never acceptable, regardless of whether the code makes sense or not. This still happens in the latest lgi.

As far as I know, the following is known by the Lua authors and is not considered to be a bug:
$ lua -v
Lua 5.3.4  Copyright (C) 1994-2017 Lua.org, PUC-Rio
$ lua -e 'debug.getinfo(2).func()'
[1]    17609 segmentation fault (core dumped)  lua -e 'debug.getinfo(2).func()'

I'm pretty sure the Lua authors consider all Lua-side segfaults bugs unless they depend on the debug library. The debug library is an exception for obvious reasons.


Spyder won't launch on windows 7 after anaconda2 install missing Qt "windows" in "".

I have tried to install the platform a few times now and it continues to result in this error.
The error window is attributed to pythonw.
Versions and main components

Spyder Version: 3.0.0
Python Version: 2.7.12
Operating system: Windows 7 Service pack 1

I have seen similar errors that were closed before being resolved asking for the output of qmake -query so I will include that as well.
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
C:\Users\Stephen>qmake -query
QT_SYSROOT:
QT_INSTALL_PREFIX:C:/Users/ray/qt5-x64-2.7/envs/_build/Library
QT_INSTALL_ARCHDATA:C:/Users/ray/qt5-x64-2.7/envs/_build/Library
QT_INSTALL_DATA:C:/Users/ray/qt5-x64-2.7/envs/_build/Library
QT_INSTALL_DOCS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/doc
QT_INSTALL_HEADERS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/include/qt
QT_INSTALL_LIBS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/lib
QT_INSTALL_LIBEXECS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/bin
QT_INSTALL_BINS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/bin
QT_INSTALL_TESTS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/tests
QT_INSTALL_PLUGINS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/plugins
QT_INSTALL_IMPORTS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/imports
QT_INSTALL_QML:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/qml
QT_INSTALL_TRANSLATIONS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/translation
s
QT_INSTALL_CONFIGURATION:
QT_INSTALL_EXAMPLES:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/examples
QT_INSTALL_DEMOS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/examples
QT_HOST_PREFIX:C:/Users/ray/qt5-x64-2.7/envs/_build/Library
QT_HOST_DATA:C:/Users/ray/qt5-x64-2.7/envs/_build/Library
QT_HOST_BINS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/bin
QT_HOST_LIBS:C:/Users/ray/qt5-x64-2.7/envs/_build/Library/lib
QMAKE_SPEC:win32-msvc2008
QMAKE_XSPEC:win32-msvc2008
QMAKE_VERSION:3.0
QT_VERSION:5.6.0

Please wait for Anaconda 4.3 (to be released tomorrow) and tray again

Closing because this bug is too old.


UnknownError: unknown error: unrecognized Blink revision

Hi Guys,
I have cloned this project into my laptop and installed the required npm's.
I am running both selenium and browsermob-proxy.
when I run npm test
I am getting this error
/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/atoms/error.js:109
var template = new Error(this.message);
^
UnknownError: unknown error: unrecognized Blink revision: a337fbf3c2ab8ebc6b64b0bfdce73a20e2e2252b
(Driver info: chromedriver=2.10.267517,platform=Mac OS X 10.13.4 x86_64)
at new bot.Error (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/atoms/error.js:109:18)
at Object.bot.response.checkResponse (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/atoms/response.js:106:9)
at /Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/webdriver/webdriver.js:134:24
at /Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/goog/base.js:1243:15
at webdriver.promise.ControlFlow.runInNewFrame_ (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/webdriver/promise.js:1539:20)
at notify (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/webdriver/promise.js:362:12)
at notifyAll (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/webdriver/promise.js:331:7)
at resolve (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/webdriver/promise.js:309:7)
at fulfill (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/webdriver/promise.js:429:5)
at /Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/goog/base.js:1243:15
==== async task ====
WebDriver.createSession()
at Function.webdriver.WebDriver.acquireSession_ (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/webdriver/webdriver.js:131:49)
at Function.webdriver.WebDriver.createSession (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/lib/webdriver/webdriver.js:111:30)
at Object.createDriver (/Users/Sunil/protractor-browsermob-test/node_modules/selenium-webdriver/chrome.js:460:30)
at ChromeDriverProvider.getDriver (/Users/Sunil/protractor-browsermob-test/node_modules/protractor/lib/driverProviders/chrome.js:67:27)
at /Users/Sunil/protractor-browsermob-test/node_modules/protractor/lib/runner.js:241:41
at _fulfilled (/Users/Sunil/protractor-browsermob-test/node_modules/protractor/node_modules/q/q.js:797:54)
at self.promiseDispatch.done (/Users/Sunil/protractor-browsermob-test/node_modules/protractor/node_modules/q/q.js:826:30)
at Promise.promise.promiseDispatch (/Users/Sunil/protractor-browsermob-test/node_modules/protractor/node_modules/q/q.js:759:13)
at /Users/Sunil/protractor-browsermob-test/node_modules/protractor/node_modules/q/q.js:573:44
npm ERR! Test failed.  See above for more details.
What changes i have to make in this project to work in my laptop and to capture the network traffic.  Please help me on this.
Thanks,
Sunil

I facing the exact same issues. The steps that I followed:-

Clone the project
Open in VS code and run npm install
webdriver-manager start in cmd
npm test

failed with the exact same error as above. Could someone pls help?

I facing the exact same issues. The steps that I followed:-

Clone the project
Open in VS code and run npm install
webdriver-manager start in cmd
npm test

failed with the exact same error as above. Could someone pls help?

I updated the chromedriver, chrome and protractor version. It resolved the issue


HTTP2 Adapter doesn't work with gzip response

Package
http2_adapter
Version
2.3.0
Output of flutter doctor -v
[!] Flutter (Channel stable, 3.7.12, on Fedora Linux 36 (KDE Plasma) 5.18.13-200.fc36.x86_64, locale pt_BR.UTF-8)
    • Flutter version 3.7.12 on channel stable at /home/vicente/fvm/versions/3.7.12
    ! Warning: `dart` on your path resolves to /home/linuxbrew/.linuxbrew/Cellar/dart/2.17.6/libexec/bin/dart, which is not inside your current Flutter SDK checkout at /home/vicente/fvm/versions/3.7.12. Consider adding /home/vicente/fvm/versions/3.7.12/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 4d9e56e694 (2 months ago), 2023-04-17 21:47:46 -0400
    • Engine revision 1a65d409c7
    • Dart version 2.19.6
    • DevTools version 2.20.1
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.0)
    • Android SDK at /home/vicente/Android/Sdk
    • Platform android-33, build-tools 33.0.0
    • Java binary at: /opt/android-studio/jre/bin/java
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)
    • All Android licenses accepted.

[✓] Chrome - develop for the web
    • Chrome at google-chrome

[✗] Linux toolchain - develop for Linux desktop
    ✗ clang++ is required for Linux development.
      It is likely available from your distribution (e.g.: apt install clang), or can be downloaded from https://releases.llvm.org/
    ✗ CMake is required for Linux development.
      It is likely available from your distribution (e.g.: apt install cmake), or can be downloaded from https://cmake.org/download/
    ✗ ninja is required for Linux development.
      It is likely available from your distribution (e.g.: apt install ninja-build), or can be downloaded from https://github.com/ninja-build/ninja/releases
    • pkg-config version 1.8.0
    ✗ GTK 3.0 development libraries are required for Linux development.
      They are likely available from your distribution (e.g.: apt install libgtk-3-dev)

[✓] Android Studio (version 2021.2)
    • Android Studio at /opt/android-studio
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 11.0.12+0-b1504.28-7817840)

[✓] VS Code (version 1.79.2)
    • VS Code at /usr/share/code
    • Flutter extension version 3.66.0

[✓] Connected device (3 available)
    • sdk gphone64 x86 64 (mobile) • emulator-5554 • android-x64    • Android 12 (API 31) (emulator)
    • Linux (desktop)              • linux         • linux-x64      • Fedora Linux 36 (KDE Plasma) 5.18.13-200.fc36.x86_64
    • Chrome (web)                 • chrome        • web-javascript • Google Chrome 109.0.5414.74

[✓] HTTP Host Availability
    • All required HTTP hosts are available

! Doctor found issues in 2 categories.

Dart Version
2.19.6
Steps to Reproduce
Any response with compressed content will throw an error "Unexpected character"
Expected Result
Any response with compressed content should be uncompressed automatically
Actual Result
I have no specific logs, just a DioExceptionType.unknown

Could you identify if the http2 package works with GZIP responses? If yes, then it's our adapter's issue, otherwise, it's caused by that package.

I believe that http2 doesnt support automatic gzip decompression.
https://github.com/dart-lang/http2/issues/41


fix #828

Fix the Code By Adding a Script to Scroll to top

@HunainSiddiqui Scroll to top feature is not showing. After resolving the conflicts, please open a new PR for review.
Thank you!


Proposal: RUM Configuration

The OTel Android library is essentially an OTel Java SDK wrapper that adds very useful features for Android apps on top. This provides huge value when it comes to adopting OpenTelemetry in Android apps as some of the features can be really difficult and/or time-consuming to implement manually, and some might even need specialized compilation tools that allow for bytecode instrumentation, which is accomplished very differently than doing the same for regular Java applications due to differences at runtime. So having Android-specific tools handy can provide an inestimable value when using OTel in an Android app, possibly comparable to creating an Android app with Android Jetpack tools vs without using those tools.
The problem
Providing several tools comes with an important challenge though, which is configuration. The challenge comes when we ask ourselves questions such as “What features are meant to be added out of the box?”, and “How should the ‘X’ feature behave by default?”, or “What aspects of the ‘X’ feature should be configurable?” And so on, and the reason why these are difficult questions is because all apps are different and can therefore have different needs, some of which might not be possible to foresee at the time of creating the feature.
There is a risk of making the library too opinionated if there aren’t enough config options available, but there’s also a risk of making it cumbersome to use if there’s a long list of flags and different params associated with several features, sometimes with several params associated to a single feature but only valid when the feature flag is enabled and so on, within the RUM config that would require making different combinations of flags and other params to make the overall agent work as expected.
The proposal
Because of the above, I’d like to propose dividing (and conquering) the overall functionality of the OTel Android RUM agent into 2 categories:

Initialization: Covers what’s needed to initialize the OpenTelemetry instance. This may include the app’s info (service.* params) as well as signal processors/exporters customizers, dynamic global attrs, resources, and clock configurations.
Instrumentation: Covers features that are not needed to initialize the OpenTelemetry instance. This includes auto-instrumentations though not necessarily limited to bytecode-instrumentation-related instrumentations, it could also cover things like crash reporting, ANR detection, and Activity/Fragment lifecycle instrumentations, which are arguably also auto-instrumentations, is just that they don’t rely on bytecode instrumentation to work.

With the intention of keeping both fully separated (in different artifacts) and allowing desired instrumentations to get installed during the initialization process. This will allow us to:

Keep the OtelRumConfig object focused on the initialization process only, preventing it from becoming a sort of cumbersome “god object” to deal with in the future, full of feature flags and a mixture of feature-specific params.
Not having to make opinionated decisions like “Which instrumentations are meant to be added out of the box?”.
Keeping the “core” lib lightweight and more straightforward to use for projects that need more specific customizations (as they wouldn’t get what to them would essentially be “dead code” packed into a single artifact that they would have to remember to disable before adding their desired features to avoid unexpected behaviors).
Users wouldn't need to know which instrumentations are enabled by default to check what they’d like to disable if needed, as nothing would be installed by default. We can add an example in the docs on how to set up the RUM agent with some “basic” or “minimum recommended” instrumentations for people who don’t have custom requirements and just want to quickly set the tool up and running with some basic functionality.

This approach of “installing” an instrumentation is already implemented in this repo, although, based on its javadoc, it seems like it was initially intended to be used as an internal feature. Nevertheless, the functionality is there already so I believe it shouldn’t take too many changes to do the separation of existing instrumentations into their own subprojects should we agree on going with this path.
I have seen similar approaches working well for widely used libs (in Android apps) such as Retrofit for example, where you can add a specific “serializer tool” of your choice into your project’s dependencies and set it as your “converter”. So I think this way of setting up tools shouldn’t be strange to Android devs.
There are more reasons why I think this "separation approach" is worth taking into consideration, but this is already a lot of text so, thanks for reaching the end 🙂 we can follow up in the comments if there are some questions and/or suggestions for this proposal.

Keep the OtelRumConfig object focused on the initialization process only, preventing it from becoming a sort of cumbersome “god object” to deal with in the future, full of feature flags and a mixture of feature-specific params.

I like the idea of separating the setup config. and the instrumentation config.

Keeping the “core” lib lightweight and more straightforward to use for projects that need more specific customizations (as they wouldn’t get what to them would essentially be “dead code” packed into a single artifact that they would have to remember to disable before adding their desired features to avoid unexpected behaviors).

Having a lightweight lib is important, for that, features that are not used can just be removed via minifyEnabled (not sure how well it works though, the code cannot be coupled).
Every feature that depends on an external package, should also be another library (jar/aar) and manually installed (or automatically via bytecode manipulation if the target is available at compile time), this would reduce binary size as well.

Users wouldn't need to know which instrumentations are enabled by default to check what they’d like to disable if needed, as nothing would be installed by default. We can add an example in the docs on how to set up the RUM agent with some “basic” or “minimum recommended” instrumentations for people who don’t have custom requirements and just want to quickly set the tool up and running with some basic functionality.

I'm not so sure about that, usually the friction of finding that something exists via documentation is already a huge entry barrier, plus getting something installed and working is another one (people don't read docs - most of the time).
I prefer the experience that I install something and everything is working by default, this is the best DX, unless there's a risk such as PII, high-performance impact, etc.
I prefer the experience where people opt out of simple stuff that can be installed automatically and opt in for stuff that requires extra setup such as external deps, Gradle plugins, etc.
So we don't need to be opinionated on what should be enabled by default or not, but rather we can do this automatically or not.

Having a lightweight lib is important, for that, features that are not used can just be removed via minifyEnabled (not sure how well it works though, the code cannot be coupled).

Yeah that's the thing though, the unused code would still be referenced somewhere but behind some conditions that are only evaluated at runtime, so I don't think R8 can help much in this case.

I prefer the experience that I install something and everything is working by default, this is the best DX, unless there's a risk such as PII, high-performance impact, etc.

I understand this, though I think it applies better to some libs than others. So for example, if I use a lib that is only a crash reporter then I'd expect the crash reporting feature to work well out of the box (send the reports to some backend with at least the stacktrace of the crash without having to configure too many things) as you mentioned, though for the case of this OTel Android lib which is meant to provide tools to send any kind of telemetry data, sending data automatically by default means that we know what type of data is a must for every project and also how it is expected to be shaped, the latter might clash with the separation of instrumentation vs setup configs, unless we provide a default config for all the default features that we're sure is the one almost everyone will need.
So In other words, having default features means that we need to be opinionated on what those features are that all, or most, projects need, and then also being opinionated as to how those features should behave by default too, as well as providing and supporting mechanisms to disable them, which in the end might still require people to read some docs anyway, which brings me to:

(people don't read docs - most of the time)

I think this is true to some extent, if we're talking about javadocs then yeah I agree most people don't bother reading it, but there are some places, such as what's in the README and "quick start" type of documentations that I believe most people do read, and the people who don't read it tend to look at online tutorials or StackOverflow posts where usually it takes one person who read the README to sort of copy/paste or rephrase what it says and it should be enough to get people sorted.

So we don't need to be opinionated on what should be enabled by default or not, but rather we can do this automatically or not.

I'm not sure I'm following this sentence, could you elaborate a bit more on the "do this automatically or not" part?

I'm not sure I'm following this sentence, could you elaborate a bit more on the "do this automatically or not" part?

For example, hooking up to an error signal handler, the activity lifecycle observers, and measuring slow and frozen frames, all of that is dependency-free and does not depend on external dependencies such 3rd party SDKs and plugins, so all is possible to be done automatically, I expect all those things to be enabled by default.
Measuring the performance of HTTP requests using the OkHttp lib depends on adding an interceptor, adding an external dependency (OkHttp itself), this cannot be done automatically, I mean it can be done via bytecode manipulation, but it requires adding a Gradle plugin, so it's not fully automatic, hence I don't expect this to be enabled by default, this is just an example though, I know the Android OTel ships OkHttp anyway.

I think this is true to some extent, if we're talking about javadocs then yeah I agree most people don't bother reading it, but there are some places, such as what's in the README and "quick start" type of documentations that I believe most people do read, and the people who don't read it tend to look at online tutorials or StackOverflow posts where usually it takes one person who read the README to sort of copy/paste or rephrase what it says and it should be enough to get people sorted.

My experience with that is the opposite, the majority of people missed most of the features (not enabling them) just because they didn't know they existed, and they were right there in all forms of documentation, it's not everyone, but the majority.

@LikeTheSalad I understand your points and I can relate, I had this discussion in the past, multiple times, and I was in favor of all opt-ins most of the time.
Time proved me wrong, People will go the extra mile to disable what they don't need because they see the data and they don't want it.
The opposite is a much bigger entry barrier, they will have to go the extra mile in configurations and installations to check if something is worthy, and they probably don't even start or give up in the very first lines of code, considering they find out the possible extra features, which was often not the case.
This is just my experience, there's no right or wrong, just the trade-off of considering things opt-in or opt-out.

Hey thanks for this discussion. Sorry it's taken me a little time to be able to share my thoughts.

There is a risk of making the library too opinionated if there aren’t enough config options available, but there’s also a risk of making it cumbersome to use if there’s a long list of flags [...]

I think we should strive to find a balance between ease of use and detailed technical configurability. I suggest, as a guiding principle (with respect to Rich Hickey) that we try to make the simple thing easy. That is, we should try and create tools such that:
Most users, with very little reading, should be able to get up and running quickly, with very few lines of code and achieve results that are not surprising.

most users

(one size doesn't fit all, but there's probably a Gaussian distribution!)

with very little reading (few docs)

(you shouldn't have to read multiple pages before getting started)

should be able to get up and running quickly

(if it's easy it should be fast to get started)

with very few lines of code

(shouldn't have to rearchitect your application to use this stuff)

and very few surprises in the outcomes

(the results should make sense to the notive user)

Historically, we did not want users to have to think much about otel initialization, because it can be quite complex. We hid all of the direct otel initialization from them and allowed hooks in a few small places to customize things. We assume that Android developers primarily want to deal with setting up opentelmetry-android and don't want to have to know about its dependencies (like the otel java sdk or api or exporters or all of that). Because of this, I am concerned that having two (or more!) artifacts will introduce more complexity and make the lib slightly harder to use.

Keep the OtelRumConfig object focused on the initialization process only, preventing it from becoming a sort of cumbersome “god object” to deal with in the future, full of feature flags and a mixture of feature-specific params.

I'm less worried about the config evolving into a god object. If we see it going in that direction, I think there are plenty of opportunities to carve off groups of functionality into smaller configs. I agree that config should only be set and used at startup time and should not be long lived. If that's the case right now, let's work on fixing it.

Not having to make opinionated decisions like “Which instrumentations are meant to be added out of the box?”.

I respectfully disagree. I think we should try and find the set of features that most users will want, and then make it easy for users that need extra customization to add/remove/alter features. There may not be a perfect set, but I think we can get it close enough.

nothing would be installed by default

I also respectfully disagree with this. I think a user who has gone out of their way to start using opentelemetry-android would expect some common core set of instrumentation/functionality to be included in the default configuration.
@marandaneto said

My experience with that is the opposite, the majority of people missed most of the features (not enabling them) just because they didn't know they existed, and they were right there in all forms of documentation, it's not everyone, but the majority.

And that is my experience as well. Users have an expectation (no matter how unreasonable 😅 ) that things should "just work". I think that the more we can try and make things "just work" the better.
I appreciate all this discussion! I'd like to better understand what we're actually trying to separate...because I think I've missed something. I see mention of separating "initialization" and "instrumentation" but also some mention of separating "config".
If the idea is to publish separate independent artifacts that contain small features that have some stand-alone merit, then let's have that discussion. I'm not opposed to it, I just want to grok what that looks like in practice. I'm reluctant to give a big menu of unrelated features to users and tell them to ala-carte start adding dependencies. It's too much work for users to pick and choose...and I haven't seen a current/modern/supported way of bundling an uber-aar (similar to how we bundle/repackage shade dependencies in other projects). If we had that, we could do it both -- provide the pieces and provide the pie.

Btw it's possible to install dependencies automatically with gradle plugins.
For example, people add the OTel Gradle plugin, if okhttp is on the classpath, you could install the otel-okthttp package, this is just an example that adding dependencies can also be automatized via plugins.
So in case many small feature packages depend on 3rd party dependencies, this could be a solution.
One day all one needs to do is to install the OTel Gradle plugin and nothing more, besides host, apiKeys, etc.

Hey thanks for this discussion. Sorry it's taken me a little time to be able to share my thoughts.

No worries, I know it's a lot to ponder about and I'm glad we can discuss these things, even if it's slowly (though I'm looking forward to having a dedicated SIG to avoid the typing 😅)

Most users, with very little reading, should be able to get up and running quickly, with very few lines of code and achieve results that are not surprising.
...
Historically, we did not want users to have to think much about otel initialization, because it can be quite complex.

Definitely, it's also what we had in mind when creating the Elastic agent, setting up OTel Java takes a lot of code, so we also hid the whole OTel setup and added some config options where it made sense and I'm pretty sure it's enhanced the overall user experience, especially when they just want to give it a quick try. So I'm all on board with making things as easy as possible, though I know from experience that there's a fine line between "helping a lot" vs "helping too much", and usually the consequences are maintenance hell and some users complaining about either lib size being big, or unwelcomed automatic behavior which is not too obvious to them, which could be surprising, unless they read the docs... So I think the 'not-reading-docs' issue can cause problems in both cases.

Because of this, I am concerned that having two (or more!) artifacts will introduce more complexity and make the lib slightly harder to use.

I understand where the concern comes from, but I think this is unavoidable, in fact, we already have 2 artifacts (the core one and the okhttp instrumentation) and we have a PR to add one more soon and issues to work on others in the future. And I think the reason is that telemetry isn't a "defined feature" where there's a clear behavior to be expected but rather a tool with virtually unlimited use cases, though not all of them will apply to every project, which is why users need to be able to choose what they want to use and ignore what they don't. Having a catalog of tools to choose from might be annoying at first when you only want to get to know the tool with a quick sample app, but I think it's the most sensible way to make it work in the long run (just image if the OTel Java SDK decided to include all these features into a single artifact, it's just not happening 😅 )

I'm less worried about the config evolving into a god object. If we see it going in that direction.

The god object is no joke, it will for sure turn our lives, and our users', into hell on earth.

I think there are plenty of opportunities to carve off groups of functionality into smaller configs.

Each of those opportunities will become a breaking change for our users, so what's more likely to happen is that we'll be hesitant about touching anything about the god object to avoid affecting them while having to keep maintaining a bunch of config params that might not be needed anymore, so we'll have to have some new configs and some deprecated ones in the same place while still supporting the old ones.. (which is highly likely to happen when there are too many features managed from a single place, at some point one will have to change, rendering the old config params useless, yet still referenced in many projects and that's when hell starts).
I agree that making our users read the docs is going to be annoying for a lot of them, but I don't think anything will be more annoying than having to use an API that keeps changing over and over. I've actually seen a lot of backlash from Android devs when using tools created by Google where they kept deprecating and creating a lot of major versions with breaking changes, so if Google gets backlash for that, I don't think we'll be an exception. That's why I'd like to try and search for some form of API config that's scalable and organized in a way that there's a clear separation of concerns, and frankly having a lot of unrelated config params in a god object seems to be the exact opposite of that.

I think we should try and find the set of features that most users will want, and then make it easy for users that need extra customization to add/remove/alter features.
...
And that is my experience as well. Users have an expectation (no matter how unreasonable 😅 ) that things should "just work". I think that the more we can try and make things "just work" the better.

I understand the benefits of this approach, and to be honest I think it would be great if we could find the "golden set of features" that most people will want in their apps. Though I frankly just wish it wouldn't have to mean adding feature flags, and possibly feature-specific params too, to the initialization config, maybe there's a way we can have our cake and eat it too, probably by going with uber jars as you mentioned (which I know it's possible by using the Gradle shadow plugin), or probably with a dependency-aware Gradle plugin as mentioned by @marandaneto, I'd like to further discuss the options we might have available.

I'd like to better understand what we're actually trying to separate...because I think I've missed something. I see mention of separating "initialization" and "instrumentation" but also some mention of separating "config".

It's just the two ("initialization", which is essentially what would live in OtelRumConfig, and "instrumentation", which is every tool that automatically generates telemetry), the separation of the configs will come naturally once those are separated, since the "instrumentation" part, which will cover the automatic instrumentations, will require each one to have its own config (like it's already happening with the okhttp auto-instrumentation for example). That way, not only OtelRumConfig wouldn't need to be aware of any auto-instrumentation flags, but it also wouldn't care about the configs params that those might need either.

I just want to grok what that looks like in practice

I think a good example is the OTel Java SDK with its auto-instrumentations, or maybe not even the auto-instrumentations, but also the implementations provided within the same SDK repo but in separate artifacts, such as the exporters. I think another example of having to use separate artifacts to set up a tool (although in a much smaller scale) would be Retrofit, where you must add one extra dependency if you want to get automatic response deserialization, Retrofit is a pretty popular tool in Android development so I don't think this concept should be too difficult to grasp in general for Android devs. Also, you can see it in Glide, another popular Android tool, it has extensions to make it work with other tools for which you need to add extra dependencies into your project, and people still use it, and I think the reason is that, after they understand the concept of core + feature catalog, it's easy to know how to do the rest for every existing feature as well for any new ones (since the way to use them all will be the same and there wouldn't be any exceptions to that rule, such as "special features" already in the core lib that would need to be disabled).
I think we all agree that providing an easy-to-use tool is important and I think we will be able to accomplish that, is just that I'd like to avoid falling into the trap of mixing things up to achieve it because, most likely that approach will come to bite us later which is almost certain to happen every time the single responsibility principle is broken.

@LikeTheSalad Thanks for writing out such a thorough and thoughtful response. That definitely helps me to better see what you had in mind and where the priorities/concerns are.

Each of those opportunities will become a breaking change for our users, so what's more likely to happen is that we'll be hesitant about touching anything about the god object to avoid affecting them while having to keep maintaining a bunch of config params that might not be needed anymore

I also respect the desire to not break users when we make changes, but until we reach some kind of stability around 1.0 I think that's going to be challenging. 😁
I think it's fine for us to keep this issue around for some time, as part of the decision record, but also for interested folks to continue chiming in on...but I would like us to figure out a path forward. I'd love to hear ideas about this. As a first step, does it perhaps make sense to

rename the current instrumentation module to android-sdk (or similar)
introduce a new top-level module called instrumentation-bundle

move the code in the io.opentelemetry.android.instrumentation package from android-sdk to the new instrumentation-bundle module.

make a new top-level module called instrumentation
begin incrementally migrating per-package instrumentations from instrumentation-bundle over to instrumentation as their own module with published artifacts.

where applicable, migrate the config for each module as well

after the above is done, we can delete instrumentation-bundle or use it to build an uber-jar (shadow jar) of all instrumentations.

I'm sure there will be some rough spots, but does that help get us moving?

Thanks for coming up with this alternative 🙏  I love it! - I think the migration can also be used as an excuse to convert the code being moved to Kotlin 🙌
In terms of namings (which is always the hardest part) I would suggest just one addition, regarding this part:

make a new top-level module called instrumentation

Which I believe is a good opportunity to just rename the existing top-level module auto-instrumentation to instrumentation instead, and add all the new submodules there.
Generally speaking, I really like this approach for several reasons, for example, it could potentially avoid us these kinds of issues in the future, since we could move some "androidx" dependencies out of the "core", or "android-sdk" module, into their own module (such as the fragment one and the fragment instrumentation) where we could keep upgrading the androidx.fragment dependency to its latest version all the time without having to affect users who might not want to use it but do want to use the "android-sdk" lib (or even allowing them to set a fixed version of the instrumentation module while keeping upgrading the "android-sdk" dependency to its latest version until they're ready to bump their project's compileSdk version). Anyway, it might be a thing or not, but what I'm trying to say is that it would be possible after these changes, unlike the way it is now, and there could be other benefits as well so I'm really looking forward to implementing something like this.

Hey, so I wanted to see how bad or how much work this restructuring would be, so I spent some time today running ahead of this. You can check out my fork's branch that has this suggested structure here: https://github.com/breedx-splk/opentelemetry-android/tree/restructure_repo_modules. I encourage folks to clone it and play with it.
A few points of interest:

There were a few oddities that suggested circular dependencies, but I was able to mitigate those by creating the topmost common module. That module contains a few classes that are depended on by both the android-sdk module and the instrumentation modules.
The instrumentation/common-api module is only named that way so that it doesn't collide with the topmost common module, which causes this headache.
I treated the single annotation as instrumentation, suggesting that we may build more in the future (we've talked about it)
There could be a few unnecessary dependencies in the instrumentation libs
I tweaked how each library output aar is named. Please check my work and make sure I'm not insane. :)
The project builds and tests pass.
I had to change the interface of InitializationEvents.recordConfiguration() to take a map instead of config, to prevent improper dependency coupling. Just kicking the can down the road some more.

This structure is feeling surprisingly good to me.
Unless folks end up finding anything really concerning, I'm cool with moving forward with this approach and can probably start doing some piecemeal changes. As that branch stands now, it touches most files in the repo and would be madness to review. 🙃

Finally had a chance to take a look at the whole proposal. At a high level, I definitely agree with the "core + installable instrumentation modules" design. This is very much the direction of how I see the Embrace SDK going - this allows folks who want to leverage the Android Extension to select the feature set they want a la carte. If they only want crashes, they shouldn't have to bare the runtime burden of all the other features. I see the following advantages of such a design:

This keeps the core SDK as lightweight as possible, both in terms of install size and runtime burden
The scrutiny of adding new modules that pull in additional dependencies can reduced because they wouldn't automatically bloat the size of the core SDK they aren't installed out of the box
Managing minimum version of dependencies will be less tricky - if a module requires a new version of some dependency, it doesn't automatically move the entire SDK up a level
A modularized architecture should reduce the burden of contributions as you wouldn't have to know the lifecycle and workings of the entire thing to add or modify a single module.

That said, I do agree that the extension shouldn't be completely opinions free - there should be a reasonable set of default modules that are "enabled" out of the box so that the default, no-configuration experience provides a common set of features that the maintainers think unopinionated folks should have. Those that want to add or remove modules based on their needs, they should be able to do so, but for the portion of users who just want what we recommend, they should go with the default, which can be determined later (and does not have to be set in stone).
As the SDK goes down this path, there are probably some points to keep in mind:

What is the contract between the instrumentation module and the core module? Is there an additional API that will be exposed so the instrumentation module can interact the the core module, or will the just leverage the OTel Java API? If it's the former, dopes that mean additional versioning??
Are there rules about how instrumentation modules can build on top of or enhance each other, or should they be completed independent?
How do the instrumentation modules described differ from regular OTel instrumentation libraries? Is this just a packaging issue or is there something fundamentally different between the two?
How configurable should the core module be? That is, are the opinions it implements essentially fixed, or is there a desire for some aspects of it (e.g. how sessions are defined) be configurable and/or extensible?

There are probably a lot more issues that will come up as the extension heads down this path, but overall, I think it's a really positive step forward.

This is solved after the instrumentation API implementation.


Stacked progressbars are missing in v4

So I noticed that the Bootstrap 4 has no documentation on stacked progressbars. Are they gone or is this simply missing? I hope the later, as stacked progressbars are quiet useful.

They are gone since the <progress> element basically didn't allow it. Given some of the other problems we've run into with that move, however, I'm thinking we should revert some of the progress bar changes. Maybe we can rebalance some things and make using the <progress> a seccondary option.

Given some of the other problems we've run into with that move

Such as?

I think loosing the stacked progress bar functionality would be shame. Could you leave in the div.progress bars so the functionality does not disappear....

stacked progress bar is needed! Please!

+1 Need! Stacked! Bars!

up vote +1 for stacked progress bars!

@magnusmanske @simran-ssk Per our contributing guidelines, please use GitHub's reactions feature instead of making "+1" comments. Thanks.

Any news on this?

Any update on what's going to happen to this rather useful feature? Will it be in 4.0? Will it be in 4.1?

Switched back to div.progress instead of <progress> in #21473, allowing progress components to have multiple bars.


Suggested option: label_as_placeholder

Would be pretty cool if you could hide label and add it as placeholder instead in one option.
Something like:
<%= f.text_field :postal_code, label_as_placeholder: true %>

would generate:

  Postal code
  <input placeholder="Postal code" class="form-control" name="client[postal_code]" id="client_postal_code" type="text">

Today you would need the following to get this behaviour:
<%= f.text_field :postal_code, hide_label: true, placeholder: t('activerecord.attributes.client.postal_code') %>

Thanks for the suggestion! I like the idea. 👍


make regions roles instead of immaterial entities

Description of the issue
Part 1
While discussing Issue #1489 with the OVGU-Group, we agreed that the current structure of spatial region should be slightly changed.
One reason for that is the fact that study region considered region and interacting region are currently on the same hierarchical level as one-two-three and zero-dimensional region.
Part 2
Right now, subregion is a subclass of spatial region and has only one child, study subregion.
study subregion is defined as: A study subregion is a subregion of a study region.
but has no relation to study region, neither through inheritance nor axiom.
Are subregion and study subregion important for the ontology?
If we decide to make the regions into roles, study subregion has to be edited as well.
This is a little bit confusing, I offer a solution below but I am not sure, since subregion is defined as a spatial region that is part of a spatial region, so theoretically, a subregion could be bearer of the study region role as well, which would make the distinction obsolete. This may be related to the circular definition of subregion.
Ideas of solution
Make the different regions into roles of spatial region instead.
study region role:
definition: A study region role is a role of a spatial region that is under investigation and consists entirely of one or more subregions.
interacting region role:
definition: An interacting region role is a role of a spatial region that interacts with a spatial region that has the study region role. It is part of a spatial region that has the considered region role, but not a study region role.
considered region role:
definition: A considered region role is the role of a spatial region that is used in an analysis.
Part 2
Change study subregion into a role.
study subregion role
definition: The study subregion role is the role of a subregion that is under investigation and is part of a spatial region with the study region role.
'subregion' and 'part of' 'spatial region' and 'has role' some 'study region role'
The current examples of usage, alternative labels and the term tracker items of the regions should be included in the new roles as well.
Workflow checklist

[ ] I discussed the issue with someone else than me before working on a solution
[ ] I already read the latest version of the workflow for this repository
[ ] The goal of this ontology is clear to me

I am aware that

[ ] every entry in the ontology should have a definition
[ ] classes should arise from concepts rather than from words

Why two issues for the same topic?

@l-emele I united the two issues to one. The reason I made two separate ones in the first place was because I thought the discussion about the definition/use of subregion could maybe be worth its one issue, but I agree that it seems kind of unnecessary in hindsight.
Regarding your suggestion from the other issue:
I think having those role is a good idea. However, I think we should add these additionally and not instead of the existing classes. We should keep then the existing classes as equivalent classes.
I somewhat disagree. As explained in the issue, having the regions at the same hierarchical level as BFO-metacategories seems poorly constructed.
Counter-Proposal:
Implement one meta-class under spatial region that contains the equivalent region-classes, for example (rough draft):
region of relevance:
definition: A region of relevance is a spatial region that is mentioned in any study or analysis.

As explained in the issue, having the regions at the same hierarchical level as BFO-metacategories seems poorly constructed.

I agree that the current structure could be improved.

Counter-Proposal: Implement one meta-class under spatial region that contains the equivalent region-classes, for example (rough draft):
region of relevance: definition: A region of relevance is a spatial region that is mentioned in any study or analysis.

I am fine with this.

Okay, so should I implement?
@stap-m

@adelmemariani does the OEKG break if the classification of study region etc change?


Add replace, after and before function

Hi,
I have to add the jQuery functions "before", "after" and "replace" to this plugin for my own project.
So I want to share it now. Please have a look into this.
But I don't know how to write tests for these cases. Can you help me?
Best regards

Thank you, I'm purely doing maintenance on this repository now, but may pull this in and release in the near future.

Hi Vmadmax
it seems interesting for me, could you explain  / doc your methods?
Can we use them?
Thanks
Regards


Add commits up to 2/10

These commits need to be changed in their respective location to maintain consistency.
Add but don't release (for now).
https://github.com/sigma67/ytmusicapi/commits/master

Resolved in https://github.com/codyduong/ytmusicapiJS/commit/f3c7994082b98d9b6622caae05da71a1ada3fa47


after i edit in my save file i go into the game then the all shops in the camp has been disappeared

i need help please

Make sure you are using the latest version of MCDSaveEdit. If that isn't the problem then please send me a copy of your save file and I will take a look.


nc_test4/tst_vars2 fails on OSX

Seeing a crash on OSX but not Windows or linux for tst_vars2.  Debugging.

@edhartnett  The first commit that fails is e0577cb2.  Output is
(....)

*** Tests successful!
Abort trap: 6 (core dumped)

Note to self: compiling with address sanitizer, we see the following (sorry it's a bit long).
** Testing netcdf-4 variable functions, even more.

 Unexpected result, /Users/wfisher/Desktop/t/netcdf-c/nc_test4/tst_vars2.c, line: 1557


CSV import for clients

How's it going? This is my first time contributing to an open source project and I was hoping to help out with this issue. If there is someone else working on it already just let me know and I'll see if I can't help out somewhere else. Thanks!

@anubiskhan Thanks for your consideration here! Unfortunately, we've halted development on this project for now. The team we were developing it for ended up having to use a different solution.
If you'd like, there are still a lot of other Ruby for Good projects that could use contributions. Specifically, https://github.com/rubyforgood/diaper and https://github.com/rubyforgood/diaperpartner are two of the biggest ones.
Thanks again! 👍

@jgaskins Sounds good. I will check out these other 2 projects. Thanks!


feat: add prefix option to DiagConsoleLogger

see https://github.com/open-telemetry/opentelemetry-js-api/issues/52
Introduced an optional solution for this issue.

This will give the same prefix to every log. Multiple tracing components in the same process will still not be able to be differentiated.

This will give the same prefix to every log. Multiple tracing components in the same process will still not be able to be differentiated.

yep, this prefix intended to give a context for the host itself, not for OT.
currently, the logs are like that:
~/Workspace/test_ot_js > PORT=1301 NAME=my-server npm start
> ts-node app.ts

Applying patch for<EMAIL_ADDRESS>Applying patch for<EMAIL_ADDRESS>[my-server] Listening for requests on http://localhost:1301
http instrumentation incomingRequest http
http instrumentation outgoingRequest http
http.ClientRequest return request
http instrumentation incomingRequest HTTP
[my-server] Got body: {test: 1}
outgoingRequest on response()
outgoingRequest on end()

IMO we should have the option to add a prefix for OT logs so the clients debugging a flow will be able to understand the source of each log

Just saw the reference https://github.com/open-telemetry/opentelemetry-js/issues/2104
probably a better approach, so we have the option to understand which package exactly triggers this log instead of just "OpenTelemetry"

A global prefix could be combined with a namespace for additional information. There is no reason they can't coexist. If you write a custom Logger that dumps to a logging library like pino or bunyan you might get host information "for free" though.

I think this has been implemented with https://github.com/open-telemetry/opentelemetry-js-api/pull/62/files so we should close this ?

reopen this one because the newly ComponentLogger is only for components (per-package) namespaces, IE it assumes that we have a global logger already.
In this case, we want a global prefix for the host itself, so we will have a log context for entire OpenTelemetry logging namespace, WDYT?

reopen this one because the newly ComponentLogger is only for components (per-package) namespaces, IE it assumes that we have a global logger already.
In this case, we want a global prefix for the host itself, so we will have a log context for entire OpenTelemetry logging namespace, WDYT?

I think you could just construct a custom logger that does this and set it as the diag logger. This is why the logger is settable so we don't have to implement any options in the API itself


Pass decrement amount value through to recipe remainder handler

Closes #218
This correctly handles the amount parameter from the output slot mixins instead of ignoring it. This fixes mods that alter the amount of items consumed by a recipe through mixins (or some potential future API).

Confirmed working with my changes to Stonecutter Recipe Tags in https://github.com/TropheusJ/stonecutter-recipe-tags/pull/6
Before crafting:

After crafting:

I found another, broader, issue with the remainder API mixins: handleRemainderForScreenHandler doesn't "split" the stack and return the split-off part, it just decrements a stack. The mixins return the current stack, not the split-off stack with 0-to-amount items.
What do you think we should do about this? As far as I can tell, only StonecutterOutputSlotMixin is problematic because it uses the size of the split stack to determine if something was crafted.
Should we:

refactor handleRemainderForScreenHandler even more

to either return the split stack OR
to return the size that the stack would be

write some hack that just makes an amount-size stack to return, regardless of how many were actually consumed

I'm going to implement option 2 for now since that's the easiest thing that works, but it might break in the future.


Redis key-value distribution with twemproxy compatible with phpredis redisArray

Implementation to use key-value distribution with twemproxy compatible with phpredis redisArray (https://github.com/phpredis/phpredis/blob/master/arrays.markdown)

nicolasff can you please tell me why this pull request is still not accepted & merged?

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.0 out of 2 committers have signed the CLA.:x: amol.r:x: amolrajobaamol.r seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

rcrc32 (implementation compatible with phpredis redisArray )
If there is a need to use key-value distribution as per phpredis redisArray use hashing function 'rcrc32' and distribution mode 'redisarray'.


Build the docs when the workflow is modified

What does this PR do?

Build the docs when the workflow is modified
Motivation

Because it's not the case currently
Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

/merge


Fix Keras imports.

Description
Brief Description of the PR:
Recently, Keras changed how you must import internal symbols. Now, you must import private symbols from keras.src instead of keras, e.g. you must use from keras.src.utils import tf_utils instead of from keras.utils import tf_utils. See slide 12 of the April Keras community meeting slides for details Because old versions of Keras, including the current stable version, require the old import form, this PR changes every file importing internal Keras symbols to try both import forms: first it tries importing the new version (with keras.src), and if that fails, it tries importing the old version (with keras)
Without this change, TF Addons cannot be imported with the latest keras-nightly pip package.
Fixes # (issue)
Type of change

[x] Bug fix
[ ] New Tutorial
[ ] Updated or additional documentation
[ ] Additional Testing
[ ] New Activation and the changes conform to the activation contribution guidelines
[ ] New Callback and the changes conform to the callback contribution guidelines
[ ] New Image addition and the changes conform to the image op contribution guidelines
[ ] New Layer and the changes conform to the layer contribution guidelines
[ ] New Loss and the changes conform to the loss contribution guidelines
[ ] New Metric and the changes conform to the metric contribution guidelines
[ ] New Optimizer and the changes conform to the optimizer contribution guidelines
[ ] New RNN Cell and the changes conform to the rnn contribution guidelines
[ ] New Seq2seq addition and the changes conform to the seq2seq contribution guidelines
[ ] New Text addition and the changes conform to the text op contribution guidelines

Checklist:

[x] I've properly formatted my code according to the guidelines

[ ] By running Black + Flake8
[x] By running pre-commit hooks

[ ] This PR addresses an already submitted issue for TensorFlow Addons
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] This PR contains modifications to C++ custom-ops

How Has This Been Tested?
If you're adding a bugfix or new feature please describe the tests that you ran to verify your changes:

Ran the official TensorFlow models with the updated TensorFlow Addons package, confirmed it worked correctly.

@hyang0129
You are owner of some files modified in this pull request.
Would you kindly review the changes whenever you have the time to?
Thank you very much.

CC @bhack

Are you using try/except as it is faster instead of checking the version?

Are you using try/except as it is faster instead of checking the version?

No, I use try-except because the issue only affects recent keras-nightly versions, and users with older keras-nightly versions need the old import. I don't think there's an easy way to check if the keras-nightly commit is newer than a certain commit.

I think, but that version only refers to the stable version. The try-except will work on any given commit of Keras, which allows any version of keras-nightly to work. This is a fairly minor use case, so I can switch to a version check if you prefer.

Right, It is that keras-nightly is a quite ambiguous concept.
See my old point (2021) at:
https://github.com/keras-team/keras/issues/14867#issuecomment-876002266
I am ok with both. I am only worried that in the future users will be surprised by the wrong fallback import if the env is broken.
/cc @seanpmorgan what do you think?

@bhack I switched to checking tf.__version__ instead of using a try-except statement. I'm happy to switch it back if you prefer the try-except statement. The tf.__version__ check means older version of keras-nightly will not be supported, but this is fine as users should expect to have to update the nightly TF and Keras packages if they also update TF-Addons.
The issue is causing various things to break, such as the official models, so it would be great if this could get merged quickly. Since @seanpmorgan hasn't responded yet, can you review this without @seanpmorgan's approval?

No problem, I am re-running two failed job. The I'll merge it.

Thanks @bhack! Agreed, without CI coverage we cannot make any compatibility guarantees.


Add CMakeLists.txt

I added a CMakeLists.txt for easier integration in other projects. Usage is documented in the README.md.
Issue: #2
Tested with Ubuntu 21.04 and CMake version 3.18.4

Great. Thanks for the PR


Picture IOS not display

Bonjouur, on IOS, I can not display the image, do you have a solution?
(On android it works well)

hrm... I havn't looked onto this for a long time... and I can't tell when I have time to test that. Maybe if someone uses this library she or he can tell if iOS is broken?

Could be the problem that the argument fileName is missing. It's required for iOS as mentioned in #16

I keep seeing the thumbnail come back as an all white image, is there a fix for this?


vuejs/vue and this repository links to unencrypted vuejs.org site

You probably have https implemented but not linked

Good catch

It might not take too long to fix the descriptions, just add an 's' to every protocol there.

Obviously. I personally just don't have the privileges for those repositories.

@LinusBorg Are PR's encouraged for this?

It's probably easier to just force SSL. I believe @yyx990803 has access to do this.

SSL appears to be forced now, so closing.


Build fails on JDK9

Please answer these questions before submitting a bug report.
What version of OpenCensus are you using?
This is against master ca3e76f3
What JVM are you using (java -version)?
java version "9.0.4"
Java(TM) SE Runtime Environment (build 9.0.4+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode)

What did you do?
If possible, provide a recipe for reproducing the error.

check out the project
./gradlew build

What did you expect to see?
successful build :-)
What did you see instead?
./gradlew build

> Task :opencensus-api:compileJava FAILED
warning: [options] bootstrap class path not set in conjunction with -source 1.6
warning: [options] source value 1.6 is obsolete and will be removed in a future release
warning: [options] target value 1.6 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
error: warnings found and -Werror specified

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':opencensus-api:compileJava'.
> Compilation failed with exit code 1; see the compiler error output for details.

./gradlew build --stacktrace

> Task :opencensus-api:compileJava FAILED
warning: [options] bootstrap class path not set in conjunction with -source 1.6
warning: [options] source value 1.6 is obsolete and will be removed in a future release
warning: [options] target value 1.6 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
error: warnings found and -Werror specified

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':opencensus-api:compileJava'.
> Compilation failed with exit code 1; see the compiler error output for details.

* Try:
Run with --info or --debug option to get more log output.

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':opencensus-api:compileJava'.
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70)
        at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
        at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62)
        at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60)
        at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97)
        at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87)
        at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52)
        at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
        at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
        at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
        at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241)
        at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626)
        at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581)
        at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98)
        at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
        at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
        at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: org.gradle.api.internal.tasks.compile.CompilationFailedException: Compilation failed with exit code 1; see the compiler error output for details.
        at net.ltgt.gradle.errorprone.ErrorProneCompiler.execute(ErrorProneCompiler.java:74)
        at net.ltgt.gradle.errorprone.ErrorProneCompiler.execute(ErrorProneCompiler.java:23)
        at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.delegateAndHandleErrors(NormalizingJavaCompiler.java:98)
        at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute(NormalizingJavaCompiler.java:51)
        at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute(NormalizingJavaCompiler.java:37)
        at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.execute(CleaningJavaCompilerSupport.java:35)
        at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.execute(CleaningJavaCompilerSupport.java:25)
        at org.gradle.api.tasks.compile.JavaCompile.performCompilation(JavaCompile.java:207)
        at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:192)
        at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:124)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
        at org.gradle.api.internal.project.taskfactory.IncrementalTaskAction.doExecute(IncrementalTaskAction.java:46)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
        at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:121)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199)
        at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:110)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:92)
        ... 29 more

At the first glance there isn't much in this stack trace to get started.
I can confirm that using a JDK 8 (1.8.0_131) the build worked.

Hi Alex, thanks for reporting that!

> Task :opencensus-api:compileJava FAILED
warning: [options] bootstrap class path not set in conjunction with -source 1.6
warning: [options] source value 1.6 is obsolete and will be removed in a future release
warning: [options] target value 1.6 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
error: warnings found and -Werror specified

It seems that the compiler issued some warnings. @al3xandru since I currently don't have a java 9 environment, would you please help paste the whole output so we can examine what went wrong?

@HailongWen I'll rerun it and see if there's anything useful in the output.  At first thought, I don't remember seeing anything useful (no warnings or anything to give us a hint to where to start looking).

I think the error is due to source and target set to 1.6, combined with -Werror.
I tried building with Java 9 on Travis, and I got the same warnings.  However, it passed when I removed -Werror and fixed some Error Prone warnings.
branch: https://github.com/sebright/opencensus-java/tree/oraclejdk9
build: https://travis-ci.org/sebright/opencensus-java/jobs/344666042
compiler warnings: https://travis-ci.org/sebright/opencensus-java/jobs/344666042#L597-L602
We should fix these warnings and then add Java 9 to CI.

I also saw an "illegal reflective access" warning from Mockito: https://travis-ci.org/sebright/opencensus-java/jobs/344666042#L1597-L1601
:opencensus-api:testWARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.mockito.cglib.core.ReflectUtils$2 (file:/home/travis/.gradle/caches/modules-2/files-2.1/org.mockito/mockito-core/1.9.5/c3264abeea62c4d2f367e21484fbb40c7e256393/mockito-core-1.9.5.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain)
WARNING: Please consider reporting this to the maintainers of org.mockito.cglib.core.ReflectUtils$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Let me know if I can test anything locally.
Any ideas what the warning https://travis-ci.org/sebright/opencensus-java/jobs/344666042#L600 means:

An exception occurred while looking for AutoValue extensions. No extensions will function. This may be due to a corrupt jar file in the compiler's classpath. Exception: java.util.ServiceConfigurationError: com.google.auto.value.extension.AutoValueExtension: Provider com.google.auto.value.extension.memoized.MemoizeExtension could not be instantiated

Thanks.  I tried upgrading to AutoValue 1.5.3.  That fixed the warning with Java 9, but it failed with Java 7:
https://travis-ci.org/sebright/opencensus-java/builds/344955952
The error message is here: https://gist.github.com/sebright/414c04e1fb7ab072f1cf92628298efbf#file-autovalue-1-5-3-error-with-java-7

I turned off -Werror with Java 9 in #1016, so the build should succeed now.

I remembered about the problem with the upgrade. The answer from auto-value was to generate files using java > 7 but the generated files will be java 6 (or 7 don't remembered exactly) compatible.

Here is the link:
https://github.com/google/auto/issues/449