Switch to lewton

Hi, just have published the 0.6.0 release of lewton. It has the seeking support we spoke about and supports stable Rust (1.18). Also, there is an async mode, which doesn't support seeking though. Maybe its time to switch to lewton? If you see any blockers, please say so!

Doesn't support soft float ARM yet :-/

@wfraser yeah, there is no support for fixed point math, but for that one you seem to keep tremor around. You can still replace the vorbis dep with lewton, no?

Yes, I'm definitely planning on switching to lewton in the near future, I'm just too busy for the moment. Probably sometime within the next month.
@wfraser I'm planning on keeping tremor support around for this.
I might also support libogg at least for sometime, since it's basically no extra maintenance once I support tremor. lewton will be the default however.
I'm not too sure what to do about async yet. I'd like to use it, but it might be make it complicated to support both async lewton and non-async tremor. At first I'll probably stick with synchronous, and later see if and how I could support async.
@est31
What is missing to lewton to have seeking in asynchronous mode ? Is there any chance lewton might support a fixed point mode eventually ? This aren't high priority requirements for switching to lewton, but would definitely be nice

What is missing to lewton to have seeking in asynchronous mode?

Two things:

First, I'd need to find out how to actually represent seeking in async mode in a smart way -- how can I use tokio-io and futures traits to express such an API? I'd need two apis, one in lewton, and one in the ogg crate where the seeking code is (its generic over ogg formats used).

Second, I'd have to refactor the seeking code in the ogg crate to actually support async. The first step towards async seeking is done -- blocking one, so I already know the algorithm, just have to move the data from the stack to structs, etc.

It took me quite a bit of time to refactor the ogg crate to support async the tokio way (not the hackish way I had it before), seeking is involving far more back and forth of system calls, so it might be even harder to port.
IDK, given your statement async seek support will be mostly useless to you anway until there is fixed point support? I guess I'll give that one a try first...

how can I use tokio-io and futures traits to express such an API

This is maybe something that should be brought up to tokio authors. They might have ideas on what an AsyncSeek trait would look like.

IDK, given your statement async seek support will be mostly useless to you anway until there is fixed point support? I guess I'll give that one a try first...

When using tremor, I can probably offload the ogg decoding to a separate thread, with a channel sending decoded packets back to the main thread.
In any case, even ignoring tremor, async requires some bigger changes in librespot so it will probably come later.

Actually thinking about it I'll probably keep libogg the default for some time. I prefer not to require a too recent stable version.
I'll probably switch to lewton in one rust release cycle (6 weeks). After this I'll encourage people with old compilers to use libogg/tremor, which requires me to support at least one of them even if lewton were to get fixed point support and asynchronous seeking. I'll drop support in two or three cycles.

Lewton support was added in d1447d2bfb88db6fb9b9293b22c1a96d8d4dccbe.
Build with cargo build --features "with-lewton" to enable.
I'll enable it as the default when Rust 1.20 comes out at the end of the month.
Thanks for your great work @est31


Unable to add Google analytics tg

I need to include the Google anaytics tag in header. I don't seee a way to do that. Please help.

@bhattumang7 I have opened this PR https://github.com/YoussefRaafatNasry/portfolYOU/pull/43 to add Google Analytics support, after merging you can use by adding this in your _config.yml:
### Analytics ###
analytics:
  enabled: false  # Set true to enable analytics
  google:
    tracking_id: UA-XXXXXXX-1

A gentle check to see if there is progress? Thank you.

A gentle check to see if there is progress? Thank you.

Currently development is paused until the 11th of June,
Sorry for the inconvenience.


wallet, integration: Fix watchonlywallet bugs

Bugs that affected reorganizations in the watch only wallet code are fixed and an integration test in added to test the functionality of the watch only wallet.
The integration test not only tests that the watch only wallet bug is fixed but it also tests that the bridge node and the csn is able to sync up and handle reorganizations.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage increased (+0.02%) to 53.285%

Files with Coverage Reduction
New Missed Lines
%

peer/peer.go
1
75.29%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
27548

Relevant Lines:
51699

💛  - Coveralls


Multiple router-views in different shells don't work

I'm submitting a bug report

Library Version:
1.0.8

Please tell us about your environment:

Operating System:
Windows 10

Node Version:
6.9.4

