Uncaught TypeError: undefined is not a function

Uncaught TypeError: undefined is not a function
Atom Version: 0.153.0
System: linux 3.13.0-44-generic
Thrown From: linter package
:-1:
I've got the same error. Ubuntu x86_64

/cc @kevinsawicki @nathansobo @probablycorey

Atom Version: 0.153.0

0.176.0 is out. Does the error still happen there?

If this is thrown from the linter package, then it is a problem with linter most likely. In any case, please update to the latest version and let us know if this reproduces.


cast syscall.Stdin to an int

When GOOS=windows, syscall.Stdin is of type syscall.Handler which is
of type uintptr. Casting to an int is considered the "right" way to
fix this.

@bacongobbler,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

Codecov Report

Merging #173 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master     #173   +/-   ##
=======================================
  Coverage   33.06%   33.06%
=======================================
  Files          18       18
  Lines        1104     1104
=======================================
  Hits          365      365
  Misses        690      690
  Partials       49       49

Impacted Files
Coverage Δ

cmd/draft/init.go
2.45% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


F 328 write test for donations from wallets

Add test for  donationsFromWallets
Related to #328

@mohammadranjbarz can you review this?

@FatemeGhasemi Please resolve conflicts


[Bugfix] Fix prompt_logprobs when SamplingParams.detokenize is set to True

prompt_logprobs is skipped currently when SamplingParams.detokenize is set to True.
This will enable a workaround of https://github.com/vllm-project/vllm/issues/4904 if the user only needs prompt_logprobs and not detokenized text.

Thanks for the fix! Can you add a test case to avoid future regressions?

Thanks for the fix! Can you add a test case to avoid future regressions?

Done. PTAL.


fix(version): update fabric8-stack-analysis-ui to 0.1.1

There were the following issues with your Pull Request

Commit: fd49417f84e42f814c3f781619042b0192439afe
Your subject line is longer than 50 characters

Guidelines are available at https://github.com/fabric8io/fabric8-ui

This message was auto-generated by https://gitcop.com


keyFile not parsed in workspace

It breaks internals visible to when using omnisharp.
/cc @troydai

same as #279?

Could be

Fixed in https://github.com/OmniSharp/omnisharp-roslyn/commit/8f04b008c2e89f56cf264c13a8f99cc505825f36


Decide what framework to use to build our Chrome extension

Plasmo? Parcel.js? Vite?

Here is a quick summary of our tools: @ykdojo
Tools
Parcel.js

Zero Config: Parcel offers a seamless development experience, requiring no configuration. It supports various languages and file types out of the box, from HTML, CSS, and JavaScript to images, fonts, and more.

Dev Server: Parcel includes a built-in development server for easy project setup. It supports HTTPS, and a built-in API proxy helps simulate the production environment.

Hot Reloading: Automatic code updates in the browser without page reloads. Integration with React Fast Refresh and Vue Hot Reloading API preserves application state between updates.

Diagnostics: Parcel provides clear error diagnostics in the terminal and browser, including syntax-highlighted code frames and documentation links for issue resolution.

Native Performance: Written in Rust, Parcel's JavaScript compiler, CSS transformer, and source maps offer superior performance, outpacing other JavaScript-based tools by 10-20x.

Multi-core: Designed with a multi-core architecture, Parcel parallelizes work across all cores, enhancing performance in transforming source files, packaging, and optimizing output bundles.

Reliable Caching: Everything, from transformation to bundling, is cached, ensuring instant dev server restarts and avoiding redundant builds.

Lazy Dev Builds: Parcel can defer building files until requested in the browser during development, reducing dev server startup time.

Production Optimization: Parcel optimizes the entire app for production, including tree-shaking, minification, image resizing, content hashing, automatic code splitting, and more.

Tree Shaking: Supports tree-shaking for both ES modules and CommonJS, removing unused code and classes automatically.

Minification: Parcel includes minifiers for JavaScript, CSS, HTML, and SVG out of the box, ensuring optimized builds.

Image Optimization: Supports resizing, converting, and optimizing images with easy query parameters in HTML, CSS, and JavaScript.

Compression: Provides Gzip and Brotli compression options for app deployment.

Code Splitting: Automatically deduplicates common modules, allowing parallel loading and caching of dependencies.

Dashboard and Profile: Parcel automatically includes content hashes in output file names, enabling efficient long-term browser caching.

Transpilation: Automatically transpiles JavaScript and CSS based on specified target browsers, supporting JSX, TypeScript, and modern CSS syntax.

Differential Bundling: Generates nomodule fallbacks for old browsers when using <script type="module">, resulting in smaller bundles.

Workers: Supports web workers, service workers, and worklets out of the box, following standard browser APIs.

Libraries: Can build libraries for multiple targets simultaneously, allowing compilation to different module types and TypeScript definitions.

Extensible Configuration: While requiring zero configuration initially, Parcel allows easy extension through a JSON-based config file for more complex build requirements.

⚙ Powerful Plugins: Parcel's core is language-agnostic, allowing customization through various plugins for transforming, resolving dependencies, bundling, optimizing, and more.

🔄 Named Pipelines: Supports the creation of named pipelines for transforming files in multiple ways during a single build.

⚡ Performance Design: Parcel's plugin system is optimized for performance, automatically parallelizing plugins and integrating with caching.

🔄 API Integration: Offers an API for programmatically performing builds, enabling integration into existing build systems.

🚀 Open Source Support: Parcel is an open-source project supported by contributions from companies and individuals, categorized into gold, silver, and bronze sponsors, as well as backers and contributors.
Summarized by https://chrome.google.com/webstore/detail/cbgecfllfhmmnknmamkejadjmnmpfjmp

Plasmo
Plasmo Overview:

Plasmo helps build, test, and deploy powerful browser extensions.
First-class support for React, Svelte, and Vue frameworks.
Automatically mounts existing components onto the extension for ease.

Development Features:

Style Leakage Prevention: Plasmo creates a shadow DOM to prevent style leakage.
Live-reloading: Automatically reloads the extension upon code changes.
React HMR: Enables Hot Module Replacement for real-time component

Browser Extension Utility:

Acts as an additional layer on Chrome and Firefox extension APIs.
Includes utility functions enhancing the extension development experience.

Case Study - ArConnect:

ArConnect leverages Plasmo for innovative browser extension development.
Marton Lederer, Lead Engineer, highlights Plasmo's seamless integration.

Case Study - Liveblocks:

Marc Bouchenoire, Design Engineer, praises Plasmo's abstraction level.
Opted for Plasmo over vanilla extension development for flexibility.

Plasmo Itero:

Upload extension to Itero for instant deployment to testers.
GitHub Integration: Deploy extension to beta testers with each git push.

Production Deployment:

Itero simplifies web store deployment credential management.
One-click publishing to any major browser from the Itero interface.

Vite

Instant Server Start: No more waiting around – kickstart your development with on-demand file serving using native ESM. And guess what? No bundling required! It's like your code is ready to party right when you are.

Fast HMR: You know that feeling when you're waiting for your code to hot-reload, and it's slower than a turtle in molasses? Well, fear not! This frontend tooling comes with a Hot Module Replacement (HMR) that's speedy, no matter how big your app gets. Zoom, zoom, baby!

Rich Features: It's the full package deal. TypeScript, JSX, CSS – you name it, it's got it. Right out of the box. No need to wrestle with configurations. It's like having a superhero toolbelt for frontend development.

Optimized Build: Rollup, with its pre-configured magic, is here to make your life easier. Whether you're dealing with multi-page projects or creating the next big library, this tool's got your back. Building stuff has never been so smooth.

Universal Plugins: Plug and play, my friend. This tool's got a superset plugin interface that works seamlessly for both development and building. It's like having universal remote control but for your frontend workflow.

Fully Typed APIs: Flexibility meets TypeScript. The APIs are not just APIs; they are fully typed. So, you can code confidently, knowing that your buddy TypeScript has your back. No more second-guessing, just smooth sailing.

My take on this is that Parcel.js and Vite are all great tools with a general purpose, while Plasmo is specifically designed for browser extensions.
cc: @ykdojo

Thank you for sharing this, @Jonath-z

I recommend choosing Plasmo as our framework. With a focus on extension development, Plasmo offers potential performance advantages. This decision aligns well with our project goals and ensures a smoother development process.

Thank you both.
@Jonath-z let me know if you might want to turn what you wrote into a Medium post, as well. We have a publication for this kind of thing.

@ykdojo definitely yeah. I would love that

Great! Here's the publication: https://medium.com/cs-dojo
It hasn't been active recently but we can start it up again.

^Looks like we all agree on Plasmo, so let's go with it.


BUG: align the community spotlight page with the main website

Is there an existing issue for this?

[X] I have searched the existing issues

What happened?

This is not aligned with the theme of the website
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Please assign this issue to me @anuragverma108

Assigned!
Make sure to attach before & after screenshots in your PR and include the issue number.
Also, please star the repo before working on it. Happy open-source contributing!


Tokio trace instrumentation example

This is an example of demonstrating tokio-trace instrumentation. I have used the proxy server implementation in the Tokio crate examples.

Great I shall look into it.

I have made all the changes as discussed above.

why is my build failing with rust-1.26.0 ? And what can I do to fix it?

Its because your code has warnings, which you denied here.
You can find that information, by clicking on the details link next to the travis check status. Then you can check the log information of the CI job by clicking on the failing job entry. When you scroll down a bit or search for error, you'll find the respective compiler errors.

Okay, I shall look into it. Thanks a lot though!

While i meant removing the cause for the warnings, i didn't see at first that the errors originate in the macro. I will take a look into it.

@MSleepyPanda I think the issue with the macro was due to an upstream change --- previously we had an #[allow(unused_imports)] because the macro import rules are different in earlier Rust versions. However, now that we are using local_inner_macros, I believe the use $crate::callsite; statement in the macros (which is causing these warnings) may be able to just be removed entirely.

I was not able to resolve the warnings as they were in other crates, or not where I could really fix it. I could look into fixing other warnings but I guess it should be another PR. But, is every other thing okay,  @hawkw ?

How is this ?

Done I guess.

@kanishkarj this looks good --- I'll go ahead and merge it when it passes on CI.

and merged! thanks for your contribution!


Won't close fd cause "Too many open files (os error 24)"

shadow-tls won't close the file handles after the connection is used. finally, it will cause "Too many open files (os error 24)" Error.

https://github.com/tokio-rs/tokio/issues/4782
seem same as this tokio's issue

Aha, I also observed the same problem. There are significantly more logs for creating connections than closing connections.
And I think this problem has no relation with tokio. It's just my mistake that I did not relay the half close action. I've pushed a fix and let's check if it will work as expected.

looks fine, closed


More than just a sidebar!

I’m anxious to see this UI working outside of the editor sidebar. How can we map these patterns to the top toolbar, the block toolbar, and even outside of the editor into wp-admin.

Yes! I'm glad you brought these topics up. The components are designed to enable seamless integration into varying apps, environments, and features* (*Assuming JS + React can run)
The top/block toolbar are interesting real world candidates. I'm excited to prototype these out. That being said, I understand there is a lot (I mean a lot) that goes into the Toolbar in Gutenberg. So the prototypes will be approaching it (almost) purely from a UI + interaction perspective.
If you have any ideas for potential WP Admin UI / implementations, please lemme know :D

Technically still a Sidebar... but it's on the left side now 😂
https://github.com/ItsJonQ/g2/issues/20


