[Python] Arrow to Python list (to_pylist) conversion is slow

It seems that we are 20x slower than Numpy for converting the exact same data to a Python list.
With integers:

>>> arr = np.arange(0,1000, dtype=np.int64)
>>> %timeit arr.tolist()
8.24 µs ± 3.46 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
>>> parr = pa.array(arr)
>>> %timeit parr.to_pylist()
218 µs ± 2.39 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

With floats:

>>> arr = np.arange(0,1000, dtype=np.float64)
>>> %timeit arr.tolist()
10.2 µs ± 25.5 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
>>> parr = pa.array(arr)
>>> %timeit parr.to_pylist()
199 µs ± 1.04 µs per loop (mean ± std. dev. of 7 runs, 10000 loops each)

Reporter: Antoine Pitrou / @pitrou
Related issues:

[Python] Efficient "row accessor" for a pyarrow RecordBatch / Table (is related to)

Note: This issue was originally created as ARROW-12976. Please see the migration documentation for further details.

Just started using PyArrow. Are there any updates/recommended practices on this issue, this would significantly speed up "iterating through rows" for me.


duplicate warnings on initial setup

Category: Bug or enhancement
Bug
Severity: Low , Medium, High, Critical
Medium
Expected behaviour (In case of bug)
If there is no settings path and no software package available, I will be asked after another to serve the download paths or simply continue to take some default from the internet.
Actual/current behaviour (In case of bug)
Currently I have multiple *** ATTENTION *** warnings continuing progressing something, that i think I made something wrog. Finally, the settings URL is asked by the system. Why is there so much attention needed if it is the default behavior. It seems like warnings.
In general from a user perspective, it is quite hard to differentiate the log from the system and the actual text necessary to be read by the user as of a question to be answered. It would be nice if logs could be somehow differentiated for example by a leading > or anything like this.
Steps to reproduce (In case of bug)
Download beta.11 and run the setup
Description of issue / expected enhacement /Comments
Your environment - windows/Linux, Devonfw version , component
windows7

Just as another example, there comes a text To be fully functional please rerun 'devon' command to update your PATH properly. i the middle of the dowloading and setting up mvn. I would bet, that nobody is reading it as there is so much text.
couldn't it be even more sutable to make 90% of the logs just visible on a --verbose flag? I am just interested in the progress and on the step being progressed at the moment. Nothing more ;)

Use -q option for quiet output.
Everything else you are complaining here is prio minus infinity for me at the moment.
I also disagree that a an extra error log output is a bug. A bug means that something is not working.
Thanks for the feedback. I am just frank with my straight answer to clarify the expectation how fast these issues will be fixed. This project has already eaten tripple of my resources planned for it and so far I still have no other developers working on this.
Feel free to provide pull requests.

Ok, totally agree about the priority of this.
Anyhow, for the one who is implementing this later. It would be better to always put less into the log. Just what is necessary to be read by the user by default. If he wants to get more, you can simply provide a --debug or --verbose flag. The other way around with the quite flag does not make sense to me and would disturb 90% of the users.

I think there is still a trade-off to make.
Users will like the status output from curl when downloading tools as otherways they might think the installer crashed or hangs. However, already such output is already quite verbose.
Further bash is often creating very poor error messages with limited contect info.
You also need to be aware that I have to be able to give support for users running into issues.
If I only get mvn: command not found or ln: failed I will be puzzled but unable to assist.
That is why I created this doRunCommand stuff that first prints out the command that is going to be executed with all args and then reports exit codes, etc.
Please be aware there is nothing such as a Java Exception in bash...

What we could do is actually write a real logfile and put the major details there and have only minimal output on stdout. But sill I would suggest to output download progress to end-users.

Yes totally agree to your last statement. This should be the best of both worlds.
Interestingly, during a usability study of the cobigen cli ohne of the most often mentioned requirement was 'it should be colorful and Easy to read' ;)

Was autoclosed by github from commit comment.
However, actual issue is indeed fixed. File new issue to request advanced logging features.


Kernel modules in the docker images.

I am trying to use ghcr.io/seagate/cortx-build:centos-7.8.2003.
$(uname -r) gives "5.10.25-linuxkit", but in /lib/modules there are only 3.10.0-1160.25.1.el7.x86_64 and 3.10.0-1160.el7.x86_64.
As a result, build of motr (and build of any other software relying on kernel modules, I assume), fails.
Is there a workaround?

Hi @nikitadanilov I think this is a workaround for your issue: #1130

@hessio and @nikitadanilov , what guide was this following?

I am thinking @nikitadanilov was trying to use the community build guide: https://github.com/Seagate/cortx/tree/main/doc/community-build and if you go to this guide step 4 you call docker run to use this docker container https://github.com/Seagate/cortx/blob/main/doc/community-build/Generate-Cortx-Build-Stack.md

I am doing a manual build within a docker on macos.


pdfmm: fix build on (at least) macOS

Description of changes
The package isn't marked linux-only, but pulling locale from glibc effectively limited it to linux. Using the generalized locale attr gets it building on macOS.
Also:

While looking into this, I noticed that the script only uses xmessage if zenity isn't present, so I think we can drop that dependency.
Not super familiar with what the package should run on, but I went ahead and set the platform meta based on what I've personally verified.

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[x] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review run on x86_64-darwin 1

1 package built:

pdfmm

Result of nixpkgs-review run on x86_64-linux 1

1 package built:

pdfmm

Add a :+1: reaction to pull requests you find important.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/3785


Cross-compile for Windows

Mainly as a flex but also because apparently the devices (LGX and LGX2) aren't supported on Windows 11? (Not verified)
MingW + CMake guide
libusb windows libraries
SDL2 libraries
SDL2 linker options:
lmingw32 -lSDL2main -lSDL2 -mwindows -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lversion -luuid -static-libgcc -lsetupapi

Guard around Linux specific code with #ifdef __MINGW32__/#endif
Use following directives to make CMake statically link by default:
set(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
set(BUILD_SHARED_LIBS OFF)
set(CMAKE_EXE_LINKER_FLAGS "-static")

Prevent stack overflow exceptions on startup by modifying FrameBuilder to not attempt to statically allocate 1920x1080x4 bytes for the video frame buffer, use dynamic allocation instead (boo).
Document the process of using something like Zadig to create a 'driver' on Windows that can be used to claim the device so that libusb can be used to send and receive data from the device.

I've only gone and done it! Using Conan as a way of handling external libs (libusb and SDL2)


Feature/2024/09

Codecov Report
Attention: Patch coverage is 97.95918% with 2 lines in your changes missing coverage. Please review.

Project coverage is 79.38%. Comparing base (543ea5c) to head (680a397).

Files with missing lines
Patch %
Lines

2024/day09/src/common.rs
97.82%
2 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #35      +/-   ##
==========================================
+ Coverage   79.09%   79.38%   +0.29%
==========================================
  Files         138      140       +2
  Lines        6261     6359      +98
==========================================
+ Hits         4952     5048      +96
- Misses       1309     1311       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Remove core-requirements.txt from installed package

https://github.com/alteryx/evalml/pull/1293 updated and fixed our CLI tool by adding core-requirements.txt to our package data so it is readable. However, users may be confused as to why this is being installed. We should look into how to achieve the same functionality without adding core-requirements.txt to our installed package.

Yep, for context for whoever picks this up, we decided it was worth merging the fix, including core-requirements.txt in our packaging in order to satisfy codecov and to fix the env CLI tool before the next release. This issue tracks paying down that tech debt :)


fiat support for bc_start and bc_payment_component

@Alan-AC7 I will close this now - could you give it another try using Bitcoin Connect v3 and the new bc-balance component?
Referencing the original issue: https://github.com/getAlby/bitcoin-connect/issues/105

@Alan-AC7 I will close this now - could you give it another try using Bitcoin Connect v3 and the new bc-balance component?
Referencing the original issue: https://github.com/getAlby/bitcoin-connect/issues/105


Basic SBOM generation in apks

This PR wires SBOM generation into the melange build process.
It creates basic SBOMs for all apks built by melange. The SBOMs themselves only inventory the apk contents and write them to the SBOM. In the next iterations we will start adding features to the SBOMs like language and build deps, vcs references, smarter licensing, etc.
Closes https://github.com/chainguard-dev/melange/issues/141

The reproducible builds test is now failing as the .apk is packaging the SBOM.  Fixing.

Looks good once the e2e tests are fixed.

I had missed a few bits where the SBOM creation was not deterministic. Fixed now.


This package destroys basic Meteor components

As soon as I installed this, even Spacebars wasn't recognized. Templates weren't recognized.
I don't know how this Atmosphere package was compiled, but it wasn't done correctly. I packaged a small JS library for my own use and it didn't hose my entire application.
This readout is from the web console in Chrome:
Uncaught TypeError: Cannot set property 'guid' of undefined
global-imports.js:6 Uncaught TypeError: Cannot read property 'Materialize' of undefined
template.about.js:2 Uncaught ReferenceError: Template is not defined
template.contact.js:2 Uncaught ReferenceError: Template is not defined
template.home.js:2 Uncaught ReferenceError: Template is not defined
template.master-layout.js:2 Uncaught ReferenceError: Template is not defined
template.nav.js:2 Uncaught ReferenceError: Template is not defined
meteor.js:888 Exception in callback of async function: ReferenceError: Deps is not defined
    at Layout.beginRendering (http://localhost:3000/packages/iron_layout.js?4e65c46acdaf0ce6a8b1a479d7b9d0b5c0902062:288:3)
    at Controller.beginRendering (http://localhost:3000/packages/iron_controller.js?5a7eedaafda7001b9d5cb52322a419bbb758968c:290:23)
    at RouteController._runRoute (http://localhost:3000/packages/iron_router.js?7b16fe70bccff9182aca02afb2ccd7708ac57c64:470:8)
    at Function.Route.dispatch (http://localhost:3000/packages/iron_router.js?7b16fe70bccff9182aca02afb2ccd7708ac57c64:854:18)
    at route (http://localhost:3000/packages/iron_router.js?7b16fe70bccff9182aca02afb2ccd7708ac57c64:711:11)
    at boundNext (http://localhost:3000/packages/iron_middleware-stack.js?56e0c02a758f48c0a704ca978a8fb6d7bd9ebbab:424:31)
    at http://localhost:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:983:22
    at boundNext (http://localhost:3000/packages/iron_middleware-stack.js?56e0c02a758f48c0a704ca978a8fb6d7bd9ebbab:371:14)
    at http://localhost:3000/packages/meteor.js?43b7958c1598803e94014f27f5f622b0bddc0aaf:983:22
    at dispatch (http://localhost:3000/packages/iron_middleware-stack.js?56e0c02a758f48c0a704ca978a8fb6d7bd9ebbab:448:3)
iron_layout.js:95 Uncaught ReferenceError: Spacebars is not defined

Having the same problem

When Spacebars isn't recognized, something must be terribly wrong.
Some issue here, btw.

Note that $meteor remove materialize:materialize will remove the package successfully, apparently with no detrimental effects (none that I've found so far).

I've found this package, but it doesn't appear to have an Atmosphere package yet.
https://github.com/npvn/meteor-material-design
Their Material examples are superb.
I may try to package this up for Atmosphere later. I've also left a note on the owner's Github issues that there's no Atmosphere instructions the package is not found at Atmospherejs.com.

This is the same issue as https://github.com/Dogfalo/materialize/issues/2037.
You can still use all the features of this package, just specify to use the last version, 0.97.0.  Quoting from that thread:

...edit your .meteor/packages file and change materialize:materialize to<EMAIL_ADDRESS>for the time being. Then a meteor update will ensure your version stays at 0.97.0 until the latest one gets fixed.

meteor remove materialize:materialize
meteor add<EMAIL_ADDRESS>

meteor remove materialize:materialize
meteor add<EMAIL_ADDRESS>And now all is ok.

yep go for with the previous version has @heshaohu  mentioned:
meteor add<EMAIL_ADDRESS>

Same issue. Rolling back to 0.97.0

Worked with me when back to 0.97.0

Same issue.

+1

Just for the record, are you all on the latest version of Meteor @.4?

Using latest Meteor version, Materialize 0.97.1 breaks everything, 0.97.0 works fine

I made a fix for that, guys
Waiting approve for merging

Thanks for the report and looking into the issue. For now I'll be closing this one to consolidate this specific issue into https://github.com/Dogfalo/materialize/issues/2037.

@heshaohu +1

+1

+1 why its not fixed yet ?

Rolled back to 0.97.0 , thanks @Hamatek and @heshaohu


removeRenderer is not working, due to that memory issues are coming

#201 # Description
I am trying to remove old video render & try to add new one, but it is keeping adding & due to that memory issues are coming & app is crashing.
Steps to Reproduce

Adding a remote video by using addRenderer
self.localVideoTrack!.addRenderer(remoteView)
self.remoteView!.addSubview(remoteView)

Trying to remove that remote video by using removeRenderer (check the method below)

Code
Init : -
    @IBOutlet var remoteView: VideoView?

Method : -
func addRemoteVideo(videoTrack: RemoteVideoTrack, name: String) {

        self.lblDominan.text = name

        if (self.remoteView != nil) {

            videoTrack.removeRenderer(self.remoteView!)

            if let remoteView = VideoView.init(frame: CGRect(x: 0, y: 0, width: CGFloat(self.remoteView!.frame.size.width), height: CGFloat(self.remoteView!.frame.size.height)), delegate:self) {

                videoTrack.addRenderer(remoteView)

                self.remoteView!.addSubview(remoteView)

                remoteView.contentMode = .scaleAspectFill
                remoteView.shouldMirror = true
            }
        }
    }

Expected Behavior
It should remove the old rendered video & add new one
Actual Behavior
It is keeping adding new video and increase count by 1 every time, I have check this by printing count
Reproduces How Often
Often
Logs
Debug level logs are helpful when investigating issues. To enable debug level logging, add the following code to your application:
TwilioVideoSDK.setLogLevel(.debug)

// Log output when the issue occurs

Versions
All relevant version information for the issue.
Video iOS SDK
CocoaPods
Xcode
11.5
iOS Version
11 and above
iOS Device
iPhone 8, Simulator

@gurupatel,
It appears that you have a TVIVideoView set up in Interface builder that is linked as an @IBOutlet to the remoteView instance variable.
Then in your addRemoteVideo(videoTrack:, name:) method you first check to see that remoteView is not nil and then attempt to call removeRenderer() on the newly passed in video track. Then you are creating yet another TVIVideoView, assigning it as the renderer for the supplied video track and then adding it as a subview to the @IBOutlet remoteView instance variable.
You never appear to remove the subviews that you add to the @IBOutlet remoteView instance variable. The resource exhaustion crash you are likely seeing is due to the fact that the @IBOutlet remoteView instance variable of your application lives a very long time and as you add more and more tracks over time, the instance variable is still holding all of those subviews.
There are a few things I would consider:

I don't think you want to keep adding subviews to the remoteView instance variable. If you want a container to add and remove TVIVideoViews from, I would suggest just make the containing view a regular UIView.
You are never actually adding self.remoteView as a renderer to any video track. You are creating a TVIVideoView, adding that object as the renderer to the video track and then adding that view as a subview of self.remoteView. The subsequent calls to videoTrack.removeRenderer(self.remoteView!) are never going to do anything at this point for two possible reasons:
a. self.remoteView is not the view being added as the renderer to a video track... The subview is the renderer. When you call removeRenderer it is going to look for the view you pass in, and here, it is the parent, and not the actual rendering view
b. You are calling removeRenderer on the newly supplied video track, not the one that was previously being rendered.
It is not necessary to create new TVIVideoViews if you want to reuse the same view. Create the TVIVideoView as you are in interface builder and have it configured as you like. When you are subscribed to a remote video track, call addRenderer on the supplied track and pass in the instance of TVIVideoView. When you unsubscribe from that track, call removeRenderer on the supplied track and pass in the instance of TVIVideoView. When a view is removed as a renderer for a track internally we invalidate and reset the TVIVideoView which will cause it to display a black frame instead of that last rendered video frame.

Let me know if you have any further questions,
Ryan

@gurupatel,
Haven't heard back from you in a while. Did the answer above help you?
Ryan

@gurupatel,
Closing this issue, but feel free to reopen it if you are still experiencing the issue.
Ryan

@gurupatel,
Closing this issue, but feel free to reopen it if you are still experiencing the issue.
Ryan


Mapping rules implementation

This introduces optional features useful for proxies:

rest-mappings
rest-mappings-serde

Compatibility: while these do not enforce the "std" feature, they
currently end up requiring it effectively because of the regular
expression engine requirements.
This implements the matching of HTTP (REST) mapping rules via inspection
of the HTTP method, path and query string.
The current implementation is just an approximation of what Apicast is
currently doing. There are a few reasons for this, not the least that
the documentation underspecifies this functionality and that Apicast
itself just passes down unchecked contents to its PCRE-based regular
expression engine.
In particular, this specification allows users to specify:

Method: the HTTP verb literal string or the string "any"
(case-insensitive).
Pattern: the path and the query string pattern to match against the
actual path and query string of requests.

Methods must match the precise HTTP verb string, case-insensitive, or
use the special method "any", which matches all methods. Note that when
you set up a rule, you can use any other string as well, allowing for
new verbs.
Patterns are a bit of a mess, though. The general rule is that you can
use placeholders for values in paths matching a superset of the
alphanumeric characters, and use the same placeholders in query string
parameter values (not keys) that match just word characters and
underscore and dash. You do so by indicating them inside curly braces
like "/path/{id}?key={val}" - at least one character is required in
between the braces, though, and the matches also require at least one
character.
In the case of the path, streams of repeated forward slashes will be
converted to a single slash, and the $ dollar sign at the end of the
path part of the pattern is guaranteed to mean an exact match (ie.
"pear$" will match "pear" but not "pears"). Whatever your pattern it
will always match at the beginning of your path, so "/hello" will match
"/hello/world" but it won't match "/world/hello".
In the case of the query string, parameter keys and values will match
any order in which they appear, so "/path$?a=1&b={_}" will match
"/path?a=1&b=2" and it will also match "/path?b=3&a=1". Specified
patterns are requirements, so the presence of other unspecified
parameters does not make a difference.
However while with path patterns there's some sense into implicitly
assuming that the literal pattern should be matching, with query string
parameter values there is no such information, and in fact Apicast seems
to only look for whether a pattern exists or not to consider any value a
match.
Just like this point above, many things are not well defined or
questionable:

What if the $ sign at the end of a pattern is preceded by a ?
What if the $ sign appears elsewhere in the path?
What if regular expression special characters are used outside the
curly braces placeholders, like [ or (?
Do query string patterns also match from the beginning? Do they also
support using $ at the end? At the end of the parameter name or value?
Do both names and values have implicit matches to their respective
beginnings? Do placeholders in values match assuming the whole value
is variable or can placeholders work like path patterns with some
literal parts, ie. /numbers-ending-with-1$?n={num}1
Do placeholders always need at least one character? (ie. see previous
point where n=1 would not match)
Can you use placeholders in query string parameter keys?

There are quite a lot of places where this underspecification can bite a
user and the implementor.
The documentation also states that you can use placeholders recursively,
which both Apicast and this implementation don't support (at least not
correctly), but you'd be hardpressed to find value in that. The
documenttion also states other quite suspect things like Apicast looking
at POST/DELETE/etc bodies to match query string parameters (which this
implementation completely does not even pretend to do).
So because there is so much not specified, underspecified or just plain
wrong in the documentation, there are quite a few issues with the
current mapping rules implementations, including this one.
Apicast just looks for placeholders in paths and in query string
parameter values. With path patterns it uses a specific regular
expression to capture path segments (or parts), and with query string
parameter values it just looks at whether the value has a placeholder,
in which case everything matches directly, or if not it compares the
value literally for a match.
The thing is that whenever the pattern has been modified to contain a
regular expression, Apicast will then submit the whole string down to
its PCRE engine for evaluation. This way they support the above
definition, but they do so at the expense of leaving the interpretation
of all characters outside the placeholders to the regex engine. So a $
character outside a placeholder would only match the end of the string,
but if it is escaped with a backslash then it just means a literal $
sign. So because Apicast just passes down everything unescaped, lots of
additional behaviour is now trapped behind the interpretation of the
exact engine used.
So our implementation behaves the same by replacing placeholders and
submitting everything else down to our engine (which should be mostly
PCRE-compatible). Doing so this way feels wrong and is not specified,
that is, no one told the user that /path[0-9]/id would match
path5/id, for example, but instead they'd think it matches the literal
path including the brackets.
In the case of query string parameters this implementation also allows
placeholders in parameter keys but it escapes absolutely everything not
within the placeholders, which breaks the case of ending these patterns
with a $ character. On the other hand, using special characters outside
the placeholders won't have special meaning. It also allows for
placeholders in value positions, but they are fully evaluated to match
so that you can match on values that have literal parts, ie. n=9{_}9
for values that start with a 9 and have at least another one (but note
it does not mean it will end with a 9 necessarily).
Of course, the above is not coherent with how path patterns are being
matched. But there is little coherence overall, so let's change it
whenever the dust settles around this topic.
All in all, this needs discussion, agreement and docs fixing.

Codecov Report

Merging #78 (4e96dd4) into master (845ab63) will increase coverage by 6.92%.
The diff coverage is 90.54%.

@@            Coverage Diff             @@
##           master      #78      +/-   ##
==========================================
+ Coverage   65.05%   71.98%   +6.92%
==========================================
  Files          22       27       +5
  Lines        1219     1674     +455
==========================================
+ Hits          793     1205     +412
- Misses        426      469      +43

Impacted Files
Coverage Δ

src/http.rs
0.00% <ø> (ø)

src/http/mapping_rule/serde_impl.rs
70.31% <70.31%> (ø)

src/http/mapping_rule/method.rs
90.52% <90.52%> (ø)

src/http/mapping_rule.rs
91.50% <91.50%> (ø)

src/http/mapping_rule/escaping.rs
98.42% <98.42%> (ø)

src/util/string.rs
100.00% <100.00%> (ø)

... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 845ab63...4e96dd4. Read the comment docs.

We are going to merge this first implementation of mapping rules as a first basic step to release 0.8. It is known to be incomplete in some respects and I have been cooking a few fixes and enhancements, but it is known to be featured enough to support the feature as is now, and those enhancements shall wait until a full comparison with Apicast and the work at #79 is complete.

@davidor ping for initial review so we have this initial implementation in pending more changes after testing with Apicast.

I see no problem in merging this, just mention in the changelog that because of what you explained here and the related issue (https://github.com/3scale-rs/threescalers/issues/79) this is an area where users can expect breaking changes.

bors r=@davidor


smoke timer calculation crashes on start due to not understanding datetime

The timer calculation currently only uses time, not a full date/time.

Look at using the functionality in Toybox::Time (Duration, Moment, etc) for date/time calculations. We should store the full UTC date time to app settings/properties and use the full UTC date/time when calculating how long it's been since the app went to sleep. This way we always work correctly when daylight savings time happens and it won't matter how long the app has been sleeping we'll have the full date(s) to work with.

actually, this crash was due to not cleaning and rebuilding the project after pulling changes. however, I do think we should probably use full date/time and the built-in time stuff. Imagine smoking overnight, once the date changes the times will still be messed up.

we can store the value property of "now" when saving (UTC seconds since unix epoch) and load that back up on start. we can calculate the difference when waking up by calculating the duration between now and then:

Yes, the overnight behavior is something I had not considered. Good point. Will work on this today.

The API objects for date/time should make it easier. We just need to make sure we are using UTC so that when daylight savings time changes, or the user changes time zones (not likely but if you're in el paso it could happen) the time calculation stays correct.

I pushed the time calculation using the Time objects. Basically I'm persisting a Moment on app exit. On the app start I recover it, create the current time as a Moment. Then do a diff of the two in UNIX time. The diff is the sleep duration.

We can probably comment this out for the upcoming release since we're not using it.

go ahead and comment it out for now - I just branched off development for low-n-slow which will be for the smoking stuff. We'll continue testing this week and merging any bug fixes from dev into it and release dev at the end of the week if it looks good?

Let's do it


microshift: Add logic to create bundle of upcoming release

It uses MICROSHIFT_PRERELEASE as environment variable to create
bundle for upcoming release by getting the microshift-* rpms from
mirror.openshift.com

/cherry-pick release-4.14

/lgtm
/aprrove

/lgtm
/approve


TypeError: SerialPort is not a function

Operating System and Hardware:Windows 7 & intel i7-4700MQ HM86 Chipset
NodeJS Version: 5.2
Serialport version:3.1.2
Python Version (if you're having trouble building serialport):
(Run node -v && npm -v && python --version to get the version numbers.)
Expected behavior
this two lines of code does not work:
var SerialPort = require('serialport');
var port = new SerialPort('COM16');
I got :
var port = new SerialPort('COM16');
^
TypeError: SerialPort is not a function
at Object. (C:\Users\bunny\Desktop\AcquireData\serialport.js:20:1
2)
at Module._compile (module.js:399:26)
at Object.Module._extensions..js (module.js:406:10)
at Module.load (module.js:345:32)
at Function.Module._load (module.js:302:12)
at Function.Module.runMain (module.js:431:10)
at startup (node.js:141:18)
at node.js:977:3
Buuuuuuut, I have no problem running the function:
SerialPort.list(function (err, ports) {
ports.forEach(function(port) {
console.log(port.comName);
console.log(port.pnpId);
console.log(port.manufacturer);
});
});
it successfully list my serial port,somebody help!
Actual behavior
Steps and/or code to reproduce the issue

It works ,thanks buddy！

Hi
I am having the same exact issue. can you tell me how did you solve this.
the list function works but when i said new SerialPort it gives me
TypeError: SerialPort is not a function
please help
Thanks

Thank you. not sure how i missed it. works perfect.


[googleGroups]: update env variables and credentials files

Please ping me when the final version is ready for review.

@lukaszgryglicki the final version is ready for review


Optimize size of BoundingBox

Builds on (#1045).
This makes BoundingBoxes smallest for each primitive.

Thank you so much for the pull request @Project-PLATEAU! I noticed this is your first pull request and I wanted to say welcome to the Cesium community!
The Pull Request Guidelines is a handy reference for making sure your PR gets accepted quickly, so make sure to skim that.

:heavy_check_mark: Signed CLA found.

Reviewers, don't forget to make sure that:

[ ] Cesium for Unreal Samples works.

Thanks for the PR @Project-PLATEAU!
I think there are two mostly unrelated changes in this PR. The first changes how an axis-aligned bounding box is computed from a primitive. Previously, it would trust the min/max values on the position accessor, if available, or compute them from all the positions if not.
Now it never trusts the accessor's min/max, and computes them from positions referenced by the index accessor.
In the common case where a tile has only one primitive, these are equivalent, except that the old implementation is much more efficient because it doesn't need to loop over the index array and use it to random access into the position array. They're also equivalent where the tile has multiple primitives but those primitives each have their own vertices. The only time the new implementation provides a better result is when the primitives have different indices but the same vertices. Oh and also the vertices used by the two sets of indices also need to be in different places within the model, otherwise the bounding volumes won't be very different, anyway.
In my experience, this is really not common. In fact, if you have this scenario, it will be quite inefficient in Cesium for Unreal in general because Cesium for Unreal will create a separate copy of the vertices for each primitive that uses them. I'm not sure whether Unreal's StaticMeshComponent gives us the tools to easily address this.
The other change in this PR is to avoid setting the primitive's boundingVolume property, which has the effect of disabling the bounding volume improvement we implemented in #823 and #841. Again, I don't think this a worthwhile tradeoff, as those PRs made a significant improvement in our bounding volumes, especially near the georeference origin. We don't want to lose those improvements without a very good reason.
So in all, I'm not completely sold on the value of this change, because it seems to make common cases less efficient while making an uncommon one faster, which is probably not a good tradeoff. But I'm interested in hearing more about how you've ended up with this seemingly-uncommon scenario and what improvements you've seen from the change in this PR.
But I think it's worth noting that if you really do have this scenario, it may be very worthwhile to restructure your tileset to avoid it. The 3D Tiles selection algorithm is driven by the bounding volumes in tileset.json. If your bounding volumes are not representative of your content, because there are multiple different "parts" in different locations all lumped into the same tile, then the selection algorithm is going to do a lot more loading than is necessary. Tile loading is usually much more expensive than rendering, so optimizing the rendering-time bounding volumes will yield only a small improvement. Restructuring the tileset so that tiles have good spatial locality and a minimal number of draw calls (primitives) will improvement performance significantly, and also avoid the need for the sort of changes in this PR.
Happy to discuss further!

The first change minimizes the bounding box of primitives, even when multiple gltf primitives share one position accessor. However, this change is applied only when primitives share the position accessor, considering other cases as well.
The second change is a modification to reflect the bounding box of each primitive in physics calculations. Since this may be inefficient in use cases that do not require physics calculations, it has modified to make it an option for 3DTilesetActor, so it can be chosen as needed.
This change is required when the CreateNavCollision option added in #1044 is enabled, so it only applies when that option is enabled.
These changes improve physics simulation when moving characters using navigation on the Tileset.
For example, if a building defines primitives for each floor, the physics calculations for character movement can be reduced to only the floor the character is on, rather than the entire building. This is more effective when moving many characters.

Our apologies.
There was a line that was accidentally deleted and I have added a commit to undo it.

Sorry I'm so long in coming back to this, @Project-PLATEAU. I'm still not convinced of why this is needed, though. I understand you have a single tile with a separate primitive for each floor. And it's more efficient if each primitive's bounding volume only covers that floor, rather than the entire building. But since floors are unlikely to share (many) vertices anyway, I think you would find it is much more efficient - and avoids the need for this PR - to have a separate position accessor for each floor. Using a single position buffer with multiple index buffers will be much less efficient, with or without this PR, because each floor primitive will get a copy of all the positions, even if they're not used.
So, can you tell me what I'm missing there, if anything? And if you still think this PR is necessary in spite of that, can you please walk me through it so that I can understand?


feat: batch subcribe

Looks good, I wonder whether we should start calling batchSubscribe on AuthSDK, and ChatSDK in engine setup() calls

It's already in AuthSDK, do you want me to add it in Chat as well?

Must have missed AuthEngine change.

do you want me to add it in Chat as well?

Yes 😄!


noop not working

What system are you running Yazi on?
Windows
What terminal are you running Yazi in?
wezterm
yazi --debug output
Yazi
    Version: 0.4.1 (VERGEN_IDEMPOTENT_OUTPUT 2024-12-13)
    Debug  : false
    Triple : x86_64-pc-windows-msvc (windows-x86_64)
    Rustc  : 1.80.1 (3f5fd8dd 2024-08-06)

Ya
    Version: 0.4.1 (VERGEN_IDEMPOTENT_OUTPUT 2024-12-13)

Emulator
    Brand.from_env      : Some(WezTerm)
    Emulator.detect     : Emulator { kind: Left(WezTerm), light: false, cell_size: None }
    Emulator.detect_full: Ok(Emulator { kind: Right(Unknown { kgp: false, sixel: false }), light: false, cell_size: None })

Adapter
    Adapter.matches: Iip

Desktop
    XDG_SESSION_TYPE           : None
    WAYLAND_DISPLAY            : None
    DISPLAY                    : None
    SWAYSOCK                   : None
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

NVIM
    NVIM          : false
    Neovim version: program not found

Variables
    SHELL           : Some("nu")
    EDITOR          : Some("hx")
    VISUAL          : None
    YAZI_FILE_ONE   : None
    YAZI_CONFIG_HOME: None
    YAZI_ZOXIDE_OPTS: None
    FZF_DEFAULT_OPTS: None

Text Opener
    default     : Some(Opener { run: "%EDITOR% %*", block: true, orphan: false, desc: "%EDITOR%", for_: None, spread: true })
    block-create: Some(Opener { run: "%EDITOR% %*", block: true, orphan: false, desc: "%EDITOR%", for_: None, spread: true })
    block-rename: Some(Opener { run: "%EDITOR% %*", block: true, orphan: false, desc: "%EDITOR%", for_: None, spread: true })

Multiplexers
    TMUX               : 0
    tmux version       : program not found
    tmux build flags   : enable-sixel=Unknown
    ZELLIJ_SESSION_NAME: None
    Zellij version     : program not found

Dependencies
    file          : 5.45
    ueberzugpp    : program not found
    ffmpeg/ffprobe: program not found / program not found
    pdftoppm      : program not found
    magick        : program not found
    fzf           : program not found
    fd/fdfind     : 10.2.0 / program not found
    rg            : program not found
    chafa         : program not found
    zoxide        : program not found
    7z/7zz        : program not found / program not found
    jq            : program not found

Clipboard
    wl-copy/paste: program not found / program not found
    xclip        : program not found
    xsel         : program not found

Describe the bug
This is my config:
[manager]
show_hidden = true

prepend_keymap = [
	{ on = "<A-q>", run = 'quit' },
	{ on = "<C-q>", run = 'close' },

	{ on = "<C-o>", run = "back", desc = "Go back to the previous directory" },
	{ on = "<C-i>", run = "forward", desc = "Go forward to the next directory" },
	{ on = "<C-c>", run = "escape --search", desc = "Cancel the ongoing search" },

	{ on = "q", run = 'noop' },
	{ on = "Q", run = 'noop' },
	{ on = "<C-c>", run = 'noop' },
	{ on = "H", run = "noop" },
	{ on = "L", run = "noop" },
	{ on = "<C-s>", run = "noop" },
]

The noop rebinds are ignored and the default commands are still executed. E.g. pressing q still quits.
However, if I change this to say asdlfhsadfasd, then the keys are unbound.
This seems weird to me, since the docs say this command is specifically created for unbinding keys
Minimal reproducer
See above
Anything else?
No response
Checklist

[X] I tried the latest nightly build, and the issue is still reproducible
[X] I updated the debug information (yazi --debug) input box to the nightly that I tried
[X] I can reproduce it after disabling all custom configs/plugins (mv ~/.config/yazi ~/.config/yazi-backup)

Please try https://github.com/sxyazi/yazi/pull/2064
BTW, your show_hidden = true should be in yazi.toml not keymap.toml


Errors when instancing a sprite that contains a viewport

Godot version: commit 9002b045c (Godot 3.2 beta)
OS/device including version: Linux Mint 19
Issue description:
Instancing a Sprite3D with a ViewportTexture that points to a viewport which descends from it generates many errors and doesn't render correctly.

Minimal reproduction project:
viewport_wierdness.zip

Making it so the viewport doesn't descend from the sprite only prevents some of the errors.

Interestingly, changing the order of the nodes changes the number of errors too.

On further inspection, I attempt to assign the ViewportTexture through GDScript.
The highlighted line doesn't seem to execute; after that, the Sprite3D's texture is still [empty] in the remote inspector.

Found a workaround: setting the texture from code using Viewport::get_texture() seems to work. However, I think that the other way I tried to do it should have worked as well.
Also, doing this on ready prevents it from rendering in the editor.
Seems like changing the viewport path dynamically doesn't update the vp pointer in ViewportTexture.

Still valid in a3a3b02
I re-assigned the viewport path and it reduced error count from 7 to 4. The viewport texture displays correctly despite the error.


Enable Wasmtime's code cache

This makes it so that repeated wizenings of the same Wasm module (e.g. with
different WASI inputs) doesn't require re-compiling the Wasm to native code
every time.
Fixes #9

Bonus points for "wizening" as a verb, by the way :-)

All credit to @tschneidereit ;)


ViT architecture and dynamic resolution

Hello, I was wondering why NaViT or an architecture similar to it was not used as the vision transformer architecture. NaViT natively (hence native resolution) supports multi-resolution training as one of its defining features and a similar architecture was used for OpenAI's Sora to allow for good visual fidelity with differing resolutions. In the Latte paper here section 4.1 it states that the model was trained only on square images/videos and would require resizing to process non-square images/videos.

NaViT's structure without good system acceleration may lead to poor GPU utilization. For now, we focus on the video quality first, and thus delay the support for NaViT.


RAG MVP

Adding a minimum minimum viable RAG feature

Hi Simon, added the commits address your previous comments.
Note the last one is unfinished, hope we can finish it in our meeting.
Unfinished tasks:

available_variables should be added as "source_material" using form_data , but I could not figure out how to do it with form_data.
A message hint should be added to  the UI when files are attach to explain how to add the "context" and "input" variables. (Guess you will do this on your end)
Testing was minimal see screenshot below:

Totally independently:
I don't remember if I reported the bug where there are issues if you attach a file before creating the experiment.
It may not exist anymore.
I had to create an experiment every time I tested, sometimes if I reused old experiments after changing the code there was issues such as getting no answer with  the system got in a bad state and started to throw lots of logs.

@snopoke, just pushed your fixes.
 Use the following pieces of retrieved context to answer the question. If you don't know the answer, just say that you don't know. Use three sentences maximum and keep the answer concise.

Question: {input}

Context: {context}

Answer:

The following questions:

Hello, you can ask me anything you want about last_test.
What is "Policy objective 1" ?
Policy objective 1 is to reduce newborn, child, and adolescent morbidity and mortality due to preventable communicable diseases.
What is the capital of France ?
I don't know.


Add WTI logic to catch HcnCreateNetwork failures

This will help triage issues like #11716

With out knowing why, the issue has my vote for it going forward.


Where is the output answer to the result

Why can't I find the value of the three output indicators of the test, for example, Dice=0.85, where is the output?

I'm not sure what you meant by output indicators, you mean the raw forward output? The processed prediction output? And please stop spamming all other issues.
If you simply want to calculate the test statistics (DICE, PQ, etc) refer to https://github.com/vqdang/hover_net/tree/master/metrics


Graphs to properly represent history logs

steps to reproduce
Track some history entries, in my case I've tracked 3 different named entries. Single day work out. And one named entry, the day before.
expected graph

I would expect the dot to be higher on the axis. The issue might be due to the fact there is no range to establish where to put that dot with just a few entries, I don't know. Somewhere above the middle would make sense to me. Anywhere but at y zero.

the one named entry also got the issue. I would expect a line/curve to form since I tracked entries for that one two days in a row.

actual

Note those entries were imported via CSV, not typed in via Flexify. But they look like totally correct history logs in the history tab with weight , about of reps, date.

Yeah not sure why but there's this bug with the graphs where some days don't register as being on separate days. It happens I think when the time difference between them isn't large enough? I have tried many things and still think about this bug every now and then.

I see a compounding of issues in there.
From what I'm seeing one issue is when the values are all identical. They have nothing to scale and bottom to y = 0 for all points.
With the example above, all weights are the same.
I've reproduced it with a fresh set.
steps to reproduce
Having nothing in the history tab

Create 3 gym set logs, each with about a day or more apart as date.
have all 3 entries all have the same weight and number of reps
go to graphs tab and select that gym set.

expected

graph with lines or curved across 3 points somewhere above the x axis.

actual

graph shows a straight line over the x axi

That's maybe problem with determining the right scale and/or determining an appropriate min and max given a certain range ? Perhaps adopting d3 utilities, or even d3 even for rendering, you will have a much easier time with difficult to come up with appropriate logic to plot data meaningfully in all possible crazy scenarios users come up with. (d3 range article)[https://observablehq.com/@d3/d3-range]
Another issue is the single dot. It happens when the datetime in between two entries is short. Here with just 2 history entiers 24h apart:

Cases where weights differ, and with at least 3 entries seem to work fine even though the time between each entry is as as small:

I initially wrote a bunch of logic for scaling the Y axis, but it sacrificed a lot of features the chart author has put into his implementation. In the end it added an equal number of visual quirks (maybe more) than it fixed.
I'm going to close this ticket since it mainly contains suggestions I'm not going to make, however feel free to make a separate one for the bug where different day entries appear as a single dot.


[Bug]: Change of variable name for Measured battery open circuit potential

liionpack Version
0.3.3
Python Version
3.9
Describe the bug
Next release of PyBaMM will break Liionpack as referenced variable name is changed. There also appears to be some change in simulation results which needs looking into
Steps to Reproduce
No response
Expected behaviour
No response
Relevant log output
No response
Additional context
No response

Fixed in #240


corrected type in EnforceCleanOption

for consistency with ingredient.collect_repositories

Coverage remained the same at 86.377% when pulling 3e4cd87aba580d2b69ec254702345ce883b66f89 on jkramar:master into 9fc3becad57dbe51e7f87aeb7fd11a6552663cc1 on IDSIA:master.

Coverage remained the same at 86.377% when pulling eeb16a4479b71c9729742969575f98d3f365ebe1 on jkramar:master into 9fc3becad57dbe51e7f87aeb7fd11a6552663cc1 on IDSIA:master.

Thanks a lot!


fix bug of limit writer when cause short writer

Closes #
Describe your proposed changes here.

[x] Well-formatted commit messages
[ ] Rebased/mergeable
[ ] Tests pass
[ ] http/swagger.yml updated (if modified Go structs or API)
[ ] Feature flagged (if modified API)
[ ] Documentation updated or issue created (provide link to issue/pr)
[ ] Signed CLA (if not already signed)

@IronsDu I don't understand how this is a bug. Can you explain the bug you encountered, how this fixes it, and write a unit test to demonstrate that it was broken but is now fixed?
The Go documentation for io.Writer's Write() method states:

It returns the number of bytes written from p (0 <= n <= len(p)) and any error encountered that caused the write to stop early.

<EMAIL_ADDRESS>So, it is correct to update the value of n even if an error is returned.
Closing this PR for now but will reopen if the requested updates are made.

@dgnorton
If cause short write, the return value n is not correct. so, the limit writer's user maybe rewrite some data.

@dgnorton
This is a real issue in my production when cause disk full .  can you reopen it and test it?


getThreadHistory Error: parseAndCheckLogin got status code: 404. Bailing out of trying to parse response

getThreadHistory Error: parseAndCheckLogin got status code: 404. Bailing out of trying to parse response

Yep, same here

I encountered this yesterday. Apparently getThreadHistory has been causing problems for over six months. I recommend switching to getThreadHistoryGraphQL.
I assume getThreadHistory will soon be deprecated -- or perhaps replaced with the GraphQL version?

same issue

getThreadHistory uses GraphQL now
@Schmavery, we can close it


Copy PNG+XML when copying selection.

When we copy, currently, we copy the data model of the selection. That only makes sense to our editor. To implement what you’re asking would require a seperate copy as image option.
I rather suspect nobody would naturally find the option, rather expect copy/paste to “just work”. There’s also the problem that people might copy as image into another diagram and then complain they can’t edit it.
Short version - both we and the user needs to understand what the paste target is.
The solution here is to change copy to create a PNG of the selection with the data model embedded within that PNG.
That would paste the right thing in both cases without exposing the underlying issue.

Not possible to add a ClipboardItem with a Promise (lazy) to create the image when requested, XML is removed from images when using image/png mime type and not possible to add multiple clipboard items for different mime types. Workaround via img tag with data URI that contains embedded XML and use image/html mime type for clipboard item is possible, but image creation cannot be delayed so will slow down copy operations in the app.


Add .NET 6 as a target framework

Add .NET 6 as a target framework
Description
I believe that as a modern library, AngleSharp should target the current and latest LTS release of .NET, i.e. the recently released .NET 6, in addition to the frameworks it already targets.
This would also eliminate the need to reference the NuGet package System.Buffers, which became part of the framework since .NET 5.
PR submitted: https://github.com/AngleSharp/AngleSharp/pull/1011

Landed in preview.


Added new plantrip page

Title and Issue number

Title :
Added a new plantrip page.
Issue No. :
#415
Code Stack :
HTML ,CSS
Close #415

Video/Screenshots (mandatory)

Checklist:

[X] I have mentioned the issue number in my Pull Request.
[X] I have commented my code, particularly in hard-to-understand areas
[X] I have gone through the  contributing.md file before contributing

Additional context (Mandatory )
Enhanced the Plantrip page by making it fully responsive, adding visually appealing background images, and implementing a complete navigation bar. These improvements not only elevate the aesthetic appeal but also significantly boost the usability and user experience.
Are you contributing under any Open-source programme?

yes ,gssoc'24.

@apu52 now check i have linked the newplantrip page.


Single implementation of column type autodetection

Description of feature
Column type autodetection (e.g. whether numeric or categorical) is required at different stages of ehrapy
E.g. the autodetect option of encoding here relies on the adata.var[EHRAPY_TYPE_KEY] tag.
This is set when

reading a dataframe here
moving something from obs to X here.

We might want to harmonize that? It is the df.select_dtypes("number").columns pattern pretty consistently it appears at a first glance, but seems to be scattered.
TODOs:

[ ] collect where this type detection is done
[ ] move it to a single implementation

tableone might have something fairly robust we could be interested in too

I've merged this issue with the related issues #649 and #637 into the new issue #701 for a better overview. Therefore, I'll close this issue here.


Switch between Stereo / Hands-Free mode

Sony 1000WH4 can work in 2 modes:

hands-free - poor sound quality, mic works
stereo - good sound quality, mic doesn't work

I would like to be able to easily switch between these, as I both listen to music and sometimes use HF for online meetings.
Is there a switch implemented in this client?
If no, I would like to contribute and implement it.

Just built it. Apparently, there's no switch like that.

Correct. Two things:

There are prebuilt versions in the Releases page.
The app is built in order to support functions that are specific to Sony headphones. Switching between hands-free is not done using a proprietary Sony protocol, but a different device selection. I'm saying this because Zoom easily allows me to switch between the two options even though the Zoom people obviously never reverse engineered the app. So while support can be added, this tool is not the right place.

@Plutoberth for some reason I can't switch :( When I select handsfree output, it is suddenly gone. Same for input - mic simply does not work.
Everything works with mobile.

@Plutoberth for some reason I can't switch :( When I select handsfree output, sound is suddenly gone. Same for input - mic simply does not work.
Everything works with mobile.

Odd. Sounds like an OS issue.

Switching audio output endpoint on-the-fly may not work with some bugged applications
Also, selecting the microphone automatically switches the whole connection over to HFP, so if you still have selected the normal A2DP output it goes bust (even though programs aren't aware of that)


added inputSearchModel attribute exposing input search value

added inputSearchModel attribute exposing input search value to a model in the parent scope
Solves Issue #829

+1. Exactly what I needed.

Hi. it is possible to have this pull request accepted? in our company we have a project using ui-sellect and we wish to use this feature

+1 Please merge!

Fairly simple to do with a custom directive...
myModule.directive('myUiSelect', function() {
  return {
    require: 'uiSelect',
    link: function(scope, element, attrs, $select) {
      scope.$watch(function() { return $select.search; }, function(newSearchValue) {
        //...
      });
    }
  };
});

You can also then programmatically set $select.search to a new value if you wish.
(Ref: 7. Accessing $select)


Number.isNaN and Number.parseInt breaks app in IE

Hi,
I don't think you should use Number.isNaN and Number.parseInt in the lt-body component:
https://github.com/offirgolan/ember-light-table/blob/master/addon/components/lt-body.js
as it breaks apps in IE. I've tested IE 11.
I think you should use a polyfill or isNaN,  and parseInt directly.
Thanks,
Camille

Well actually it can be fixed by adding the following in ember-cli-build.js:
"ember-cli-babel": {
  includePolyfill: true
}

We took the approach of doing https://github.com/alphasights/ember-scrollable/pull/69 in ember-scrollable. It's pretty trivial to add if someone wants to bother with it and maybe save someone else headache.
A more involved but proper solution would be to leverage the new targets in 2.12+

A more involved but proper solution would be to leverage the new targets in 2.12+

Turns out targets don't currently include polyfills but only manage transpilation. :slightly_frowning_face:

https://embercommunity.slack.com/archives/C045BNHAP/p1498049676269826

thanks for the investigation @buschtoens
It seems like the logical next steps for targets, I clearly overstated what targets can do (for now).
I updated https://github.com/offirgolan/ember-light-table/issues/430 do you think that's the right approach?

I do have a spike to make ember-cli-babel build a more minimal polyfill

Until we get this functionality, a conditional polyfill in index.js seems like a sensible solution.


Can't import from Typescript

I'm trying to use chrome-promise in a Typescript Chrome Extension. The documented ES usage is:
import ChromePromise from 'chrome-promise';

const chromep = new ChromePromise();
chromep.something_or_other('param');

When I do the same in Typescript everything transpiles properly - ChromePromise is recognized with the right type information. Intellisense is shown, Typescript catches errors if I call a non-existing method - it's all fine.
At runtime, however, I can't create the ChromePromise instance. I get the following error:
Uncaught TypeError: chrome_promise_1.default is not a constructor
    at Object.__WEBPACK_AMD_DEFINE_ARRAY__ (background.js:77)
    at __webpack_require__ (background.js:20)
    at Object.defineProperty.value (background.js:63)
    at background.js:66

And indeed, chrome_promise_1.default is undefined, while chrome_promise_1 is a function.
Changing the import to import { ChromePromise } from ... results in an error saying ChromePromise is undefined.
import * as ChromePromise from ... yields an error saying ChromePromise has no type.
There's also a Stack Overflow question: https://stackoverflow.com/questions/47651244/cant-import-from-chrome-promise-in-typescript

I saw your SO question. As far as I can see, the typings are wrong. They declare a default export but that isn't reflected in the JS. The typings should have the form:
class ChromePromise {
}
export = ChromePromise // so require() works
export as namespace ChromePromise // so global is accessible

You would then use it as
Import CP = require('chrome-promise'), or with syntheticDefaultExports: import CP from 'chrome-promise'.

Hi! I think I used webpack when I tested typescript. Let me check tomorrow if I find anything. I will try @NaridaL solution first.

From what I tested, the problem is in the generated code. So the typings should not matter. I think it is related to #15 . Disabling amd in webpack should work. But it's better if I fix it in the code. I will try to release a new version this weekend.

I disabled AMD by adding the following to my module loaders:
{        test: /\.js$/,        loader: 'imports-loader?define=>false' }
It did not make any difference. So either this isn't the solution, or that's not the right way to disable AMD on Webpack.

To disable AMD in Webpack:
module: {
  rules: [
    { parser: { amd: false } }
  ]
}

Source: https://github.com/webpack/webpack/issues/3017#issuecomment-285954512

This is critical bug, please fix. I do not understand how to disable AMD.

I released a new version (v2.1.2). If it doesn't work, let me know. Thanks to @rafis for the PR.

@tfoxy I'm on v3.0.0 and seem to be encountering this error.
If I try what's listed in the documentation:
import chromep from 'chrome-promise';
chromep.tabs; // <-- type error, because typescript things chromep is the ChromePromise constructor

but
import ChromePromise from 'chrome-promise';
const chromep = new ChromePromise();
chromep.tabs...; // This compiles, but the transpiled code fails

No worries.  Would you accept a pull request that fixed them? :)

Of course! You can update the typings file directly. It is generated from another script, but that code is really ugly and it's only there to update the typings in case an api is added. So I doubt the script will be used again soon.

v3.0.1 fixes the typings in v3

The typings don't appear to be fixed for me.
import chromep from 'chrome-promise';

...

const tab = await chromep.tabs.get(tabId);

At runtime, this gets transpiled to:
chrome_promise_1.default.tabs.get(...);

but default is undefined, so I get:
Uncaught (in promise) TypeError: Cannot read property 'tabs' of undefined
    at Popup.tsx:66
    at step (Popup.tsx:41)
    at Object.next (Popup.tsx:22)
    at Popup.tsx:16
    at new Promise (<anonymous>)
    at __awaiter (Popup.tsx:12)
    at getMas (Popup.tsx:59)
    at Popup.<anonymous> (Popup.tsx:91)
    at step (Popup.tsx:41)
    at Object.next (Popup.tsx:22)

Check v3.0.2 . It has to do with the way typescript handles CommonJS modules.

Thanks, v3.0.2 worked for me!


Updating documents rewrites file and loses cursor position

When you edit a document and save it, the file is rewritten and the cursor is placed at the end of the file. Also, undoing/redoing though this state causes the cursor to jump to the beginning or end of the document, and any user formatting is lost.
It would be nice to update attributes in-place and save the cursor position. One possible approach would be walk through the JSON and only replace the attribute ranges needed (e.g. etag and ts). In vscode, we use `jsonc-parser for looking at the ranges in JSON. If this is done, then the cursor position should be preserved.

:slightly_frowning_face: In the last 60 days, this issue has received less than 5 community upvotes and we closed it. Still a big Thank You to you for taking the time to create it! To learn more about how we handle issues, please see our documentation.
Happy Coding!


Respect .ruby-version by default

We use this in our apps to reduce duplication of the version number.
When this option was added for the gems, we made this default to 2.7 - which I think was over- cautious.

Looks good, I didn't realise that the ruby/setup-ruby action looked at the .ruby-version file.
Is the use of 'default' special at all?


biulding a eat out bill splitter using JS

Topic Suggestion
biulding a bill splitter and eat with friends.
Proposed title of article
Eating Out Bill Splitter with js
Proposal Submission
Proposed title of article
buildiing a bill splitter and eat with friends.
Proposed article introduction
Key takeaways
creating  a splitter eater.
learning how to use js
getting knowledge on js usage
Article quality
this article will enable learners to gain skills on technology
References
n/a
Conclusion
this will enhance learners create a split eater

There are a lot of grammatical mistakes and readability issues in your suggestion. Please read our docs and work on your writing skills before submitting a new topic. @ngaremoses


Refactoring tfsef for vulberabilities

This PR fixes #
Checklist

[X] I have signed the CLA
[X] I have updated/added any relevant documentation

Description
What's the goal of this PR?
What changes did you make?
What alternative solution should we consider, if any?

This is not building :-\


Not compatible with react 0.13

I cannot install from the npm repository with React 0.13. Maybe just an update of the react version in package.json, or are there issues with React 0.13?

I just published 0.3.0, it should work with React 0.13.0.


Bluetooth: Convert HCI drivers to use a proper Zephyr driver API

Current status:

[x] Create a base binding and API definition
[x] Update the host to support new HCI driver instances
[x] Update h4.c
[x] Update native controller HCI driver
[x] Fix samples/bluetooth/hci_uart_async/ to work with the new driver model
[x] Fix bsim to work both with native and UART-based controllers (right now CI is failing)
[x] Figure out what to do with bt_read_static_addr(). Taken care of by #72580
[x] Figure out what to do with BT_HAS_HCI_VS, BT_HCI_VS and BT_HCI_VS_EXT (perhaps DTS properties?). Some preparation in #72580.
[x] Fix controller unit tests: no devicetree available for unit_testing "board" right now: #72871
[x] Update ipc.c
[x] Update userchan.c
[x] Update h5.c
[x] Update hci_ambiq.c (and associated DT binding)
[x] Remove hci_b91.c: #73289
[x] Update hci_esp32.c
[x] Update hci_psoc6_bless.c (and associated DT binding)
[x] Update hci_spi_st.c (and associated DT binding)
[x] Update hci_stm32wba.c
[x] Update ipm_stm32wb.c (and associated DT binding)
[x] Update spi.c
[x] Update hci_da1469x.c
[x] Update hci_nxp.c
[x] Update slz_hci.c
[x] Update documentation, especially stuff regarding /chosen properties
[x] Make it possible for nrf52_bsim to use also UART for HCI
[x] Update various apps under samples/ and tests/ that use the legacy HCI driver API
[x] Get rid of the Kconfig choice section for HCI drivers
[x] Get rid of BT_NO_DRIVER
[x] Deprecate the old API
[ ] Lots of testing

[x] bsim with virtual driver (hci_driver.c)
[x] ipc.c tested in CI
[ ] Test on hardware with virtual bus (i.e. combined build)
[ ]  Test on hardware with IPC (i.e. split build)
[ ]  Test on hardware with UART (i.e. split build)
[x]  userchan.c
[ ] Test with an OoT driver (e.g. NCS)

Right now the host hci_core.c uses #if DT_HAS_CHOSEN(zephyr_bt_hci) to separate the new-style HCI drivers from the legacy HCI driver support. The old API has been deprecated, but will only be removed after a deprecation period.
The following drivers depend on "west blobs", so they're not covered by CI, but were manually compile tested:

hci_psoc6_bless.c (west blobs fetch hal_infineon)
hci_esp32.c (west blobs fetch hal_espressif)
hci_stm32wba.c (west blobs fetch hal_stm32 doesn't work for me, see https://github.com/zephyrproject-rtos/zephyr/pull/72323#issuecomment-2143443846 )
slz_hci.c (west blobs fetch hal_silabs, same problem for me as with stm32, i.e. had to manually download)

What this PR doesn't try to tackle:

Find a solution for and fix driver dependencies on host HCI command sending APIs, which are e.g. not available with HCI_RAW. https://github.com/zephyrproject-rtos/zephyr/blob/d3c0dfbf3699fc98e01909ecf9a2ee834d7f4d41/drivers/bluetooth/hci/apollox_blue.c#L289-L333
Decide what to do with BT_HCI_ACL_FLOW_CONTROL currently referencing specific HCI drivers
net_buf allocations by drivers. Drivers should own their own memory rather than calling into the host side to do these allocations.
Making the HCI driver API support system calls. This is related to the above first point. We also can't have the driver make direct calls using the recv callback to the host, rather there needs to be another mechanism for the host to fetch data from the driver.

Fixes #51503

@jhedberg May I know what the main issue will be addressed by this driver API converting? It seems the changes are wide so I would like to know more about the background and see what comments I can give for HCI Ambiq codes. Thanks.

@jhedberg May I know what the main issue will be addressed by this driver API converting? It seems the changes are wide so I would like to know more about the background and see what comments I can give for HCI Ambiq codes. Thanks.

@aaronyegx most of the justifications can be found in the linked issue, i.e. #51503. Additionally, longer term we're considering the possibility of having the Bluetooth host run in user space. The primary way for user space to communicate with kernel space is through the system call interface, and there's a well established way how to do this for Zephyr driver APIs. Note that this aspect is something that's going to happen much later in the future (if at all) - the justifications in #51503 should be sufficient in themselves.

@aaronyegx I've pushed a conversion commit for the Ambiq HCI driver (https://github.com/zephyrproject-rtos/zephyr/pull/72323/commits/f7c34d40791099f6154da7d96bddc8d518c31545). It's a very simplistic one which doesn't e.g. try to add support for multiple instances (i.e. I keep the global variables instead of moving them to the instance structs). Could you take a look? I was able to verify that it builds, but I have no idea if it still works on actual HW.

@aaronyegx I've pushed a conversion commit for the Ambiq HCI driver (4818516). It's a very simplistic one which doesn't e.g. try to add support for multiple instances (i.e. I keep the global variables instead of moving them to the instance structs). Could you take a look? I was able to verify that it builds, but I have no idea if it still works on actual HW.

@jhedberg Thank you. I will test and update the Ambiq EVB test result soon.

@aaronyegx I've pushed a conversion commit for the Ambiq HCI driver (4818516). It's a very simplistic one which doesn't e.g. try to add support for multiple instances (i.e. I keep the global variables instead of moving them to the instance structs). Could you take a look? I was able to verify that it builds, but I have no idea if it still works on actual HW.

@jhedberg Thank you. I will test and update the Ambiq EVB test result soon.

@aaronyegx since #72609 was merged, I went ahead and updated this PR to support ambiq3 platforms as well: https://github.com/zephyrproject-rtos/zephyr/pull/72323/commits/15d8dd9a411a8d299397e2905a226eb2b7e694c7
Feel free to test :)

@ifyall would be good if someone checked that the psoc6_bless driver still works with this PR (see https://github.com/zephyrproject-rtos/zephyr/pull/72323/commits/19c6f37235e4807e47aeff66b22abb45bda0068e). I was able to compile test it but don't have the HW to do runtime testing.

@sylvioalves would be good if someone did some runtime testing of the ESP32 HCI driver changes in this PR (https://github.com/zephyrproject-rtos/zephyr/pull/72323/commits/0cb7f9977a285fbb52af7474cf61a70ef6fb49aa). It seems to build fine, but I haven't been able to test it on actual hardware.

@erwango could you or someone else with the HW test that the hci_stm32wba.c HCI driver still works as expected with this PR? (https://github.com/zephyrproject-rtos/zephyr/pull/72323/commits/8f84c50ceb9b07b8c56fb3e28a89eb7333603059). Another problem I had with this one was the blobs support, at least for me west blobs fetch hal_stm32` did not fetch the binaries and I had to manually download them instead. It looks like "west blobs" should be currently supported by hal_stm32, however for some reason it didn't work for me. Could you check if this is some local thing or maybe something is wrong with the stm32 HAL definition? Blobs from other modules (like espresso) seem to work fine for me.

@erwango and please also take a look at the conversion of the STM32 IPM HCI driver: https://github.com/zephyrproject-rtos/zephyr/pull/72323/commits/5ce503f401ba47b25a4f7b475d57136f50c9cb47

@yeaissa @dleach02 it'd be good if the NXP driver conversion in this PR was tested (commit https://github.com/zephyrproject-rtos/zephyr/pull/72323/commits/3d58d23385e413d9b417b8e40b18568693837221). It seems to build fine at least.

@fkokosinski are you able to test the slz_hci.c changes in this PR (commit https://github.com/zephyrproject-rtos/zephyr/pull/72323/commits/d964da8ed32638652213671ac13f4f58b1017116)?

@fkokosinski are you able to test the slz_hci.c changes in this PR (commit d964da8)?

Also, can you confirm that the controller really sits behind an UART like it claims:
https://github.com/zephyrproject-rtos/zephyr/blob/fe03e0c4bb3f8a658efe69b04c430d1a15474c6c/drivers/bluetooth/hci/slz_hci.c#L198
It seems a bit odd that it'd be requiring so many binary blobs in that case.

I now promoted this to a normal PR since all HCI drivers have been converted. I still added the DNM label, since there are documentation updates which are still missing. We also need to decide whether to keep the bt_hci_driver_register() API or remove it. With this PR there are no more users of it in the upstream tree.

@fkokosinski are you able to test the slz_hci.c changes in this PR (commit 121c14f)?

Hey, unfortunately I don't have the HW at hand. I'm no longer maintaining SiLabs platforms in Zephyr, but maybe someone from SiLabs could help you with this?

hi @jhedberg,
the cy8cproto_062_4343w board does not work ('west build -b cy8cproto_062_4343w samples\bluetooth\peripheral_dis')
i do not see CONFIG_DT_HAS_ZEPHYR_BT_HCI_UART_ENABLED in .config,
in boards\infineon\cy8cproto_062_4343w\cy8cproto_062_4343w.dts we use compatible  infineon,cyw43xxx-bt-hci, which actually is extension of H4.
	bt-hci {
		status = "okay";
		compatible = "infineon,cyw43xxx-bt-hci";
		bt-reg-on-gpios = <&gpio_prt3 4 (GPIO_ACTIVE_HIGH)>;

		/* Configuration UART speeds for firmware download (fw-download-speed) and
		 * HCI operation (hci-operation-speed).
		 * If hci-operation-speed or fw-download-speed are not defined in bt-hci{...}
		 * node, cyw43xx driver will use bus/current-speed as default speed.
		 */
		fw-download-speed = <3000000>;
	};

Should we update infineon,cyw43xxx-bt-hci binding or board dtsi to addition enable zephyr,bt-hci-uart as well.
Regards,
Nazar

Should we update infineon,cyw43xxx-bt-hci binding or board dtsi to addition enable zephyr,bt-hci-uart as well.

@npal-cy thanks for discovering this issue. It seems I overlooked the various extensions to the standard drivers, like h4.c (basically I thought the extensions wouldn't be drivers in themselves, having their own DT_DRV_COMPAT, etc. The h4.c driver gets enabled by having a zephyr,bt-hci-uart DTS node, so I think that can't be avoided. The way I'd structure this, is to place the zephyr,bt-hci-uart node as a child of the actual UART node (like I've done in other places in this PR), and then the infineon,cyw43xxx-bt-hci node would be a child of that one. That way you could just reference DT_PARENT() from the cyw43xxx driver instead of relying on DT_CHOSEN(zephyr_bt_uart) (a property which should really go away as part of this PR). Does that sound alright?

@npal-cy I've now pushed an update to the H4 commit in this PR which does the necessary change. It turns out I had already done the same restructuring for the giga_r1 board, but not for the Infineon board.

@ifyall would be good if someone checked that the psoc6_bless driver still works with this PR (see e361ac4). I was able to compile test it but don't have the HW to do runtime testing.

@npal-cy I've now pushed an update to the H4 commit in this PR which does the necessary change. It turns out I had already done the same restructuring for the giga_r1 board, but not for the Infineon board.

Hi @jhedberg ,
for now there are two Infineon's boards with enabled BLE:

cy8cproto_062_4343w (use H4 extension )
cy8cproto_063_ble  (use bless hci driver)

I checked your changes on both kits and it works.

Just an update to the people following (and potentially testing) this: it was decided in yesterday's Bluetooth meeting that this will be targeted for the Zephyr 3.7 release. The old API will still remain, but be marked as deprecated.

@rugeGerritsen just as a general note, the documentation for many of the drivers/bluetooth.h APIs have been copied from the original drivers/bluetooth/hci_driver.h, i.e. the original documentation likely suffers from the same issues. I will address your comments for the new APIs, but since we're deprecating the old API I think I'll leave that untouched.

@jhedberg Working good on esp32 devices.

@jerome-pouiller @Thalley could you take another look? Due to the size of this PR it'd be better to get it in sooner rather than later, especially since the feature freeze is coming this week. Since there doesn't seem to be any fundamental objections to the architectural/API change introduced here, any follow-up fixes & cleanups could happen after the feature freeze as well. There are a couple of other open HCI driver PRs which conflict with this one, which also target the next release, so it'd be good to start merging these sooner rather than later so we get the conflicts resolved and everything merged on time.

@jerome-pouiller @Thalley could you take another look? Due to the size of this PR it'd be better to get it in sooner rather than later, especially since the feature freeze is coming this week. Since there doesn't seem to be any fundamental objections to the architectural/API change introduced here, any follow-up fixes & cleanups could happen after the feature freeze as well. There are a couple of other open HCI driver PRs which conflict with this one, which also target the next release, so it'd be good to start merging these sooner rather than later so we get the conflicts resolved and everything merged on time.

Indeed, and the number of commits easily hide comments on Github (...).
I'd be OK with merging as is, but I would have to have at least https://github.com/zephyrproject-rtos/zephyr/pull/72323#discussion_r1633432927 resolved ASAP so that we can do things properly (which I believe was the main point of this change in the first place ;) )

@rugeGerritsen @aescolar @yeaissa @erwango @npal-cy @alwa-nordic please take a look ASAP, we would like to include this in Zephyr 3.7.0, which means merging it before this Friday


Proposal: Get all permissions associated to a resource relation

Problem
At the moment there isn't an API to retrieve all permissions that are given with a relation on a resource.
Eg:
given a schema like:
definition resource {
    relation manager: user
    relation owner: user

    permission own = owner
    permission manage = manager + own
}

it would be very useful if there was an API that given resource_type=resource, relation=owner returns a list of permissions [own, manage], while if relation=manager the result would be [manage]
Proposal
Introduce a new API does what explained in "Problem"

One suggestion I would like to add if possible, make "relation" parameter optional, if not passed, return all the possible permissions.
Same API pass, resource_type=resource
Returns -> [own, manage]

Related: https://github.com/authzed/spicedb/issues/439

Related: https://github.com/authzed/spicedb/issues/439

Is this something that the AuthZed team plans to work on? At my company we're evaluating alternatives to Oso, and SpiceDB/AuthZed seem to fit the majority of the use cases and is much more flexible.
But we do have a need to show to users what permissions they have on specific resources. As I understand from this issue, this doesn't exist yet?

@DonDebonair 👋🏻 it would seem like your requirement is slightly different tho?

this issue suggests that "for a given resource and relation, what permissions does it have?"
your ask reads like "for a given subject, what permissions does it have over a given resource?"

is that correct?

@vroldanbet you are absolutely right! I misread/misunderstood the original issue. I mixed up relation and subject.
So I'm indeed asking "for a given subject, what permissions does it have over a given resource"
Should I open a separate issue for that, or is this already possible and did I not look properly for it?

@DonDebonair yup, feel free to open a new issue! I suspect it would be built on top of the foundations for https://github.com/authzed/spicedb/issues/621

Fixed by #1891


Inline cell edit deselect rows

I'm submitting a ... (check one with "x")
[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, post on Stackoverflow or Gitter

Current behavior
On inline cell edit, selected rows become deselected.

On updating cell value with inline edit, when selecting content of the input (in the cell) with double click, all selected rows deselect.
Expected behavior
Selected rows should stay selected after and during cell editing

Selected rows should stay selected after and during cell editing
Reproduction of the problem

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

Please tell us about your environment:

Windows. VSC

Table version:

16.1.1

Angular version:

7

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript X.X | ES6/7 | ES5]

Possibly related to #1887


Add rudimentary doc generation

Adds basic typescript -> doc generation.

@petebacondarwin it would be super cool if we could move to dgeni-typescript package into dgeni-packages, if possible - i realize the angular team might not like that, but having even basic support would clean up other repos a LOT (and allow easier contributions...)

@robwormald I agree that copying it from the angular repository is a annoying. We don't need to remove it from angular just to put it into dgeni-package.
If you could put together a PR against dgeni-packages that contains a basic typescript package then I will merge it. As it matures, we can drop the custom package that is in angular.

Awesome!
@robwormald can you flatten this PR into fewer commits at all? Are they each significant enough to have their own commit?
Also, can you rename the commits to have the "angular style" commit messages? chore(docs): add documentation generation for example.

yeah, oops. i'll close this one without merging and i'll drop in another flattened one.

@robwormald no need, just rebase yours and force push to your fork, it'll update this PR.

@robwormald  in other words:
git rebase -i HEAD~9

then fixup the ones you want to "flatten" and reword the ones you'd like to change the text to.
after that you just: git push origin dgeni-docs -f and it'll update this PR.

see https://github.com/ReactiveX/RxJS/pull/240


Time Series CSV| Can't Import in the App

Description:
Importing CSV with no header and no timestamp. Signals are column-wise, each signal contains 100 rows with values between 0 and 1.
I want to see each column (one signal) at a time, and label them, one by one, as good or bad.
Problem:
However I keep getting the error:

Your config and imported data are inconsistent
Error   at item 0: "csv" key is expected in task data [assume: item["data"] = task root with values]
{'data': {'0.8': 0.8, '0.7': 0.7}} Error at item 1: "csv" key is expected in task data [assume: item["data"] = task root with values]

My config file, as described in the docs:
<View>
    <Header value="Time Series from headless CSV"
            style="font-weight: normal"/>

    <!-- Control tag for region labels -->
    <TimeSeriesLabels name="label" toName="ts">
        <Label value="Good" background="#5b5"/>
        <Label value="Bad" background="#55f"/>
    </TimeSeriesLabels>

    <!-- Object tag for time series data source -->
    <TimeSeries name="ts" valueType="url"
                value="$csv"
                sep=",">
        <Channel column="1"
                 strokeColor="#1f77b4"/>
    </TimeSeries>
</View>

App: https://app.labelstud.io

Hi, @vcmorini ! Label Studio 1.0.0 doesn't support importing time series data without a header. In your particular case you have to specify column name 1 in csv file. Meanwhile we're planning to add a headerless file upload support for time series, thanks for pointing out


TV Android App: Updated vendor id support

Problem

TV Android app had issues executing shell commands needed for Matter testing.
TV casing app users cannot execute certain commands as they don't have access

Change overview

Updated JNI layer for Native C++ AppPlatfromShellCommand logic so that users can pass string and execute this code
Deleted unused

Testing
Manually tested the flow:

Run both TV Android app && TV casting app linux
On TV Android app go to -> Run Commands and select input text at the top
Enter add-admin-vendor 65521 and press ok
On TV casting app, once TV Android app is discovered run cast request 0
On TV Android app, once you get a dialog popup select ok
On TV casting app run command: cast cluster channel read channel-list 0 1

Users can now print the app access level

Updated instructions.

If possible, could you get Android chip-tool working again? I think it was the API change from wifi scanning that broke it.


libc::lutimes is not defined when building with --target=wasm32-unknown-emscripten

I'm building a wasm project that depends on filetime and it looks like libc::lutimes is not defined for wasm32-unknown-emscripten targets.
Build log:
$ cargo web build --target=wasm32-unknown-emscripten
   Compiling filetime v0.1.15
error[E0425]: cannot find value `lutimes` in module `libc`
  --> /home/justas/.cargo/registry/src/github.com-1ecc6299db9ec823/filetime-0.1.15/src/unix/utimes.rs:12:42
   |
12 |     super::utimes(p, atime, mtime, libc::lutimes)
   |                                          ^^^^^^^ did you mean `utimes`?
error: aborting due to previous error
For more information about this error, try `rustc --explain E0425`.
error: Could not compile `filetime`.
error: build failed

This might just be an issue with libc so feel free to close it and I'll reopen it in the libc repo.

Ah this is probably a case where the right API needs to be used for emscripten and the current fallback may be too aggressive or something like that. Unfortunately I'm not that famiar with emscripten though :(


Command::send() is highly inefficient

Even the simplest blinky example compiles down to this horrorshow on ARMv7M:
File  .text    Size Name
0.0%   0.6%     74B [10 Others]
2.6%  79.4% 10.1KiB ssd1306::command::Command::send
0.2%   6.9%    900B blinky::init
0.1%   3.3%    424B cortex_m_rt::reset_handler
0.1%   2.3%    300B <ssd1306::mode::graphics::GraphicsMode<DI>>::flush
0.0%   1.3%    166B __aeabi_memset4
0.0%   1.2%    152B blinky::draw_square
0.0%   1.1%    142B cortex_m_rtfm::atomic
0.0%   1.0%    134B <ssd1306::mode::graphics::GraphicsMode<DI>>::set_pixel
0.0%   0.8%    100B memset
0.0%   0.7%     96B memcpy
0.0%   0.6%     80B blinky::idle
0.0%   0.2%     30B blinky::main
0.0%   0.1%     10B __aeabi_memset
0.0%   0.1%     10B core::result::unwrap_failed
0.0%   0.1%     10B core::panicking::panic_bounds_check
0.0%   0.1%     10B SVCALL
0.0%   0.1%     10B MEM_MANAGE
0.0%   0.1%     10B DEBUG_MONITOR
0.0%   0.1%     10B PENDSV
0.0%   0.1%     10B USAGE_FAULT
3.3% 100.0% 12.7KiB .text section size, the file size is 387.9KiB

Obviously the compiler fails to see through the nature of the call to generate straight forward output.
It's not as close as bad on ARMv6M but a trivial test application easily doubles in size mostly due to that one function:
File  .text   Size Name
0.2%  13.5%   320B [35 Others]
0.4%  27.3%   644B ssd1306::command::Command::send
0.2%  15.6%   368B main
0.2%  14.9%   352B <ssd1306::properties::DisplayProperties<DI>>::init_column_mode
0.1%   6.1%   144B <ssd1306::properties::DisplayProperties<DI>>::set_rotation
0.1%   5.1%   120B <ssd1306::interface::i2c::I2cInterface<I2C> as ssd1306::interface::DisplayInterface>::send_data
0.1%   4.2%   100B <stm32f042_hal::i2c::I2c<stm32f042::I2C1, PINS> as embedded_hal::blocking::i2c::Write>::write
0.0%   3.6%    84B <ssd1306::mode::character::CharacterMode<DI> as core::fmt::Write>::write_str
0.0%   2.7%    64B cortex_m_rt::reset_handler
0.0%   1.8%    42B <ssd1306::interface::i2c::I2cInterface<I2C> as ssd1306::interface::DisplayInterface>::send_command
0.0%   0.8%    18B __aeabi_memcpy
0.0%   0.6%    14B __aeabi_memset
0.0%   0.5%    12B __aeabi_memclr
0.0%   0.4%    10B core::result::unwrap_failed
0.0%   0.4%    10B core::panicking::panic_bounds_check
0.0%   0.4%    10B core::slice::slice_index_order_fail
0.0%   0.4%    10B core::slice::slice_index_len_fail
0.0%   0.4%    10B PVD
0.0%   0.4%    10B TIM1_BRK_UP_TRG_COM
0.0%   0.4%    10B DMA_CH4_5_6_7
0.0%   0.4%    10B EXTI0_1

Oh, I just noticed this actually varies a lot depending on the interface type, the first bloat output above was from a SPI version and here's the same for examples/blinky_i2c:
File  .text   Size Name
0.0%   2.4%   108B [13 Others]
0.3%  21.8%   976B ssd1306::command::Command::send
0.2%  14.7%   658B blinky_i2c::init
0.2%  13.2%   590B <stm32f103xx_hal::i2c::I2c<stm32f103xx::I2C1, PINS> as embedded_hal::blocking::i2c::Write>::write
0.1%   9.5%   424B cortex_m_rt::reset_handler
0.1%   8.0%   358B <ssd1306::mode::graphics::GraphicsMode<DI>>::flush
0.1%   5.1%   226B <stm32f103xx_hal::i2c::I2c<stm32f103xx::I2C1, PINS>>::init
0.1%   4.2%   186B __aeabi_memcpy4
0.1%   3.7%   166B __aeabi_memset4
0.1%   3.4%   152B blinky_i2c::draw_square
0.0%   3.1%   138B cortex_m_rtfm::atomic
0.0%   3.0%   134B <ssd1306::mode::graphics::GraphicsMode<DI>>::set_pixel
0.0%   2.2%   100B memset
0.0%   2.1%    96B memcpy
0.0%   1.8%    82B blinky_i2c::idle
0.0%   0.7%    30B blinky_i2c::main
0.0%   0.2%    10B __aeabi_memset
0.0%   0.2%    10B core::result::unwrap_failed
0.0%   0.2%    10B core::panicking::panic_bounds_check
0.0%   0.2%    10B core::panicking::panic
0.0%   0.2%    10B SVCALL
1.5% 100.0% 4.4KiB .text section size, the file size is 290.8KiB

Wow that's pretty awful. Is this on 1.26 nightly? Presumably it's the compiler doing some sort of monomorphisation stuff. Any ideas how to solve?

This is with rustc 1.26.0-nightly (9c9424de5 2018-03-27)
And no, no idea yet.

Strange!
I also played with the GPIO stuff of the SPI interface a bit and it seems that simply removing the self.dc.set_high(); makes an interesting difference...

Ah, I thought it would've inlined into flush() which gets called by init(). Either way yeah the problem is in command.rs.


Deferred background upload of large files

Hi,
I currently work for Kinderly and am scoping out a way to rewrite our current Flash/Air mobile app as a progressive web application. One of the key requirements is the ability to schedule fire-and-forget uploads of large files (photos and videos in addition to other data) when the user is offline, for automatic assumption and resumption when the user returns online. The use case is as follows:
Picture a nursery with a large garden, with one crappy BT Hub from 5 years ago. The manager there bought a bunch of cheap tablets¹ with just WiFi on them and told the staff that they need to use these to take EYFS observations and attach photos and videos to them. Now, in the far end of the garden, the WiFi is nonexistent so the app absolutely must work offline - so far that's not too much of a problem as service workers are already here. Then the staff return the devices to the office, where it can connect to WiFi again. What should happen at this point is that background sync should be initiated, and all those observations with media attached should start being uploaded to the server.
My question is, how much of this use case is covered by the current service worker spec as well as this proposal? On first reading of this example it seems like it may actually be quite difficult to pull off, requiring a request to be fired immediately and then put on hold by the cache. In my scenario, I'd like to be able to store all the media in say IndexedDB, and initiate uploads in response to some event that informs the service worker that it has network again (unsure if I can listen to online/offline events in a service worker, probably not).
¹ For now I'm assuming Android tablets which can run latest Chrome; I have no illusions that a shim Cordova app for iOS won't be necessary

https://developers.google.com/web/updates/2015/12/background-sync?hl=en solved this already for small uploads & downlaods. But this spec will solve it for larger ones.

@jakearchibald would you have any preliminary thoughts as to around the file size and/or transfer time that would mark the boundary between background-sync and background-cache? If that boundary wasn't a fixed size, the browser time out in the description lightly implies that, would you see a world where we err on he side of background-cache or possibly a somewhat fluid switch by which the browser could move activities between the two as size and connectivity, etc warranted?

@Westbrook

would you have any preliminary thoughts as to around the file size and/or transfer time that would mark the boundary between background-sync and background-cache?

I think it's more: If an OS notification showing the progress of the upload/download feels like overkill, you're probably better off with background sync.


Crypto delete refactoring

Refactoring of CryptoDelete transition logic

Should we close this PR @CordonaCodeCraft ?

First thing to do tomorrow morning


Using seq.hpp in multiple translation units generates duplicated definition errors

When seq.hpp is used in different translation units then you get an error during linking that the global operators in the seq_logger namespaces are duplicated. Solution is to use inline functions for these operators to fix it. Would be nice to have it fixed!

Yup, thanks for pointing this out. Will commit changes today


Not working for gridsome + Bootstrap Vue

What

Our site got some bugs working on IE (11), no input is clickable/functioning.  b-pagination, b-form-checkbox, etc...
Details
I checked bootstrap vue (the package we added to gridsome) and found out that it requires polyfill for older browsers. They suggested to use polyfill.io but the bug is still there. - Const must be initialized

Do you have any idea why?
(Bootstrap vue's instruction about loading polyfill package: https://bootstrap-vue.org/docs#js)

@ngoclx The code loaded in the browser must be compiled to ES5, I think you may be loading code with modern syntax such as const and let.
Can you please post the error message you are seeing?

Sorry guys, it was actually a bug from flexsearch plugin of gridsome. I'll be closing this tiket!


Blase3D Short-Term Roadmap

BACKGROUND READING

[x] Read blase paper
[x] Skim starfish paper Link
[ ] Read PHOENIX paper Link
[ ] Skim sick paper Link
[ ] Read perceptron brown dwarf paper Link

PAPERS TO CITE

[ ] Lueber23

CODE PRIMERS

[x] Pytorch (install with CUDA)
[x] Tensorboard

[ ] Make Teff, Logg, Z heatmap for one spectral line for amplitude, line width, and line shape
[ ] Register for TACCSTER

[ ] Deal with GPU Memory (be more memory friendly)
[ ] Need to write grid point to state dict, and in .pt name
[ ] Create equivalent width mapping from amplitude, sigma, and gamma
[ ] Fix Z to solar

[ ] Bake blase versions into state_dicts
[ ] Grid range Teff (4200, 5800), Logg(3, 5)


Add preset webpack (postcss-loader)

👋
Reference https://github.com/postcss/postcss-loader/issues/262
normalizeUrl doesn't seem to be a safe transform, when using webpack :)

👋
Is it possible to locate what's causing the issue? normalizeUrl should be a safe transform, if it isn't it'd be good to remedy it. webpack preset sounds like a good idea. 👍

This appears to be an issue with the use of css-modules within css-loader (and webpack module resolution) in combination with the normalized URL.  For a web browser ./images/image.png and images/image.png are equivalent.

I hadn't found the time yet to express the issue, yep normalized URL's normalizeUrl can be a problem for the abnormal css-loader :D 😛 if cssnano runs before (postcss-loader). I dunno if this needs to be adressed by cssnano directly, webpack edge cases tend to spread like cancer across other projects 😉 . Anyways @clydin thx for chiming in :)

Is there any updates for current issue?

@o-mega The webpack guys are developing a new loader which should take care of the issue. I haven't heard anything from them in a while, though.

@andyjansson Is there any way to disable only normalizeUrl and stay cssnano working normally with css-loader ?

@o-mega it's already disabled in css-loader by default: https://github.com/webpack-contrib/css-loader/blob/master/lib/processCss.js#L193-L199


Fix PER bug. Add loadable memory. N-step TD.

This is basically #214 with most of the extra features cut out, because the PER bug needs to get fixed, whether or not the rest ever merges. DQfD, NoisyNets, and the csv logging callback are removed.

Fixes bug discussed in #212 where observation indices rotate while their priorities stay static.

Adds loadable memory. The PartitionedRingBuffer is similar to the old implementation of RingBuffer but the data stays locked to the idx it was originally assigned to. That's what fixed the PER issue, and also makes it pretty easy to load demonstration data and never delete it. I originally used it in DQfD but I think it has more applications than that. A feature like this was requested in #262.

Adds n-step temporal difference error to dqn (only for prioritized memories). This basically involves a change to how the experiences are retrieved from memory. I'd appreciate someone double checking my math on that.

@jakegrigsby Thanks for your PR! I've left you some comments. Also, it seems it doesn't pass on Tensorflow backend. Can you clear this out?


Automate Service Startup

As someone who wants use backend utilities, I should be able to deploy all of the services with one command.

[ ] #2
[ ] #3