Dockerfile fails on "pip install" due to tensorflow-addons Lib issue

Bug description
tensorflow-addons releases have very limited versions, and the Dockerfile in the repo does not install as-is.
To fix this....
Replace "FROM python:3.8" to something like "FROM brunneis/python:3.8.3-ubuntu-20.04"
Code snippet to reproduce the bug
just build docker
Error traceback
Could not find a version that satisfies the requirement tensorFlow-addons
Environment
The TensorFlow library was compiled to use AVX instructions, but these aren't available on your machine.
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
Deep Learning backend
Type "help", "copyright", "credits" or "license" for more information.

from doctr.file_utils import is_tf_available, is_torch_available
The TensorFlow library was compiled to use AVX instructions, but these aren't available on your machine.
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted

Hello @clarkdong !
Thanks for this issue ! I have some questions regarding your environments:

are you running doctr on Windows, MacOS, Linux ?
can you give the exact model of your CPU please ?
it seems you are running an environment with QEMU and CPU flags are not passthrough in your virtual machine. Tensorflow has been compiled with AVX supports, that's why you have this error message
I don't understand the link with tensorflow-addons. Do you have a traceback which involves this problem ?

Thanks ! :-)

Hi @clarkdong :wave:,
tensorflow_addons is removed as dependency on main branch.
Could you test it again please ? :)

Tested on main branch without issues: (i think the tf-addons drop has solved it)
(doctr-dev) felix@felix-ThinkPad-L15-Gen-1:~/Desktop/doctr$ docker build .
[+] Building 187.1s (11/11) FINISHED                                                                                docker:default
 => [internal] load build definition from Dockerfile                                                                                0.1s
 => => transferring dockerfile: 552B                                                                                0.0s
 => [internal] load .dockerignore                                                                                0.1s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load metadata for docker.io/library/python:3.8-slim                                                                                1.6s
 => [internal] load build context                                                                                0.2s
 => => transferring context: 2.18MB                                                                                0.1s
 => [1/6] FROM docker.io/library/python:3.8-slim@sha256:a28effe2dc18af117dcf9bee09d618dbd72345f003c2d31b31a7042d9c052d42                                                    3.5s
 => => resolve docker.io/library/python:3.8-slim@sha256:a28effe2dc18af117dcf9bee09d618dbd72345f003c2d31b31a7042d9c052d42                                                    0.0s
 => => sha256:a28effe2dc18af117dcf9bee09d618dbd72345f003c2d31b31a7042d9c052d42 1.86kB / 1.86kB                                                                              0.0s
 => => sha256:b5b5e28ee70d0f23d8713328e0abfad8fd3babb062b04b8e93518f73bbe5db55 1.37kB / 1.37kB                                                                              0.0s
 => => sha256:d93876cc81ae12477300318e0c1f70d89067400d1e7f631e97daf47164b85545 6.96kB / 6.96kB                                                                              0.0s
 => => sha256:faef57eae888cbe4a5613eca6741b5e48d768b83f6088858aee9a5a2834f8151 29.12MB / 29.12MB                                                                            1.0s
 => => sha256:36578dff3c0fff67d9b9ae5e14142d1ac9db66c0d7257ac839d956ce63402d64 3.50MB / 3.50MB                                                                              0.7s
 => => sha256:dcd31b199ad3541f71a52d1d60496f3c56c43a3e99bc595fc985a8a13c2295fb 18.80MB / 18.80MB                                                                            1.5s
 => => sha256:c4e710c5c61bbed87b8c4894c2955e80179161242bc518b69fbd1160641d4ace 243B / 243B                                                                                0.9s
 => => sha256:55324d36570ccd5a61ddca04f37462ba16756940a187c422a5620de14a41a75a 3.13MB / 3.13MB                                                                              1.2s
 => => extracting sha256:faef57eae888cbe4a5613eca6741b5e48d768b83f6088858aee9a5a2834f8151                                                                                0.8s
 => => extracting sha256:36578dff3c0fff67d9b9ae5e14142d1ac9db66c0d7257ac839d956ce63402d64                                                                                0.1s
 => => extracting sha256:dcd31b199ad3541f71a52d1d60496f3c56c43a3e99bc595fc985a8a13c2295fb                                                                                0.4s
 => => extracting sha256:c4e710c5c61bbed87b8c4894c2955e80179161242bc518b69fbd1160641d4ace                                                                                0.0s
 => => extracting sha256:55324d36570ccd5a61ddca04f37462ba16756940a187c422a5620de14a41a75a                                                                                0.1s
 => [2/6] COPY ./pyproject.toml /tmp/pyproject.toml                                                                                0.4s
 => [3/6] COPY ./README.md /tmp/README.md                                                                                0.1s
 => [4/6] COPY ./setup.py /tmp/setup.py                                                                                0.1s
 => [5/6] COPY ./doctr /tmp/doctr                                                                                0.2s
 => [6/6] RUN apt-get update     && apt-get install --no-install-recommends ffmpeg libsm6 libxext6 -y     && pip install --upgrade pip setuptools wheel     && pip insta  165.3s
 => exporting to image                                                                                15.7s
 => => exporting layers                                                                                15.6s
 => => writing image sha256:5c00927ae6c52ec2fceb9a004be333730d06ac91c9e2383f67d585809c9d6407


Enable "find in selection" by default when replace executed against a multi-line selection

When doing a replace (in current file) and there is a selection that spans lines, the "find in selection" ought to be enabled by default.

I believe this is standard behavior in most other programmer's editors (visual studio, intellij, textpad++)
Ignoring the current context (multiple line selection) when doing a search makes no sense - why else would the use have made the selection then pressed replace?
For me at least, its pretty rare that I want to do a global search/replace.  This is certainly the least likely use case

We have a bunch of users who don't want to have this by default but we definitely can have a setting to define the default behavior, maybe named as autoFindInSelection or so. Let's track it in https://github.com/Microsoft/vscode/issues/15148.


fix show_all.sh after workspace improvement change

While investigating #167, I was using show_all.sh and realized that it had been broken by 46a9a23b6b3306f8919bc2d886bccb4c97c9e387, so this fixes it to work with the new folder layout.

hey there, thanks, missed that :)


Although targeted for .Net Standard 2.0 phonix is loaded by full framework

    Package 'Phonix 1.0.1' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETStandard,Version=v2.0'. This package may not be fully compatible with your project.

Hi @eldersantos,
I think I know what @AlbertoBN is talking about. When adding Phonix to the project you can see the warning

It looks like the project is targeting .NET Standard 2.0. Can you please check if your nuget package is targeting the same? Or is there any chance you didn't create a package after migrating to .NET Standard 2.0?

Hi @eldersantos 👋
As you can see above I've created a PR with a possible fix. I will be much obliged if you can please take a look.
Thanks for your work! 🙌

Hi @eldersantos
Any chance this PR could be merged in?

@lubiepomaranczki I just took a look at the package and I don't think your PR will fix the problem. Actually, the NuGet package only includes the net40 build. No update has been published since 2014.

@kawazoe I will take a look into this over the weekend, not sure too if the PR will work, so I need to test it

Did a push for a possible fix, v1.0.2 is already in Nuget, let me know any problems.

It looks good. The package now reference the netstandard2.0 lib. Though, you lost your package description in the update so you might want to fix that for SEO.