DUOS-1887[risk=med] Enable nav refactor for Prod with updated env conditionals

DUOS-1887

Updated the app to exclusively use the new DUOS header.
Updated utils to remove conditional logic that considers environment for navigation.
Removed conditional logic that considers environment for DataCustodianTable visibility in the Signing Official Console.
Fixed a no-unused-vars from the MDV changes.

Have you read Terra's Contributing Guide lately? If not, do that first.

Label PR with a Jira ticket number and include a link to the ticket
Label PR with a security risk modifier [no, low, medium, high]
PR describes scope of changes
Get a minimum of one thumbs worth of review, preferably two if enough team members are available
Get PO sign-off for all non-trivial UI or workflow changes
Verify all tests go green
Test this change deployed correctly and works on dev environment after deployment

Open Questions:

When looking for other instances of env conditionals, I found background sign in is disabled for prod staging. That should remain that way, correct?
Should I remove the DuosHeaderOld code?
How do I get to the Data Custodian table? I wasn't able to access the DataCustodianTable - need reviewers to take a closer look at that to make sure the logic I updated is working correctly.

How do I get to the Data Custodian table? I wasn't able to access the DataCustodianTable - need reviewers to take a closer look at that to make sure the logic I updated is working correctly.

You shouldn't have to worry about getting the DataCustodianTable visible - we removed tabs to it on the signing official console since it wasn't displaying any information, just a duplicated table of researchers. We've been keeping around the component though with the intention of repurposing it later for data submitters, I believe. Maybe it would be useful to leave a comment so that if someone looks at that code in the future they'll have this context?

When looking for other instances of env conditionals, I found background sign in is disabled for prod staging. That should remain that way, correct?

@quazi-broad Correct, we only want background sign-in enabled for certain testing envs


NW | RAHWA ZESLUS | Module-User-Focused-Data| FEATURE/|WIREFRAME WEEK 1

NW | RAHWA ZESLUS | Module-User-Focused-Data | WEEK 1
For example,
-->
Learners, PR Template
Self checklist

[x] I have committed my files one by one, on purpose, and for a reason
[x] I have titled my PR with COHORT_NAME | FIRST_NAME LAST_NAME | REPO_NAME | WEEK
[x] I have tested my changes
[x] My changes follow the style guide
[x] My changes meet the requirements of this task

Changelist
Briefly explain your PR.
My first wireframe was a bit messy ,I have done all the projects on that branch so I am forced to create this branch with the wireframe task only.
Ask any questions you have for your reviewer.
can you review this please.

PLEASE CAN YOU REVIEW MY WORK ?

It seems that in the current repo you have a Module-User-Focused-Data folder which is also a Git repo. I think that's why your repo cannot be deployed to Netlify automatically. Can you fix that?

Thanks for the review . I have removed the folder

The boxes with a cross in the wireframe represents images. Can you add images to the page to make it more like the wireframe?
In general, when given a wireframe, we should pay attention to

Text alignments and justifications
Relative size and position of the elements.
and make the page look like the wireframe as much as possible.

Thank you in advance for taking your time ,I have tried to correct those reviews . Can you review my latest work please?


Resulting app does not open when bundleJRE = true

The createApp task works when bundleJRE = false. My program runs and loads.
However, when bundleJRE = true it does not. It opens an OS X Error Dialog saying JRELoadError.
I'm not sure how to start troubleshooting this.

Just tested here with bundleJRE=true and it worked, so not sure what to say. I assume you have java from installed?
What version of OSX? What version of Java?
What is the output of:
/usr/libexec/java_home
Did you set jreHome?

OSX 10.12.6
I have two versions of Java installed: jdk-9.jdk, jdk1.8.0_121.jdk
So java_home points to jdk-9 at the moment (I did try removing jdk-9, apparently Mac OS simply picks the most recent version, this didn't make any difference).
My gradle project has source compatibility set to 1.8. I'm quite new to gradle. I'm not 100% sure which java version I'm running when I run the project from gradle. I can check. Where can I see the bundled JRE?
I've also noticed a separate issue, which may not be an issue of your builder per se (so I won't log it unless you want me to). When I run my app (with bundleJRE = false) by double clicking on it, some part of the program is not running properly. However, if I run the app by calling MyApp.app/Contents/MacOS/JavaAppLauncher from the terminal it works as expected. I need to investigate more what is failing. My first thought was that certain resources are not loading, but they seem to be. So I wonder if something to do with JavaFX graphics rendering is not behaving in the same way. I realise this is incredibly vague - that's because I don't know how to see the standard out and error when running the app, so I can't tell what is failing. Is there a log file somewhere that will show me the Java stdout and stderr?
Anyway, thanks for making such an awesome plugin. This is surely the missing ingredient to make gradle the winner Java build tool.

PS those are both Oracle Java.

Java is copied into the Contents/PlugIns directory inside the app, so for example
TestApp.app/Contents/PlugIns/jdk1.8.0_51.jdk
You can try running your app from the command line with
open Test.app
which is closer to double clicking than directly running JavaAppLauncher

OK thanks. So the Java 9 JDK was being bundled. I assume this is done based on the system settings (use whichever JDK is most recent), as I don't see any setting saying to use JDK 9. When I removed JDK 9 from my /Libraries/Java/JavaVirtualMachines folder everything worked perfectly and the app had Java 8 bundled.
Thank you! Perhaps the world is just not ready for Java 9 ;-)

I'll check into the java9 issue.
You can also set jreHome within the macAppBundle section if you want to choose a particular jre. Otherwise it uses whatever the output of /usr/libexec/java_home is.


vocms0304 JobSubmitter