NPM Version:
4.1.1

JSPM OR Webpack AND Version
JSPM 0.16.15

Browser:
Chrome 55

Language:
TypeScript 2.1.5

Current behavior:
When having multiple router-view tags inside different shells, switching from one shell to another (e.g. from login shell to main) doesn't work anymore.
Expected/desired behavior:
main.ts
// ...
export function configure(aurelia: Aurelia) {
	// ...
	aurelia.start().then(() => aurelia.setRoot('./login/login'));
}

login/login.html
<template>

Login Shell

	<router-view></router-view>
</template>

login/login.ts
import {autoinject, Aurelia} from 'aurelia-framework';
import {RouterConfiguration, Router} from 'aurelia-router';

@autoinject
export class Login {
	constructor(public aurelia: Aurelia, public router: Router) {
	}

	configureRouter(config: RouterConfiguration, router: Router): void {
		this.router = router;
		config.title = 'Demo';
		config.map([
			{ route: '', moduleId: './login/mail' },
			{ route: 'social', moduleId: './login/social' }
		]);
		config.mapUnknownRoutes('./login/mail');
		config.fallbackRoute('');
	}
}

login/mail.ts
// ...
export class Mail {
	// ...
	login() {
		this.aurelia.setRoot('./app/app');
	}
	// ...
}

app/app.html
<template>

Main Shell

	<button click.delegate="logout()">Logout</button>
	<router-view></router-view>
</template>

app/app.ts
import {autoinject, Aurelia} from 'aurelia-framework';
import {RouterConfiguration, Router} from 'aurelia-router';

@autoinject
export class App {
	constructor(public aurelia: Aurelia, public router: Router) {
	}