Yeah, I will fix that later, Nuget + VS + Nuget spec is not talking very well with each other ;(


Has anyone explained how to find the correct offset?

I encountered this error when using R3nzSkin.(Failed to find pattern:48 8B 05 ? ? ? ? 8B 58 0C)
Has anyone explained how to find the correct offset?

me too, but close the error window, still work.

I encountered this error when using R3nzSkin.(Failed to find pattern:48 8B 05 ? ? ? ? 8B 58 0C) Has anyone explained how to find the correct offset?

me too, but close the error window, still work.

In my comment in this issue https://github.com/R3nzTheCodeGOD/R3nzSkin/issues/760#issuecomment-1721908678 I explain how to fix this. Reply if it still doesn't work with error dialogs.


Metrics page refreshing bug on webkit based browsers

Start9 Team Comments:
Done: Bug Resolved
Time: 8 hours (Matt)
Dependency: None
The Metrics page on Embassy is refreshing page every time the metrics values change - making page scrolling unusable.
For example checking values from bottom section NETWORK is very hard because page reloads and begins from the top. Refer to attached gif file.

Tested on latest Brave and Safari.

Firefox is also affected but requires more time to refresh


@Scheduled is not instrumented and no trace context is created when aggregated in @Schedules

method annotated with *@Schedules * is not instrumented, so no trace context is created.

reproduction can be found in https://github.com/lrozek/sleuth-repro-2255
Please note below logs produced by the the simple application.

only job1 method has trace context established due to usage of @Scheduled
job2 method does not have trace context established. Single @Scheduled is aggregated in @Schedules
job3 method also does not have trace context established. This time two @Scheduled annotation are aggregated in @Schedules

My expectation is that @Scheduled is instrumented regardless of the usage, ie standalone (job1 method) or aggregated (job2 and job3 method)
2023-01-25 12:16:30.945  INFO [,ab2b3e2cc679dd0c,ab2b3e2cc679dd0c] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job1: LazySpan(ab2b3e2cc679dd0c/ab2b3e2cc679dd0c)
2023-01-25 12:16:35.927  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job2: null
2023-01-25 12:16:40.928  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job3: null
2023-01-25 12:16:45.926  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job3: null
2023-01-25 12:17:00.926  INFO [,9d324fbd7c802467,9d324fbd7c802467] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job1: LazySpan(9d324fbd7c802467/9d324fbd7c802467)
2023-01-25 12:17:05.926  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job2: null
2023-01-25 12:17:10.927  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job3: null
2023-01-25 12:17:15.927  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job3: null
2023-01-25 12:17:30.926  INFO [,343bf822476eb6bf,343bf822476eb6bf] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job1: LazySpan(343bf822476eb6bf/343bf822476eb6bf)
2023-01-25 12:17:35.927  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job2: null
2023-01-25 12:17:40.927  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job3: null
2023-01-25 12:17:45.927  INFO [,,] 37677 --- [   scheduling-1] pl.lrozek.schedulinginstrumenting.Jobs   : job3: null

Rather see https://github.com/spring-projects/spring-framework/issues/29883 (of which the above issue is a duplicate)


Service with NodePort + externalTrafficPolicy: Local does not expose port on worker nodes

As title says.
Is this expected behaviour?
I need to expose a GRPC service to a cloud load balancer but I lose Client IP information if I use externalTrafficPolicy: Cluster.
I've tried behind NGINX before but that is creating a slew of different issues relating to proxy timeouts that I cant seem to fix.
Any help would be much appreciated
inspection-report-20220309_102844.tar.gz

Hi @Firaenix, not sure if this issue is still relevant and/or valid. Stale bot notification got me here.
Unless I'm missing something from the issue description, https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip, using externalTrafficPolicy: Cluster should by design obscure the client IP address. Is this what you are experiencing?

Sorry I missed this notification, yes it's still valid.
Basically, if I set externalTrafficPolicy to Local on a service, any pods assigned to that service that get allocated to a Worker node, that is, not the control plane, are unreachable because the worker is not exposing the ports on the machine. Basically all traffic to that port on that worker node gets blackholed.

I am also experiencing this issue.  Would like to reopen this issue.

I opened a new issue here: https://github.com/canonical/microk8s/issues/4345


NISHTHA - Update the data in Enrollments and Completion by State/Course Name visual

Update the proper data in the visual once get from the Abhineet

Duplicate Issue Created.


Support for :em :i :strong :b

Support for :em, :i, :strong, and :b elements would be very helpful, as they are often supported in markdown as strong and emphasis elements.

Thanks for raising this. It should be possible with 0.14.0 to do the following:
(marge/markdown
 [:strong "Strong!"])

Strong!
(marge/markdown
 [:em "Emphasised!"])

Emphasised!


chore: update required advisory keys in check-data-keys

Removed spec.type as a required key as the create advisory task will calculate it for us so we don't need to pass it. Also removed issues.fixed as I think enhancement advisories may not have fixed issues.

Also removed issues.fixed as I think enhancement advisories may not have fixed issues.

First of all, can you reference a Jira in the commit message / PR description? How did we come up with the required fields in the first place? Hopefully there was some specification which said which fields were required? It would be good to know for sure if this field is required or not.

Nope, I don't have a JIRA for the check-data-keys task. That is why I didn't put one. I came up with the required fields in the first place by adding every key that was in the example advisory. I do not have a specification saying which fields are required. This is POC, minimal advisory work. In creating the task that generates the advisory, I figured an enhancement advisory may not have issues fixed, so I am removing it.

Also removed issues.fixed as I think enhancement advisories may not have fixed issues.

First of all, can you reference a Jira in the commit message / PR description? How did we come up with the required fields in the first place? Hopefully there was some specification which said which fields were required? It would be good to know for sure if this field is required or not.

Nope, I don't have a JIRA for the check-data-keys task. That is why I didn't put one.

Maybe there isn't a Jira specifically for this, but you're doing this as part of something that is in Jira, no? At least an Epic... Anything is better than nothing so that there is some context.

I came up with the required fields in the first place by adding every key that was in the example advisory. I do not have a specification saying which fields are required. This is POC, minimal advisory work. In creating the task that generates the advisory, I figured an enhancement advisory may not have issues fixed, so I am removing it.

OK, if it's a POC and not everything is set in stone yet, then it's fine.


Update SE-0382 to match feedback on API

We've decided that this is a Swift Syntax change that doesn't need to be re-reviewed, but that we should update the proposal text to match the adopted name.
Leaving this as a PR for now to be merged when the implementation matches.

cc @DougGregor

The implementation (https://github.com/apple/swift-syntax/pull/1367) just merged, so I'll merge this now. Thank you!


Error out when configuration key is unknown

Describe the problem/challenge you have
When a user provides configuration to kbld but that configuration contains a typo or a key that should not be part of the configuration, kbld does not error out or tell the user that the configuration has keys that kbld does not know off.
One example would be
apiVersion: kbld.k14s.io/v1alpha1
kind: Config
testing:
  to see:
    - if it fails

the key testing does not exist
Describe the solution you'd like
kbld should return an error saying something like
Error: Unable to read configuration, the key `testing` is not valid

Anything else you would like to add:
For a better UX maybe if it would be easy we should provide the line of the file where this error occurs. We should be mindful that maybe the configuration can be piped into kbld so there will be no filename.

Duplicated of #10


Json output for the kiota info command

This should ease the integrations and enable them to better automate processes.

@andreaTP would you mind adding the documentation for the new option in the documentation as well please?


[FLINK-5496] [mesos] Relocate Mesos Protobuf dependency to avoid version conflicts

This PR is based on #3155.
Only relocate Mesos Protobuf dependency in flink-mesos. This avoids problems with Mesos
because Flink pulls in Protobuf 2.5.0 via Flakka.

+1 to merge (I assume you've tested this)

Yes I did.

Thanks for your review @rmetzger. Merging this PR.


Exclude table permissions from /viz when show_permission=false

Related to https://github.com/CartoDB/support/issues/2291
When calling to api/v1/viz with show_permission=false, it now excludes both permissions from visualizations and related tables.

Tested in staging that the flag works as expected and everything seems to work fine :rocket:


Added a Home container

I am getting this error: Application Artist has not been registered
I tried changing things in the app registry and relay routes but to no avail.

Works!
⚠  However, this depends on both https://github.com/artsy/metaphysics/pull/313 and https://github.com/artsy/metaphysics/pull/337 to be merged first, so don’t merge yet.

yay!

Cool

This can now be merged.


As i was commiting my code to github i was not able view my code.

Hello, QT
As i was Once again commiting my code to github i was not able view my code. Iam attaching my output screen shot.

Hi vishwendh105,
what ever you commit's it will moved to local repository .if you want to see your commits  go with "git log "  it will shown your commit's details as like below mentioned snap
. if you want to see the code which your commited , enter pwd , it will show the path . you can find it there.

hi vishwendh, please elaborate your question.

When I was committing my code to GitHub through powershell. I am not able
to see my code which is committed  in my repo.
On Sun, May 31, 2020 at 8:24 PM srmanikanta<EMAIL_ADDRESS>wrote:

hi vishwendh, please elaborate your question.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/890#issuecomment-636482000,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMG5ZEKAIVPV3JAJBIOALODRUJVS5ANCNFSM4NPBUWKQ
.

use git push command and then check.

Tried using the Git Push but same result
On Sun, May 31, 2020 at 8:30 PM srmanikanta<EMAIL_ADDRESS>wrote:

use git push command and then check.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/QT-DevOps/DevOpsIssues/issues/890#issuecomment-636482775,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMG5ZENY5TKGGRZ3AKG7UJTRUJWJNANCNFSM4NPBUWKQ
.

post a screenshot of git push command

I have tried git push it was showing fatal showing fatal error have tried all the possibilities it showed and also attached the screen shot.

use this command git push vishwendh105 master

this works out $git push origin master

Hello, manikanta. I have used the command mentioned by you but it gives an error. Here is the screen shot of it.

do git pull operation before git push.


Integration tests are skipped

Currently, some of the tests for these integrations are skipped because the expected env var is not set:

~ragas~
~uptrain~
~deepeval~
[x] nvidia
[ ] gradient https://github.com/deepset-ai/haystack-core-integrations/pull/625
[x] astra https://github.com/deepset-ai/haystack-core-integrations/pull/623

It happens for different reasons. We should understand why and fix this issue.

API key for Nvidia integration added, integration tests should run now.

@silvanocerza yes!
Those with nvcf backend run fine: https://github.com/deepset-ai/haystack-core-integrations/actions/runs/8444638551/job/23146314844


NullPointerException for Business L&F under Java 9

Version of Substance
7.1.01
Version of Java
9.0.4
Version of OS
Windows 10
The issue you're experiencing (expected vs actual, screenshot, stack trace etc)
Hi, I've been working to upgrade my Java application to Java 9. I know it's not officially supported, so I modularized the jar file on my own by introducing a module-info.java file. It pretty much fully works except our old L&F, SubstanceBusinessBlackSteelLookAndFeel throws the below exception at runtime.
A non-business L&F such as SubstanceModerateLookAndFeel works fine.
Any idea what might have broken in SubstanceBusinessBlackSteelLookAndFeel ? In my module-info.java  I export and open every package (e.g. just to be super paranoid).

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at substance.org.pushingpixels.substance/org.pushingpixels.substance.api.painter.decoration.ImageWrapperDecorationPainter.getColorizedTile(ImageWrapperDecorationPainter.java:267)
	at substance.org.pushingpixels.substance/org.pushingpixels.substance.api.painter.decoration.ImageWrapperDecorationPainter.tileArea(ImageWrapperDecorationPainter.java:214)
	at substance.org.pushingpixels.substance/org.pushingpixels.substance.api.painter.decoration.ImageWrapperDecorationPainter.paintExtraBackground(ImageWrapperDecorationPainter.java:178)
	at substance.org.pushingpixels.substance/org.pushingpixels.substance.api.painter.decoration.ImageWrapperDecorationPainter.paintDecorationArea(ImageWrapperDecorationPainter.java:102)
	at substance.org.pushingpixels.substance/org.pushingpixels.substance.internal.painter.DecorationPainterUtils.paintDecorationBackground(DecorationPainterUtils.java:223)
	at substance.org.pushingpixels.substance/org.pushingpixels.substance.internal.painter.DecorationPainterUtils.paintDecorationBackground(DecorationPainterUtils.java:182)
	at substance.org.pushingpixels.substance/org.pushingpixels.substance.internal.painter.BackgroundPaintingUtils.update(BackgroundPaintingUtils.java:106)
	at substance.org.pushingpixels.substance/org.pushingpixels.substance.internal.ui.SubstanceMenuBarUI.update(SubstanceMenuBarUI.java:145)
	at java.desktop/javax.swing.JComponent.paintComponent(JComponent.java:798)
	at java.desktop/javax.swing.JComponent.paint(JComponent.java:1075)
	at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:908)
	at java.desktop/javax.swing.JComponent.paint(JComponent.java:1084)
	at java.desktop/javax.swing.JLayeredPane.paint(JLayeredPane.java:590)
	at java.desktop/javax.swing.JComponent.paintChildren(JComponent.java:908)
	at java.desktop/javax.swing.JComponent.paintToOffscreen(JComponent.java:5263)
	at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBufferedImpl(RepaintManager.java:1633)
	at java.desktop/javax.swing.RepaintManager$PaintManager.paintDoubleBuffered(RepaintManager.java:1608)
	at java.desktop/javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1546)
	at java.desktop/javax.swing.RepaintManager.paint(RepaintManager.java:1313)
	at java.desktop/javax.swing.JComponent.paint(JComponent.java:1061)
	at java.desktop/java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
	at java.desktop/sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:78)
	at java.desktop/sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:115)
	at java.desktop/java.awt.Container.paint(Container.java:1998)
	at java.desktop/java.awt.Window.paint(Window.java:3926)
	at java.desktop/javax.swing.RepaintManager$4.run(RepaintManager.java:868)
	at java.desktop/javax.swing.RepaintManager$4.run(RepaintManager.java:840)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89)
	at java.desktop/javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:840)
	at java.desktop/javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:815)
	at java.desktop/javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:764)
	at java.desktop/javax.swing.RepaintManager.access$1200(RepaintManager.java:69)
	at java.desktop/javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1880)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:764)
	at java.desktop/java.awt.EventQueue.access$500(EventQueue.java:97)
	at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:717)
	at java.desktop/java.awt.EventQueue$3.run(EventQueue.java:711)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:89)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:734)
	at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:199)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

