Add a secondary mode with --document-private-items

Context
Often, the internal parts of a crate have their own documentation, even if they're not exposed as part of the public API.  It can be pretty useful to be able to have a rendered version of that documentation for reference and development purposes:

the doc comments are rendered as text in a way that may be nicer to read;
the docs are linkable, making it easy to share references to specific items' docs with collaborators;
the rustdoc interface can show highlights of the internal structure (e.g., all trait implementations in one place);
the internal documentation may be of independent interest.

For instance, a bunch of notes on the internal details of a crypto implementation I wrote are kept in documentation for internal modules, hosted separately from the "external" docs. Although that's probably an extremal example in terms of "effort put into documentation of private items", I think this would still be useful ecosystem-wide.
Proposal
docs.rs could render documentation for all crates twice, once as normal and once with --document-private-items, then host a second copy of the documentation for all crates under a different URL. Each set of docs would link internally to itself, so following links in the "public" section would remain in the "public" section, and following links in the "private" section would remain in the "private" section.
I'm not attached to this in particular, but my suggestion would be to place all private docs on a separate subdomain, say private.docs.rs, with an identical URL structure to the "public" docs.rs. The advantage of this choice is that:

it's really easy to switch between internal and external docs by adding or removing the subdomain;
it's clear from looking at the URL bar which version you're seeing, even if the full path is too long to display.

I would very much like to see this or perhaps some other mechanism that would allow me to produce

Properly rendered documentation for non-public components
The source for the documentation should be close to the source code
A way to make very very clear to the reader of the documentation that the private parts are private.

The distinction between public API and private components is vital when documenting for external consumers, but that is not the only reason to document code. Well organized documentation should be read and created for those who are developing the unit.
Currently, for example, I'm working on a module that provides only a single public public method, but there are enough different internal parts that it would be extremely useful (even for me, who is the sole author of this at the moment) to have a navigable and reasonably rendered docs. Once I ask colleagues to look at this, it will be even more important that there be something more readable than the raw comments in the source.

You can currently set this for the entire crate by setting the --document-private-items flag in your cargo.toml (docs). It sounds like you're asking for even more than that though: both public and private documentation. That sounds hard to do in general, I want to avoid building crates twice. Maybe rustdoc could get a feature that marks items as private when passing --document-privste-items?

Right, setting the --document-private-items flag in a single crate doesn't provide the feature I think would be great: linkable, crossreferenced documentation for the internals for every crate in the ecosystem. Having rustdoc mark items as private when rendering them with --document-private-items would be great, but I think it's independent of this feature request, which is really about rendering crates twice.
Can I ask what the motivation for avoiding building crates twice is? Is it just server load, or is there some other reason?
I'm not sure how the docs.rs infrastructure is organized, but if the private docs were rendered independently on a subdomain, would it be possible to scale out rather than up by running a second copy of the existing infrastructure?

Can I ask what the motivation for avoiding building crates twice is? Is it just server load, or is there some other reason?

The reason is storage costs, not server load. All the documentation we build we have to store in perpetuity: we currently have 3 TB of docs and that number will only go up over time.
I think this is a reasonable request, but I don't want to implement it until we reduce some of our needless storage use (#379 and #343). See also https://github.com/rust-lang/docs.rs/issues/608 and https://github.com/rust-lang/docs.rs/issues/174#issuecomment-572590213 which have been postponed for similar reasons.

Ah, that's totally reasonable. Thanks for the information and for your work on docs.rs :)

@jyn514 Can private items be labeled as private in any way using rustdoc? Is that too dependent on other requests?

@shivanandvp not currently, no - if you pass --document-private-items, rustdoc won't distinguish between private and public items. I think it's useful to do so, though - can you open an issue in rust-lang/rust? https://github.com/rust-lang/rust/issues/new/choose

Note: private items are now marked with a lock icon in --document-private-items docs.

I think this is now feasible to implement. We implemented compression a while ago, which greatly decreased our storage costs, and rustdoc now distinguishes private items in the documentation. My main concern is that this will show private items even for crates that have not opted in, which both makes the UI more overwhelming (more docs overall) and exposes the implementation details, even if they're marked with a lock.
That said, I would be very willing to expose this as a config in package.metadata.docs.rs as long as it's opt-in and not opt-out.

Oh, I missed that the original suggestion was for a separate private.docs.rs domain. Yes, I agree that makes sense to do for all crates without a config.

We do have a build duration issue right now, the number of published crates has increased a lot in the last few years and the build system hasn't scaled with it. We're pretty close to doing that scaling though, and then we should have the capacity to double the number of builds.

IMO even after having additional build capacity / scaling, #343 would still be a good idea before adding this additional build (or storing the json output additionally, for that matter :) )

@syphar let's not block anything on #343, I don't have the energy to make an rfc for that. We can limit the private docs to a single target if that makes you happier.

@Nemo157 I suspect 99% of our build issues come from constantly rebuilding dependencies, and if we reused the build cache for the public and private doc builds, it would add hardly any time. But we can wait for https://github.com/rust-lang/docs.rs/issues/1757 if that would make you comfortable.

I think, it would more preferrable to have a switch, like a theme switch, to show the all documentation or only the public one. This of course would require such support from rustdoc.

@Mingun Agreed, this would be nice to have in rustdoc and not just docs.rs (potentially also for hidden ones, not just private).
In general, switches like that (or collapsed-by-default elements) in rustdoc may be useful in other cases too, e.g. I suggested it as a solution for the fallible allocation APIs (or other uncommon/advanced APIs that most users may not need/want).


Support for Gentoo and Sabayon Wikis

Hi,
I've been trying to edit Gentoo and Sabayon Wikis with your extension but both keep returning errors such as:
/Error detected while processing function <SNR>16_MWRead:
line    2:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/fusion809/.vim/bundle/vim-mediawiki-editor/plugin/mediawiki_editor.py", line 104, in mw_read
    s = site()
  File "/home/fusion809/.vim/bundle/vim-mediawiki-editor/plugin/mediawiki_editor.py", line 67, in site
    text='/w/'))
  File "/usr/lib64/python2.7/site-packages/mwclient/client.py", line 116, in __init__
    self.site_init()
  File "/usr/lib64/python2.7/site-packages/mwclient/client.py", line 124, in site_init
    siprop='general|namespaces', uiprop='groups|rights', retry_on_error=False)
  File "/usr/lib64/python2.7/site-packages/mwclient/client.py", line 204, in api
    info = self.raw_api(action, **kwargs)
  File "/usr/lib64/python2.7/site-packages/mwclient/client.py", line 316, in raw_api
    raise errors.InvalidResponse(res)