I think it is submitting to the wrong sites or something here is the error:
2017-09-24 12:17:44,745:139752376227584:INFO:JobSubmitterPoller:Have 27 packages to submit.
2017-09-24 12:17:44,745:139752376227584:INFO:JobSubmitterPoller:Have 1000 jobs to submit.
2017-09-24 12:17:44,745:139752376227584:INFO:JobSubmitterPoller:Done assigning site locations.
2017-09-24 12:18:57,307:139752376227584:INFO:SimpleCondorPlugin:Done submitting jobs for this cycle in SimpleCondorPlugin
2017-09-24 12:18:58,272:139752376227584:INFO:JobSubmitterPoller:Jobs that succeeded/failed submission: 1000/0.
2017-09-24 12:19:01,983:139752376227584:INFO:DashboardReporter:Handling 1000 jobs
2017-09-24 12:41:32,861:139752376227584:INFO:JobSubmitterPoller:Transaction cycle successfully completed.
2017-09-24 12:44:10,772:139752376227584:INFO:JobSubmitterPoller:Refreshing priority cache with currently 189379 jobs
2017-09-24 12:44:10,858:139752376227584:INFO:JobSubmitterPoller:Skipping cache update to be submitted. (189379 job in cache)
2017-09-24 12:44:10,858:139752376227584:INFO:JobSubmitterPoller:Determining possible sites for new jobs...
2017-09-24 12:44:22,684:139752376227584:INFO:JobSubmitterPoller:Done pruning killed jobs, moving on to submit.
2017-09-24 12:55:29,685:139752376227584:INFO:JobSubmitterPoller:Site submission report: {'T1_IT_CNAF': Counter({'submitted': 2}), 'T2_FR_CCIN2P3': Counter({'NoPendingSlot': 101}), 'T2_IT_Rome': Counter({'NoPendingSlot': 1}), 'T1_ES_PIC': Counter({'NoPendingSlot': 165}), 'T1_FR_CCIN2P3': Counter({'submitted': 1}), 'T2_US_Florida': Counter({'NoPendingSlot': 93}), 'T2_FR_GRIF_IRFU': Counter({'NoPendingSlot': 96}), 'T2_US_UCSD': Counter({'submitted': 11}), 'T2_US_Purdue': Counter({'NoPendingSlot': 87}), 'T2_US_MIT': Counter({'submitted': 663}), 'T2_UK_SGrid_RALPP': Counter({'submitted': 15}), 'T2_FR_GRIF_LLR': Counter({'submitted': 67, 'NoPendingSlot': 29}), 'T2_UK_London_IC': Counter({'NoPendingSlot': 12}), 'T2_IT_Legnaro': Counter({'NoPendingSlot': 19}), 'T2_IT_Bari': Counter({'NoPendingSlot': 53}), 'T2_CH_CERN_HLT': Counter({'NoPendingSlot': 74}), 'T2_ES_CIEMAT': Counter({'submitted': 38}), 'T2_FR_IPHC': Counter({'NoPendingSlot': 90}), 'T1_RU_JINR': Counter({'submitted': 99}), 'T2_US_Wisconsin': Counter({'submitted': 16}), 'T2_DE_DESY': Counter({'submitted': 8}), 'T1_UK_RAL': Counter({'NoPendingSlot': 150}), 'T1_US_FNAL': Counter({'NoPendingSlot': 985}), 'T2_US_Nebraska': Counter({'NoPendingSlot': 74}), 'T2_DE_RWTH': Counter({'NoPendingSlot': 13, 'submitted': 2}), 'T2_US_Caltech': Counter({'submitted': 5}), 'T2_UK_London_Brunel': Counter({'NoPendingSlot': 37}), 'T2_BE_IIHE': Counter({'NoTaskSlot': 110, 'submitted': 3}), 'T1_DE_KIT': Counter({'NoPendingSlot': 44}), 'T2_IT_Pisa': Counter({'NoPendingSlot': 45}), 'T2_CH_CERN': Counter({'submitted': 70, 'NoPendingSlot': 29})}
2017-09-24 12:55:29,686:139752376227584:INFO:JobSubmitterPoller:Priority submission report: {50110000.0: Counter({'Total': 403}), 30063000.0: Counter({'Total': 13}), 50085000.0: Counter({'Total': 1002}), 50090000.0: Counter({'Total': 2}), 50063000.0: Counter({'Total': 121}), 30085000.0: Counter({'Total': 42}), 110000.0: Counter({'Total': 2}), 85000.0: Counter({'Total': 1200, 'submitted': 895}), 63000.0: Counter({'Total': 340, 'submitted': 105})}
2017-09-24 12:55:29,687:139752376227584:INFO:JobSubmitterPoller:Have 20 packages to submit.
2017-09-24 12:55:29,927:139752376227584:INFO:JobSubmitterPoller:Have 1000 jobs to submit.
2017-09-24 12:55:29,927:139752376227584:INFO:JobSubmitterPoller:Done assigning site locations.
2017-09-24 12:56:31,284:139752376227584:INFO:SimpleCondorPlugin:Done submitting jobs for this cycle in SimpleCondorPlugin
2017-09-24 13:33:40,332:139752376227584:INFO:JobSubmitterPoller:Jobs that succeeded/failed submission: 1000/0.
2017-09-24 13:33:44,448:139752376227584:INFO:DashboardReporter:Handling 1000 jobs
2017-09-24 13:58:54,232:139752376227584:INFO:JobSubmitterPoller:Transaction cycle successfully completed.
2017-09-24 14:01:05,899:139752376227584:INFO:JobSubmitterPoller:Refreshing priority cache with currently 188379 jobs
2017-09-24 14:01:05,945:139752376227584:INFO:JobSubmitterPoller:Skipping cache update to be submitted. (188379 job in cache)
2017-09-24 14:01:05,945:139752376227584:INFO:JobSubmitterPoller:Determining possible sites for new jobs...
2017-09-24 14:01:05,950:139752376227584:INFO:JobSubmitterPoller:Done pruning killed jobs, moving on to submit.
2017-09-24 14:03:09,202:139752376227584:INFO:JobSubmitterPoller:Site submission report: {u'T1_IT_CNAF': Counter({'submitted': 12}), 'T2_FR_CCIN2P3': Counter({'NoPendingSlot': 61, 'submitted': 42}), 'T2_CH_CERN_HLT': Counter({'submitted': 60}), 'T1_ES_PIC': Counter({'submitted': 167}), 'T1_FR_CCIN2P3': Counter({'submitted': 20}), 'T2_DE_RWTH': Counter({'submitted': 10, 'NoPendingSlot': 8}), 'T2_US_Florida': Counter({'submitted': 115}), 'T2_FR_GRIF_IRFU': Counter({'submitted': 28, 'NoPendingSlot': 4}), 'T2_US_UCSD': Counter({'submitted': 2}), 'T2_US_Purdue': Counter({'NoPendingSlot': 86, 'submitted': 32}), 'T0_CH_CERN': Counter({'submitted': 7}), 'T2_UK_London_IC': Counter({'submitted': 4}), 'T2_FR_GRIF_LLR': Counter({'submitted': 4}), 'T2_US_Nebraska': Counter({'submitted': 58, 'NoPendingSlot': 20}), 'T2_BE_UCL': Counter({'submitted': 5}), 'T2_IT_Legnaro': Counter({'submitted': 25, 'NoPendingSlot': 4}), 'T2_IT_Bari': Counter({'NoPendingSlot': 54, 'submitted': 1}), 'T2_ES_CIEMAT': Counter({'submitted': 3}), 'T2_FR_IPHC': Counter({'submitted': 59, 'NoPendingSlot': 34}), 'T1_RU_JINR': Counter({'submitted': 9}), 'T2_US_Wisconsin': Counter({'submitted': 6}), 'T2_DE_DESY': Counter({'submitted': 5}), 'T1_UK_RAL': Counter({'submitted': 88, 'NoPendingSlot': 62}), 'T1_US_FNAL': Counter({'NoPendingSlot': 869, 'submitted': 122}), 'T2_US_MIT': Counter({'submitted': 4}), 'T2_BE_IIHE': Counter({'NoTaskSlot': 110}), 'T2_IT_Rome': Counter({'NoPendingSlot': 1}), 'T2_UK_London_Brunel': Counter({'NoPendingSlot': 31, 'submitted': 6}), 'T2_CH_CERN': Counter({'submitted': 25}), 'T1_DE_KIT': Counter({'submitted': 29, 'NoPendingSlot': 17}), 'T2_IT_Pisa': Counter({'submitted': 52})}
2017-09-24 14:03:09,204:139752376227584:INFO:JobSubmitterPoller:Priority submission report: {50110000.0: Counter({'Total': 403, 'submitted': 224}), 30063000.0: Counter({'Total': 13, 'submitted': 10}), 50085000.0: Counter({'Total': 1002, 'submitted': 133}), 50090000.0: Counter({'Total': 2}), 50063000.0: Counter({'Total': 121, 'submitted': 66}), 30085000.0: Counter({'Total': 42, 'submitted': 36}), 110000.0: Counter({'Total': 2, 'submitted': 2}), 85000.0: Counter({'Total': 305, 'submitted': 252}), 63000.0: Counter({'Total': 467, 'submitted': 277})}
2017-09-24 14:03:09,220:139752376227584:INFO:JobSubmitterPoller:Have 62 packages to submit.
2017-09-24 14:03:09,220:139752376227584:INFO:JobSubmitterPoller:Have 1000 jobs to submit.
2017-09-24 14:03:09,221:139752376227584:INFO:JobSubmitterPoller:Done assigning site locations.
2017-09-24 14:04:37,596:139752376227584:INFO:SimpleCondorPlugin:Done submitting jobs for this cycle in SimpleCondorPlugin
2017-09-24 14:04:38,909:139752376227584:INFO:JobSubmitterPoller:Jobs that succeeded/failed submission: 1000/0.
2017-09-24 14:22:32,267:139752376227584:INFO:DashboardReporter:Handling 1000 jobs
2017-09-24 14:24:44,116:139752376227584:INFO:JobSubmitterPoller:Transaction cycle successfully completed.
2017-09-24 14:26:48,994:139752376227584:INFO:JobSubmitterPoller:Refreshing priority cache with currently 187379 jobs
2017-09-24 14:26:49,103:139752376227584:INFO:JobSubmitterPoller:Skipping cache update to be submitted. (187379 job in cache)
2017-09-24 14:26:49,104:139752376227584:INFO:JobSubmitterPoller:Determining possible sites for new jobs...
2017-09-24 14:26:49,107:139752376227584:INFO:JobSubmitterPoller:Done pruning killed jobs, moving on to submit.
2017-09-24 14:26:54,331:139752376227584:INFO:JobSubmitterPoller:Site submission report: {u'T1_IT_CNAF': Counter({'submitted': 883, 'NoPendingSlot': 107}), 'T2_FR_CCIN2P3': Counter({'NoPendingSlot': 61}), 'T2_IT_Rome': Counter({'NoPendingSlot': 1}), 'T1_FR_CCIN2P3': Counter({'submitted': 1}), 'T2_DE_RWTH': Counter({'NoPendingSlot': 44}), 'T2_US_Purdue': Counter({'NoPendingSlot': 122}), u'T2_FR_GRIF_LLR': Counter({'NoPendingSlot': 36}), 'T2_US_Nebraska': Counter({'NoPendingSlot': 20}), 'T1_DE_KIT': Counter({'NoPendingSlot': 17}), 'T2_IT_Bari': Counter({'NoPendingSlot': 54}), 'T2_FR_IPHC': Counter({'submitted': 36, 'NoPendingSlot': 34}), u'T1_ES_PIC': Counter({'submitted': 71, 'NoPendingSlot': 36}), 'T1_UK_RAL': Counter({'NoPendingSlot': 62}), 'T1_US_FNAL': Counter({'NoPendingSlot': 869}), 'T2_IT_Legnaro': Counter({'NoPendingSlot': 4}), 'T2_CH_CERN_HLT': Counter({'submitted': 9}), 'T2_UK_London_Brunel': Counter({'NoPendingSlot': 31}), 'T2_BE_IIHE': Counter({'NoTaskSlot': 110})}
2017-09-24 14:26:54,332:139752376227584:INFO:JobSubmitterPoller:Priority submission report: {50110000.0: Counter({'Total': 179}), 30063000.0: Counter({'Total': 3}), 50085000.0: Counter({'Total': 869}), 50090000.0: Counter({'Total': 2}), 50063000.0: Counter({'Total': 55}), 30085000.0: Counter({'Total': 6}), 85000.0: Counter({'Total': 53}), 63000.0: Counter({'Total': 1190, 'submitted': 1000})}
2017-09-24 14:26:54,332:139752376227584:INFO:JobSubmitterPoller:Have 11 packages to submit.
2017-09-24 14:26:54,333:139752376227584:INFO:JobSubmitterPoller:Have 1000 jobs to submit.
2017-09-24 14:26:54,333:139752376227584:INFO:JobSubmitterPoller:Done assigning site locations.
2017-09-24 14:28:20,194:139752376227584:INFO:SimpleCondorPlugin:Done submitting jobs for this cycle in SimpleCondorPlugin
2017-09-24 14:28:21,237:139752376227584:INFO:JobSubmitterPoller:Jobs that succeeded/failed submission: 1000/0.
2017-09-24 14:28:24,099:139752376227584:INFO:DashboardReporter:Handling 1000 jobs
2017-09-24 14:32:12,139:139752376227584:INFO:JobSubmitterPoller:Transaction cycle successfully completed.
2017-09-24 14:34:16,114:139752376227584:INFO:JobSubmitterPoller:Refreshing priority cache with currently 186379 jobs
2017-09-24 14:34:16,800:139752376227584:INFO:JobSubmitterPoller:Skipping cache update to be submitted. (186379 job in cache)
2017-09-24 14:34:16,800:139752376227584:INFO:JobSubmitterPoller:Determining possible sites for new jobs...
2017-09-24 14:34:16,804:139752376227584:INFO:JobSubmitterPoller:Done pruning killed jobs, moving on to submit.
2017-09-24 14:34:19,245:139752376227584:INFO:JobSubmitterPoller:Site submission report: {'T1_DE_KIT': Counter({'submitted': 17}), u'T1_IT_CNAF': Counter({'submitted': 769}), 'T2_FR_IPHC': Counter({'NoPendingSlot': 34}), 'T2_FR_CCIN2P3': Counter({'NoPendingSlot': 59, 'submitted': 2}), 'T2_IT_Rome': Counter({'NoPendingSlot': 1}), 'T1_UK_RAL': Counter({'submitted': 40, 'NoPendingSlot': 22}), 'T1_US_FNAL': Counter({'NoPendingSlot': 869}), 'T2_DE_RWTH': Counter({'submitted': 8}), 'T2_IT_Legnaro': Counter({'submitted': 4}), 'T2_UK_London_Brunel': Counter({'NoPendingSlot': 31}), 'T2_BE_IIHE': Counter({'NoTaskSlot': 110}), 'T2_IT_Bari': Counter({'submitted': 54}), 'T2_US_Nebraska': Counter({'submitted': 20}), 'T2_US_Purdue': Counter({'submitted': 86})}
2017-09-24 14:34:19,246:139752376227584:INFO:JobSubmitterPoller:Priority submission report: {50110000.0: Counter({'Total': 179, 'submitted': 26}), 30063000.0: Counter({'Total': 3, 'submitted': 2}), 50085000.0: Counter({'Total': 869, 'submitted': 1}), 50090000.0: Counter({'Total': 2}), 50063000.0: Counter({'Total': 55, 'submitted': 4}), 30085000.0: Counter({'Total': 6, 'submitted': 3}), 85000.0: Counter({'Total': 53, 'submitted': 28}), 63000.0: Counter({'Total': 959, 'submitted': 936})}
2017-09-24 14:34:19,247:139752376227584:INFO:JobSubmitterPoller:Have 29 packages to submit.
2017-09-24 14:34:19,247:139752376227584:INFO:JobSubmitterPoller:Have 1000 jobs to submit.
2017-09-24 14:34:19,247:139752376227584:INFO:JobSubmitterPoller:Done assigning site locations.
Here is the Jira ticket:
https://its.cern.ch/jira/projects/CMSCOMPPR/issues/CMSCOMPPR-1350?filter=allopenissues

@scarletnorberg, Scarlet, So JobSubmitter is just crashes without error messages? Message you posted seems to be generic log messages. Did you restart JobSubmitter? It seems it is working fine now. Could ping me if it happens again without restarting?

It is happening now. Wont restart. Looks like the same message.
On Mon, Sep 25, 2017 at 9:42 AM, ticoann<EMAIL_ADDRESS>wrote:

@scarletnorberg https://github.com/scarletnorberg, Scarlet, So
JobSubmitter is just crashes without error messages? Message you posted
seems to be generic log messages. Did you restart JobSubmitter? It seems it
is working fine now. Could ping me if it happens again without restarting?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dmwm/WMCore/issues/8190#issuecomment-331903521, or mute
the thread
https://github.com/notifications/unsubscribe-auth/APKOXZmzL3JCsoYWMw0iXompsB6pfHcNks5sl7vigaJpZM4Ph61a
.

--

Scarlet Norberg
Post doctoral Research Associate
University of Puerto Rico
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>skype: s.norberg1

