Add support to samples to "copy link to this page" with appropriate protocol activation parameters

Description

Adds support to copy links to clipboard for sample groups and items

Added context menu to NavigationViewItems
Added button to ItemsPage

Fixes issue in protocol activation preventing html links that strips one of the slashes ("///" -> "//"), which some applications, like Outlook, does automatically. These links will now launch properly.
Fixes issue that was preventing NavigationView visuals from matching navigation due to protocol launch on first launch.

Motivation and Context
It would be helpful to be able to quickly generate links to specific pages within the app and add them to your clipboard. This would make it easier to reference specific samples in emails, chat, support tickets, issues, documentation, etc.
Fixes #623
How Has This Been Tested?
For each of:

What's New
All Controls
At least one sample group (e.g., Basic Input)
At least one sample item (e.g., Button)

I manually tested:

Generating a link on right-click
Generating a link via sample page (sample items only)
Pasting into Notepad (plaintext)
Pasting into Word (html)
Protocol launch with app closed
Protocol launch with app open

Screenshots (if appropriate):
Context Menu

Button

Paste Results:

Types of changes

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

Love this change overall - thanks @grochocki. One specific concern I have is that it isn't immediately obvious what to do with the output of the copied URI. In the plain-text case, for example, the user will need to enter that text into the Run dialog in order for it to do anything useful. This is mostly mitigated by the HTML-generated text in the word example above, but that depends on the user pasting the link into an app that understands what to do with it.
I think there are a few ways to mitigate this concern:

Include some text somewhere after the user clicks a link that says "Pasting this link into the Run dialog will open the app to this page" (or something)
Removing or minimizing the copy button on each page (maybe to just an icon?)

Open to ideas. Also open to being told that this isn't actually as much of a concern as I think it is 😉

Love this change overall - thanks @grochocki. One specific concern I have is that it isn't immediately obvious what to do with the output of the copied URI. In the plain-text case, for example, the user will need to enter that text into the Run dialog in order for it to do anything useful. This is mostly mitigated by the HTML-generated text in the word example above, but that depends on the user pasting the link into an app that understands what to do with it.
I think there are a few ways to mitigate this concern:

Include some text somewhere after the user clicks a link that says "Pasting this link into the Run dialog will open the app to this page" (or something)
Removing or minimizing the copy button on each page (maybe to just an icon?)

Open to ideas. Also open to being told that this isn't actually as much of a concern as I think it is 😉

Also open to being told that this isn't actually as much of a concern as I think it is 😉

I am not (yet) convinced this is that big of a concern. If it were a consumer app, sure, but if we are optimizing for developer audience, I feel like it is fairly low risk.

Include some text somewhere after the user clicks a link that says "Pasting this link into the Run dialog will open the app to this page" (or something)

I am open to something like this, though, anyway! I will noodle on it a bit.

Removing or minimizing the copy button on each page (maybe to just an icon?)

I thought about this originally, and just the icon (or the icon + "copy") might imply that you are copying selected content/text. I am open to other suggestions, but I think we may want to make what you are copying explicit in the action. Could reduce slightly to "Copy Sample Link", perhaps?

Also open to being told that this isn't actually as much of a concern as I think it is 😉

I am not (yet) convinced this is that big of a concern. If it were a consumer app, sure, but if we are optimizing for developer audience, I feel like it is fairly low risk.

Include some text somewhere after the user clicks a link that says "Pasting this link into the Run dialog will open the app to this page" (or something)

I am open to something like this, though, anyway! I will noodle on it a bit.

Removing or minimizing the copy button on each page (maybe to just an icon?)

I thought about this originally, and just the icon (or the icon + "copy") might imply that you are copying selected content/text. I am open to other suggestions, but I think we may want to make what you are copying explicit in the action. Could reduce slightly to "Copy Sample Link", perhaps?

Also open to being told that this isn't actually as much of a concern as I think it is 😉

I am not (yet) convinced this is that big of a concern. If it were a consumer app, sure, but if we are optimizing for developer audience, I feel like it is fairly low risk.

Fair enough, but it does bear mentioning that this app is also used by folks just learning about Xaml, designers, and is our "booth" app that we use to show off the power of the platform. It's not just devs.

Include some text somewhere after the user clicks a link that says "Pasting this link into the Run dialog will open the app to this page" (or something)

I am open to something like this, though, anyway! I will noodle on it a bit.

One idea: this info could be hosted in a flyout that either opens when the user clicks the button, or maybe inside a tooltip if the user hovers over the button.

Removing or minimizing the copy button on each page (maybe to just an icon?)

I thought about this originally, but just the icon (or the icon + "copy") might imply that you are copying selected content/text. I am open to other suggestions, but I think we may want to make what you are copying explicit in the action. Could reduce slightly to "Copy Sample Link", perhaps?

Good point, and I was pondering this as well. What if we swapped from "Copy" to "Link" for both the icon and the verbiage? Something like "Generate link to page"?
Thinking aloud: what if when you clicked the button, it opens up a flyout or TeachingTip that looks something like the share experience in Word including a link, a button that copies the link to the clipboard, etc.

Also open to being told that this isn't actually as much of a concern as I think it is 😉

I am not (yet) convinced this is that big of a concern. If it were a consumer app, sure, but if we are optimizing for developer audience, I feel like it is fairly low risk.

Fair enough, but it does bear mentioning that this app is also used by folks just learning about Xaml, designers, and is our "booth" app that we use to show off the power of the platform. It's not just devs.

Include some text somewhere after the user clicks a link that says "Pasting this link into the Run dialog will open the app to this page" (or something)

I am open to something like this, though, anyway! I will noodle on it a bit.

One idea: this info could be hosted in a flyout that either opens when the user clicks the button, or maybe inside a tooltip if the user hovers over the button.

Removing or minimizing the copy button on each page (maybe to just an icon?)

I thought about this originally, but just the icon (or the icon + "copy") might imply that you are copying selected content/text. I am open to other suggestions, but I think we may want to make what you are copying explicit in the action. Could reduce slightly to "Copy Sample Link", perhaps?

Good point, and I was pondering this as well. What if we swapped from "Copy" to "Link" for both the icon and the verbiage? Something like "Generate link to page"?
Thinking aloud: what if when you clicked the button, it opens up a flyout or TeachingTip that looks something like the share experience in Word including a link, a button that copies the link to the clipboard, etc.

Re Page link on pages:
What about updating the "page links" section that links to the source code to include that link? They all link to the page one way or another depending on what you are interested in, being able to get the link to the sample page could fit in there.

Re Page link on pages:
What about updating the "page links" section that links to the source code to include that link? They all link to the page one way or another depending on what you are interested in, being able to get the link to the sample page could fit in there.

@Chingucoding
That also seems like a reasonable place for this link as well, though the header will need to be updated from "View page code on GitHub" to something else - but I don't have a good idea off the top of my head.

@Chingucoding
That also seems like a reasonable place for this link as well, though the header will need to be updated from "View page code on GitHub" to something else - but I don't have a good idea off the top of my head.

Fair enough, but it does bear mentioning that this app is also used by folks just learning about Xaml, designers, and is our "booth" app that we use to show off the power of the platform. It's not just devs.

Great point!

One idea: this info could be hosted in a flyout that either opens when the user clicks the button, or maybe inside a tooltip if the user hovers over the button.

Thinking aloud: what if when you clicked the button, it opens up a flyout or TeachingTip that looks something like the share experience in Word including a link, a button that copies the link to the clipboard, etc.

I see a couple possible issues with the flyout approach. First, I would be concerned about it getting in the way of quick copies -- every copy would be two+ clicks. Also, unlike Word, there are not any other sharing options that really necessitate the flyout -- it would just be a surface to put instructional text, which gives me a "not the right tool for the job" kind of feeling.
The tooltip/teaching tip addresses both of those shortcomings and is along the lines of what I was thinking originally. For example, on first click, pop a teaching tip automatically. Subsequent copies would be one click. If you want to see the help text again, hover/click on a little info icon.
Similar to this pattern:

What if we swapped from "Copy" to "Link" for both the icon and the verbiage? Something like "Generate link to page"?

♥

What about updating the "page links" section that links to the source code to include that link? They all link to the page one way or another depending on what you are interested in, being able to get the link to the sample page could fit in there.

I considered this as well, but all of these links facilitate navigation, per the guidance:

Only use hyperlinks for navigation; don't use them for other actions.

I'd also be worried about discoverability. Both among a sea of links, but also because the content is shifted to the bottom on all but the largest layouts:

Fair enough, but it does bear mentioning that this app is also used by folks just learning about Xaml, designers, and is our "booth" app that we use to show off the power of the platform. It's not just devs.

Great point!

One idea: this info could be hosted in a flyout that either opens when the user clicks the button, or maybe inside a tooltip if the user hovers over the button.

Thinking aloud: what if when you clicked the button, it opens up a flyout or TeachingTip that looks something like the share experience in Word including a link, a button that copies the link to the clipboard, etc.