There have been quite a few changes between 7.1 and the upcoming 8.0 releases. The stack trace lines at the very top in ImageWrapperDecorationPainter no longer match.
Just tried the main Substance demo app under Black Steel skin on Java 9 (which is fully supported even without modularizing Substance) and Windows 10, and I don't see any crashes.
If this is still happening for you under the latest development bits of Substance 8.0 (see migration guide at https://github.com/kirill-grouchnikov/substance/blob/master/www/release-info/8.0/release-info.md ) then I'll need to see a small, standalone and complete sample that reproduces this issue.

Also, until Substance and other projects move to Java 9 as the minimum runtime, there will be no modularization of these projects, so if this only happens under the locally modularized version of Substance, it's not going to be a priority on my side.

So, just your affirmation that it should be working lead me to trying the v8 dev version, which does line up better with the source code. In that way I was able to trace the problem to one that I had caused myself: the resource folder was not available which caused a variable to be nullified at init time. I'm sure 7 was working fine too. Thanks

Thanks for the confirmation. I'll move the brushed.gif from resource/ folder to another one that aligns better with the package structure of Substance.


arm_mat_qr_f32

Hello,
I have a question about the arm_mat_qr_f32 function regarding the threshold parameter. It appears that the threshold must be specified as a negative value. Is this intentional, or does it differ from the typical practice of using positive values for thresholds in similar functions?
Thanks all.

@yanlong658 Hello,
The threshold is positive. For instance, it can be one of the thresholds defined in the header dsp/matrix_functions.h
#define DEFAULT_HOUSEHOLDER_THRESHOLD_F64 (1.0e-16)
#define DEFAULT_HOUSEHOLDER_THRESHOLD_F32 (1.0e-12f)

Hello sir,
I have find it.
Thank you


1.2.1 Version compatibility

We already fixed 1.2.1 so that it can consume 1.2.0 modules, but it appears there's another issue, which is that because 1.2.2 modules will not be usable by 1.2.1, people will want to target 1.2.0 to make sure everyone can use their modules.  This is probably not what we meant with compatibility of the 1.2.x releases. As it is we have two options:

Make is so that 1.2.x "provides" 1.2.y for x >= y and x < y, but that means that applications won't be able to indicate depending on a specific fix or new API in the language module for version X+1, because distrib version X will pretend that it can run it. This will lead to runtime exceptions.
Keep it so that 1.2.x "provides" 1.2.y for x >= y, but allow a -target 1.2.0 flag for the compiler to produce code suitable for 1.2.0 distribs (and later, thus).

Either way has drawbacks, and the second way implies we only have backward compatibility in minor releases, not backward/forward compatibility like Java has in minor releases.

So the question comes down to whether it's ok to freeze the language module api for minor releases? That seems reasonable to me.
Note that the api for non-sealed interfaces has to be frozen in either case.

people will want to target 1.2.0 to make sure everyone can use their modules. That pretty much sucks

Yeah, and without flat-classpath-maven-style-version-resolution, non-shared imports won't be auto-upgraded. So a 1.2.0 targeted library will need to import ceylon.collection 1.2.0, and the old 1.2.0 version of ceylon.collection will actually be used at runtime. This form of version lock is no good. (With the "x >= y and x < y" approach, at least the library provider might choose a newer version, which is some help.)

The simplest thing would be to add support for a --target which would (right now) take affect during codegen. In other words we'd typecheck the module using the dist dependencies (1.2.1), but generate dependencies on the given version (1.2.0).
This works for ceylon.language because it's not in module.ceylon, but what should we do about  other dist modules such as com.redhat.ceylon.common? We ought to require a module import like
import com.redhat.ceylon.common "1.2.0";

but the 1.2.1 typechecker will reject this, since it can't typecheck it. So I suppose we have to require
import com.redhat.ceylon.common "1.2.1";

and then go changing that in the module descriptor.

This form of version lock is no good.

I agree, but take it up with the boss. This is a slightly independent issue to this one which is only about distribution modules, though.

@tombentley currently we force users to rewrite deps that they control, including dist modules. We could relax that error for dist modules with a --target that matches the one they import, and substitute it during compilation for the current dist like we do with dist overrides for typechecking, but keep it to the target version on generation.
I'm still very much on the fence about this form of backward-only compatibility that looks very much like  major releases.

Well for 1.2.1 (i.e. right now) we just need something which will allow people to compile stuff with 1.2.1 which runs on 1.2.0. For 1.2.2 (i.e. in the next few weeks) we can try to do something better resembling the right thing. I don't think what I outlined above is the right thing. But it's something simple which I can get to work today, rather than taking days while we thrash out what the right thing would even look like.

Except this implies we compile all the distrib modules + SDK + IDE deps with --target 1.2.0 and tell people to use that too if they want their stuff to be compatible.
A good test of your system may be the ceylon.test module which does depend on distrib modules in the SDK.

Well for 1.2.1 (i.e. right now) we just need something which will allow people to compile stuff with 1.2.1 which runs on 1.2.0.

And how will we do that if JS breaks binary compatibility (the Array stuff)?

Except this implies we compile all the distrib modules + SDK + IDE deps with --target 1.2.0 and tell people to use that too if they want their stuff to be compatible.

Well the alternative would be to make compatibility with 1.2.0 the default and have an option to let people depend on a more recent version. But that sucks because (at the moment at least) this is all a code generator thing -- you'd be typechecking against 1.2.1, but generating code which said 1.2.0. in other words it would be unsafe by default. And if we let any incompatible change slip through it would result in runtime errors.
Really we need the typechecker to typecheck using the given --target version of the language module. That would require it fetching it from herd. Plus there are a tonne of places where we assume "the language module" which would have to know the target version. That's surely doable, but not quickly.

I've got it so that the typechecker uses a language module that respects the --target which means we have to declare a 1.2.0 dependency for any distribution modules which we import, for example
import com.redhat.ceylon.common "1.2.0";

It seems to me that this is the right thing to do (i.e. the dependencies we typecheck against are precisely the declared verions), but it relies on having the necessary modules in your ~/.ceylon/repo.
The generated .car file runs on 1.2.0 exactly as you'd expect (since on 1.2.0 it's linking against the same 1.2.0 modules it was compiled against) and on 1.2.1 (which working via the compatibility stuff I did before Christmas, using the 1.2.1 modules at runtime). It now seems a bit weird to me that we go using 1.2.0 modules at compile time, only to decide at runtime to use the 1.2.1 modules. It makes sense if you have a 1.2.1 module wanting to use a 1.2.0 dependency, but if all your modules are 1.2.0, I'm not so sure.
I've not yet tested:

A module which uses the metamodel.
Whether we download any missing 1.2.0 distribution modules from the herd (assuming they're all there, but we can add them if not).
Surely there's a whole raft of other tests I need to do.

Thoughts please!

Whether we download any missing 1.2.0 distribution modules from the herd (assuming they're all there, but we can add them if not).

It gets downloaded automatically when doing a CLI build.

A module which uses the metamodel.

Looks like the metamodel "just works" (in the sense that you get the metamodel of which ever language module you run with)

So now "all" I need to do is figure out how to write tests for this. The tricky bit is running the compiled module in both 1.2.0 and 1.2.1. Any ideas better than "configure the tests with the location of a 1.2.0 install and run in a subprocess"?

I've pushed this to the target branch, if anyone wants to try it out.

The other questions is: did we test any of this with the IDE?

did we test any of this with the IDE?

No, not yet.
We also need to decide what the default behaviour is: should an omitted --target mean --target=${current-dist-version} or --target=1.2.0. Probably the latter, since it's best for the ecosystem. But that means that after downloading ceylon 1.2.1 the very first compile will end up dowloading the dist modules for 1.2.0.

Which is 10M and if it happened to me without any progress indication I'd just kill the compiler as hung. Damn.

Probably the latter, since it's best for the ecosystem. But that means that after downloading ceylon 1.2.1 the very first compile will end up dowloading the dist modules for 1.2.0.

To me that seems unacceptable, it would mean that someone who doesn't have an internet connection can't use Ceylon unless they specify --target=1.2.1
I find it very difficult to oversee the consequences of the choices we make, it seems very easy to make a big mess of it that might hurt us for versions to come. The fact that we're forced to bring out a new version ASAP so we can't say "let's try this for a couple of weeks to see what works best" only makes me more uncomfortable.

To me that seems unacceptable, it would mean that someone who doesn't have an internet connection can't use Ceylon unless they specify --target=1.2.1

Well we could include the 1.2.0 modules in the 1.2.1 dist, but that's not much of an alternative.
I suppose a better solution would be for the dist modules to always end up in ~/.ceylon/cache, so that a user who installed 1.2.x and then installed 1.2.(x+1) would already have the modules in their cache (because they'd been put there by 1.2.x) so they'd not be downloaded again. But that sounds complicated.

It would be well-worth investigating how hard it would be to decouple the compiler version from the language module version. Perhaps it's too hard. But perhaps it's not.

I don't think the compiler version is the issue here, at least on the JVM side we didn't break binary compatibility (and personally I think we should not break JS binary compatibility right now either and wait with those changes for 1.3).
With what I'm reading here it seems to me that the simplest solution would be to have the Ceylon compiler by default target the latest version and that people who want to publish on the Herd or need compatibility with 1.2.0 specifically say so. That you need an 1.2.0 version installed or in your cache when using --target=1.2.0 seems more logical. The Herd could perhaps warn when uploading code that depends on a language module with a non-0 release version?

So @gavinking on PM suggested two other options:

Make it so that on a 1.2.1 distrib, if any compiled/run module uses 1.2.2, then we auto-update the distrib modules to 1.2.2.
Keep it automatic that 1.2.1 provides/substitutes 1.2.0 modules, and make it optional (with a flag) that a 1.2.1 distrib provides/substitutes 1.2.2 modules. It may work, or not and then just download the 1.2.2 distrib.

My opinion on the first option is that it would make it impossible for people to "stick" to using a 1.2.1 distrib, if they determine that it works better for them because 1.2.2 has a compiler/runtime bug that affects them.
I quite like the second, because it means we don't need to add any default --target. Users of 1.2.1 who encounter a 1.2.2 module will get an error suggesting addition of a flag, try with the flag and if it works then great.

Is this something that is done on the cmr, or on the compilers/runtimes?

Is this something that is done on the cmr, or on the compilers/runtimes?

It's done by @tombentley don't worry ;)

I think you meant:

It's done by @tombentley. worry ;)

@FroMage

Then we auto-update the distrib modules to 1.2.2.

This means "let's pretend that 1.2.1 is 1.2.2" rigth? So we're not trying to download 1.2.2 here.
I agree that I like the second option better. Let's not go and download other versions or pretend by default to support things that might cause problems.

To answer your question @chocos it's mostly done in the JVM compiler. I've not considered the JS compiler at all, since there seems to be a whole range of opinions about what we should do for compatibility there.
It works by loading the language module according to the --target and the TC will use that language module at compile time. I think that's what @gavinking meant by " decouple the compiler version from the language module version". Previous work allowed the compiler and runtime to use 1.2.1 dist modules in place of 1.2.0 (in the absence of --target being given).

did we test any of this with the IDE?

No, not yet.

I have a patch for ceylon-ide-common which is enough to make the Eclipse IDE compile. It would need the attention of someone a little more versed in the IDE to add a project configuration option equivalent to passing --target on the command line.

We need to decide what we're doing here.
How about:

A missing --target means whatever the dist version is
We support supplying a --target from your .ceylon/config to avoid having to specify it every time.
In 1.2.1 and all future versions we ensure that dist modules automatically get copied into your ~/.ceylon/cache (or ~/.ceylon/repo).

We can't avoid the fact the --target is going to require people to download modules that didn't come with their dist. All we can do it make that as convenient as possible.

I agree with the first two. For the third I'm not sure. I guess it's a good idea.

I wonder if the cache would still be used in preference to the sysrep though, if that's the case it should probably rather be in the repo.

if that's the case it should probably rather be in the repo.

I thought the same at first, especially because on a Linux system your sysrep is probably not writable by you if Ceylon was installed using a package manager.
But on the other hand if no Ceylon was previously installed that could copy the car files to repo it would still fall on the CMR to download it which would put it in the cache. Then it becomes a bit of a hit and miss where Ceylon versions will appear, sometimes it's repo, sometimes it's cache. In that case perhaps I'd prefer to put it in the cache always.
For the other two points: "agreed" on the first and "duh, obviously" on the second ;)

In order to compile the SDK with --target=1.2.0 we need to decide what to do about those modules which import dist modules. The main difference of these wrt the language module is they're explicitly imported in module descriptors. I suppose we should change the versions of dist modules to those versions which we shipped with 1.2.0. At runtime on 1.2.0 that will just work, and on 1.2.1 they should be upgraded using the dist overrides mechanism.

That's a little tricky though because ceylon.war has grown a dependency on com.redhat.ceylon.tool.provider which didn't exist in 1.2.0.

If I downgrade the dist module versions imported by the SDK and don't compile ceylon.war then I'm able to compile the sdk using --target. But I can't run the tests using ceylon.test. That could be a bug in ceylon.test, but it's not exactly clear.

Related? https://github.com/ceylon/ceylon/issues/5944

No, I don't thik that's the same issue. What I see looks like (when running with jboss modules 1.3.3.Final):
test-jvm:
[ceylon-test] ceylon test: null
[ceylon-test] java.lang.NullPointerException
[ceylon-test] 	at ceylon.test.engine.internal.Workaround.loadModule(Workaround.java:12)
[ceylon-test] 	at ceylon.test.engine.internal.Runner$1loadModule_.loadModule(Runner.ceylon:132)
[ceylon-test] 	at ceylon.test.engine.internal.Runner.initializeTestedModules$priv$(Runner.ceylon:136)
[ceylon-test] 	at ceylon.test.engine.internal.Runner.run(Runner.ceylon:30)
[ceylon-test] 	at ceylon.test.runTestTool_.runTestTool(tool.ceylon:9)

@thradec: any idea?

It seems that org.jboss.modules.Module.getCallerModuleLoader returned null, and its documentation says ...

@return the current module loader, or {@code null} if this method is called outside of a module

... but I have no idea, how it could happen.

After a lot of discussion it seems that --target probably isn't what we want/need for 1.2.1. One of the problems is it's a thing which is global to a whole project (assuming you want to compile a project "in one go"). The situation with ceylon.war means we can't use that unless we can specify the target on a per module level. Having it as a compiler option also means there's information you need to build a module which is not contained in the module descriptor. Instead it gets buried in build scripts or config files (which might not even be committed to version control). Even if we fixed this (by allowing to explicitly import ceylon.language in the module descriptor, for example), the IDE doesn't support having two language modules in the same project (such as the SDK), and it would take quite a lot of work to make it do that.

Instead it gets buried in build scripts or config files

And not only that, the Herd doesn't have a way either to store that information. So in general the module descriptor seems like a better place.
The idea was to allow people to specify the language module import explicitly. But although this is a glad idea in general we should try to do the best we can even when lacking that information

So we said we needed a flag (for ceylon compile, doc and run) to pass a policy about what to do when a module has a dist dependency at a version > the current dist version. The policy could be one of:

Download it from the herd
Try to run with what I have locally (might fail with a linker error)
Immediately give up.

That would be fine for ceylon.language, but one problem is that we don't actually know which modules are dist modules for 1.2.2 and above. I suppose that means there are circumstances (a module gets added to the dist) where we don't apply the given policy, and get the default behaviour (download modules missing locally).

We agreed that for 1.2.1 we runtime the options are:

auto upgrade of past versions to the current dist (i.e. 1.2.0, this is already implemented via dist-overrides)
an implied downgrade would result in an error. Because jboss modules is lazy it would be possible for this error to happen after at some point after the program has started.
it's possible to explictly downgrade the ceylon.language version using some --force-current-dist flag.

This would work by having the flag switch between one of two dist overrides, one (the default) which upgrades 1.2.0 to 1.2.1 and another which simply sets 1.2.1 globally.
At compile time we always use 1.2.1. It would be an error for another version to be used (for example, in a user supplied overrides.xml). Obviously modules which import other modules which were compiled with 1.2.0 are allowed (as currently exists using dist-overrides).
The only thing is that, lacking an explicit linker phase, we have that error happening at some point during runtime. That should not a problem though, because how could we have compiled a module that itself depended on 1.2.1 but whose dependency depended on 1.2.2?

Done except for figuring out what should happen with --flat-classpath

So what happened to --force-current-dist? I prefer it as it's version-independent and can be used defensively while --downgrade-dist sounds like it will only work if we need to downgrade, and not if the dist matches.

Can you explain what the issue is with --flat-classpath?

So what happened to --force-current-dist?

Same thing with a different name. I suppose --force-current-dist better describes what it does, but I don't really think either name is quite right. Maybe --link-current-dist would be better?

Fine.

--use-current-dist ?

Fine as in "leave it as --downgrade-dist" or as in "let's change it to --link-current-dist"?

I'm finding that all language module versions are being replaced with 1.2.1 when using default settings for pretty much everything.
Since I'm using 1.2.1-DP2-SNAPSHOT as the language module version for the Dart backend, this causes an error:
cannot find module artifact ceylon.language-1.2.1.dart
    - dependency tree: default/unversioned -> ceylon.language/1.2.1-DP2-SNAPSHOT
    get ceylon.language and run 'ant publish' (more information at http://ceylon-lang.org/code/source/#ceylonlanguage_module)

Compiling w/the following commented out in cmr/api/src/main/resources/com/redhat/ceylon/cmr/api/dist-overrides.xml:
      <replace module="ceylon.language" version="1.2.0">
        <with module="ceylon.language" version="1.2.1"/>
      </replace>

disables the dist-upgrade replacement and fixes the problem I'm having. But that seems a bit strange since it means the "replace" version 1.2.0 is being ignored.
I'm still looking for a workaround for the Dart backend. I suppose I always need to create my own input RepositoryManagers, and make sure they have dummy Overrides, somehow. OTOH, might it be better for the default behavior to be to not muck with a backend's idea of the correct module versions to use? That is, neither upgrade nor downgrade by default?

@jvasileff the auto-upgrade behaviour has been the default for a while now (since December in fact), so I don't understand why this is breaking your stuff now.
But nor do I understand why the replace version is being ignored. So this is something I need to fix.
I toyed with making the flag --dist-upgrade=(upgrade|downgrade|abort), but the problem is that the way this works (via Overrides) means it's not trivial to implement abort -- you'd need the CMR to return a resolution error when trying to use the "banned" module.

@tombentley oh, ok.  I probably also commented out:
    <define name="dv" value="1.2.1"/>
    <set module="ceylon.language" version="${dv}"/>

so it's actually a downgrade. I'll run another test to confirm.
It does appear, at least now, that upgradeDist defaults to false in CeylonRepoManagerBuilder, thereby making downgrade the default.

Confirmed. It's the dist-downgrade that's giving me trouble, which now appears to be the default.

OK, so I just need to fix the default
On 2 Feb 2016 6:21 pm, "John Vasileff"<EMAIL_ADDRESS>wrote:

Confirmed. It's the dist-downgrade that's giving me trouble, which now
appears to be the default.
—
Reply to this email directly or view it on GitHub
https://github.com/ceylon/ceylon/issues/5889#issuecomment-178734755.

@jvasileff's problem should now be fixed, which means in theory this can be closed, right @FroMage?

So what's the name of the flag now? :)

Well you never answered my question:

Fine as in "leave it as --downgrade-dist" or as in "let's change it to --link-current-dist"?

so it's still downgrade dist. Speak now or forever hold your peace if you want it to be something else.

Man you seriously disappoint me, I thought you could read my mind my now…
I meant "Fine" as "let's change it to --link-with-current-distribution" (since we avoid abbrevs)

Hmm. That doesn't quite work for things like ceylon classpath which isn't really doing any linking. Maybe --resolve-with-current-distribution would be better?

Well, depends what you call linking. ceylon classpath gives you a link path, IMO that's still linking.

Renamed.

Well you never answered my question

Well you also totally ignored my suggestion :-p

Sadly, I can only satisfy one opinion at a time.

Forgot the ant tasks will need a `link-with-current-distribution="true" attribute...

And I suppose ceylon test needs to support this as well.


Clean up auto-scrolling code.

This doesn't fix anything yet.  In particular, we still have the spurious you-must-scroll messages.
Hope to make more progress here soon, as well as adding some test coverage.

Merged, thanks @showell!


schema: fix name of dockerfile_inline field in YAML

Missing Go struct tag here, so the field name in YAML was actually dockerfileinline.
(This isn't a breaking change: it was a mistake/broken before and not even usable since the schema validation would prevent you from using the typo'd field name.)
See also:

docker/compose#10456

In my case a clean debian 11 install and compose installation instructions here:
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
lead to reproduciblity of the bug.
It looks like the official docker ppa suffers from this regression.
Fortunately enough I have dev/pre-prod/prod mechanisms, so only the dev box is affected. Nevertheless the bug forces me to rollback the version, and that leads to an environmental inconsistencies and so on and so forth... such a nuisance.
Hot-fix would be much appreciated, thanks.


Docs: Add 0.8.0 to changelog

[ci skip]

(When editing source directly on GH website, only option is to open new PR, AFAICT)

Thanks for taking care of this!


Failed to parse KDL

I use Zellij with following config:
theme "catppuccin-mocha"
default_layout "compact"
default_mode "locked"
on_force_close "quit"
simplified_ui true

ui {
    pane_frames {
        hide_session_name true
    }
}

keybinds {
shared {
        bind "Alt p" { SwitchFocus; }
        bind "Alt o" { NewTab; }
        bind "Alt ]" { GoToNextTab; }
        bind "Alt [" { GoToPreviousTab; }
        bind "Alt n" { NewPane; }
        bind "Alt m" { NewPane "Down"; }
    }
}

https://kdl-play.danini.dev/ check my config with no problem, also Zellij can load it but kdlfmt fails to parse it.
❯ kdlfmt check ~/.config/zellij/config.kdl
Error parsing file '/Users/anon/.config/zellij/config.kdl' - Failed to parse KDL.

kdlfmt is simply a wrapper around the official kdl crate for Rust  (kdl-rs), which sadly does not have a cli. Any formatting/parsing errors should be reported there.
The error you are getting is because the kdl-rs crate is in the progress of being rewritten to kdl specification v2, but zellij uses kdl v1.
I have downgraded the kdl-rs crate back to the latest stable version using kdl v1, since most kdlfmt users are most likely using it for zellij configuration. Installing the newest version of kdlfmt should fix your issue 😄

Thank you @hougesen l, til there is 2 version of kdl.


Does unspents() work with taproot addresses?

I did faucetComplex() to send regtest coins to my TR address.  I can see the txn in fetch(txId), mine() is ok.
But when I try unspents() on a taproot address, I get a 400 error.  Here's the curl:
$ curl -vvvv http://localhost:8080/1/a/bcrt1pk8pcxnep6l54s603k6m9atzajy5acfu4d9xgewcre6mfjwt7cudqseqw9x/unspents; echo
*   Trying <IP_ADDRESS>:8080...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 8080 (#0)
> GET /1/a/bcrt1pk8pcxnep6l54s603k6m9atzajy5acfu4d9xgewcre6mfjwt7cudqseqw9x/unspents HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Access-Control-Allow-Origin: *
< Date: Sun, 07 Jan 2024 01:34:11 GMT
< Connection: keep-alive
< Content-Length: 0
<
* Connection #0 to host localhost left intact

No problem if a segwit address:
$ curl http://localhost:8080/1/a/bcrt1qcr8te4kr609gcawutmrza0j4xv80jy8zeqchgx/unspents; echo
[{"txId":"408efa8731f11e0f10e06135b77b8821e997364048ab0b96a54d384b54857b79","vout":1,"height":439,"value":20000,"coinbase":0},{"txId":"b12fd45da4251bdd54ca7a54900cc8cd5473718a681ef54571af621315eb1057","vout":0,"height":573,"value":20000,"coinbase":0}]

I am using regtest-server docker.
No log messages appear in docker when this 400 error happens.

It only works if you pass the scriptPubkey as hex.
You should convert the taproot address into an output script (starts with the two bytes 5120 then the 32 byte key) and pass it as a hex string in place of the address.

Thank you
You rule.  It works:
const unspents = await regtestUtils.unspents(output.toString('hex'))

where output is returned by bitcoin.payments.p2tr()


How to process all ports as features

The current way that ports are processed as features is by limiting port number < config['max port'] here with is 1024 by default.
Based on this paper, IoT devices are using ports numbers greater than 1024.
Ideally, all ports that are used should be used as features. However, set max port=65535 will create a huge feature vector where most of its value is zeros.
What I am proposing is to use two lists during the training (ports_list and ports_freq). Such that ports_list contains only the ports witnessed in the dataset and ports_freq counts its frequency.
What do you think?

@gregs5 - You are right learning from server/services ports is what we are looking for not the emphemeral ports.
That paper (http://www2.ee.unsw.edu.au/~vijay/pubs/conf/17infocom.pdf) is the one that you gave me the link for its dataset before :). It shows (in TABLEI) that ten IoT devices use services with ports > 1024 (actual service distination ports not empherals).

@alshaboti I think your proposal makes sense - I'd be happy to review a PR with the proposed changes if you'd like to cook something up. thanks!

Since the ML results and vector representations are already stored in Redis, that seems like a good place for this list as well?

@alshaboti An overhaul of the featurizer might be in order. I've opened issue #84 to explain the rationale behind this. Until that's actually implemented, though, I think your solution is probably reasonable... though I would caution that if you could code the ingesting of ports and their counts so that users and subsequent coders don't have to manually keep track of the ordering, that would be ideal. Perhaps use of a dictionary that could then be flattened/standardized for use by other functions?

So thinking about this a bit more, since the list will be needed for both training and evaluation/testing it probably doesn’t make sense to use Redis, since it won’t necessarily be the same instance at training and evaluation times.  It probably makes more sense to include it in the pickled model, or possibly as a supplemental file alongside the model.  Open to ideas there.

@alshaboti open to seeing what that looks like. it might work?

This is now doable using the featurizer to create functions of whatever ports you want as features.


mem-ruby: Fix for not creating log entries on atomic no return requests

Augmenting Datablock and WriteMask to support optional arg to distinguish between return and no return. In the case of atomic no return requests, log entries should not be created when performing the atomic.
Change-Id: Ic3112834742f4058a7aa155d25ccc4c014b60199a

Not sure if the flow has changed, but is there anything I need to do to have the unit tests begin running on this PR? Seems like they're stalled, waiting on some approval before beginning (been stalled in this state since last night). From the "gem5: A guide to contributing" it mentions that "Once you have created a pull request, the gem5 Continuous Integration (CI) tests will run."

Is there a way to see more details on why certain tests are failing? When I click the "Details" option on the "CI Tests / unittests-all-opt (pull request)" tab, it takes me to a page that only says "This job failed." I tested my PR locally with scons build/NULL/unittests.opt, and all the tests that were enabled passed. Just trying to see if this is a runner issue (e.g. runner failed to launch tests and that's the 'failure'), or if this is a true error, and how I can reproduce it locally to debug.

Is there a way to see more details on why certain tests are failing? When I click the "Details" option on the "CI Tests / unittests-all-opt (pull request)" tab, it takes me to a page that only says "This job failed." I tested my PR locally with scons build/NULL/unittests.opt, and all the tests that were enabled passed. Just trying to see if this is a runner issue (e.g. runner failed to launch tests and that's the 'failure'), or if this is a true error, and how I can reproduce it locally to debug.

I don't know if it's the issue here or not, but the unit tester has been flaky and failing randomly the last couple days.  Not sure if we want to try rerunning first (don't know the answer to your question though).

I can't seem to add a comment outside the range of a hunk, but the new Atomic CoherenceRequestTypes need to be added to the directories.  This fixes the atomic test:
+++ b/src/mem/ruby/protocol/MOESI_AMD_Base-dir.sm
@@ -402,7 +402,9 @@ machine(MachineType:Directory, "AMD Baseline protocol")
           trigger(Event:RdBlkM, in_msg.addr, entry, tbe);
         } else if (in_msg.Type == CoherenceRequestType:WriteThrough) {
           trigger(Event:WriteThrough, in_msg.addr, entry, tbe);
-        } else if (in_msg.Type == CoherenceRequestType:Atomic) {
+        } else if (in_msg.Type == CoherenceRequestType:Atomic ||
+                   in_msg.Type == CoherenceRequestType:AtomicReturn ||
+                   in_msg.Type == CoherenceRequestType:AtomicNoReturn) {
           trigger(Event:Atomic, in_msg.addr, entry, tbe);
         } else if (in_msg.Type == CoherenceRequestType:VicDirty) {
           if (getDirectoryEntry(in_msg.addr).VicDirtyIgnore.isElement(in_msg.Requestor)) {
@@ -746,7 +748,9 @@ machine(MachineType:Directory, "AMD Baseline protocol")

         // CPU + GPU or GPU only system
         if ((in_msg.Type != CoherenceRequestType:WriteThrough &&
-             in_msg.Type != CoherenceRequestType:Atomic) ||
+             in_msg.Type != CoherenceRequestType:Atomic &&
+             in_msg.Type != CoherenceRequestType:AtomicReturn &&
+             in_msg.Type != CoherenceRequestType:AtomicNoReturn) ||
              !in_msg.NoWriteConflict) {
           if (noTCCdir) {
             probe_dests.add(mapAddressToRange(address, MachineType:TCC,

I don't think the other directories are even used but wouldn't hurt to make the same change there too.


ODBC stored procedure

How i can get the data then of execute a stored procedure? in the documentation use the class procedure but only calls the ST.
Thanks!

@mloskot Should we close this? I suspect it is not an real issue.

Good catch. Thx


Checking in executable files, should this be excluded in the git ignore file

Executable files have been checked in; does this need to be added to .gitignore or has it been accidentally committed?
zig-out/bin

Definitely not


[atlantis]: implement helmfile using monochart

what

Implement helmfile using monochart
Here are sample envs :https://github.com/cloudposse/atlantis/blob/master/helm/atlantis/templates/statefulset.yaml

why

The official chart uses hardcoded envs, so it's a pain to extend. Our monochart is more flexible.

Here's how we deployed it with ECS: https://github.com/cloudposse/geodesic-aws-atlantis/blob/master/Makefile
You can use the cloudposse/root.cloudposse.co docker image which has our flavor of atlantis for testing.


Infinite load for some projects

Hi Morten, I just recently started using your wonderful ad-on to VS, and I love it!  However, I have noticed an odd problem.  In one of my VS solutions, the test adapter loads forever and never finishes (green bar always scrolling, "Run All" always grayed out), which means I cannot run any tests.
Here is my karma.conf.js file, which is included in the solution:
// Karma configuration
// Generated on Wed Oct 08 2014 13:34:17 GMT-0400 (Eastern Daylight Time)

module.exports = function (config) {
config.set({

    // base path that will be used to resolve all patterns (eg. files, exclude)
    basePath: '',

    // frameworks to use
    // available frameworks: https://npmjs.org/browse/keyword/karma-adapter
    frameworks: ['jasmine'],

// list of files / patterns to load in the browser
files: [
    'DNDGenSite/Scripts/Angular/angular.min.js',
    'DNDGenSite/Scripts/Angular/angular-mocks.js',
    'DNDGenSite/Scripts/app/**/*.module.js',
    'DNDGenSite/Scripts/app/**/*.js',
    'Tests/Unit/Scripts/**'
],

    // list of files to exclude
    exclude: [
    ],

    // preprocess matching files before serving them to the browser
    // available preprocessors: https://npmjs.org/browse/keyword/karma-preprocessor
    preprocessors: {
    },

    // web server port
    port: 9876,

    // enable / disable colors in the output (reporters and logs)
    colors: true,

    // level of logging
    // possible values: config.LOG_DISABLE || config.LOG_ERROR || config.LOG_WARN || config.LOG_INFO || config.LOG_DEBUG
    logLevel: config.LOG_INFO,

    // enable / disable watching file and executing tests whenever any file changes
    autoWatch: true,

    // start these browsers
    // available browser launchers: https://npmjs.org/browse/keyword/karma-launcher
    browsers: ['PhantomJS'],

    // Continuous Integration mode
    // if true, Karma captures browsers, runs the tests and exits
    singleRun: true,
    reporters: ['progress', 'junit'],
    junitReporter: {
        outputFile: 'unit-specs.xml',
        suite: 'unit'
    }
});
};

In different solutions, the adapter works just fine - it finds all the Karma tests and auto-runs them, showing them in the test explorer.  I'm not sure what the differences are here.
In both solutions, I installed karma via npm install karma --save-dev
Is this an issue with something I have configured, or possible an error in your add-on?  If you need any additiona information (or for me to file this in a different place), please say so, and I will be more than willing to oblige :)
Many thanks for a great tool!

This might be a long shot, but I had what seems to be the same issue. My problem was that I had removed the plugins property from the config file (which specified the karma-phantomjs-launcher plugin) at some point and I forgot to re-add it – i.e.
        plugins: [
          'karma-phantomjs-launcher`
        ],

Does adding this to your config file fix your problem?

Unfortunately, I have moved on and am now using Chutzpah instead.  Sorry :(  But I do know that I that property was not set in my config files, so that could very well have been the issue.


UnhandledPromiseRejectionWarnings thrown in Unit Tests

When running this test suite:
describe('after resetStore', () => {
We see the following log alerts:
yarn run test -t "resetStore"
yarn run v1.3.2
$ jest -t resetStore
(node:4409) UnhandledPromiseRejectionWarning: TypeError: Cannot set property 'loading' of undefined
(node:4409) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a ca
tch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:4409) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate
 the Node.js process with a non-zero exit code.
(node:4409) UnhandledPromiseRejectionWarning: TypeError: Cannot set property 'loading' of undefined
(node:4409) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a ca
tch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:4409) UnhandledPromiseRejectionWarning: TypeError: Cannot set property 'loading' of undefined
(node:4409) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a ca
tch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 3)

This is still occurring!

It looks like this was fixed at some point:

Closing - thanks for reporting this @fbartho!


Testing thunks

I have dead simple pure actions and reducers. The majority of my 'business logic' is in async action thunks (using just redux-thunk). I am testing these (using expect & mocha). It's good, but I ran into a repetitive pattern: 1) setup preconditions, 2) run the action, 3) review the pure actions that resulted.
What is a good way to review these pure actions that resulted?  store.subscribe(...) gives access to the state, but I want a trail of actions. I thought of middleware, but that means modifying the way my middleware chain works and using a different configureStore type function only for testing. Is that the best way?
Edit: I realize this is a question/discussion, and would be happy to move it to a better place than an issue.

#546 answers this, sorry for the noise.

And the recipes


There is an unused folder visibility configuration in the content module

There appears to be a configuration for folders visibility in both the oae-content/config/content.js and oae-folders/config/folders.js file.
Only the oae-folders/config/folders.js is used, so we should be able to just remove the oae-content version of this configuration.

Assigned to @simong for review


may install this module use pod ?

how to use pod install this module  ？
Or is there any project using this project.

There is no CocoaPods release. I don't think there is any project using this. The framework is an UI that can be embedded in other apps. But, for running commands and building your own terminal, you can use ios_system (doesn't support CocoaPods). <- This library contains the commands.