Thanks Scarlet, I changed to debug mode and restarted job Submitter.

Thanks!
On Mon, Sep 25, 2017 at 10:08 PM, ticoann<EMAIL_ADDRESS>wrote:

Thanks Scarlet, I changed to debug mode and restarted job Submitter.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dmwm/WMCore/issues/8190#issuecomment-332073471, or mute
the thread
https://github.com/notifications/unsubscribe-auth/APKOXTggft-H11U17i1UWk_iQ4osa6jNks5smGqVgaJpZM4Ph61a
.

--

Scarlet Norberg
Post doctoral Research Associate
University of Puerto Rico
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>skype: s.norberg1

@amaltaro @ticoann went down again I am afraid

It seems it hang here. (However not all the time it succeed many times before it failed)
https://github.com/dmwm/WMCore/blob/master/src/python/WMCore/BossAir/Plugins/SimpleCondorPlugin.py#L148
I think we need to look at the schedd log what happens. I will ask Farrukh.
Here is the last record we have.
2017-09-26 10:17:21,300:140359024850688:DEBUG:SimpleCondorPlugin:Start: Submitting 200 jobs using Condor Python SubmitMany
2017-09-26 10:17:26,579:140359024850688:DEBUG:SimpleCondorPlugin:Finish: Submitting jobs using Condor Python SubmitMany
2017-09-26 10:17:26,759:140359024850688:DEBUG:SimpleCondorPlugin:Start: Submitting 200 jobs using Condor Python SubmitMany
2017-09-26 10:17:41,324:140359024850688:DEBUG:SimpleCondorPlugin:Finish: Submitting jobs using Condor Python SubmitMany
2017-09-26 10:17:41,507:140359024850688:DEBUG:SimpleCondorPlugin:Start: Submitting 200 jobs using Condor Python SubmitMany
2017-09-26 10:17:47,643:140359024850688:DEBUG:SimpleCondorPlugin:Finish: Submitting jobs using Condor Python SubmitMany
2017-09-26 10:17:47,854:140359024850688:DEBUG:SimpleCondorPlugin:Start: Submitting 200 jobs using Condor Python SubmitMany
2017-09-26 10:17:52,866:140359024850688:DEBUG:SimpleCondorPlugin:Finish: Submitting jobs using Condor Python SubmitMany
2017-09-26 10:17:53,069:140359024850688:DEBUG:SimpleCondorPlugin:Start: Submitting 200 jobs using Condor Python SubmitMany

JobSubmitter is restarted.

everyone in the P&R team should be getting those condor automatic emails. But since I've just got back from holidays, did people notice how many condor instabilities we have been facing these last days? I counted at least 50 emails within the last 6 days and - besides adding some protection to the WMCore code - somebody should follow this up with the SI team as well.

As CRC, I have seen many emails about many things, including instability in couch, reqmgr, phedex, schedd. that is not a reason for crashing JobSubmitter in general. Unless we add an automatic restart.
The shedd instability are very likely due to running them at the limit, because most of the time we were running on 2-3 agents (since the other ones were down in the dust)

Vytas, since I'm time constrained until tomorrow evening, you might want to create this cronjob (download the script too :)) in the production T0 agent such that it gets automatically restarted if JobSubmitter goes quiet for > 15min:
https://github.com/dmwm/WMCore/blob/master/bin/deploy-wmagent.sh#L355
Then we can start investigating it. This isn't something new and we have seen the component getting stuck in the submitMany in the past. Have you got any schedd alarms for that box? I have suspicious that submitMany might be having issues when schedd is unresponsive or something like that.

I added the cronjob you mentioned to the vocms0313.
Earlier this morning, the JobSubmitter died the same way on the vocms0313. However, there weren't any schedd alarms (neither any other alarms, besides the WMStats), so not sure if that was anyhow helpful.

That method invoked C++. Could you get a stack trace from it?

Let's observe how it does with the latest HTcondor version 8.8. There is some time since I last saw such problem.


Bug in CICIDS notebook

In [4], in the train_model_predict method, the loop iterating over the stratified kfold needs to include the model fit and aggregate the predicted results as well.
Similar issue happens in method get_shuffled_stratifiedKFold_train_test_split, its results need to be concatenated over all the iterations.

Very true. I took it out originally as it took too long to run and didn't provide any meaningful benefits to the overall results (especially since 100 permutations are run anyway). I was going to rename the methods and just use simple splitting but I kept some of the code in case one wanted to implement it later. So, it can be renamed and slightly refactored or the actual K-Folds can be run (the stratification still occurs, just no K-Folds are run); what would be the ideal choice?

Thanks for the clarification. I would opt for using actual K-fold then.
@HarithF opinion ?

I agree, opting K-folds would be a better idea. Since @WillBridges1999 seems to have tested and confirmed that the original implementation didn't provide a meaningful contribution, then I don't see a point in putting time and effort in refactoring it.


contour visualisation of a selected group does not update when changing x and y features

contours of groups show the lines for the projected x and y and not the selected features when changing the features for x and y axis

This was already fixed 6 months ago


Ifc4x3 span annotation

running discussion - needs improvements once it is clarified how to link the alignment and the annotation entity

@jmirtsch I've updated the test implementation but have some issues exporting IfcCurveSegment and IfcAlignmentSegment


⚠ Bofrost.at has degraded performance

In d47ca30, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2768 ms

Resolved: Bofrost.at performance has improved in 31b3030.


Rethink and simplify program design

Currently the program is divided into approximately four steps:

Group variants, add CS information
a. But also add phenotype information, and also crash on invalid phenoinfo data. Yikes.
Add annotations, creating a large dataframe.
Compare against gwas catalog, which is an annotation of sorts.
Create top report
a. this part has no knowledge of the annotations, so since it selects some of the columns from some of the annotations, it has to know their names -> orchestrating between the report and top report creation. Currently this is hard-coded, which means a lot of fiddling and a lot of typos, thought mistakes etc when changing both this and annotations.

I recently thought about this, and there are at least a few things that could be done differently:

Separate phenotype information to be its own kind of annotation, move to annotation step. Limit grouping as a step to the minimal amount of operations needed, mostly so debugging would be clearer.
Abstract away the annotations, e.g. behind an AnnotationDAO or whatever. Then ensure that they are handled correctly. This would simplify the code quite a bit, AND add a way for easy addition of different annotations - just write DAO for it & add to args.
Use these abstracted annotations in creating the top report. For example, information on whether an annotation is included in top report could be added to the DAO, e.g. by adding a get_top_report_annotation() method to the AnnotationDAO. Some parts do not generalise that well, like novelty reporting and  functional variant aggregation, but that I can live with.
Having these annotations as an abstract DAO would also make it possible to stop caring about the implementation details - I imagine it would be relatively simple to just deal with a container of AnnotationDAOs, add them to the top report as their implementation defines, and maybe have a separate container/some sort of filter for the aggregated data. But we'll see.
Instead of eagerly joining all of the annotations to the grouped data as soon as possible, maybe let them live as annotation objects that can be merged to the grouped data when we want to create the report or top report. This could make data processing simpler.

So the program structure would be three steps after the changes:

Group, add cs info since it's used in grouping
Add all annotations (annotations now, phenoinfo and gwas catalog comparison)
Output normal report, top report.

These steps IMO pave the way for some more ambitious changes:

Switch to a config file from args. This would integrate quite well with having most data resources as DAOs, I think. I imagine something like pheweb's DAO config would be the easiest. Using command-line args gets old fast when there are more than 20 flags and options that need to be set.
Use actual multithreading to load the annotations. Since they don't depend on each other, it should be trivial to just load them using multiprocessing and a threadpool. Would be nice since e.g. gwas catalog annotation is 99% waiting for a request to go through. Other annotations are single-threaded and most likely processor-bound, so having may of them run at the same time should be no problem.

This was done in the new grouping PR.


Revisit supported versions of python, numpy

Right now, our policy is to support the two most recent python 3 versions plus python 2.7 and the two most recent numpy releases.
I think this is a little overengineered, especially since everyone involved in packaging has a "day job" other than packaging. We run into issues supporting odd configurations that no one is using (python 3.5 and numpy 1.9)
I'd like to open the discussion for dropping support for certain configurations. My ideas are as follows

Drop numpy 1.9. Anyone with conda can and will easily upgrade to numpy 1.10
Drop python 3.4 at some point in the near future. It's nice having both during the "transition" period when python 3.5 wasn't mature. Maybe when 3.5.2 comes out, we can drop support for 3.4
Drop python 2.7 and 3.4 on windows. This would simplify the building of things with compiled extensions a lot, since vs2015 has a much more compliant compiler. Windows users don't have a /usr/bin/python stuck on 2.7 that they're clinging to.
Consider dropping python 2.7 at some point. Its EOL is in 2020 (4 years away). Anyone using conda can easily get a newer version of python

Let me know what you all think

Consider dropping python 2.7 at some point. Its EOL is in 2020 (4 years away). Anyone using conda can easily get a newer version of python

Many of us here are still stuck on python 2.7, so it would be best to avoid dropping that for a little while.
I'm fine with dropping 3.4 now or soon.

Thought I might get some push back on that one :)
What are your thoughts on dropping numpy 1.9

What are your thoughts on dropping numpy 1.9

I don't have a good idea for how much trouble that would cause, so I'm game to give it a try...

I am fine with dropping older numpys, but think it would be a shame to drop older pythons.
Sent from my iPhone

On Mar 29, 2016, at 10:03 PM, John Chodera<EMAIL_ADDRESS>wrote:
What are your thoughts on dropping numpy 1.9
I don't have a good idea for how much trouble that would cause, so I'm game to give it a try...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

Dropping older Pythons also requires a good deal of warning, since we have to update all the .travis.yml files to exclude the dropped Python version...

Upgrading Python versions is disruptive and a hassle.  Once you get python all set up, and everything you want installed in it, who wants to have to throw it out and do all that work over again?  That's not to say we have to keep supporting them forever, but Python 3.5 was only released in September!  You already want to stop supporting 3.4?
On Windows it's especially complicated due to the issues with binary compatibility.  Python 3.4 and 3.5 were compiled with different versions of Visual Studio, so they can only link to libraries that were compiled with those same versions.

Numpy 1.11 was just released. When that becomes available through conda, we can start building packages for that and dropping numpy 1.9


[Bug]: Calling Python transforms from Go pipeline results in an error

What happened?
Following the documentation available here for Beam 2.4.1, I am trying to write a simple pipeline in Go using an external transform defined in Python.
I followed the docs with my own "word count" code but ended up having an error that was very obscure. Then I decided to run the Python test cross lang suite (pip installed at apache_beam/runners/portability/expansion_service_test.py) to use it as expansion service entrypoint and call a sample from the Go SDK tree, specifically, the xlang/wordcount sample. To my surprise, It failed with the same kind of error.
After several trial and errors I failed to get Go pipeline call an external Python transform following the docs and even reading some code from the stack traces.
Here is the output from the Python expansion service:
(env) $ python ../env/lib/python3.9/site-packages/apache_beam/runners/portability/expansion_service_test.py -p 12345
INFO:apache_beam.runners.portability.stager:Executing command: ['/home/ronoaldo/workspace/micro-beam/env/bin/python', '-m', 'pip', 'download', '--dest', '/tmp/dataflow-requirements-cache', '-r', '/tmp/tmpomfse_4t/tmp_requirements.txt', '--exists-action', 'i', '--no-deps', '--implementation', 'cp', '--abi', 'cp39', '--platform', 'manylinux2014_x86_64']
INFO:root:Default Python SDK image for environment is apache/beam_python3.9_sdk:2.41.0
INFO:root:No image given, using default Python SDK image
INFO:root:Default Python SDK image for environment is apache/beam_python3.9_sdk:2.41.0
INFO:root:Python SDK container image set to "apache/beam_python3.9_sdk:2.41.0" for Docker environment
INFO:__main__:Listening for expansion requests at 12345
INFO:root:Missing pipeline option (runner). Executing pipeline using the default runner: DirectRunner.

This is the error from the pipeline (very similar one I got with my own code, except it was complaining for 'n5' but same KeyError at the same place):
(env) $ wordcount --expansion_addr=localhost:12345
panic:  tried cross-language for beam:transforms:xlang:count against localhost:12345 and failed
        expanding external transform
        expanding transform with ExpansionRequest: components:{pcollections:{key:"n3" value:{unique_name:"n3" coder_id:"c0@OfMQSsncEv" is_bounded:BOUNDED windowing_strategy_id:"w0@OfMQSsncEv"}} windowing_strategies:{key:"w0@OfMQSsncEv" value:{window_fn:{urn:"beam:window_fn:global_windows:v1"} merge_status:NON_MERGING window_coder_id:"c1@OfMQSsncEv" trigger:{default:{}} accumulation_mode:DISCARDING output_time:END_OF_WINDOW closing_behavior:EMIT_IF_NONEMPTY on_time_behavior:FIRE_IF_NONEMPTY environment_id:"go"}} coders:{key:"c0@OfMQSsncEv" value:{spec:{urn:"beam:coder:string_utf8:v1"}}} coders:{key:"c1@OfMQSsncEv" value:{spec:{urn:"beam:coder:global_window:v1"}}} environments:{key:"go" value:{}}} transform:{unique_name:"External" spec:{urn:"beam:transforms:xlang:count"} inputs:{key:"i0" value:"n3"} environment_id:"go"} namespace:"OfMQSsncEv"
expansion failed
        caused by:
