The fans are noticably louder then on Windows/Linux

The fans are running more often then on other operating systems and they are quite load. I'm not sure is this a problem with my machine or not. Could someone verify that?

The fans are running more often then on other operating systems and they are quite load. I'm not sure is this a problem with my machine or not. Could someone verify that?

 I'm not sure is this a problem with my machine or not. Could someone verify that?

 For example lower the clock speeds or change the fan curve using YogaSMC.

The fans are running more often then on other operating systems and they are quite load. I'm not sure is this a problem with my machine or not. Could someone verify that?

 For example lower the clock speeds or change the fan curve using YogaSMC.

Cpu is terrible. This is my mind.

I've the I7 and after change the thermal paste, fans are very quiet (ah and don't forget to calibrate the cpu usage with CPUFriend)

I have T460s i5, and part of what I like about it is no fan noise and little heat wether running Win10 or Big Sur.  This is compared to my other laptops, 15" MacBook Pro i7 (still on Mojave) and work's T480 i7.  I wish the T460s had the display of the MacBook, but cost was right, and perfect for many situations.  I suspect the i5 is the main difference for this.
I second @alexdelli 's thoughts that your thermal paste may need refreshing or the fan cleaning, especially if yours is i5.

I've the I7 and after change the thermal paste, fans are very quiet (ah and don't forget to calibrate the cpu usage with CPUFriend)

I've tried to create more power saving plan in CPUFriend but without any luck. I'll try to do the repaste and I'll be back with the results.

I have T460s i5, and part of what I like about it is no fan noise and little heat whether running Win10 or Big Sur.  This is compared to my other laptops, 15" MacBook Pro i7 (still on Mojave) and work's T480 i7 (Win10).  I wish the T460s had the display of the MacBook, but cost was right, and perfect for many situations.  I suspect the i5 is the main difference for this.
I second @alexdelli 's thoughts that your thermal paste may need refreshing (or perhaps the fan needs a good cleaning), especially if yours is i5.

I have the i5-6300u. I was even thinking of applying liquid metal to improve the thermals.

I found mine (i7) reasonably silent when room temp is <20°C

I have the i5-6300u. I was even thinking of applying liquid metal to improve the thermals.

Repasting a laptop is always a good idea. I've thought about liquid metal but from what I understood it needs to be redone every year or so.


npm install pcap failed (node-gyp rebuild fails on system)

On Windows 8.1 machine with NodeJS 0.12.7 installed (latest)
I'm quite new to NodeJS, is there any workaround for this?
Thanks!

it looks like you need to install python on that system and set your env variables correctly.
https://docs.python.org/2/using/windows.html

@hortinstein It worked, Thanks a lot! (Can't believe I missed that)

I have the same issue, but I have python installed (v2.7.10), I filed a bug here: https://github.com/mranney/node_pcap/issues/190

@Chris2011 did you try npm config set python C:\Python27\python.exe?

Yes, I think that this was the problem, this ticket was very great and helped me: https://github.com/nodejs/node-gyp/issues/629


change enforcer rule to require jdk version >= jdk11

to avoid compilation errors on lower jdk versions:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project brave-context-jfr:
Compilation failure: Compilation failure:
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[7,15] package jdk.jfr does not exist
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[8,15] package jdk.jfr does not exist
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[9,15] package jdk.jfr does not exist
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[10,15] package jdk.jfr does not exist
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[33,41] cannot find symbol
[ERROR]   symbol:   class Event
[ERROR]   location: class brave.context.jfr.JfrScopeDecorator
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[30,4] cannot find symbol
[ERROR]   symbol:   class Category
[ERROR]   location: class brave.context.jfr.JfrScopeDecorator
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[31,4] cannot find symbol
[ERROR]   symbol:   class Label
[ERROR]   location: class brave.context.jfr.JfrScopeDecorator
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[32,4] cannot find symbol
[ERROR]   symbol:   class Description
[ERROR]   location: class brave.context.jfr.JfrScopeDecorator
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[34,6] cannot find symbol
[ERROR]   symbol:   class Label
[ERROR]   location: class brave.context.jfr.JfrScopeDecorator.ScopeEvent
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[35,6] cannot find symbol
[ERROR]   symbol:   class Label
[ERROR]   location: class brave.context.jfr.JfrScopeDecorator.ScopeEvent
[ERROR] C:\RC\src\brave\context\jfr\src\main\java\brave\context\jfr\JfrScopeDecorator.java:[36,6] cannot find symbol
[ERROR]   symbol:   class Label
[ERROR]   location: class brave.context.jfr.JfrScopeDecorator.ScopeEvent
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :brave-context-jfr

not sure why circleci isn't happy about this, seems like a stackoverflow error somehow.

clicked rebuild without cache. circle will die soon anyway
On Thu, Apr 25, 2019 at 12:53 AM Jorg Heymans<EMAIL_ADDRESS>wrote:

not sure why circleci isn't happy about this, seems like a stackoverflow error somehow.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

thanks!


Pymongo, Issue

Probably an error because pymongo is called from processes
Traceback (most recent call last):
  File "C:/Users/John/PycharmProjects/Hurricane/engine/crawler.py", line 143, in <module>
    crawl = Crawler(1)
  File "C:/Users/John/PycharmProjects/Hurricane/engine/crawler.py", line 85, in __init__
    self.processes[process].start()
  File "C:\Python27\lib\multiprocessing\process.py", line 130, in start
    self._popen = Popen(self)
  File "C:\Python27\lib\multiprocessing\forking.py", line 277, in __init__
    dump(process_obj, to_child, HIGHEST_PROTOCOL)
  File "C:\Python27\lib\multiprocessing\forking.py", line 199, in dump
    ForkingPickler(file, protocol).dump(obj)
  File "C:\Python27\lib\pickle.py", line 224, in dump
    self.save(obj)
  File "C:\Python27\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Python27\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Python27\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python27\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Python27\lib\pickle.py", line 331, in save
    self.save_reduce(obj=obj, *rv)
  File "C:\Python27\lib\pickle.py", line 419, in save_reduce
    save(state)
  File "C:\Python27\lib\pickle.py", line 286, in save
    f(self, obj) # Call unbound method with explicit self
  File "C:\Python27\lib\pickle.py", line 649, in save_dict
    self._batch_setitems(obj.iteritems())
  File "C:\Python27\lib\pickle.py", line 681, in _batch_setitems
    save(v)
  File "C:\Python27\lib\pickle.py", line 306, in save
    rv = reduce(self.proto)
  File "C:\Python27\lib\site-packages\pymongo\collection.py", line 1709, in __call__
    self.__name.split(".")[-1])
TypeError: 'Collection' object is not callable. If you meant to call the '__getnewargs__' method on a 'Collection' object it is failing because no such method exists.

Since i simply switched from processes
class Worker(multiprocessing.Process):

to threads
class Worker(threading.Thread):

i wonder if this is the correct solution and if this project shall start using threads instead of processes


Update option.go for Process param

Solving issues: https://github.com/aliyun/aliyun-oss-go-sdk/issues/80, https://github.com/aliyun/aliyun-oss-go-sdk/issues/95, https://github.com/aliyun/aliyun-oss-go-sdk/issues/109

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Alex Kam seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

You can check for similar PR as in: https://github.com/aliyun/aliyun-oss-go-sdk/pull/88, https://github.com/aliyun/aliyun-oss-go-sdk/pull/96, https://github.com/aliyun/aliyun-oss-go-sdk/pull/99, https://github.com/aliyun/aliyun-oss-go-sdk/pull/105

Coverage decreased (-50.7%) to 40.567% when pulling a42c50887f0558cab5c72071acee35adca067d88 on kavimaluskam:master into 36bf7aa2f916f274137aedd05d1d36f6a3c0f4a6 on aliyun:master.


[Bug] Extension is using way too much memory

https://bugzilla.mozilla.org/show_bug.cgi?id=1708506

Thank you, @unbeatable-101! We will look into that. We are in the process of restructuring the architecture of OptMeowt, and will address this issue along the way.
From the linked thread above:

I could not reproduce the issue on the latest Nightly (90.0a1/20210503214210) under Windows 10 x64.

I tested both with and without the extensions installed (OptMeowt).

Without the extension installed, overall memory usage was around 1.2 GB of RAM with the WebExtensions process spiking to a maximum of 120-150 MB.

With the extensions installed, overall memory usage spiked at around 2.8 GB several times, but returned to around 1.2 GB memory usage (as without the add-on installed). The WebExtensions process spiked to ~300 MB but not more, at the same time the overall memory usage was higher. It returned to under 100 MB when the overall memory usage got lower.

I looked into this issue and running the current OptMeowt build from source on Firefox (90.0.2 (64-bit)) with a few tabs open, including a YouTube video, uses about 600 MB for the whole browser. There do not seem to be any spikes in memory usage. The same for Brave. Maybe, our use of IndexedDB took care of the issue. If the problem comes up again, we can reopen this issue or create a new one.


close #57 rebuild sender screen firstly

I just fix the code, but I need some help, I don't know how to reset Textformfield after click the button send, so now i just show the code and need some help 😁😁

conflicts


C13980: Incorrect bullet point structure

Hello, @MandiOhlinger,
Localization team has reported source content issue that causes localized version to have broken format on en-us version.
Please, help to check my proper if you would like me to fix it in another way within this PR, if you prefer to fix it in another PR, or if I should close this PR as by-design. In case of using another PR, please, let me know of your PR number, so we can confirm and close this PR.
Many thanks in advance.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

biztalk/core/feature-pack-add-build-release-definitions.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Clarify the form and constraints of target_url

OTIO has long used target_url as a way to refer to assets referenced by a timeline (such as media files). However the ruleset for how these URLs are formatted has been "wild west" since the fields to store them are strings.
We should explicitly specify how these urls are formatted. Considerations include:

Convention about URL scheme formatting
Clarifications and examples for the most common use case of file:// urls
Clarifications about percent-encoding
Explicit specification about how to resolve relative URLs to a resource

This work should likely be followed up with some code to assist users in properly constructing and working with these URLs for the common use cases.

I think we should probably follow something like this:
https://restfuljson.org
In a nutshell, string encoding and escaping per: https://tools.ietf.org/html/rfc7159
URL encoding per: https://tools.ietf.org/html/rfc3986
Additional meta-data associated with the media referred to by the URL are specified by https://tools.ietf.org/html/rfc6906

I think in addition to specifying the constraints, we should provide a couple of functions, in C++ and in python, that let you convert from filesystem paths to correctly encoded urls, and back, including support for relative and absolute file paths.  The unit tests alone would benefit from this.
Probably be a good idea to add a test of some kind to otiostat and run it on the .otio files in the repo.  We could also run it in the unit tests when running self.assertJsonEqual() if we wanted to be really thorough.


Add an allowlist?

Sorry if this strays too far from the mission of this project, but it might be nice to add an allowlist to the Python script, as it seems ipsniper (in some shape or fashion) lists domains such as googlevideo.com (used by YouTube), google.com (and some other regional TLDs for it), youtube.com, youtubekids.com.
This doesn't seem to be a bug in your scripts, as they are listed in the original source:

I don't see an easy way to report FPs on their website, or else I would contact them.

Hi, thanks for the suggestion. However, I do not pre-emptively filter out false positives to keep the feeds consistent with upstream, even for obvious ones like "youtube.com".


request: cobalt color scheme

cobalt color scheme rocks my world. is anybody is up for doing it, it'd be really happy. this is such a kick-ass editor! thanks!

Here's the guide if you want to do it yourself. Otherwise I could probably do it, but I'd need an example from another editor or whatever, as I don't know what that looks like.

hopefully this is a good enough reference ^_^
https://emacsthemes.com/themes/cobalt-theme.html I'll buy you a beer if you
can pull it off. thanks!
On Dec 27, 2017 11:27, "sum01"<EMAIL_ADDRESS>wrote:
Here's the guide
https://github.com/zyedidia/micro/blob/master/runtime/help/colors.md#creating-a-colorscheme
if you want to do it yourself. Otherwise I could probably do it, but I'd
need an example from another editor or whatever, as I don't know what that
looks like.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/zyedidia/micro/issues/967#issuecomment-354165331, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAWsgh96CpIz7D8caci_mLqVKt8FAjX8ks5tEpojgaJpZM4RNuyg
.

I'm trying to make it, but I couldn't find docs explaining what the Emacs settings actually translate to, so it's a bit of a guessing game. The Micro docs for colorscheme are also lacking, with only a few things actually explained.

maybe this is of some help?
some definitions
https://github.com/mig/gedit-themes/blob/master/cobalt.xml
a screenshot
https://delightlylinux.files.wordpress.com/2015/03/0_cobalt.gif
thank you again in advance

It seems to me like https://github.com/emacs-jp/replace-colorthemes/blob/master/cobalt-theme.el would also provide some useful information.

If on linux make sure true color is set by below or the colors will be wrong as I found out when testing.
 export MICRO_TRUECOLOR=1

Try below,  just copy to a file named cobalt.micro in to folder ~/.config/micro/colorschemes
# Cobalt color scheme
# Editor colors
color-link default "#F8F8F8,#09223F"
color-link cursor-line "#00162A"
# color-link color-column "#26425D"
color-link statusline "#F8F8F8,#008AFF"
color-link tabbar "#F8F8F8,#008AFF"
color-link indent-char "#F8F8F8,#09223F"
# Line number colour scheme
color-link line-number "#888888,#111111"
color-link current-line-number "#888888,#111111"
# Gutter color scheme
color-link gutter-info "#40FFB9,#09223F"
color-link gutter-error "#FF0000,#09223F"
color-link gutter-warning "#FF518C,#09223F"
# Message color scheme
color-link message "#008AFF,#09223F"
color-link error-message "#FF0000,#09223F"
# Syntax colors
color-link error "bold #FF0000,#09223F"
# comment
color-link comment "#008AFF,#09223F"
# identifier
color-link identifier "#FFDD00,#09223F"
# constant and subgroups
color-link constant "#FF518C,#09223F"
color-link constant.string "#42D915,#09223F"
# statement
color-link statement "#FA9E18,#09223F"
# symbol and subgroups
color-link symbol "#CCCCCC,#09223F"
# color-link symbol.brackets "default"
# preproc and subgroups
color-link preproc "#8090A2,#09223F"
color-link preproc.shebang "#008AFF,#09223F"
# type and subgroups
color-link type "#FFEF79,#09223F"
# special
color-link special "#E9C062,#09223F"
# todo
color-link todo "bold #D33682,#09223F"

thank you so much! close, but there are some minor details, though. i have attached a screenshot here

left window is gedit (for reference). top right window is xterm 322 with "export MICRO_TRUECOLOR=1". bottom right window is xfce4-terminal 0.6.3.
firstly: the background does not appear blue. secondly: line 36: "clear" should appear in orange, but doesn't.
thanks again!
(oh, and please send me your paypal address, so i can shoot you over that beer i promised!)

Looks like the terminal does not use true color, as this is what I got when testing, micro tries to match the closest color match when using 255 colors which looks bad. I will look into line 36 color. No need for payment, happy I could help you. What version of linux and distro are you using so I can test.

I'm on Xubuntu 16.04. i wonder if the theme can be adapted to 256 colors,
instead of true color. what terminal are you using? maybe I should switch
to that instead of using my vanilla, generic terminal. thanks! and please
reconsider accepting my gratitude.

I am using gnome terminal, I can look at a 255 color version, now I know what you are using for testing. I will post results here when I have a working version.

that would be f***ing awesome, dude! ^_^

@tulakalbeyo I am struggling with the background color, can you please look at the color list below and pick a background color.
Link to colors list that can be used in the terminal
The highlighting problem is not with the color scheme but with the syntax file used by micro.
clear and sudo are missing from the list of keywords and there might be more.
If you get a list of missing highlighting commands then I could do a pull request to get them added.

@tommyshem
background color:
xterm #25 (DeepSkyBlue4 | #005f87) <-- this looks good ^_^
syntax highlighting:
keywords = if fi then elif else for do done until while break continue case function return in eq ne ge le
commands = alias apropos awk basename bash bc bg builtin bzip2 cal cat cd cfdisk chgrp chmod chown chroot cksum clear cmp comm command cp cron crontab csplit cut date dc dd ddrescue declare df diff diff3 dig dir dircolors dirname dirs du echo egrep eject enable env ethtool eval exec exit expand export expr false fdformat fdisk fg fgrep file find fmt fold format free fsck ftp gawk gedit getopts git grep groups gzip hash head history hostname id ifconfig import install join kill less let ln local locate logname logout look lpc lpr lprint lprintd lprintq lprm ls lsof make man micro mkdir mkfifo mkisofs mknod more mount mtools mv netstat nice nl nano nohup nslookup open op passwd paste pathchk ping popd pr printcap printenv printf ps pushd pwd quota quotacheck quotactl ram rcp read readonly renice remsync rm rmdir rsync screen scp sdiff sed select seq set sftp shift shopt shutdown sleep sort source split ssh strace su sudo sum symlink sync tail tar tee test time times touch top traceroute trap tr true tsort tty type ulimit umask umount unalias uname unexpand uniq units unset unshar useradd usermod users uuencode uudecode v vdir vi watch wc whereis which who whoami wget xargs yes
thanks!

Try below, just copy to a file named cobalt.micro in to folder ~/.config/micro/colorschemes
# Cobalt color scheme
# Editor colors
color-link default "#FFFFFF,#005f87"
# #09223F
color-link cursor-line "#003b70"
# color-link color-column "#26425D"
color-link statusline "#F8F8F8,#008AFF"
color-link tabbar "#F8F8F8,#008AFF"
color-link indent-char "#F8F8F8,#09223F"
# Line number colour scheme
color-link line-number "#888888,#111111"
color-link current-line-number "#888888,#111111"
# Gutter color scheme
color-link gutter-info "#00BF8C"
color-link gutter-error "#990000"
color-link gutter-warning "#FF518C"
# Message color scheme
color-link message "#0088FF"
color-link error-message "#990000"
# Syntax colors
color-link error "bold #990000"
# comment
color-link comment "#0088FF"
# identifier
color-link identifier "#80ffbb"
color-link identifier.var "#80ffbb"
# constant and subgroups
color-link constant "#ffee80"
color-link constant.string "#42D915"
color-link constant.number "#FF518C"
color-link constant.bool "#42D915"
# statement
color-link statement "bold #FA9E18"
# symbol and subgroups
color-link symbol "#FA9E18"
color-link symbol.bracket "#FA9E18"
# color-link symbol.brackets "default"
# preproc and subgroups
color-link preproc "#80ffbb"
color-link preproc.shebang "#0088FF"
# type and subgroups
color-link type "bold #FA9E18"
# color-link type "bold #80ffbb"
# special
color-link special "bold #ff9d00"
# todo
color-link todo "bold #ffee80"

 # from Gedit cobalt style
 # faded_yellow"                value="#ffee80"/>
 # bright_orange"               value="#ff9d00"/>
 # faded_orange"                value="#ffb054"/>
 # nail_polish_pink"            value="#ff0044"/>
 # neon_pink"                   value="#ffdd00"/>
 # sky_blue"                    value="#0088ff"/>
 # teal_blue"                   value="#80ffbb"/>
 # light_blue"                  value="#0065bf"/>
 # medium_blue"                 value="#003b70"/>
 # dark_blue"                   value="#001b33"/>
 # black_blue"                  value="#000d1a"/>
 # white"                       value="#ffffff"/>
 # pale_grey"                   value="#eeeeee"/>
 # steel_grey"                  value="#333333"/>
 # spring_green"                value="#3ad900"/>
 # sea_green"                   value="#00BF8C"/>
 # light_grey"                  value="#cccccc"/>
 # dark_red"                    value="#990000"/>
 # bluish_grey"                 value="#777777"/>
 # steelblue3"                  value="#4f94cd"/>
 # dark_medium_blue_blend"      value="#00213F"/>

Change color
If there is a color you want to change just look at the link I gave you in the other post and change the # number to that value you want, then save file. (Note in 256 color terminal it might look different in different setup terminal emulators)
Remove color highlighting
If there is a color highlighting you do not want change the color value to "default"
Missing keywords
I will do a pull request to micro editor for the missing keywords later today.
Or you can add them yourself to folder ~/.config/micro/syntax
Make a file called sh.yaml and copy below code.
filetype: shell

detect:
    filename: "(\\.sh$|\\.bash|\\.bashrc|bashrc|\\.bash_aliases|bash_aliases|\\.bash_functions|bash_functions|\\.bash_profile|bash_profile|Pkgfile|pkgmk.conf|profile|rc.conf|PKGBUILD|.ebuild\\$|APKBUILD)"
    header: "^#!.*/(env +)?(ba)?sh( |$)"

rules:
    # Numbers
    - constant.number: "\\b[0-9]+\\b"
      # Conditionals and control flow
    - statement: "\\b(case|do|done|elif|else|esac|exit|fi|for|function|if|in|local|read|return|select|shift|then|time|until|while)\\b"
    - special: "(\\{|\\}|\\(|\\)|\\;|\\]|\\[|`|\\\\|\\$|<|>|!|=|&|\\|)"
      # Shell commands
    - type: "\\b(cd|echo|export|let|set|umask|unset)\\b"
      # Common linux commands
    - type: "\\b((g|ig)?awk|bash|dash|find|\\w{0,4}grep|kill|killall|\\w{0,4}less|make|pkill|sed|sh|tar)\\b"
      # Coreutils commands
    - type: "\\b(base64|basename|cat|chcon|chgrp|chmod|chown|chroot|cksum|clear|comm|cp|csplit|cut|date|dd|df|dir|dircolors|dirname|du|env|expand|expr|factor|false|fmt|fold|head|hostid|id|install|join|link|ln|logname|ls|md5sum|mkdir|mkfifo|mknod|mktemp|mv|nice|nl|nohup|nproc|numfmt|od|paste|pathchk|pinky|pr|printenv|printf|ptx|pwd|readlink|realpath|rm|rmdir|runcon|seq|(sha1|sha224|sha256|sha384|sha512)sum|shred|shuf|sleep|sort|split|stat|stdbuf|stty|sum|sync|tac|tail|tee|test|time|timeout|touch|tr|true|truncate|tsort|tty|uname|unexpand|uniq|unlink|users|vdir|wc|who|whoami|yes)\\b"
      # Conditional flags
    - statement: "--[a-z-]+"
    - statement: "\\ -[a-z]+"

    - identifier: "\\$\\{?[0-9A-Z_!@#$*?-]+\\}?"
    - identifier: "\\$\\{?[0-9A-Z_!@#$*?-]+\\}?"

    - constant.string:
        start: "\""
        end: "\""
        skip: "\\\\."
        rules:
            - constant.specialChar: "\\\\."

    - constant.string:
        start: "'"
        end: "'"
        rules: []

    - comment:
        start: "(^|[[:space:]])#"
        end: "$"
        rules:
            - todo: "(TODO|XXX|FIXME):?"

Add the keywords you need (put | before and after every keyword, but at beginning of first keyword or not on the end of last keyword).
I have put clear in add from there.
Hope this helps you.
Any other problems let me know.

@tommyshem
thank you so much!
i combined your and mine's "coreutils commands"
alias|apropos|awk|base64|basename|bash|bc|bg|builtin|bzip2|cal|cat|cd|cfdisk|chcon|chgrp|chmod|chown|chroot|cksum|clear|cmp|comm|command|cp|cron|crontab|csplit|cut|date|dc|dd|ddrescue|declare|df|diff|diff3|dig|dir|dircolors|dirname|dirs|du|echo|egrep|eject|enable|env|ethtool|eval|exec|exit|expand|export|expr|factor|false|fdformat|fdisk|fg|fgrep|file|find|fmt|fold|format|free|fsck|ftp|gawk|gedit|getopts|git|grep|groups|gzip|hash|head|history|hostid|hostname|id|ifconfig|import|install|join|kill|less|let|link|ln|local|locate|logname|logout|look|lpc|lpr|lprint|lprintd|lprintq|lprm|ls|lsof|make|man|md5sum|micro|mkdir|mkfifo|mkisofs|mknod|mktemp|more|mount|mtools|mv|nano|netstat|nice|nl|nohup|nproc|nslookup|numfmt|od|op|open|passwd|paste|pathchk|ping|pinky|popd|pr|printcap|printenv|printf|ps|ptx|pushd|pwd|quota|quotacheck|quotactl|ram|rcp|read|readlink|readonly|realpath|remsync|renice|rm|rmdir|rsync|runcon|scp|screen|sdiff|sed|select|seq|set|sftp|(sha1|sha224|sha256|sha384|sha512)sum|shift|shopt|shred|shuf|shutdown|sleep|sort|source|split|ssh|stat|stdbuf|strace|stty|su|sudo|sum|symlink|sync|tac|tail|tar|tee|test|time|timeout|times|top|touch|tr|traceroute|trap|true|truncate|tsort|tty|type|ulimit|umask|umount|unalias|uname|unexpand|uniq|units|unlink|unset|unshar|useradd|usermod|users|uudecode|uuencode|v|vdir|vi|watch|wc|wget|whereis|which|who|whoami|xargs|yes
for some reason, i can't get the right colors even in 256 mode :-/ i blame my terminals.
here is a small bug with the syntax highlighting i saw:

it seems that after the first single-mark quote, anything that comes afterwards is interpreted differently, even the # comment character. then, the second single-mark quote is interpreted "correctly" (red arrow), and everything after that is interpreted as another quote.
thanks again!

Delete is code below from the sh.yaml file and it should cure it.
 - constant.string:
        start: "'"
        end: "'"
        rules: []

@tommyshem
it worked!! thank you so much!! and please reconsider my beer offer.. i will be at Southern California Linux Expo (SCALE) this coming march, btw.

how to make the background transparent?(i.e same as terminal)

I just discovered this cobalt colorscheme and it's great!  Why is this not one of the default colorschemes?


Allow to sign outbound for Gas token withdrawAndCall

The gas token outbound would call the function defined in https://github.com/zeta-chain/protocol-contracts/issues/148 and send the gas token as value for the call

No longer relevant: https://github.com/zeta-chain/node/issues/2402


NVS basic tests

Added basic tests for the NVS file system. One of the tests covers power down during the flash write operation.

CC: @nvlsianpu

I would wrap all simulator specific routines in a #ifdef CONFIG_FLASH_SIM (don't know if this exists tough, my knowledge on the flash simulator is limited). This would allow the test also to run on real hardware as well (except of course the test of the write failure).

Yes, that would be feasible provided that we can elicit corrupted write operation on the real hardware in the test. Here it is achieved because the flash simulator doesn't store any data after it executes a certain number of write calls and this number is configured by the test.
This test scenario is supposed to simulate the power loss when the NVS writes to the flash. It is intended to verify the NVS (not the flash drivers underneath), so IMHO running the test on the real hardware doesn't bring much value since all platforms share the same NVS codebase.
Anyway, thanks for the feedback.

I would wrap all simulator specific routines in a #ifdef CONFIG_FLASH_SIM (don't know if this exists tough, my knowledge on the flash simulator is limited). This would allow the test also to run on real hardware as well (except of course the test of the write failure).

Yes, that would be feasible provided that we can elicit corrupted write operation on the real hardware in the test. Here it is achieved because the flash simulator doesn't store any data after it executes a certain number of write calls and this number is configured by the test.
This test scenario is supposed to simulate the power loss when the NVS writes to the flash. It is intended to verify the NVS (not the flash drivers underneath), so IMHO running the test on the real hardware doesn't bring much value since all platforms share the same NVS codebase.
Anyway, thanks for the feedback.

OK, I would rename the PR into: "nvs basic powerfail test"


Change messages and Gherkin parser/pickle compiler to retain step keyword

Summary
Re #768: As discussed, for further discussion, implement a proposal for retention of step keywords Given/When/Then/But/And into the pickle.
Please note that the tests on this PR can't succeed until the test-data has been patched to include the new fields defined in the JSON schema. I'll take that task when the general direction has been decided to be acceptable/refined.
Details
Considerations (summarized from the issue as well as implementation-wise):

Some implementations use keyword-specific dispatching of step functions; without the keyword in the pickle, these implementations can't migrate to Gherkin
The keywords But and And are resolved to the Given/When/Then keywords they inherit their context from, because:

Pickles contain execution plans, i.e. with variables resolved (readily available for execution)
Along the same lines, the But and And keywords have been resolved to eliminate variability in intepretation

The step dispatch environment doesn't have the parser available to determine the meaning of the keyword as mentioned in the parsed document; therefore the GherkinDocument mentions both the keyword from the parsed text (keyword) and the key as it is used in the translations (Given/Then/When/And/But).

Motivation and Context

To allow implementations to move to the Gherkin parser
To retain information currently, literally, "lost in translation"
Strengthen separation of concerns (remove the need to mix parsing, execution and formatting stages)

Screenshots
Not screenshots, but rendered output nonetheless.
(the first scenario of the) AST output from gherkin --predictable-ids --no-source --no-pickles testdata/good/i18n_fr.feature:
{
  "gherkinDocument": {
    "comments": [],
    "feature": {
      "children": [
        {
          "scenario": {
            "description": "",
            "examples": [],
            "id": "3",
            "keyword": "Scénario",
            "location": {
              "column": 3,
              "line": 4
            },
            "name": "Support des caractères spéciaux",
            "steps": [
              {
                "id": "0",
                "keyword": "Soit ",
                "keywordType": "Given",                                        ******
                "location": {
                  "column": 5,
                  "line": 5
                },
                "text": "un exemple de scénario en français"
              },
              {
                "id": "1",
                "keyword": "Quand ",
                "keywordType": "When",                                        ******
                "location": {
                  "column": 5,
                  "line": 6
                },
                "text": "j'ai 1 gâteau"
              },
              {
                "id": "2",
                "keyword": "Alors ",
                "keywordType": "Then",                                       ******
                "location": {
                  "column": 5,
                  "line": 7
                },
                "text": "je suis heureux"
              }
            ],
            "tags": []
          }
        },

And the pickle output for said first scenario (gherkin --predictable-ids --no-source --no-ast testdata/good/i18n_fr.feature):
{
  "pickle": {
    "astNodeIds": [
      "3"
    ],
    "id": "53",
    "language": "fr",
    "name": "Support des caractères spéciaux",
    "steps": [
      {
        "astNodeIds": [
          "0"
        ],
        "id": "50",
        "keyword": "Given",                                                     ******
        "text": "un exemple de scénario en français"
      },
      {
        "astNodeIds": [
          "1"
        ],
        "id": "51",
        "keyword": "When",                                                     ******
        "text": "j'ai 1 gâteau"
      },
      {
        "astNodeIds": [
          "2"
        ],
        "id": "52",
        "keyword": "Then",                                                     ******
        "text": "je suis heureux"
      }
    ],
    "tags": [],
    "uri": "testdata/good/i18n_fr.feature"
  }
}

See the lines with the ****** markers for the new output.
How Has This Been Tested?
It's only lightly tested, because this is mostly for discussion purposes.
Types of changes

[ ] 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 not work as expected).

Checklist:

[x] The change has been ported to Java.
[x] The change has been ported to Ruby.
[ ] The change has been ported to JavaScript.
[ ] The change has been ported to Go.
[ ] The change has been ported to .NET.
[ ] I've added tests for my code.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have updated the CHANGELOG accordingly.

It looks promising 👍
Is the "non-keyword" * missing?
How would you manage the following:
Feature:
  Scenario:
    * first step
    * second step

Yes. The "non-keyword" is missing. If you look at
https://github.com/cucumber/common/pull/1741/files#diff-c07661832329db6cbfc36ea70c7dde480191c281e6e134531ef7b7638d144cfbR182
you'll see that the * keyword isn't being considered in the current Perl implementation of the Gherkin parser, which is why I overlooked it. There's no failure in the parser's test suite, which makes me wonder: is * still a supported keyword? Or is it there in some implementations for backward compatibility?

Yes. The "non-keyword" is missing. If you look at
https://github.com/cucumber/common/pull/1741/files#diff-c07661832329db6cbfc36ea70c7dde480191c281e6e134531ef7b7638d144cfbR182
you'll see that the * keyword isn't being considered in the current Perl implementation of the Gherkin parser, which is why I overlooked it. There's no failure in the parser's test suite, which makes me wonder: is * still a supported keyword? Or is it there in some implementations for backward compatibility?

Good question for our community meeting 😁

is * still a supported keyword? Or is it there in some implementations for backward compatibility?
Good question for our community meeting grin

So, in preparation of that meeting, I took a stab at the Ruby parser, trying to find whether it supports the * non-keyword. I found:
https://github.com/cucumber/common/blob/main/gherkin/ruby/lib/gherkin/token_matcher.rb#L120-L124
which suggests that it also doesn't. So, definitely something to discuss!

My take on the "*" keyword is that when using it, the step should be allowed to match step definitions defined with all of "Given", "When", and "Then".
From the original discussions of "unambiguous keywords", I think I remember the view that defining both step definitions for "Given " and "When " should (still?) be an error, so the keywords in the pickles should rather be for verifying the keyword of the step definition, than for selecting one of several candidates of step definitions.

As long as the "* " keyword is defined in the gherkin-languages.json is is supported, isn't it?

The keywords But and And are resolved to the Given/When/Then keywords

I would suggest deferring this to a the cucumber implementation. It's non trivial, especially with *  keyword is used. The pickle may also be used in representations in which case it would be confusing to see it replaced.

This is how *  keyword is supported: https://github.com/cucumber/common/blob/main/gherkin/gherkin-languages.json#L4 shows that *  is a translation/dialect for the And keyword.

It looks like '*' is supported in some Cucumber Rubys (I tried it in 4.0.0)
By converting the actual keyword used in the scenario into G/W/T in the pickle, we lose the ability to reconstitute the scenario as written
There's nothing to prevent a scenario starting with a conjunction (And / But)

This is how *  keyword is supported: https://github.com/cucumber/common/blob/main/gherkin/gherkin-languages.json#L4 shows that *  is a translation/dialect for the And keyword.

Yeah
Actually it is a translation for all given/when/then/and/but keyword.
I guess it fallback as "Given" if needed?

On the other hand, we realized with @sebrose that treating * just as a simple synonym of And is not perfect... e.g. a scenario with only * steps might be valid on the other hand having a scenario with only Ands does not look good...
So if we do this change it would be good if we could semantically detach the * from the Ands...

By converting the actual keyword used in the scenario into G/W/T in the pickle, we lose the ability to reconstitute the scenario as written

I think the intent was to have this as well as the verbatim keyword, not instead?

The "* " is a valid keyword for Given, When, Then, And, But (see gherkin-languages.json). So any parser that passes the test supports "* " (see this ast.ndjson). Currently its not a problem that "* " is a valid keyword for all types, but when converting to G/W/T then the question of how to convert "* " occurs. My suggestion in that case, it should be converted to the "*" type (which would be valid for all step definitions).

@gasparnagy writes:

On the other hand, we realized with @sebrose that treating * just as a simple synonym of And is not perfect... e.g. a scenario with only * steps might be valid on the other hand having a scenario with only Ands does not look good...

I'd agree that a scenario of pure conjunctions (And / But) doesn't look good. However, if I'm understanding correctly the way Cucumber Ruby/Java work now, it's still allowed. To that extent, I'd say that the argument @mpkorstanje and @mattwynne (?) made to leave the intepretation of the keywords to the actual executor and not hard-code it in the Pickle compiler, does allow the executor to object to scenarios like these (or simply assume "* ").

So if we do this change it would be good if we could semantically detach the * from the Ands...

I think that if I change the PR to have the same fields keyword and keywordType in PickleStep the way it's now done in the Step, with the addition of the new keywordType * (in addition to the keywordTypes Given/When/Then//And/But), the code will be able to handle all comments made so far.

We can map *, And and But to Ambiguous

@mattwynne I disagree with that * is mapped the same way And and But. The current meaning of And and But is "the same as the previous step". But that is currently not the meaning of *, as it is a valid keyword for Given, When, Then, And and But.

I like the abstraction of phase suggested my @mattwynne. What about these?

Context -- like Given
Action -- like When
Outcome -- like Then
Conjunction or Inherited -- like And and But
Step -- for the *

But that is currently not the meaning of *, as it is a valid keyword for Given, When, Then, And and But.

Good point. In fact we might find (now or in the future) that there are other strings mapped in the gherkin language spec that could be mapped back to more than one keyword.

But that is currently not the meaning of *, as it is a valid keyword for Given, When, Then, And and But.

Good point. In fact we might find (now or in the future) that there are other strings mapped in the gherkin language spec that could be mapped back to more than one keyword.

Assuming that more of these exist today, should all of these be mapped to "General" in that case? Doing so will at least give us the desired behaviour for *  without special-casing.

Based on the comments above, I've updated the PR for further discussion. The output of the AST now looks like:
{
  "gherkinDocument": {
    "comments": [],
    "feature": {
      "children": [
        {
          "scenario": {
            "description": "",
            "examples": [],
            "id": "3",
            "keyword": "Scénario",
            "location": {
              "column": 3,
              "line": 4
            },
            "name": "Support des caractères spéciaux",
            "steps": [
              {
                "id": "0",
                "keyword": "Soit ",
                "keywordType": "Context",
                "location": {
                  "column": 5,
                  "line": 5
                },
                "text": "un exemple de scénario en français"
              },
              {
                "id": "1",
                "keyword": "Quand ",
                "keywordType": "Action",
                "location": {
                  "column": 5,
                  "line": 6
                },
                "text": "j'ai 1 gâteau"
              },
              {
                "id": "2",
                "keyword": "Alors ",
                "keywordType": "Outcome",
                "location": {
                  "column": 5,
                  "line": 7
                },
                "text": "je suis heureux"
              }
            ],
            "tags": []
          }
        },

And the pickle output:

  "pickle": {
    "astNodeIds": [
      "3"
    ],
    "id": "53",
    "language": "fr",
    "name": "Support des caractères spéciaux",
    "steps": [
      {
        "astNodeIds": [
          "0"
        ],
        "id": "50",
        "keyword": "Soit ",
        "keywordType": "Context",
        "text": "un exemple de scénario en français"
      },
      {
        "astNodeIds": [
          "1"
        ],
        "id": "51",
        "keyword": "Quand ",
        "keywordType": "Action",
        "text": "j'ai 1 gâteau"
      },
      {
        "astNodeIds": [
          "2"
        ],
        "id": "52",
        "keyword": "Alors ",
        "keywordType": "Outcome",
        "text": "je suis heureux"
      }
    ],
    "tags": [],
    "uri": "testdata/good/i18n_fr.feature"
  }
}

Note that the pickle now has the keywordType field as well as the keyword field with the same values as present in the Step in the GherkinDocument. The code currently specializes *, but that's work in progress: I think that all keywords that a dialect associates with more than one step keyword (given/then/when/and/but), should have the "General" keywordType associated, based on the discussion above. That will be part of a further update to this PR.

With this latest commit, we don't need to restructucture gherkin-languages.json. It will extract all translations ("dialect words") that are associated with more than one step keyword and declare that translation to then be in the "General" group. Because "* " has been associated with all keywords, it automatically goes into the "General" type without special-casing it in the code.

@gasparnagy Like yours. My only suggestion is "Any" for "*"

@gasparnagy Like yours. My only suggestion is "Any" for "*"

@luke-hill , given that the comment above, I'd say that "Unspecified" may be a good value, because it won't be just mapped to by "* ", but all keywords having more than one association with Given/Then/When/But/And. ("Unspecified" is better than "Unknown", because actually the keyword type is known, but it's not a strict mapping to a single type).

I'd say that "Unspecified" may be a good value, because it won't be just mapped to by "* ", but all keywords having more than one association with Given/Then/When/But/And.

I think what we want to say here is that these are neutral to whether they belong to the context, action or outcome. So it is specified and we say that it is neutral. If in the future there will be a new keyword that works as Given and When, but not as Then, we would anyway need to create a new category for that.
I think the point is that the processing logic should be able to make decisions based on the keyword_type without checking the concrete keyword. (So we don't want to have the *  constant in the code.)
From this perspective, Any or General might be better IMHO.

What about having gherkinKeywords as an array, and list all the "root" keywords that the string used in the parsed document maps back to? Maybe a bit too low level?

@mattwynne I don't understand your proposal. Could you please give an example?

Adjustments I'll make to this PR:

Change the enum in the Pickle as per your last comment
Add translation of But/And to the preceeding keyword in the pickle compiler
Rename the "keywordType" field in the Pickle to type

@aslakhellesoy does that encompass all change you intended to ask for?

The latest push rebases on top of current origin/main and adds the changes requested by @aslakhellesoy.

@mattwynne I don't understand your proposal. Could you please give an example?

In gherkin-languages.json in the entry for the en language, the translations for the "given" keyword are "Given "  and "* ". For the "when" keyword they are "When " and "* ", etc.
I was suggesting, though I think the conversation has moved on, that we simply model this mapping in the keywordType field, so if the user puts a * as their step keyword, we write the pickle's keywordType as an array of all those map keys in the language object, i.e.
{
  ...
  "keyword": "*",
  "keywordTypes": [ "and", "but", "given", "when", "then" ]
  ...
}
```

In most cases, there will be only one entry in the `keywordTypes` array, but for a keyword that has an ambiguous / general mapping there will be more than one entry.

The CI is failing because the Step.keywordType and PickleStep.type are defined as "required" in the json schema.
Yet the gherkin implementation has not been updated accordingly.
Do we need those properties to be mandatory? Doing so will make the implementation of the keyword retention more difficult

The CI is failing because the Step.keywordType and PickleStep.type are defined as "required" in the json schema. Yet the gherkin implementation has not been updated accordingly.
Do we need those properties to be mandatory? Doing so will make the implementation of the keyword retention more difficult

Just tested locally: removing the keyword type from the "required" attributes make the build go further.
It would be more easier to move on incrementally with this feature without those new fields to be required

When we add a new field, it should never be marked as required. This is to ensure forward compatibility: Consumers using a new version of the lib can still process messages produced by an old version of the lib.

When we add a new field, it should never be marked as required. This is to ensure forward compatibility: Consumers using a new version of the lib can still process messages produced by an old version of the lib.

Maybe this is a bridge too perfect, but: I'd expect schemas to adhere to semantic versioning similar to the way libraries do: new APIs/fields lead to new version numbers, which, when not backward compatible, leads to a new version number. While schemas and input parsers need to be forward compatible by ignoring any unknown data that's provided but not recognized, the software to parse the input data could be made backward compatible by recognizing the schema version of the data provided and e.g. treating keywordType as optional or even ignore it - thereby supporting (mimicing) older versions.
Having said that, I'll agree that it's probably an approach that 's too complex to maintain long-term for the amount resources available to the project. In which case, yes, the best solution is to mark these fields as optional.
There is a bit of a problem that I'm left with after that conclusion though: for e.g. the Perl implementation of Cucumber that I maintain, I'll need the keywordType and corresponding type fields (on the step and picklestep respectively) to be provided. What declaration/level of conformance would an implementation require to be guaranteed that type of input?

@ehuelsmann There's a slight semver complexity in both Gherkin and Messages, in that the major version will get bumped when API changes happen in the various implementations, without it reflecting a backwards compatibility break in the serialisation format
For instance, Gherkin is very broadly backwards compatible since 6.0 but the libraries have changed methods, etc, so the major version increases.
I think if you want to require the new fields for cucumber-perl:

messages supports the new fields from a particular version X
gherkin to always populates the fields from version Y
cucumber-perl requires messages >=X gherkin >= Y
cucumber-perl checks the fields are populated and shows an appropriate error message if not (which won't really happen, it's only if someone's feeding it gherkin from a different source than the correct gherkin-perl version)

Maybe this is a bridge too perfect, but: I'd expect schemas to adhere to semantic versioning similar to the way libraries do: new APIs/fields lead to new version numbers, which, when not backward compatible, leads to a new version number. While schemas and input parsers need to be forward compatible by ignoring any unknown data that's provided but not recognized, the software to parse the input data could be made backward compatible by recognizing the schema version of the data provided and e.g. treating keywordType as optional or even ignore it - thereby supporting (mimicing) older versions.
Having said that, I'll agree that it's probably an approach that 's too complex to maintain long-term for the amount resources available to the project. In which case, yes, the best solution is to mark these fields as optional.

There is a bit of a problem that I'm left with after that conclusion though: for e.g. the Perl implementation of Cucumber that I maintain, I'll need the keywordType and corresponding type fields (on the step and picklestep respectively) to be provided. What declaration/level of conformance would an implementation require to be guaranteed that type of input?

Actually, the generated code issue from the schema will set fields that are not marked as "required" with default values. Thus the field is always there and have a correct value next in the stack
It is then up to gherkin to manage exception if the data is missing in the source being parsed, which is already the case I guess. The "required" attribute in the schema does not mean a "required" field in the gherkin syntax.

Let's assume I have a server that always uses the latest version of messages. This server parses messages sent to it, and these messages can be produced by many different versions of messages (different cucumber versions).
If a message field is required in the new version, the code in the server will not check whether it has a value or not. Checking if a field is null is only done for fields that are not required.
So the server might blow up, because it receives an old message that doesn't set the (newly) required field. This is what I mean by forward compatibility.
This is explained in more detail here

Had to force-push after rebasing on main, resolving conflicts due to the Java JSON changes.

Forced pushed to base this on the messages-retain-keyword branch, which factors out of this branch, the change solely to messages.

Updating the go part requires modifying dialects_builtin.go.jq - which is really hard to understand. I'm trying to grok it, but it might take some time...

I've figured out how to update the jq code generator, but only if we can make a step keyword correspond to a single keyword type. The current implementation assumes a step keyword can correspond to multiple keyword types.
This is because the following languages uses some keywords in multiple places:

en-old (Old English) uses Tha, Þa and Ða for both given and when
ne (Nepalese) uses अनी for both then and and
uz (Uzbek) uses Агар for both given and when

Without being a native speaker of any of them, I think it might be a mistake to have this duplication. In order to move this forward I propose that we modify the 3 languages in question to not have duplicated keywords:

en-old given becomes þæt, þæs, þæm (Old English Translator)
ne and becomes अनि (Google Translate)
uz and becomes Va, Esa, Ham (Google Translate)

It's of course possible that this is wrong. In that case, the community will let us know. These languages will probably not be used a lot, so hopefully it will not affect many users. In fact, we're not removing any keywords, so everything will probably just work as before.

@aslakhellesoy thanks for looking into that. If we agree that the mapping needs to be unique for all keywords other than *  (as you're proposing above), then the code on the other implementations can be (a bit) simpler too. So, I'm definitely :+1: on that. Maybe we should add a check to the test-suite to enforce it?

Maybe we should add a check to the test-suite to enforce it?

The Go code won't compile if keywords are duplicated, so I think that's a good enough protection for now.

@ehuelsmann The suggestion of @aslakhellesoy about single keyword to type match makes the whole thing much simpler, because in this case, the step keyword type does not have to be represented on the token (the step keyword type can be queried any time based on the keyword as now this is a singular match), but only in the pickle.
I added the code to make the .NET pass (I hope), but my suggestion is that we completely remove the step type from the token and also from the token tests (test data files).

PHP is green 🎉

@ehuelsmann The suggestion of @aslakhellesoy about single keyword to type match makes the whole thing much simpler, because in this case, the step keyword type does not have to be represented on the token (the step keyword type can be queried any time based on the keyword as now this is a singular match), but only in the pickle.

@gasparnagy, thanks for your review. The lookup of the keyword can be simplified now that we have 1-to-1 correspondence, indeed. However, I considered what would happen without the keywordType in the Step object. If we would go with that design, we'd need access to the Dialect everywhere that a lookup is required. Currently, the dialect is only available to the parser, at least in the languages that I changed the code on. That's what made me decide to have the keywordType in the Step object.

I added the code to make the .NET pass (I hope), but my suggestion is that we completely remove the step type from the token and also from the token tests (test data files).

Hmm. How about the need to access the Dialect then?

@ehuelsmann my suggestion was not to remove it from the "Step", but to remove it from the token.
I don't know about the other platforms, but the token in the .NET implementation has a reference to the dialect. With that the keyword type can be calculated for the "Step" in the AST builder.

@gasparnagy Sorry for the misunderstanding. Indeed, I now see that the token has the dialect in the languages that I ported this to (checked Perl and Java). The only reason to keep it as it is, then, is because at token match time, we're already finding out which keyword it is, or at least, it's really easy to: in Java, all keywords used to be lumped into a single array followed by an "exists in array" check for the potential step keyword. By going through each of the sets separately, instead of lumping them into one, we already know what the keyword type is and don't need to do the lookup later.
I did consider adding a method to the dialect to look up a keyword and return its keyword type. However, that doesn't work well with the JS implementation, where the dialect is a simple value map (js object), without any methods.

I don't know why your commits do not trigger the CI @gasparnagy 🤔

Thanks a lot @brasmusson for the python implem 🤩
Still dunno why dotnet is failing 🤔👀

@aurelien-reeves I look at the dotnet one today. It is strange because if I make the .NET tests pass, the ones that check the result with make/jq fail, but if I try to satisfy those, the others start to fail. Probably some rsync problem. So far I tried to save the efforst of setting up a work make-comatible work env locally, but I think I can't do it further without it... :(

@ehuelsmann I understand your argument about the performance and convenience thing. I don't know. I was never good at such a cleanness vs convenience/performance decisions, so I leave it up to you.
My original vision was that the "token" is a generic concern. It contains fields that are generally available of most token types, like generic "keyword", "text", or "items". So far we did not have any specific field that is only valid for a single token type, like the "keyword type" would be (because that makes only sense for step tokens).
If we really would like to represent this at the token level, then probably the clean solution would be to split the "step line" token type to "context step line", "action step line", etc. But that would be a bigger change and it would also require to change the grammar and all the token matchers... I don't know...

Oh my, it seems it is green 🤩🎉
I guess next steps are:

update the branch to merge incoming commits from main
set it "ready for review"
having a last call for discussion/objection
merge it :)

Well, do we have some documentation to update beside the changelog?

Well, do we have some documentation to update beside the changelog?

All that's going on here really is the implementation of a change in messages, which was documented in a prior PR. I'd expect all we need to do is to do the changelog item -- all other documentation is in the messages definitions (and there, we have some debt to repay, but that was true far before this PR).

Last call for discussion and/or objection
Are we good? Can we merge? Are we still waiting for something else?


Implement vm_to_constrained in PIL or at least make more use of PIL's new features

Rust code inside vm_to_constrained.rs should be reduced and moved to be implemented in PIL instead.
This is more of a brainstorming issue to see if it's possible at all.
The syntax can of course stay exactly as it is now, but instead of transforming the asm syntax into PIL directly, we should transform it into a set of functions that do the actual conversion as part of the evaluator / condenser.
This is roughly how it could look, for example:
// The whole machine is inside a closure, so we can create an instance of it by calling it.
let vm_machine = || {
  let machine = Machine{...};
  // "reg pc[@pc]" is replaced by:
  // this is the column. We need this to exist by that name in this namespace because directly written pil code references it.
  // It is also referenced in the `default_update` field. We could also use a function for default_update that receives the column as input.
  let pc;
  let machine = add_register(machine, Register{column: pc, name: "pc", conditioned_updates = [], default_update = Some(pc + 1)};
  // reg X[<=];
  let X;
  let machine = add_register(machine, Register{column: X, name: "X",  conditioned_updates = [], default_update = None});

  // instr jump l: label { pc' = l }
  let machine = add_instruction(machine, Instruction{name: "jump", inputs: [Input::Label()], outputs: [], constraints: [|input1| pc' = input1]});

  // instr mload Y -> X, Z { ... }
  let machine = add_instruction(machine, Instruction{name: "mload", inputs: [Y], outputs: [X, Z], constraints: [...]});

  machine.create()
};

This would be cool!


added missing dependency for eslint-config-prettier

I've added eslint-config-prettier to the boilerplates since it was failing on missing dependency.
eslint-config-prettier is defined as peer dependency in eslint-config-react-union

Thank you for the fix!


Remove Ruby version constraint from the gemspec

Hello,
we would love to use this gem to validate JSON payloads on-failure in our gem, jsonapi_parameters. This gem provides a simple way to consume JSON:API compliant inputs in Ruby, with Rails support included. You can read more about the standard here: https://jsonapi.org
Sadly, we are facing an issue where choosing json_schemer as the validation engine would mean that we would have to give up support for Ruby 2.4. While we are aware that this Ruby version has reached its EOL, we would rather not limit our users to specific Ruby versions unless it is required by the gem's logic.
Because of that we are currently seeing three scenarios:

either exporting the validation as a plug-in (so the validation part would be excluded out of JsonApi::Parameters gem and instead be provided as a complementary gem),
leave it as it is in the current state (PR link: https://github.com/visualitypl/jsonapi_parameters/pull/45), thus give up for Ruby versions below 2.5.0,

and, the third scenario is: reaching out and asking whether its possible (and if not - what is the reason for this decision) to remove the constraint in json_schemer that enforces Ruby versions above 2.4.0. This is the path that we decided to choose first.
Commit link: https://github.com/davishmcclurg/json_schemer/commit/8cbd5ccf4ce4eaa11d75ffa1518340fc6b437e52#diff-6f69d521c8f547072ea493be84d7a52eL23-R23

IMHO with Ruby 3 just a few months to go, let’s nudge people towards using  newer Ruby versions. 🚀

IMHO with Ruby 3 just a few months to go, let’s nudge people towards using newer Ruby versions.

Why? Why forcing people to update their well-working scripts, gems, programs would be the way to go?
Ruby is an open-minded community, and while Ruby 3 is great, I do not share an opinion of forcing anybody to upgrade their Ruby version solely because there's a newer one.
Ruby version requirement should be dictated by the need of the language functionalities, not because of language creators' support.
New applications should indeed be written in the highest Ruby versions possible, but please allow users that already have their use-cases covered to have their application still working without having to upgrade everything just so they can validate their JSON inputs.

@Marahin Alright. Sounds plausible.

we would love to use this gem to validate JSON payloads on-failure in our gem, jsonapi_parameters.

Sounds great!

and, the third scenario is: reaching out and asking whether its possible (and if not - what is the reason for this decision) to remove the constraint in json_schemer that enforces Ruby versions above 2.4.0. This is the path that we decided to choose first.

I originally enforced Ruby 2.5 because 2.4 is EOL and I'd like to use some of the features in 2.5. Would it work for you to pin your dependency on an older version of the gem? I believe 0.2.11 works on Ruby 2.4. In fact, bundler should pick up that version when running on 2.4.

@davishmcclurg  indeed we could pin down to the version before the Ruby 2.5 dependency was introduced, but this way we are giving up on the new features, fixes and changes in your library, such as more precise errors: https://github.com/davishmcclurg/json_schemer/issues/1
So while this would indeed allow us to include and use json_schemer, it:

creates another issue (what about new features? We are locking ourselves to one specific version),
already by the time its introduced will be outdated

I'd like to use some of the features in 2.5

This is a super valid point, but are there any features that json_schemer is making use of right now? If yes, then this indeed discards our request and is a great argument behind setting this dependency up.

This is a super valid point, but are there any features that json_schemer is making use of right now?

I think you're right that there aren't any. I was thinking of some things I changed when I dropped 2.3.

but this way we are giving up on the new features, fixes and changes in your library, such as more precise errors: #1

That's true. I'm open to supporting 2.4 again since it shouldn't require any other changes. How long do you plan to support it? I don't have a good sense for people's expectations on these types of things.
Please open a PR with the changes, if you can.

Merged 2.4 support and released in 0.2.14.


Match Sublime and TextMate version?

After looking into #47 + #51, it seems that this theme uses the Solarized colors but the syntax highlighting in base.less is different to other Solarized ports like for Sublime or TextMate.
For example a generic .variable in Atom's version uses @cyan, but it's @blue in Sublime/TextMate. Might be a good idea to match it in Atom too. Then we shouldn't need to override it for every language separately because people make issues like the above.
So instead of
.variable { color: @cyan; } // base.less

.source.coffee .variable { color: @blue; } // coffee.less
.source.java .variable { color: @blue; } // java.less
.source.javascript .variable { color: @blue; } // javascript.less
.source.go .variable { color: @blue; } // go.less
// etc.

change to
.variable { color: @blue; } // base.less

It would be a (big) change for people that got used to the Atom version and that use a language that doesn't get overridden. But I think matching the base styles to what Sublime/TextMate are using would benefit all the users that switch over to Atom or are used to these versions. And less overriding should be needed.
@schmittyjd How do you feel about it?

@simurai could be a smart move. I initially started contributing because the javascript highlighting was poor and did not match my vim setup. Knowing that most people coming to atom were likely using sublime or textmate before I can see the benefit of keeping our theme familiar to those editors. That may mean more changes overall but I'm for it! Besides if I personally don't like how some of the colors are I can just tweak them in my own styles file (yay for atom!)


feature/update types

changes

fix types ParseData
update version
update typedocs

Pull Request Test Coverage Report for Build 171

1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 94.952%

Totals

Change from base Build 168:
0.0%

Covered Lines:
654

Relevant Lines:
680

💛  - Coveralls


Add search APIs: search by TitleCreatorYear or search by Tag

I'm a user of Zotero-Link Plugin. I encountered Search Accuracy Issue and I tried the solution proposed by this comment, which solved my problem.
Zotero-Bridge‘s original search API uses "quicksearch-everything" search mode provided by ZotServer Search Endpoint. In this Pull Request, I added to two more search APIs that uses "quicksearch-titleCreatorYear" and "tag"  search modes of ZotServer, respectively. These new APIs can be used by Zotero-Link to provide different search modes.

Hi @jungle-gym-ac
Thanks for your interest and sorry for the late reply (1 year is some time...)
I think this change will also require corresponding implementation in Zotero Link to make use of those new endpoints.
I would be interested to hear more how do you use those endpoints in your setup and what value do they provide?
On a side note: I have just updated the bridge with an option to use built-in Local API in Zotero 7, which I am very hopeful will solve the search accuracy problem.


index.html favicon updated

Updated favicon.
Report for an update if any.

i had assigned it to you please create your pull request.

i had assigned it to you please create your pull request.

Okay, thanks.


Creating a new Table with expanded cells

I'm creating a Table with expanded cells. I wrote it without ktx:
Table().apply {
  setFillParent(true)

  add(TextButton("Tutorial", skinny).apply {
    onClick { doSomething() }
  }).expand()

  row()

  add(TextButton("Play", skinny).apply {
    onClick { doSomething()
  }).expand()
}

Trying to use ktx for it, I could not access the cells that were created, to call expand() on.
Any ideas?
By the way, thanks for a great library!

Check the Scene2D examples section. You can access the table cells in two ways:
// 1. Widget's building block lambda parameter:

table {
  button {
    it.expand()
  }
  button { cell ->
    cell.expand()
  }
}

// 2. `cell` extension method:

table {
  button().cell(expand = true)
  button {
    // ...
  }.cell(expand = true)
}

I missed it in the docs. Thanks!


Proper absolute import app loading with ROOT_DIR structure change

Hello!
Working on a project loosely based on the arrangement that created the config directory at project root.
Does this mean in apps that are referencing modules in other apps, the absolute path you'd use has changed from:
from <app_name>.models import <Model>

To:
from <project_name>.<app_name>.models import <Model>

A little wordy, but not too bad! I wanted to double check I'm going about it right before I go too far down that path.

@rdmurphy the new import always need be from the top of the root. This to avoid any kind of confusion w.r.t PYTHON_PATH. The new import need to be in the form from <project_name>.<app_name>.models import <Model>.
That said, you can are now free to add apps/modules on the top level of directory if you prefer, but that would be your way of logically organising your project and it's different modules.
The idea behind this change is that your Django apps are nothing but yet another python module and they should not get any special privileges.

Thanks @theskumar! Makes sense.


PHP8.0 - select best method for extension installs

There are a few possibilities to install packages under PHP8.0
PECL (as per PHP7.x)
This (prior to previous info) is now included in PHP8.0 - although not all modules are published to PECL in Nov 2020
RUN pecl channel-update pecl.php.net \
    && yes '' | pecl install -f apcu-5.1.19
RUN docker-php-ext-enable apcu

Pickle (https://github.com/FriendsOfPHP/pickle)
RUN pickle install -n apcu-5.1.19
RUN curl -L https://api.github.com/repos/imagick/imagick/tarball > /tmp/imagick.tar.gz \
    && tar xzvf /tmp/imagick.tar.gz -C /tmp \
    && cd /tmp/Imagick-imagick* \
    && pickle install -n --version-override=3.4.99
RUN docker-php-ext-enable apcu imagick

Pickle shows promise, but at the time of release didn't have a stable version that allowed version-overrides
docker-php-source
RUN docker-php-source extract \
    # ext-imagick
    && mkdir -p /usr/src/php/ext/imagick \
    && curl -fsSL https://api.github.com/repos/imagick/imagick/tarball | tar xvz -C /usr/src/php/ext/imagick --strip 1 \
    && docker-php-ext-install imagick \
    # cleanup
    && docker-php-source delete
RUN docker-php-ext-enable imagick

Handy reference - https://mediatemple.net/community/products/dv/204644340/installing-pecl-extensions

using PECL


Missing map_fim_emif_axi_mm_to_GROUP_local_mem.sv with ofs-fim EA

Hi
We are running into the following compilation error for a PR/PIM build when using the latest revision of ofs-platform-afu-bbb:
[...]
+ RELEASE_NAME=dummy_release
+ mkdir -p ../dummy_release/hw/lib/platform/platform_db
+ mkdir -p ../dummy_release/hw/lib/build/platform
++ abspath ../dummy_release
++ python -c 'import os, sys; print(os.path.realpath(*sys.argv[1:]))' ../dummy_release
+ DUMMY_RELEASE=/net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release
+ PLATFORM_INI=../design/top/stratix10/pac_N5010pr/pac_N5010pr.ini
+ echo pac_N5010pr
+ /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/ofs-platform-afu-bbb/plat_if_develop/ofs_plat_if/scripts/gen_ofs_plat_json -c ../design/top/stratix10/pac_N5010pr/pac_N5010pr.ini /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/platform/platform_db/pac_N5010pr.json
Parsing configuration defaults file: /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/ofs-platform-afu-bbb/plat_if_develop/ofs_plat_if/src/config/defaults.ini
Parsing configuration file: ../design/top/stratix10/pac_N5010pr/pac_N5010pr.ini
Found CCI-P
Found local memory
+ /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/ofs-platform-afu-bbb/plat_if_develop/ofs_plat_if/scripts/gen_ofs_plat_if -c ../design/top/stratix10/pac_N5010pr/pac_N5010pr.ini -q -t /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/build/platform/ofs_plat_if
    Preserving /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/build/platform/ofs_plat_if/rtl/ifc_classes/host_chan/prims/gasket_ea_ofs_fim
Traceback (most recent call last):
  File "/net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/ofs-platform-afu-bbb/plat_if_develop/ofs_plat_if/scripts/gen_ofs_plat_if", line 312, in <module>
    main()
  File "/net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/ofs-platform-afu-bbb/plat_if_develop/ofs_plat_if/scripts/gen_ofs_plat_if", line 299, in main
    gen_fim_interface()
  File "/net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/ofs-platform-afu-bbb/plat_if_develop/ofs_plat_if/scripts/gen_ofs_plat_if", line 186, in gen_fim_interface
    group_num=group_num, verbose=args.verbose)
  File "/net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/ofs-platform-afu-bbb/plat_if_develop/ofs_plat_if/scripts/platlib/gen_ofs_class_if.py", line 82, in copy_class
    os.path.join(tgt, tgt_subdir))
  File "/usr/lib/python2.7/distutils/dir_util.py", line 163, in copy_tree
    verbose=verbose, dry_run=dry_run))
  File "/usr/lib/python2.7/distutils/dir_util.py", line 163, in copy_tree
    verbose=verbose, dry_run=dry_run))
  File "/usr/lib/python2.7/distutils/dir_util.py", line 167, in copy_tree
    dry_run=dry_run)
  File "/usr/lib/python2.7/distutils/file_util.py", line 156, in copy_file
    _copy_file_contents(src, dst)
  File "/usr/lib/python2.7/distutils/file_util.py", line 44, in _copy_file_contents
    fdst = open(dst, 'wb')
IOError: [Errno 2] No such file or directory: '/net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/build/platform/ofs_plat_if/rtl/ifc_classes/local_mem/prims/gasket_fim_emif_axi_mm/map_fim_emif_axi_mm_to_GROUP_local_mem.sv'

And the file doesn't seem to exist:
❯ ls -l /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/build/platform/ofs_plat_if/rtl/ifc_classes/local_mem/prims/gasket_fim_emif_axi_mm/map_fim_emif_axi_mm_to_GROUP_local_mem.sv
ls: cannot access '/net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/build/platform/ofs_plat_if/rtl/ifc_classes/local_mem/prims/gasket_fim_emif_axi_mm/map_fim_emif_axi_mm_to_GROUP_local_mem.sv': No such file or directory
❯ ls -l /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/build/platform/ofs_plat_if/rtl/ifc_classes/local_mem/prims/gasket_fim_emif_axi_mm/
ls: cannot access '/net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/build/platform/ofs_plat_if/rtl/ifc_classes/local_mem/prims/gasket_fim_emif_axi_mm/': No such file or directory
❯ ls -l /net/fs01/fpga_build/CBS/FPGA/syntese/iofs-clean/obj/synth_pr/dummy_release/hw/lib/build/platform/ofs_plat_if/rtl/ifc_classes/local_mem/prims/
total 16
-rw-rw-r-- 1 1011 fb 5583 jun 29 08:32 ofs_plat_avalon_mem_if_user_ext.sv
-rw-rw-r-- 1 1011 fb 7758 jun 29 08:32 ofs_plat_axi_mem_if_user_ext.sv

The change seems to have happened in one of the following two commits:
https://github.com/OPAE/ofs-platform-afu-bbb/commit/e9b058369537bef8b1fbb3cca3c23f9020c71cb1
https://github.com/OPAE/ofs-platform-afu-bbb/commit/0e1183407e717e5a0cf9c4493633139f79edadee
Is it clear to you what the error is here and if we need to change something in our build scripts?
We are using ofs-fim (EA) 0.7.1 but adapted to the Silicom N5010 platform
https://github.com/otcshare/ofs-fim/releases/tag/0.7.1.-d5005-21.4

@chrbirks - Please share the pac_N5010pr.ini file you are using to configure the PIM. Given the state of your .../local_mem/prims/ directory, I suspect you are defining multiple memory groups, one with Avalon and another with AXI interfaces. I can imagine how the most recent changes might have a bug if that is true.

Here is the content of pac_N5010pr.ini
And yes, it defines DDR4 mem with Avalon, and HBM and eSRAM with AXI.
;; Platform Interface Manager configuration
;;

[define]
native_class=none
PLATFORM_FPGA_FAMILY_S10=1
PLATFORM_FPGA_PAC=1
PLATFORM_FPGA_PAC_LC=1

[clocks]
native_class=none
pclk_freq=250

[host_chan]
native_class=native_axis_pcie_tlp

;; Minimum number of outstanding flits that must be in flight to
;; saturate bandwidth. Maximum bandwidth is typically a function
;; of the number flits in flight, indepent of burst sizes.
max_bw_active_flits_rd=512
max_bw_active_flits_wr=256

;; Recommended number of times an AFU should register host channel
;; signals before use in order to make successful timing closure likely.
suggested_timing_reg_stages=0

;; DDR4 interfaces
[local_mem]
native_class=native_avalon
;; Ideally, num_banks would be ofs_fim_emif_cfg_pkg::NUM_LOCAL_MEM_BANKS.
;; Unfortunately, some PIM scripts need to know the actual number of banks,
;; making it impossible to use SystemVerilog package values.
num_banks=2
addr_width=ofs_fim_emif_cfg_pkg::AVMM_ADDR_WIDTH
data_width=ofs_fim_emif_cfg_pkg::AVMM_DATA_BASE_WIDTH
ecc_width=ofs_fim_emif_cfg_pkg::AVMM_ECC_WIDTH
burst_cnt_width=ofs_fim_emif_cfg_pkg::AVMM_BURSTCOUNT_WIDTH
suggested_timing_reg_stages=2

;; HBM lower bottom and top, mapped into a single vector
[local_mem.1]
native_class=native_axi
num_banks=32
;; The PIM always expects the address width to be configured without byte offset
addr_width=ofs_fim_hbm_cfg_pkg::HBM_LINE_ADDR_WIDTH
data_width=ofs_fim_hbm_cfg_pkg::HBM_DATA_WIDTH
;; The PIM is always configured in Avalon-style one-based burst count width
burst_cnt_width=ofs_fim_hbm_cfg_pkg::HBM_AVMM_BURSTCOUNT_WIDTH
user_width=ofs_fim_hbm_cfg_pkg::HBM_USER_WIDTH
rid_width=ofs_fim_hbm_cfg_pkg::HBM_ARID_WIDTH
wid_width=ofs_fim_hbm_cfg_pkg::HBM_AWID_WIDTH
suggested_timing_reg_stages=2

;; ESRAM interface
[local_mem.2]
native_class=native_axi
num_banks=16
;; The PIM always expects the address width to be configured without byte offset
addr_width=ofs_fim_esram_cfg_pkg::ESRAM_IP_ADDR_WIDTH
data_width=ofs_fim_esram_cfg_pkg::ESRAM_IP_DATA_WIDTH
user_width=ofs_fim_esram_cfg_pkg::ESRAM_IP_USER_WIDTH
suggested_timing_reg_stages=0

;; Ethernet, QSFP interfaces
[hssi]
native_class=native_axi_mac
num_channels=ofs_fim_eth_if_pkg::NUM_QSFP
has_clkdiv2=0

I believe this is fixed by https://github.com/OPAE/ofs-platform-afu-bbb/commit/45fd7c4459ae19e1d2bdf4caf47d4495ebaeec2a

That seemed to fix the problem so I'll close this again. Thanks for the quick fix.


Versioned documentation

Versioned documentation
Project: https://github.com/prometheus/docs/projects/1
Preview: https://pr851.preview.prometheus.io/
This PR provides the necessary changes to the docs page generator in order to load additional documentation pages from other repositories/branches. The content will be cloned from specified repositories in nanoc.yaml. Links in these pages will be normalized to work inside the docs project. It's assumed the documentation pages include the standard nanoc config options and set :title and optionall :sort_rank.
Proposed workflow
I'd propose to first port all the existing Prometheus 1.x documentation over to prometheus/prometheus before starting to adding Prometheus 2.x documentation, as it'll make it easier to see the diff of changes and what needs to change at all.
There is a branch docs in the prometheus repository, either open a PR against that branch or just commit directly into it with your modifications. If applicable, do the same against the branch afterwards to remove/adjust any ported documentation pages.

I updated the description, this PR can now be viewed on https://pr851.preview.prometheus.io/. It won't automatically rebuild as of yet, will add this.

Awesome. The docs structure is obviously not perfect yet (e.g. alerting rules would live in Prom), but I assume the plan is to improve that after getting the basic facilities in place.
:+1: besides fixup comments.

Ah, happy to move /docs/alerting/rules/ to prometheus/prometheus as well. Does it make sense to have that under querying/ actually? recording rules are there, but than neither creating recording nor alerting rules sounds like a querying concept to me. Maybe configuration/{???,recording rules,alerting rules}. Not sure how to rename the current configuration page though.


Deduplicate distributors announce membership

https://github.com/kubernetes/k8s.io/pull/346 added declarative group management for distributors-announce, but in doing so duplicated the member list and work to add a new member. Rather than trying to keep the lists in sync, let's just use the configuration as the source of truth.
We lose the "organization" column, but I think it's obvious from the email domains. If there is concern about this, I can open a PR to add a comments to the configuration with the organization name.
/cc @cblecker @dims

YAML comments would be fine if you wanted to add them

/assign @cblecker

/lgtm

/approve