If you want to embed the UI of this app in another app, You can download the pre-built framework: https://github.com/ColdGrub1384/LibTerm/releases/tag/1.5. Libraries mentioned in the release notes must also be installed, then, for using it, it's in the README.md.


[Select] the text is cleared automatically --bug

ElementUI version
1.1.2
OS/Browers version
OS: macOS Sierra 10.12.2 (16C67)
Browser: Chrome 55.0.2883.95

Note: I also tested this bug on Safari, Firefox and MS Edge

Vue version
2.1.8
Reproduction Link
https://jsfiddle.net/gil0mendes/fj9efd5a/2/
Steps to reproduce
You need create a el-select with the allow-create and filterable enabled.
What is Expected?
Is supposed write any text without clean the text off.
What is actually happening?
When you write something passed some milliseconds the text will be cleared to the last selected text.

This issue can be closed, this problem was fixed on merge #2186.


Add example for theming

After releasing the updated UI in graphiql@2 users will be able to override our CSS variables to create their own theme (colors, spacing, etc.) for GraphiQL. We should also add an example to the examples folder that demonstrates how to make this happen.

We can add to one of the webpack/vite/etc examples, but ideally a bundler-free config as well. From rough estimates from CDN stats and NPM stats, about half our users still don't even use a bundler to configure/ship their custom graphiql implementation!