	configureRouter(config: RouterConfiguration, router: Router): void {
		this.router = router;
		config.title = 'Demo';
		config.map([
			{ route: [ '', 'app1 ], moduleId: './app/app1', nav: true },
			{ route: 'app2', moduleId: './app/app2', nav: true }
		]);
		config.mapUnknownRoutes('./app/app1');
		config.fallbackRoute('');
	}

	logout() {
		this.aurelia.setRoot('./login/login');
	}
}

I'll try to set up a running gist tomorrow...

What is the expected behavior?

Calling this.aurelia.setRoot('./app/app'); from login/mail.ts doesn't work. If I remove all router stuff from login/* (router config, router-view etc.) everything is working as expected.
I've also tried to use a dedicated viewPort for the login router-view which didn't work either.
Is this supposed to work and I'm doing something wrong, is it not suppossed to work or is it a bug?

What is the motivation / use case for changing the behavior?

Thanks to this thread I found out, that calling
this.router.reset();
this.router.deactivate();

before this.aurelia.setRoot('./app/app'); fixes the issue.


Add usage guide for Campaign Tracking (https://github.com/idehub/react-native-google-analytics-bridge/pull/124)

Finding some difficulty in understanding on how to track campaign from URL using trackCampaignFromUrl .
Can someone update README with how to use this new method and probably add some examples?
Thanks.

Hi @surendharreddy! This function has been removed because the campaign url now is set in the HitPayload (the utmCampaignUrl property).
This means you can send the campaign url with something like:
const payload = { utmCampaignUrl: "your_url" }
tracker.trackEvent("CampaignEvent", "Click", null, payload);
// or via the other tracking-functions, like trackScreenView:
tracker.trackScreenView("Home", payload);

As for your point about README; maybe you could make a wiki-article instead: https://github.com/idehub/react-native-google-analytics-bridge/wiki about tracking campaigns?
I feel like the README is getting bloated, so would like to move more to wiki.

Thanks, @cbrevik for the clarification. Now, for a campaign tracking, I will use trackEvent with utmCampaignUrl in the payload.
And I'll see how I can help create a wiki-article to help developers understand the usage.


replace the thread-id hack with thread-id crate

Turns out there is a crate for getting the id of the current thread:
https://crates.io/crates/thread-id
We currently use a kind of nasty hack instead, where we take the address of a thread-local variable. We should replace that with thread-id.
I'm marking this as Help Wanted since it seems like a good starter issue.

Well... maybe.  As that hack notes, it really doesn't care about the actual value, just that it's unique per thread.  I fear that a call to get an OS thread identifier might hurt performance.  I guess that depends on how fast TLS is in comparision, but I also hope that Rust will someday use static TLS, which makes that something like just a register and offset.
Alternatively, our own ThreadPool::current_thread_index() might also suffice, although we'd also need a way to get the current thread pool, and use a default like usize::MAX if outside any pool.

Well... maybe. As that hack notes, it really doesn't care about the actual value, just that it's unique per thread. I fear that a call to get an OS thread identifier might hurt performance. I guess that depends on how fast TLS is in comparision, but I also hope that Rust will someday use static TLS, which makes that something like just a register and offset.

Rust already does use static TLS, at least on linux. I also believe that this is how pthread_self() works, but I agree it's worth benchmarking.

When I say static TLS, I'm referring to -ftls-model=initial-exec.  You can see this in readelf -d that the flags will include STATIC_TLS.  I've never seen this on a Rust executable, but even with GCC it's only the default for non-PIC compilation.  (The space for static TLS could get exhausted by dynamic library loads.)  Dynamic TLS is still native ELF, but IIRC it requires libc calls to get the thread area every time.
In glibc, pthread_self() returns the arch-specific THREAD_SELF, which on x86_64 is just an fs offset, much like static TLS.  Compared to dynamic TLS which must call glibc's __tls_get_addr()... hmm, ok pthread_self() might be better for us after all.
Anyway, what I vaguely recall now is that the splitter TLS stuff barely registered at all on perf profiles, even in our various microbenchmarks, so we probably don't need to worry too much.

Oh, the other dissatisfying part of thread_local! is that it's so dynamic with lazy init.  If we could use a direct #[thread_local] in this thief_id(), then I'd expect it to get much tighter code.
I guess that's another point in favor of thread-id.  So yeah, if someone wants to try this, please don't be turned off by my hesitation -- let's make an actual comparison!

@cuviper ok you've exceeded my knowledge of TLS internals. That said, I think that thread_local! will use #[thread_local] under the hood. But I'm not really sure. @alexcrichton would know more.

Ah looks like @cuviper knows all about the impl of thread_local!, I believe everything he's mentioned is correct. The asm confirms that calls go through __tls_get_addr on Linux.
That being said yeah I've never seen this in a profile. I'd love to have a mode of thread_local! that accepts a constant initializer though to avoid the lazy init!

Hi guys; I'm just taking a poke around at some libz blitz tickets, and I came across this one. Forgive me if I'm asking an ignorant question, but is there a reason not to use std::thread::ThreadId? The thread-id crate mentions that the only reason it exists is because something didn't exist in the stdlib before, but now there is.
In any case, it was such a simple change that I went ahead and made a branch for each: one with std::thread::ThreadId, and the other with the thread-id crate.

Sorry, we should have mentioned it here -- I think we'll use #354 and not need a thread id at all.
Anyway, the reason not to use std::thread::ThreadId was that it wasn't stable at the time -- only as of Rust 1.19.  And I'm generally very reluctant to raise the minimum Rust requirement.

Oh, I see; that makes sense. Thanks for letting me know :)

#354 was merged.

Forgive me if I'm asking an ignorant question, but is there a reason not to use std::thread::ThreadId?

Just an FYI for anyone reading this, std::thread::ThreadId() is also much slower than the alternatives proposed here and allocates with calls to Arc.


sg721-updatable v3 migration update

Created a new PR to avoid conflicts: https://github.com/public-awesome/launchpad/pull/597


selected configuration(fps,resolution) is not supported

|---------------------------------|------------------------------------------- |
| Camera Model                       |  D400  |
| Firmware Version                   | <IP_ADDRESS> |
| Operating System & Version |   Win 10 |
| Platform                                 | PC |
| Language                            |  python |
While I change resolution from 640480 to 1280720 and FPS from 15 to 30, RGB Camera can not be started. But I started RGB Camera in 640*512 resolution and 30 FPS before. Where is the problem?

@123liluky, as @HippoEug suggested the camera seem to be detected as a USB2.1 device.
To see the full list of supported resolutions and FPS values, you can run rs-enumerate-devices.

Thank you. I have changed to USB3 and the problem is solved.


NetCore3.1发现不了服务

用 https://github.com/nacos-group/nacos-sdk-csharp/tree/master/samples 的APP1和APP2跑起来，能够注册服务到nacos，但是发现不了服务，如下代码：

_serverManager.GetServerAsync("App1").GetAwaiter().GetResult();

看了下一下代码没有获取到weight，加上weight就可以获取到服务了，请教下，不改源代码怎么能够发现服务？
                    var list = serviceInstances.Hosts.Select(x => new NacosServer
                    {

                        // it seems that nacos don't return the scheme

                        // so here use http only.

                        Url = $"http://{x.Ip}:{x.Port}",

                        //加上这个就可以发现服务了

                        Weight=x.Weight

                    }).ToList();

@kookpua   谢谢您对这个项目感兴趣！
INacosServerManager 是基于接口的，可以自己实现对应的方法，然后在DI那里做对应的替换就可以了。
出现这个问题是调整了获取可用服务的算法，无权重->带权重，但是没有把权重字段赋值。

Thanks for your interest in this project.
INacosServerManager is based on interface, you can implement it by yourself, the replace it in dependency injection.
The problem is that the algorithm for obtaining available services has been adjusted, from without weight to with weight, and the weight field is not assigned.

@kookpua 谢谢您对这个项目感兴趣！
INacosServerManager 是基于接口的，可以自己实现对应的方法，然后在DI那里做对应的替换就可以了。
出现这个问题是调整了获取可用服务的算法，无权重->带权重，但是没有把权重字段赋值。
如果您有时间的话，可以提个PR过来修复这个问题。 😄
Thanks for your interest in this project.
INacosServerManager is based on interface, you can implement it by yourself, the replace it in dependency injection.
The problem is that the algorithm for obtaining available services has been adjusted, from without weight to with weight, and the weight field is not assigned.
If you have time, you can send a PR to fix this problem. 😄

Thank you for your explanation, I will give it a try, I will have time next week


Radar chart x-axis labels get cut off  on small screens(mobile)

Description

Steps to Reproduce

Expected Behavior
Actual Behavior
Screenshots

Reproduction Link

Did not follow bug template instructions


Bytes paths

For consistency in how paths are passed around with the backends.
This would require a little knock-on code in distributed.hdfs and gcsfs.dask_link .

Is it possible to do this in such a way that slightly older versions of dask.distributed will continue to work, although without the improved feature set?

(Should have gone in the main description)
Previous distributed.hdfs did not work as intended https://github.com/dask/dask/pull/2171 , which is where this came from

Understood.  I'm not asking for that bug to be retroactively fixed in dask.distributed, I'm asking that we ensure that these changes do not cause dask.distributed tests to break without changes of their own.  We should subsequently make those changes, I'm just trying to make sure that users are allowed some flexibility so that the libraries don't have to be updated in precise lock-step.

Yes, I can confirm that the tests in distributed/tests/test_hdfs pass with these changes in place.

I have tested this using:
import dask.dataframe as dd
df = dd.read_parquet('s3://bucket/dask_data/*')

and I have the following errors:
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-8-c743efed9868> in <module>()
----> 1 df = dd.read_parquet('s3://mr-meeseeks/testing/dask_data/*')

/home/ec2-user/coding/dask/dask/dataframe/io/parquet.py in read_parquet(path, columns, filters, categories, index, storage_options)
     75
     76     if len(paths) > 1:
---> 77         pf = fastparquet.ParquetFile(paths, open_with=myopen, sep=myopen.fs.sep)
     78     else:
     79         try:

/opt/anaconda/anaconda<IP_ADDRESS>/lib/python3.6/site-packages/fastparquet/api.py in __init__(self, fn, verify, open_with, sep)
     43                  sep=os.sep):
     44         try:
---> 45             fn2 = sep.join([fn, '_metadata'])
     46             self.fn = fn2
     47             with open_with(fn2, 'rb') as f:

TypeError: sequence item 0: expected str instance, list found

@DigitalPig , are you using the latest fastparquet master?

Gahh, fails on windows paths in LocalFileSystem

@mrocklin , this is a timing sensitive test?
dask/tests/test_threaded.py::test_interrupt FAILED

Yes, it has been breaking recently.  I think that @jcrist is aware of it but he's out this week.

https://github.com/dask/dask/issues/2192

Rerunning made it pass

+1 from me