I see a couple possible issues with the flyout approach. First, I would be concerned about it getting in the way of quick copies -- every copy would be two+ clicks. Also, unlike Word, there are not any other sharing options that really necessitate the flyout -- it would just be a surface to put instructional text, which gives me a "not the right tool for the job" kind of feeling.
The tooltip/teaching tip addresses both of those shortcomings and is along the lines of what I was thinking originally. For example, on first click, pop a teaching tip automatically. Subsequent copies would be one click. If you want to see the help text again, hover/click on a little info icon.
Similar to this pattern:

What if we swapped from "Copy" to "Link" for both the icon and the verbiage? Something like "Generate link to page"?

♥

What about updating the "page links" section that links to the source code to include that link? They all link to the page one way or another depending on what you are interested in, being able to get the link to the sample page could fit in there.

I considered this as well, but all of these links facilitate navigation, per the guidance:

Only use hyperlinks for navigation; don't use them for other actions.

I'd also be worried about discoverability. Both among a sea of links, but also because the content is shifted to the bottom on all but the largest layouts:

I don't think that opening a flyout to be able to copy the text is the best way to handle this. Copying the URL is a non destructive operation and doesn't need confirmation.  I think a good way would be to have the button copy and then show a ToolTip with "Copied link" or similar which hides after a certain amount of time. TeachingTip is usually quite large and feels a bit overkill if next to the button. Not sure though how a TeachingTip at the bottom would look like, maybe that is another option to confirm the copying.

I'd also be worried about discoverability. Both among a sea of links, but also because the content is shifted to the bottom on all but the largest layouts:

True though you can still get the link by right clicking on the item in the navigation, though of course people need to know of this option first.

I don't think that opening a flyout to be able to copy the text is the best way to handle this. Copying the URL is a non destructive operation and doesn't need confirmation.  I think a good way would be to have the button copy and then show a ToolTip with "Copied link" or similar which hides after a certain amount of time. TeachingTip is usually quite large and feels a bit overkill if next to the button. Not sure though how a TeachingTip at the bottom would look like, maybe that is another option to confirm the copying.

I'd also be worried about discoverability. Both among a sea of links, but also because the content is shifted to the bottom on all but the largest layouts:

True though you can still get the link by right clicking on the item in the navigation, though of course people need to know of this option first.

Based on the feedback above, I tried to strike a balance between keeping the copy action quick, while also helping users familiarize themselves with this functionality:

Updated default string to "Generate Link to Page" and after clicked, updates to "Copied to Clipboard".
Added Teaching Tip that will always be displayed until the user chooses "Don't show again"
Teaching Tip can be reset in Settings

Teaching Tip:

New "Reset teaching tip" setting:

In action:

Based on the feedback above, I tried to strike a balance between keeping the copy action quick, while also helping users familiarize themselves with this functionality:

Updated default string to "Generate Link to Page" and after clicked, updates to "Copied to Clipboard".
Added Teaching Tip that will always be displayed until the user chooses "Don't show again"
Teaching Tip can be reset in Settings

Teaching Tip:

New "Reset teaching tip" setting:

In action:

:shipit:

:shipit:


Fix compatibility

This was using the vanilla unit_icon_wait_table and had conflicts with trap rework and free movement, so I made it hook a tiny part of RefreshUnitSprites instead of replacing the whole thing.

Hey, sorry if you misunderstood me, but I was just showing you what I did to fix it. How you maintain your repo is up to you.


chore(rust): update rustc to 1.65.0

Should this PR also include an updated Cargo.lock? I had to run cargo udpate to make the project compile, but I don't know if the CI already contemplates this.

Should this PR also include an updated Cargo.lock? I had to run cargo udpate to make the project compile, but I don't know if the CI already contemplates this.

No changes made to rust crate (yet), so I don't think cargo update is needed

@mergifyio rebase


Add Support AbstractPaths for pathname argument

Is your feature request related to a problem? Please explain.
Filepaths.jl and Filepathsbase.jl provide a type based approach to file paths. Makes programmatic usage much easier. It'd be great to support that interface.
Describe the solution you'd like
Support AbstractPath Types
Describe alternatives you've considered
This is a feature enhancement that would be nice to have and likely not take too much work, but ultimately the currently standard string-based path API does get the job done.

Thanks for opening the issue @jordancluts . I do think that this is likely to be an issue in those libraries which can be fixed inside Javis but maybe it would make sense to mention them there.
What I mean is the following:
pathname = p"gifs/test.gif" is what I assume you want to have. Is that correct?
When I write "Pathname: $pathname" this works but inside the run command i.e
run(`ffmpeg .... $pathname`)

this gets messed up and the slashes are lost.
I figured that we can use string(pathname) instead but I think it should be done by the libraries as this is unexpected behavior.

Thanks for your thoughts @Wikunia. Which libraries are you referring to that would need fixed? Do you mean Javis dependencies which could be modified to accept both string and filepath types?

I think that FilePathsBase should handle this. I will provide a fix tomorrow that makes it work but maybe it should still be an issue in their repo that when interpolating it inside backticks it seems to remove slashes which is unexpected.
In general Javis does not need a new dependency for this as we just handle it as a string. The library itself should interpolate it into a string in my understanding at least. I hope that makes more sense. I can also investigate it further tmr and open the issue on their end.
If you open an issue on either of those repos please link to this issue and/or ping me such that I'm aware :wink:

Ah I see what you mean now. Sorry for not grasping the first time around. Having glanced at the Javis code it does seem like there is nothing that would need to be changed to support it in a future world where interpolating into a command string works as expected. Certainly no need for a dependency.


Byebug install error

l am currently trying to install byebug with my rails project and keep getting this error
An error occurred while installing byebug (9.0.5), and Bundler cannot continue.
Make sure that `gem install byebug -v '9.0.5'` succeeds before bundling.

Any idea why this would be?

@katawura please include compilation log.

Same issue for me...
prompt$ gem install byebug -v '9.0.5'
Building native extensions.  This could take a while...
ERROR:  Error installing byebug:
ERROR: Failed to build gem native extension.
/Users/myid/.rvm/rubies/ruby-2.2.4/bin/ruby -r ./siteconf20160929-41835-10wdbb2.rb extconf.rb

creating Makefile
make "DESTDIR=" clean
make "DESTDIR="
compiling breakpoint.c
couldn't understand kern.osversion `15.6.0'
cc1: error: unrecognized command line option "-Wdivision-by-zero"
make: *** [breakpoint.o] Error 1
make failed, exit code 2
Gem files will remain installed in /Users/myid/.rvm/gems/ruby-2.2.4/gems/byebug-9.0.5 for inspection.
Results logged to /Users/myid/.rvm/gems/ruby-2.2.4/extensions/x86_64-darwin-15/2.2.0/byebug-9.0.5/gem_make.out

Not sure it will help much....  and FYI to get around this error I ran sudo gem install byebug -v '9.0.5' and it didn't throw this error.  Not ideal but it works.
/Users/myid/.rvm/rubies/ruby-2.2.4/bin/ruby -r ./siteconf20160929-41835-10wdbb2.rb extconf.rb
creating Makefile
make "DESTDIR=" clean
make "DESTDIR="
compiling breakpoint.c
couldn't understand kern.osversion `15.6.0'
cc1: error: unrecognized command line option "-Wdivision-by-zero"
make: *** [breakpoint.o] Error 1
make failed, exit code 2

Looks like it only happens on Mac OS.
So sudo gem install byebug -v '9.0.5' successfully compiled byebug?

sudo which gcc and which gcc have the same paths?

looks like it installed ok
prompt$ sudo gem install byebug -v '9.0.5'
Password:
Fetching: byebug-9.0.5.gem (100%)
Building native extensions.  This could take a while...
Successfully installed byebug-9.0.5
Parsing documentation for byebug-9.0.5
Installing ri documentation for byebug-9.0.5
Done installing documentation for byebug after 22 seconds
1 gem installed
and yes it appears they have the same path
prompt$ sudo which gcc
Password:
/usr/bin/gcc
prompt$ which gcc
/usr/bin/gcc

I'm not a Mac user, but looks like the only solution is to use:
CC=llvm-gcc gem install byebug -v '9.0.5'

I tried that before and it didn't work unless I typed something wrong.....
prompt$ CC=llvm-gcc gem install byebug -v '9.0.5'
Building native extensions.  This could take a while...
ERROR:  Error installing byebug:
ERROR: Failed to build gem native extension.
/Users/myid/.rvm/rubies/ruby-2.2.4/bin/ruby -r ./siteconf20160929-41761-hgkxot.rb extconf.rb

creating Makefile
make "DESTDIR=" clean
make "DESTDIR="
compiling breakpoint.c
couldn't understand kern.osversion `15.6.0'
cc1: error: unrecognized command line option "-Wdivision-by-zero"
make: *** [breakpoint.o] Error 1
make failed, exit code 2
Gem files will remain installed in /Users/myid/.rvm/gems/ruby-2.2.4/gems/byebug-9.0.5 for inspection.
Results logged to /Users/myid/.rvm/gems/ruby-2.2.4/extensions/x86_64-darwin-15/2.2.0/byebug-9.0.5/gem_make.out

Try a clean install of another ruby. If that works I think this is a problem with your current ruby. If it doesn't it might be a problem in byebug. For example,
rvm install 2.2.5
rvm use 2.2.5
gem install byebug

Speaking from memory since I don't use rvm.

@notcreativeusername anything?

I had the same problem.  Installing XCode Command Line Tools fixed it.

Closing since it's an old issue probably unrelated to byebug, thanks for the feedback!

Confirmed @deivid-rodriguez! Upgrading rvm fixes this issue.
https://github.com/rvm/rvm/issues/4371#issuecomment-385750233

This worked for me!
sudo gem install byebug -v '11.1.3'
Fetching byebug-11.1.3.gem
Building native extensions. This could take a while...
Successfully installed byebug-11.1.3
Parsing documentation for byebug-11.1.3
Installing ri documentation for byebug-11.1.3
Done installing documentation for byebug after 22 seconds
1 gem installed

I does NOT work on the latest stable macOS 11.4
gem install byebug -v '11.1.3'
❯ gem install byebug -v '11.1.3'
Building native extensions. This could take a while...
ERROR:  Error installing byebug:
	ERROR: Failed to build gem native extension.

    current directory: /Users/hipertracker/.frum/versions/3.0.2/lib/ruby/gems/3.0.0/gems/byebug-11.1.3/ext/byebug
/Users/hipertracker/.frum/versions/3.0.2/bin/ruby -I /Users/hipertracker/.frum/versions/3.0.2/lib/ruby/3.0.0 -r ./siteconf20210717-27404-hz68wf.rb extconf.rb
creating Makefile

current directory: /Users/hipertracker/.frum/versions/3.0.2/lib/ruby/gems/3.0.0/gems/byebug-11.1.3/ext/byebug
make DESTDIR\= clean

current directory: /Users/hipertracker/.frum/versions/3.0.2/lib/ruby/gems/3.0.0/gems/byebug-11.1.3/ext/byebug
make DESTDIR\=
compiling breakpoint.c
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/defines.h:73:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/backward/2/attributes.h:43:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/attr/pure.h:25:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/assert.h:132:1: error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes
RBIMPL_ATTR_NORETURN()
^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/attr/noreturn.h:29:33: note: expanded from macro 'RBIMPL_ATTR_NORETURN'
# define RBIMPL_ATTR_NORETURN() __declspec(noreturn)
                                ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:24:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/anyargs.h:77:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/intern/vm.h:64:1: error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes
RBIMPL_ATTR_NORETURN()
^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/attr/noreturn.h:29:33: note: expanded from macro 'RBIMPL_ATTR_NORETURN'
# define RBIMPL_ATTR_NORETURN() __declspec(noreturn)
                                ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/int.h:26:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/long.h:70:1: error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes
RBIMPL_ATTR_NORETURN()
^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/attr/noreturn.h:29:33: note: expanded from macro 'RBIMPL_ATTR_NORETURN'
# define RBIMPL_ATTR_NORETURN() __declspec(noreturn)
                                ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:28:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:46:14: error: expected parameter declarator
RUBY_ALIGNAS(SIZEOF_VALUE)
             ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/value.h:41:23: note: expanded from macro 'SIZEOF_VALUE'
# define SIZEOF_VALUE SIZEOF_LONG
                      ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/x86_64-darwin20/ruby/config.h:64:21: note: expanded from macro 'SIZEOF_LONG'
#define SIZEOF_LONG 8
                    ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:28:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:46:14: error: expected ')'
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/value.h:41:23: note: expanded from macro 'SIZEOF_VALUE'
# define SIZEOF_VALUE SIZEOF_LONG
                      ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/x86_64-darwin20/ruby/config.h:64:21: note: expanded from macro 'SIZEOF_LONG'
#define SIZEOF_LONG 8
                    ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:46:1: note: to match this '('
RUBY_ALIGNAS(SIZEOF_VALUE)
^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/backward/2/stdalign.h:27:22: note: expanded from macro 'RUBY_ALIGNAS'
#define RUBY_ALIGNAS RBIMPL_ALIGNAS
                     ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/stdalign.h:66:44: note: expanded from macro 'RBIMPL_ALIGNAS'
# define RBIMPL_ALIGNAS(_) __declspec(align(_))
                                           ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:28:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:47:1: error: expected function body after function declarator
RBasic {
^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:82:23: error: incomplete definition of type 'struct RBasic'
    return RBASIC(obj)->klass;
           ~~~~~~~~~~~^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:82:12: note: forward declaration of 'struct RBasic'
    return RBASIC(obj)->klass;
           ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:34:50: note: expanded from macro 'RBASIC'
#define RBASIC(obj)          RBIMPL_CAST((struct RBasic *)(obj))
                                                 ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:30:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:35:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/value_type.h:157:28: error: incomplete definition of type 'struct RBasic'
    VALUE ret = RBASIC(obj)->flags & RUBY_T_MASK;
                ~~~~~~~~~~~^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/value_type.h:157:17: note: forward declaration of 'struct RBasic'
    VALUE ret = RBASIC(obj)->flags & RUBY_T_MASK;
                ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:34:50: note: expanded from macro 'RBASIC'
#define RBASIC(obj)          RBIMPL_CAST((struct RBasic *)(obj))
                                                 ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:30:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:237:23: error: incomplete definition of type 'struct RBasic'
    return RBASIC(obj)->flags & flags;
           ~~~~~~~~~~~^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:237:12: note: forward declaration of 'struct RBasic'
    return RBASIC(obj)->flags & flags;
           ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:34:50: note: expanded from macro 'RBASIC'
#define RBASIC(obj)          RBIMPL_CAST((struct RBasic *)(obj))
                                                 ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:30:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:285:1: error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes
RBIMPL_ATTR_NOALIAS()
^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/attr/noalias.h:53:32: note: expanded from macro 'RBIMPL_ATTR_NOALIAS'
# define RBIMPL_ATTR_NOALIAS() __declspec(noalias)
                               ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:30:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:288:30: warning: declaration of 'struct RBasic' will not be visible outside of this function [-Wvisibility]
rbimpl_fl_set_raw_raw(struct RBasic *obj, VALUE flags)
                             ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:290:8: error: incomplete definition of type 'struct RBasic'
    obj->flags |= flags;
    ~~~^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:288:30: note: forward declaration of 'struct RBasic'
rbimpl_fl_set_raw_raw(struct RBasic *obj, VALUE flags)
                             ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:298:27: warning: incompatible pointer types passing 'struct RBasic *' to parameter of type 'struct RBasic *' [-Wincompatible-pointer-types]
    rbimpl_fl_set_raw_raw(RBASIC(obj), flags);
                          ^~~~~~~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:34:30: note: expanded from macro 'RBASIC'
#define RBASIC(obj)          RBIMPL_CAST((struct RBasic *)(obj))
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/cast.h:33:28: note: expanded from macro 'RBIMPL_CAST'
# define RBIMPL_CAST(expr) (expr)
                           ^~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:288:38: note: passing argument to parameter 'obj' here
rbimpl_fl_set_raw_raw(struct RBasic *obj, VALUE flags)
                                     ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:310:1: error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes
RBIMPL_ATTR_NOALIAS()
^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/attr/noalias.h:53:32: note: expanded from macro 'RBIMPL_ATTR_NOALIAS'
# define RBIMPL_ATTR_NOALIAS() __declspec(noalias)
                               ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:30:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:313:32: warning: declaration of 'struct RBasic' will not be visible outside of this function [-Wvisibility]
rbimpl_fl_unset_raw_raw(struct RBasic *obj, VALUE flags)
                               ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:315:8: error: incomplete definition of type 'struct RBasic'
    obj->flags &= ~flags;
    ~~~^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:313:32: note: forward declaration of 'struct RBasic'
rbimpl_fl_unset_raw_raw(struct RBasic *obj, VALUE flags)
                               ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:323:29: warning: incompatible pointer types passing 'struct RBasic *' to parameter of type 'struct RBasic *' [-Wincompatible-pointer-types]
    rbimpl_fl_unset_raw_raw(RBASIC(obj), flags);
                            ^~~~~~~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:34:30: note: expanded from macro 'RBASIC'
#define RBASIC(obj)          RBIMPL_CAST((struct RBasic *)(obj))
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/cast.h:33:28: note: expanded from macro 'RBIMPL_CAST'
# define RBIMPL_CAST(expr) (expr)
                           ^~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:313:40: note: passing argument to parameter 'obj' here
rbimpl_fl_unset_raw_raw(struct RBasic *obj, VALUE flags)
                                       ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:335:1: error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes
RBIMPL_ATTR_NOALIAS()
^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/attr/noalias.h:53:32: note: expanded from macro 'RBIMPL_ATTR_NOALIAS'
# define RBIMPL_ATTR_NOALIAS() __declspec(noalias)
                               ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:30:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:338:34: warning: declaration of 'struct RBasic' will not be visible outside of this function [-Wvisibility]
rbimpl_fl_reverse_raw_raw(struct RBasic *obj, VALUE flags)
                                 ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:340:8: error: incomplete definition of type 'struct RBasic'
    obj->flags ^= flags;
    ~~~^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:338:34: note: forward declaration of 'struct RBasic'
rbimpl_fl_reverse_raw_raw(struct RBasic *obj, VALUE flags)
                                 ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:348:31: warning: incompatible pointer types passing 'struct RBasic *' to parameter of type 'struct RBasic *' [-Wincompatible-pointer-types]
    rbimpl_fl_reverse_raw_raw(RBASIC(obj), flags);
                              ^~~~~~~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:34:30: note: expanded from macro 'RBASIC'
#define RBASIC(obj)          RBIMPL_CAST((struct RBasic *)(obj))
                             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/cast.h:33:28: note: expanded from macro 'RBIMPL_CAST'
# define RBIMPL_CAST(expr) (expr)
                           ^~~~~~
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:338:42: note: passing argument to parameter 'obj' here
rbimpl_fl_reverse_raw_raw(struct RBasic *obj, VALUE flags)
                                         ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:465:43: error: incomplete definition of type 'struct RBasic'
        if (RBASIC_CLASS(x) && !(RBASIC(x)->flags & RUBY_FL_SINGLETON)) {
                                 ~~~~~~~~~^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/fl_type.h:465:34: note: forward declaration of 'struct RBasic'
        if (RBASIC_CLASS(x) && !(RBASIC(x)->flags & RUBY_FL_SINGLETON)) {
                                 ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rbasic.h:34:50: note: expanded from macro 'RBASIC'
#define RBASIC(obj)          RBIMPL_CAST((struct RBasic *)(obj))
                                                 ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:25:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic.h:23:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/arithmetic/char.h:29:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:74:19: error: field has incomplete type 'struct RBasic'
    struct RBasic basic;
                  ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:74:12: note: forward declaration of 'struct RBasic'
    struct RBasic basic;
           ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:109:26: error: incomplete definition of type 'struct RBasic'
    VALUE f = RBASIC(str)->flags;
              ~~~~~~~~~~~^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:74:12: note: forward declaration of 'struct RBasic'
    struct RBasic basic;
           ^
In file included from breakpoint.c:1:
In file included from ./byebug.h:4:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby.h:38:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/ruby.h:26:
In file included from /Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core.h:23:
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rarray.h:88:19: error: field has incomplete type 'struct RBasic'
    struct RBasic basic;
                  ^
/Users/hipertracker/.frum/versions/3.0.2/include/ruby-3.0.0/ruby/internal/core/rstring.h:74:12: note: forward declaration of 'struct RBasic'
    struct RBasic basic;
           ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
6 warnings and 20 errors generated.
make: *** [breakpoint.o] Error 1

make failed, exit code 2

Gem files will remain installed in /Users/hipertracker/.frum/versions/3.0.2/lib/ruby/gems/3.0.0/gems/byebug-11.1.3 for inspection.
Results logged to /Users/hipertracker/.frum/versions/3.0.2/lib/ruby/gems/3.0.0/extensions/x86_64-darwin-20/3.0.0-static/byebug-11.1.3/gem_make.out

I can confirm it is not working on Ruby 3.0.1 running on Apple M1, macOS 11.5.2

I'm also unable to install this extension (or sqlite3 1.4.2) using Ruby 3.0.0 or 3.0.2 on macOS (Intel) 11.5.2.

I definitely don't have this 100% but in case this is useful to someone else, here's what I did to get this working.
Background: I have an Intel MacBookPro on Catalina (10.15.7).
I was getting the above error message and the messages seemed to be coming from C, which made me think it could be a C-compiler problem.
So, with homebrew, I was able to install a newer clang/llvm:
brew install llvm
And then use it:
export CC=/usr/local/opt/llvm/bin/clang
After this I was able to install byebug. I'm not aware of anything else I did, so I think this made the difference.
In case it's helpful, here are the versions of clang before/after:
❯ /usr/bin/clang -v
Apple clang version 11.0.3 (clang-1<IP_ADDRESS>)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

❯ /usr/local/opt/llvm/bin/clang -v
Homebrew clang version 13.0.0
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin

This might help - have not tried it yet to confirm..
#825 comment 903260365

I also encountered this error (Apple M1, Monterey), and it worked after setting export CC=clang.

I got it working with below steps on big sur:
Reinstall commandline tools
sudo rm -rf /Library/Developer/CommandLineTools
xcode-select --install

Install llvm
brew install llvm

Set cc and ccx to llvm from homebrew
export CC=/usr/local/opt/llvm/bin/clang
export CCX=/usr/local/opt/llvm/bin/clang

Thank you. This solution worked for me. However, on my setup, Homebrew installed the clang executable in a different directory, and it was only necessary to set CC. So, for me, this was enough:
brew install llvm
export CC=/opt/homebrew/opt/llvm/bin/clang

Tengo este problema y no pude resolverlo con las sugerencias de aquí.
my log:
gem install byebug -v '8.2.1' --source 'https://rubygems.org/'
Building native extensions. This could take a while...
ERROR:  Error installing byebug:
ERROR: Failed to build gem native extension.
current directory: /Users/cristopherhuarocolivera/.rvm/gems/ruby-2.3.1/gems/byebug-8.2.1/ext/byebug

/Users/cristopherhuarocolivera/.rvm/rubies/ruby-2.3.1/bin/ruby -I /Users/cristopherhuarocolivera/.rvm/rubies/ruby-2.3.1/lib/ruby/site_ruby/2.3.0 -r ./siteconf20220827-2255-9s7bl4.rb extconf.rb
creating Makefile
current directory: /Users/cristopherhuarocolivera/.rvm/gems/ruby-2.3.1/gems/byebug-8.2.1/ext/byebug
make "DESTDIR=" clean
current directory: /Users/cristopherhuarocolivera/.rvm/gems/ruby-2.3.1/gems/byebug-8.2.1/ext/byebug
make "DESTDIR="
compiling locker.c
make: /usr/local/opt/llvm@11/bin/clang: No such file or directory
make: *** [locker.o] Error 1
make failed, exit code 2
Gem files will remain installed in /Users/cristopherhuarocolivera/.rvm/gems/ruby-2.3.1/gems/byebug-8.2.1 for inspection.
Results logged to /Users/cristopherhuarocolivera/.rvm/gems/ruby-2.3.1/extensions/-darwin-21/2.3.0/byebug-8.2.1/gem_make.out
Thanks in advance
Mac 12.5.1 Macbook Air M1

Using Ventura, I had the same issue and tried the above solutions. I tried them in the embedded IDE terminal (vs code) and gem install showed same error - even when restarting embedded terminal. Then I switched to the OG mac terminal app and gem install byebug and subsequent bundle install completed without issue.

I get an error when I try to install llvm@11:
$ brew install llvm@11
Error: llvm@11 has been disabled because it is a versioned formula!

But the following worked for me on Sonoma 14.5:
brew install llvm@12
export CC=/usr/local/opt/llvm@12/bin/clang
gem install byebug -v '9.0.6'

llvm@16 did not work. I'm not sure at which point between 12 and 16 this broke.

adapted answer if your address for brew packages is different:
brew install llvm@12
export CC=$(brew --prefix llvm@12)/bin/clang
gem install byebug -v '9.0.6'

In my case, need to install byebug 11.0.1.
So I installed llvm@14 and installed with flags like following

Install LLVM 14:
brew install llvm@14

Add LLVM to your PATH and set compiler flags:
export PATH="/usr/local/opt/llvm@14/bin:$PATH" export LDFLAGS="-L/usr/local/opt/llvm@14/lib" export CPPFLAGS="-I/usr/local/opt/llvm@14/include"

Now try installing byebug with these flags:
ARCHFLAGS="-arch x86_64" CC=/usr/local/opt/llvm@14/bin/clang CFLAGS="-Wno-error=implicit-function-declaration" gem install byebug -v '11.0.1'


Valkey.set() checks

hi
if we pass both ex and px to set, it will be passed down to valkey, which thros a syntax error, but the error is not descriptive, so maybe adding a check would be good.
also there is no type check for exat and pxat and keepttl and nx and xx
also get looks like a bug, it should be the value of get that is passed down, not hardcoded True
the options dict also seems un-needed
let me know what you think

I'm not sure what you mean. I don't think we validate types anywhere, except in the broken type annotations. If it quacks like a duck, it is a duck.

since set() checks the type of ex and px i mentioned that, but it's not that important
i'll write up something to check the first problem

I'm not sure what you mean. I don't think we validate types anywhere, except in the broken type annotations. If it quacks like a duck, it is a duck.

since set() checks the type of ex and px i mentioned that, but it's not that important

Oh right! I missed that. Well then we can add something similar for exat and pxat.

i'll write up something to check the first problem

thanks!


Uncaught TypeError: undefined is not a function

[Enter steps to reproduce below:]

...
...

Atom Version: 1.0.0
System: Mac OS X 10.10.3
Thrown From: ever-notedown package, v0.2.2
Stack Trace
Uncaught TypeError: undefined is not a function
At /Users/tyler/.atom/packages/ever-notedown/lib/ever-notedown.coffee:1105

TypeError: undefined is not a function
  at Object.module.exports.file2Evernote (/Users/tyler/.atom/packages/ever-notedown/lib/ever-notedown.coffee:1105:19)
  at /Users/tyler/.atom/packages/ever-notedown/lib/ever-notedown.coffee:475:12
  at Emitter.module.exports.Emitter.emit (/Users/tyler/Downloads/Atom.app/Contents/Resources/app.asar/node_modules/event-kit/lib/emitter.js:82:11)
  at HTMLButtonElement.<anonymous> (/Users/tyler/.atom/packages/ever-notedown/lib/ever-notedown-preview-view.coffee:452:22)
  at HTMLButtonElement.jQuery.event.dispatch (/Users/tyler/Downloads/Atom.app/Contents/Resources/app.asar/node_modules/jquery/dist/jquery.js:4435:9)
  at HTMLButtonElement.elemData.handle (/Users/tyler/Downloads/Atom.app/Contents/Resources/app.asar/node_modules/jquery/dist/jquery.js:4121:28)

Commands
  6x -2:04.0 core:backspace (atom-text-editor.editor.is-focused)
     -2:02.6.0 core:move-down (atom-text-editor.editor.is-focused)
     -2:02.3.0 core:backspace (atom-text-editor.editor.is-focused)
     -2:01.4.0 core:save (atom-text-editor.editor.is-focused)
     -1:19.8.0 editor:newline (atom-text-editor.editor.is-focused)
     -1:19.3.0 core:move-up (atom-text-editor.editor.is-focused)
     -1:16.5.0 editor:newline (atom-text-editor.editor.is-focused)
     -1:15.3.0 core:save (atom-text-editor.editor.is-focused)
     -1:01.8.0 editor:move-to-first-character-of-line (atom-text-editor.editor.is-focused)
     -1:01.3.0 core:backspace (atom-text-editor.editor.is-focused)
     -1:00.8.0 core:save (atom-text-editor.editor.is-focused)
     -0:41.8.0 core:copy (atom-text-editor.editor.is-focused)
     -0:40.6.0 core:paste (atom-text-editor.editor.is-focused)
     -0:38.4.0 core:save (atom-text-editor.editor.is-focused)
     -0:22 ever-notedown:toggle (atom-text-editor.editor.is-focused)
     -0:18.4.0 core:paste (atom-text-editor.editor.is-focused)

Config
{
  "core": {
    "themes": [
      "one-light-ui",
      "one-light-syntax"
    ],
    "disabledPackages": [
      "wrap-guide"
    ]
  },
  "ever-notedown": {
    "openNoteInEvernoteAuto": true
  }
}

Installed Packages
# User
ever-notedown, v0.2.2
multi-wrap-guide, v0.20.0

# Dev
No dev packages

@tjgillies I released a very basic patch that should in theory ostensibly fixes this... But may I ask on what kind of file are you trying to apply the "send current file to Evernote" operation? As of now I kind of assume people would use it on a markdown or text file (with extensions like '.md', '.markdown', '.txt'), with default note format (in package preference) set to "markdown". I have written some code to handle notes that are in raw html or plain text (so EVND will not perform the markdown->html rendering), but honestly I have not tested those cases (and don't have time to...) so I doubt it actually works.


Problem in running the code

Hi cheind,
Thanks for sharing your codes. I've compiled it using visual studio 2015 successfully.
This error was appeared in output window when I run it:
'dest_tests.exe' (Win32): Loaded 'D:\Programming\Programming_Morteza\dest-master\build\Release\dest_tests.exe'. Module was built without symbols.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\ntdll.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\kernel32.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\KernelBase.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\msvcp140.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\vcruntime140.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-runtime-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-heap-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-utility-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-stdio-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-filesystem-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-string-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-time-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-math-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-locale-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-multibyte-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-convert-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\api-ms-win-crt-environment-l1-1-0.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\advapi32.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\msvcrt.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\sechost.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\rpcrt4.dll'. Cannot find or open the PDB file.
'dest_tests.exe' (Win32): Loaded 'C:\Windows\System32\ucrtbase.dll'. Cannot find or open the PDB file.
The program '[8144] dest_tests.exe' has exited with code 0 (0x0).
Regards.
Morteza

Please try to build and run in Release mode.

Thanks for your reply, i run it in release mode but the same error was appeared.

Not sure what error you are referring to. The only thing i can see from your logs are missing pdb files which is just a hint not necessarily an error. What happens when you run one of the examples?

So thanks. It solved. I found that any of example projects was build using cmake. I recompiled it again and enable Opencv. The examples work without problem.It is very nice.
I've another question, I want to use video tracker in web based application. How can I convert code to client side web based code. dest_tracker_VJ_ibug.bin is about  48M and it is heavy to load in web applications. How can I use it?

I would advise to provide a web-service, i.e a service that runs on some dedicated host / port and to which clients communicate with a JSON like API. That way all the heavy lifting is done on the server side and not the client side.
closes #3

I would advise to provide a web-service, i.e a service that runs on some dedicated host / port and to which clients communicate with a JSON like API. That way all the heavy lifting is done on the server side and not the client side.


Upgrade to Terraform 0.12 HCL language

Terraform v0.12 is a major release focused on configuration language improvements.
I've upgraded the syntax to fit.

@laviavigdor Thanks for that. As far as I've time I will review it :)

Closing this, because we just updated to 0.13.


Reverse selected publications order in about page

I would like to know how I can present my "Selected Publications" list on the About page in reversed order. I tried some solutions proposed in this issue, but nothing worked. Please, note that I can reverse the order in the Publications list tab by changing the order of the years in publications.md file.

I believe you are using an older version of our template, since we removed the list of years in the publications page, as you can see here. But you can probably achieve this by setting some parameters for the query done in selected_papers.html for the jekyll-scholar plugin. More specifically, try this:
{% bibliography -f {{ site.scholar.bibliography }} --group_by none --sort_by year,month --order descending --query @*[selected=true]* %}


Moderation queue or restricted access to annotate

Love your work!
I would like to use this plugin on a WP page with a longer text to add my own annotations to the text and let some others help out with the annotations, without letting the whole world add to it.
I guess this is not perfectly within your scope, but I don't know of any other tool that would work better for this. All I need is for you to add an option to let me choose either:

that all new annotations be put in a moderation queue for the site owner to allow or deny before they are published, or
only let specific Hypothesis accounts annotate a specific WP page.

Would this be possible?
Thank you!

Hello,
I'm afraid Hypothesis does not currently support either of these features, but we do have some closely related requests from other users. Specifically:

We have users who are interested in pre-moderation (ie. a moderation queue of some sort)
We have users who are interested in being able to control which "channel" (or Group) is shown by default, and a kind of group which users have to be invited to before they can annotate in.

I cannot promise when either of these will be implemented yet, but we post about product updates on our blog at https://web.hypothes.is/blog/

So, this is not about creating a moderation queue? https://twitter.com/dr_jdean/status/887401832582062081
Or is it the pre-moderation thing you mentioned? Any ETA on this?
Thanks!

We currently support flagging annotations, and there are plans to support more moderation controls eventually.
Closing this though, as that would not be exclusive to the WordPress plugin.


New PR to test SignCLA at 2019-03-22 12:13:51.302456795 -0400 EDT m=+5.150635062

Body of PR

corp-pass-fork-staging: test succeeded


Saving to a database?

Are there any examples that show how to save Scribe logs to a database? Thanks

Is there any reason you would want to?

Scalability, I could query logs from a database from anywhere then

For such scalability, I suggest using more powerful tools like Splunk. Closing for now since this library was meant to serve as a lightweight solution for smaller applications i.e. internal tools.


Uncaught AttributeError in sendchat.py line 32

Aider version: 0.60.0
Python version: 3.11.10
Platform: Linux-6.6.58-x86_64-with-glibc2.40
Python implementation: CPython
Virtual environment: No
OS: Linux 6.6.58 (64bit)
Git version: git version 2.47.0
An uncaught exception occurred:
Traceback (most recent call last):
  File ".aider-wrapped", line 9, in <module>
    sys.exit(main())
             ^^^^^^
  File "main.py", line 776, in main
    coder.run()
  File "base_coder.py", line 730, in run
    self.run_one(user_message, preproc)
  File "base_coder.py", line 773, in run_one
    list(self.send_message(message))
  File "base_coder.py", line 1212, in send_message
    saved_message = self.auto_commit(edited)
                    ^^^^^^^^^^^^^^^^^^^^^^^^
  File "base_coder.py", line 1895, in auto_commit
    res = self.repo.commit(fnames=edited, context=context, aider_edits=True)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "repo.py", line 110, in commit
    commit_message = self.get_commit_message(diffs, context)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "repo.py", line 195, in get_commit_message
    commit_message = simple_send_with_retries(
                     ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "sendchat.py", line 40, in wrapper
    retry_exceptions(),
    ^^^^^^^^^^^^^^^^^^
  File "sendchat.py", line 32, in retry_exceptions
    litellm.llms.anthropic.chat.AnthropicError,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: module 'litellm.llms.anthropic.chat' has no attribute 'AnthropicError'

Thanks for trying aider and filing this issue.
This looks like a duplicate of #2145. Please see the comments there for more information, and feel free to continue the discussion within that issue.
I'm going to close this issue for now. But please let me know if you think this is actually a distinct issue and I will reopen this issue.


Cannot Test Connection To Bot

Whenever I test the bot from https://dev.botframework.com/ I click test, and I receive this error in the console:
TypeError: Cannot read property 'id' of undefined
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:135:50
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:336:53
    at UniversalBot.tryCatch (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:425:13)
    at next (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:336:23)
    at UniversalBot.eventMiddleware (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:339:9)
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:132:23
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:381:53
    at UniversalBot.tryCatch (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:425:13)
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:381:23
    at UniversalBot.tryCatch (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:425:13)

Every time I try to send a message to the bot from the chat on that page, I receive the same error.
Here's my test code:
var express = require (__dirname + "/../../nodejs/node_modules/express");
var expressServer = express ();
var port = 9042;
var fs = require ("fs");
var configFile = fs.readFileSync (__dirname + "/testconfig.json");
var config = JSON.parse (configFile);
var credentials = {
		key: fs.readFileSync (config.key),
		cert: fs.readFileSync (config.cert),
		ca: fs.readFileSync (config.ca)
	};

var server = require ("https").createServer (credentials, expressServer);
var serverIO = require (__dirname + "/../../nodejs/node_modules/socket.io")(server);
server.listen (port);
var cookieParser = require ("cookie-parser");
var bodyParser = require (__dirname + "/../../nodejs/node_modules/body-parser");
var session = require ("express-session");
expressServer.use (cookieParser ());
expressServer.use (bodyParser.urlencoded ({ extended: true }));
expressServer.get ("/", function (req, res)
	{
		res.send ("Derp");
	});
// A bunch of Socket.io stuff is done here.

var builder = require (__dirname + "/../../nodejs/node_modules/botbuilder");
var connector = new builder.ChatConnector ({
				appId: config.appId,
				appPassword: config.appPassword
			});
expressServer.post ("/assistant", connector.listen ());

var bot = new builder.UniversalBot (connector);
bot.dialog ("/", function (session, args)
	{
		console.log ('yep1');
	});

Am I doing something wrong here?

Am I just doing something wrong here?

@cglong sorry about bugging you guys. I really am looking for any response though

Hi @ncoonrod, I've unfortunately never worked with the NodeJS version of the framework 😞 Perhaps @msft-shahins can point you in the right direction?

@maxpert can you help?

It looks like the test connection message isn't sending a properly formatted message. I'll work on reproducing this.

I just tried to reproduce this and the test ping works fine for me.  Could you try updating to the latest version of the SDK (3.7.0) and then try again.

My original test was on that version it seems. I did a fresh install of all packages too, just to be safe. Still getting the same error.

@ncoonrod can you check to see if your bot in the portal is a v1 bot?  You would have a gray bar across the top of the portal telling you that you should upgrade to v3. That would be the only thing we can think of that would be causing the test to fail.

There's no gray bar anywhere on that page, it does say that my bot's framework version is 3.0.

Adding Dan for other ideas...

Which is the name of your bot in https://dev.botframework.com/  ? Have you tried to use any channel ?

The bot's name is Nicole, the url is: https://dev.botframework.com/bots?id=nicole
All I've tried using is clicking the Test Connection to your bot button. When I click on Test, it says accepted, then in my console, I receive that error message.
Same happens when I try using the web chat down below on that same page. I just tried testing it using the "Add to Skype" link, and the same thing happens.

Just another update, when I was testing this code, I was using Node.js version v4.6.1. For giggles, I also tried version v6.10.1 and v7.7.3. All versions have the same issue.

Hi ncoonrod,
Please try changing:
expressServer.post ("/assistant", connector.listen ());
to:
expressServer.post ("/api/messages", connector.listen ());
and post the results here.  If this change doesn't fix your issue, please also provide a functioning repo with all external files included (i.e. testconfig.json, without your appid and password of course), so we can more easily reproduce your issue.

I changed it to what you specified, and I get the same message, just different line numbers:
TypeError: Cannot read property 'id' of undefined
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:136:50
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:381:53
    at UniversalBot.tryCatch (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:470:13)
    at next (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:381:23)
    at UniversalBot.eventMiddleware (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:384:9)
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:133:23
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:426:53
    at UniversalBot.tryCatch (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:470:13)
    at /mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:426:23
    at UniversalBot.tryCatch (/mnt/disk/website/webapp/nodejs/node_modules/botbuilder/lib/bots/UniversalBot.js:470:13)

You can clone the example repo at: https://github.com/ncoonrod/botframeworktest

Thank you for your submission.
I've made a pull request for your repo.
Here you can find some samples: https://github.com/Microsoft/BotBuilder-Samples/tree/master/Node
Here are some very helpful videos: https://www.youtube.com/playlist?list=PLgF-CyaX1p3Exrp9F80bSIdNdnw2iTAZp

Please Note:
The Microsoft Bot Framework team prefers that how to questions be submitted on Stack Overflow. The official Bot Framework Github repo  is the preferred platform for submitting bug fixes and feature requests.

I have closed this issue. If more assistance is required, please feel free to resubmit your question over on Stack Overflow and one of our support engineers will help you out as soon as possible.

Thank you for your code changes, however you are using Restify as the server. Is the Bot Framework not compatible with Express acting as the server?
The overview at https://docs.botframework.com/en-us/node/builder/overview/ states that it is. Was I using Express incorrectly?

Yes, the Bot Framework is compatible with Express as the server.  I believe your implementation had some issues.  I just tried to simplify things, so you have a working example.


chore: Always disable instance metadata tags

Fixes #N/A
Description
This change always disables instance metadata tags. Not passing this setting explicitly to the instance launch can cause an account that [has configured account defaults for instance metadata settings] to override the instance default. If the account default has IMDS tags set to enabled, EC2 will use this, causing Karpenter to fail to launch instances with
  - lastTransitionTime: "2024-09-15T05:00:09Z"
    message: 'creating instance, with fleet error(s), InvalidParameterValue: ''kubernetes.io/cluster/scale-test''
      is not a valid tag key. Tag keys must match pattern ([0-9a-zA-Z\\-_+=,.@:]{1,255}),
      and must not be a reserved name (''.'', ''..'', ''_index''); RequestLimitExceeded:
      Request limit exceeded.'

How was this change tested?
Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>8
Details

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

Totals

Change from base Build<PHONE_NUMBER>4:
0.0%

Covered Lines:
5512

Relevant Lines:
6639

💛  - Coveralls


[#8070]Update WebRequestActivity.cs

Add http DELETE method implement in WebRequestActivity

Looks good to me!


Implement a CLI manual solution that minimizes doc drift

Implement a CLI manual solution that minimizes doc drift
Context and Problem Statement
The Cobra library works really well for generating a manual in the CLI, but this is not the only place our customers will be ingesting the manual. We need a way to generate documentation that can be rendered as HTML, PDF, and the like.
Decision Drivers

Reduce or eliminate documentation drift
Support i18n
Enable non-developers to contribute
Build an HTML based manual

Considered Options

Hand-crafted documentation
Cobra based solution
Doc driven CLI + Hugo

Decision Outcome
Chosen option: Doc driven CLI + Hugo
This approach offers more value to customers with the tradeoff of some DX pain. The assumption is that new CLI commands will be on the rare side as we continue developing the product and the energy will be invested in a TUI or Web experience.
Confirmation

Hand-crafted documentation

🟢 Control over the documentation
🟢 Easy to implement
🔴 Prone to documentation drift
🔴 High level of collaboration required

Cobra based solution
This solution will utilize Cobra's pre-build documentation solution.

🟢 Code driven documentation
🟢 Reduced documentation drift
🟡 Additional tool needed for i18n
🔴 Little control over the documentation look and feel without enhancements

Doc driven CLI + Hugo
This approach will utilize markdown files to define the documentation and thus the behavior of the CLI. This will reduce the documentation drift and enable i18n if it becomes needed. The documentation is driven by Hugo's content management.

🟢 Markdown based solution
🟢 Centralize behavior
🟢 Full control over HTML documentation
🟡 Small negative impact on DX

Feels a little unnatural, but so does i18n with token files
Less DRY
Slightly slower when running hot (no build first)

🟡 Embedded HTML theme via submodule or committed to repo via Hugo
🔴 Bespoke

I don't understand how Hugo would avoid doc drift. Do you have an example or reference?

@suchak1 Hugo enables us to build easily consumed documentation as HTML. The markdown is organized as markdown files and then pulled into the code like so...

This allows us to expand like this

If we go with hand-crated or cobra-based, there is a higher barrier to entry for less technical folks (product/technical writers) to engage with the documentation. Given that, it seems likely we'd build a separate source of truth for technical docs, which would lead to greater potential for doc drift. Option 3 (hugo), gives us one documentation source of truth:

for less technical folks to contribute to docs (including styling)
for code to consume
for internationalization support (with minimal to no engineering engagement necessary)
to build a static docs site with

I think option 3's benefits outweigh the costs to DX, which are relatively minimal overall. The only thing worse than no documentation is incorrect documentation, and this seems like the best long-term solution to keep docs in sync.


Restrict the plugin to specific RedProtect regions

We'd like to restrict the plugin to specific RedProtect regions.

I implemented this feature and will send you a pull request for this.


superenv: handle formulae with runtime CPU detection

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew typecheck with your changes locally?
[x] Have you successfully run brew tests with your changes locally?

Some formulae are able to detect the features of the runtime CPU, and
execute code accordingly. This typically entails 1) the detection of
features of the build-time CPU in order to determine the targets that
the compiler can generate code for, and 2) generating code for the
targets that the compiler can support.
Our filtering of optimization flags can cause misdetection of compiler
features, leading to failed builds [1], and miscompilation even when the
build does not fail [2].
Let's try to fix this by allowing formulae to declare
ENV.runtime_cpu_detection which skips the filtering of -march and
related flags.
I've also skipped the filtering of the optimisation
level, since it seems to me that if upstream maintainers have gone to
the lengths of writing code that detects runtime hardware, they probably
also know better about appropriate -O flags to use.
This is a partial list of formulae that should make use of this feature:

apache-arrow
fftw
gromacs
open-mpi
openblas

Partially resolves Homebrew/homebrew-core#76537.
[1] open-mpi/ompi#8306 and linked issues/PRs
[2] Homebrew/homebrew-core#76537

Review period will end on 2021-06-29 at 00:00:00 UTC.

I like this approach but think it's too broad. If you have runtime CPU detection: we still shouldn't allow passing -march but -mtune/-mcpu/ should all be fine.

Allowing -march flags is actually the most important change here, as that's the one that fixes apache-arrow.
It should be safe to allow a build to pass -march flags to generate e.g. AVX512 instructions whenever the software does runtime CPU detection, as the AVX512 code is not run when the machine doesn't support it. (Of course, this is predicated on their runtime detection not having any significant bugs, but this seems no different from any other important feature of any other formula we ship.)

I'd also rather see the existing O methods used over making this also allow that.

The difficulty with O methods is that they're too broad: they apply to everything the compiler builds in a given make invocation when in practice a build system could be much more calibrated than that.
I just think that if upstream have invested a lot of work into optimising their build, it seems wiser to rely on the work they've done rather than try to duplicate it (poorly) ourselves. However, if you'd rather not defer to upstream on this issue, I'm fine with leaving this out of the PR.

More specifically on the bug:

it seems Open MPI also used to pass -march=skylake-avx512 to the compiler as a way of detecting CPU features, and it looks like Arrow is doing the same thing here

Is this something that we could then scope just to e.g. configure and avoid using during e.g. make?

Scoping flag refurbishment to make but avoiding it at configure is exactly what broke open-mpi, unfortunately. I'm also not aware of a way to do this with cmake.
When we filter these flags, we start violating the build system's assumptions about the code it generates and that leads to broken software. This is especially bad when we do one thing at configure and another thing at make. This isn't an issue when the build doesn't do runtime detection, because the build is typically mostly agnostic about the details of the generated code.

Review period ended.

It should be safe to allow a build to pass -march flags to generate e.g. AVX512 instructions whenever the software does runtime CPU detection, as the AVX512 code is not run when the machine doesn't support it. (Of course, this is predicated on their runtime detection not having any significant bugs, but this seems no different from any other important feature of any other formula we ship.)

It should be safe but I'm not completely concerned it's worth the risk (in the abstract). These sort of bugs are a bit of a nightmare to reproduce.

I just think that if upstream have invested a lot of work into optimising their build, it seems wiser to rely on the work they've done rather than try to duplicate it (poorly) ourselves. However, if you'd rather not defer to upstream on this issue, I'm fine with leaving this out of the PR.

Yes, I'd rather not defer to upstream on build flags when it doesn't actively break things (which it doesn't seem to with O).

Scoping flag refurbishment to make but avoiding it at configure is exactly what broke open-mpi, unfortunately. I'm also not aware of a way to do this with cmake.

Yeh, I've always been a bit dubious by this approach.

When we filter these flags, we start violating the build system's assumptions about the code it generates and that leads to broken software. This is especially bad when we do one thing at configure and another thing at make. This isn't an issue when the build doesn't do runtime detection, because the build is typically mostly agnostic about the details of the generated code.

I agree.
Sorry for you needing to talk me through on this so much: can you explain what we're filtering right now, how that breaks things (and on what formula) and what filtering this would avoid/fix (and on what formula)?
Thanks @carlocab ❤

It should be safe but I'm not completely concerned it's worth the risk (in the abstract). These sort of bugs are a bit of a nightmare to reproduce.

There are two kinds of bugs here: one is when the upstream get their runtime detection code wrong, and another which we introduce via flag filtering. I'd argue the former is easier to diagnose and fix because it's something upstream will be able to reproduce in their own builds.
If we really are keen on filtering flags, we probably have to be much more aggressive about it, but this might take expertise we don't have and can be a bit brittle (see below).
I also think that if we want to restrict the code that the compiler generates, we should probably be doing so through an API they expose (e.g. configure flags and environment variables) -- at least for complicated build systems that are designed to generate code for different hardware targets.

Yes, I'd rather not defer to upstream on build flags when it doesn't actively break things (which it doesn't seem to with O).

Sure, will drop this.

can you explain what we're filtering right now, how that breaks things (and on what formula) and what filtering this would avoid/fix (and on what formula)?

The primary thing seems to be the filtering of -march, and I think that is summarised most concisely in this comment. From superenv logs in that comment:
clang++ called with: -DCXX_SUPPORTS_AVX512 -march=skylake-avx512 -mbmi2 -mavx512f -mavx512cd -mavx512vl -mavx512dq -mavx512bw -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -MD -MT CMakeFiles/cmTC_8a09b.dir/src.cxx.o -MF CMakeFiles/cmTC_8a09b.dir/src.cxx.o.d -o CMakeFiles/cmTC_8a09b.dir/src.cxx.o -c /tmp/apache-arrow-20210504-8671-1nk57rs/apache-arrow-4.0.0/build/CMakeFiles/CMakeTmp/src.cxx
superenv removed:  -march=skylake-avx512 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
superenv added:    -pipe -w -Os -march=nehalem -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -isystem/usr/local/include -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/llvm/include<EMAIL_ADDRESS>-I/usr/local/opt/openblas/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include
superenv executed: clang++ -pipe -w -Os -march=nehalem -DCXX_SUPPORTS_AVX512 -mbmi2 -mavx512f -mavx512cd -mavx512vl -mavx512dq -mavx512bw -MD -MT CMakeFiles/cmTC_8a09b.dir/src.cxx.o -MF CMakeFiles/cmTC_8a09b.dir/src.cxx.o.d -o CMakeFiles/cmTC_8a09b.dir/src.cxx.o -c /tmp/apache-arrow-20210504-8671-1nk57rs/apache-arrow-4.0.0/build/CMakeFiles/CMakeTmp/src.cxx -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -isystem/usr/local/include -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/llvm/include<EMAIL_ADDRESS>-I/usr/local/opt/openblas/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include

clang++ called with: -march=skylake-avx512 -mbmi2 -mavx512f -mavx512cd -mavx512vl -mavx512dq -mavx512bw -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_8a09b.dir/src.cxx.o -o cmTC_8a09b
superenv removed:  -march=skylake-avx512 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
superenv added:    -pipe -w -Os -march=nehalem -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -isystem/usr/local/include -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/llvm/include<EMAIL_ADDRESS>-I/usr/local/opt/openblas/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include<EMAIL_ADDRESS>-L/usr/local/opt/openblas/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/lib -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries
superenv executed: clang++ -pipe -w -Os -march=nehalem -mbmi2 -mavx512f -mavx512cd -mavx512vl -mavx512dq -mavx512bw -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_8a09b.dir/src.cxx.o -o cmTC_8a09b -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk --sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -isystem/usr/local/include -isystem/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers -I/usr/local/opt/llvm/include<EMAIL_ADDRESS>-I/usr/local/opt/openblas/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include<EMAIL_ADDRESS>-L/usr/local/opt/openblas/lib -L/usr/local/opt/readline/lib -L/usr/local/opt/sqlite/lib -L/usr/local/lib -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries -Wl,-headerpad_max_install_names

So the miscompilation seems to occur when we switch out the -march=skylake-avx512 flag, but not also the other related flags:

-DCXX_SUPPORTS_AVX512
-mavx512f
-mavx512cd
-mavx512vl
-mavx512dq
-mavx512bw

This actively breaks apache-arrow (but only at runtime), used to break open-mpi (upstream have since worked around this, but I still suspect we pass mixed flags somewhere, leading to things being subtly broken and difficult to reproduce).
In particular, the apache-arrow build gets broken because it still produces AVX512 instructions, but then gets the runtime hardware detection wrong and attempts to run AVX512 instructions on hardware that doesn't support it (possibly because it finds code that was generated with -march=nehalem and doesn't notice that it was also generated with -mbmi2 or -mavx512f and friends).
In light of this, I think our options here are:

Don't filter this flag when the software supports runtime detection.
Filter flags much more aggressively.

I find the latter a bit fragile. We'd need to know about all the compiler flags we want to avoid--these are woefully documented and change over time. This might also be software-dependent because of things like custom macros (e.g. -DCXX_SUPPORTS_AVX512 above).

It should be safe but I'm not completely concerned it's worth the risk (in the abstract). These sort of bugs are a bit of a nightmare to reproduce.

There are two kinds of bugs here: one is when the upstream get their runtime detection code wrong, and another which we introduce via flag filtering. I'd argue the former is easier to diagnose and fix because it's something upstream will be able to reproduce in their own builds.

Well, there's the third potential bug that we're opening with this: upstream set march to a value based on the build machine that is too new for the machines that we run bottles on.
This is something we used to set a lot of and this filtering pretty much solved the problem.

-DCXX_SUPPORTS_AVX512

Feels like this is what we should be filtering out in this specific case. We don't want to use these instructions. We shouldn't be setting march to a value newer than the machines we expect this to be shipped on because the compiler can decide at any point to use instructions that machines we distribute the bottles on don't support. In this case: perhaps that's scoped entirely to code that's run at runtime but the added complexity here doesn't seem to outweigh just disabling AVX512 support here for this particular formula.

Well, there's the third potential bug that we're opening with this: upstream set march to a value based on the build machine that is too new for the machines that we run bottles on.

That's not a bug -- that is intentional. Build systems that do runtime detection will set march to values based on the build machine, but scopes this code to run only when the runtime hardware supports it. That's what the apache-arrow build does, and it successfully avoids running code generated for newer processors at runtime when you build it outside of brew. It fails to do this because brew's flag filtering violates its assumptions about the code that it is generating.
More flag filtering is fragile and requires more maintenance, and is needed only when upstream get their builds wrong (and could still break things in other ways in this case), and runs the risk of breaking things when they get their builds right. It is also more complicated than the approach I've proposed here, and less prone to being subject to subtle and difficult-to-reproduce bugs.
We could try to disable AVX512 for specific formulae, but, even if we do, I think we would still need the changes here because everything I've said above about builds that do runtime detection is still true. (e.g. they could try to generate code that runs on processors older than Nehalem, but then our flag filtering interferes with that can could break things)
I understand the concern about breaking things needlessly, but I think it's worth the risk. It's a relatively simple fix to an existing broken bottle and allows us to ship bottles for other formulae that work better for users with newer machines than the oldest we support.
If it helps, I'm happy to slowly roll this out to formulae and monitor them closely to make sure nothing's broken.

@carlocab Thanks again for your explanations. Personally, I'm still not sure that this is worth it. While the ENV.runtime_cpu_detection accurately describes what we're using it for what it translates to is ENV.allow_march_mcpu_mtune. My concern is that this ends up being used in more formulae than the original intent in this PR because "upstream wants to use their own values".
If this is scoped to only be what we need it for today (i.e. -march only) and we add an audit with an allowlist: fine with me. If it starts getting misused, though, expect me to start asking for a revert 😁.
Do you have a sense of how many formulae you want to use this on?

No thanks are necessary!

While the ENV.runtime_cpu_detection accurately describes what we're using it for what it translates to is ENV.allow_march_mcpu_mtune.

I think the name is useful because it's suggestive enough for any maintainer reviewing a PR that adds this to ask the right questions about it.

If this is scoped to only be what we need it for today (i.e. -march only)

This sounds good to me. Now that I think about it, I don't think we run the risk of miscompilation from filtering out -mtune and -mcpu, so I'm happy restrict the scope here.

and we add an audit with an allowlist: fine with me. If it starts getting misused, though, expect me to start asking for a revert 😁.

This is good to me too, but I think I can do you one better: we can audit the use of ENV.runtime_cpu_detection beyond the allowlist using the following heuristic. We disassemble the TEXT sections of the MachO files in a bottle and check for a cpuid instruction. If it doesn't have that, then it is unlikely that the software actually does runtime detection.
I hope this can help allay your concern about upstream trying to abuse this.

Do you have a sense of how many formulae you want to use this on?

All the formulae I named in my initial post definitely do runtime detection and would be improved by the change here. Any formula used for computation-intensive tasks [1] is a good candidate too, but I'll need to check them carefully to make sure.
[1] e.g. vtk, pcl, opencv, tbb -- these all have cpuid instructions in their bottles too.

This is good to me too, but I think I can do you one better: we can audit the use of ENV.runtime_cpu_detection in addition to having an allowlist using the following heuristic. We disassemble the TEXT sections of the MachO files in a bottle and check for a cpuid instruction. If it doesn't have that, then it is unlikely that the software actually does runtime detection.
I hope this can help allay your concern about upstream trying to abuse this.

Yes, that would completely allay my concerns!

I think the name is useful because it's suggestive enough for any maintainer reviewing a PR that adds this to ask the right questions about it.

Ok. Don't feel strongly on the name (particularly if audits for it appear at some stage too).

Great; thanks for hashing this out with me. I'm pleased with where we've landed here.

I initially planned to add the audit here, but I'll do that in a separate PR.


Update vendor files to point to k8s 1.12.0 release

This PR updates dependency files to point to k8s 1.12.0 release.

/lgtm


react-native link (aka rnpm) support for Windows

Seeing as Windows is a supported platform until platforms can better manager their own CLI and packager needs.
This PR adds RNWindows 3rd party library linking like expected in iOS and Android.
Motivation
Linking 3rd party libraries should be supported first, because then I'd like to do a follow up PR with @grabbou to identify how we can effectively move RNPM functionality out of react-native core and eventually housed in each external platform's repo.  The goal would be working with @cpojer and hopefully @andrewimm to help keep external platform needs in their respective repos, for rnpm/packager et al.  Seeing as this is a major discussion point, I've made this PR first.  Making small steps towards this goal, seems to be the approved methodology from all.
Additionally, I have a merged PR that makes an excellent place for documenting the CLI when it advances, as preparation for this initiative: (previous PR)
About this PR
We're no stranger to rnpm/react-native link:  This brings that known experience to this platform.

Here is my example: Project ready for linking
Running react-native link

Running react-native link again

The resulting code is available in this branch: Example project linked
Running react-native unlink react-native-win-gif twice

The resulting code is available in this branch: Example project unlinked

Code style
This code is meant to follow the exact style of the previous structures and commands.  For anyone familiar with the existing CLI framework, this should fit accordingly.  There were some new needs for revoke patches that might be worth eventually merging into a shared codebase between Android and C#.

@GantMan I just wanna make sure that we are on the same page wrt ownership. The JavaScript Tools team at FB London owns React Native Packager. rnpm is a community contribution that was merged into react-native and it isn't part of packager. So I'm happy to work with you on all the RNP related things but for rnpm I'm afraid I can't really help that much. Just thought I clear this up in case there is any confusion here. We don't use rnpm at Facebook, so our React Stack team is the one that should be looking at this PR specifically (cc @mkonicek).

Hey @cpojer :)  Yes, sorry to mention you on this.  I'm aware it's unrelated to your direct tasks on packager.  I mentioned you because I'm speaking on the concepts we had mentioned for platforms, since we're all having to think about how to best handle multiple platforms (across RNPM and RNP).  In this sense, I would appreciate enjoy your expertise in theory.   As far as the code, I expect @grabbou and @rozele to chime in.  I've already discussed this PR with them.

the failing test seems unrelated to the changes.  Can some one corroborate?  Looks like CI is failing a lot for even doc update PRs?

Thanks! I'll follow up on this tomorrow. Let's move this discussion onto Slack for faster iteration. Anyone who wants to be in the loop - please let me know. There's going to be a bit of work and by using a synchronous way of communicating we can speed it up!

Thanks @GantMan for the contribution, as I already said via Slack!

Going to merge it, impressive work!
@rozele how do you feel about Windows-specific code finally landing in RN code? :trollface:
Seriously speaking, here's the plan:

Next PR - remove windows related code from this repo and put it inside react-native-windows/local-cli/core/windows so it still mirrors this repo. We merged this one for now to test it faster, get it out faster.
Next PR - make all the getters on rnpm config lazy, so that they don't run when you don't need them. That should significantly speed up the CLI, because who needs the config to run when there's start command running?

@facebook-github-bot shipit


Spelling mistake in docs - Devloper API Reference

We've got a spelling mistake in on the home page of the docs - Devloper API Reference

I would like to work on this one

I have created a pull request, kindly review it.


Question: Why is there a yarn.lock file

Why is there a yarn.lock file? Can it be safely removed?

It's useful only if you use yarn.


Is it a map or random reference?

It would be better for beginners if you could arrange it linearly like a road map to follow.
I know they are very good resources but which one do I start with?
Something like the "road map to web development 2017" will be very nice.

This is a good suggestion. But currently, it is a compilation of some of the best resources. I will surely consider creating a road map styled resource soon.

I will surely love that. thanks
On Thu, May 18, 2017 at 6:43 AM, Aritra Roy<EMAIL_ADDRESS>wrote:

This is a good suggestion. But currently, it is a compilation of some of
the best resources. I will surely consider creating a road map styled
resource soon.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/aritraroy/UltimateAndroidReference/issues/53#issuecomment-302315552,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOI21GrLcnCg7wQax4FrWhqgoUWIKqYKks5r6-iRgaJpZM4Nby1q
.