it would be cool if we linked to open source framework implementations of graphiql with custom 2.x themes. We can work with the authors of the implementations in this list to improve if needed
@patrick91 would you and @benjie like for your frameworks to be on this list? Do you do or need much more style customization? @lekoarts would love to make the gatsby custom theme implementation a point of reference as well! Let us know what improvements we can make

@patrick91 would you and @benjie like for your frameworks to be on this list? Do you do or need much more style customization? @LekoArts would love to make the gatsby custom theme implementation a point of reference as well! Let us know what improvements we can make.

I haven't done any custom theme yet, but I think we might do something at somepoint 😊, so yes!

I'll be releasing a new PostGraphiQL along with PostGraphile V5 sometime next year, so no point linking to our old one since it's way out of date. Will definitely be in touch for help at the relevant times though - thanks!

@acao I've been playing a bit with theming and the way it is currently setup makes it quite difficult to customise things, if I understood correctly we should be able to use the following variables:
.graphiql-container,
.CodeMirror-info,
.CodeMirror-lint-tooltip,
reach-portal {
  --color-primary: 52, 99%, 57%;
  --color-secondary: 243, 100%, 77%;
  --color-tertiary: 188, 100%, 44%;
  --color-info: 208, 100%, 72%;
  --color-success: 158, 100%, 42%;
  --color-warning: 30, 100%, 80%;
  --color-error: 13, 100%, 58%;
  --color-neutral: 253, 82%, 30%;
  --color-base: 219, 29%, 18%;

  --popover-box-shadow: none;
  --popover-border: 1px solid hsl(var(--color-neutral));
}

to customise the colors, but they are usually used in combination with hsla, which makes it difficult to have a specific color for a specific section, for example both the background and the text color depend on --color-neutral
maybe we can have more granular variables, that default on the current values?

Having separate variables to control font and background colors make sense to me! @patrick91 Would you mind opening a dedicated issue for that? Do you run into more problems where you'd need more control?


Upgrade to appengine-maven-plugin 1.0.0

Update plugin version to 1.0.0, via property in parent pom.

Obsolete. The only place we use the appengine-maven-plugin now is in the test-war-hello, and the version is not specified there, meaning that Maven will pick the latest.


Remove "Genetic associations (genes)" column from associations heatmap

Due to changes in the development API, the datatypes have changed and the "Genetic associations (genes)" column is now blank as there is no data. For example, see the inflammatory bowel disease associations page.

Can we please remove this column?

In the static file we need to:

remove: Genetic associations (genes) aka genetic_literature
rename: Genetic associations (variants) aka genetic_associations -> Genetic associations

Looks great. Thanks @mirandaio


Tests failing when change profile in use

Hey all,
I'm authenticating to AWS accounts via shared credentials file, stored in regular path(/home/$USERNAME/.aws/credentials). When I run my simple test that is checking if 4 created subnets are public using "default" profile(my testing AWS account) it all works well, test is passing.
When I change the profile used to clients AWS profile, passing this info as variable in provider block:
provider "aws" {
region  = var.region
profile = var.profile
}
Test is failing... Interesting fact, when i check AWS console in parallel with test, I see with my own eyes that everything is deployed correctly to correct AWS account, but for some strange reason test is reporting that there are 0 subnets present, when it is expecting 4. Questionable code block from test:
func TestLaunchpadDrVpc(t *testing.T) {
t.Parallel()
// Define variables for passing into Terraform
// These variables are expected by Terraform and must be provided
dRsubnet1Cidr := "***.***.***.***/**"
dRsubnet2Cidr := "***.***.***.***/**"
dRsubnet3Cidr := "***.***.***.***/**"
dRsubnet4Cidr := "***.***.***.***/**"
dRawsRegion := "eu-west-1"
dRawsProfile := "clientname"
// billingTag := "clientname"
// envTag := "testing-dr"

terraformOptions := &terraform.Options{
	TerraformDir: "../examples/test-example",

	Vars: map[string]interface{}{
		"subnet1_cidr_block": dRsubnet1Cidr,
		"subnet2_cidr_block": dRsubnet2Cidr,
		"subnet3_cidr_block": dRsubnet3Cidr,
		"subnet4_cidr_block": dRsubnet4Cidr,
		"region": dRawsRegion,
		"profile": dRawsProfile,
		// "billing_code_tag": billingTag,
		// "environment_tag": envTag,
	},
}

// This will run when test end - terraform destroy
defer terraform.Destroy(t, terraformOptions)

// Initalizing and applying terraform code
terraform.InitAndApply(t, terraformOptions)

dRsubnet1Id := terraform.Output(t, terraformOptions, "subnet1_id")
dRsubnet2Id := terraform.Output(t, terraformOptions, "subnet2_id")
dRsubnet3Id := terraform.Output(t, terraformOptions, "subnet3_id")
dRsubnet4Id := terraform.Output(t, terraformOptions, "subnet4_id")
dRvpcID := terraform.Output(t, terraformOptions, "vpc_id")

dRsubnets := aws.GetSubnetsForVpc(t, dRvpcID, dRawsRegion)

require.Equal(t, 4, len(dRsubnets))

assert.True(t, aws.IsPublicSubnet(t, dRsubnet1Id, dRawsRegion))
assert.True(t, aws.IsPublicSubnet(t, dRsubnet2Id, dRawsRegion))
assert.True(t, aws.IsPublicSubnet(t, dRsubnet3Id, dRawsRegion))
assert.True(t, aws.IsPublicSubnet(t, dRsubnet4Id, dRawsRegion))

}
When I change region that is being used, with default profile, it all works. Issue starts when I change the profile(AWS account) that is used.
Bare in mind that my knowledge of Go is close to 0.
Please help...

This is an issue with how terratest handles authentication in the aws modules. Specifically, currently there is no way to modify which profile it assumes in the code.
We built it this way because the philosophy behind terratest is that which account you run the tests in should be provided to it from the environment, as opposed to in the test code. So the suggested way to handle your use case is to set the environment variable AWS_PROFILE when calling out to go test:
AWS_PROFILE=clientname go test -v -timeout 90m .

This is an issue with how terratest handles authentication in the aws modules. Specifically, currently there is no way to modify which profile it assumes in the code.
We built it this way because the philosophy behind terratest is that which account you run the tests in should be provided to it from the environment, as opposed to in the test code. So the suggested way to handle your use case is to set the environment variable AWS_PROFILE when calling out to go test:
AWS_PROFILE=clientname go test -v -timeout 90m .

I confirm that this solved my issue... Closing this thread...
Thank you very much!

Just for the next person that runs into this and putting a note here about it.  If you are assuming a role via a source_profile like:
[profile1]
aws_access_key_id = aaaaaaaaaaaaaaaaaaa
aws_secret_access_key = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

[profile2]
role_arn = arn:aws:iam::111111111111:role/my-role
source_profile = profile1
role_session_name = profile1-session-name

You will need to set the AWS_SDK_LOAD_CONFIG envar like:
AWS_SDK_LOAD_CONFIG=1 AWS_PROFILE=clientname go test -v -timeout 90m .

This doc gives you more information on why: https://pkg.go.dev/github.com/aws/aws-sdk-go/aws/session#hdr-Shared_Config_Fields

Just for the next person that runs into this and putting a note here about it.  If you are assuming a role via a source_profile like:
[profile1]
aws_access_key_id = aaaaaaaaaaaaaaaaaaa
aws_secret_access_key = bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

[profile2]
role_arn = arn:aws:iam::111111111111:role/my-role
source_profile = profile1
role_session_name = profile1-session-name

You will need to set the AWS_SDK_LOAD_CONFIG envar like:
AWS_SDK_LOAD_CONFIG=1 AWS_PROFILE=clientname go test -v -timeout 90m .

This doc gives you more information on why: https://pkg.go.dev/github.com/aws/aws-sdk-go/aws/session#hdr-Shared_Config_Fields


Complete discontinued currencies on Kraken

Completing according https://support.kraken.com/hc/en-us/articles/360001185506-How-to-interpret-asset-codes

linked to https://github.com/knowm/XChange/issues/3829


MDX from /Widgets now includes filters

New feature! Now (on tfoms) /Widget request returns MDX with all filters.
Please, test it @ZitRos, @gnibeda

Jush make as it was before, without parsing filters.

Let's name it "noFilters"?. MHO it is better describes the option then
"basicMDX"
2015-01-04 18:46 GMT+03:00 Nikita<EMAIL_ADDRESS>
Jush make as it was before, without parsing filters.
—
Reply to this email directly or view it on GitHub
https://github.com/intersystems-ru/Cache-MDX2JSON/issues/37#issuecomment-68637172
.

I agree, but if project reach a new MDX modification (parsing) in future, the meaning of "noFilters" name will be corrupted. Also I propose variants "cleanMDX", "originMDX" or much better "pivotMDX". What do you think?

Let's name it "noFilters"?

I agree, but if project reach a new MDX modification (parsing) in future, the meaning of "noFilters" name will be corrupted. Also I propose variants "cleanMDX", "originMDX" or much better "pivotMDX". What do you think?

I think it's bad to have parameter name start with negation like "no" or "not". You can always call this parameter IncludeFilters with default value true


Window

The Changes are Awesome!! the sprites are on their finest quality! Thank You!
but with backgrounds we can't see they full, i was trying to rip Super Robot Taisen Alpha Gaiden Background, but it's doesnt let me see the full sprite it's just cut on the middle, it's possible do something about it, like, increasing the window size?
Thanks ;)
sorry (looks like ive put my doubt in the wrong place, don't use github so much, pardon me.)

Wow, I'm glad, that this tool is not forgotten. Thank you for contribution!

Wow, I'm glad, that this tool is not forgotten. Thank you for contribution!


Remove Maven wrapper scripts

If we are removing the helper scripts from the Quarkus project, we need to document that devs need the maven installed with the correct version as a prerequisite to building the project; otherwise, the Quarkus maven plugins will not function.

Its in "Prerequisites"

We need to have a clear directory directory layout such that it is easy to figure out where your contribution goes

What does clear directory layout have to do with Maven wrapper? Having that is a standard thing for any Quarkus project.

To digress a bit, why are Keycloak, Grafana and PostgreSQL in Prerequisites?  You don't need to have that installed locally. On the other hand, you need either Docker or Podman.
Sure, we depend on these but they're transparently managed via images. So I wouldn't list them (we don't list Quarkus either and we depend on that...)

They are prerequisites since the test suite won't run without them - docker or podman is a way to get them running locally.

In my view Prerequisites are the thing you need to do/get manually. Testsuite will run just fine even if you never touch them. I see these as Dependencies.


have to press back 6 times to exit app

if a want to exit the app then i have to click the back button 6 times to exit

@Jatin887 can u take a look at it?

ok


Convert to TypeScript

Convert addon to TypeScript
Support Glint

Thanks for the PR @charlesfries! Would you be interested in finishing it up or would you like some help?

Thanks @RobbieTheWagner, it should be good now. The only minor annoyance is the usage of declare const Prism: any;; I tried  installing @types/prismjs and then importing Prism from prismjs but that seems to slightly change the padding of the code blocks on the test app.
Not sure what the deal is there but I just left the globals in and added that line.

LGTM, thanks for the PR!


Detecting master material.

Hi, is there a way to detect the master material of an instance and get the name or location of it? And once you have done that, is there a way to change the master material of an instance?

It's a bit confusing, but "parent" is what you are looking for. If I remember correctly you can get the current master mtl and set it as well.

Searching through the docs I found options to set the parent, but, not to identify the parent name of an instance.
Maybe I was looking for the wrong thing but that is what I found.

It seems like python material_instance.Parent
works. Thank you!


VSCode Saves The File Endlessly

VSCode Version:
Version: 1.34.0 (system setup)
Commit: a622c65b2c713c890fcf4fbf07cf34049d5fe758
Date: 2019-05-15T21:59:37.030Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17134

-OS: Windows 10
Steps to Reproduce:

Open a .css file and make a minor change.
Save the file.

Note VSCode endlessly saving the file. The only way I can stop it is to close the window containing the file.
Further notes:

It doesnt happen for every file, but its happens more often when saving a css file.

I have already disabled all extensions to no effect.

Does this issue occur when all extensions are disabled?: Yes

@bpasero any idea?

Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/

Thank you, Benjamin, for replying.
I got rid of the problem by re-installing vscode.  Here is my current working version:
Version: 1.34.0 (user setup)
Commit: a622c65b2c713c890fcf4fbf07cf34049d5fe758
Date: 2019-05-15T21:59:37.030Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17134

From: Benjamin Pasero<EMAIL_ADDRESS>Sent: June 4, 2019 5:53 AM
To: microsoft/vscode
Cc: litopjos; Author
Subject: Re: [microsoft/vscode] VSCode Saves The File Endlessly (#74720)
Can you try to reproduce with our nightly insider builds? You can give our preview releases a try from: https://code.visualstudio.com/insiders/
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vscode/issues/74720?email_source=notifications&email_token=AASCEF23UPFKYWRCUPYVPXLPYX7PPA5CNFSM4HSAKHZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW3PWYY#issuecomment-498531171, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AASCEF44C4UNQRM5YV7CEXTPYX7PPANCNFSM4HSAKHZQ.


feat: in tech mix, distinguish similarly named scenarios by prepending source

Maybe closes #74
Relates to AB#10962

@cjyetman @MonikaFu given that we barely have any tests in this repo together (and adding a good testing infrastructure is a large task unto itself), I would elect to ignore the 2 failing test coverage checks.

I'm not a fan of Codecov failing tests because of lack of coverage. It's there to give us information, not tell us we shouldn't merge things.


Infinite scrolling with remote data available?

Don't see a way to provide the data necessary to enable infinite scrolling using query

+1

+1

+1

+1

:+1:

+1

+1

+1

+1

:+1:

+1

+1

+1

:+1:

+1

+1

+1

Use this with ui select;
it works
https://github.com/tushariscoolster/angular-scroll-complete
eg

{{$item.category}}

@tushariscoolster  does it destroy the elements when you scroll back up? If I have a large list, it's good for a start but once a user begins to scroll down the list, if it just keeps adding to the dom it will begin to slow things down.

@simkessy  yupps I agree, I too faced that problem, but dint got much time to enhance that
But for performance improvement u can try https://github.com/bimal1331/paperDom
Am not sure it work

+1

+1 on this

+1

+1

+1

+1

+1

+1

Here is extension of ui-select https://github.com/hyzhak/ui-select-infinity that solve this issue. Pls send PR or add issue if you find something that doesn't solve your problem

+1

+1

+1

+1

:+1:

+1

+1

+1

+1

+1

:+1:

+1

-(-1)

+1

+1
We use the deprecated ui-select2 and can migrate without this feature

+1

Hi guys!
I was in the same trouble, i solved using this:
https://jsfiddle.net/betonetotbo/0yfhe7pf/

+1

@betonetotbo very good solution for me!! thanks

@betonetotbo very good solution for me! thanks

+1

+1

+1

:+1:

:+1:

+1

Pretty please?

+1

+1

+1

An example using ui-select-infinity plugin: http://plnkr.co/edit/p6Dt3yvTq40Vn56AKiqC?p=preview
I think it can be simplified if it is merged with ui-scroll. Which i'm going to try soon.

Yesterday I've also introduced ui-select-infinity into my app. It works fine except sometimes it throws Cannot read property 'getBoundingClientRect' of undefined exception. If someone encounters the same problem - check my fork which solves it: https://github.com/jacek213/ui-select-infinity/pull/1

Great! +1

I am using ui-select2 dropdown with infinite scroll But search feature is not working with it. Can anyone please help ?

+1

Any state of situación for this request? Is there any documentación how ti solve this?

+1

+1

+1

+1


Fix all the README typos

Hi,
Thank you for open sourcing this.

Thank you.
Fixes #52

Thank you!


File references

There are a myriad of reasons to split type definitions across several files, which unfortunately raise the issue of how to point at the files containing the type definitions being used.
Please comment on possible solutions, past experiences, successes, and also very important, failures.

At Insomniac we used the mcpp so we could #include other files and avoid having the parser locate and parse other files to get all the definitions, but in the end I think it wasn't worth the trouble because:

We had to use an external tool to be able to parse the DDL files
We had to keep track of which definition was in which file using the #line directive, otherwise we would generate code for the definitions in the included files
We had to pass flags to mcpp so it could find the included files
Although I prefer a C-like syntax for a DDL, having a C pre-processor may feel too much alien for programmers with background in different programming languages

One benefit though is having all the power of a C pre-processor available for use in the DDL files.
I was recently thinking in different ways to add references to other files in an in-house DDL, and thought about requiring fully qualified IDs for types defined in other files, but didn't have the time to explore it.
It was something like this:
struct particle {
    math::vec3 position;
    math::vec3 velocity;
};

math::vec3 would be looked up in <path_to_root_of_ddl_files>/math/vec3.ddl, but I don't like having to declare one structure per file.

I agree with the avoid #include sentiment. Besides being C-centric, I'm not a fan of the issues it causes if you want to move the referenced files around.
Meanwhile I've been thinking a path include might not be needed at all. In the initial discussions a project system topic was debated, or lack of, where it will probably end up being the responsability of the pipeline to pass the tooling with a list of files to be included.
This approach, with the namespace support #6, makes me think we can support your fully qualified name suggestion, with a few more things, like using statements.
Lets assume you have a foo/math/vec/vec.ddl file:
namespace Math;

def struct Vec3
{
    x: float,
    y: float,
    z: float,
}

with your particle example we can do:
using math;

struct particle {
    vec3 position;
    vec3 velocity;
};

And we could pass a list of namespaces to be included automatically to the libraries and tools, allowing us to use vec3 position directly.

I dislike using but that's coming from a large code base where it did nothing good but add confusion.

where it will probably end up being the responsability of the pipeline to pass the tooling with a list of files to be included.

The pipeline won't know which files a particular DDL file will need, and we don't want to pass all existing DDL files every time the tooling is invoked.
My two favorite ways to deal with this:

By convention, where the type Math::Vec3 would be looked up in <path_to_root_of_ddl_files>/Math/Vec3.ddl
By using explicit imports, where import Math.Vectors; will make the tooling load the definitions in the <path_to_root_of_ddl_files>/Math/Vectors.ddl

The difference between #1 and #2 is that with #1 each type will have to be defined in its own file, where with #2 a DDL file can have multiple type definitions.
Both options need all DDL files to exist under a common root folder, which I wanted to hate but don't. This root folder would be a parameter to the tooling.

Do you have examples of those confusions? Always useful to know the shortcomings of other implementations.
I think this discussion is starting to invade the scope of the project system, whatever that will be, so might be better to create a new issue for this :) (Issue #11)
Regarding the convention approach I have to argue against it. This project aims to create both a file syntax and tooling to support its use. If we implement any convention that goes against the existing implementation of a project, that is one less project that can benefit from this, and by consequence less value this project brings to the community.
But I like way #2. Doesn't force a file convention, and works in similar ways to other namespaced languages.
And it doesn't require explicit imports in the files for every type. This method still allows for the user to pass a list of implicit imports to the tooling, like a prelude in a way.
If we use using Math::Vectors or import Math.Vectors will probably end up an implementation detail, I like that we have common ground on leveraging the namespaces for referencing other files.

Do you have examples of those confusions?

Nothing special, just a developer that used using std; in some files and brought tons of stuff to the global namespace just to avoid typing std:: where necessary, which required some maintenance.

But I like way #2.

+1

I think I see the concern. I'm assuming the DDL tooling on that project somehow added the using std; to the generated C++ file.
From my perspective this isn't the concern of the DDL tooling, but purely on the codegen side of things. So a using, or import, or some other alternative, should only inform the DDL parser where to look for the type, and not be used on the generated files.

Sorry, I was under the impression that you were suggesting that DDL supported using math; to avoid having to type the fully qualified ID of types like math::vec3.

Ah, right. That too. Was mixing both functionalities, without even noticing it, were the two functionalities are:

Picking the right file\namespace\package from the name
Bringing the types in that source into scope

Might not be a good idea to do a 2-in-1, but maybe we can. We could paraphrase Rust use.
Let's assume a .ddl with
use SomeFancyLib::math;

def struct Entity {
    position: math::vec3,
}

For this file, the reference system (from https://github.com/TheToolsmiths/ddl/issues/11#issuecomment-524071002) takes SomeFancyLib::math  and returns /SomeFancyLib/math.ddl.
Then the type system maps any type prefixed with math:: to the scope of the file.
Seems simple enough to me, and hopefully sorts out your dislike for using.

I'm used to read using as C++'s using, and import as Java's import. use meaning import confuses me.

The keyword itself can be using, use, import, include, etc. Any of those brings their own assumptions from the languages that already use them.
Important is to figure out the behavior. Is there a benefit of separating things with two statements like C++ does, or can we keep things simple and do the 2-in-1 above?

Less magic is better. I would never thing about implementing something like C++'s using.


if( Ping.ping("www.google.com")) -- doesnt wait for ping response

This doesnt work. It doesnt wait for ping response.
if( Ping.ping("www.google.com"))
This works for now -
bool pingstate = Ping.ping(pinghost);
delay(500);
float avg_time_ms = 0;
avg_time_ms = Ping.averageTime();
if (avg_time_ms)

Also Can you add Home Button to return to main page and 'Done' message after upload is done.

sorry , i don't understand your last comment

sorry accidentally posted that in wrong place

pb with yield() and esp8266


custom color on links

Saw your answer here https://github.com/danielcaldas/react-d3-graph/issues/47 but didn't get it working. I basically want to define color on link level.

Hello @Finbel, yes the comment on #47 has a solution proposition for this, but it was not yet implemented. I think it's a good first issue, will tag this issue. Feel free to submit a PR for this.


Update/fastkml v0.12

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Recipe maintainer "dcunn" does not exist
noarch: python recipes are required to have a lower bound on the python version. Typically this means putting python >=3.6 in both host and run but you should check upstream for the package's Python compatibility.

For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Recipe maintainer "dcunn" does not exist

For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


%matplotlib inline   not responding

Hi,
We are not able to display/output graphs inline ( as embedded objects, like in the earlier release) the popups are annoying and hang.
How to switch back to display the results inline as embedded objects in the latest release.
Iam using the latest version of Pyleecan
We tried below along with other options but no luck
%matplotlib notebook
%matplotlib inline
import matplotlib.pyplot as plt
import numpy as np

Hello,
We sometime have the same issue, running twice the first cell with plots seems to solve the issue.
Best regards,
Pierre


haskellPackages.mono-traversable: fix build inputs for ghc7.10.x

Motivation for this change
This fixes #17635
Things done

[x] Tested using sandboxing
(nix.useChroot on NixOS,
or option build-use-chroot in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[x] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Fits CONTRIBUTING.md.

Looks like the same problem as #17586 and should hopefully be fixed when https://github.com/NixOS/cabal2nix/issues/238 is resolved