mwclient.errors.InvalidResponse: Did not get a valid JSON response from the server. Check that you used the correct hostname. If you did, the server might be wrongly co
nfigured or experience temporary problems.

with g:mediawiki_editor_url being set manually to wiki.gentoo.org (when prompted), g:mediawiki_editor_path being set to / (when prompted). mwclient has been installed on my PC using sudo pip install mwclient and vim-mediawiki-editor works fine for the English Wikipedia.
Thanks for your time,
Brenton

@fusion809 8 years later...
I'm unable to reproduce the bug with the Gentoo wiki. It appears the Sabayon Wiki domain is dead.
Is it possible that this was a network failure issue?

Could be; doesn't matter anyway, I don't use either distros or have much interest editing their Wikis anymore.


can not find EthereumRlp in swift

Describe the bug
read this code https://github.com/trustwallet/wallet-core/blob/master/swift/Tests/Blockchains/EthereumRlpTests.swift
cannot find
EthereumRlpRlpList
EthereumRlpRlpItem
EthereumRlpEncodingInput
EthereumRlp
EthereumRlpEncodingOutput
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Add any other context about the problem here.

Hi @lovivid, could you tell how do you run the tests? Do you run tools/generate-files before running iOS tests?


[RULE] Deploy VMSS across availability zones with VMSS Flex

Existing rule
No response
Suggested rule
As per APRL recommendation, when creating VMSS, implement availability zones as a protection measure for your applications and data against the rare event of datacenter failure.
Resource Type microsoft.compute/virtualmachinescalesets
Property with expected value array_length(zones) > 1
Pillar
Reliability
Additional context
Reliability Hub
Create a Virtual Machine Scale Set that uses Availability Zones
Update scale set to add availability zones

@jeanchg The documentation is unclear on the point of flexible vs uniform in your title.
Are we saying this is only a recommendation if the orchestration mode is Flexible?

I can create the rule, but awaiting for alignment before constructing the rule body.

checking with @rahalan , will update shortly

Any update @jeanchg?

@BernieWhite @BenjaminEngeset @jeanchg I see no reason, why this should only apply for flexible. I would suggest to recommend it for uniform as well.


all paths start from the same origin in rviz

when apply them in rivz all paths start from the same point, how should run them and keeping each robot from it's own start point?

Hi
I used kimera_multi dataset to implement MR-SLAM, but i don't know the
starting coordinates to start running the dataset so i start all at origin
coordinate (0,0,0) at rviz, this problem causes no overlap area between the
trajectories or many wrong overlapped area. The final constructed map is
not matched with the groundtruth map, so how can i resolve this problem?
في الاثنين، 1 مايو 2023 في 5:14 م تمت كتابة ما يلي بواسطة Yun Chang <
@.***>:

Hi. Are you visualizing the trajectory of Kimera-VIO or Kimera-Multi?
—
Reply to this email directly, view it on GitHub
https://github.com/MIT-SPARK/Kimera-Multi-Data/issues/4#issuecomment-1529759379,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZHQ4Z6A4V73R4V3VQVDCI3XD7ANNANCNFSM6AAAAAAXRSCNSE
.
You are receiving this because you authored the thread.Message ID:
@.***>

How can we do it? Can you support me with any code or guide?
في الثلاثاء، 9 مايو 2023 في 7:02 م تمت كتابة ما يلي بواسطة Yun Chang <
@.***>:

You can align the trajectories with the ground truth trajectories given
and use the resulting transform to transform your constructed map.
—
Reply to this email directly, view it on GitHub
https://github.com/MIT-SPARK/Kimera-Multi-Data/issues/4#issuecomment-1540462438,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AZHQ4Z3SY5RTY2RYS5MHVDLXFJTC5ANCNFSM6AAAAAAXRSCNSE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Apologies, I just re-read your question:

Hi I used kimera_multi dataset to implement MR-SLAM, but i don't know the starting coordinates to start running the dataset so i start all at origin coordinate (0,0,0) at rviz, this problem causes no overlap area between the trajectories or many wrong overlapped area. The final constructed map is not matched with the groundtruth map, so how can i resolve this problem?

I think this is more of a fundamental problem with the MR-SLAM algorithm. I would recommend you to check out our multi-robot SLAM system, Kimera-Multi. We are able to deal with scenarios without initial calibrations on locations.
https://github.com/MIT-SPARK/Kimera-Multi
Closing this thread now because the issue is irrelevant to the datasets.


🔔 [Request]: Add Resend White icon

🔎 Information:

Title: Resend White
Category: Software
Source (.svg): https://resend.com/static/brand/resend-icon-white.svg
Website: https://resend.com/

📝 Checklist:

[x] I have permission to use this logo.
[x] The link I have provided is optimized for web use.
[x] The size of the SVG is less than 20kb.

Ready 😊


Pass new translateX value through SwipeRow onRowOpen.

I've added the toValue as a param for onRowOpen function you can pass as a prop to SwipeRow when using it on it's own, which was my initial use case and this works perfectly :)
I'm not sure about how to go about adding it to the SwipeListView though? The toValue is calculated within the SwipeRow component and can't be accessed by the SwipeListView.

