Use scene.pick to get GroundPrimitive and return wrong results

Sandcastle

Quick look showed that it works properly if only one row is generated.  Adding even one more (i <= 6) results in failure.

Quick look showed that it works properly if only one row is generated. Adding even one more (i <= 6) results in failure.

Yes, Now I get all pickedObjects through scene.drillPick, and then take the last one. I don't know if it's the right thing to do, or if there's a better way.

For more help:
With OrthographicFrustum, we can drillpick successfully.(only when camre.pitch equals to -90 degree).
sandcastle

Also reported in https://github.com/CesiumGS/cesium/issues/10863.

Hi, do you have a plan to fix the problem? @ggetz

@MeanYou There hasn't been any activity on this item recently.
If you'd like to add more information about your use case, that may help us prioritize.
If you are interesting in contributing, please let us know and we'd be happy to discuss implementation or review a PR.
Thanks!

I also encountered the same problem. When I created the GroundPrimitive, I found that its bounding box is a cube, but the Primitive is a sphere.


Recalculate tabSpacers with Dynamic Type

When dynamic type re-sizes the fonts, any calculated tab stops should also be re-calculated.

Working in feature/swift-first


Clicking code folding collapsed marker should expand it

Click a gutter triangle to collapse a block of code
Click the "↔" indicator that appears inline in the code

Result: nothing happens
Expected: in many other editors (though not all), clicking this indicator un-collapses the folded section

Clicking on the "↔" indicator does expand the folded code; but it doesn't seem to work in all the cases.

On a somewhat related note, the cursor: pointer css rule for .CodeMirror-foldmarker in main.less does not seem to have any effect. Cursor still renders as text when one mouses over the collapsed marker.

I think this only happens when the collapsed code has a nested collapsable code.

On a somewhat related note, the cursor: pointer css rule for .CodeMirror-foldmarker in main.less does not seem to have any effect. Cursor still renders as text when one mouses over the collapsed marker.
Our pointer-events: none rule causes this problem.

PR https://github.com/adobe/brackets/pull/10960 merged. Closing this.


