Error parsing time with time zone directly from string

I was looking for the functionality that is requested exactly in #6. The answer was that one can use the "zzzz" format like:
ZonedDateTime("2015-08-06T22:25:31+07:00", "yyyy-mm-ddTHH:MM:SSzzzz")

But if I copy and paste this example exactly, I get
julia> ZonedDateTime("2015-08-06T22:25:31+07:00", "yyyy-mm-ddTHH:MM:SSzzzz")
ERROR: ArgumentError: Non-digit character encountered
 in getslot at dates/io.jl:143
 in parse at dates/io.jl:158

Did this used to work and some change in base broke it? I don't see any code/documentation in this repo or in base about the "zzzz" format.
Using Julia 0.4.5 and TimeZones 0.1.2

The example you gave should work:
julia> using TimeZones

julia> ZonedDateTime("2015-08-06T22:25:31+07:00", "yyyy-mm-ddTHH:MM:SSzzzz")
2015-08-06T22:25:31+07:00

Could you run the following and give me your output?
versioninfo()
Pkg.status("TimeZones")
Pkg.test("TimeZones")

You are correct in that there is missing documentation for the TimeZones formats Z and z. I'll try to get around to dealing with that soon.
The code that deals with parsing/formating ZonedDateTimes is in "src/timezones/io.jl" which is extending the code found in Base's "dates/io.jl".

Interesting, no, that example doesn't work on my system.
julia> versioninfo()
Julia Version 0.4.5
Commit 2ac304d* (2016-03-18 00:58 UTC)
Platform Info:
  System: Linux (x86_64-redhat-linux)
  CPU: Intel(R) Xeon(R) CPU E5-2697 v2 @ 2.70GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Sandybridge)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.3

julia> Pkg.status("TimeZones")
 - TimeZones                     0.1.2

julia> Pkg.test("TimeZones")
INFO: Testing TimeZones
ERROR: LoadError: LoadError: test error in expression: ZonedDateTime("1942-12-25T01:23:45+0100","yyyy-mm-ddTHH:MM:SSzzz") == ZonedDateTime(dt,fixed)
ArgumentError: Non-digit character encountered
 in getslot at dates/io.jl:143
 in parse at dates/io.jl:158
 in anonymous at test.jl:90
 in do_test at test.jl:50
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:320
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:320
 in process_options at ./client.jl:280
 in _start at ./client.jl:378
 in getslot at dates/io.jl:143
 in parse at dates/io.jl:158
 in anonymous at test.jl:90
 in do_test at test.jl:50
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:320
 in include at ./boot.jl:261
 in include_from_node1 at ./loading.jl:320
 in process_options at ./client.jl:280
 in _start at ./client.jl:378
while loading /home/username/.julia/v0.4/TimeZones/test/timezones/io.jl, in expression starting on line 24
while loading /home/username/.julia/v0.4/TimeZones/test/runtests.jl, in expression starting on line 25
=====================================================================================[ ERROR: TimeZones ]=====================================================================================

failed process: Process(`/apps/julia-0.4.5/bin/julia --check-bounds=yes --code-coverage=none --color=yes /home/username/.julia/v0.4/TimeZones/test/runtests.jl`, ProcessExited(1)) [1]

==============================================================================================================================================================================================
ERROR: TimeZones had test errors
 in error at ./error.jl:21
 in test at pkg/entry.jl:803
 in anonymous at pkg/dir.jl:31
 in cd at file.jl:22
 in cd at pkg/dir.jl:31
 in test at pkg.jl:71

It appears that the slotparse method provided by TimeZones isn't being used. Could you run the following code on your system?
julia> using TimeZones

julia> methods(Base.Dates.slotparse)
# 5 methods for generic function "slotparse":
slotparse(slot::Base.Dates.Slot{Base.Dates.Month}, x, locale) at dates/io.jl:123
slotparse(slot::Base.Dates.Slot{Base.Dates.Millisecond}, x, locale) at dates/io.jl:131
slotparse(slot::Base.Dates.Slot{Base.Dates.DayOfWeekSlot}, x, locale) at dates/io.jl:132
slotparse(slot::Base.Dates.Slot{Base.Dates.TimeZone}, x, locale) at ~/.julia/v0.4/TimeZones/src/timezones/io.jl:31
slotparse(slot, x, locale) at dates/io.jl:121

Sure:
julia> methods(Base.Dates.slotparse)
# 5 methods for generic function "slotparse":
slotparse(slot::Base.Dates.Slot{Base.Dates.Month}, x, locale) at dates/io.jl:123
slotparse(slot::Base.Dates.Slot{Base.Dates.Millisecond}, x, locale) at dates/io.jl:131
slotparse(slot::Base.Dates.Slot{Base.Dates.DayOfWeekSlot}, x, locale) at dates/io.jl:132
slotparse(slot::Base.Dates.Slot{Base.Dates.TimeZone}, x, locale) at /home/username/.julia/v0.4/TimeZones/src/timezones/io.jl:31
slotparse(slot, x, locale) at dates/io.jl:121

I'm not sure what's going on still. Let's try a different test:
df = Dates.DateFormat("yyyy-mm-ddTHH:MM:SSzzzz")
Dates.slotparse(df.slots[end], "+07:00", "english")

For sure, thanks for sticking with me.
julia> df = Dates.DateFormat("yyyy-mm-ddTHH:MM:SSzzzz")
Base.Dates.DateFormat(Base.Dates.Slot[Base.Dates.DelimitedSlot{Base.Dates.Year}(Base.Dates.Year,'y',4,"-"),Base.Dates.DelimitedSlot{Base.Dates.Month}(Base.Dates.Month,'m',2,"-"),Base.Dates.DelimitedSlot{Base.Dates.Day}(Base.Dates.Day,'d',2,"T"),Base.Dates.DelimitedSlot{Base.Dates.Hour}(Base.Dates.Hour,'H',2,":"),Base.Dates.DelimitedSlot{Base.Dates.Minute}(Base.Dates.Minute,'M',2,":"),Base.Dates.DelimitedSlot{Base.Dates.Second}(Base.Dates.Second,'S',2,"zzzz")],"","english")

julia> Dates.slotparse(df.slots[end], "+07:00", "english")
ERROR: ArgumentError: Non-digit character encountered
 in slotparse at dates/io.jl:121

No problem. I want to get to the bottom of this too.
Hmm, that is definitely something. "zzzz" slot is being treated as if the TimeZones package hasn't extended Base.Dates. Can you start a new Julia REPL and run:
julia> Dates.DateFormat("SSzzzz")
Base.Dates.DateFormat(Base.Dates.Slot[Base.Dates.DelimitedSlot{Base.Dates.Second}(Base.Dates.Second,'S',2,"zzzz")],"","english")

julia> using TimeZones

julia> Dates.DateFormat("SSzzzz")
Base.Dates.DateFormat(Base.Dates.Slot[Base.Dates.FixedWidthSlot{Base.Dates.Second}(Base.Dates.Second,'S',2),Base.Dates.DelimitedSlot{Base.Dates.TimeZone}(Base.Dates.TimeZone,'z',4,r"(?=\s|$)")],"","english")

Yes, that appears to be right:
julia> Dates.DateFormat("SSzzzz")
Base.Dates.DateFormat(Base.Dates.Slot[Base.Dates.DelimitedSlot{Base.Dates.Second}(Base.Dates.Second,'S',2,"zzzz")],"","english")

julia> using TimeZones

julia> Dates.DateFormat("SSzzzz")
Base.Dates.DateFormat(Base.Dates.Slot[Base.Dates.DelimitedSlot{Base.Dates.Second}(Base.Dates.Second,'S',2,"zzzz")],"","english")

Very strange issue. Looks like we have at least isolated it to the DateFormat constructor. I'm speculating this may have something to do with SLOT_RULE. Here is something else to try:
using TimeZones
Base.Dates.keys(Dates.SLOT_RULE)
Base.Dates.SLOT_RULE['t'] = Dates.Millisecond
Dates.DateFormat("SSttt")

I may need to make myself a redhat VM to solve  this...

julia> using TimeZones

julia> Base.Dates.keys(Dates.SLOT_RULE)
11-element Array{Char,1}:
 'E'
 'H'
 'M'
 'S'
 'U'
 'd'
 'e'
 'm'
 's'
 'u'
 'y'

julia> Base.Dates.SLOT_RULE['t'] = Dates.Millisecond
Base.Dates.Millisecond

julia> Dates.DateFormat("SSttt")
Base.Dates.DateFormat(Base.Dates.Slot[Base.Dates.FixedWidthSlot{Base.Dates.Second}(Base.Dates.Second,'S',2),Base.Dates.DelimitedSlot{Base.Dates.Millisecond}(Base.Dates.Millisecond,'t',3,r"(?=\s|$)")],"","english")

Well I'm still not sure why the issue exists but I believe I can fix it.
I believe the example you gave will work if you run the following code:
using TimeZones
Base.Dates.SLOT_RULE['z'] = TimeZone
Base.Dates.SLOT_RULE['Z'] = TimeZone
ZonedDateTime("2015-08-06T22:25:31+07:00", "yyyy-mm-ddTHH:MM:SSzzzz")

... but it will not work with this code:
using TimeZones
import Base.Dates: SLOT_RULE
SLOT_RULE['z'] = TimeZone
SLOT_RULE['Z'] = TimeZone
ZonedDateTime("2015-08-06T22:25:31+07:00", "yyyy-mm-ddTHH:MM:SSzzzz")

If I'm right this could be a bug in Base.

Strangely, they both work, and identically produce
julia> ZonedDateTime("2015-08-06T22:25:31+07:00", "yyyy-mm-ddTHH:MM:SSzzzz")
2015-08-06T22:25:31+07:00

Good to know. I'll do some thinking about this and hopefully we can solve this permanently

I believe we have discovered a bug in Julia! Or at least a suboptimal behaviour.
TimeZones is not precompileable, so when I attempt to using it in a package with __precompile__(), that precompilation will fail:
julia> using Foo
INFO: Precompiling module Foo...
INFO: Recompiling stale cache file /Users/ericdavies/.julia/lib/v0.4/Foo.ji for module Foo.
WARNING: Module TimeZones uuid did not match cache file
  This is likely because module TimeZones does not support  precompilation but is imported by a module that does.
ERROR: __precompile__(true) but require failed to create a precompiled cache file
 in require at ./loading.jl:268

However, it will still precompile TimeZones (which I can see by noting that ~/.julia/lib/v0.4/TimeZones.ji has been created). When I quit Julia and load TimeZones again, the "side-effects" (updating Base.Dates.SLOT_RULE) of the module load will not take place because it will load TimeZones.ji, the precompiled version.
If you remove ~/.julia/lib/v0.4/TimeZones.ji you should get the correct behaviour. @omus is working on making TimeZones precompileable so that this is solved permanently.

@micahjsmith I think your issue should be solved now. Can you try the following?
Pkg.checkout("TimeZones", "master")
using TimeZones
ZonedDateTime("2015-08-06T22:25:31+07:00", "yyyy-mm-ddTHH:MM:SSzzzz")

@omus Awesome, that solves the problem -- great detective work. No errors now with the ZonedDateTime constructor.

Glad we solved it. @iamed2 thanks for coming up the precompilation theory. I'll make a new release shortly that includes the fix.


add run_lint to Jenkinsfile

Signed-off-by: Andrea Gunderson<EMAIL_ADDRESS>

Did we figure out what the Unable to create directory /.pylint.d message is from?


create preview and print S3 methods

here are print and preview methods that give more flexibility on how the output object can be used and allows for new users to create their own classes to build off of these. it also should answer the feature request that @MilesMcBain had.

Thanks. I have not forgotten about this. I just was in the middle of a pretty major refactor when this came in which has now be merged with master. I also sort of want to build out S3 methods for the whole package and get more organized for future development so, while this may work great, it's sort of a bit ahead of where we're at currently. I will keep it open and revisit it after I do the S3 work though, which I'm hoping will be this week.

With #31 done, we might want to take the preview = TRUE argument and the ... passthrough to texPreview out and implement a preview() S3 function like the one here. (We're probably too far past this PR, but with the other S3ization, adding preview ourselves should hopefully not be too difficult)

Addressed by #34.


Added indexFiles and fileExtensions options.

Added indexFiles and fileExtensions options for allowing more fine-grained config over the served files, focused on esm loading in the browser (importing folders or extensionless files) but not limited to that.

I have added issue #24 which describes this PR.


feat: Auto add repo upon Github/Gitea Webhook

@ramunasd Now I have understood what you meant, I would also update this PR accordingly.

I have now updated the PR

please run composer test before submitting PR
looks like github CI does not work ATM

All tests are green now. ✅


Added the get_info call and basic example

The getinfo() call.  I went ahead and added an example project using it just to have a nice, simple example for basic Hello World usage in case someone is starting with a fresh LND node that doesn't have any invoices present.  In that case, the other example won't produce any output.

@daveajones This looks great! But I think there are extra commits included in this PR. Shouldn't  it just be the 5cda and a05c ones? I might be mistaken.

Ugh. That’s my fault. Will resubmit.


Decoupling Html/Form Helper Package

I've a plan to decouple or have an option to use the Html/Form Helper or not.

Hi Guys, I'm planning to get rid the Html/Form helper totally.
Do you think it will help you? or should I have an option for Html/Form helper as well?

Don't get rid of the helper totally, It makes scaffolding easier. Having an option for it would be better. I personally would still want to use the helper

Yeah, I have plan for that even more flexible customization. User can use any helper package their own now. I'm working on it :) check the develop branch

In my opinion the Html/Form Helper could be removed completely, but if some other users want to keep it, it's surely better to have an option for it ;)
Will it also be possible to exclude Twitter Bootstrap code by an option in the new version you are developing?
I used to use some custom stubs each time when I installed the crud-generator to get rid of the Html/Form Helper and Twitter Bootstrap code: https://github.com/johnnydoe82/appzcoder-crud-generator-stubs
But in newer versions my version doesn not work completely anymore and there are some really "dirty" hacks I did in lack of better knwoledge of package programming on my behalf...
But maybe there are some areas where I can help somehow with the new version? Please let me know :)

@johnnydoe82 I've no plan to decouple the bootstrap codes yet, but if you can help in anyway then you're always welcome :)

Implemented


Export: more fixes for changing the filename when format changed (#718)

Further fixes to the on_export_format_changed junk.

When exporting using the Python console in master, it will fail if passing export_format= because context.space_data.active_operator is None, and on_export_format_changed does not handle that. Further defensive checks have been added to prevent this. (I've also checked that #1281 did not regress.)
The hack with bpy.ops.file.filenum was replaced with setting context.space_data.params.filename, which is much cleaner. This is thanks to batFINGER's answer to my question on Blender SE.

@donmccurdy @julienduroure @emackey

Since this is a bugfix, will it be backported to the 2.92 branch?

I will backport and merge with blender repo tonight

Done!


Updates to the JSON Schema - symlinks and root description

update $comment symlinks
update root description

This PR assumes we will follow OAS and Overlay in providing $comment metadata in the schema which points to symlinks on the spec site.
symlinks need to be updated on the main openapis.org site to support the changes here:

#289

Should be merged after #289 and the resulting publishing PR in the OAS repo.

@jeremyfiel please remove the JSON representation

it's been removed in #286


feat(@angular-devkit/build-angular): add custom postcss plugin support

PR Checklist
Please check to confirm your PR fulfills the following requirements:

[ x] The commit message follows our guidelines: https://github.com/angular/angular-cli/blob/main/CONTRIBUTING.md#-commit-message-guidelines
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[x ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] Other... Please describe:

What is the current behavior?
Currently including user PostCSS plugins into the Angular build process is not easily accomplished. This PR intends to fix that.
What is the new behavior?
This commit adds seamless custom PostCSS plugin inclusion to the Angular build process, with minimal changes to the angular-cli source.
Adding a postcss plugin is now as easy as,

Installing the plugin package (e.g. npm install postcss-nested)

Adding the package name to angular.json postcssPlugins
e.g.

        .
        .
        .
        "styles": [
          "src/styles.scss"
        ],
        "postcssPlugins": [
          {
            "packageName": "postcss-nested",
            "options": {
              "bubble": []
            }
          }
        ],
        .
        .
        .

Does this PR introduce a breaking change?

[ ] Yes
[ x] No

Other information

very good feature, would love to use it, because previous versions of angular have limitations


import/named does not report non-existent exports in yarn workspace

https://github.com/jd2rogers2/eslint-plugin-import-bug-minimal-repo for testing it for yourself
as seen above, no report for import/named despite not having an helloFooV2 export from foo/index.js
foo and bar are both separate workspaces, bar lists foo as a dependency, and foo is in node_modules
i would expect it to report
maybe a larger issue as there is also https://github.com/benmosher/eslint-plugin-import/issues/1832

Hey @jd2rogers2 , I encountered a similar false positive error in my project and managed to fix it with the following:

change exports in foo workspace to ES6 exports (same for imports in bar)
add 'import/ignore': ['!^@my'], under settings in eslint configuration. You're extending airbnb-base config, which has defined custom import/ignore settings: https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb-base/rules/imports.js#L26. So you need to override those, because yarn workspaces are installed in node_modules (in your case under @my folder.

@Skidle thanks for taking a look!
i'm not so sure it's because of the airbnb extension though
here i remove the extension and just use the plugin and rule directly, and still eslint . does not report

@jd2rogers2 yes, since my comment I realized that it happens with or withour airbnb plugin. If you don't use airbnb config, import/ignore will be node_modules by default, effectively ignoring yarn workspaces too.
So you need to add 'import/ignore': ['!^@my'], to ignore anything that's not your workspace.

@Skidle still no luck on my end :(
i tried out your solution here but i don't get any eslint reports for the import that i expect should receive an error
were you testing in your own repo or by cloning down mine? if you're working in another project would love to be able to find out the differences somehow
and thanks again for you help and time on this!

@jd2rogers2 you need also to change require to import from in bar.js. Works for me here :)

I've just encountered this and was able to determine that the existence of the "import/resolver" key, even if the value is just an empty object, is what's causing import/named to not detect invalid imports.
Still working on figuring out how to get it working with an import/resolver, but that should give some clue.


Fix range (WIP)

This should work, but I can't run tests locally because of some weird bugs.

Is there a youtrack issue for this?

@alissapajer Yep, https://slamdata.myjetbrains.com/youtrack/issue/qz-2625.

I'm still concerned about the lack of double coercion, but we'll have to loop back to that.


Issue with underscore in both name and value of enumerated parameter

Using the below spec, I get the error:
parameter 'start_time: recorded_at' is not found within the URI template '/api/devices/{imei}{?start_time}' for 'Device'

I have found that it works properly with an underscore in either the parameter name or the example value. It only seems to fail when there is an underscore in both places.
FORMAT: 1A

# API

## Device [/api/devices/{imei}{?start_time}]
A device resource

+ Parameters

    + start_time: recorded_at (enum[string], optional)

        QWERTY

        + Members
            + `recorded_at`
            + `created_at`

_ is reserved character because it has a meaning in markdown so if you wan to use it in parameter name you need escape it using backticks. See the fixed API Blueprint below it does not produce any warning or error.
FORMAT: 1A

# API

## Device [/api/devices/{imei}{?start_time}]
A device resource

+ Parameters

    + `start_time`: `recorded_at` (enum[string], optional)

        QWERTY

        + Members
            + `recorded_at`
            + `created_at`

Thanks @w-vi, that works for me.


keylime_agent broken for non-x86_64 architectures due to libefivar.so not being available

Environment

OS / version: Fedora 32
Processor architecture: PowerPC64
TPM Manufacturer: ST Micro (?)
Keylime version: today's master (1766957a748140d6040df70f)

Description
The keylime_agent fails to start on ppc64. The needed package providing the library is not available on this platform.
# keylime_agent
Using config file /etc/keylime.conf
Traceback (most recent call last):
  File "/usr/local/bin/keylime_agent", line 11, in <module>
    load_entry_point('keylime==0.0.0', 'console_scripts', 'keylime_agent')()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 489, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2852, in load_entry_point
    return ep.load()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2443, in load
    return self.resolve()
  File "/usr/lib/python3.8/site-packages/pkg_resources/__init__.py", line 2449, in resolve
    module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/local/lib/python3.8/site-packages/keylime/cmd/agent.py", line 9, in <module>
    from keylime import keylime_agent
  File "/usr/local/lib/python3.8/site-packages/keylime/keylime_agent.py", line 37, in <module>
    from keylime.tpm.tpm_main import tpm
  File "/usr/local/lib/python3.8/site-packages/keylime/tpm/tpm_main.py", line 26, in <module>
    from keylime import tpm_bootlog_enrich
  File "/usr/local/lib/python3.8/site-packages/keylime/tpm_bootlog_enrich.py", line 50, in <module>
    efivarlib_functions = CDLL(efivarlib)
  File "/usr/lib64/python3.8/ctypes/__init__.py", line 373, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: libefivar.so: cannot open shared object file: No such file or directory

Expected behavior vs. actual behavior
keylime_agent should work
Steps to reproduce problem

See above

@maugustosilva It seems that requiring libefivar just for tpm_bootlog_enrich() means it gets pulled in for the agent, which we don't want. Can we change tpm_main to dynamically load tpm_bootlog_enrich  just in calls to parse_binary_bootlog? This should remove the need for the agent to depend on a lib it doesn't use.

On Fedora efivar-libs-37-14 has this content
$ rpm -q --list efivar-libs
/usr/lib/.build-id
/usr/lib/.build-id/e5
/usr/lib/.build-id/e5/7a921d131d6238a68eab784c1847e9831f3234
/usr/lib/.build-id/f8
/usr/lib/.build-id/f8/d95982f367c6cc0eea3b7c22b62d285c46f106
/usr/lib64/libefiboot.so.1
/usr/lib64/libefiboot.so.1.37
/usr/lib64/libefivar.so.1
/usr/lib64/libefivar.so.1.37

Only efivar-devel has the symlink /usr/lib64/libefivar.so but this one is typically not installed.
$ rpm -q --list efivar-devel
[..]
/usr/lib64/libefiboot.so
/usr/lib64/libefivar.so
[...]

also see: https://fedora.pkgs.org/33/fedora-x86_64/efivar-libs-37-14.fc33.x86_64.rpm.html
and here: https://fedora.pkgs.org/33/fedora-x86_64/efivar-devel-37-14.fc33.x86_64.rpm.html
So, on Fedora you may have try to to load libefivar.so.1 and if that fails short-out the rest of tpm_bootlog_enrich.py. This would then probably also solve it for other architectures that do also not have the library.
I installed both of these libraries now on a Fedora 33 system with SeaBIOS and it doesn't affect the start of keylime_agent.


Add names and colormaps (via LayerDataTuple) to the output layers

The plugin implements 3 different decompositions. Applying colormaps to the output decompositions makes them easier to interpret (and stand out more vs. the data).
PCA and ICA return both positive and negative values, so it makes sense to visualize using a diverging colormap. napari implements PiYG, which is colorblind-safe, so that one is used by default.
NMF specifically does not return negative values, so viridis a uniform, colorblind-safe colormap is used by default.
Also, the layers are named explicitly.

Hi Peter @psobolewskiPhD,
This implementation make total sense to me, good idea!
I also like the flexibility of the LayerDataTuple return annotation.
I can confirm the changes work here.
Best,
Marcelo


Broken link in https://docs.getdbt.com/guides/best-practices/materializations/4-incremental-models

Contributions

[X] I have read the contribution docs, and understand what's expected of me.

Link to the page on docs.getdbt.com requiring updates
https://docs.getdbt.com/guides/best-practices/materializations/4-incremental-models
What part(s) of the page would you like to see updated?
does in fact exist in dbt
Additional information
broken link

hey @MaratAbdullaev ! great catch and thank you for opening up this issue! I've spun up a pr to fix these links so we'll get this correct as soon as we can ✨.


Rework market factories to use full parameters

We pack market creation into bytes32 but we do not have to. Instead we should remove the encode/decode methods and take the full parameters.
One HUGE advantage: we can now take full team names instead of IDs. This is crucial for the MMA markets because every player is a "team" and the ID mapping would be onerous. But it's also useful for all sports markets.

Done.


[2023-07-06T22:10:39Z ERROR cadency_core::response] Failed to submit response: Unknown interaction

When the user tries to use the /play command the bot answers with ':x: Couldn't add audio source to the queue!'.
The console response in case it's useful:
[2023-07-06T22:10:39Z INFO  cadency_core::handler::command] ⚡ Execute 'play' command
[2023-07-06T22:10:39Z ERROR cadency_core::response] Failed to submit response: Unknown interaction
thread 'tokio-runtime-worker' panicked at 'Unable to submit deferred info: Response', cadency_core/src/handler/command.rs:49:26
stack backtrace:
0:     0xaaaea6bcce20 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7e7f1aaafc0cf2d2
1:     0xaaaea6beff4c - core::fmt::write::h0b028505b82bc0c1
2:     0xaaaea6bc6c84 - std::io::Write::write_fmt::h956aa06f020dbeed
3:     0xaaaea6bccc2c - std::sys_common::backtrace::print::h1432c0d35b51f06d
4:     0xaaaea6bce6e8 - std::panicking::default_hook::{{closure}}::he3709b970919b674
5:     0xaaaea6bce42c - std::panicking::default_hook::h06f450223d1a38ba
6:     0xaaaea6bced70 - std::panicking::rust_panic_with_hook::h4c5a2c369298e1bc
7:     0xaaaea6bceb50 - std::panicking::begin_panic_handler::{{closure}}::h5a80bba510c18577
8:     0xaaaea6bcd2b0 - std::sys_common::backtrace::__rust_end_short_backtrace::ha6d29e38acd9daf6
9:     0xaaaea6bce894 - rust_begin_unwind
10:     0xaaaea55c8b4c - core::panicking::panic_fmt::hb2f2a43d40c93c4f
11:     0xaaaea55c8d34 - core::result::unwrap_failed::h3dfded8c0af49953
12:     0xaaaea589c61c - core::result::Result<T,E>::expect::h8fcddbc33f9ca5df
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/result.rs:1070:23
13:     0xaaaea589f974 - <cadency_core::handler::command::Handler as serenity::client::event_handler::EventHandler>::interaction_create::{{closure}}::ha92a2286a927bcca
at /home/opc/youtube-bot/cadency_core/src/handler/command.rs:44:21
14:     0xaaaea58a6784 - <core::future::from_generator::GenFuture as core::future::future::Future>::poll::h8403737604239269
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/future/mod.rs:91:19
15:     0xaaaea5e6ca38 - <core::pin::Pin as core::future::future::Future>::poll::h04e453e202f01728
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/future/future.rs:124:9
16:     0xaaaea5b78d88 - serenity::client::dispatch::handle_event::{{closure}}::{{closure}}::{{closure}}::h8956950b4af0da37
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/serenity-0.11.6/src/client/dispatch.rs:744:77
17:     0xaaaea5ff486c - <core::future::from_generator::GenFuture as core::future::future::Future>::poll::h61691f27a311ded1
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/future/mod.rs:91:19
18:     0xaaaea5e6e0a0 - <core::pin::Pin as core::future::future::Future>::poll::hbe84908c390bb004
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/future/future.rs:124:9
19:     0xaaaea60ad0a4 - tokio::runtime::task::core::Core<T,S>::poll::{{closure}}::h8bbd6042a3d524ce
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/core.rs:311:17
20:     0xaaaea5cc6978 - tokio::loom::std::unsafe_cell::UnsafeCell::with_mut::hec978478c5b6c80b
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/loom/std/unsafe_cell.rs:14:9
21:     0xaaaea609d298 - tokio::runtime::task::core::Core<T,S>::poll::hed6916d731838527
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/core.rs:300:13
22:     0xaaaea62e8ed8 - tokio::runtime::task::harness::poll_future::{{closure}}::h7a7119156a7d876d
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/harness.rs:476:19
23:     0xaaaea5fcd270 - <core::panic::unwind_safe::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once::h3a3d6083285a14d9
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/panic/unwind_safe.rs:271:9
24:     0xaaaea6260af0 - std::panicking::try::do_call::hb2d3fcc36837cdfe
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panicking.rs:483:40
25:     0xaaaea629d6e0 - __rust_try
26:     0xaaaea620c804 - std::panicking::try::h3ed320d2e8f83a9b
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panicking.rs:447:19
27:     0xaaaea5cee6d8 - std::panic::catch_unwind::h9da8da10d7c15fb6
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panic.rs:137:14
28:     0xaaaea62b8044 - tokio::runtime::task::harness::poll_future::h1d1f31f860435e4e
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/harness.rs:464:18
29:     0xaaaea62f856c - tokio::runtime::task::harness::Harness<T,S>::poll_inner::h15a432daed38c380
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/harness.rs:198:27
30:     0xaaaea6344a1c - tokio::runtime::task::harness::Harness<T,S>::poll::h469d70680bc77016
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/harness.rs:152:15
31:     0xaaaea618c810 - tokio::runtime::task::raw::poll::h196fcf7cae6c40de
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/raw.rs:276:5
32:     0xaaaea68f1f28 - tokio::runtime::task::raw::RawTask::poll::hcb6dda8ccca8b6ed
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/raw.rs:200:18
33:     0xaaaea68feeb0 - tokio::runtime::task::LocalNotified::run::hc92ff9a9978e4eee
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/mod.rs:400:9
34:     0xaaaea690e364 - tokio::runtime::scheduler::multi_thread::worker::Context::run_task::{{closure}}::h3cdc073515aa1b7e
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/scheduler/multi_thread/worker.rs:639:17
35:     0xaaaea690de10 - tokio::runtime::coop::with_budget::h1712d68f5a84ba45
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/coop.rs:107:5
36:     0xaaaea690de10 - tokio::runtime::coop::budget::h147f87b3486494e0
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/coop.rs:73:5
37:     0xaaaea690de10 - tokio::runtime::scheduler::multi_thread::worker::Context::run_task::h915e53b98737c9f4
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/scheduler/multi_thread/worker.rs:575:9
38:     0xaaaea690d6d8 - tokio::runtime::scheduler::multi_thread::worker::Context::run::hea8a85b27c57e63c
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/scheduler/multi_thread/worker.rs:526:24
39:     0xaaaea690d47c - tokio::runtime::scheduler::multi_thread::worker::run::{{closure}}::{{closure}}::h2917b6e1fe55a84a
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/scheduler/multi_thread/worker.rs:491:21
40:     0xaaaea68d464c - tokio::runtime::context::scoped::Scoped::set::hc7c4148c32ab6e3a
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/context/scoped.rs:40:9
41:     0xaaaea693e1c4 - tokio::runtime::context::set_scheduler::{{closure}}::h673ad26400c9e7a1
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/context.rs:176:26
42:     0xaaaea68a6d8c - std::thread::local::LocalKey::try_with::hf9fa644e862300b0
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/thread/local.rs:446:16
43:     0xaaaea68a45e0 - std::thread::local::LocalKey::with::h327c65c7f256fa00
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/thread/local.rs:422:9
44:     0xaaaea693e148 - tokio::runtime::context::set_scheduler::h7849ce7b8bc2797f
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/context.rs:176:9
45:     0xaaaea690d3a0 - tokio::runtime::scheduler::multi_thread::worker::run::{{closure}}::h15ef0966f452b370
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/scheduler/multi_thread/worker.rs:486:9
46:     0xaaaea68e9f38 - tokio::runtime::context::runtime::enter_runtime::ha63a27489c6f3236
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/context/runtime.rs:65:16
47:     0xaaaea690d188 - tokio::runtime::scheduler::multi_thread::worker::run::hb83099a616a7073d
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/scheduler/multi_thread/worker.rs:478:5
48:     0xaaaea690d03c - tokio::runtime::scheduler::multi_thread::worker::Launch::launch::{{closure}}::h86d0102c82b97a6d
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/scheduler/multi_thread/worker.rs:447:45
49:     0xaaaea68c381c - <tokio::runtime::blocking::task::BlockingTask as core::future::future::Future>::poll::hb773c93889f2d7ed
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/blocking/task.rs:42:21
50:     0xaaaea68bcbcc - tokio::runtime::task::core::Core<T,S>::poll::{{closure}}::h64703a4895458d97
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/core.rs:311:17
51:     0xaaaea6929c44 - tokio::loom::std::unsafe_cell::UnsafeCell::with_mut::he5e455e020531998
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/loom/std/unsafe_cell.rs:14:9
52:     0xaaaea68bc578 - tokio::runtime::task::core::Core<T,S>::poll::h9f549b6c139f45b2
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/core.rs:300:13
53:     0xaaaea694ae78 - tokio::runtime::task::harness::poll_future::{{closure}}::hfd32d8e31bf0d498
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/harness.rs:476:19
54:     0xaaaea68f2f64 - <core::panic::unwind_safe::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once::h32d35ac696ee8541
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/panic/unwind_safe.rs:271:9
55:     0xaaaea69576c4 - std::panicking::try::do_call::he405d8c617260e90
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panicking.rs:483:40
56:     0xaaaea69593c0 - __rust_try
57:     0xaaaea6954bac - std::panicking::try::h6dfda46ace8764d4
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panicking.rs:447:19
58:     0xaaaea6938e14 - std::panic::catch_unwind::hadcf7ab49123674f
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panic.rs:137:14
59:     0xaaaea694a100 - tokio::runtime::task::harness::poll_future::h69f3e896d9a1433d
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/harness.rs:464:18
60:     0xaaaea6944ab8 - tokio::runtime::task::harness::Harness<T,S>::poll_inner::h30f4266ec631f904
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/harness.rs:198:27
61:     0xaaaea6944658 - tokio::runtime::task::harness::Harness<T,S>::poll::h56186a6269250c1a
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/harness.rs:152:15
62:     0xaaaea68f222c - tokio::runtime::task::raw::poll::h174218a0269b38fe
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/raw.rs:276:5
63:     0xaaaea68f1f28 - tokio::runtime::task::raw::RawTask::poll::hcb6dda8ccca8b6ed
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/raw.rs:200:18
64:     0xaaaea68fef7c - tokio::runtime::task::UnownedTask::run::h4816a5d6f60b84e2
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/task/mod.rs:437:9
65:     0xaaaea68bf704 - tokio::runtime::blocking::pool::Task::run::hec60ec3fbc956772
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/blocking/pool.rs:159:9
66:     0xaaaea68c336c - tokio::runtime::blocking::pool::Inner::run::h86b46f48f33b88f8
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/blocking/pool.rs:513:17
67:     0xaaaea68c2a78 - tokio::runtime::blocking::pool::Spawner::spawn_thread::{{closure}}::h04db02853d0e9952
at /home/opc/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.29.1/src/runtime/blocking/pool.rs:471:13
68:     0xaaaea68f388c - std::sys_common::backtrace::_rust_begin_short_backtrace::h7150c4c6a2cf812f
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/sys_common/backtrace.rs:121:18
69:     0xaaaea68cef44 - std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}}::ha37c1ee073b9ca9e
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/thread/mod.rs:551:17
70:     0xaaaea68f35e8 - <core::panic::unwind_safe::AssertUnwindSafe as core::ops::function::FnOnce<()>>::call_once::hf51ddb39caefac05
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/panic/unwind_safe.rs:271:9
71:     0xaaaea6956d68 - std::panicking::try::do_call::h7d726ca0ae2fe496
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panicking.rs:483:40
72:     0xaaaea69593c0 - _rust_try
73:     0xaaaea6954694 - std::panicking::try::h4ca81c2982f8bc65
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panicking.rs:447:19
74:     0xaaaea6938ec4 - std::panic::catch_unwind::hd7be967759e3f5a1
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/panic.rs:137:14
75:     0xaaaea68cedac - std::thread::Builder::spawn_unchecked::{{closure}}::h7983506e3141e1fd
at /builddir/build/BUILD/rustc-1.66.1-src/library/std/src/thread/mod.rs:550:30
76:     0xaaaea691adb8 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h91d3452caa4660ea
at /builddir/build/BUILD/rustc-1.66.1-src/library/core/src/ops/function.rs:251:5
77:     0xaaaea6bd3168 - std::sys::unix::thread::Thread::new::thread_start::h4f9b99c50c6adb95
78:     0xfffe4a1d7928 - start_thread
79:     0xfffe49f73e1c - thread_start
80:                0x0 -

Thanks for your feedback @Manw107
I looked into this and the error thrown in the stack trace Failed to submit response: Unknown interaction bubbles up from the serenity framework. Serenity throws this error if the submitted command is not known by discord (=Unknown interaction).
This is a strong indicator that the commands (=interactions) weren't finished with the registration to the discord api. This can happen due to the following reasons:

The bot wasn't ready yet and the command was executed before all commands were submitted to the discord api. You can check this by looking at your logs. You should not submit any commands to the bot before the ✅ Application commands submitted log appears. As you see in the logs below, this can take a few seconds.

 [2023-07-07T12:49:33Z INFO  cadency_core::handler::command] 🚀 Start Cadency Discord Bot
[2023-07-07T12:49:33Z INFO  cadency_core::handler::command] ⏳ Started to submit commands, please wait...
[2023-07-07T12:50:14Z INFO  cadency_core::handler::command] ✅ Application commands submitted
[2023-07-07T12:51:28Z INFO  cadency_core::handler::command] ⚡ Execute 'play' command
[2023-07-07T12:51:32Z INFO  cadency_core::handler::command] ✅ Command 'play' was successful

The bot was started for the first time and therefore the commands were submitted for the first time to discord. As these commands are global, it can take up to 1 hour until the commands are available, according to the serentiy documentation: https://docs.rs/serenity/latest/serenity/http/client/struct.Http.html#method.create_global_application_command

So the issue might be resolved by waiting a little bit. From my experience it mostly doesn't take a full hour until the commands are working.

What is the best solution for this issue? I tried restarting the bot and waiting 12 hours and still same message about audio source cannot be added

@sintaxx Could you please provide me with the logs?
The message ❌ Couldn't add audio source to the queue! can have multiple root causes and I want to verify that this is actually the same as reported above.
Do you use the latest docker image?

Hi, sorry if it took me a lot to answer.

The bot was started for the first time and therefore the commands were submitted for the first time to discord. As these commands are global, it can take up to 1 hour until the commands are available, according to the serentiy documentation: https://docs.rs/serenity/latest/serenity/http/client/struct.Http.html#method.create_global_application_command

This is probably the reason why the /play command doesn't work because I always wait for ✅ Application commands submitted
Btw could the OS or the architecure of the host be a problem?

@Manw107
I just tried it out with a brand new discord bot. I'm unable to reproduce this. :|
Do you use the docker image and are you on the latest version?
If not, this might be the issue, as older docker builds use very likely an outdated yt-dlp version and this has caused problems in the past. Thats why I publish a new cadency version with every yt-dlp update...

Btw could the OS or the architecure of the host be the source of the problem?
Right now, I'm not aware of any platform specific issues. As long as you use the docker image you should be fine. And the image supports arm64 and amd64.


Kagi search as new tab page - Can I make a PR to do this?

Very simple, I pay for and use Kagi. I like it, but I also want Kagi search as my "new tab" landing page.
If I make a simple PR to do this, would it be accepted? Just let me know yes/no.
If not, I'd be happy to make an open source new tab extension that sets kagi as the default new tab page.
I build tons of extensions.
Papillon

We have open sourced the extnesion so that people can submit PRs :)

Thanks, have just made my PR - my first ever open source PR

commented on the PR associated, #9
for anyone reading in the future:
unfortunately not allowed to do it this way as per store guidelines

and at that point it becomes non-optional if we force the new tab to go to a markup file or just direct to kagi like other extensions do.


Support for GraphQL Mocks

Any suggestions on how to use Storybook together with GraphQL mocks? I think this could be really handy.

I wonder if looking through the Graphiql editor source could help. cc: @leeb
https://github.com/graphql/graphiql

@raedle could you tell me more about GraphQL mocks. Not sure, what exactly we can do with GraphQL.

So, my example is in React-Native, but I don't think this should make too much of a difference. However, we are using relay, which does matter.
I wanted to write stories like this:
  .add('Multiple Items', () => {
    const props = {
      articles: [{
        thumbnail_title : 'Example Article',
        href: '/artist/glenn-brown',
        id: '2',
        author : { name: 'Made by Orta' },
        thumbnail_image: { url: "" }
      }, {
      ...
    }]
    };
    return <StubContainer Component={ArtistArticles} props={props}/>;

So I created a component that emulates the work of really against a graphQL implementation:
/* @flow */
'use strict';

import React from 'react';

// Emulates a Relay-compatible container, passing the data in directly.
// It's hard to know how well this can work for complicated examples. However,
// it's worked well enough so far - ./

export default class StubbedContainer extends React.Component {
  // Provide a stubbed context for child componentes
  getChildContext() {
    return {
      relay: {
        forceFetch: () => {},
        getFragmentResolver: () => {},
        getStoreData: () => {},
        primeCache: () => {}
      },
    route: { name: 'string' , params:{}, useMockData: true, queries: {}}
    };
  }

  // Directly render the child, and add the data
  render() {
    return <this.props.Component {...this.props.props} />;
  }

  // Needed to pass the isRelayContainer validation step
  getFragmentNames() {}
  getFragment() {}
  hasFragment() {}
  hasVariable() {}
}

// Expose dummy relay and a fake route
StubbedContainer.childContextTypes = {
  relay: React.PropTypes.object,
  route: React.PropTypes.object
};

In the end it means that our stories and either use relay, or use a stubbed relay to work with our GraphQL API. Note this is my first jump into react/react native, so it might not be 100%.
For full discussion on some of the trade-offs, see this PR: https://github.com/artsy/emission/pull/215

@orta Great. This is awesome. Is it possible for you to wrap this component into a NPM package and add it to here.

I hope we've a fix here.

Hi, I am facing an issue on integrating storybook with gatsby.As my gatsby site consists of components which uses graphql queries which are giving an error.Is there any solution to create storybook for such components.
FooterSocialIcons component
import React from 'react'
import { StaticQuery, graphql,Link } from "gatsby"
const FooterSocialIcons = (props)=>(
<StaticQuery
query={graphql    query{         fbLogo: file(relativePath: { eq: "icon-green-fb.svg" }) {           publicURL         }         twLogo: file(relativePath: { eq: "icon-green-tw.svg" }) {           publicURL         }         ytLogo: file(relativePath: { eq: "icon-green-yt.svg" }) {           publicURL         }         pinLogo: file(relativePath: { eq: "icon-green-pin.svg" }) {           publicURL         }       }    }
// render={data => { return }}
render={data => {
return (

<Link to="https://www.youtube.com/channel/UChH5SIf95NpjRbIgRJzDDPQ"aria-
label="Redirects to Kelloggs youtubePage">

            )
        }
    }
/>

)
export default FooterSocialIcons
Storybook for FooterSocialIcons Component
import React from "react";
import { storiesOf } from "@storybook/react";
import FooterSocialIcons from './footerSocialIcons';
storiesOf("FooterSocialIcons", module).add(
"with diffent SocialIcons",
() => (

),
{ info: "It should show social icons with links" }
);
Error while creating the storybook for this component
It appears like Gatsby is misconfigured. Gatsby related graphql calls are supposed to only be evaluated at compile time, and then compiled away,. Unfortunately, something went wrong and the query was left in the compiled code. .Unless your site has a complex or custom babel/Gatsby configuration this is likely a bug in Gatsby.
Error: It appears like Gatsby is misconfigured. Gatsby related graphql calls are supposed to only be evaluated at compile time, and then compiled away,. Unfortunately, something went wrong and the query was left in the compiled code.
.Unless your site has a complex or custom babel/Gatsby configuration this is likely a bug in Gatsby.
Any solution please let me know

Hi, I am facing an issue on integrating storybook with gatsby.As my gatsby site consists of components which uses graphql queries which are giving an error.Is there any solution to create storybook for such components.
footerSocialIcons Component
import React from 'react'
import { StaticQuery, graphql,Link } from "gatsby"
const FooterSocialIcons = (props)=>(
<StaticQuery
query={graphql    query{         fbLogo: file(relativePath: { eq: "icon-green-fb.svg" }) {           publicURL         }         twLogo: file(relativePath: { eq: "icon-green-tw.svg" }) {           publicURL         }         ytLogo: file(relativePath: { eq: "icon-green-yt.svg" }) {           publicURL         }         pinLogo: file(relativePath: { eq: "icon-green-pin.svg" }) {           publicURL         }       }    }
render={data => {
return (

<Link to="https://www.youtube.com/channel/UChH5SIf95NpjRbIgRJzDDPQ"aria-label="Redirects to Kelloggs youtubePage">

            )
        }
    }
/>

)
export default FooterSocialIcons
Storybook for FooterSocialIcons Component
import React from "react";
import { storiesOf } from "@storybook/react";
import FooterSocialIcons from './footerSocialIcons';
storiesOf("FooterSocialIcons", module).add(
"with diffent SocialIcons",
() => (

),
{ info: "It should shows social icons with links" }
);
Error while creating the storybook for this component
It appears like Gatsby is misconfigured. Gatsby related graphql calls are supposed to only be evaluated at compile time, and then compiled away,. Unfortunately, something went wrong and the query was left in the compiled code. .Unless your site has a complex or custom babel/Gatsby configuration this is likely a bug in Gatsby.
Error: It appears like Gatsby is misconfigured. Gatsby related graphql calls are supposed to only be evaluated at compile time, and then compiled away,. Unfortunately, something went wrong and the query was left in the compiled code.
.Unless your site has a complex or custom babel/Gatsby configuration this is likely a bug in Gatsby.
Any solutions?


Absolute file path in code

I don't know what this exactly is, but it looks wrong to me:
https://github.com/nolanlawson/pouchdb-authentication/blob/master/dist/pouchdb.authentication.js#L285

It's an old browserify bug, due to the fact that this module uses an older version of browserify.


Arabic translation

The Arabic translation of Phoenix Wallet, I tried to make it as clear as possible.
I invited some people on Twitter to review this translation and fix what is wrong. tweet link

Kindly check the suggested changes in the Arabic translation, Good luck
برجاء مراجعة التعديلات المقترحه في الترجمه العربيه ،، بالتوفيق

Thanks for your review, I edited most of your suggestions except the "Electrum" edit, I tend to not translate names of brands as it doesn't reflect anything when translated.

I built the app and tested it after adding the translation, everything worked well. no RTL issues. the app became RTL without doing anything.

Thanks a lot!
There are some RTL glitches (like the back arrow pointing to the left and the currency picker being misaligned), but it's outside the scope of this PR. I'll review the translation asap.

if you mean the currency picker in the top of the screen that is because a lot of arabic countries uses Hindu–Arabic numeral system<PHONE_NUMBER>) not the Arabic numeral system<PHONE_NUMBER>), and these Hindu–Arabic numbers are considered RTL letters that is why they look kinda weird next to "sats", I think the way to solve this is to translating "sats" or any currency into an arabic word. so it will look like (٤٠ ساتوشي) meaning (40 sats)
and btw it is also possible to make the language of the deivce Arabic with Arabic numeric system, just like this:-

if you mean the currency picker in the top of the screen that is because a lot of arabic countries uses Hindu–Arabic numeral system<PHONE_NUMBER>) not the Arabic numeral system<PHONE_NUMBER>), and these Hindu–Arabic numbers are considered RTL letters that is why they look kinda weird next to "sats", I think the way to solve this is by translating "sats" or any currency into an arabic word. so it will look like (٤٠ ساتوشي) meaning (40 sats)
and btw it is also possible to make the language of the deivce Arabic with Arabic numeric system, just like this:-


Duplicate of ClearScript.V8?

Why is this package needed? Is there a plan to make it eventually just a virtual nuget which references ClearScript.V8—or is there some reason that using the official ClearScript.V8 nuget package just doesn’t work? If there’s a good reason for this package, could that be documented in the README please?

Nevermind, that package is third party and doesn’t even work (at least with VS2015CTP6 it doesn’t copy over the v8-.dlls properly). I’ve opened https://clearscript.codeplex.com/workitem/78 , but I guess that ClearScript.Installer is necessary in the meantime… though I am still against this proliferation of ClearScript installation wrappers showing up on nuget.org…


remove legacy content

Docs Build status updates of commit c56cd7d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Advertising/bingads-12/bulk-service/budget.md
:white_check_mark:Succeeded

Advertising/bingads-13/bulk-service/budget.md
:white_check_mark:Succeeded

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.