@CJStroud awesome! Can you do me a favor and just add this to the Readme so other people know to use it as well. Also if you want to give it a shot to pass it through to the SwipeListView you could change these lines:
https://github.com/jemise111/react-native-swipe-list-view/blob/master/components/SwipeListView.js#L78
and
https://github.com/jemise111/react-native-swipe-list-view/blob/master/components/SwipeListView.js#L89
from
onRowOpen={ _ => this.onRowOpen(secId, rowId, this._rows) }
to something like
`onRowOpen={ translateX => this.onRowOpen(secId, rowId, this._rows, translateX) }
and test it out. I think that might do the trick.
But at the very least just add some notes to the Readme and I'll be happy to merge this in, thanks!

@CJStroud Going to merge this in so I can close your open issue but have a look at my previous comment, it would be awesome if you could try to make those changes, thanks!

fixes #73

@jemise111 This is mentioned as being in the 0.3.2 release, however checking the source out this doesn't seem to have been merged: https://github.com/jemise111/react-native-swipe-list-view/blob/master/components/SwipeRow.js#L189
Any chance we can get this merged and released?

@jdmunro Wow I mean to close the issue but I closed the PR by accident! Good find, thanks for the heads up. I'll release 0.3.3 in a few min and it'll be there, thanks!

No worries! Thanks, I'll take a look 👍

Thanks this is all sorted now :)


Support account switching

This may mean switching to XHR-based OAuth, or allowing for "auto-login-via-Chrome mode" and "manually-login-from-any-account mode".

UI Note: with account icon in the menu's header, native apps support swiping left to change between logged-in accounts (Hangouts Android, for instance)


[CN DataTimeV2]Fix Bug in“早”,“晚”and“到”.

Fix bug in #1414.
Modify DatePeriodDayRegexInChinese so it won't match blank string anymore. (It is really hard to find this bug. )
Add "早" into MorningTermList &"晚" into "EveningTermList". For example, now "七月五号晚" would be correctly extracted from "台风将于七月五号晚过境".
As for Festivals, it is not supported in Java, Javascript, and Python.

@FeifanLiu98 why not supported in Python? The original issue report is a python one, so ideally it should also be fixed in that platform unless there is a blocking issue for it.

Okay,  I will try to fix the bug in Python.


Performance problem after obfuscation

Hi, I'm working on a method that generates 3d surfaces by marching cubes.
The underlying data is generated by various 3d distance measurements which are accumulated into a javascript array.
Calculation times in firefox on i7 are shown below for various levels of obfuscation (and some use of :enable :disable comments in code)

Method
Time (s)

Unobfuscated
0.66

Default
7.75

High
7.80

Enable/Disable
4.0

So I'm seeing a > 10x decrease in performance which I can't really live with.
Inspection of generated code shows that code in the critical sections like this
    grid[pos] = d;
becomes something like
    this[a15_0x16af('0x0')][_0x941b7f] =  _0x5d67a9;
I could not see any options that would simplify the obfuscation of the grid array lookup.
Is there any way to change the obfuscation settings that would help improve performance here?
Thanks

Hi. Use conditional comments to exclude parts of your code from obfuscation
https://github.com/javascript-obfuscator/javascript-obfuscator#conditional-comments

Did it help?

I used conditional comments in some places and see some improvements but still leaves it nearly 10x slower, and its not practical to catch all the places I need.
I would like obfuscation to provide the software as part of a software evaluation without fully exposing the code.
I was hoping for a simpler but obviously less effective method, such as just variable mangling without the function and dictionary lookup steps.
I will check the reservedStrings suggestion.
Thanks

Disable all options like: stringArray

OK, I added a couple of variables to the reservedNames list (e.g. gr in the example above) and got most of the performance back.
Unobfuscated 0.66s now 1.1s, which is still usable.
Thanks for your help and great software!

Nice!


Support for mutiple languages and pre failing

In some languages you can write code in some other language to enhace functionality, i.e. asm blocks in ANSI C, Java code in Matlab code, and HTML markup in Java, HTML in markdown, etc.
Is it possible to have more then one language at the same time recognized with for example the tag ?
BTW, sometimes the
 tag let us write formatted html if we use the html tag.
Please run the example and see how it does some crazy things.

b2 = new JButton("middle button", middleButtonIcon);
b2.setFont(font);
b2.setForeground(new Color(0xffffdd));
b3 = new JButton("Enable
"
             + "middle button",
             rightButtonIcon);
  b1 = new JButton("Disable
"
             + "middle button",
             leftButtonIcon);
    Font font = b1.getFont().deriveFont(Font.PLAIN);
    b1.setFont(font);
    b3.setFont(font);
    }

No, there is no way to provide multiple languages on a single code block.
But some languages already allow to embed other languages inside themselves, with the inside feature. So the inclusions you mention could probably be added in the grammars. Take a look at the CSS, JS, HAML, Jade or ActionScript components for examples.
Regarding the
 tag that interpretes HTML code, yes, this is its normal behaviour.
To highlight the code you provided with Prism, you need to write it like this:

b2 = new JButton("middle button", middleButtonIcon);
b2.setFont(font);
b2.setForeground(new Color(0xffffdd));
b3 = new JButton("<html><center><b><u>E</u>nable</b><br>"
             + "<font color=#ffffdd>middle button</font>",
             rightButtonIcon);
  b1 = new JButton("<html><center><b><u>D</u>isable</b><br>"
             + "<font color=#ffffdd>middle button</font>",
             leftButtonIcon);
    Font font = b1.getFont().deriveFont(Font.PLAIN);
    b1.setFont(font);
    b3.setFont(font);
    }

I don't see any reason to keep this issue open. We won't add support for multiple languages on a single block. Language inclusion should be handled inside the components themselves.


invalid IPv6 address in resolver, scoped address, zone index

I have made a Comment on a different Bug Report #149 but noticed later, that my problem was different to the one described there. That is why I made this separate Bug report.
The Problem
I am running this Docker Image on my Rapsberry Pi Home server. When I try to start the Container, it is marked as 'unhealthy', the web-interface will not start and the following error is repeatedly being logged:
nginx: [emerg] invalid IPv6 address in resolver "[fe80::abd:43ff:feca:7350%2]" in /etc/nginx/conf.d/include/resolvers.conf:1
finish: applet not found

Cause
When the Container is beeing started it will copy /etc/resolv.conf from the host machine (outside of the container) into the Container to the same location. The Content of that file will then be converted by the script located at  nginx-proxy-manager/docker/rootfs/etc/services.d/nginx/run of this repository in the following line:
# Dynamically generate resolvers file, if resolver is IPv6, enclose in `[]`
# thanks @tfmm
echo resolver "$(awk 'BEGIN{ORS=" "} $1=="nameserver" {print ($2 ~ ":")? "["$2"]": $2}' /etc/resolv.conf);" > /etc/nginx/conf.d/include/resolvers.conf

The output will then be written into /etc/nginx/conf.d/include/resolvers.conf. This file is read by nginx which will throw the error.
/etc/resolv.conf:
nameserver <IP_ADDRESS>
nameserver fd00::3a10:d5ff:fe77:c05d
nameserver fe80::abd:43ff:feca:7350%2
search jonas.local

/etc/nginx/conf.d/include/resolvers.conf:
resolver <IP_ADDRESS> [fd00::3a10:d5ff:fe77:c05d] [fe80::abd:43ff:feca:7350%2] ;
Note: fd00::3a10:d5ff:fe77:c05d is the IP of the Router which is connected to the Internet and directly to my Server via ethernet. fe80::abd:43ff:feca:7350 is the IP of a second Router which is only responsible for the WLAN in my Network
The Error emerges, because one of the IPs is ending with the  zone index %2.
How  to reproduce
Unfortunately I don't have any knowledge in this area and can't give an explanation on how to reproduce this behavior other than adding the IP address with zone index manually to the resolver of the host-machine.
As stated before I have two Routers in my Network which might be the root cause of the Problem.
The Fix
A simple fix would be to edit the line which converts /etc/resolv.conf to /etc/nginx/conf.d/include/resolvers.conf so, that it will remove the zone index or the entire scoped IP. Unfortunately I am unable to find if nginx should handle these scoped IPs or if these IPs should even exist in /etc/resolv.conf. So this may fix a behavior which shouldn't even exist.
Setup
Device: Raspberry Pi 4B
Operating System: Raspbian GNU/Linux 10 (buster)
Docker:
Client: Docker Engine - Community
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:19:30 2021
 OS/Arch:           linux/arm
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:17:16 2021
  OS/Arch:          linux/arm
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Container: jc21/nginx-proxy-manager:latest
Thank you for the Help!

Thanks for the detailed report. I don't see why we can't include that second address in the resolvers. Shouldn't be too hard to fix the regex.

same error
nginx: [emerg] invalid IPv6 address in resolver "[fe80::46d9:e7ff:fe95:e3db%br0]" in /etc/nginx/nginx.conf:13


teleop drive

the robot shall respond to joystick or controller input for driving.
the robot shall map joystick or controller input to the drive using tank or cheesy drive (TBD)

closed


Investigate in supporting RackN and/or MaaS as provider

Both metal provisioning technologies shall be compared and the effort on implement a provider estimated. Prototype implementations on https://rebar.digital/ already exist at https://github.com/galthaus/machine-controller/tree/drp2 .

[ ] Create feature table
[ ] Estimate RackN
[ ] Estimate MaaS

Timebox to 4 hours

Currently Metal³ (https://github.com/metal3-io) is investigated. It's the one chosen as bare metal provider for the Cluster API.

Current status: talk to Sebastian about which provider to work on.


Create html folder

Create a html folder & put every html files under it. It will look better :)

@Udbhav18 what is this card_number?


Try porting some HOWTOs to Linen under "Flax Patterns"

The old HOWTO system aimed to demonstrate how to achieve common training procedures. We can probably do something much simpler under Flax Patterns as simple markdown files.
We can probably find a way to port all of our old HOWTOs (while thinking carefully and reformatting them appropriately, and adding text blocks to help explain)

Split into issues:
#785
#787
#786
#784
#783


fix objc inference in swift 4

In swift 4, swift subclasses of objective-c classes don't export members by default, see https://help.apple.com/xcode/mac/current/#/deve838b19a1 and http://evgenii.com/blog/disabling-swift3-objc-inference-in-xcode9/
Alternatively, @objc could be added to all members which should be exported.
I'm not sure if other classes like SideMenuTransition should also be adapted, but I didn't need it.

@herrernst thank you for your contribution.
After reviewing your code, I am declining to merge this change for the following reasons:

You can successfully access properties by creating your own SideMenuManager instance instead of using the default instance, e.g.:

    SideMenuManager *manager = [[SideMenuManager alloc] init]
    manager.menuWidth = 0;

Per Apple's documentation:

When a Swift class introduces many new methods or properties that require behavior from the Objective-C runtime, use the @objcMembers attribute in the declaration of that class. Applying the @objcMembers attribute to a class implicitly adds the @ objc attribute to all of its Objective-C compatible members. Because applying the @ objc attribute can increase the compiled size of an app and adversely affect performance, only apply the @objcMembers attribute on declarations when each member needs to have the @ objc attribute applied.

It appears the problem is actually being able to access the default instance. Instead, I will add a defaultManager property for objective-C support.

manager.menuPresentMode = MenuPresentModeMenuSlideIn;
manager.menuAnimationFadeStrength = 0.4;
manager.menuShadowRadius = 3;
manager.menuShadowOpacity = 0.3;
manager.menuWidth = [UIScreen mainScreen].bounds.size.width * 0.7;

those properties are still not accesible when creating our own managers.
Adding @objcMembers like this pull request does, makes everything work just fine.

@jlubeck Something doesn't add up... I just tested this on an objective-C project of mine moments ago... I was able to access all of the manager properties on a custom instance without issue... Xcode 9, latest SideMenu version.

Mmm, something definitely doesn't add up, I just tried again and now it works! So weird...
Maybe it was a caching issue from when I was getting errors???
No idea, but yeah, your suggestion works. Thanks!

Thanks for your time, @jonkykong.
Unfortunately, I cannot confirm your research. When I create a new project (with "Swift Language Version" set to 4 and "Swift 3 @objc Inference" left on default), I can neither access [SideMenuManager default] nor the properties on a new SideMenuManager instance. I don't think adding an @objc defaultManager will help because the instance properties still wouldn't be accessible. This seems consistent to the documentation I've read and linked in the first post: no new Swift properties in a subclass of an Objective-C class are available in Objective-C by default.
This is also apparent when you look at the generated Objective-C Bridging Header "SideMenu-Swift.h" (to be sure, I always clean the project before rebuilding):

(only the overriden init and the explicitly marked enums are exported)
I don't see any alternative to adding @objcMembers to the class or @objc to each property which should be available in Objective-C.
I wouldn't exaggerate this note from Apple:

"Because applying the @ objc attribute can increase the compiled size of an app and adversely affect performance"

I think it means that property access passes the Objective-C runtime ("performance"), but that also was the case with SideMenu in Swift 3; and maybe unused Swift methods could be optimized away if not exported for Objective-C ("compiled size"), but I think that's only some few bytes.

Again, something isn't adding up here.
@herrernst please make sure you're running the latest version of SideMenu. Clear your DerivedData and clean your project. I have no issues with a dummy Objective-C project I created that uses SideMenu.
It won't be necessary to add @ objc to a defaultManager property because the issue isn't with the declaration, but the name default.

Sorry, I still don't get it to work.
I've tried a new Objective-C project in Xcode 9.1 with both CocoaPods (which uses 3.1.4) and Carthage, and I never can access the properties from Objective-C.
You say it works for your dummy Objective-C project. How have you created that project? Mind sharing it?
Thank you again!

SideMenuObjectiveC.zip

I see why it's working in your project: In the SideMenu pod, Swift version is set to 3.2, so it uses the old inference rules:

(I don't know why CocoaPods did set it to 3.2, when I set up a new Objective-C project, Swift version was not set, and I set it to 4.0, assuming SideMenu was adapted to work with 4.0.)
When I change Swift version to 4.0 here, I get the the error about missing properties.

@herrernst Thank you for the follow-up. I can confirm this was the issue. I created this project in Swift 3, and assumed pod update would take care of this.
Despite this change, default is still inaccessible, so I will add a defaultManager property for access in objective-c to avoid having to create custom managers as a workaround.


Fix path normalization for patterns such as './/tsconfig.json'

I noticed this when trying to compile with the "-p" switch for the local folder, using "./" (i.e. "tsc -p ./").  The code appends "/tsconfig.json" to locate the file, which results in a path of ".//tsconfig.json".  The current normalization code splits this on "/" which results in an empty string in the array.  As it drops the leading "." (for current folder), when it rejoins ["","tsconfig.json"] with the separator this results in "/tsconfig.json", and it fails to find it at the root of the drive.  This fix drops the empty string parts caused by consecutive path separators, which is how most other path normalization code works.

The old code was also incorrectly normalizing a relative path such as "tests/cases/projects/ReferenceResolution//test.js" (when in the ReferenceResolution folder) to "/test.js" on a couple of projects, which the project runner then re-writes if it's not under the project output folder to something like "diskFile0.js".  Now the code correctly normalizes the path to "test.js" these files are emitted without the re-written name.  Updated the baselines to reflect this.

:+1:


add share sheet to action sheet and episode detail view

#77
I've added the share sheets, but you can't actually share anything yet (I think that's where #85 comes in)

Looks good, merge it


Fix api tests

Description
Refactored API tests, added a test for api/polygons.
Removed a trailing space in "prettierrc." (It caused problems with git on Windows)
Type of changes

[x] Bugfix
[ ] Chore
[x] New Feature

Testing

[ ] I added automated tests
[x] I think tests are unnecessary

Hi Mack, I rebased the branch. Let me know if there are any comments.

@mackcooper1408 Hi Mack, i deleted the duplicate files :)


Libmockspotify support

These commits transfer all the mocking logic to the libmockspotify project. Nothing new otherwise.
They should be merged sometime after https://github.com/mopidy/libmockspotify/pull/3 has been merged into libmockspotify. Also, it will break the current CI setup :-).

We should probably add an empty changelog to the libmockspotify project and tag a release before we merge this. I'm all for doing it tonight :-)

As of now, all the tests are passing with the new libmockspotify (https://github.com/mopidy/libmockspotify/pull/4). This should be merged after the pull request from libmockspotify has been merged.

Lovely! :-)
Just waiting on mopidy/libmockspotify#4 and a libmockspotify release then.

I installed libmockspotify 0.1 from APT:
sudo apt-get install libmockspotify-dev

Then I merged this pull request into the develop branch and ran all of pyspotify's tests:
rm -rf build && python setup.py build && PYTHONPATH=build/lib.linux-x86_64-2.7/ nosetests

All 98 tests pass.


Move algorithms to tag_fallback_invoke

Proposed Changes
Move algorithms to tag_fallback_invoke
Any background context you want to provide?
Issue: https://github.com/STEllAR-GROUP/hpx/issues/5204

Can one of the admins verify this patch?

@toktarev any  reason you closed this PR?

@hkaiser I am sorry, I see some conflict with master
Will have to fix it and re-open

@hkaiser
I am sorry again for this confusion (I see that you've made some work with labels here).

Feel free to leave it open. Just rebase against master, that should take care of the conflicts.

The problem is that I've already created the same one (https://github.com/STEllAR-GROUP/hpx/pull/5288).
And @msimberg  made there some work (review).

ReOpen option is disabled here


Should sos_targets["name"] slice groups as well?

Running
sos run test B

on workflow
[A]
input: for_each=dict(i=range(5))
output: a=f'a_{i}.txt', b=f'b_{i}.txt'
_output.touch

[B]
input: named_output('a')
print(_input)

would yield
a_0.txt
a_1.txt
a_2.txt
a_3.txt
a_4.txt

because named_output slices not only the targets, but also groups of output_from('A') so that named_output('A') would also have groups.
The same output would be generated for
[A]
input: for_each=dict(i=range(5))
output: a=f'a_{i}.txt', b=f'b_{i}.txt'
_output.touch

[B]
input: output_from('A')
print(_input['a'])

because output_from('A') has groups.
However, output from the following workflow using output_from('A')['a']
[A]
input: for_each=dict(i=range(5))
output: a=f'a_{i}.txt', b=f'b_{i}.txt'
_output.touch

[B]
input: output_from('A')['a']
print(_input)

is
a_0.txt a_1.txt a_2.txt a_3.txt a_4.txt

because ['a]slices the targets and produce asos_target` without groups.
Should the slice operation always slices groups?