Fixed Svace warning loop-var-in-closure (#8554).

Close #8554

See https://github.com/prometheus/prometheus/issues/8554#issuecomment-790760100

As discussed, this is not needed.


Add Spring Boot Admin

Console to manage and monitor our micro-services Spring Boot Applications.
See https://github.com/codecentric/spring-boot-admin and https://spring.io/blog/2016/12/07/spring-tips-bootiful-dashboards

If you are interested, I coud work on it next week.

An overview of what is comming:

Nice, excited 👍


More flexible start/end types in TradingCalendar

Changes:

Allow to pass string and datetime types to TradingCalendar's start and end parameters.
Set default parameters to None. This way it is easier to propagate undefined start/end parameters when the TradingCalendar initialization is encapsulated in another function/method (no need to import start_default/end_default to have consistent behavior).
Store start/end attributes as they are useful to know the first/last day of the calendar (they do not need to match the first/last trading session in the calendar).

This pull-request also includes #1802.

Coverage decreased (-0.05%) to 87.499% when pulling 50486e510a2d7dc79f925313b18fa9d8a8a31612 on Peque:flexible_startend into c2e011440e87417e0d790ebfdd1a0d80da3efcfc on quantopian:master.

Coverage increased (+0.007%) to 87.554% when pulling 6690b31f3fac42abe74d901e007462eae8ee2bcc on Peque:flexible_startend into c2e011440e87417e0d790ebfdd1a0d80da3efcfc on quantopian:master.

Coverage increased (+0.007%) to 87.554% when pulling 6690b31f3fac42abe74d901e007462eae8ee2bcc on Peque:flexible_startend into c2e011440e87417e0d790ebfdd1a0d80da3efcfc on quantopian:master.

Coverage increased (+0.007%) to 87.554% when pulling 9933da338af598793f19d5ad6badceee0fcba075 on Peque:flexible_startend into beba243e2ed17da81a97035d08375890a42f2b5e on quantopian:master.

Coverage increased (+0.007%) to 87.554% when pulling 9933da338af598793f19d5ad6badceee0fcba075 on Peque:flexible_startend into beba243e2ed17da81a97035d08375890a42f2b5e on quantopian:master.

x-ref https://github.com/quantopian/zipline/issues/418

TradingCalendar has been moved to its own repo: https://github.com/quantopian/trading_calendars


DEP: remove remaining 0.3.0 deprecated fuctionality

Coverage decreased (-0.04%) to 98.98% when pulling d14c59355b96547ec30013211b9797051b0e5a9b on jairideout:0.3.0-more-dep-removal into 3ecf4548f730bca1859296398cc296363e9d6978 on biocore:master.


Main.py

Star Wars scraper function
- remove whitespace from text file
- remove numbering system from text file

if we canty get whitespace removed, or this bug fixed by end of day 8/1/2022, scrape from somewhere different or pick another category. MVP is more important.


⚠ GitLab Server has degraded performance

In 6202680, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 11445 ms

Resolved: GitLab Server performance has improved in a9a7280.


Position of the items are scattered after the sorting

Some css transform is applied while sorting and it is not removed. I guess it  causes the misbehavior

@Sureshowler could you provide some more info or screenshots? I'm not entirely sure what you mean by the issue title - so some more information would go a long way toward me being able to solve this. Thanks 😄

Demo-component.hbs
{{#sortable-group tagName="ul" onChange="reorderItems" as |group|}}
{{#each recipients_list as |item index|}}
{{#sortable-item tagName="li" model=item group=group handle=".handle"}}
{{index}}  {{item.a}}
↕
{{/sortable-item}}
{{/each}}
{{/sortable-group}}
Demo-component.js
import Ember from 'ember';
export default Ember.Component.extend({
recipients_list:[{a:"boy"},{a:"dad"},{a:"fox"},{a:"eagle"},{a:"dog"},{a:"frog"}],
actions:{
reorderItems(itemModels, draggedModel) {
this.get('recipients_list').setObjects(itemModels);
// Ember.run.later(this,function(){$('.sortable-item').css("transform","");},1000);
}
}
});

Hi @acburdine ... Do you need more info?

Try with chrome version 56......... It is working good in firefox....

I'm experiencing the same issue, the only thing I have is the code from the example on the README file.

Here are some screenshots of different cases I've experienced. It seems to depend on where I stop dragging, but only happens occasionally.
Expected:

Example 1:

Example 2:

The transform on the div.sortable-item is not always being removed after dragging.

i'm still seeing this issue. any update here? can i provide some info to help?

I am having this issue, and I have found the source of the problem. In the mixin the _drag method is being called after the reset method is invoked by the group on drop. The item being dragged is stuck with a transform until another drag event happens.

@shidel-dev thank you for investigating! I look forward to your PR.

This looks like it should have been automatically closed by #156


Enhancement requests and questions regarding attachment library for CAP applications

Hello team,
we have been exploring the new attachment library for CAP applications, and we really like how easy it is to integrate it into existing applications! We have some question regarding the usage internally at SAP:

The library injects the UI annotation for the attachments. We would like to have an option to influence this behaviour, e.g. to hide certain columns or to show the attachments somewhere else on the object page.
We have use cases where only one attachment is allowed. Is there currently a possibility to control/restrict the number of attachments.
For security reasons we have to use mTLS authentication where ever possible. The library is internally using Basic Authentication for consuming the malware scanning service. Is there a way to change this?
We have the guideline that files should be scanned for virus during the upload and during the download stage as well. Is it possible to enforce this in the library?

@UpendraMallya : Thanks for the feedback!
We need to discuss about the enhancement request and get back to you!


1ab0fc61-45d6-43df-ad64-c37ec87e9204

this is for automated testing

16d68cfe-f143-4036-9700-8e3ba63670d6


Auto-update openal-soft to 1.24.0

New version of openal-soft detected (package version: 1.23.1, last github version: 1.24.0)

superseded by #6019


Improve using elements in lists

This PR changes the recommended way to convert Blueprint Elements into Items or HeaderFooters. The old way was to either manually define a BlueprintItemContent or BlueprintHeaderFooterContent, which worked great for more complex needs, or to use  the ElementItem(...) or ElementHeaderFooter(...) funcs, which were meant for simpler use cases. However, the latter was still pretty wordy, and people would still regularly mess it up.
Here, we instead add extensions to Element to support both Item and HeaderFooter use cases: You can just directly return an Element (as long as the element is Equatable or LayoutEquivalent) anywhere an ItemContent or HeaderFooterContent was previously required (caveat: Where assignment happens  directly; such as Section.header, you still need to do section.header = element.headerFooter()).
This PR also moves isEquivalent(to:) into its own interface (LayoutEquivalent), so (a) the docs can be shared, and (b) so elements can conform to it and be used in either the item or header/footer case.
TL;DR
Now that this PR exists, you can now do:
List {
   Section("some-id") {
       SomeElement()
       AnotherElement()
       SomeItemContent()
       MyCoolElement().listItem(id: "my-id") {
          $0.selectionStyle = .tappable
       }
   } header: {
      MyHeaderElement()
   } footer: {
      MyFooterElement().listHeaderFooter {
         ...
      }
   }
}

Checklist
Please do the following before merging:

[x] Ensure any public-facing changes are reflected in the changelog. Include them in the Main section.

I agree with the core aspects of the direction here - the builders, the reversal of construction (from Item containing Element to Element modified to Item), and even some of the more controversial sugar that you've included. Thanks for backing this up with so much testing.

Finally getting around to landing this!


hono/client hc<>() breaks when using with BunJS build

What version of Hono are you using?
4.5.0
What runtime/platform is your app running on?
Bun
What steps can reproduce the bug?
import the hono/client hc to a file and build it using BunJS Bun.build(). Then try to consume it, this will crash the execution.
What is the expected behavior?
No errors.
What do you see instead?
BunJS crash.
Additional information
Bun related issues:
https://github.com/oven-sh/bun/issues/11079
https://github.com/oven-sh/bun/issues/11880
Migrating the client class ClientRequestImpl to a function fixes the issue.

Hi @AlbertSabate
If it's not solved, please provide a minimal project to reproduce it and show an instruction.

Hello, @yusukebe problem is solved. The code is good and working, but check the PR, there are some type improvements and I left one comment on one line which I think is a bug on the scenario where there is a searchParam which is a string[].
Other than that comment and some type improve everything is working fine. I think you can review the PR and if there is something you like I'll keep only those lines.

@AlbertSabate
Thanks! For now, we can close this issue.


enable ENET ethernet on imx8mm and imx8mn

Added new driver for PHY AR8031.
Enabled ENET on Cortex-A Core for imx8mm EVK and imx8mn EVK.

As the PHY driver introduces a new file, run clang-format on it before submitting.

Done, thanks.

Updated to rebase on https://github.com/zephyrproject-rtos/zephyr/pull/75083 which is used to fix twister failure.

Rebased as dependency https://github.com/zephyrproject-rtos/zephyr/pull/75083 has been merged.

Hi, @decsny, would you please help to review this PR? thanks.

Updated to address the review comments.

Rebased and move some common PHY registers definition to mii.h

Moved some common register definition to mdio.h

Fixed compliance checking issue.

Hi, @jukkar and @rlubos would you please review this PR as it is assigned to you, thanks.


[Vimeo] No download of 2K/4K format (at least via HTTP)

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2016.12.18. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

[x] I've verified and I assure that I'm running youtube-dl 2016.12.18

Before submitting an issue make sure you have:

[x] At least skimmed through README and most notably FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)
[ ] Site support request (request for adding support for a new site)
[ ] Feature request (request for a new functionality)
[ ] Question
[ ] Other

$ youtube-dl -F -v https://vimeo.com/130032076
[debug] System config: []
[debug] User config: []
[debug] Command-line args: [u'-F', u'-v', u'https://vimeo.com/130032076']
[debug] Encodings: locale UTF-8, fs UTF-8, out UTF-8, pref UTF-8
[debug] youtube-dl version 2016.12.18
[debug] Python version 2.7.6 - Linux-4.4.0-53-generic-x86_64-with-Ubuntu-14.04-trusty
[debug] exe versions: avconv 9.20-6, avprobe 9.20-6, rtmpdump 2.4
[debug] Proxy map: {}
[vimeo] 130032076: Downloading webpage
[vimeo] 130032076: Extracting information
[vimeo] 130032076: Downloading webpage
[vimeo] 130032076: Downloading JSON metadata
[info] Available formats for 130032076:
format code  extension  resolution note
http-360p    mp4        640x268    25fps
http-720p    mp4        1280x536   25fps
http-1080p   mp4        1920x804   25fps (best)

Description of your issue, suggested solution and other information
The mentioned video is in 4K can be played at Vimeo in this five resolutions:

360p / 720p / 1080p / 2K / 4K

However youtube-dl only offers:

360p / 720p / 1080p

Looking into the player source (view e.g. in JS Beautifier) it turns out that via HTTP indeed only these three resolutions are available. The complete five ones are only available via MPEG-DASH or HLS.
So the Vimeo extractor should be modified to also take MPEG-DASH and/or HLS formats into account (or perhaps completely switch to one of these).

Did Vimeo changed their site recently?
Because downloading via HLS definitely worked before, don't know why it isn't listed in the format list above.

Thank you for fixing this so fast!


New package: DogAPI v1.0.0

Registering package: DogAPI
Repository: https://github.com/thexxiv/DogAPI.jl
Created by: @thexxiv
Version: v1.0.0
Commit: ad2f55fd2caa3c6a0dd02ee04bf0f111c09139fe
Git reference: HEAD
Description: Dog API client for Julia.

Error while trying to register: Register Failed
@thexxiv, it looks like you are not a publicly listed member/owner in the parent organization (JuliaRegistries).
If you are a member/owner, you will need to change your membership to public. See GitHub Help


Solaris 10 x86 not recognizing keyboard at installation (M1) [Emulation]

Describe the issue
I am trying to install Solaris 10 on UTM using emulation to install the x86 version. the first screen that appears to select Solaris install the keyboard works to select it, but past that screen the keyboard doesn't work anymore and i have tried multiple external USB keyboards but still nothing, because of the timer i get stuck at the select the keyboard layout screen.

And this is where the keyboard stops responding at all:

So we get stuck in here forever:

Configuration

UTM Version: Version 4.2.5 (81)
macOS Version: Ventura 13.4.1
Mac Chip M1 pro

Debug log
debug.log
VM config:
config.plist.zip

It might be a USB controller issue, try downgrading to usb 1 or ps2

I have tried that but nothing. isn't my mac keyboard supposed to work
anyway?
On Fri, Jul 7, 2023, 00:18 Tifa Software @.***> wrote:

It might be a USB controller issue, try downgrading to usb 1 or ps2
—
Reply to this email directly, view it on GitHub
https://github.com/utmapp/UTM/issues/5426#issuecomment-1624423211, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AV73QADXC6HTJZDNAQ6Q7ITXO5BVXANCNFSM6AAAAAAZ7TGQS4
.
You are receiving this because you authored the thread.Message ID:
@.***>


Maximum call stack size exceeded with custom validator

Upon adding custom validations, on no error the validator is getting called infinite times. I think this is the same issue https://github.com/christianalfoni/formsy-react/issues/298.
"react": "^16.4.2",
"react-form-validator-core": "^0.4.4",

Hi
can you reproduce your issue here?

My mistake.. sometime I can't think properly. The infinite call was due improper coding :)
Thanks a lot


Cleanup RancherOS references

Signed-off-by: Ettore Di Giacinto<EMAIL_ADDRESS>

Supersedes https://github.com/rancher/elemental/pull/187

Only things I see still missing with a grep now are, tests, old scripts used for building and docs. But that would likely be a better fit in a follow-up


Add library import example

Problem
Show the recommended way to import external libraries.
Proposed solution
Import this library and do a basic operation in an example circuit.
Alternatives considered
No response
Additional context
No response
Submission Checklist

[ ] Once I hit submit, I will assign this issue to the Project Board with the appropriate tags.

@critesjosh I think we could point lib imports to [noir-examples)(https://github.com/noir-lang/noir-examples/blob/6f34a761fad880c4deb0e0246289da96009b7929/stealthdrop/circuits/Nargo.toml#L6) 🙂 wdyt? would close this issue nevertheless

works for me!


Mdx ?

It's using md, while it could be more interesting to build this with mdx.

Do you know any slide decks with mdx?

Nope. I used mdx without sliding decks instead. Would be very interesting to build one 👍

I'm archiving this repository in favor of https://github.com/jxnblk/mdx-deck/tree/master/packages/gatsby-theme ✌


build: allow building packages with CPack

I have just successfully compiled polybar for Debian Buster and packaged it up into an installable deb package that I can throw into my own local repo.  This has several advantages:  I can build the package in a container and deploy to my normal system without having to install all of the build dependencies on it.  When installing the package from my local repo, APT will do the dependency resolution for me and only install the runtime dependencies.
Right now, the packaging option in CMake is turned off my default.  Building the package works via the new package target.
Open questions/future work:

[ ] Possibly add the package building option to build.sh
[ ] Maybe automatically build packages on Travis CI and deploy via GitHub releases.
[ ] Perhaps users do not want to build both DEB and RPM (for which they'd have to have dpkg and rpm installed) so maybe split the CMake option into two.

Here is what building the package looks like in the terminal:
root@debian:~/polybar/build# make package
[  5%] Built target xpp
[  9%] Built target jsoncpp_lib_static
[ 11%] Built target i3ipc++
[ 92%] Built target poly
[ 94%] Built target polybar
[100%] Built target polybar-msg
Run CPack packaging tool...
CPack: Create package using TGZ
CPack: Install projects
CPack: - Run preinstall target for: polybar
CPack: - Install project: polybar
CPack: Create package
CPack: - package: /root/polybar/build/polybar-3.4.0-Linux.tar.gz generated.
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: polybar
CPack: - Install project: polybar
CPack: Create package
-- CPackRPM:Debug: Using CPACK_RPM_ROOTDIR=/root/polybar/build/_CPack_Packages/Linux/RPM
CPackRPM: Will use GENERATED spec file: /root/polybar/build/_CPack_Packages/Linux/RPM/SPECS/polybar.spec
CPack: - package: /root/polybar/build/polybar-3.4.0-Linux.rpm generated.
CPack: Create package using DEB
CPack: Install projects
CPack: - Run preinstall target for: polybar
CPack: - Install project: polybar
CPack: Create package
CPackDeb: - Generating dependency list
CPack: - package: /root/polybar/build/polybar-3.4.0-Linux.deb generated.

I knew that cmake could do this but I didn't think it takes that little code.
I very much like the idea of people being able to manage their polybar installation through their package manager, even if they compile from source.

When installing the package from my local repo, APT will do the dependency resolution for me and only install the runtime dependencies.

The package created on my system doesn't have any dependencies listed. It even tells you that:

-- CPACK_DEBIAN_PACKAGE_DEPENDS not set, the package will have no dependencies.

Is this different on systems with apt?
The main issue I have with this is that we don't want to have code in our repo that is not actively maintained. I don't use a distro with apt or rpm, so to test this I will each time need to load up two different VMs and I don't have the capacity to dedicate that much time for something like this. This means unless @Lomadriel or @NBonaparte uses a distro with apt or rpm, there is no one on the team that will really maintain this code.
I was already quite conflicted about adding a polybar.spec file for openSUSE in the contrib folder, but there the author said they would update it regularly and secondly the contrib folder is meant more for that kind of thing while this PR would actually change the main build flow (even if it is off by default).
I don't really know what to do here, because the benefits are quite nice. @Lomadriel, @NBonaparte what are your thoughts on this?

There is also a repo that allows you to build polybar in a container (and create .deb packages): https://github.com/ayosec/polybar-debian
And polybar is coming to the official fedora repos: https://github.com/polybar/polybar/pull/1976

Oh, I don't think the DEB package can be reliably built on a non-APT system (similarly for the RPM package).  On an APT-based system, make sure you have dpkg-dev installed, then the line
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)

will use dpkg-shlibdeps to automagically determine which packages are needed to fulfill the dynamically-linked dependencies.
The same holds for RPM-based systems where the magic line is:
set(CPACK_RPM_PACKAGE_AUTOREQPROV ON)

This works a little bit different an requires the existence of the file utility.
This also means that the new CMake code needs exactly zero maintenance because as long as the make install target works correctly, make package will work as well (on a supported distribution of course).
Further I have thought about the interface again and come to the conclusion that using an extra ENABLE_PACKAGE option does not make too much sense and it is much more convenient to hijack the existing CPACK_GENERATOR variable for that purpose.  That way I can say for example
$ cmake -DCPACK_GENERATOR='DEB;RPM;TGZ' ..

to build packages for all generators or just
$ cmake -DCPACK_GENERATOR=DEB ..

to build only the Debian package.
On another branch (https://github.com/hmenke/polybar/commit/7cd281fbfec535d677b776a42a6d89749a200ddc) I have also integrated building the Debian package into the Travis CI workflow, but that became sort of ugly.  Right now, I'm using aptly to set up a local repo that contains the polybar package that falls out of CMake.  Then I fire up a ubuntu:bionic Docker container in which I install the local repo and install the polybar package.  After that I check whether ldd can resolve all the dynamically linked dependencies. I can understand if you don't want to have this sort of stuff in the build system.

The RPM generator actually did create a proper dependency list (though in rpm in general dependencies are to specific library files and not package names).

This also means that the new CMake code needs exactly zero maintenance because as long as the make install target works correctly, make package will work as well (on a supported distribution of course).

This assumes there are no errors in the cmake code responsible for configuring cpack. That was my actual concern that the package files generated had some kind of issue (missing files, wrong metadata) that didn't allow it to run (or be installed).
This is something where travis could be very useful.

I can understand if you don't want to have this sort of stuff in the build system.

Actually, this is something I would like to have in the travis config because it allows us to test the cpack functionality. I does look rather unreadable if it's all written directly into the travis config file, but adding scripts in common/travis to automate packaging and testing inside docker seems reasonable to me.

Considering that polybar is now available in debian and fedora as a native package and also as an rpm download from OBS for openSUSE, this PR is largely obsolete.
If someone wants to build a package for a non-release commit, they can also use checkinstall.

Fair enough. Thanks for considering my contribution.

Thank you for contributing, even if it didn't make it into the project :)


Fix message "Action failed" on CLI commands start, stop, terminate and others

Hey Hex 👋. I noticed this problem started in 1.0.0-rc.5. If you do pup run and then pup terminate for example, it says "Action failed" even though it worked.

💯


Could you realese the init models of the flow on UCF101 dataset

hi,
I think you could try following links to download the init models:
https://www.dropbox.com/s/vnban7sbmwgllbd/ucf101_bninception_flow_split1_flow_model_best.pth.tar?dl=0
https://www.dropbox.com/s/qqoxpt505s4xjwu/ucf101_bninception_flow_split2_flow_model_best.pth.tar?dl=0
https://www.dropbox.com/s/58pd7rnihbp6irl/ucf101_bninception_flow_split3_flow_model_best.pth.tar?dl=0

Thank you for your reply!

Could you also raise the init models of the RGB on UCF101 dataset?


Magento platforms are showing cart functionlity

Platform
Which platform does the bug apply to?
Ubuntu

WebExtension (Google Chrome, Mozilla Firefox)

Chrome
Describe the bug
Magento function is showing as cart functionality.
Expected behavior
Should show Magento.

@Adel-Magebinary Curious - Are you seeing both Magento and "Cart Functionality" in the Ecommerce category or are you seeing just 'Cart functionality', if so please share a site URL for review.
The newer "Cart functionality" was added by @rockeynebhwani to help two fold - a) find site that showcase a "cart function" in general as well as b) provide additional context for site detection. We made a few changes to improve existing Ecommerce platform signals but there are some sites that still would not get trapped and this helps uncover more sites.

@Adel-Magebinary - 'Cart Functionality' detection in addition to an eCommerce platform. It shouldn't really impact Megento detection. It should look like this.. If you share the site, we can definitely look into it for you.

hey guys, looks like it is fixed now. Thank you so much.

We didn't change anything

Closing

@AliasIO - Please close this.


Replace BallistaContext with SessionContext

closes to #1081
Which issue does this PR close?

Closes #.
Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

At the moment this just a draft, need a bit more work.
Looks like we finally support write in ballista, if we use SessionContext directly.
It looks a bit easy, do I miss something @andygrove ?

It looks a bit easy, do I miss something @andygrove ?

I quickly skimmed over this and I thought it looks good.

thanks @andygrove ,
I'm almost happy with current state of the PR, we have distributed write and information_schema support as new features.
Will try to use new methods to initialise PySessionContext and provide initial support for datafusion python.

when ever you have time @andygrove please have a look,
I haven't done any changes to python interface as of yet, as it would make this PR too big.
there is some duplicate code which can be re-used, will be addressed as follow up

did a quick test for python support
from datafusion.context import SessionContext
from pyballista import Ballista

# this makes most of the ballista python code redundant
ctx : SessionContext = Ballista.standalone()

df = ctx.sql("SELECT 1")
batches = df.collect()
batches.show()

df = ctx.sql("SHOW TABLES").show()
ctx.register_parquet("p", "testdata/test.parquet")

ctx.sql("select * from p").show()
ctx.sql("select name, value from information_schema.df_settings where name like 'ballista%'").show()

two things left to be addressed

remote to get url instead of host, port tuple
do not expose _with_config as we may be able to deprecate BallistaConfig as well

thanks a lot @andygrove
will push few small changes, and fix test asap
i'll use url in remote methods as may help add security later, and I'll remove methods with config as im not sure about them, will add them in due course once i get better idea about configuration (would not be great to add them then remove them :) )

can't really fix failing test on windows, disabling it for now on windows.
clippy should be fixed with #1090

I'm happy with current PR state, will create follow up PRs for configuration, python, and to try windows test.
@andygrove  If you're happy with the PR please merge it after #1090 which should fix clippy issues

thanks a lot @andygrove


Fdscript schema validation test

Fix the test Validate schema
Remove Performance tag so that it runs on every PR commit

https://github.com/strusoft/femdesign-api/blob/aa0d993ebc58d5c8255d4fb801ee264b9bf343eb/FemDesign.Tests/Calculate/FdscriptTests.cs#L50-L78

[ ] #624
[ ]  #623
[ ] #597
[ ] #596

Feel free to raise a ticket.

https://strusoft.fogbugz.com/f/cases/123504


add compat section

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@a758a69). Click here to learn what that means.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main       #1   +/-   ##
=======================================
  Coverage        ?   96.75%
=======================================
  Files           ?        5
  Lines           ?      216
  Branches        ?        0
=======================================
  Hits            ?      209
  Misses          ?        7
  Partials        ?        0

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


Conflicting routes between creating new document and displaying document detail

If document ID == 'new', the following two routes will be in conflict.
<Route path='/databases/:db/documents/new' component={DocumentNew}/>
<Route path='/databases/:db/documents/:docId' component={Document}>

One easy solution would be changing /new to /_new. Github has also done this on their Wiki page.

Closed the issue as it has been fixed.


chore: init repo

singleton tuple; profiling libraries
Issue: https://github.com/linuxdeepin/developer-center/issues/5731
Log: init repo

/approve


please find attached the source file of BUTA.

made some minor changes to my fork, so I will close this pull request and issue another one.


Storybook Documentation - Component: TabBar

Description / User Story
With this task we want to make the Tab Bar Component page in Storybook look like the template from design.

Requirements

[ ] #460
[ ] #501

Acceptance Criteria

[ ] Component Page has the same structure as the design template (in the following order):

[ ] Headline & Intro Text incl. a list of anchor links to all following sections
[ ] Docs Area with Example and all Props (see which props should be displayed for this component in the section below)
[ ] Appearance

[ ] Variant (incl. variant = standard, fullWidth)
[ ] SizeVariant (incl. sizeVariant = SM, MD, LG)
[ ] Alignment (incl. alignment = left, right)
[ ] HasDivider (incl. hasDivider = true, false)
[ ] HasButton (incl. hasButton = true,false)
[ ] HasScrollbar (incl. hasScrollbar = true, false)

[ ] Dependencies

[ ] IconButton (incl. default IconButton)
[ ] Icon (incl. iconPosition = leading, trailing)

[ ] Component Page includes the texts as defined in the section below (incl. non default values for the shown examples)
[ ] Component Page text styles (uppercase, lowercase, spacing) correspond the the design template
[ ] Component Page spacing corresponds to design template
[ ] Component Page colours correspond to design template

Props
See this table page "Tab Bar" for all props that should be displayed for the component, incl. their description, default values and the type of controls. Props that do not appear and that can be removed, should also be removed (not including theme for example, because this is needed for all components, but still not part of the props section).
If the props in the list are not the same as the component currently uses, just leave a comment in column G in the excel and a follow-up task will be created. Fixing the components is not part of this ticket.

Content / Texts
See this table page "Documentation Texts" for all texts that should be displayed for the component. Filter column A in cell A3 to only show you the texts of this components.
For the texts please change "[component name]" with "Tab Bar" and "[componentName]" with "tabBar".
Also all the examples in the documentation below the Props should not use the default values, but they should use descriptive texts for Label, Placeholder and other text fields. Some examples are already given in the template.

Background information

Example of a collapsible Props Section can be seen here

This ticket has open requirements and should not be started before these are done.


[3.0.0] Error data flags can carry over from one error to another

Using the 3.0.0-alpha5 release, the flags component of an error is not properly cleared out from the error stack's internal storage. This results in errors created without any string data still reporting ERR_TXT_STRING and ERR_TXT_MALLOCED if the error's slot in the internal stack previously contained an error with malloced string data.
As an example, here's a simple C program:
#include <openssl/err.h>
#include <stdio.h>

int main() {
    int flags;

    // ERR_raise_data(0, 0, "hello %s", "world");
    // ERR_clear_error();

    ERR_raise(0, 0);
    ERR_get_error_data(NULL, &flags);

    printf("flags: %d\n", flags);
}

If you compile and run that, it prints flags: 0, as expected. However, if you uncomment the two lines that create the earlier error, it now prints flags: 3 (i.e. ERR_TXT_STRING | ERR_TXT_MALLOCED), which is incorrect. The end result is that code that looks at the error sees an empty string for its data, rather than no string at all.
It looks like this is the result of #9459, which avoids deallocating malloced data buffers to avoid allocator traffic. The logic should probably be adjusted to clear the flags unconditionally and track the fact that the buffer is still malloced somewhere else.

I am not so sure this is an error because, internally, the field does have a malloc'd buffer. It just so happens that the buffer is empty.
The ERR stuff exposes too many internals, anyway. Since that is being deprecated, and it's not incorrect (although it is confusing), I would close this as "wontfix" because that code is going to vanish.
I do think, however that the ERR_TXT_xxx numbers should be moved to not collided with the ERR_FLAG_xxx values. i can do a PR for that if wanted.

If you replace ERR_get_error_data(NULL, &flags) with ERR_get_error_all(NULL, NULL, NULL, NULL, &flags) you see exactly the same behavior, so I'm not sure how ERR_get_error_data's removal would change things here.
As a consumer of OpenSSL, I don't care if OpenSSL's internal error glue has a malloc'd buffer to cut down on allocator traffic, I care if there's an extra message string in the data component or not. It seems valuable to properly distinguish that for consumers.

The issue for the ERR stuff right now is that the "internal error glue" is exposed in public header files. We missed this when we made most things opaque in a previous release. I can argue it's a feature that lets users safely manipulate internal state.

Oh sure, I am definitely in favor of providing a minimal clean interface to the error state. This is just a case where the internal implementation details leak out into the public API in a way that could be avoided by e.g. creating a new internal-only flag for a cached allocation as you (I think) mentioned above.

No, that idea of a new internal-only flag doesn't work, without creating a parallel structure to the current errinfo and keeping that private. While also populating the necessary fields out to the (unfortunately public) error state.  The key question is given that much effort, why spend anything cleaning up an API that will be made opaque soon.

If the data pointer is no longer going to be publicly exposed, then it seems reasonable to close this issue.
What will the AIP to pull errors look like once it's all cleaned up out of curiosity?

I am not a member of the project, but I would expect all API's to work except for the data structure and the "get state" function being made opaque and removed, respectively.

I've created a PR with the flags fix, making the structures opaque will have to wait until after 3.0.


Multi doamin plugin not howing control panel

I have added the mautic domain plugin in mautic plugin manually after refreshing the plugin is not added in site plugin using mautic 4.4.6 version ?

Added the mautic multi domain plugin in plugin directory

But plugin is not shown after added in plugin directory can give us solution to fix this issue


Shrink database instance in dev environment

Value Statement
As a VANotify platform admin/owner
I want to use correct instance sizes
** And** not over provision environments
So that we can keep costs down
Acceptance Criteria
GIVEN VANotify dev environment
THEN we use db.*.small instance family
Checklist

[ ] Verify that data was not lost

Assumptions

Additional Info/Resources

Out of Scope

Open Questions

Here is the snapshot of the VAEC RDS Aurora proving db.t3.medium is configured by dev.  During deployment while the new DB instance type was initialized, the DB was not available to VANotify or celery workers.  It took around 4 minutes for the DB to become available.

Reviewed Acceptance Criteria, it has been satisfied as demonstrated in the Screen shot above.
Testing criteria has been met. Ready for Signoff


Links to live demo are dead

Example link:
ritikbanger.github.io/react18-input-otp

This will be fixed in any upcoming push to npm.
For the time being here is the- codesandbox


TextField can not accept  "obscureText: true" and "maxLines: null" together!

TextField(
obscureText: true,
maxLines: null,
decoration: InputDecoration(
border: OutlineInputBorder(),
hintText: 'Enter a search term',
),
);
its not working!
you have to rewrite it as :
TextField(
obscureText: true,
//maxLines: null,
decoration: InputDecoration(
border: OutlineInputBorder(),
hintText: 'Enter a search term',
),
);
O __ O

Hi @alisinaee, obscureText: true is usually meant to be used for password fields, which is why it was decided that they should not be multiline.
What is your use case for wanting to use a multiline "password" field?

Hi , this is the point , I don't want multiline with obscure so I need to pass maxLines: null, to the TextField ( i have custom TextField widget with many options so i have to sett max line to null) but flutter wont let me !
logically its right to have both maxline:null and obscureText: true, in text input so they need to fix it,
I hope you understand what I mean. tnx btw

Hi @alisinaee, can you share what your code for the custom textfield looks like?
I believe you should be able to make those two work together without needing a change in the framework.
If the field is supposed to be multiline, you could just set obscureText to false for that particular field.


Error in code

is the code wrong?   should it be:
app.MapGet("/shorten/{redirect}",

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: a14cbeaa-a4a8-bb83-8395-3f890755492b
Version Independent ID: 8c6c6fdc-2422-5fc1-64cd-fd90e51bd349
Content: Quickstart: Build your first Orleans app with ASP.NET Core
Content Source: docs/orleans/quickstarts/build-your-first-orleans-app.md
Product: dotnet-orleans
GitHub Login: @alexwolfmsft
Microsoft Alias: alexwolf

No, the code is correct as is. In ASP.NET Core, the url that is given here is passed as a query string. With your suggested way of doing it, it would be part of the route, which doesn't work with encoding a full URL.


fix(codec): support transinfo in attachment codec

What type of PR is this?

fix: https://github.com/kitex-contrib/codec-dubbo/issues/84
Check the PR title.

[x] This PR title match the format: <type>(optional scope): <description>
[x] The description of this PR title is user-oriented and clear enough for others to understand.
[x] Attach the PR updating the user documentation if the current PR requires user awareness at the usage level. User docs repo

(Optional) Translate the PR title into Chinese.
在 attachment 编解码中支持处理 transinfo
(Optional) More detailed description for this PR(en: English/zh: Chinese).

en: support transinfo in attachment codec
zh(optional): 在 attachment 编解码器中支持 TransInfo
(Optional) Which issue(s) this PR fixes:

fix: https://github.com/kitex-contrib/codec-dubbo/issues/84
(optional) The PR that updates user documentation:

BTW, maybe we should exclude "go.mod" in _typos.toml.

done

Yes, please add to _typos.toml.

done

This PR introduces an issue where Kitex client calls Dubbo service:

The corresponding Java code is as follows,  where 'attachments' is a Map with keys of type String:

In this PR, the attachment contains data with keys of type uint16:
        //  pkg/dubbo_spec/attachment.go:  line 56 ~ line 58
	for k, v := range transInfo.TransIntInfo() {
		result[k] = v
	}

This PR introduces an issue where Kitex client calls Dubbo service:
The corresponding Java code is as follows, where 'attachments' is a Map with keys of type String:
In this PR, the attachment contains data with keys of type uint16:
        //  pkg/dubbo_spec/attachment.go:  line 56 ~ line 58
	for k, v := range transInfo.TransIntInfo() {
		result[k] = v
	}

Besides,the trace context was not correctly propagated to dubbo server side ( extracting trace context through opentelemetry-javaagent ):

I compared the 'attachments' received by the Dubbo service when called by the Dubbo client and the Kitex client.
called by dubbo client:

called by kitex client:

I made a local modification to the codec-dubbo, removing the prefix RPC_TRANSIT_, and found that the Dubbo server could correctly parse the trace context:

I'm not sure if directly removing the prefix(RPC_TRANSIT_) will introduce other issues, but currently, it seems that this prefix causes the Dubbo server to be unable to parse the trace context.

This PR introduces an issue where Kitex client calls Dubbo service:
The corresponding Java code is as follows, where 'attachments' is a Map with keys of type String:
In this PR, the attachment contains data with keys of type uint16:
        //  pkg/dubbo_spec/attachment.go:  line 56 ~ line 58
	for k, v := range transInfo.TransIntInfo() {
		result[k] = v
	}

@nobody-s07 Sorry for not having enough testing before causing the issue. This PR（https://github.com/kitex-contrib/codec-dubbo/pull/90） has fixed the issue, you can try again

This PR introduces an issue where Kitex client calls Dubbo service:
The corresponding Java code is as follows, where 'attachments' is a Map with keys of type String:
In this PR, the attachment contains data with keys of type uint16:
        //  pkg/dubbo_spec/attachment.go:  line 56 ~ line 58
	for k, v := range transInfo.TransIntInfo() {
		result[k] = v
	}

@nobody-s07 Sorry for not having enough testing before causing the issue. This PR（https://github.com/kitex-contrib/codec-dubbo/pull/90） has fixed the issue, you can try again

Thank you for your resolution! Now the trace context is correctly passed to the Dubbo service.

@CoderPoet Thank you for your resolution! Now the trace context is correctly passed to the Dubbo service.

Hi! Thank you very much for pointing this out. Would you be interested in contributing a testcase to https://github.com/kitex-contrib/codec-dubbo-tests ?


Reference Gide removed but still has no content

Issue: The Reference page was removed here https://github.com/github/catalyst/commit/8ea720843f017e78e75ae3dcdc8f9b9d7353f805
as a solution to https://github.com/github/catalyst/issues/126, but unfortunately there are still links to this broken page within the main site header and banner image.

Thanks @Nickel-Less. Our plan is to replace this with a cheat-sheet instead. It's a work in progress but will be here in the next few weeks. I'm going to close this in favour of #126 which is effectively the same issue.


[Toggler] Does not show up when using search

Shows up fine for me. What browser are you using?

Ok I just realized something strange: When I type "togg", it does not show up. When I type "toggler”, it shows up?

Yeah, this is a know issue with our search for some reason if you are typing 3-4 letters. We have this documented and are working on a fix.

It was a bug with Typeahead, the autocomplete/search library we use.
Fixed via zurb/foundation-docs@83fe96ed4f3880c74e31f53642cee924c531ec1c


Add parameter inlays

Hello! I was playing around with an inlay parameter hint provider, inspired by the intellij-rust implementation.
I wanted to get an initial version to you for feedback, along with some notes of the current behavior and some future possibilities. It turns out, this all worked out quite smoothly, although there are some interesting cases that I note below. Overall, I think this is pretty interesting with the current cases implemented as is, and we can iterate and refine from there.
I have a few todos that I'd like to take care of before merging that I've written out below as well. If you think of anything else, let me know and I'll add it to the list.
Cases
Pipelines
Right now, I'm now showing hints for pipelines. This is a good thing in general, because usually the argument that you're piping through is understood to be the subject of the pipeline, so it doesn't need a name.

Destructured names
Destructuring a Custom Type with a single constructor value
Shows a hint with the destructured name.

Destructuring records
I believe the best way to handle these cases would be to not show a hint at all for these arguments:
example =
    nameToString
        { first = "Jane"
        , last = "Doe"
        }

nameToString { first, last } =
    first ++ " " ++ last

This is on my todo list, because right now it's using one of the destructured names, but that's not accurate (whether there is only one value destructured, or more than one as in the above example).
Cases with no hint
Point-free definitions
Underlying kernel function
It turns out, quite a few of the standard library definitions use this point free style. Like Decode.map, for example.
map : (a -> value) -> Decoder a -> Decoder value
map =
    Elm.Kernel.Json.map1

For cases like this, I don't think there's much you can do since it's defined in the kernel.
Non-Kernel point-free definitions
Longer term, if a function is point-free, but its underlying definition is non-kernel code, we can look at the argument name one level deeper. For example:
example =
    heading "This is content" "This is postfix"
            -- ^ content
                                       -- ^ postfix

heading =
    combine "Heading:"

combine prefix content postfix =
    prefix ++ "\n" ++ content ++ "\n" ++ postfix

We can infer those values that I annotated. I think it makes sense to defer this to a future pull request, after we see how it goes with the first set of functionality, though.
Remaining TODOs

[x] Don't show hints for destructured records (including 1 argument, don't show for any of these cases)
[ ] Hide hints for arguments that only have a single argument
[ ] Don't show hints for arguments that end with the passed in variable name
[x] Don't show hints for parameters named _

Future possibilities
Pipeline type names
Show the types along the way in the pipeline. Sometimes it's hard to keep track of the intermediary types, and there's prior art. See https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html#type-name-hints

Applicative pipeline field names
I think it could solve a real problem that comes up a lot that it's hard to tell which decoder value will map to which record value because of the positional nature of pipelines. This recent Discourse thread discusses it, and there have been many similar discussions in the past.
Lambda type hints
As with the Rider IDE, we could display type hints for lambdas. I often get confused when I'm writing a foldl expression, for example, and can't keep the order of the arguments straight. Having the type names would help for this kind of case.
Here's what it looks like in Rider (see https://www.jetbrains.com/help/rider/Inline_Parameter_Name_Hints.html#type-name-hints)

Here are some more cases as they are currently handled. One thing to note, I'm using top-level as clauses for names, which I think works well.
The (_,y) hint in example2 also seems readable and useful, but I'd be interested to hear your opinion on that. I'm definitely open to not showing hints in those cases if that doesn't seem helpful.

I made a few changes from the last update:

I was able to show the hints for those destructured tuples inline
I decided to skip record destructure hints for now since they can get noisy and can contain low-level details
I am skipping hints for Custom Type destructuring for now since those hints don't seem to be useful too often from looking through some examples with that on
I'm still using as clauses whenever they are provided

When you pass in a non-literal tuple, I currently don't provide a hint for that. I could easily show a hint like ( x, y ) here:
example coordinates =
    xPosition coordinates

xPosition ( x, y ) =
    x

I'm thinking it's reasonable to skip that for now, though, and revisit that later.
Summary
I think this is generally in pretty good shape, besides those two remaining todos. I'm open to any and all feedback, so feel free to share any constructive criticism or concerns you might have with any of the hints.
I was having some trouble getting the setting to save as well, I'm not sure if that's an issue with the runIde gradle task, or if I'm doing something wrong. I tried to follow the intellij-rust example there, but it doesn't seem to persist when I toggle the Elm-specific setting off for SHOW_PARAMETER_HINT. I'll work on that more as well, and it's good to know that we can add nuanced options in case users want to configure specific behavior (the Kotlin hints seem to have several options, for example).

I'll give it a try in the next few days. I can see how this would be useful, and I trust that your GraphQL examples are a good motivating factor. Personally, I turn off inlay hints for Kotlin and Java.
I have mixed feelings about showing parameter names as part of the API of a function in Elm. In most languages it's totally normal, but in Elm they are really more an internal name than an outward-facing name. For instance, if you look at the docs for elm/core List, the function signature only shows the type of parameters, never their name.
As you mentioned, point-free style is problematic since there are no names for the parameters. Destructuring is also problematic. And even in the case where the argument is named, the habit is to choose a name that makes sense internally, but not necessarily externally.
In any case, I will give your code a try and see how it feels.

One challenge in this is going to be the “stubs” system. For features like this that run automatically on multiple elements in the editor and which depend on analysis of imported files, the Psi queries should be able to get the data directly from the stubs. Otherwise, what will happen is that you will end up reading in all imported files and parsing them, which gets slow.
Our stub index includes the name of a function but not its parameters (see ElmFunctionDeclarationLeftStub). We also include the type annotation in the stub index.
We could add parameters / destructuring-pattern to the stub index, but that will increase the size of the index. And it won’t help with some of the fancier dereferencing that you wanted to do (re: point-free style) since you would need to reach into the function body to chase down a named binding.
I think the only path forward is to try adding function parameters to the stub index and see how much it increases the size of the index, RAM usage, project load time for a real-world project. Unfortunately I don’t have any existing technique for measuring those things, so it would need some investigation.

Hey Keith, thanks so much for taking a look and sharing that info.
That's a great point about the stub indexes. Regarding looking through point-free definitions and finding the underlying definition, those performance considerations sound like more reason not to pursue that functionality, at least for now.
It also seems like pattern matching info is probably not worth including in the indexed function data. In some cases, the names may not be high-level, so it seems like it's not worth the effort and potential performance cost to include that extra metadata.
From playing around with it, it seems that the most useful names are the regular parameter names. I'll play around with some performance profiling. It looks like there are some tools for that here: https://intellij-support.jetbrains.com/hc/en-us/articles/207241225-Performance-testing-plugin. I'll let you know what I find. I'm not sure what it would entail to do add parameter names to the stubs, but I'll take a look at that and think about the tradeoffs and effort there.
Type Hints
What I think will be most valuable by far are type hints.
For example, type hints for lambdas:

Since lambda parameters don't have type annotations, I find myself using ctrl-shift-p often to get context on what data is available.
I also have an initial version working for providing type info for let bindings that aren't annotated, and I think this can be useful. And I'm also working on adding annotations for intermediary types in a pipe chain.
Adding type hints calls to ElmPsiElement.findTy(). Do you think that will use information that will be indexed already since it's just resolving types? Here's the basic implementation. It doesn't handle all the cases, like excluding annotations when the type is unknown. But it already works pretty well:
https://github.com/dillonkearns/intellij-elm/blob/ea8ac76d3b7190ead672692d494ed4f0ac04315e/src/main/kotlin/org/elm/ide/hints/parameter/ElmInlayParameterHints.kt#L32-L41
Pipeline Type Annotations
For the pipeline type annotations, I'll need to expose some type information that's being computed here:
https://github.com/dillonkearns/intellij-elm/blob/977792141195be51ab9da901885024ae489a576c/src/main/kotlin/org/elm/lang/core/types/TypeInference.kt#L345-L346
That will give me access to the type of each piece of the pipe chain. Since it's already being computed here, I'll just need to include that data in that Ty data type. Does that seem like a reasonable idea?
Thanks again for taking the time to look at this. I'm happy to do a call some time if it's easier to discuss more details that way.

Adding type hints calls to ElmPsiElement.findTy(). Do you think that will use information that will be indexed already since it's just resolving types?

Yes, the type inference system is already designed to work strictly in terms of stub data so that it never needs to parse any files other than the one you are editing.

For the pipeline type annotations, I'll need to expose some type information ... That will give me access to the type of each piece of the pipe chain. Since it's already being computed here, I'll just need to include that data in that Ty data type. Does that seem like a reasonable idea?

The Ty values are heavily cached, so any changes to that data will need some extra scrutiny by either AJ or me. But I'm wondering if there's a better way. It sounds like you need more fine-grained sub-expression type inference. This is tracked in InferenceResult.expressionTypes, and it is how the ctrl-shift-p (lookup type of expression) feature works (see ElmExpressionTypeProvider). I'm not entirely sure what you want to do, but it may be that we just need to break apart the pipeline expression and register it in expressionTypes. This will result in higher memory usage, but AJ did a lot of work earlier this year to make the cached type inference data use less memory. In any case, let's keep type inference changes out of this PR so that we can look at a smaller change later with AJ.

In terms of performance, I guess the main thing I'm curious about is the increase to the size of the stub index on disk/memory, whichever is easier to calculate. Unfortunately I don't know off-hand how to investigate that.
But I do have a couple tricks to detect when code accidentally parses a file when it should instead be getting the data from the stub index.

for unit tests, see ElmResolveTestBase.stubOnlyResolve(), specifically checkAstNotLoaded
for running the IDE, set a breakpoint on PsiFileImpl.loadTreeElement()line 196. Whenever the breakpoint hits, log the name of the file and continue. Then when you are running the IDE, just keep an eye on the log output and make sure that it only prints out the name of the currently edited file.

 It should never parse external files when running an inspection or any other kind of passive annotator.

Yes, the type inference system is already designed to work strictly in terms of stub data so that it never needs to parse any files other than the one you are editing.

That's great news! Maybe to keep things simple, I can focus on having this first pull request introduce some hints for types like lambda types and unannotated let bindings. Then I can break up other features into other PRs so it's more manageable to evaluate any performance implications.
Pipeline Hints
I can also do the pipeline type hints as separate PR. To give you a sense of what the pipeline type inference might look like, here's a very simple implementation. I'm not sure if this plays well with the cached types, probably not given that it introduces a new field.
I guess instead of introducing a new field, I could just use the existing expressionTypes field and then it would get cached? It sounds like that would make it easier in terms of relying on existing caching logic instead of introducing new data that needs caching.
https://github.com/klazuka/intellij-elm/commit/4716f24aabed6ab8810c25001b9bdeefec6b84a4
And here are a few examples of the above implementation in action:

If we were to use the existing expressionTypes to cache the computed types, it would be pretty straightforward I think as long as we can build up those expressions.
Is it valid to build up an expression that's only part of an ElmBinOpExpr, though? That might be the sticking point to that approach. Take this example:
123.45
    |> round
    |> List.singleton

We would need to store the expressionType for 123.45 (not a problem since that's already an expression).
And 123.45 |> round. But I'm not sure if we can do that? This code builds it up into its own data structure to evaluate it and compute the precedence and types of the sub-expression. But can we build an ElmPsiElement out of it that we can then use to index into the hash? Does it get the value out of the hash by reference equality check, or something deeper?
https://github.com/dillonkearns/intellij-elm/blob/977792141195be51ab9da901885024ae489a576c/src/main/kotlin/org/elm/lang/core/types/TypeInference.kt#L358

It may be that the reason AJ doesn't register the types of the sub-expressions within an infix operator expr is due to the representation problems. As you've noticed, he had to build a temporary parse tree because precedence is not known during the normal parser pass.
I don't think we will be able to cook-up an ElmPsiElement because these are stateful things that are deeply hooked into IntelliJ magic. But I'm certain that there's a way to make this work. For now, let's keep the focus on low-hanging fruit and then deal with extending type inference data later.

I don't think we will be able to cook-up an ElmPsiElement because these are stateful things that are deeply hooked into IntelliJ magic.

That's what I was thinking, too.

For now, let's keep the focus on low-hanging fruit and then deal with extending type inference data later.

I totally agree 👍 I'll focus on getting the lowing hanging fruit to a released state, and then revisit these things that require larger architectural changes after that. I'll work on getting this PR ready with a focus only on type hints (and not for intermediary pipeline values).

Hi @dillonkearns ! Are you still working on this, or can I close this issue. (maybe you can close it yourself explaining where you stalled)

Hi @cies, the reason I didn't merge this was because Keith had some concerns about performance. I'll close this, but feel free to make use of it if you'd like to.


Same domain for Weblogic 12.1.3 fails to start

I am trying to run the 1213-domain example extended on the 12.1.3-developer docker image and I am having some issues...

The PRODUCTION_MODE variable is not being passed correctly to create-wls-domain (I bypassed this by just hardcoding the value)
When trying to log into the console, the server just hangs with out-of-memory exceptions. (I've attempted to increase the JVM memory with no luck)

So I am kind of stuck.
Any help would be greatly appreciated
Thanks!

@Blackburn29 please see #319 corrected the 1213-domain to accept the PRODUCTION_MODE as an ARG

Managed to start the admin server using the following JVM settings:
docker run -d -e "USER_MEM_ARGS= -Xms1024m -Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=1024m" --name wlsadmin --hostname wlsadmin -p 7001:7001 1213-domain
Otherwise it hangs with out of memory exceptions.


docs(CONTRIBUTING.md): Add Linux MailHog install commands

Pre-Submission Checklist

[x] Your pull request targets the staging branch of freeCodeCamp.
[ ] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm test. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds new functionality)
[ ] Breaking change (fix or feature that would change existing functionality)
[ ] Add new translation (feature adding new translations)

Checklist:

[x] Tested changes locally.
[ ] Addressed currently open issue (replace XXXXX with an issue no in next line)

Closes #XXXXX
Description
It took me some time to get MailHog running on my machine, so I wanted
to update the guide for any future Linux users.
Also fixed a small typo at the beginning of the MailHog section.
BREAKING CHANGE: None.

Thank you too, @raisedadead! Sorry about the branch name.

Sent from Mail for Windows 10
From: Kristofer Koishigawa
Sent: Friday, December 29, 2017 2:57 PM
To: freeCodeCamp/freeCodeCamp
Cc: Subscribed
Subject: Re: [freeCodeCamp/freeCodeCamp] docs(CONTRIBUTING.md): Add LinuxMailHog install commands (#16366)
Thank you too, @raisedadead! Sorry about the branch name.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


similar sentence generation

Can this be modified to generate similar sentences given an input sentence?

Hi @nikky4D,
Can you provide more details of your task formulation? For example, which is the input and output of the language model?

The input to the language model is my own sentence. The expected output of the language model is a sentence. The output sentence will have similar meaning to the input sentence, but may be phrased differently.
Eg: input -- The cat is yellow ->  gives output -> That cat over there is yellow. Sentence is similar in meaning and important nouns that were being referred to in the input sentence are preserved.


use standard configuration directory

Python package directories are not meant to store writable user configuration data.
Quick patch: https://git.m-labs.hk/M-Labs/nix-scripts/src/branch/master/artiq-full/wand-fix-config-dir.patch

thanks! I acknowledge the issue and overall the fix looks good, but (a) I need to coordinate with current users to find a minimally disruptive time to role this out so it doesn't break things unexpectedly (b) I need to have a think about whether I actually want to make artiq a dependency of this package.
PS out of curiosity, are you using this for a hobby project or is another uni group using wand?

Joe wants to use it on Nix, which enforces read-only package files. Sadly, I don't have enough hobby budget for a lot of wavemeters and SFPIs.

aah, ok. Always nice to gather users...
I'm swamped for the next couple of days, but I'll find time to merge a fix to this this week. If it's causing you issues please do chase me.

Not a high priority, I'm applying the patch in the packaging, so it already works.

And yes, ARTIQ shouldn't be a dependency just for this - I just imported it because wand already depended on it.

aah, oops, yes. That's probably a hang over from the pre-sipyco days and should be changed.

TBH I'm not sure how this didn't come up before...AFAICT our current conda package for wand server cannot possibly work since it assumes a local checkout. I'll fix it...

TBH I'm not sure how this didn't come up before...AFAICT our current conda package for wand server cannot possibly work since it assumes a local checkout

Yep, we are indeed running a local checkout e.g. in lab 1.

okay, I've fixed that and a few other issues on our fork. I'll send some PRs over in a few days once I've had a go at (a) quamash -> qasync (which AFAICT is the most live project of its ilk) and (b) using the WLM as an OSA.

using the WLM as an OSA

What WLM is that?

WS*

The Highfinesse Fizeau/Snyder units? They can do OSA now?

Just exporting the interferometer pattern gives a lot of information about how happy the laser is

But do you get the actual spectrum or just something that approximates it? Aren't there multiple reflections in these interferometers, so they are more like etalons and don't just give the autocorrelation of the laser?

that's correct, but you can still end up telling by eye when the laser is single mode or not. This is used when manually tuning the laser up, and there is a clear plateau when increasing the current where the etalon signal does not change, hence the laser is single mode.

Yep; a "proper" OSA is more sensitive (especially with a logarithmic detector), but for choosing ECDL operating points, the WS* interferometer signals are enough information – particularly if you have and idea how the "known-good" single-mode pattern should look like. Back when I was in Jonathan Home's group, we didn't use any OSAs either.

I do think that it would be easier to automate the multimodw detection/correction with a proper osa if that was something one wanted to do however

Fixed in #33.


Simplify python_requires procedure

python_requires=('>=2.7,!=3.0.*,!=3.1.*,!=3.2.*,!=3.3.*,!=3.4.*, !=3.5.0, !=3.5.1') is easier to read as python_requires=('>=2.7, >=3.5.2').
Thanks @hugovk for the suggestion.

I believe python_requires=('>=2.7, >=3.5.2') will still match 3.0 - 3.4 because they're bigger than 2.7.
This simplification can only be done when dropping 2.7:
python_requires=('>=3.5.2')

Got it. That's why it was like that.


Communication issue between Astarte and Edgehog in a docker-compose-based setup

What did I do?
I have created a docker-compose file combining the Astarte part and the Edgehog part. I had to change the external port (4000) for the edgehog-backend service so that it doesn't conflict with the one for the astarte-realm-management-api service.
I have also followed the steps in Astarte in 5 minutes as well as the Edgehog initialization steps
What did I get?
I am able to successfully login to the Astarte frontend and see the simulated connected device and the data it is streaming.
I am also able to login successfully to the Edgehog frontend. I can create system models and HW types successfully. However, the simulated device is not displayed there.
I use the following as a connection-trigger.json:
{
    "name": "edgehog-connection",
    "action": {
        "http_url": "http://edgehog-backend:4000/tenants/test/triggers",
        "ignore_ssl_errors": false,
        "http_method": "post",
        "http_static_headers": {}
    },
    "simple_triggers": [
        {
            "type": "device_trigger",
            "on": "device_connected"
        }
    ]
}

When I replace the http_url above with a Mailgun Postbin URL, I am able to see the device connection event there.
After some debugging, I realized the issue is probably related to the communication between Astarte and Edgehog. More specifically, the value used for base_api_url. For example, when inspecting the logs that occur after a device connects, I notice a HTTP GET request is sent to <base_api_url>/appengine/v1/test/devices/<device_id> which fails with a 404 error.
I tried different values for base_api_url e.g. http://astarte-appengine-api:4002 or http://astarte-realm-management-api:4000, but all fail because the API paths are not correct.
As for the logs for the edgehog-backend service, they show an error like the one documented in this open issue.
Would there be a workaround to configure the base_api_url in a way that indicates that the astarte instance is running locally (e.g. via environment variables)?
Please let me know if it is more appropriate to submit this ticket to the edgehog repository instead.
Thanks for your help!

The trigger you posted here is trying to send a message to "http://edgehog-backend:4000" but by default docker-compose files will use listen on localhost.
If you want to receive thoese triggers, you have to either use "localhost:4000" or define some domain resolution that will map "edgehog-backend" to the proper IP.
A common aproach is to edit your hosts file, or setup some reverse proxy (with nginx or traefic) to make sure all the requests are redirected to the appropriate service.

Closing this since it has been answered


BLAS and other Maths library support?

HIP is a really nice effort to have a transparent C++ code for both Nvidia and AMD graphic cards. One important feature, however, for GPGPU is BLAS routines. I saw that there is an hcBLAS implementation. I was wondering if you guys intend to support a hipBLAS, which to dispatch the BLAS call to the appropriate hardware calling the corresponding library, or that is not the case?

Hi Alexander - hcBlas and hcFft are the best options right now because the interface for data uses pointers, hc::accelerator_view, and hc::completion_future.  HIP provides a couple accessors to translate from HIP to HC data structures, see for example "hipHccGetAcceleratorView".   We are looking at some additional syntactic sugar to make this a little smoother, perhaps a hipBlas like approach like you suggested.

A hipBLAS would be a really great feature, as currently HIP provides a very nice unified language to run things on both Nvidia and AMD cards. However, for BLAS routines you will need to import and use the concrete libraries - either cuBLAS or hcBLAS, which would require separate source code for both cases. Additionally, my guess is that any of these libraries like fft, math, rand which exits in both hcc and cuda would be great to have wrappers around. I like HIP a lot for unifying and allowing to write same code for both platforms, I think that is a really great benefit.

There is a hipblas branch in hcBLAS repository. https://bitbucket.org/multicoreware/hcblas/commits/branch/hipblas
I wonder when it will be released? It will be interesting to use to benchmark DeepBench. Is someone already working on it? The guy responsible for it seems interested in finding out the performance on AMD GPUs (http://www.eetimes.com/document.asp?doc_id=1330521)

@briansp2020 I'm not sure, but isn't hcBLAS targeted exclusively to AMD cards? We need something that is transparent and can be used both on Nvidia and AMD cards, since both of them actually have this kind of libraries implemented.

@botev hcBLAS is exclusively for AMD card at the moment. My guess is that hipBLAS will provide wrapper functionality so that single source can be compiled for NVidia using cuBLAS or AMD using hcBLAS.
Also, it looks like AMD is getting ready to release their own machine learning library similar to cuDNN soon. Crossing my fingers and waiting (im)patiently for ROCm 1.3 release this November.


DateTimeOffset Marshalling not matching documentation

When using DateTimeOffset, it marshals to System.DateTimeOffset not [Date, number] as mentioned in the docs: https://github.com/microsoft/node-api-dotnet/blob/main/Docs/typescript.md#special-types
Extract from ĒxampleModule.d.ts
export class SomeModelJS {
	constructor();

	id?: string;

	name?: string;

	created?: System.DateTimeOffset;

	updated?: Date;

	anotherField?: string;
}

c# Model:
[JSExport]
public  class SomeModelJS
{

    public string? Id {get; set;}
    public string? Name {get; set;}
    public DateTimeOffset?  Created {get; set;}
    public DateTime?  Updated {get; set;}
    public string? AnotherField {get; set;}

}

Thanks for reporting this. It appears the planned DateTimeOffset marshalling support was simply not implemented at all, and I lost track of it. So I'll use this issue to track the implementation. It shouldn't be difficult, so I can get it done relatively soon.

Thank you Jason.

Fixed, though I decided on a different design from how it was originally documented. See https://github.com/microsoft/node-api-dotnet/blob/main/Docs/dates.md


Skipping analysis for function at 0x8656b4 : Exceeds 'analysis.limits.maxFunctionUpdateCount'.

Version and Platform (required):

Binary Ninja Version: 4.0.4911,  15e9149
OS: macos
OS Version: 14.2
CPU Architecture: arm64

Bug Description:
Running analysis on the attached library results in:
[Function] Skipping analysis for function at 0x8656b4 : Exceeds 'analysis.limits.maxFunctionUpdateCount'. If possible, please report this issue.
Reporting just in case this is useful for you folks as per the log message :)
Steps To Reproduce:
Open libtmessages.48.so in Binja and allow analysis to run.
Expected Behavior:
Screenshots:
Additional Information:
Lib is a .so object attached as .zip to appease GitHub.
libtmessages.48.so.zip

Maybe related similar issue: #5141

This seems to be fixed as of at least 4.1


Shall we put this into a templated function and use it for the few cases?

Shall we put this into a templated function and use it for the few cases?
Originally posted by @bixia1 in https://github.com/tensorflow/tensorflow/pull/54452#discussion_r811363136

Hi @MobaXyna ! Could you please update the template too? It will help us expedite the issue. Thanks!


Don't need to place elv and ra-tls-server to bin directory

Type make on root directory, bin will be created and elv and ra-tls-server are placed under bin directory. This is not needed.

This problem has been resolved in the latest enclave-tls branch.


Page 'shifts' on opening and closing

Hi, forgive me if this was covered before. Searched and didn't find anything.
The issue I'm having is when a page is scrollable, and I open an image lightbox, it opens the lightbox and removes the scroll from the page. This causes the page to shift a bit. Is this avoidable at all? As I'm using plain image lightboxes I won't ever need to scroll whats inside the lightbox so its fine if the background page scrolls.
Not using any js...only the data attributes.
Thanks.

I think this is due to the following CSS rule:
html.with-featherlight {
	/* disable global scrolling when featherlights are visible */
	overflow: hidden;
}

I think you'll get what you want if you simply override it (with overflow: inherit).

I recommend this:
html.with-featherlight {     scrollbar-gutter: stable; }


Bump gtfs-lib for feed_id fix

Checklist

[x] Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
[x] Any modified or new methods or classes have helpful JavaDoc and code is thoroughly commented
[x] The description lists all applicable issues this PR seeks to resolve
[x] The description lists any configuration setting(s) that differ from the default settings
[x] All tests and CI builds passing

Description
refs conveyal/gtfs-lib#260

:tada: This PR is included in version 3.6.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket: