text:
Shift the GitHub action to CLI repository

Why do we need this improvement?
Currently the versions, releases and other stuff are isolated from CLI which is directly coupled with this CLI. However, this creates problems in bumping of versions and keeping code updated as well.
Furthermore, any change in CLI spec could be easily made here as well.
How will this change help?
This will help in automation of releases of CLI and tie them together properly.
How could it be implemented/designed?
This issue can be resolved through the following steps:-

Transfer the source code of this action in a github-action folder.
Put the test workflow in its proper place in .github directory.
Tie the version at these steps:
https://github.com/asyncapi/github-action-for-cli/blob/590180ca0d91785af367276558b2b60d86f7d1e2/entrypoint.sh#L29
https://github.com/asyncapi/github-action-for-cli/blob/590180ca0d91785af367276558b2b60d86f7d1e2/Dockerfile#L13
Add automation for release of new version of action with bump in CLI version.
Put action.yml in root folder.

Additional steps:

Instead of installing the asyncapi cli, dockerise the code from parent directory itself.

[!IMPORTANT]
The action and bump of version would need to be tested in your personal repo or account. From my past experience would suggest using an alternate account itself.

🚧 Breaking changes
Yes

bounty/candidate

@Shurtu-gal I wish to work on this issue. Basically, want to try something new, apart from website 😅

@Shurtu-gal I wish to work on this issue. Basically, want to try something new, apart from website 😅

Great, however would need to wait for it to be accepted before assigning.

Bounty Issue's service comment
Text labels: bounty/2024-Q3, bounty/medium, bounty/coding
First assignment to third-party contributors: 2024-06-21 00:00:00 UTC+12:00
End Of Life after: 2024-07-31 23:59:59 UTC-12:00
@asyncapi/bounty_team
The Bounty Program is not a Mentorship Program. The accepted level of Bounty Program Participants is Middle/Senior.
Third-party contributors should coherently articulate how they are going to approach the resolution process when expressing a desire to work on this Bounty Issue.

@asyncapi/bounty_team as per the rules with maintainers having more preference, I have assigned @akshatnema the issue.

Thanks @Shurtu-gal 😄 👍

Bounty Issue's Timeline

Complexity Level
Assignment Date (by GitHub)
Start Date (by BP Rules)
End Date (by BP Rules)
Draft PR Submission
Final PR Merge Start
Final PR Merge End

Medium
2024-06-17
2024-07-01
2024-08-11
2024-07-14
2024-07-28
2024-08-11

Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.
Keep in mind the responsibility for violations of the Timeline.

Hey @aeworxet,
Can you please extend the deadline of bounty issue by 2 weeks, as I caught Dengue in the previous week?

Upon request of the Bounty Program Participant (@akshatnema), all remaining target dates of the Bounty Issue's Timeline are extended by two calendar weeks.
Bounty Issue's Timeline Extended

Complexity Level
Assignment Date (by GitHub)
Start Date (by BP Rules)
End Date (by BP Rules)
Draft PR Submission
Final PR Merge Start
Final PR Merge End

Medium
2024-06-17
2024-07-01
2024-08-25
2024-07-28
2024-08-11
2024-08-25

Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.
Keep in mind the responsibility for violations of the Timeline.

Thanks @aeworxet

@akshatnema do you need any help on this ?

@akshatnema, please provide an update to the PR.

@akshatnema, please provide an update to the PR.

@akshatnema had scheduled a call with @derberg on 2024-08-27 to clarify some final details on this Bounty Issue before merging https://github.com/asyncapi/cli/pull/1487.

Response, critical for technical resolution of this Bounty Issue (clarification on implementation) was delayed for one period of three consecutive working days
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2307699278
so all remaining target dates of the Bounty Issue's Timeline are extended by two calendar weeks.
Bounty Issue's Timeline Extended

Complexity Level
Assignment Date (by GitHub)
Start Date (by BP Rules)
End Date (by BP Rules)
Draft PR Submission
Final PR Merge Start
Final PR Merge End

Medium
2024-06-17
2024-07-01
2024-09-08
2024-07-28
2024-08-25
2024-09-08

Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.
Keep in mind the responsibility for violations of the Timeline.

Hey @aeworxet ,
after discussion this with @Shurtu-gal and Lukasz, I find that this may get delayed for the completion. Can you please extend the bounty deadlines by 2 weeks?

Upon request of the Bounty Program Participant (@akshatnema), all remaining target dates of the Bounty Issue's Timeline are extended by two calendar weeks.
Bounty Issue's Timeline Extended

Complexity Level
Assignment Date (by GitHub)
Start Date (by BP Rules)
End Date (by BP Rules)
Draft PR Submission
Final PR Merge Start
Final PR Merge End

Medium
2024-06-17
2024-07-01
2024-09-22
2024-07-28
2024-08-11
2024-09-22

Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.
Keep in mind the responsibility for violations of the Timeline.

@akshatnema, please provide an update to the PR.

There is no update as I'm researching around the fact on how to manage GitHub Action for CLI.
@Shurtu-gal and @derberg proposals require different configurations, which in fact means we need to have the same package.json for both CLI and it's respective GitHub action.
I'm currently looking at how to use only one configuration and one package.json.
Although the matter looks simple, it will take time to try different approaches, so if I don't achieve a break-through in the nearest couple of days, I'll ask for the Timeline Extension.

https://github.com/asyncapi/cli/pull/1487#issuecomment-2353301910

The latest conversation with @akshatnema took place on Friday 2024-09-20 in Slack, where he stated that the solution to this Bounty Issue will be merged later because it requires thorough testing, as it is a complete repo being moved into an existing one, and then became unresponsive.
Reasons for sudden silence after a lively conversation can be numerous, so I'm waiting for the clarification on this matter before taking any action.

Hey @aeworxet Sorry for the late reply.
The solution requires thorough testing, as this is a complete repo being moved into an existing one, so I need an extension by 2 weeks. But most probably, I will do everything on this weekend.

Upon request of the Bounty Program Participant (@akshatnema), all remaining target dates of the Bounty Issue's Timeline are extended by two calendar weeks.
Bounty Issue's Timeline Extended

Complexity Level
Assignment Date (by GitHub)
Start Date (by BP Rules)
End Date (by BP Rules)
Draft PR Submission
Final PR Merge Start
Final PR Merge End

Medium
2024-06-17
2024-07-01
2024-10-06
2024-07-28
2024-09-22
2024-10-06

Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.
Keep in mind the responsibility for violations of the Timeline.

@aeworxet the versions automation task will be done in another PR.

@aeworxet this issue is pretty complicated as some things related to containerizing part is still not working and we still have to do the automation of version locking and bumping. @akshatnema is also pretty new to the CLI repo so is it possible to reclassify this bounty as advanced and extend it for 1-2 weeks.
P.S: Original Source: https://github.com/asyncapi/cli/pull/1487#issuecomment-2395396217

Upon request of the AsyncAPI Maintainer (@Shurtu-gal, githubID 100484401), the Complexity Level of this Bounty Issue was reclassified to Advanced (upgraded), and all remaining target dates of its Timeline were extended by two calendar weeks.
Bounty Issue was Reclassified and its Timeline Extended

Complexity Level
Assignment Date (by GitHub)
Start Date (by BP Rules)
End Date (by BP Rules)
Draft PR Submission
Final PR Merge Start
Final PR Merge End

Advanced
2024-06-17
2024-07-01
2024-10-20
2024-07-28
2024-09-22
2024-10-20

Please note that the dates given represent deadlines, not specific dates, so if the goal is reached sooner, it's better.
Keep in mind the responsibility for violations of the Timeline.

Implementation of https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2395440596

the versions automation task

is the PR
https://github.com/asyncapi/cli/pull/1543

Timeline for this Bounty Issue has run out. Knowing it is quite complex, and taking into account that both @akshatnema and @Shurtu-gal have remained responsive during its resolution, I must first ask what should be done with it moving forward? Is more time needed to complete it, is it in the final stages, or is there something else?

Timeline for this Bounty Issue has run out. Knowing it is quite complex, and taking into account that both @akshatnema and @Shurtu-gal have remained responsive during its resolution, I must first ask what should be done with it moving forward? Is more time needed to complete it, is it in the final stages, or is there something else?

It's in the final stages, just need to get the automation in place.

This bounty is still in progress. We have been discussing possible solutions and have come with two plausible ones:-

Using docker image directly to forego the github relase overhead.
Using changeset to bump action.yml before release

cc: @aeworxet

@aeworxet @akshatnema is exploring the above mentioned solutions and would be giving any updates he finds out here.

This Bounty Issue is still in progress and is encountering many restrictions and limitations related to GitHub Actions, AsyncAPI infrastructure, and the release process.

I tried to create release workflow using changeset here - https://github.com/akshatnema/cli/actions/runs/11999463258/job/33447396874. Currently debugging in it to create a changeset in the fork repo, and test the workflow.

Update: this weekend we got the the changeset workflow to work regarding bump so it seems promising enough to fulfill all the requirements. The PR for mentioned workflow will be coming soon.

The PR for said workflow has been created and merged. The changeset is not yet working as intended and @akshatnema is trying to debug it.

@aeworxet this bounty has been completed.

After a set of delays that were beyond the control of the Bounty Program Participant
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2426794619
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2461485869
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2468117918
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2490006384
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2497032782
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2513539523
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2537558011
https://github.com/asyncapi/github-action-for-cli/issues/396#issuecomment-2542902617
Bounty Issue Is Completed 🎉
@akshatnema (githubID 76521428), please go to the AsyncAPI page on Open Collective and submit an invoice for USD 400.00 with the expense title Bounty github-action-for-cli#396, tag bounty, and full URL of this Bounty Issue in the description.

repo: asyncapi/github-action-for-cli


text:
[BUG] layout of tree in specification explorer doesnt reorganize on collapsing

Describe the bug.
see the blank space between components and operations
whenever you expand and collapse a node in the tree the blank space is retained by the node even though it is not expanded.

Expected behavior
when i collapse a node A and then expand another node B
node A should not have extra blank space as its children are hidden
Screenshots
added
How to Reproduce

go to https://www.asyncapi.com/docs/reference/specification/v3.0.0-explorer
expand components
collapse components
expand channels
see the blank space

🥦 Browser
Mozilla Firefox
👀 Have you checked for similar open issues?

[X] I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

[X] I have read the Contributing Guidelines

Are you willing to work on this issue ?
Yes I am willing to submit a PR!

@catosaurusrex2003 could you please provide few files which might have the logic of rendering this tree

@hkv24  I'm not quite sure what you mean by 'files.' Could you clarify that for me?
I was just exploring the asyncapi spec https://www.asyncapi.com/docs/reference/specification/v3.0.0-explorer when i encountered this

@catosaurusrex2003 I meant the file from the codebase. Anyway did you figured out something to solve this one?

I haven't started working on this issue yet and was hoping to see if others encounter it first to confirm it's a legitimate concern. But if you’d like to solve it, feel free to go ahead!

@catosaurusrex2003 I see that the issue still persists, can you mention the name of the file where the actually logic of this issue lies ?

@JeelRajodiya thanks 👌
I was just about to comment on that too 😆
I will be opening a PR in https://github.com/AceTheCreator/schyma soon

hey is this issue still open,i wanted to give it a try?

@BiradarScripts
The issue has already been fixed.

source: gharchive/issue

repo: asyncapi/website

license_type: permissive

license_source: github-api


text:
new fragment for contributor questions section

Description

Fixes #1555

Related issue(s)

@alequetzalli I think it is docs related

@golu-99 any updates???

@alequetzalli we need your approval here

@sambhavgupta0705 I think it's fine to close this as the issue got resolved, adding on, it got negative feedback from Alejandra here

Correct, this PR is full of mistakes.
Closing.

source: gharchive/pull-request


text:
Gnome 40 Support

Hello. Fedora 34 user here. Any chance of updating this for Gnome 40?

Working on it....

Fixed for GNOME 40 on tag https://github.com/atareao/wireguard-indicator/releases/tag/v6

Ty for your excellent work!

authors: JKomoroski atareao

repo: atareao/wireguard-indicator

license: MIT


text:
🛑 Wedding HTTPS is down

In a900cab, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 6676c4f.

repo: atatkin/milos-uptime


text:
🛑 Wedding HTTPS is down

In 7f945a4, Wedding HTTPS ($WEDDINGHTTPS) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wedding HTTPS is back up in 22035ca.


text:
First pass at Circle 2

This pull request attempts to use Circle CI 2.0 to create an auto-update script that is scalable with the ability to handle multiple site updates in parallel. The previous version, running on Circle CI 1, wasn't scalable and needed a new project created for each site being updated.
Summary of updates:

Adds support for Circle CI 2
Uses multiple jobs for different steps, e.g. checking for updates and running visual regression tests
Makes use of a custom Node or PHP Docker container depending on the job needs
Has a starting job that runs on cron, checking for all sites in an org with a specific tag to update
Fires off an update job for each site via the Circle CI API
Subsequent steps, such as visual regression testing are also triggered via API and only run when needed
Dynamically crawls URLs for each site with backstop-crawlhttps://github.com/fffunction/backstop-crawl/ rather than having a hard-coded list of URLs
Extremely scalable, depending on the parallelism you have in Circle CI builds
Native cron support! No more pinging the Circle CI API manually to the update script

Know issues:

Backups taking too long timeout on Circle CI
backstop-crawl not crawling all site URLs
backstop-crawl taking too long when many URLs


text:
[Datamapper] Adding property with existing name seems allowed but nothing happens

From @apupier on July 27, 2017 13:42

create property with Name "mydata", click on Save
try to create another property "mydata",
--> Save is still enabled
--> when clicking Save, nothing happens

it is also the case when using a different case, for instance "myData"
Copied from original issue: syndesisio/syndesis-ui#682

From @akieling on September 19, 2017 14:29
@rhuss do you know the validation rules we need to run when adding properties in the data mapper?

From @rhuss on September 20, 2017 19:52
@akieling sorry, no idea. But @igarashitm is on it I guess ...

create property dialog should check the existing property tables and if it already exists show an alert and disable save button

authors: gashcrumb igarashitm

repo: atlasmap/atlasmap-ui


text:
fix: yarn build fails without prior maven build

Fixes: #3938
Just check those file in so we can detect if there's format change.

Had to get the phase hook off as the property order is not fixed

repo: atlasmap/atlasmap


text:
thread 'main' panicked at 'called Result::unwrap()

Hi
FSRT crashes when scanning the application source.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { error: (Span { lo: BytePos(2651), hi: BytePos(2652), ctxt: #0 }, Unexpected { got: "@", expected: "identifier, string literal, numeric literal or [ for the computed key" }) }', crates/fsrt/src/main.rs:112:18
stack backtrace:
   0:        0x102736714 - std::backtrace_rs::backtrace::libunwind::trace::hbe97f4303076f99a
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:        0x102736714 - std::backtrace_rs::backtrace::trace_unsynchronized::hb462a91ac605b16b
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:        0x102736714 - std::sys_common::backtrace::_print_fmt::h555c176cf2344151
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:65:5
   3:        0x102736714 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he84d5e26d26c914d
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:44:22
   4:        0x10274f638 - core::fmt::write::h07c7e4739f78f3b0
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/fmt/mod.rs:1209:17
   5:        0x102733894 - std::io::Write::write_fmt::h4a3c5f094ffc65e8
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/io/mod.rs:1682:15
   6:        0x102736528 - std::sys_common::backtrace::_print::h03a1c9ac6001091a
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:47:5
   7:        0x102736528 - std::sys_common::backtrace::print::h6fc2cc8be2392a8e
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:34:9
   8:        0x102737b7c - std::panicking::default_hook::{{closure}}::h3bb44ba6ff437e23
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:267:22
   9:        0x1027378d4 - std::panicking::default_hook::h92c6668a1a98ae8c
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:286:9
  10:        0x1027381b8 - std::panicking::rust_panic_with_hook::h9b8acc949e1fb807
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:688:13
  11:        0x102737fc8 - std::panicking::begin_panic_handler::{{closure}}::hfc38b2cc56e3623c
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:579:13
  12:        0x102736b7c - std::sys_common::backtrace::__rust_end_short_backtrace::hbafd151207fc448f
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/sys_common/backtrace.rs:137:18
  13:        0x102737d1c - rust_begin_unwind
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:575:5
  14:        0x10276c57c - core::panicking::panic_fmt::h8c7f3d540a75578f
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:65:14
  15:        0x10276c764 - core::result::unwrap_failed::h666d2c7e0d130ea0
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/result.rs:1791:5
  16:        0x10247d964 - scoped_tls::ScopedKey<T>::set::h22e16881a898f189
  17:        0x10247b874 - fsrt::scan_directory::h327990d6f05f4066
  18:        0x102478178 - fsrt::main::h7e5999c60bcd1235
  19:        0x1024a7bc8 - std::sys_common::backtrace::__rust_begin_short_backtrace::h6cdbbfae25a6e331
  20:        0x1024711c0 - std::rt::lang_start::{{closure}}::hfebf8c7afa473ce9
  21:        0x10272f6f0 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::ha4b10a239e2af884
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/ops/function.rs:286:13
  22:        0x10272f6f0 - std::panicking::try::do_call::h6b4bcb7d3635e86a
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40
  23:        0x10272f6f0 - std::panicking::try::h579c8cca81ff0f69
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19
  24:        0x10272f6f0 - std::panic::catch_unwind::h4a997c12755a6e33
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14
  25:        0x10272f6f0 - std::rt::lang_start_internal::{{closure}}::hf20057b44f57f87c
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:48
  26:        0x10272f6f0 - std::panicking::try::do_call::hdfca34da16d8863f
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:483:40
  27:        0x10272f6f0 - std::panicking::try::h4f4022e500de0807
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:447:19
  28:        0x10272f6f0 - std::panic::catch_unwind::h62721286166676e8
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panic.rs:137:14
  29:        0x10272f6f0 - std::rt::lang_start_internal::h659a783147314d97
                               at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/rt.rs:148:20
  30:        0x10247d3f0 - _main

FSRT and cargo versions:
fsrt 0.1.0
cargo 1.66.0 (d65d197ad 2022-11-15)

App ID
3ee42c72-975c-4ada-b418-b656f45c6b04

Ah, swc ignores decorators by default, so we're erroring during parsing. Should be a simple fix.

repo: atlassian-labs/FSRT


text:
Automatic Sync

My issues are not updating with the commits that I made. I don't believe the Smart Sync worked...any idea as to why this could be happening?

Hi @Manpreet-Bhatti , please check #834 . We are currently experiencing the incident; I'll post an update once we resolve it. Sorry for the inconvenience.

authors: Manpreet-Bhatti bgvozdev

repo: atlassian/github-for-jira


text:
Issue building atom on Windows

Prerequisites

[X] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
In attempting to build Atom from source on Windows 10, I am presented with an issue that a "path, file name, or both are too long".
Steps to Reproduce

Checkout latest commit (currently 1fc23c3)
script/build --create-windows-installer --compress-artifacts

Expected behavior: Atom builds, providing installer
Actual behavior: Build fails during creation of installer
Reproduces how often: 100%
Versions
OS: Windows 10 Pro x64
Node: v6.10.2
NPM: v3.10.10
Python: 2.7.12
Also, I am using Visual C++ Build Tools 2015.
Additional Information
My repo is checked out to c:\atom to get the path as short as possible. I have run npm dedupe on my node_modules in both the repo base and the 'out' directories at different points to attempt to get rid of this error - I am using NPMv3 so I believe this is not needed anyway.
Here is a snippet of the build output with debugging:
Verifying if snapshot can be executed via `mksnapshot`
Generating startup blob at "C:\atom\out\snapshot_blob.bin"
Moving generated startup blob into "C:\atom\out\Atom x64\snapshot_blob.bin"
Skipping code-signing. Specify the --code-sign option and provide a ATOM_WIN_CODE_SIGNING_CERT_DOWNLOAD_URL environment variable to perform code-signing
Creating Windows Installer for C:\atom\out\Atom x64
Thu, 20 Apr 2017 03:04:54 GMT electron-windows-installer:spawn Spawning C:\atom\script\node_modules\electron-winstaller\vendor\rcedit.exe C:\atom\out\Atom x64\Update.exe --set-icon C:\atom\resources\app-icons\dev\atom.ico
Thu, 20 Apr 2017 03:04:54 GMT electron-windows-installer:fs-utils Error: ENOENT: no such file or directory, stat 'C:\atom\out\Atom x64\resources\app.asar'
  at Error (native)
Thu, 20 Apr 2017 03:04:54 GMT electron-windows-installer:main Created NuSpec file:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
  <metadata>
    <id>atom</id>
    <title>Atom</title>
    <version>1.18.0-dev-41f0d5825</version>
    <authors>GitHub Inc.</authors>
    <owners>GitHub Inc.</owners>
    <iconUrl>https://raw.githubusercontent.com/atom/atom/master/resources/app-icons/dev/atom.ico</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>A hackable text editor for the 21st Century.</description>
    <copyright>Copyright © 2017 GitHub Inc.</copyright>
  </metadata>
  <files>
    <file src="locales\**" target="lib\net45\locales" />
    <file src="resources\**" target="lib\net45\resources" />
    <file src="*.bin" target="lib\net45" />
    <file src="*.dll" target="lib\net45" />
    <file src="*.pak" target="lib\net45" />
    <file src="Update.exe" target="lib\net45\squirrel.exe" />
    <file src="icudtl.dat" target="lib\net45\icudtl.dat" />
    <file src="LICENSE" target="lib\net45\LICENSE" />
    <file src="atom.exe" target="lib\net45\atom.exe" />
  </files>
</package>
Thu, 20 Apr 2017 03:04:54 GMT electron-windows-installer:spawn Spawning C:\atom\script\node_modules\electron-winstaller\vendor\nuget.exe pack C:\Users\SHANE~1.AEO\AppData\Local\Temp\si-117320-944-68ih1h.cxazcl3di\atom.nuspec -BasePath C:\atom\out\Atom x64 -OutputDirectory C:\Users\SHANE~1.AEO\AppData\Local\Temp\si-117320-944-68ih1h.cxazcl3di -NoDefaultExcludes
Thu, 20 Apr 2017 03:18:49 GMT electron-windows-installer:main Attempting to build package from 'atom.nuspec'.
Successfully created package 'C:\Users\SHANE~1.AEO\AppData\Local\Temp\si-117320-944-68ih1h.cxazcl3di\atom.1.18.0-dev-41f0d5825.nupkg'.

Thu, 20 Apr 2017 03:18:49 GMT electron-windows-installer:spawn Spawning C:\atom\script\node_modules\electron-winstaller\vendor\SyncReleases.exe -u https://atom.io/api/updates-x64?version=1.18.0-dev-41f0d5825 -r C:\atom\out
Thu, 20 Apr 2017 03:19:47 GMT electron-windows-installer:main Attempting to sync URL as remote RELEASES folder
Trying to download RELEASES index from https://atom.io/api/updates-x64/RELEASES?version=1.18.0-dev-41f0d5825
Downloading release from https://atom.io/api/updates-x64/atom-1.16.0-full.nupkg

Thu, 20 Apr 2017 03:19:47 GMT electron-windows-installer:spawn Spawning C:\atom\script\node_modules\electron-winstaller\vendor\Update.com --releasify C:\Users\SHANE~1.AEO\AppData\Local\Temp\si-117320-944-68ih1h.cxazcl3di\atom.1.18.0-dev-41f0d5825.nupkg --releaseDir C:\atom\out --loadingGif C:\atom\resources\win\loading.gif --setupIcon C:\atom\resources\app-icons\dev\atom.ico
Deleting downloaded nupkg for previous version at C:/atom/out/atom-1.16.0-full.nupkg to prevent it from being stored as an artifact
Error: Failed with exit code: 4294967295
Output:
System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
   at System.IO.PathHelper.GetFullPathName()
   at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths)
   at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength)
   at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
   at Squirrel.DeltaPackageBuilder.createDeltaForSingleFile(FileInfo targetFile, DirectoryInfo workingDirectory, Dictionary`2 baseFileListing)
   at Squirrel.DeltaPackageBuilder.CreateDeltaPackage(ReleasePackage basePackage, ReleasePackage newPackage, String outputFile)
   at Squirrel.Update.Program.Releasify(String package, String targetDir, String packagesDir, String bootstrapperExe, String backgroundGif, String signingOpts, String baseUrl, String setupIcon, Boolean generateMsi)
   at Squirrel.Update.Program.executeCommandLine(String[] args)
   at Squirrel.Update.Program.main(String[] args)
   at Squirrel.Update.Program.Main(String[] args)

  at ChildProcess.proc.on.code (C:\atom\script\node_modules\electron-winstaller\lib\spawn-promise.js:62:16)
  at emitTwo (events.js:106:13)
  at ChildProcess.emit (events.js:191:7)
  at maybeClose (internal/child_process.js:886:16)
  at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)

Hmm, can you try creating a c:\temp folder and putting typing SET TEMP=c:\temp in your command prompt before issuing the build command?  (This won't change temp for your machine just for that command window while it is open)

Unfortunately that doesn't seem to change anything

Hmm, not sure what else to suggest. If you just want to build atom you don't normally need to use --create-installer - it's used to create the .exe and .msi setup systems and can take some time as well.  the -compress-artifacts flag will give you a zip you can use if that helps.

No, I actually want an installer - or at least I want to invoke the squirrel installer to test some registry additions.
Sent from BlueMail
On 21 Apr 2017, 11:29 AM, at 11:29 AM, Damien Guard notifications@github.com wrote:

Hmm, not sure what else to suggest. If you just want to build atom you
don't normally need to use --create-installer - it's used to create the
.exe and .msi setup systems and can take some time as well.  the
-compress-artifacts flag will give you a zip you can use if that helps.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/atom/atom/issues/14264#issuecomment-296040156

Was the output exactly the same when you set TEMP?  The locations of the files should have been different.

Maybe some of the paths may have changed, but it ultimately resulted in the same error in the same place.

https://github.com/Squirrel/Squirrel.Windows/blob/master/src/Squirrel/DeltaPackage.cs#L148 is the point where things went awry in squirrel - this function is mostly performing operations creating temporary files using your temp folder.
Your temp folder is longer than the one I personally use to build Windows and longer than the one we use on the build server both of which are working fine right now.  It might be worth creating a c:\temp and setting TMP and TEMP to that from your system settings (then re-open the command window to take effect)

No further response.

Found something else you can try if you're still stuck;
MKDIR C:\squirreltemp
SET SQUIRREL_TEMP=C:\squirreltemp

Might get you past it - we just ran into a length issue on our build server and this helped.

Hi @damieng i was facing with same problem and overriding SQUIRREL_TEMP variables solves the issue thk for your suggest!!

Hi @damieng
Sorry, it's obviously been quite a while since I last looked at this. However, setting that environmental variable has done the trick and I have now managed to compile a Windows installer.
Now, I am attempting to run the install, and it failed until I set SQUIRREL_TEMP as an environmental variable for my user account. This can't be right? Is there something else you guys are doing to get around this?
Thanks

Our installers don't typically have this problem however if your temp path is long it might be necessary (the default is within your user folder so longer user names can cause this)

I don't think my user folder is all that long, and my username is only five characters. I guess it must be due to the dev build having a long name. I've figured out a workaround for now.
Thanks

What do you mean 'dev build' having a long name? Is the workaround to set SQUIRREL_TEMP?

authors: damieng muten84 shanept

repo: atom/atom


text:
Atom should warn user if file changed on disk if file is unsaved on Atom and has been modify else where

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Atom should warn user if file changed on disk if file is unsaved on Atom and has been modify else where
Steps to Reproduce

Open a file on atom and make some changes (e.g add a space somewhere)
Open the same file on vim, make some changes to the file and save.
Go back to atom and save the file

Expected behavior: [What you expect to happen]
Atom should warn the user that the file on disk has been modify since it was last loaded.
Actual behavior: [What actually happens]
Atom doesn't show or do anything.
Reproduces how often: [What percentage of the time does it reproduce?]
100%
Versions
You can get this information from copy and pasting the output of atom --version and apm --version from the command line. Also, please include the OS and what version of the OS you're running.
Atom    : 1.19.0-dev-d289ca447
Electron: 1.6.9
Chrome  : 56.0.2924.87
Node    : 7.4.0
Additional Information
subl warns the user:

Vim does too:

VS Code:

Any additional information, configuration or data that might be necessary to reproduce the issue.
/cc @iolsen @maxbrunsfeld

A closely related point:

edit in Atom a file F in a directory X
move X elsewhere (mv on unix-like systems)
save file F from Atom
ouch:
file is silently re-created in X (no warning)
directory X is created by Atom !

This is specially annoying when editing remotely shared files (eg NFS): if the volume is not mounted, Atom create the mounting point directory (empty, et /Volumes/X on MacOS) and fails. This empty directory stay in the way and prevent mounting the server's volume.

authors: emmanuelito ungb


text:
Uncaught (in promise) Error: EOVERFLOW, Unknown error

Prerequisites

[X ] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
I want to be clear I have not been able to reproduce after I solved the problem. Been trying for 2 days now. But was such a strange problem and behavior I felt i should report it.
I closed atom 2 nights ago and when I reopened it the following morning. No tabs were showing. It was just the menu. Not git browser, project tree, ect. just about everything in the menus didn't respond.  The program wasn't locked up as I could open and close the menus, but it wouldn't open the settings, packages, or even reopen my project. This is what it looked like: https://prnt.sc/g6s8yo
So I started working through the debug steps. I check to ensure i was on the latest version (1.19).
I then closed it out and reopened it in safe mode. The problem was still there. I then closed it and cleared the save state and reopened it normal mode and cleared the saved state and reopened in safe mode. The problem was still there. I then closed it and moved the .atom folder. repeating again opening in normal and safe mode. Problem continued. I checked for links and there were none. I had to skip the "Check Atom and Package Settings" because I was unable to open the settings or packages sections inside of atom.
I restored my original .atom folder again to check for font rendering issues. I noticed a error count in the developer window. So when I switch to the console. I saw:
Uncaught (in promise) Error: EOVERFLOW, Unknown error
C:\wamp64\www\influxproject\html\application\helpers\myform_helper.php
Curious i closed Atom and reset to factory again and cleared saved state. When I open it back up and reopened the developer console. again I saw the same error. It made no since that point as to how and why it knew about that file after clearing the save state and restoring to factory default. I opened the file up in Notepad++ and turned on all symbols. I skimmed through the file looking for anything that seemed like it might not belong. I couldn't find anything.
So I closed atom and moved the file to someplace else. When i reopened atom everything was back to normal. Thinking it might just be the file it's self still. I closed atom moved the file back to where it was and reopened atom. Yet when it opened Atom was acting normally like there wasn't even a problem.
Steps to Reproduce

[First Step]
[Second Step]
[and so on...]

Expected behavior: [What you expect to happen]
Actual behavior: [What actually happens]
Reproduces how often: [What percentage of the time does it reproduce?]
Versions
Atom    : 1.19.0
Electron: 1.6.9
Chrome  : 56.0.2924.87
Node    : 7.4.0
OS: Windows 10 Pro x64
Additional Information
Attached is the crash log which apears to contain no real info of note, but included just in case.
operation_log.txt

See https://github.com/atom/atom/issues/15236#issuecomment-322099135

Thanks so much for the detailed notes @pyromanci and thanks for working through the debugging steps :bow:
Not sure if we'll be able to figure out what happened since it's not reproducible (and a quick search didn't find any other Atom issues with EOVERFLOW) but before you closed Atom 2 night ago, do you happen to remember what you were doing before closing Atom?  Just working on a file and saved it, installing a package, etc?
In any case, we can leave this open for a bit in case someone else runs into the same error.

Ya. Since i couldn't reproduce it I felt is should include as much info as I could. All I was doing 2 nights ago was working on that myform_helper.php file and a few other php files all in the same project. I did use a few packages (Atom Beautify and SASS Autocompile), but did not install any.

I've experienced the same issue. When I try to open any file in the drive from sshfs, it throws the exception "Uncaught (in promise) Error: EOVERFLOW, Unknown error". Other text editors such like notepad++ or sublime text work as usual on that files.
It only occurs in atom 1.19.0 version and does not occur in atom 1.18.0.  Thus, I suspect https://github.com/atom/atom/pull/14435 may be related to this issue.
I'm using Windows 10 Pro x64 and the test was done with fresh install without any 3rd party packages.

Thanks @pjknkda - can you share the full stack trace?

I can only get exception with no stack trace when I use Chrome dev tools,

Is there any way to get more detailed stack trace?

Thanks for checking, I was wondering if there was more details than just "Uncaught (in promise) Error: EOVERFLOW, Unknown error" and your screenshot shows a bit more info 👍

@pjknkda how large is that README file?

It was 342 bytes. I also tested on a large file (~100MB) and the same exception has occurred.

@pyromanci @pjknkda I believe I have fixed this, but it would be great if you could help verify the fix.  Here is a page containing downloads for a version of Atom with the fix.
We will publish Atom 1.19.4 soon, and it will have the fix, but if you're interested you could try these downloads right away.

@maxbrunsfeld Thank you for the fix, however, I still have the same exception.

Uncaught (in promise) Error: EOVERFLOW, Unknown error 'V:\elice\elice-api\README.md'
Promise.reject (async)
step @ <embedded>:25580
Promise.reject (async)
completionCallback @ C:\Users\JK\AppData\Local\atom\app-1.19.4\resources\app\node_modules\superstring\index.js:73

(I've installed "AtomSetup.exe" file in your link.)
FYI, I'm using sshfs software (http://www.sftpnetdrive.com/) and I guess it may be correlated to its network drive implementation...

Wow, really sorry about that @pjknkda. Unfortunately, I haven't figured out what's happening yet, but this is still high priority for me. The next patch release of Atom will at least improve the error message slightly, which will help me determine why this EOVERFLOW error is happening.

Ok, Atom 1.19.4 is out. I don't think it will fix this bug but it will improve the error message slightly so that I can tell what system call is causing the error. If you get a chance, could you test again after upgrading? Thank you!

@maxbrunsfeld Here is the log from the newest atom version. I've used "AtomSetup-x64.exe" installer file. Thank you!

Thanks so much for going through this @pjknkda, that's really helpful. Working on a fix now.

@pjknkda Atom 1.19.5 is out, and the code that was producing this error has been reworked. When you get a chance, please let me know whether this problem is fixed. Thanks!

I've just installed Atom 1.19.5 and it works perfectly! Thank you so much!

Thank you so much for reporting back to me so many times. I'm really sorry this was broken for so long.

authors: 50Wliu maxbrunsfeld pjknkda pyromanci rsese


text:
Atom launches with white screen

When I try to open up atom editor, it shows a blank white screen. I can't edit any files or do anything. What is happening? Screenshot below:

Thanks for the report - can you share more information about the issue? In particular, the issue template information is really helpful and if you can add more details we can go from there:

Can you reproduce in safe mode (atom --safe)?
Have you tried any of the other debugging suggestions?
What version of Atom are you running (atom -v)?
What operating system are you running?

If you can share the above details, we can re-open and go from there.

We require the template to be filled out on all new issues and pull requests so if you can open a new issue with the template filled out, that would be helpful for us. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us half way :grinning:

authors: apollofernandes rsese


text:
Uncaught Error: The specified module could not be found./?~\AppData\Local\atom\app-1.41.0\res...

[Enter steps to reproduce:]

...
...

Atom: 1.41.0 x64
Electron: 4.2.7
OS: Microsoft Windows 10 Home
Thrown From: Atom Core
Stack Trace
Uncaught Error: The specified module could not be found.
\?\C:\Users\Rian Stephens\AppData\Local\atom\app-1.41.0\resources\app.asar.unpacked\node_modules\keyboard-layout\build\Release\keyboard-layout-manager.node
At ELECTRON_ASAR.js:160

Error: The specified module could not be found.
\\?\C:\Users\Rian Stephens\AppData\Local\atom\app-1.41.0\resources\app.asar.unpacked\node_modules\keyboard-layout\build\Release\keyboard-layout-manager.node
    at process.module.(anonymous function) [as dlopen] (ELECTRON_ASAR.js:160:31)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:722:18)
    at Object.module.(anonymous function) [as .node] (ELECTRON_ASAR.js:169:18)
    at Module.load (internal/modules/cjs/loader.js:602:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:541:12)
    at Function.Module._load (internal/modules/cjs/loader.js:533:3)
    at Module.require (/app.asar/static/index.js:72:46)
    at require (internal/modules/cjs/helpers.js:20:18)
    at customRequire (~/AppData/Local/atom/app-1.41.0/resources/app/static/<embedded>:1:727373)
    at get_KeyboardLayoutManager (~/AppData/Local/atom/app-1.41.0/resources/app/static/<embedded>:14:2746273)
    at get_manager (~/AppData/Local/atom/app-1.41.0/resources/app/static/<embedded>:14:2746375)
    at Object.getCurrentKeyboardLayout (~/AppData/Local/atom/app-1.41.0/resources/app/static/<embedded>:14:2746501)
    at e.keystrokeForKeyboardEvent (~/AppData/Local/atom/app-1.41.0/resources/app/static/<embedded>:14:1087039)
    at KeymapManager.keystrokeForKeyboardEvent (~/AppData/Local/atom/app-1.41.0/resources/app/static/<embedded>:11:1249633)
    at KeymapManager.handleKeyboardEvent (~/AppData/Local/atom/app-1.41.0/resources/app/static/<embedded>:11:1247618)
    at WindowEventHandler.handleDocumentKeyEvent (~/AppData/Local/atom/app-1.41.0/resources/app/static/<embedded>:11:284598)

Commands

Non-Core Packages
tidalcycles 3.8.1

Hi Rian.
I am an Atom user attempting to help you conversation move forward.
Have you been using Atom for long?
Which version did you install originally?
Could you check - Do you have the file keyboard-layout-manager.node as specified by your message?
I have seen some issues come up for Windows users that has a user name with the {space} in the user name. Consider using a portable installation as described here:
https://flight-manual.atom.io/getting-started/sections/installing-atom/#portable-mode
Make VERY sure that you have the full ZIP file. Sorry, I do not have a file hash to give you for verification.

Thanks for reaching out!
We require the template to be filled out on all new issues and pull requests. We do this so that we can be certain we have all the information we need to address your submission efficiently. This allows the maintainers to spend more time fixing bugs, implementing enhancements, and reviewing and merging pull requests.
Thanks for understanding and meeting us half way 😀

authors: WilSnoop darangi rianstephens


text:
Feature request: Most recently used (MRU) files and folders

I would like to be able to find files or folders that I have recently opened in previous editing sessions. On Windows this is usually done under the File menu. For example: File > Recent Files > (displays a sub menu of top 10 most recently used files in descending order).
File

Recent Files
> (top 10 most recent files)
Recent Folders
> (top 10 most recent folders)

:+1: This would be an awesome addition. I think the issue title and tags should be updated though because this isn't actually a Windows-only enhancement – all OSes should get some kind of File > Open Recent menu item and Windows and OS X should both get recent files / directories listings on their taskbar / dock right-click menus, respectively.
(It might've been lost in that whole paragraph, but to reiterate the windows tag should be removed and the issue title should be updated to remove "Windows")

I think I do have a "Most recent" on Ubuntu when I do File-->Open Folder.

@50Wilu Isn't that "Recently Used" Place in the File > Open Folder dialog on Ubuntu just "recently used" by any program, not just Atom?

Ah, yes, you're correct.

There's a package for this https://atom.io/packages/open-recent

Hey, author of open-recent here. The one thing I was wondering about if I wanted to merge the plugin into atom itself is if using localStorage for serializing the recent paths is okay.
Using atom's config to serialize the paths doesnt seem right since it updates the file every time you open something and might annoy people whove synched/use version control on their config.cson.

This feature was recently added for OS X and I believe Windows too in https://github.com/atom/atom/pull/9609.
Leaving this open and labeling it for Linux.

This feature was recently added for OS X and I believe Windows too in #9609.

This isn't working on Windows 10 in Atom 1.6.2.

@pflannery Can you try Atom 1.7.0?

@50Wliu ok. I've just tried 1.7.0 and I've managed to get files to appear but only when using the "File->Open File" menu.

It's not working when right clicking a file in explorer and choosing "Open with Atom".
It's also not working for folders.

there is also an issue when clicking on the file in the jump list

package.json is definitely there and available

Ok, thanks!  Can you please open a new issue for what you're experiencing?

Not sure if I should comment here or open a new issue.
Normally in windows if you right-click on an icon in the taskbar it shows a MRU list there and you can jump right into it. Atom shows some files there (can't figure out which ones, though - they have no connection with my MRU from the menu) but the most important list would be project directories and they don't seem to show up there.
(1) Request to have this list updated by Atom whenever a file is opened
(2) Request to have this list updated by Atom whenever a project directory is opened
(3) It would be nice if these to MRU lists would be separated as they are in the menus

Maybe a recent files list like PhpStorm ctrl+tab that can be searched as well?

authors: 50Wliu VisualTrauma Zren ghost jerone lee-dohm mnquintana pflannery plbowers


text:
Doing any context menu actions crashes Atom

Windows 8.1 64-bit Atom 0.168.0
Any action I try to do by right-clicking and selecting in the context menu crashes Atom.

This was fixed in 0.169, duplicate of #4904

authors: austincummings kevinsawicki


text:
:memo: Fix cursor name letter casing

Description of the Change
The docs currently say Cursor instead of cursor, just a quick fix there.
As discussed with @50Wliu on slack

:100:


text:
Build on Mac stops at: Running "build-atom-shell" task

When I run:
script/build

I get:
Node: v0.10.38
npm: v1.4.28
Installing build modules...
Installing apm...
Installing modules ✓
Deduping modules ✓
Running "build-atom-shell" task

It stops at that last line an never continues.

It's likely working, just slowly... on a good day, that task will take 30 min for me. I've heard others taking as long as 8 hours for that task to complete with a poor network.

@erusev It's because it's also downloading a big file 1.7G file. You can see more of what's happening if you run script/build -v, NOTE the -v flag to make it run in verbose.
Also, the sad thing is that every time you rebuild, it will clean the build, thus deleting this huge file and then you'll have to download it again. I managed to run around it by downloading the file and intercepting this call from a local server and just returning the 1.7G file.

This explains it, thanks.

authors: erusev jgeurts westoque

repo: atom/electron-starter

license: mit

license_source: bigquery


text:
updated the devtools documentation

Indicate how to get the basic chrome devtools in an electron application.

@pdoh00 Just the answer I was looking for! Thank you! :smiley:

Can you move this to quick-start.md? It is actually not related to devtools extension.

Yes. No problem.

@zcbenz My git-fu is pretty bad.  Sorry about the commit history.  Is this update to the quick-start how you would like it?  If there are some more changes you would like please let me know.

Thanks, I have pushed the change to 71ee864.

authors: brunze pdoh00 zcbenz

repo: atom/electron


text:
Incorrect application of italic when setting target in  tag.

In Atom, if an  tag is created in a Markdown document that has a target attribute set to "_blank", the remainder of the document is considered italic due to the underscore.
For example:
Not Italic.

This will be italic. (span .markup .italic .gfm)

The target attribute does appear to be on the whitelist for GitHub-flavored Markdown (and this isn't seemingly an issue on the GitHub web site, nor in the Markdown preview), so I think the underscore in the target attribute should be ignored when inside a quoted attribute value in an HTML tag, and the following text should not have the italic class applied.
Thanks!

Looks like this is a duplicate of https://github.com/atom/language-gfm/issues/44 – please subscribe there for updates.

authors: mnquintana nycdotnet

repo: atom/language-gfm


text:
Failed to activate the one-light-syntax package

[Enter steps to reproduce below:]

...
...

Atom Version: 1.3.2
System: Mac OS X 10.11.2
Thrown From: one-light-syntax package, v1.1.1
Stack Trace
Failed to activate the one-light-syntax package
At this.editor.displayBuffer.getVisibleRowRange is not a function

TypeError: this.editor.displayBuffer.getVisibleRowRange is not a function
    at pigments-markers.ColorBufferElement.updateMarkers (/Users/xaviermaximin/.atom/packages/pigments/lib/color-buffer-element.coffee:138:55)
    at pigments-markers.ColorBufferElement.editorConfigChanged (/Users/xaviermaximin/.atom/packages/pigments/lib/color-buffer-element.coffee:113:6)
    at /Users/xaviermaximin/.atom/packages/pigments/lib/color-buffer-element.coffee:77:8
    at Emitter.module.exports.Emitter.emit (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:86:11)
    at StyleManager.module.exports.StyleManager.addStyleElement (/Applications/Atom.app/Contents/Resources/app.asar/src/style-manager.js:114:27)
    at StyleManager.module.exports.StyleManager.addStyleSheet (/Applications/Atom.app/Contents/Resources/app.asar/src/style-manager.js:83:14)
    at ThemePackage.module.exports.Package.activateStylesheets (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:221:58)
    at ThemePackage.module.exports.Package.activateNow (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:167:14)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/theme-package.js:45:28
    at ThemePackage.module.exports.Package.measure (/Applications/Atom.app/Contents/Resources/app.asar/src/package.js:92:15)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/theme-package.js:41:24
    at ThemePackage.module.exports.ThemePackage.activate (/Applications/Atom.app/Contents/Resources/app.asar/src/theme-package.js:37:97)
    at PackageManager.module.exports.PackageManager.activatePackage (/Applications/Atom.app/Contents/Resources/app.asar/src/package-manager.js:517:21)
    at /Applications/Atom.app/Contents/Resources/app.asar/src/theme-manager.js:332:52
    at /Applications/Atom.app/Contents/Resources/app.asar/src/config.js:607:16
    at /Applications/Atom.app/Contents/Resources/app.asar/src/config.js:624:20
    at Emitter.module.exports.Emitter.emit (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:86:11)
    at Config.module.exports.Config.emitChangeEvent (/Applications/Atom.app/Contents/Resources/app.asar/src/config.js:809:29)
    at Config.module.exports.Config.setRawValue (/Applications/Atom.app/Contents/Resources/app.asar/src/config.js:601:19)
    at Config.module.exports.Config.set (/Applications/Atom.app/Contents/Resources/app.asar/src/config.js:227:14)
    at ThemesPanel.module.exports.ThemesPanel.updateThemeConfig (/Applications/Atom.app/Contents/Resources/app.asar/node_modules/settings-view/lib/themes-panel.js:495:28)
    at /Applications/Atom.app/Contents/Resources/app.asar/node_modules/settings-view/lib/themes-panel.js:502:24

Commands
     -2:59.3.0 window:install-shell-commands (div.panels-item)
     -1:58.2.0 settings-view:install-packages-and-themes (atom-text-editor.editor.is-focused)
  9x -1:41.9.0 core:backspace (atom-text-editor.editor.mini.is-focused)

Config
{
  "core": {
    "disabledPackages": [
      "jshint"
    ],
    "themes": [
      "one-dark-ui",
      "one-light-syntax"
    ]
  }
}

Installed Packages
# User
emmet, v2.3.13
file-icons, v1.6.9
language-babel, v2.7.3
minimap, v4.19.0
pigments, v0.19.5

# Dev
No dev packages

No idea why one-light-syntax was the package held responsible, but this is clearly a pigments issue.  Reading through the closed issues restarting Atom should fix this.

okay ! updating all extension and restarting fixed the issue

repo: atom/one-light-syntax


text:
'Sharing will resume…' messages displaying when using Markdown Preview

Description
For some clarity on the workflow where this was encountered, this happened while myself and @keeran were working on a GHE patch release. When we're figuring out fixes to verify in a GHE patch release, we basically sift through a list of PRs and see what's changed and what we may need to verify. This involves a lot of following links from Atom into a browser. We've been using this method with real-time sharing to split the work up for some time (thank you for making it possible for us to do this in Atom!).
However, yesterday, @keeran kept seeing this appear consistently while we worked through the list:

At first, we assumed this was because I kept switching to my browser to view the PRs, so @keeran jumped into Slack, to ask if this was some setting that could be disabled. After talking through our workflow with @as-cii, we eventually figured out that the problem was happening because I had enabled the Markdown Preview pane and was clicking links to the PRs from there (trying to save myself from having to copy & paste so many URLs, basically).
It would be great if the preview pane could be an exception to this behaviour, or failing that, it would be great if the message could give more clues to the end user as to why the sharing has been halted.
Steps to Reproduce

Share a markdown file containing links
Open the Markdown Preview pane
Click on one of the links in the Preview pane

Expected behavior:
Sharing continues (perhaps an incorrect expectation on my part)
Actual behavior:
Sharing is halted and the message in the screenshot above is displayed
Reproduces how often:
100%
Versions
→ atom-beta --version
Atom    : 1.21.0-beta2
Electron: 1.6.9
Chrome  : 56.0.2924.87
Node    : 7.4.0

→ apm-beta --version
apm  1.18.5
npm  3.10.10
node 6.9.5 x64
python 2.7.13
git 2.13.2

I believe this is fixed now, as per the comments in https://github.com/atom/teletype/issues/168#issuecomment-391705434

repo: atom/teletype


text:
[Tracking] RFC-001: Allow guests to collaborate on multiple remote buffers

We intend to implement RFC-001 via a series of pull requests. This will allow developers to start benefiting from the completed RFC-001 functionality without having to wait for all of RFC-001 to be completed. We'll use this issue to track progress.
TODO

[x] When following the host, any time they switch to a new buffer, a new editor for that remote buffer is automatically added to your workspace and focused. Existing editors for previous remote buffers are not automatically closed when this switch occurs. (#262) (v0.3.0)
[x] When a host closes a buffer, it is removed from all guest portals. (#262) (v0.3.0)
[x] When you are following a guest and the guest navigates to a different buffer in the same portal, you follow them to that buffer. (#262) (v0.3.0)
[ ] Show icon on site position avatars for participants that are not in the current editor proxy
[ ] Show site position avatars for participants that are in non-portal pane items
[ ] If a guest is working in a buffer when the host attempts to close the buffer, before removing the buffer from the portal, ask the host to confirm their intention to remove the buffer.
[ ] Allow guests to use fuzzy-finder to open any remote editor shared by the host

[ ] Given that the fuzzy-finder integration will likely require a new release of the fuzzy-finder package, and given that the fuzzy finder package is bundled with Atom and new versions ship with the Atom release cycle, we may want to consider providing a custom Teletype fuzzy-finder for remote editors in the interim. We could deprecate this custom fuzzy-finder after implementing it properly in the fuzzy-finder package. Food for thought.
[ ] Once the fuzzy-finder (or a custom Teletype fuzzy-finder) is in place, consider removing the logic that causes guests to automatically re-follow the host when the portal goes from n to zero remote items. (If the guest is working in a local editor when the portal goes from n to zero remote items, and we automatically re-follow the host, it will yank the guest away from their current editor. We'd like to avoid that. 😬)

Refs: https://github.com/atom/teletype/pull/231 (which introduced RFC-001)

I'd like to explore our handling of the host closing a buffer. Currently, I think we're planning on warning them if guests are editing. Another option could be to go ahead and remove the editor from the host's workspace, but maintain a reference to the editor in the host's pool (keep it's ref count above zero). This would allow guests to continue to edit and save the buffer.
One downside of this is that the host might not be aware of continued changes to particular buffers, although as we improve visibility of participant buffers this could be mitigated. I think it could be worth it though, because it prevents the need to prompt the host when closing buffers and could make it easier to bridge to a world where guests can open any file from the host's file system via the fuzzy finder.

Teletype v0.3.0 is now available. It adds support for the first set of enhancements noted in the issue body:

[x] When following the host, any time they switch to a new buffer, a new editor for that remote buffer is automatically added to your workspace and focused. Existing editors for previous remote buffers > are not automatically closed when this switch occurs.
[x] When a host closes a buffer, it is removed from all guest portals.
[x] When you are following a guest and the guest navigates to a different buffer in the same portal, you follow them to that buffer.

@simurai: Because other collaborators in the portal might be viewing a different part of the editor than you're viewing, or they might be viewing a completely different editor, we're looking for a way to visually represent where other collaborators are working, and we'd love to hear what you think. :smile:
Here's what we have so far:

A. Top-right: Collaborators in the same editor but in a row above your viewport. Clicking on avatar will take you to that collaborator's location and start following them.
B. Middle-right: The collaborator you're currently following (if any). This collaborator is working inside the current viewport. If they move elsewhere in the editor, your editor scrolls accordingly. If they move to a different editor, you follow them to their new editor.
C. Middle-right: Other collaborators in the same editor and inside your viewport. Clicking on avatar start following that collaborator.
D. Bottom-right: Collaborators in the same editor but in a row below your viewport or a column outside of your viewport. Clicking on avatar will take you to that collaborator's location and start following them.
E. Bottom-right: Collaborators in a different editor in the portal. Clicking on avatar will take you to the editor that the collaborator is working in, scroll to their location in that editor, and start following them.
F. (Not Yet Implemented) Bottom-right: Collaborators in a different pane item not associated with the portal. Since the collaborator is working on something that's not part of the portal, you can't click on them to go to their location.
We'd like a way to visually distinguish D, E, and F. Can you share any thoughts you might have on ways to visually represent this distinction?

👋  @IbisLiven kindly started a new issue 👉  #286

Allow guests to use fuzzy-finder to open any remote editor shared by the host

I have a couple questions re ☝ :

Do guests have to know the file name of a shared remote editor in order to fuzzy find it?
"any remote editor". Does that mean only tabs/files that the host currently has opened?
How many files are typically edited in a collaboration session. I guess just a handful, right?

Because it might be easier to discover what everyone is currently working on by showing all the remote files in the tooltip. Together with the avatars. So you can open files or follow somebody from there.

Read somewhere that the plan is to share the whole project (in the tree-view?). So this might only be a stop-gap.

Should we already think about scaling? Like what if there are dozens of people in the same buffer?

So far, we chosen to optimize for Teletype's primary use case: Developers collaborating closely with each other to edit code together in real time. Given that effectively editing code together in real time requires everyone to have a shared understanding of the goal, social constraints and communication constraints are likely going to limit the number of developers that you want to collaborate with simultaneously. Real world Teletype usage seems to support this theory:

With that in mind, I recommend that we continue to optimize the UI for portals that have just a few participants. I recommend that we limit the amount of effort that we invest in designing/developing/maintaining UI for portals that have a large number of participants.

... if we wanna add a way to see all, we could do it similarly to Google Docs. There it's capped at 7 avatars and then shows a dropdown that you can click to see a list of all users.

I've often wondered why Google Docs chooses to display large lists of participants. If there are 1,000 participants in a document, what use case is served by showing the user a list of all 1,000 participants? 🤔
I wonder the same thing for Teletype. A list of avatars and usernames is a solution, but I'm not sure what problem problem it's attempting to solve. What do y'all think?

[ ] Allow guests to use fuzzy-finder to open any remote editor shared by the host

@simurai: Thanks for the thoughts in https://github.com/atom/teletype/issues/268#issuecomment-352720067. @as-cii and I were looking into this today, and we wanted to share some additional context.
Responding to questions from https://github.com/atom/teletype/issues/268#issuecomment-352720067

Do guests have to know the file name of a shared remote editor in order to fuzzy find it?

The fuzzy-finder shows a maximum of 10 items at a time.
We're using the fuzzy-finder's buffer view (command+b on macOS), which currently shows all your local buffers. With that in mind, if a guest has no local buffers open, and they're collaborating in a single portal, and that portal has 10 or fewer remote files in the portal, then the guest will see a list of all 10 remote files. However, if the guest has several local buffers open, and/or if they're participating in a portal with more than 10 total remote files, and/or if they're participating in multiple portals, there may be more than 10 total buffers available, and the fuzzy finder will only show 10 items at a time.

"any remote editor". Does that mean only tabs/files that the host currently has opened?

That's right.

How many files are typically edited in a collaboration session. I guess just a handful, right?

I don't have any hard data available, but from using Teletype to build Teletype, I can say that we commonly collaborate on 5-20 files in a single collaboration session. Sometimes more.
I think the design in https://github.com/atom/teletype/issues/268#issuecomment-352720067 would struggle to scale to this many files, so I'd love to explore other options. We're currently thinking that the fuzzy-finder would be a good fit, but we're open to other ideas.
UI/UX goals for finding and opening remote files
We think that the UI should satisfy the following goals:

Distinguish remote files vs. local files - When choosing files to open (e.g., with the fuzzy-finder UI), clearly distinguish local files from remote files
Discover available remote files - When working locally, the fuzzy-finder is only useful when you know that a specific file exists, and then you can use the fuzzy-finder to locate it. You might know which files exist based on your familiarity with the project or by seeing files in the tree-view. As a guest in a portal, the fuzzy-finder will allow you to open any buffers that the host is sharing, but that set of buffers isn't necessarily the full set of files in a project. With that in mind, how can we best allow a guest to discover the set of remote files that they can open?
Maybe: Distinguish between multiple portals - Because you can be a guest of multiple portals, we may also want to distinguish portal A's files from portal B's files when choosing files to open via the UI

@simurai: Would you be willing to put together some fuzzy-finder mockups that attempt to satisfy those goals? (Note: If you think that something other than the fuzzy-finder would be a better fit for satisfying these goals, definitely let us know.)

Here some ideas:
1. Teletype fuzzy-finder keybinding
Currently the fuzzy-finder has these keybindings:

cmd-t or cmd-p to open the file finder
cmd-b to open the list of open buffers
cmd-shift-b to open the list of Git modified and untracked files

Teletype could introduce a new modifier key to find remote files, e.g. alt:

cmd-alt-t to find any remote file
cmd-alt-b to find only remote buffers that the host has open
cmd-alt-shift-b to find remote Git modified and untracked files

Concerns: Yet another keybinding to remember. Could be mitigated by adding some hints/links in the Teletype popup.

[x] Solved: Distinguish remote files vs. local files. 👉 Because it's a different keybinding, local and remote would never get mixed in the same list and are nicely separated.
[ ] Unsolved: Discover available remote files. 👉 You could cmd-alt-t to find any file, but you still have to know the file name.
[ ] Unsolved:  Distinguish between multiple portals. 👉 There could be a chord with a number involved. Like k1 cmd-b, k2 cmd-b etc. But might be cramp inducing.

2. It's just a (remote) project
Currently Atom allows to add multiple root projects. When joining a portal, it could be treated just like adding another root project. Then if you open the fuzzy-finder it shows local and remote files with a different path. Like @simurai/teletype/package.json. Or teletype/package.json (Shared by @simurai) to make it look less like it's a remote repo:

A new root project will appear in the tree-view that can be used to discover files. Remote projects and files get an (@username) added:

[x] Solved: Distinguish remote files vs. local files. 👉 Remote files show a @username.
[x] Solved: Discover available remote files. 👉 Tree-view can be used to find files even if you're not familiar with a project.
[x] Solved: Distinguish between multiple portals. 👉 There will be multiple root projects. Tabs and fuzzy-finder show different @usernames.

Open question: What happens if the host has multiple root projects. Would a guest get all of them added to the tree-view?
2B. with avatars
To make remote projects visually even more distinct, the host's avatar could be used instead of the @username.

3. custom panel
Teletype could have its own panel in a dock. With a buddy list. After joining a portal, you can drill down and open a file filter/browser:

[ ] Unsolved: Distinguish remote files vs. local files. 👉  A panel alone wouldn't solve it, remote buffers would still need a @username in the tab title, like in option 2.
[x] Solved: Discover available remote files. 👉 Has its own tree-view.
[x] Solved: Distinguish between multiple portals. 👉 Each portal has their own sub-view.

Personal opinion: Option 3 could be slick because everything is custom made and optimized for this use-case. At the same time it feels less integrated and more like "tacked on". Therefore I would give option 2 a try first by reusing existing ways (fuzzy-finder, tree-view).
Some people probably don't like having local and remote projects mixed. In that case they can open a new (empty) window before joining a portal. Then everything is separated and the local project stays untouched.

Here some ideas:

Thank you, @simurai! :bow::zap:
With https://github.com/atom/teletype/pull/323, we're pursuing the option you described in 2B:

Regarding the tree-view integration:

A new root project will appear in the tree-view that can be used to discover files. Remote projects and files get an (@username) added: ...

We're focused on the fuzzy-finder integration for this initial implementation, but I like the idea of also integrating with the tree-view. We'll keep that in mind as a future enhancement.

🎉

authors: jasonrudolph nathansobo simurai


text:
dd does not delete trailing lines

If you are at the end of the file and you have a few empty lines, "dd" or forms thereof will not delete those extra lines.

+1
Disabling whitespace package doesn't help either.
I'll dig into this later today.
I'm fairly new to this package so it'd be awesome if any maintainer could give me some pointers.

+1

Closing this out in favor of #801 since that issue has more detail. Please subscribe to that one for updates.

authors: maxbrunsfeld mitsuhiko octref spirityy

repo: atom/vim-mode


text:
Render issues using @atomist/slack-messages

Related to #32

@ddgenome I've added license header to all source ts files and made a few tweaks you suggested

repo: atomist/github-rugs


text:
more specific doc focusing on "Query Data"

Description

Currently (as-of v 0.4.1) the documentation about querying data (w/t Python API... not considering "pure UI" options here) is disseminated in the "Basics" tutorial, mostly, and doesn't include full coverage of the query API.
Notably, we are not talking about pure "query session" anymore (I think it was mentioned more explicitly in the old tutorials). I was able to locate https://docs.atoti.io/0.4.1/lib/atoti.html?highlight=query#atoti.open_query_session after a bit of search through the API ref, but tbh, only because I pretty much knew already what I was looking for.
Not sure if we should add a more specific "Query Data" section in existing "Basics" tutorial, or within the "Data Access" part of the doc (under "Help & Reference") or in a new dedicated part... but I think it's worth (re)documenting more explicitly all the options for "Data Query".
Then, more specifically for the "query session" mode, we should also document the requirement on back-end Rest API min version.
Thanks

This used to exist and have been removed in the tutorial refactoring: https://docs.atoti.io/0.4.0/tutorial/08-Queries.html
We should add something back into the doc, possibly the same page ?
I don't want to add it into "Basics" because "Basics" is made for new users and this query_session stuff is mostly for existing AP clients.

Agree with @fabiencelier . We could add it back as an extra tutorial.

Yes.  That's fine by me.
I would also emphasize on the fact that my ask is twofold: one is about mentioning (again) about the "query session" feature, but the other is about the fact that right now we don't have a clear entry point / section summarizing all API options to query data.
Atm in the "Help & Reference" section, we have a "Data Access" entry... wondering if we should/could rename that "Data Loading" (as it seems that's more of what's addressed in there atm), and add another entry called "Data Querying"...?

authors: fabiencelier flebr1 rcolle

repo: atoti/atoti


text:
at_client sdk changes for @mosphere - unique AES key for each transfer

[x] SDK changes
[ ] dev testing
[ ] atmosphere app testing with new changes
[ ] merge to trunk

have to coordinate with atmosphere team for perfecting the code and testing

waiting for Sarika  & team to give feedback on this PR
https://github.com/atsign-foundation/at_client_sdk/pull/173/files

feedback from Sarika:

File transfer object should be returned to the sender.
Status of put for each sharedWithAtsign should be returned to the sender. This will help to resend if required.
The status of file upload should also be shared.
There can be multiple files sent in a single container. So, the input of uploadFile function should be List, not single file.


text:
determine how to deal with VanillaIceCream preview API

The latest androidaudioplugin-midi-device-service contains support for MidiUmpDeviceService, but it turned out that it prevents publishing to Play Store, because of use of the preview API (compileSdkPreview embeds such metadata).
Since we haven't published any of the apps to Play Store yet, we can say it does not matter much, but it is itchy.

VIC is not a preview API anymore, so we have migrated to compileSdk = 35.

repo: atsushieno/aap-core


text:
Add Ray Traced Triangle Example

Adds the "hello world of graphics" triangle to examples.  Similar to the existing triangle.rs but this one is ray-traced.

This is awesome! Thank you for the contribution!
The existing Cornell box example has double the LOC and isn't as clear so this will be super useful for first-time users. I'm ready to merge it but I want to provide this feedback in case you plan on making any changes:

http://williamlewww.com/showcase_website/vk_khr_ray_tracing_tutorial/index.html seems to have gone offline; the source repo may be a better link for the ray_trace.rs example however for this one if you had some inspiration/source that would be fine to add.
I don't believe vk::BufferUsageFlags::STORAGE_BUFFER is required for any of these buffers.
let image = does not need to be outside the event loop; inside the loop would prevent needing to use the Option<Arc<..>> wrapper. Either way usage of the leased image is identical.
image/image_node may be removed entirely, along with .copy_image(image_node, frame.swapchain_image) if you write descriptor 1 directly to frame.swapchain_image.

These changes are not required and certainly could serve as places for new users to modify existing code to suit their needs.

Actually I referenced this, it's in C++ and is a bit old (still used the NV rt extension) but it covers the fundamentals nicely.  I will change the link to this if you think it's good enough!
And those suggestions sounds good; will update the PR for them.

Also, I have a local branch with a working proof-of-concept for compiling the example shaders to SPIRV at runtime using shaderc, so we don't have to scroll through all that inlined shader code and they can be nested away in their own dedicated files.  Do you think this would be a valuable contribution?

LGTM 😊
Compiling shaders at runtime would be a fine example; especially if it showed ways you could reload a shader and update a pipeline (create a new one, drop the old one). I do like the inline-spirv crate in the basic examples because it puts all the code right in one place for example purposes. I wouldn't use it in a real program because it increases build times for things which don't change often.
Another strategy is shown in the shader-toy example which uses build.rs to compile when shaders change (using shaderc).

I don't believe vk::BufferUsageFlags::STORAGE_BUFFER is required for any of these buffers.

Update: This was incorrect advice - a recent update to the Vulkan SDK added validation errors for the scratch buffers unless they include this. See 2b28faa.

authors: attackgoat seabassjh


text:
feat: changing builder configs from factor to boost

Boost is a percentage multiplier and should accommodate for the same requirements as factor but also gives the validator more precise control on how much they are willing to increase privileged relays score.
One additional feature of this is that validators could also create a new group and reduce the score of a specific relay. At the moment we don't see this as an issue, but would love to get your opinion on this.

Thanks for the PR @MrKoberman. We took a look through it and request that you revert to using the name factor and making it a percentage. This will reduce the amount of changes required in the PR.

@MrKoberman we're looking at releasing a beta in the next few days, at which point we'd want to freeze the features.  As such, if you could make the changes as mentioned above by @Bez625 (leave the name as factor, make it a percentage, stick with integer maths) ASAP it will allow us to include this.  Once the feature is in a release it will be much harder for us to change.

Thank you for the review, @mcdee, @Bez625. I addressed the comments on the PR with the latest commit.

authors: Bez625 MrKoberman mcdee

repo: attestantio/vouch


text:
nil is never a valid noms value

I noticed today that Struct won't complain if you construct one with nil values. Not sure if other contains suffer from the same lack of checking.

We should at least check this in validateStruct.

authors: arv rafael-atticlabs

repo: attic-labs/noms


text:
🛑 RestAPI is down

In 8ea94b6, RestAPI (https://mern-crud-ki1x.onrender.com/db-status) was down:

HTTP code: 0
Response time: 0 ms

Resolved: RestAPI is back up in ba3b616 after 10 minutes.

repo: atual-dev/upptime


text:
crashed when running the target

I have down load the audiokit.framework file from my colleague and drop it  to my project then run and build.
It crash when the app start, but the framework works fine in my colleague project.
The error is follow:
dyld: Library not loaded: @rpath/AudioKit.framework/AudioKit
Referenced from: /private/var/mobile/Containers/Bundle/Application/B2DF5B30-6850-48FA-ABEC-F5BFF3874348/XWShiChangProject.app/XWShiChangProject
Reason: no suitable image found.  Did find:
/private/var/mobile/Containers/Bundle/Application/B2DF5B30-6850-48FA-ABEC-F5BFF3874348/XWShiChangProject.app/Frameworks/AudioKit.framework/AudioKit: mmap() error 1 at address=0x00218000, size=0x001A8000 segment=__TEXT in Segment::map() mapping /private/var/mobile/Containers/Bundle/Application/B2DF5B30-6850-48FA-ABEC-F5BFF3874348/XWShiChangProject.app/Frameworks/AudioKit.framework/AudioKit

Follow the instructions in this video and it should work. https://vimeo.com/162156851 This is less of an issue and probably deserves to be a discussion on the Google group, not a Github issue:  https://groups.google.com/forum/#!forum/audiokit

authors: aure jessefang

repo: audiokit/AudioKit


text:
输出变量自动添加双引号

{{each cateList as item}}

                {{item._id}}

                    {{item.CateName}}

                    <button class="layui-btn layui-btn layui-btn-xs" onclick="x_admin_show('编辑','./cate/cateedit/{{item._id}}')">编辑</button>
                    <button class="layui-btn layui-btn-warm layui-btn-xs" onclick="x_admin_show('编辑','./cateadd')">添加子栏目</button>
                    <button class="layui-btn-danger layui-btn layui-btn-xs" onclick="member_del(this,'{{item._id}}')" href="javascript:;">删除</button>

            {{/each}}

比如:{{item._id}}  的那个路径会变成'./cate/cateedit/"5b7a5638aecb263f94335d8d"'   自动添加"" 导致路径跳转不了

请按照规范提交问题。

环境: koa + mongodb
数据: response: [{"_id":"5d5662eca1a19c41740ee08a","title":"小标题"}, { .. }]
模板:
<each response as item>
{{ item._id }} - {{ item.title }}
</each>

输出:
"5d5662eca1a19c41740ee08a" - 小标题
我的问题:
_id 字段自带双引号，title 字段不带双引号，要怎么才能让 _id 不自带双引号？

authors: Yxliam aui tsurumure

repo: aui/art-template


text:
刚发现了个 laytpl 号称比artTemplate更快的..有人尝试吗?

刚发现了个 laytpl 号称比artTemplate更快的..有人尝试吗?
http://laytpl.layui.com/
我看都差不太多....

很久没有登录 Github 了，在写一个比 artTemplate 更快的模板引擎还快的模板引擎，仅 353 字节：
function tpl (str) {
    return new Function("data", "_",
    "_='';_+=" + "'"
    + str.replace(/[\r\t\n]/g, " ")
       .replace(/'(?=[^%]*%>)/g,"\t")
       .split("'").join("\\'")
       .split("\t").join("'")
       .replace(/<%=(.+?)%>/g, "';_+=$1;_+='")
       .split("<%").join("';")
       .split("%>").join("_+='")
    + "'; return _;"
   );
}

那什么时候放出来?我们把玩把玩

这样一个就能称为模板引擎了啊？
在 2015-11-06 17:13:14，"糖饼" notifications@github.com 写道：
很久没有登录 Github 了，在写一个比 artTemplate 更快的模板引擎还快的模板引擎，仅 353 字节：
function tpl (str) {
return new Function("data", "",
"='';+=" + "'"
+ str.replace(/[\r\t\n]/g, " ")
.replace(/'(?=[^%]*%>)/g,"\t")
.split("'").join("\'")
.split("\t").join("'")
.replace(/<%=(.+?)%>/g, "';+=$1;+='")
.split("<%").join("';")
.split("%>").join("+='")
+ "'; return _;"
);
}
—
Reply to this email directly or view it on GitHub.

@miketwais 那什么才是模板引擎？

@pkptzx 二楼不是贴了源代码么？

@aui 你这个槽吐得太冷，他们都没听懂…

哈哈，是太冷！

要手写data前缀啊(/ □ )

不明觉厉...

二楼的代码怎么用啊？没有文档吗？

没看懂啊

不要迷恋速度，所谓模板引擎，就是把变量用自己定义的语法替换成js前台处理，模板处理的东西越少，自然性能越好，但是提供的脚手架就也少了很多

@jerry-he 在乎速度的话 就是用预编译吧

authors: 1021683053 aui jerry-he jerryyan1990 lfc625 miketwais pkptzx wangxingkai yanhaijing

repo: aui/artTemplate


text:
The font no created

字体无法创建,情况如下。

同样的问题，解决了吗？

可能第一个字体文件有未知错误，这里有一份可以使用的思源黑体 ttf 版本：https://github.com/aui/free-fonts/archive/KaiGenGothic-1.001-SimplifiedChinese.zip

是的，你给的那份字体可以，网上下载的不行，我之前转宋体什么的也是可以的。谢谢

authors: aui noonhorse songlipeng2003

repo: aui/font-spider


text:
(regression) computedFrom is only applied the first time the ViewModel is bound

I've prepared a Gist demo, however since there isn't a version after the computedFrom refactor, I'll just present what used to work and now is broken:
https://gist.run?id=ce252a8c24716e5d3620
To see what I mean switch between "computed" and "else". In the previous Aurelia version (the one running the Gist) this works well, as random is only computed once, every time when the route is bound. However if you run the same code using the latest version of Aurelia, when you switch to "computed" then back to "else" then back to "computed", the binding will become dirty-checked and a new Random value will be seeded every few hundred ms.
Might this be related to the recent computedFrom refactor by @jdanyow?

thanks @niieani - good catch!

authors: jdanyow niieani

repo: aurelia/binding


text:
skeleton-typescript-webpack, rimraf missing on windows

Hello, you are trying to run ./node_modules/.bin/rimraf, which is not present on Windows. That's causing Aurelia can't even build itself.
As I'm really looking forward for typescript-webpack version, I'm trying to run it every ~week, with no success. Are you planning to add some build tests? So you would know that it's not working before we report an issue?
More details:
Windows 10, installed 11.06.2016, downloaded ZIP from git half hour ago. Node.JS updated to v6.2.1.

rimraf works just fine on windows. I use it every day. The problem is that it seems rimraf isn't included as a devDependency. @niieani can you add that? I'm not exactly sure how this would have worked on any system.

Here you go: https://github.com/aurelia/skeleton-navigation/pull/484.
Sorry about that, must have missed it.

authors: AshleyGrant niieani tomasbonco

repo: aurelia/skeleton-navigation


text:
Bugfix - KeyInfo truncations

During production operation of SAML Service we had a data migration failure causing total transaction rollback when importing from FR.
Investigation showed that CSIRO had provided a KeyInfo Subject line that far exceeded our previous 255 limit.
As this is essentially a game of 'whack-a-mole' with regards to what is the correct column width to support here I have gone for the win and taken this right out to 2048, which at the length of a short novel and far greater than that allowed in even a modern tweet, should see us avoid this issue in the future.

Any chance you could poke around this today @smangelsdorf ?

repo: ausaccessfed/saml-service


text:
Failure on "yarn install" TypeError: patterns.map is not a function

Command line:
yarn install v1.3.2 (node:25978) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead. error An unexpected error occurred: "patterns.map is not a function". info If you think this is a bug, please open a bug report with the information provided in "/Users/ifirebrand/devoffcloud/scaffold/rad-new-dapp/yarn-error.log".
And yarn-error.log:
Trace:
  TypeError: patterns.map is not a function
      at /usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:54024:78
      at Generator.next (<anonymous>)
      at step (/usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:92:30)
      at /usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:110:14
      at new Promise (<anonymous>)
      at new F (/usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:29389:28)
      at /usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:89:12
      at Config.resolveWorkspaces (/usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:54060:7)
      at /usr/local/Cellar/yarn/1.3.2/libexec/lib/cli.js:21998:49
      at Generator.next (<anonymous>)

I got the same error.

Resolution is a non-intuitive upgrade / downgrade:

brew install yarn
brew upgrade yarn

This upgrades to 1.22.4 from 1.3.2 🤷♂

authors: corbinpage iFirebrand

repo: austintgriffith/scaffold-eth


text:
Auth0 token generated on node 6.2.2 stable doesn't get validated for GET all users

We have an auth0 application that works perfectly on node 4.2.4 and we recently when upgraded to node 6.2.2 breaks because of invalid token. A sample request that fails is:
❯❯❯ curl -iH "Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpYXQiOjE0Njg1MDY2OTIsInNjb3BlcyI6eyJ1c2VycyI6eyJhY3Rpb25zIjpbInJlYWQiXX19LCJqdGkiOiJmOTBiZWYxNzUwMWVkODYzY2Y5ZDgxODZhZThmNThjNyIsImV4cCI6MTQ2ODUxMDI5MiwiYXVkIjoiaEQycExGS1Zib2JmVXNld0tURDFYV2h2TmhGMlhzTjEifQ._Fb7Dyii61QPvSz5bkp2oqGWiq0Qn5R8zjBWhrh1U2A" https://cleansheet.auth0.com/api/v2/users
HTTP/1.1 401 Unauthorized
Date: Thu, 14 Jul 2016 14:50:47 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 192
Connection: keep-alive
WWW-Authenticate: Bearer error="Invalid signature received for JSON Web Token validation"
vary: origin
cache-control: no-cache

{"statusCode":401,"error":"Unauthorized","message":"Invalid signature received for JSON Web Token validation","attributes":{"error":"Invalid signature received for JSON Web Token validation"}}%

What I know at the moment is:

Tokens generated from node 4.2.4 works fine and returns 200 status.
The above mentioned token in curl request when used on http://jwt.io with api secret says verified, meaning secret works fine too.

I'm seeing the same thing since upgrading to node v6.3.1

Same here on node v6.9.1 - just forked to handle it on my own for now.
Does anyone know if the fix targets a known breaking change (from v.4 to v.6)?

any chance your auth0 secret needs to be base64 URL decoded before being used as the JWT secret?
this fixed it for me in rubyland:
# broken
token = JWT.encode payload, secret, 'HS256'
# fixed
token = JWT.encode payload, JWT.base64url_decode(secret), 'HS256'

authors: crashuniverse fabien seamusabshere simonmcmanus


text:
Multiple Audience Support

Hello,
It seems there is a bug / issue / lack of feature with the audience validation logic.  If you pass a list of audiences, it must be in all of them, not just one.  I believe it's not "standard" to allow multiple audiences as is done with the Issuer claim.
Please see the logic on line 415
https://github.com/auth0/java-jwt/blob/dd6bc25d9a7c2857bae29757a9198b798ac5734f/lib/src/main/java/com/auth0/jwt/JWTVerifier.java#L415
vs the logic on line 421
https://github.com/auth0/java-jwt/blob/dd6bc25d9a7c2857bae29757a9198b798ac5734f/lib/src/main/java/com/auth0/jwt/JWTVerifier.java#L421
Would it be possible to give us the option to validate all or at least one?  Its unclear to me why we have a list for aud, and a single value for issuer, but thats neither here nor there, can we simply check if one exists?  Not sure if this would need a broader vetting, or perhaps a new api to check for at least one vs all?
Could we simply tweak like 415 with Collections.disjoint(audience, value); instead of !audience.containsAll(value);

When validating a JWT, you can specify the audience(s), and the expectation is that all of the expected audiences are contained in the JWT's aud claim. The JWT may contain additional audiences than those specified to validate, but it must contain all the audiences specified.
For example, consider a JWT with an aud claim value of [https://domain.auth0.com/userinfo, https://api-id.com]. When validating the JWT, you can pass [https://domain.auth0.com/userinfo] to ensure the token is valid for the userinfo API, or [https://api-id.com] to ensure the token is valid for some custom API, or pass both to ensure the token is valid to be used for both APIs.

When validating a JWT, you can specify the audience(s), and the expectation is that all of the expected audiences are contained in the JWT's aud claim. The JWT may contain additional audiences than those specified to validate, but it must contain all the audiences specified.
For example, consider a JWT with an aud claim value of [https://domain.auth0.com/userinfo, https://api-id.com]. When validating the JWT, you can pass [https://domain.auth0.com/userinfo] to ensure the token is valid for the userinfo API, or [https://api-id.com] to ensure the token is valid for some custom API, or pass both to ensure the token is valid to be used for both APIs.

@jimmyjames  Agreed that is how it works today, but in our use case we do not want to require that they all are there, rather we want to require that at least one of the list is there.  We did work around this by doing a multiple pass validation logic but it seems a little ugly.

@jimmyjames  Agreed that is how it works today, but in our use case we do not want to require that they all are there, rather we want to require that at least one of the list is there.  We did work around this by doing a multiple pass validation logic but it seems a little ugly.

@PvanHengel when you say you do a multiple pass validation as a workaround, do you mean you are running multiple verifications until one passes with one of the expected audiences?
It might be cleaner to just skip audience validation in this scenario, and instead validate your expectations from the decoded JWT claim.
Regarding updating the SDK to support validating at least one of the expected audience is present, instead of all of them, I think it's something we should do. I don't know if it's something we can do really soon, as changing the current behavior would be a breaking change, so would need to be done in the next major release. Perhaps there's a non-breaking way to enable this functionality, and if so we can do that.

@PvanHengel when you say you do a multiple pass validation as a workaround, do you mean you are running multiple verifications until one passes with one of the expected audiences?
It might be cleaner to just skip audience validation in this scenario, and instead validate your expectations from the decoded JWT claim.
Regarding updating the SDK to support validating at least one of the expected audience is present, instead of all of them, I think it's something we should do. I don't know if it's something we can do really soon, as changing the current behavior would be a breaking change, so would need to be done in the next major release. Perhaps there's a non-breaking way to enable this functionality, and if so we can do that.

@PvanHengel does the changes in #472 look like they will meet your requirements?

authors: PvanHengel jimmyjames


text:
Support for i18n

I need the login screen in different languages, is it possible right now ?

+1

+1

Obviously, this is possible by passing a dict parameter to your lock.show() method. However, this parameter is not handle in Native code, hence it won't work. (cf. https://auth0.com/docs/libraries/lock/customization#dict-string-object- for references).
You can, for now, add a regular localization file (for iOS, I didn't test yet for Android) nammed Lock.strings and put your translations here, like (here is a sample for French) :
/*
  Lock.strings
  Sidemash

  Created by Kevin on 07/06/16.
  Copyright © 2016 Facebook. All rights reserved.
*/

/* Change Password */

"Please enter your email address. We will send you an email to reset your password."="Merci de renseigner votre email. Nous vous enverons un email pour réinitialiser votre mot de passe.";
"SEND"="Envoyer";
"Send reset password email"="Réinitialiser le mot de passe";
"Reset Password"="Réinitialiser le mot de passe";
"We've just sent you an email to reset your password."="Un email vous a été envoyé pour réinitialiser votre mot de passe.";
"Couldn't request to reset your password"="Impossible de traiter votre demande";

/* Credential Fields */

"Email"="Email";
"Email/Username"="Email/nom d'utilisateur";
"Password"="Mot de passe";
"Username"="Nom d'utilisateur";
"Phone Number"="Numéro de téléphone";
"Verification Code"="Code de vérification";

// ...

I will come with a full Lock.strings file later if no better solution

@KBLNY thank you so much, I just put Lock.strings file with translations into root of ios project and it works

You can do the same thing in Android by creating the corresponding entries on res/values/strings.xml.
The keys can be found in the exploded aar in a file called values.xml. Just do a file search for "Reset your password" inside your project (after you've built it at least once) and you'll find it.

Will this ever be supported? Sounds like a very simple thing.
I couldn't get it working using a Lock.strings on the root project.
Maybe it doesn't work with newer versions of react-native?

No, wait. It did work. I just couldn't notice because the example doesn't change very noticeable things.
Sorry.
Thanks @KBLNY

You can also follow this tutorial to make it work for multiple languages on iOS:
https://auth0.com/docs/libraries/lock-ios/v2/internationalization

authors: KBLNY camel113 ivanzotov mariomelo pbassut tdlage thiagoribeir015


text:
Support for non-federated logout

Currently the plugin supports only the federated logout using /v2/logout?federated.
Some social providers do not redirect the user back after logging out, so it's sometimes desirable to skip federated logout.

@thameera - Reviving this old one as we're refactoring both login and log out in the latest release.
In my mind, federated is rarely desired and I'm not even sure if it's necessary as an option. My thoughts are to leave federated out completely.
What do you think?

This was added after a customer request some time back. I've not seen any further requests afterwards, so maybe safe to close this.

authors: joshcanhelp thameera