I think so! because output_from('A') will output groups by default, it is rather weird if the slices do not.

ok, now the last example shows the same result.
Note that if we would like to regroup, we will have to regroup from output_from, as in
[A]
input: for_each=dict(i=range(5))
output: a=f'a_{i}.txt', b=f'b_{i}.txt'
_output.touch()

[B]
input: output_from('A', group_by='all')['a']
print(_input)


Explaining the models

I am testing this model for a churn task in Kaggle. I have been running into some issues trying to plug it into GNN explainers, mainly stemming from the architecture difference as the model includes embedding steps with the help of torch-frame. Does someone have any recommendation on how I can modify this see I can test some GNN explainers on the relations data? Much Appreciated

@yiweny @zechengz @XinweiHe does any of you have experience or advice regarding this?

Which embedding step from torch-frame you use?


GeoStatsBase depending on package ReferenceFrameRotations

Hi guys,
reporting that after cloning the master branch and trying to use GeoStatsBase, I'm getting this error:
julia> using GeoStatsBase
[ Info: Precompiling GeoStatsBase [323cb8eb-fbf6-51c0-afd0-f8fba70507b2]
ERROR: LoadError: ArgumentError: Package ReferenceFrameRotations [74f56ac7-18b3-5285-802d-d4bd4f104033] is required but does not seem to be installed:
 - Run `Pkg.instantiate()` to install all recorded dependencies.

Regards

I think you didn't update the environment locally. You can try to ] resolve or ] up to fix it.


error in installation

I built octree in your docker: docker pull wangps/ocnn:pytorch-1.9.0, but the error occurred. here is build log
I don't know why. Hope for you help.
and I want to know whether the ocnn can only be built in ubuntu? When I run setup.py in Win10, there are so many errors.
(base) root@(docker)67034be3fb5a:/workspace/ocnn-pytorch
$ python setup.py install --build_octree
No CUDA runtime is found, using CUDA_HOME='/usr/local/cuda'
mkdir /workspace/octree/build && cd /workspace/octree/build && cmake .. -DABI=ON -DKEY64=ON  && cmake --build . --config Release && ./octree_test
-- octree: USE_CUDA
-- The CUDA compiler identification is NVIDIA 10.2.89
-- The CXX compiler identification is GNU 7.5.0
-- The C compiler identification is GNU 7.5.0
-- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc
-- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc -- works
-- Detecting CUDA compiler ABI info
-- Detecting CUDA compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- octree: CMAKE_CUDA_STANDARD=11
-- octree: _GLIBCXX_USE_CXX11_ABI=0
-- octree: USE_MINIBALL
-- octree: KEY64
-- Found PythonInterp: /opt/conda/bin/python (found version "3.7.10")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Configuring done
-- Generating done
-- Build files have been written to: /workspace/octree/build
Scanning dependencies of target octree_lib
[  1%] Building CXX object CMakeFiles/octree_lib.dir/octree/contour.cpp.o
[  2%] Building CXX object CMakeFiles/octree_lib.dir/octree/filenames.cpp.o
[  3%] Building CXX object CMakeFiles/octree_lib.dir/octree/marching_cube.cpp.o
[  4%] Building CXX object CMakeFiles/octree_lib.dir/octree/marching_cube_table.cpp.o
[  6%] Building CXX object CMakeFiles/octree_lib.dir/octree/math_functions.cpp.o
[  7%] Building CXX object CMakeFiles/octree_lib.dir/octree/merge_octrees.cpp.o
[  8%] Building CXX object CMakeFiles/octree_lib.dir/octree/mesh.cpp.o
[  9%] Building CXX object CMakeFiles/octree_lib.dir/octree/octree.cpp.o
[ 10%] Building CXX object CMakeFiles/octree_lib.dir/octree/octree_conv.cpp.o
[ 12%] Building CXX object CMakeFiles/octree_lib.dir/octree/octree_info.cpp.o
[ 13%] Building CXX object CMakeFiles/octree_lib.dir/octree/octree_nn.cpp.o
[ 14%] Building CXX object CMakeFiles/octree_lib.dir/octree/octree_parser.cpp.o
[ 15%] Building CXX object CMakeFiles/octree_lib.dir/octree/octree_samples.cpp.o
[ 16%] Building CXX object CMakeFiles/octree_lib.dir/octree/octree_value.cpp.o
[ 18%] Building CXX object CMakeFiles/octree_lib.dir/octree/points.cpp.o
[ 19%] Building CXX object CMakeFiles/octree_lib.dir/octree/points_info.cpp.o
[ 20%] Building CXX object CMakeFiles/octree_lib.dir/octree/points_parser.cpp.o
[ 21%] Building CXX object CMakeFiles/octree_lib.dir/octree/simplify_points.cpp.o
[ 22%] Building CXX object CMakeFiles/octree_lib.dir/octree/transform_octree.cpp.o
[ 24%] Building CXX object CMakeFiles/octree_lib.dir/octree/transform_points.cpp.o
[ 25%] Building CUDA object CMakeFiles/octree_lib.dir/octree/octree_nn.cu.o
[ 26%] Building CUDA object CMakeFiles/octree_lib.dir/octree/octree_parser.cu.o
[ 27%] Linking CXX static library liboctree_lib.a
[ 27%] Built target octree_lib
Scanning dependencies of target upgrade_points
[ 28%] Building CXX object CMakeFiles/upgrade_points.dir/tools/upgrade_points.cpp.o
[ 30%] Linking CXX executable upgrade_points
[ 30%] Built target upgrade_points
Scanning dependencies of target gtest
[ 31%] Building CXX object external/octree-ext/googletest/googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
[ 32%] Linking CXX static library ../../../../lib/libgtest.a
[ 32%] Built target gtest
Scanning dependencies of target gtest_main
[ 33%] Building CXX object external/octree-ext/googletest/googletest/CMakeFiles/gtest_main.dir/src/gtest_main.cc.o
[ 34%] Linking CXX static library ../../../../lib/libgtest_main.a
[ 34%] Built target gtest_main
Scanning dependencies of target octree_test
[ 36%] Building CXX object CMakeFiles/octree_test.dir/test/test_octree.cpp.o
[ 37%] Building CXX object CMakeFiles/octree_test.dir/test/test_octree_nn.cpp.o
[ 38%] Building CXX object CMakeFiles/octree_test.dir/test/test_util.cpp.o
[ 39%] Linking CXX executable octree_test
[ 39%] Built target octree_test
Scanning dependencies of target upgrade_octree
[ 40%] Building CXX object CMakeFiles/upgrade_octree.dir/tools/upgrade_octree.cpp.o
[ 42%] Linking CXX executable upgrade_octree
[ 42%] Built target upgrade_octree
Scanning dependencies of target transform_points
[ 43%] Building CXX object CMakeFiles/transform_points.dir/tools/transform_points.cpp.o
[ 44%] Linking CXX executable transform_points
[ 44%] Built target transform_points
Scanning dependencies of target simplify_points
[ 45%] Building CXX object CMakeFiles/simplify_points.dir/tools/simplify_points.cpp.o
[ 46%] Linking CXX executable simplify_points
[ 46%] Built target simplify_points
Scanning dependencies of target points_noise
[ 48%] Building CXX object CMakeFiles/points_noise.dir/tools/points_noise.cpp.o
[ 49%] Linking CXX executable points_noise
[ 49%] Built target points_noise
Scanning dependencies of target check_octree
[ 50%] Building CXX object CMakeFiles/check_octree.dir/tools/check_octree.cpp.o
[ 51%] Linking CXX executable check_octree
[ 51%] Built target check_octree
Scanning dependencies of target chamfer_distance
[ 53%] Building CXX object CMakeFiles/chamfer_distance.dir/tools/chamfer_distance.cpp.o
[ 54%] Linking CXX executable chamfer_distance
[ 54%] Built target chamfer_distance
Scanning dependencies of target ply2points
[ 55%] Building CXX object CMakeFiles/ply2points.dir/tools/ply2points.cpp.o
[ 56%] Linking CXX executable ply2points
[ 56%] Built target ply2points
Scanning dependencies of target octree
[ 57%] Building CXX object CMakeFiles/octree.dir/tools/build_octree.cpp.o
[ 59%] Linking CXX executable octree
[ 59%] Built target octree
Scanning dependencies of target clip_points
[ 60%] Building CXX object CMakeFiles/clip_points.dir/tools/clip_points.cpp.o
[ 61%] Linking CXX executable clip_points
[ 61%] Built target clip_points
Scanning dependencies of target adaptive_octree
[ 62%] Building CXX object CMakeFiles/adaptive_octree.dir/tools/adaptive_octree.cpp.o
[ 63%] Linking CXX executable adaptive_octree
[ 63%] Built target adaptive_octree
Scanning dependencies of target rply
[ 65%] Building C object CMakeFiles/rply.dir/external/octree-ext/rply-1.1.4/rply.c.o
[ 66%] Linking C static library librply.a
[ 66%] Built target rply
Scanning dependencies of target octree2mesh
[ 67%] Building CXX object CMakeFiles/octree2mesh.dir/tools/octree2mesh.cpp.o
[ 68%] Linking CXX executable octree2mesh
[ 68%] Built target octree2mesh
Scanning dependencies of target merge_octree
[ 69%] Building CXX object CMakeFiles/merge_octree.dir/tools/merge_octree.cpp.o
[ 71%] Linking CXX executable merge_octree
[ 71%] Built target merge_octree
Scanning dependencies of target custom_data
[ 72%] Building CXX object CMakeFiles/custom_data.dir/tools/custom_data.cpp.o
[ 73%] Linking CXX executable custom_data
[ 73%] Built target custom_data
Scanning dependencies of target octree2pts_suncg
[ 74%] Building CXX object CMakeFiles/octree2pts_suncg.dir/tools/octree2pts_suncg.cpp.o
[ 75%] Linking CXX executable octree2pts_suncg
[ 75%] Built target octree2pts_suncg
Scanning dependencies of target octree_samples
[ 77%] Building CXX object CMakeFiles/octree_samples.dir/tools/octree_samples.cpp.o
[ 78%] Linking CXX executable octree_samples
[ 78%] Built target octree_samples
Scanning dependencies of target octree_zbuffer
[ 79%] Building CXX object CMakeFiles/octree_zbuffer.dir/tools/octree_zbuffer.cpp.o
[ 80%] Linking CXX executable octree_zbuffer
[ 80%] Built target octree_zbuffer
Scanning dependencies of target bbox
[ 81%] Building CXX object CMakeFiles/bbox.dir/tools/bbox.cpp.o
[ 83%] Linking CXX executable bbox
[ 83%] Built target bbox
Scanning dependencies of target mesh2points
[ 84%] Building CXX object CMakeFiles/mesh2points.dir/tools/mesh2points.cpp.o
[ 85%] Linking CXX executable mesh2points
[ 85%] Built target mesh2points
Scanning dependencies of target octree2points
[ 86%] Building CXX object CMakeFiles/octree2points.dir/tools/octree2points.cpp.o
[ 87%] Linking CXX executable octree2points
[ 87%] Built target octree2points
Scanning dependencies of target octree_bbox
[ 89%] Building CXX object CMakeFiles/octree_bbox.dir/tools/octree_bbox.cpp.o
[ 90%] Linking CXX executable octree_bbox
[ 90%] Built target octree_bbox
Scanning dependencies of target octree_prune
[ 91%] Building CXX object CMakeFiles/octree_prune.dir/tools/octree_prune.cpp.o
[ 92%] Linking CXX executable octree_prune
[ 92%] Built target octree_prune
Scanning dependencies of target octree_dropout
[ 93%] Building CXX object CMakeFiles/octree_dropout.dir/tools/octree_dropout.cpp.o
[ 95%] Linking CXX executable octree_dropout
[ 95%] Built target octree_dropout
Scanning dependencies of target points2ply
[ 96%] Building CXX object CMakeFiles/points2ply.dir/tools/points2ply.cpp.o
[ 97%] Linking CXX executable points2ply
[ 97%] Built target points2ply
Scanning dependencies of target play_ground
[ 98%] Building CXX object CMakeFiles/play_ground.dir/tools/play_ground.cpp.o
[100%] Linking CXX executable play_ground
[100%] Built target play_ground
Running main() from /workspace/octree/external/octree-ext/googletest/googletest/src/gtest_main.cc
[==========] Running 12 tests from 7 test suites.
[----------] Global test environment set-up.
[----------] 2 tests from OctreeTest
[ RUN      ] OctreeTest.TestOctreeBuild
[       OK ] OctreeTest.TestOctreeBuild (0 ms)
[ RUN      ] OctreeTest.TestOctreeTrim
[       OK ] OctreeTest.TestOctreeTrim (0 ms)
[----------] 2 tests from OctreeTest (0 ms total)
[----------] 1 test from VecResizeTest
[ RUN      ] VecResizeTest.TestVecResize
[       OK ] VecResizeTest.TestVecResize (0 ms)
[----------] 1 test from VecResizeTest (0 ms total)
[----------] 1 test from BiliearNeigh
[ RUN      ] BiliearNeigh.TestBiliearNeigh
[       OK ] BiliearNeigh.TestBiliearNeigh (0 ms)
[----------] 1 test from BiliearNeigh (1 ms total)
[----------] 1 test from Coord2xyzTest
[ RUN      ] Coord2xyzTest.TestCoord2xyz
[       OK ] Coord2xyzTest.TestCoord2xyz (0 ms)
[----------] 1 test from Coord2xyzTest (0 ms total)
[----------] 3 tests from UtilTest
[ RUN      ] UtilTest.TestExtractPath
[       OK ] UtilTest.TestExtractPath (0 ms)
[ RUN      ] UtilTest.TestExtractFilename
[       OK ] UtilTest.TestExtractFilename (0 ms)
[ RUN      ] UtilTest.TestExtractSuffix
[       OK ] UtilTest.TestExtractSuffix (0 ms)
[----------] 3 tests from UtilTest (0 ms total)
[----------] 2 tests from MeshTest
[ RUN      ] MeshTest.TestFaceCenter
[       OK ] MeshTest.TestFaceCenter (0 ms)
[ RUN      ] MeshTest.TestFaceNormal
[       OK ] MeshTest.TestFaceNormal (0 ms)
[----------] 2 tests from MeshTest (0 ms total)
[----------] 2 tests from MathTest
[ RUN      ] MathTest.TestRotMatrix1
[       OK ] MathTest.TestRotMatrix1 (0 ms)
[ RUN      ] MathTest.TestRotMatrix2
[       OK ] MathTest.TestRotMatrix2 (0 ms)
[----------] 2 tests from MathTest (1 ms total)
[----------] Global test environment tear-down
[==========] 12 tests from 7 test suites ran. (2 ms total)
[  PASSED  ] 12 tests.
running install
running bdist_egg
running egg_info
writing ocnn.egg-info/PKG-INFO
writing dependency_links to ocnn.egg-info/dependency_links.txt
writing requirements to ocnn.egg-info/requires.txt
writing top-level names to ocnn.egg-info/top_level.txt
reading manifest file 'ocnn.egg-info/SOURCES.txt'
writing manifest file 'ocnn.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
running build_ext
building 'ocnn.nn' extension
Emitting ninja build file /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/build.ninja...
Compiling objects...
Allowing ninja to set a default number of workers... (overridable by setting the environment variable MAX_JOBS=N)
ninja: no work to do.
g++ -pthread -shared -B /opt/conda/compiler_compat -L/opt/conda/lib -Wl,-rpath=/opt/conda/lib -Wl,--no-as-needed -Wl,--sysroot=/ /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree2col.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/transform_points.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/points_property.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_key.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_batch.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_grow.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_align.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/point2octree.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_pool.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/transform_octree.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_property.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_pad.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_conv.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/pybind.o /workspace/ocnn-pytorch/build/temp.linux-x86_64-3.7/./cpp/octree_samples.o -L/workspace/octree/build -L/opt/conda/lib/python3.7/site-packages/torch/lib -L/usr/local/cuda/lib64 -loctree_lib -lcublas -lc10 -ltorch -ltorch_cpu -ltorch_python -lcudart -lc10_cuda -ltorch_cuda -o build/lib.linux-x86_64-3.7/ocnn/nn.cpython-37m-x86_64-linux-gnu.so
creating build/bdist.linux-x86_64/egg
creating build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/transforms.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/octree2voxel.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/nn.cpython-37m-x86_64-linux-gnu.so -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/octree_conv.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/octree2col.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/ounet.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/octree_interp.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/unet.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/octree_pool.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/resnet.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/lenet.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/octree_pad.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/segnet.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/modules.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/mlp.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/octree_align.py -> build/bdist.linux-x86_64/egg/ocnn
copying build/lib.linux-x86_64-3.7/ocnn/init.py -> build/bdist.linux-x86_64/egg/ocnn
byte-compiling build/bdist.linux-x86_64/egg/ocnn/transforms.py to transforms.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/octree2voxel.py to octree2voxel.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/octree_conv.py to octree_conv.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/octree2col.py to octree2col.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/ounet.py to ounet.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/octree_interp.py to octree_interp.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/unet.py to unet.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/octree_pool.py to octree_pool.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/resnet.py to resnet.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/lenet.py to lenet.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/octree_pad.py to octree_pad.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/segnet.py to segnet.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/modules.py to modules.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/mlp.py to mlp.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/octree_align.py to octree_align.cpython-37.pyc
byte-compiling build/bdist.linux-x86_64/egg/ocnn/init.py to init.cpython-37.pyc
creating stub loader for ocnn/nn.cpython-37m-x86_64-linux-gnu.so
byte-compiling build/bdist.linux-x86_64/egg/ocnn/nn.py to nn.cpython-37.pyc
creating build/bdist.linux-x86_64/egg/EGG-INFO
copying ocnn.egg-info/PKG-INFO -> build/bdist.linux-x86_64/egg/EGG-INFO
copying ocnn.egg-info/SOURCES.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying ocnn.egg-info/dependency_links.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying ocnn.egg-info/requires.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
copying ocnn.egg-info/top_level.txt -> build/bdist.linux-x86_64/egg/EGG-INFO
writing build/bdist.linux-x86_64/egg/EGG-INFO/native_libs.txt
zip_safe flag not set; analyzing archive contents...
ocnn.pycache.nn.cpython-37: module references file
creating 'dist/ocnn-1.0.0-py3.7-linux-x86_64.egg' and adding 'build/bdist.linux-x86_64/egg' to it
removing 'build/bdist.linux-x86_64/egg' (and everything under it)
Processing ocnn-1.0.0-py3.7-linux-x86_64.egg
removing '/opt/conda/lib/python3.7/site-packages/ocnn-1.0.0-py3.7-linux-x86_64.egg' (and everything under it)
creating /opt/conda/lib/python3.7/site-packages/ocnn-1.0.0-py3.7-linux-x86_64.egg
Extracting ocnn-1.0.0-py3.7-linux-x86_64.egg to /opt/conda/lib/python3.7/site-packages
ocnn 1.0.0 is already the active version in easy-install.pth
Installed /opt/conda/lib/python3.7/site-packages/ocnn-1.0.0-py3.7-linux-x86_64.egg
Processing dependencies for ocnn==1.0.0
Searching for numpy==1.20.2
Best match: numpy 1.20.2
Adding numpy 1.20.2 to easy-install.pth file
Installing f2py script to /opt/conda/bin
Installing f2py3 script to /opt/conda/bin
Installing f2py3.7 script to /opt/conda/bin
Using /opt/conda/lib/python3.7/site-packages
Searching for torch==1.9.0
Best match: torch 1.9.0
Adding torch 1.9.0 to easy-install.pth file
Installing convert-caffe2-to-onnx script to /opt/conda/bin
Installing convert-onnx-to-caffe2 script to /opt/conda/bin
Using /opt/conda/lib/python3.7/site-packages
Searching for typing-extensions==<IP_ADDRESS>
Best match: typing-extensions <IP_ADDRESS>
Adding typing-extensions <IP_ADDRESS> to easy-install.pth file
Using /opt/conda/lib/python3.7/site-packages
Finished processing dependencies for ocnn==1.0.0
(base) root@(docker)67034be3fb5a:/workspace/ocnn-pytorch
$ python -W ignore test/test_all.py -v
test_backward (test_octree2col.Octree2ColTest) ... ERROR
test_forward (test_octree2col.Octree2ColTest) ...
It's stuck in test_forward for a long time.

fixed

@zhexinXie May I ask how you fix the test_backward ERROR and stuck in test_forward?


API version change resulting in bad requests responses (400)?

Hello!
Thank you for your hard work in developing this app. We leverage this quite a bit!
I've been running into an issue with the Reservation Recommendation input. Based on Microsoft documentation, I believe the API version has been updated to 2023-05-01?
Based on the code below, it looks like the API version is hard-coded with an old version, which I believe could be the issue we are experiencing, since it references version 2019-05-01 (we stopped ingesting these logs at midnight today, May 1st, so I'm fairly confident this is the cause).
https://github.com/splunk/splunk-add-on-microsoft-azure/blob/6393fc6f487e37d8098eab959c90d1fa4742b3bc/package/bin/azure_reservation_recommendation.py#L104
What would the likelihood be of this API version being updated? Would there be a rough estimate of a timeline?

Additionally, it does seem Microsoft will be retiring these older API versions


Update bumpalo to address RUSTSEC-2022-0078

Fixing: https://rustsec.org/advisories/RUSTSEC-2022-0078.html

Codecov Report

Merging #2744 (db0355c) into main (8058497) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2744   +/-   ##
=======================================
  Coverage   29.08%   29.08%
=======================================
  Files         321      321
  Lines       38454    38454
=======================================
  Hits        11185    11185
  Misses      27269    27269

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Use of unresolved identifier motionModalTransitionType

I'm currently in the Transition sample

I used the default .sh file to pod install. Turns out that the library is not the newest version so it couldn't find motionModalTransitionType. Solved by pod installing Material to 2.10.2

Maybe someone should fix that .sh file?

@harrison0723 Thank you! The Samples repo is getting a bit of an overhaul to match the documentation we are working on. I will review the .sh file :)

I have taken note of the install script. For now this issue can be closed as the updated version of Material and Motion address the issue. Thank you!


Remove usage of TS non-null-assertion by using

refs to identify the input compoentcomponent

no longer necessary


Asus C433T | Shyvana | Arch (based) Manjaro | HDMI + Headset = Y | Speakers = N

alsaucm.txt
aplay_l.txt
audio-debug.log
dmesg.txt
sku.txt

Update your kernel.

Sure enough. :-)