Traceback (most recent call last):
  File "/home/ronoaldo/workspace/micro-beam/env/lib/python3.9/site-packages/apache_beam/runners/portability/expansion_service.py", line 77, in Expand
    inputs = transform._pvaluish_from_dict({
  File "/home/ronoaldo/workspace/micro-beam/env/lib/python3.9/site-packages/apache_beam/runners/portability/expansion_service.py", line 79, in <dictcomp>
    with_pipeline(context.pcollections.get_by_id(pcoll_id), pcoll_id)
  File "/home/ronoaldo/workspace/micro-beam/env/lib/python3.9/site-packages/apache_beam/runners/portability/expansion_service.py", line 49, in with_pipeline
    component.producer, component.tag = producers[pcoll_id]
KeyError: 'n3'

goroutine 1 [running]:
github.com/apache/beam/sdks/v2/go/pkg/beam.CrossLanguage({0xc000480ac0?, 0xc0004b1090?}, {0xfdbd06, 0x1b}, {0x0?, 0x8?, 0x7f39103faa68?}, {0x7fffd9812cdc, 0xf}, 0xc0006bfc68, ...)
        /home/ronoaldo/go/pkg/mod/github.com/apache/beam/sdks/v2@v2.41.0/go/pkg/beam/xlang.go:162 +0x136
github.com/apache/beam/sdks/v2/go/examples/xlang.Count({0xc0004809c0?, 0xc0004b1090?}, {0x7fffd9812cdc, 0xf}, {0x0?})
        /home/ronoaldo/go/pkg/mod/github.com/apache/beam/sdks/v2@v2.41.0/go/examples/xlang/transforms.go:113 +0x3d4
main.main()
        /home/ronoaldo/go/pkg/mod/github.com/apache/beam/sdks/v2@v2.41.0/go/examples/xlang/wordcount/wordcount.go:94 +0x22e

I tested this using a Python virtual env with apache-beam[gcp] and go install'ed this example: github.com/apache/beam/sdks/v2/go/examples/xlang/wordcount@latest. From one terminal session I launched the expansion service and on another the wordcount Go program.
Issue Priority
Priority: 2
Issue Component
Component: sdk-go

cc: @chamikaramj to triage.

I'm indeed curious about what I am missing from docs regarding calling xlang transforms.
Following the chapter 13 of Beam Programming Model guide, I wrote three Pipelines, one on each language. The Python and Java one expose their SplitWords implementation to an expansion service.
I can run each pipeline, both locally and on Google Cloud Dataflow remote worker, to make sure they all are properly working by their own. Each main has some arguments to allow for a cross language call configuration.
I have then tested several combinations of xlang calls and only one worked:

Calling the Python implementation from Go fails
Calling the Java implementation from Go also fails, but with a different error.
Calling the Java implementation from Python works! I have not tested yet calling Python implementation from Java.

This is the Go output after I launch the Java expansion server:
2022/09/01 18:02:49 Using external transform SplitWordsFromJava at localhost:12345
2022/09/01 18:02:50 Executing pipeline with the direct runner.
2022/09/01 18:02:50 Pipeline:
2022/09/01 18:02:50 Nodes: {1: []uint8/bytes GLO}
{2: string/string GLO}
{3: string/string GLO}
{4: KV<string,int64>/KV<string,varint> GLO}
{5: string/string GLO}
{6: string/string GLO}
{7: KV<string,int>/KV<string,int[varintz]> GLO}
{8: CoGBK<string,int>/CoGBK<string,int[varintz]> GLO}
{9: KV<string,int>/KV<string,int[varintz]> GLO}
{10: main.CountedWord/R[main.CountedWord] GLO}
{11: KV<int,main.CountedWord>/KV<int[varintz],R[main.CountedWord]> GLO}
{12: CoGBK<int,main.CountedWord>/CoGBK<int[varintz],R[main.CountedWord]> GLO}
{13: KV<int,[]main.CountedWord>/KV<int[varintz],[]main.CountedWord[json]> GLO}
{14: []main.CountedWord/[]main.CountedWord[json] GLO}
{15: string/string GLO}
{16: KV<int,string>/KV<int[varintz],string> GLO}
{17: CoGBK<int,string>/CoGBK<int[varintz],string> GLO}
Edges: 1: Impulse [] -> [Out: []uint8 -> {1: []uint8/bytes GLO}]
2: ParDo [In(Main): []uint8 <- {1: []uint8/bytes GLO}] -> [Out: T -> {2: string/string GLO}]
3: ParDo [In(Main): string <- {2: string/string GLO}] -> [Out: string -> {3: string/string GLO}]
4: ParDo [In(Main): string <- {3: string/string GLO}] -> [Out: KV<string,int64> -> {4: KV<string,int64>/KV<string,varint> GLO}]
5: ParDo [In(Main): KV<string,int64> <- {4: KV<string,int64>/KV<string,varint> GLO}] -> [Out: string -> {5: string/string GLO}]
6: External [In(Main): string <- {5: string/string GLO}] -> [Out: string -> {6: string/string GLO}]
7: ParDo [In(Main): T <- {6: string/string GLO}] -> [Out: KV<T,int> -> {7: KV<string,int>/KV<string,int[varintz]> GLO}]
8: CoGBK [In(Main): KV<string,int> <- {7: KV<string,int>/KV<string,int[varintz]> GLO}] -> [Out: CoGBK<string,int> -> {8: CoGBK<string,int>/CoGBK<string,int[varintz]> GLO}]
9: Combine [In(Main): int <- {8: CoGBK<string,int>/CoGBK<string,int[varintz]> GLO}] -> [Out: KV<string,int> -> {9: KV<string,int>/KV<string,int[varintz]> GLO}]
10: ParDo [In(Main): KV<string,int> <- {9: KV<string,int>/KV<string,int[varintz]> GLO}] -> [Out: main.CountedWord -> {10: main.CountedWord/R[main.CountedWord] GLO}]
11: ParDo [In(Main): T <- {10: main.CountedWord/R[main.CountedWord] GLO}] -> [Out: KV<int,T> -> {11: KV<int,main.CountedWord>/KV<int[varintz],R[main.CountedWord]> GLO}]
12: CoGBK [In(Main): KV<int,main.CountedWord> <- {11: KV<int,main.CountedWord>/KV<int[varintz],R[main.CountedWord]> GLO}] -> [Out: CoGBK<int,main.CountedWord> -> {12: CoGBK<int,main.CountedWord>/CoGBK<int[varintz],R[main.CountedWord]> GLO}]
13: Combine [In(Main): T <- {12: CoGBK<int,main.CountedWord>/CoGBK<int[varintz],R[main.CountedWord]> GLO}] -> [Out: KV<int,[]T> -> {13: KV<int,[]main.CountedWord>/KV<int[varintz],[]main.CountedWord[json]> GLO}]
14: ParDo [In(Main): KV<X,Y> <- {13: KV<int,[]main.CountedWord>/KV<int[varintz],[]main.CountedWord[json]> GLO}] -> [Out: Y -> {14: []main.CountedWord/[]main.CountedWord[json] GLO}]
15: ParDo [In(Main): []main.CountedWord <- {14: []main.CountedWord/[]main.CountedWord[json] GLO}] -> [Out: string -> {15: string/string GLO}]
16: ParDo [In(Main): T <- {15: string/string GLO}] -> [Out: KV<int,T> -> {16: KV<int,string>/KV<int[varintz],string> GLO}]
17: CoGBK [In(Main): KV<int,string> <- {16: KV<int,string>/KV<int[varintz],string> GLO}] -> [Out: CoGBK<int,string> -> {17: CoGBK<int,string>/CoGBK<int[varintz],string> GLO}]
18: ParDo [In(Main): CoGBK<int,string> <- {17: CoGBK<int,string>/CoGBK<int[varintz],string> GLO}] -> []
2022/09/01 18:02:50 Failed to execute job: translation failed
	caused by:
unexpected edge: 6: External [In(Main): string <- {5: string/string GLO}] -> [Out: string -> {6: string/string GLO}]
panic: Failed to execute job: translation failed
	caused by:
unexpected edge: 6: External [In(Main): string <- {5: string/string GLO}] -> [Out: string -> {6: string/string GLO}]

goroutine 1 [running]:
github.com/apache/beam/sdks/v2/go/pkg/beam/log.Fatalf({0x114d0e0, 0xc0000420e8}, {0xfeb8b2?, 0x18?}, {0xc0006bff60?, 0x0?, 0x464f1b?})
	/home/ronoaldo/go/pkg/mod/github.com/apache/beam/sdks/v2@v2.41.0/go/pkg/beam/log/log.go:153 +0xa5
main.main()
	/home/ronoaldo/workspace/micro-beam/05_xlang/go/pipeline.go:144 +0x2a8
exit status 2

I don't think using Python transforms from Go SDK is fully supported yet. I believe @riteshghorse is looking into this.

Yes, Python transform from Go will be available by mid Sept in Go SDK at the Head or we will try to get it in for 2.42 release.
Note: Cross Language transforms doesn't work on Go Direct Runner. You have to use Python Portable/Flink/Dataflow runner.
Here is an example code for running KafkaIO in Go SDK using Cross-Language with Java SDK: https://github.com/apache/beam/blob/master/sdks/go/examples/kafka/taxi.go

Yes, Python transform from Go will be available by mid Sept in Go SDK at the Head or we will try to get it in for 2.42 release.

Yay! Super! Thanks

Note: Cross Language transforms doesn't work on Go Direct Runner. You have to use Python Portable/Flink/Dataflow runner.
Here is an example code for running KafkaIO in Go SDK using Cross-Language with Java SDK: https://github.com/apache/beam/blob/master/sdks/go/examples/kafka/taxi.go

Oh, that is interesting. While reading over that example I didn't noticed it was not using the Direct Runner from Go. Just to make sure I understood properly, if I use a different runner, such as Dataflow, my sample that calls Go from Java should work, right? I mean, using a custom-made jar from the Java side instead of using a Java Beam SDK transform.
Calling Python from Go would be very nice in order to have access to some very handy transforms like DataframeTransform.
To avoid cluttering the issue tracker, you guys can close / relate this issue to the one tracking the implementation of Go -> Python xlang calls.

@ronoaldo Yes, Dataflow, Flink, and the Python Portable runner support executing Cross Language transforms. The Go Direct Runner doesn't and is going to be replaced with something more useful in the next 6 months.
I think we currently plan to wrap the Dataframe transforms too, along with Run Inference.
At this point, we're aiming for the 2.43.0 or 2.44.0 releases though, as 2.42.0 is cut.
I don't think we have a public issue for tracking this though, so I'll assign to @riteshghorse , and he can close this issue after referencing any existing issues. Thank you for the clear reports though!

(swapped some labels and edited the title things for book keeping)

I would also point out that the docs state this as being a possible workflow as of now, which is what confused me in the beginning:

13.2.3. Using cross-language transforms in a Go pipeline
If a Go-specific wrapper for a cross-language is available, use that. Otherwise, you have to use the lower-level CrossLanguage function to access the transform.
Expansion Services
The Go SDK supports automatically starting Java expansion services if an expansion address is not provided, although this is slower than providing a persistent expansion service. Many wrapped Java transforms manage perform this automatically; if you wish to do this manually, use the xlangx package’s UseAutomatedJavaExpansionService() function. In order to use Python cross-language transforms, you must manually start any necessary expansion services on your local machine and ensure they are accessible to your code during pipeline construction.

If 2.42 docs can be updated, it worth mentioning that calling Python from Go is unsupported, instead of telling that we must start the expansion service manually.


Release build creating stuck for ios and android

Environment
React Native Environment Info:
System:
OS: macOS 10.14.2
CPU: (4) x64 Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz
Memory: 31.72 MB / 8.00 GB
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 9.5.0 - /usr/local/bin/node
npm: 4.4.4 - /usr/local/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
Android SDK:
API Levels: 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27
Build Tools: 19.1.0, 20.0.0, 21.1.2, 22.0.1, 23.0.1, 23.0.2, 23.0.3, 24.0.0, 24.0.1, 24.0.2, 24.0.3, 25.0.0, 25.0.2, 25.0.3, 26.0.0, 26.0.1, 26.0.2, 26.0.3, 27.0.3
System Images: android-25 | Google APIs Intel x86 Atom, android-26 | Google APIs Intel x86 Atom, android-27 | Google APIs Intel x86 Atom
IDEs:
Android Studio: 3.2 AI-181.55<IP_ADDRESS>56338
Xcode: 10.1/10B61 - /usr/bin/xcodebuild
npmPackages:
react: 16.6.3 => 16.6.3
react-native: 0.57.8 => 0.57.8
Description
This problem started when I upgraded from 0.56.
I gone through similar issues I reinstalled watchman, clear cache, manually delete build data etc.
But when I try to create release in xcode or from terminal for android it stuck:
for android about: 22%
for ios: last step executing scripts last forever
> Task :app:bundleReleaseJsAndAssets
warning: the transform cache was reset.
Loading dependency graph, done.
<==-----------> 22% EXECUTING [6m 37s]
> :app:bundleReleaseJsAndAssets

Hey @vvusts, thanks for filing and sorry for the delay
Unfortunately there's not enough information here for us to act on. If you are still experiencing this issue and have more information on how to reproduce I'm happy to re-open and take a look 👍


Information on RTSP & 1.3.9

Description
Apologies, this isn't a bug but there seems to be lots of issues with RTSP and ONVIF not working on C100/C200 cameras after the latest update. The ports are open and we can ping the cameras but can't connect. If anyone is having trouble like me then head over to the TP-LINK Smart Home Community forums. I haven't found a fix yet.
Reproduction Steps
C100 with integration.
Expected behavior
Prior to 1.3.9
If applicable, add error logs.
No response
Device Firmware
1.3.9
Integration Version
5.4.12
Using stream component
Yes
Does camera work via official integrations?
Yes
Camera has all attributes filled out in developer tools
Yes
HASS Environment
HAOS
Search for similar issues
Yes
Additional information
No response

Same here, SDStream and HDStream are unavailable...

Read FAQ, closing due to this not being an integration issue.


Off-by-one errors on implicit highlighting

Scenario:
Have val test = "a" #> "foo", types a o and get val test = "a" #> "fooo". Autocomplete triggers a call to server with buffer content which is indexed. Backspace back to val test = "a" #> "foo" and hit save. This triggers call to get implicits. Even if I had a typecheck buffer before tied to save as well it didn't have the time to re-index (even if this call was made before implicit-call). I get a off-by-one error on the marking of the implicit, which looks pretty bad with newlines:

incoming: {"callId":404,"payload":{"typehint":"CompletionInfoList","prefix":"","completions":[]}}
implicits.coffee:27 showImplicits this: [object Object]
utils.coffee:37 outgoing: 0000a2{"req": {"typehint":"ImplicitInfoReq","file":"/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala","range":{"from":0,"to":76}}, "callId": 405}
client.coffee:14 incoming: {"callId":405,"payload":{"typehint":"ImplicitInfos","infos":[{"params":[{"name":"stringTransform","localName":"stringTransform","declPos":{"typehint":"OffsetSourcePosition","file":"/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala","offset":22360},"type":{"name":"CanBind","fullName":"net.liftweb.util.CanBind","pos":{"typehint":"OffsetSourcePosition","file":"/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala","offset":22262},"typehint":"BasicTypeInfo","typeId":45,"typeArgs":[{"name":"String","fullName":"java.lang.String","typehint":"BasicTypeInfo","typeId":46,"typeArgs":[],"members":[],"declAs":{"typehint":"Class"}}],"members":[],"declAs":{"typehint":"Trait"}},"isCallable":false,"ownerTypeId":47}],"typehint":"ImplicitParamInfo","fun":{"name":"#>","localName":"#>","declPos":{"typehint":"OffsetSourcePosition","file":"/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala","offset":29237},"type":{"resultType":{"name":"CssSel","fullName":"net.liftweb.util.CssSel","typehint":"BasicTypeInfo","typeId":1,"typeArgs":[],"members":[],"declAs":{"typehint":"Trait"}},"name":"[T](it: => T)(implicit computer: net.liftweb.util.CanBind[T])net.liftweb.util.CssSel","paramSections":[{"params":[["it",{"name":"<byname>","fullName":"scala.<byname>","typehint":"BasicTypeInfo","typeId":4133,"typeArgs":[{"name":"T","fullName":"net.liftweb.util.T","typehint":"BasicTypeInfo","typeId":4134,"typeArgs":[],"members":[],"declAs":{"typehint":"Nil"}}],"members":[],"declAs":{"typehint":"Class"}}]],"isImplicit":false},{"params":[["computer",{"name":"CanBind","fullName":"net.liftweb.util.CanBind","typehint":"BasicTypeInfo","typeId":4135,"typeArgs":[{"name":"T","fullName":"net.liftweb.util.T","typehint":"BasicTypeInfo","typeId":4134,"typeArgs":[],"members":[],"declAs":{"typehint":"Nil"}}],"members":[],"declAs":{"typehint":"Trait"}}]],"isImplicit":true}],"typehint":"ArrowTypeInfo","typeId":4136},"isCallable":true,"ownerTypeId":44},"funIsImplicit":false,"end":73,"start":61},{"typehint":"ImplicitConversionInfo","start":61,"end":64,"fun":{"name":"strToCssBindPromoter","localName":"strToCssBindPromoter","declPos":{"typehint":"OffsetSourcePosition","file":"/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/BindHelpers.scala","offset":47948},"type":{"resultType":{"name":"ToCssBindPromoter","fullName":"net.liftweb.util.ToCssBindPromoter","typehint":"BasicTypeInfo","typeId":44,"typeArgs":[],"members":[],"declAs":{"typehint":"Class"}},"name":"(str: String)net.liftweb.util.ToCssBindPromoter","paramSections":[{"params":[["str",{"name":"String","fullName":"java.lang.String","typehint":"BasicTypeInfo","typeId":46,"typeArgs":[],"members":[],"declAs":{"typehint":"Class"}}]],"isImplicit":false}],"typehint":"ArrowTypeInfo","typeId":1886},"isCallable":true,"ownerTypeId":49}}]}}
implicits.coffee:42 Object {typehint: "ImplicitInfos", infos: Array[2]}infos: Array[2]0: Objectend: 73fun: ObjectfunIsImplicit: falseparams: Array[1]start: 61typehint: "ImplicitParamInfo"__proto__: Object1: Objectlength: 2__proto__: Array[0]typehint: "ImplicitInfos"__proto__: Object
utils.coffee:37 outgoing: 000093{"req": {"typehint":"SymbolAtPointReq","file":"/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala","point":72}, "callId": 406}
client.coffee:14 incoming: {"callId":406,"payload":{"typehint":"FalseResponse"}}
utils.coffee:37 ensime.getSuggestions
utils.coffee:37 outgoing: 000130{"req": {"typehint":"CompletionsReq","fileInfo":{"file":"/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala","contents":"import net.liftweb.util.Helpers._\n\nobject Bar {\n  val test = \"a\" #> \"fooo\"\n}\n"},"point":73,"maxResults":5,"caseSens":false,"reload":true}, "callId": 407}
client.coffee:14 incoming: {"callId":407,"payload":{"typehint":"CompletionInfoList","prefix":"","completions":[]}}
implicits.coffee:27 showImplicits this: [object Object]
utils.coffee:37 outgoing: 0000a2{"req": {"typehint":"ImplicitInfoReq","file":"/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala","range":{"from":0,"to":76}}, "callId": 408}
client.coffee:14 incoming: {"callId":408,"payload":{"typehint":"ImplicitInfos","infos":[{"params":[{"name":"stringTransform","localName":"stringTransform","declPos":{"typehint":"OffsetSourcePosition","file":"/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala","offset":22360},"type":{"name":"CanBind","fullName":"net.liftweb.util.CanBind","pos":{"typehint":"OffsetSourcePosition","file":"/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala","offset":22262},"typehint":"BasicTypeInfo","typeId":45,"typeArgs":[{"name":"String","fullName":"java.lang.String","typehint":"BasicTypeInfo","typeId":46,"typeArgs":[],"members":[],"declAs":{"typehint":"Class"}}],"members":[],"declAs":{"typehint":"Trait"}},"isCallable":false,"ownerTypeId":47}],"typehint":"ImplicitParamInfo","fun":{"name":"#>","localName":"#>","declPos":{"typehint":"OffsetSourcePosition","file":"/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala","offset":29237},"type":{"resultType":{"name":"CssSel","fullName":"net.liftweb.util.CssSel","typehint":"BasicTypeInfo","typeId":1,"typeArgs":[],"members":[],"declAs":{"typehint":"Trait"}},"name":"[T](it: => T)(implicit computer: net.liftweb.util.CanBind[T])net.liftweb.util.CssSel","paramSections":[{"params":[["it",{"name":"<byname>","fullName":"scala.<byname>","typehint":"BasicTypeInfo","typeId":4137,"typeArgs":[{"name":"T","fullName":"net.liftweb.util.T","typehint":"BasicTypeInfo","typeId":4138,"typeArgs":[],"members":[],"declAs":{"typehint":"Nil"}}],"members":[],"declAs":{"typehint":"Class"}}]],"isImplicit":false},{"params":[["computer",{"name":"CanBind","fullName":"net.liftweb.util.CanBind","typehint":"BasicTypeInfo","typeId":4139,"typeArgs":[{"name":"T","fullName":"net.liftweb.util.T","typehint":"BasicTypeInfo","typeId":4138,"typeArgs":[],"members":[],"declAs":{"typehint":"Nil"}}],"members":[],"declAs":{"typehint":"Trait"}}]],"isImplicit":true}],"typehint":"ArrowTypeInfo","typeId":4140},"isCallable":true,"ownerTypeId":44},"funIsImplicit":false,"end":74,"start":61},{"typehint":"ImplicitConversionInfo","start":61,"end":64,"fun":{"name":"strToCssBindPromoter","localName":"strToCssBindPromoter","declPos":{"typehint":"OffsetSourcePosition","file":"/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/BindHelpers.scala","offset":47948},"type":{"resultType":{"name":"ToCssBindPromoter","fullName":"net.liftweb.util.ToCssBindPromoter","typehint":"BasicTypeInfo","typeId":44,"typeArgs":[],"members":[],"declAs":{"typehint":"Class"}},"name":"(str: String)net.liftweb.util.ToCssBindPromoter","paramSections":[{"params":[["str",{"name":"String","fullName":"java.lang.String","typehint":"BasicTypeInfo","typeId":46,"typeArgs":[],"members":[],"declAs":{"typehint":"Class"}}]],"isImplicit":false}],"typehint":"ArrowTypeInfo","typeId":1886},"isCallable":true,"ownerTypeId":49}}]}}

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/26401953-off-by-one-errors-on-implicit-highlighting?utm_campaign=plugin&utm_content=tracker%2F14719420&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F14719420&utm_medium=issues&utm_source=github).

Either could make implicits send buffer content too, but I'm thinking - don't we have a structural problem that indexing of file is updated on server when doing autocomplete without save? I'm thinking I could actually update ensime-atom's behaviour on autocomplete calls to be:

ask for completions on buffer content
index file content (rollback index)

Hm, I don't know…

Oh, that approach doesn't even work. TypecheckFileReq doesn't even update the index it seems. Is this right, @fommil? I might need some guidance here…

Seems my hook to typecheck buffer is called after implicits call, so maybe just doing it the other way around will actually work?
Isolated conversation:
outgoing: 000130{
  "req": {
    "typehint": "CompletionsReq",
    "fileInfo": {
      "file": "/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala",
      "contents": "import net.liftweb.util.Helpers._\n\nobject Bar {\n  val test = \"a\" #> \"fooo\"\n}\n"
    },
    "point": 73,
    "maxResults": 5,
    "caseSens": false,
    "reload": true
  },
  "callId": 433
}
incoming: {
  "callId": 433,
  "payload": {
    "typehint": "CompletionInfoList",
    "prefix": "",
    "completions": []
  }
}
outgoing: 0000a2{
  "req": {
    "typehint": "ImplicitInfoReq",
    "file": "/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala",
    "range": {
      "from": 0,
      "to": 76
    }
  },
  "callId": 434
}
outgoing: 0000f8{
  "req": {
    "typehint": "TypecheckFileReq",
    "fileInfo": {
      "file": "/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala",
      "contents": "import net.liftweb.util.Helpers._\n\nobject Bar {\n  val test = \"a\" #> \"foo\"\n}\n"
    }
  },
  "callId": 435
}
incoming: {
  "callId": 434,
  "payload": {
    "typehint": "ImplicitInfos",
    "infos": [
      {
        "params": [
          {
            "name": "stringTransform",
            "localName": "stringTransform",
            "declPos": {
              "typehint": "OffsetSourcePosition",
              "file": "/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala",
              "offset": 22360
            },
            "type": {
              "name": "CanBind",
              "fullName": "net.liftweb.util.CanBind",
              "pos": {
                "typehint": "OffsetSourcePosition",
                "file": "/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala",
                "offset": 22262
              },
              "typehint": "BasicTypeInfo",
              "typeId": 45,
              "typeArgs": [
                {
                  "name": "String",
                  "fullName": "java.lang.String",
                  "typehint": "BasicTypeInfo",
                  "typeId": 46,
                  "typeArgs": [],
                  "members": [],
                  "declAs": {
                    "typehint": "Class"
                  }
                }
              ],
              "members": [],
              "declAs": {
                "typehint": "Trait"
              }
            },
            "isCallable": false,
            "ownerTypeId": 47
          }
        ],
        "typehint": "ImplicitParamInfo",
        "fun": {
          "name": "#>",
          "localName": "#>",
          "declPos": {
            "typehint": "OffsetSourcePosition",
            "file": "/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala",
            "offset": 29237
          },
          "type": {
            "resultType": {
              "name": "CssSel",
              "fullName": "net.liftweb.util.CssSel",
              "typehint": "BasicTypeInfo",
              "typeId": 1,
              "typeArgs": [],
              "members": [],
              "declAs": {
                "typehint": "Trait"
              }
            },
            "name": "[T](it: => T)(implicit computer: net.liftweb.util.CanBind[T])net.liftweb.util.CssSel",
            "paramSections": [
              {
                "params": [
                  [
                    "it",
                    {
                      "name": "<byname>",
                      "fullName": "scala.<byname>",
                      "typehint": "BasicTypeInfo",
                      "typeId": 4165,
                      "typeArgs": [
                        {
                          "name": "T",
                          "fullName": "net.liftweb.util.T",
                          "typehint": "BasicTypeInfo",
                          "typeId": 4166,
                          "typeArgs": [],
                          "members": [],
                          "declAs": {
                            "typehint": "Nil"
                          }
                        }
                      ],
                      "members": [],
                      "declAs": {
                        "typehint": "Class"
                      }
                    }
                  ]
                ],
                "isImplicit": false
              },
              {
                "params": [
                  [
                    "computer",
                    {
                      "name": "CanBind",
                      "fullName": "net.liftweb.util.CanBind",
                      "typehint": "BasicTypeInfo",
                      "typeId": 4167,
                      "typeArgs": [
                        {
                          "name": "T",
                          "fullName": "net.liftweb.util.T",
                          "typehint": "BasicTypeInfo",
                          "typeId": 4166,
                          "typeArgs": [],
                          "members": [],
                          "declAs": {
                            "typehint": "Nil"
                          }
                        }
                      ],
                      "members": [],
                      "declAs": {
                        "typehint": "Trait"
                      }
                    }
                  ]
                ],
                "isImplicit": true
              }
            ],
            "typehint": "ArrowTypeInfo",
            "typeId": 4168
          },
          "isCallable": true,
          "ownerTypeId": 44
        },
        "funIsImplicit": false,
        "end": 74,
        "start": 61
      },
      {
        "typehint": "ImplicitConversionInfo",
        "start": 61,
        "end": 64,
        "fun": {
          "name": "strToCssBindPromoter",
          "localName": "strToCssBindPromoter",
          "declPos": {
            "typehint": "OffsetSourcePosition",
            "file": "/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/BindHelpers.scala",
            "offset": 47948
          },
          "type": {
            "resultType": {
              "name": "ToCssBindPromoter",
              "fullName": "net.liftweb.util.ToCssBindPromoter",
              "typehint": "BasicTypeInfo",
              "typeId": 44,
              "typeArgs": [],
              "members": [],
              "declAs": {
                "typehint": "Class"
              }
            },
            "name": "(str: String)net.liftweb.util.ToCssBindPromoter",
            "paramSections": [
              {
                "params": [
                  [
                    "str",
                    {
                      "name": "String",
                      "fullName": "java.lang.String",
                      "typehint": "BasicTypeInfo",
                      "typeId": 46,
                      "typeArgs": [],
                      "members": [],
                      "declAs": {
                        "typehint": "Class"
                      }
                    }
                  ]
                ],
                "isImplicit": false
              }
            ],
            "typehint": "ArrowTypeInfo",
            "typeId": 1886
          },
          "isCallable": true,
          "ownerTypeId": 49
        }
      }
    ]
  }
}
incoming: {
  "payload": {
    "typehint": "ClearAllScalaNotesEvent"
  }
}
incoming: {
  "callId": 435,
  "payload": {
    "typehint": "VoidResponse"
  }
}
incoming: {
  "payload": {
    "typehint": "NewScalaNotesEvent",
    "isFull": false,
    "notes": [
      {
        "beg": 29353,
        "line": 899,
        "col": 42,
        "end": 29357,
        "file": "/Users/viktor/dev/projects/ensime-test-project/.ensime_cache/dep-src/source-jars/net/liftweb/util/CssSel.scala",
        "msg": "a pure expression does nothing in statement position; you may be omitting necessary parentheses",
        "severity": {
          "typehint": "NoteWarn"
        }
      }
    ]
  }
}
incoming: {
  "payload": {
    "typehint": "FullTypeCheckCompleteEvent"
  }
}

hmm, maybe the end position is exclusive? We never rigorously defined that. Is it consistently off by one?

Ah, yeah. I could get away with just typechecking buffer before asking for implicits. However, I ask twice in a row:
outgoing: 0000f6{"req": {"typehint":"TypecheckFileReq","fileInfo":{"file":"/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala","contents":"import net.liftweb.util.Helpers._\n\nobject Bar {\n  val test = \"a\" #> \"foo\"\n}\n"}}, "callId": 7}
utils.coffee:37 outgoing: 0000f6{"req": {"typehint":"TypecheckFileReq","fileInfo":{"file":"/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala","contents":"import net.liftweb.util.Helpers._\n\nobject Bar {\n  val test = \"a\" #> \"foo\"\n}\n"}}, "callId": 8}
client.coffee:14 incoming: {"payload":{"typehint":"ClearAllScalaNotesEvent"}}
client.coffee:14 incoming: {"callId":7,"payload":{"typehint":"VoidResponse"}}
utils.coffee:37 outgoing: 0000a0{"req": {"typehint":"ImplicitInfoReq","file":"/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala","range":{"from":0,"to":76}}, "callId": 9}
client.coffee:14 incoming: {"payload":{"typehint":"ClearAllScalaNotesEvent"}}
client.coffee:14 incoming: {"callId":8,"payload":{"typehint":"VoidResponse"}}

Seems I might need to be a bit smarter with the client stacking of requests…

@fommil Sorry, the problem was that the buffer is indexed for every character insertion but not backspace due to the way the autocomplete-plus plugin works in Atom. So, I write "fooo" and this is indexed, then I backspace back to "foo" but this wasn't indexed before I ask about implicits (which currently does not take buffer as param, but only file name) If I just typechecked the file before it was indexed and server answered with correct offsets.
A better fix should probably be to add fileInfo in ImplicitInfoReq instead of just file and make that API call index as the other does.

But I still have a bit of a bad feeling that the server index of a file is updated just by using autocomplete while typing.

I'm not sure you need to typecheck the file for every character inserted, just when you want to do something with it. Emacs is smart enough to only typecheck the file when it actually needs something from the server, and will typecheck on idle. I think.

I'm not typechecking the file, but asking when asking for completions I send the buffer:
{"req": {"typehint":"CompletionsReq","fileInfo":{"file":"/Users/viktor/dev/projects/ensime-test-project/src/main/scala/Bar.scala","contents":"import net.liftweb.util.Helpers._\n\nobject Bar {\n  val test = "a" #> "fooo"\n}\n"},"point":73,"maxResults":5,"caseSens":false,"reload":true}, "callId": 6}
without that autocomplete would not be meaningful.

aah, ok that is probably what we do too

And I'm guessing now, but here:
https://github.com/ensime/ensime-server/blob/master/core/src/main/scala/org/ensime/core/Completion.scala#L64
the index is updated, but never reverted?


about documentation

I'm new here in ionic and I really love its concept.
Now I am trying to build an app using it but I am so confused.
Is there a documentation existed about ionic mobile DOM elements?
For example, I wanted to change the toggle color of <ion-toggle> into calm
I dig into ionic css documentation and showed me example but what's in there was html native DOM elements. in fact all examples there used native DOM elements which doesn't work with ionic mobile app.
I created a project using ionic start myApp tabs
there are alot of custom tags, like ion-content, ion-list and ion-option-button.

Greetings @roiabrazaldo!
My sensors indicate that you need to update your issue through our custom issue form. We are now requiring all issues to be submitted this way, to ensure that we have all of the information necessary to fix them as quickly as possible.
Click Here To Update Your Issue
I will have no choice but to close this issue if it is not resubmitted through the form. Please fill out the rest of the form, so that I may use my friendly robot powers to assist you.
Thank you!

The ion-contents, ion-list are angular directives, you can read more about them here
http://ionicframework.com/docs/api/
For the toggle, it seems to be working here.
http://codepen.io/mhartington/pen/jbweOJ


Update confusing feedback for iframe lecture video

Here is the feedback you receive when you get the first question wrong

This hint seems really wordy and confusing to me.
It would be better to just direct to the rewatch the beginning of the video
### --feedback--

Review the first 15 seconds of the video where this was discussed.

Make sure to update this feedback in all areas it occurs.
Here is the file you need to update:
https://github.com/freeCodeCamp/freeCodeCamp/blob/main/curriculum/challenges/english/25-front-end-development/lecture-working-with-media/671682b3983489a819507553.md

This has been opened for contribution. The first comprehensive PR created will be reviewed and merged. We typically do not assign issues to anyone other than long-time contributors.
If you would like to contribute and have not read the contributors docs, please do so here: https://contribute.freecodecamp.org/#/
If you have any issues with contributing, be sure to join us on the contributors channel, or on the contributors sub-forum
Happy coding


Add Amy synth to picotracker

Amy looks to be a great synth library project which already has support for rp2040 including managing multitimbral FM synth (fixed point) playback with tools that can convert existing DX-7 patches into its own programmatic patch format.
Quick testing with Amy's (as of commit 54062a91c4d2797c5f72a6d3e7cf85826cdfecbc in Amy repo) the src/amy-example-rp2040.c works on picotracker hardware with just adjustment for picotrackers i2s pins in its CMakeList.txt.
Next step for this is to port amy into picotracker though that should not be too hard give amy's existing support for building with the pico sdk and cmake in the above example code.

After extensive work by @democloid Amy has not proven amenable to being used in picoTracker.


Publisher type should be set to institution as default

This would simplify and maybe reduce some confusion. Publisher type is not required in MMD but may be useful in ACDD mostly to help the data producers.

No point in doing this. We don't use publisher_type in MMD. The data management handbook has been updated with an example telling users to set :publisher_type = "institution" ;.


[BuilderTransform] Extract all builder related operations into ResultBuilder type

This is a very first step towards transforming result builder handling into an AST transformation.
Makes it possible to share common functionality between existing and new transforms and cache
the information about the builder if needed.
The list of operations:

supports(...)
buildCall(...)
buildVar(...)
buildVarRef(...)

@swift-ci please test

@swift-ci please test macOS platform

@swift-ci please smoke test


Create expand() function

expand() is not a regular function in OrientDB SQL, but a special behavior. However the very same function is needed when you need to expand a RID to a ODocument.

Change mind, the toJSON() resolves the problem.


operator ibm-block-csi-operator-community (1.11.2)

Thanks for submitting your Operator. Please check the below list before you create your Pull Request.
New Submissions

[x] Are you familiar with our contribution guidelines?
[x] Are you familiar with our operator pipeline?

[x] Have you considered whether you want to use semantic versioning order?
[x] Is your submission signed?
[x] Is operator icon set?

Your submission should not

[x] Add more than one operator bundle per PR
[x] Modify any operator
[x] Rename an operator
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description of the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/lgtm

/lgtm

this is failing for an unclear reason, and also not allowing to mark LGTM flag
opened issue 4543

@jfrancin please note that @ArbelNathan already attempted to mark with /lgtm flag last week
https://github.com/redhat-openshift-ecosystem/community-operators-prod/pull/4542#issuecomment-2112051959

1.11.1 does indeed exist. But only in the v4.13 bundle index. It doesn't exist in the OperatorHubs for RHOCP 4.14 and 4.15.
The 1.11.1 version's annotations.yaml file contains: com.redhat.openshift.versions="v4.10-v4.13".
The 1.11.2 version's annotations.yaml file contains: com.redhat.openshift.versions="v4.13-v4.15".
Since the 1.11.1, the version being replaced, does not exist in 4.14 or 4.15, the replaces directive cannot be satisfied, as the precursor version must exist in every version's operatorHub/bundle index.  You cannot use replaces in an operator bundle which supports a wider range of versions than the one being replaced.
Instead, change the replaces: ibm-block-csi-operator.v1.11.1 to: a skips block:
spec:
  [...]
  version: 1.11.2
  skips:
     - ibm-block-csi-operator.v1.11.1
  [...]


hypercore and Yjs : how to make them work together, without worsening performance over time?

Being hypercore feeds append-only logs,  if we write every single CRDT update to an hypercore feed, this feed will grow in size too quickly, degradating the performance over time.
So, as described in my questions in this discussion: https://github.com/hypercore-protocol/hyperdrive/issues/230#issuecomment-922440438 I would like to understand  the compatibility between hypercore and CRDT implementation, like Yjs.
According to what I read here :  https://www.kn8.lt/blog/building-privacy-focused-collaborative-software/
" the y-dat implementation does not actually use the core feature of the hypercore’s append only merkle tree signed log, due to the mutable nature of the Yjs CRDT implementation.
This removes the key benefits of hypercore: the ability to sync changes asynchronously and providing redundancy by resharing feeds of other collaborators.
Yjs has a separate mechanism for computing deltas between peer states, which can be used to efficiently sync with peers upon reconnection, but that’s a distinctly different approach from hypercore"
Thus I also would like to know if y-dat is the only viable way to use Yjs with hypercore, and if there are alternative ways to make them work together.

Join the discord, https://chat.hypercore-protocol.org - easier to discuss there


Crash problem

crash-2020-11-20_15.21.50-client.txt
Mod Version:
The version that is installed in your pack.
DynamicSurroundings-1.12.2-<IP_ADDRESS>
Forge Version:
The actual Forge version - "latest" does not count.
Link to client log:
Even of there is a crash log, the client log can provide the necessary context for why the exception occured.  You can use a service like pastebin or hastebin to upload the log, and paste the link here.  The log file is called latest.txt and can be found in your logs folder.
Link to crash log:
The callstacks in the log will help pinpoint the actors involved in the crash and give a developer a pointer in the code where to start looking at the problem.  You can use a service like pastebin or hastebin to upload the log, and paste the link here.
Description:
Description of the problem.  In the case of crashes, it is good to know things like the following:

Did you just add the mod to a pack? yes i did
Did it just start crashing, or has it always crashed? started to crash
Did you update any other mods in your pack and it started crashing?  This includes Forge. no, i updated this mod and started to crash
If updating multiple mods did you update one by one or all at once?  To help narrow the problem down adding one by one is helpful. onli this
Is the modpack you are using available online somewhere? no i crated  If the crash is due to mod interaction having the pack available makes things much easier.  It is much harder to work these types of issues with a private kitchen sink pack containing 250 mods.

Not sure why this issue is posted here.  Dynamic Surroundings does not appear to be installed.


[Bug] apply was renamed to .map_elements()

"In Polars, the apply method has been renamed to .map_elements(). Therefore, the .apply() method on line 95 of feature_processor.py needs to be updated. Otherwise, an AttributeError: 'Expr' object has no attribute 'apply' will occur."
Reference: https://stackoverflow.com/questions/78753820/using-polars-with-python-and-being-thrown-the-following-exception-attributeerro

which version of polars do you use?

To backward support python 3.6, 3.7, 3.8, we currently only support polars <= 1.0.0.


Add support for virtual network id in origin

Description
Add support to virtual_network_id listed in CloudFlare API doc here: https://developers.cloudflare.com/api/operations/account-load-balancer-pools-create-pool as the current golang client does not support this field.

Has your change been tested?
Yes, confirmed test passed and existing functionality not affected

Screenshots (if appropriate):
Types of changes
What sort of change does your code introduce/modify?

[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[x] All new and existing tests passed.
[ ] This change is using publicly documented in cloudflare/api-schemas
and relies on stable APIs.

@jacobbednarz looks like the unit test and coverage test was failing, just wondering if I am missing anything? Thanks!

@jacobbednarz Updated the variable name, please take a look and merge if possible, thanks a lot!


Remove unused argument from applications_page_check

Addressing an issue from August 2014 here!!
Description
Remove unused argument current_page from applications_page_check

#3378

Checklist

[x] I have opened this pull request against develop
[ ] I have updated the CHANGELOG.rst
[ ] I have added or modified the tests when changing logic
[x] I have read the contribution guidelines  and I have joined #workgroup-pr-review on Slack to find a “pr review buddy” who is going to review my pull request.

Signature changing always scary me. Using PyCharm I found 26 usages without any attemptions to use current_page argument. All checks passed. This change will not broke any. But I think we need somebody with expert level with django cms

Signature changing always scary me. Using PyCharm I found 26 usages without any attemptions to use current_page argument. All checks passed. This change will not broke any. But I think we need somebody with expert level with django cms

The issue this fixes was agreed by the core team in 2014 at which point it was assumed to be an argument leftover from some old functionality. So I've actioned it on the grounds it had been accepted by the people that know this system the best.

Hi @vinitkumar,
may you merge it?
Thanks,
greengoaxe

@greengoaxe Yes, I will merge it once the test passes.


Add a field in the tigerdata metadata for the project id

Acceptance criteria

[ ] Add a project_id field to the project_schema_fields: https://github.com/pulibrary/tiger-data-app/blob/main/app/models/tigerdata_schema.rb#L39C5-L39C143
[ ] Modify this script and ask Robert Knight to add it to td-meta1
[ ] Change the class that sends the XML to mediaflux (app/models/project_mediaflux#project_values)

Hey team! Please add your planning poker estimate with Zenhub @carolyncole @hectorcorrea @JaymeeH @leefaisonr


Add test for 568

Summary
Add a test for the use case described in #568, since our existing tests didn't catch that.
Details and comments
Fixes #

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at ?%

Totals

Change from base Build<PHONE_NUMBER>:
0%

Covered Lines:

Relevant Lines:
0

💛  - Coveralls