Source package files lost their timestamps

While using meson-python in (a couple of) python packages, I noticed the files stored in the archive have no valid timestamps (they are all 01/01/1970). The archive is obtained with a python -m build --sdist.
https://github.com/silx-kit/fabio/issues/540
https://github.com/silx-kit/pyFAI/issues/1917
@picca, who packages the software for debian, reported this feature breaks the automatic packaging.
I quickly investigated, and both git archive and meson dist produce archive with valid timestamps for packaged files.

Here is the reference to the bug in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041443

Thanks for the report. Indeed the sdist is created without specifying a mtime, which defaults to 0. It is not difficult to fix it, but I don't know which other mtime it makes sense to use. We could use the same mtime set by meson dist, which in turn is the same used by the underlying git archive.
However, meson-python picks up uncommitted changes to files that would anyhow be present in the dist tarball, despite python -m build -s displaying a "WARNING: Repository has uncommitted changes that will not be included in the dist tarball" warning. Therefore the current time would be a better choice. However, new files are not picked up.
To confuse things a bit more, meson-python uses the value set in SOURCE_DATE_EPOCH env var as mtime for the PKG-INFO archive file, if set.
I think we should drop the support for picking up uncommitted changes, use the mtime set by meson dist for all archive member, and drop support for SOURCE_DATE_EPOCH.
@rgommers comments?

The rationale for the current behavior is in #53

The rationale is that some packages require modifications to the source tree in the sdist. But I don't see why these cannot be applied with a meson dist script https://mesonbuild.com/Reference-manual_builtin_meson.html#mesonadd_dist_script

Thanks for the report @kif and the diagnosis @dnicolodi!

I think we should drop the support for picking up uncommitted changes

This would be pretty problematic, this feature is quite important. And I don't see why we'd have to couple this to the timestamp problem.

use the mtime set by meson dist for all archive members,

Keeping the meson dist mtime seems like a good idea to me. In case of uncommitted changes, I think we can still keep the meson dist time, or the current time.

and drop support for SOURCE_DATE_EPOCH.

That seems to be a reproducibility feature, and at first sight also unrelated to the current bug report? It was touched in gh-58 (which fixed gh-53), but already present and not introduced to deal with uncommitted changes.
The original Debian bug report does not mention SOURCE_DATE_EPOCH, but probably it was set when those packages were built? See https://reproducible-builds.org/docs/source-date-epoch/ for what it's meant to do. tl;dr maybe this is a feature and not a bug?

I think we should drop the support for picking up uncommitted changes

This would be pretty problematic, this feature is quite important. And I don't see why we'd have to couple this to the timestamp problem.

Why the same cannot be achieved with a meson dist script? This couple to the mtime issue because the mtime we set should IMO represent the latest modification time of the content of the sdist, and if we pick file content from uncommitted changes we cannot guarantee that the meson dist mtime is the correct one.

use the mtime set by meson dist for all archive members,

Keeping the meson dist mtime seems like a good idea to me. In case of uncommitted changes, I think we can still keep the meson dist time, or the current time.

Unless we extract the files archived by meson dist and compare their content with the one in the source tree, we cannot know if they have uncommitted changes. I don't think doing this for all the files in the sdist is something we want to do. Thus we would need to settle for the current time or the meson mdist time independently of the fact that the files have been modified.

and drop support for SOURCE_DATE_EPOCH.

That seems to be a reproducibility feature, and at first sight also unrelated to the current bug report?

It is a reproducibility work-around for tools that otherwise produce non-reproducible archives. It is not a feature in itself. If we can produce the same archive independently of when the command to produce the archive is run, there is no use for it.

The original Debian bug report does not mention SOURCE_DATE_EPOCH, but probably it was set when those packages were built? See https://reproducible-builds.org/docs/source-date-epoch/ for what it's meant to do. tl;dr maybe this is a feature and not a bug?

We use SOURCE_DATE_EPOCH only for the modification time of the PKG-INFO file in the archive. All other files currently get an mtime of 0.

All other files currently get an mtime of 0.

That is something that is probably not a reasonable thing to do, right? It's the end of my day here, so I can only have a closer look tomorrow, but setting the time to 0 is something that I'm not sure about (also not that this was implemented intentionally).

Why the same cannot be achieved with a meson dist script?

This breaks the regular workflow for applying patches for distro packagers. Distros can take sources from either PyPI or directly from a tag on GitHub or another VCS system. The workflow is to download, then apply a set of patches with patch or another utility, then start building. Requiring packagers to not use patch et al. but a dist script is a very packager-unfriendly idea. I can dig up concrete places where this is used tomorrow. It would be a significant regression at this point imho.

Why the same cannot be achieved with a meson dist script?

This breaks the regular workflow for applying patches for distro packagers. Distros can take sources from either PyPI or directly from a tag on GitHub or another VCS system. The workflow is to download, then apply a set of patches with patch or another utility, then start building. Requiring packagers to not use patch et al. but a dist script is a very packager-unfriendly idea. I can dig up concrete places where this is used tomorrow. It would be a significant regression at this point imho.

Uh? sdist are source distributions. Distributions build binary distributions from sources, obtained from either sdists or from git checkouts. The Debian bug in this issue is indeed that the source distribution for some packages is invalid. Why would a distribution take a sdist, modify it, and then build another sdist? They would apply changes to the source tree and then build a binary package, not another source package. Is this related to pypa/build building an sdist first and a wheel from that? This behavior can be turned off, can't it?

All other files currently get an mtime of 0.

That is something that is probably not a reasonable thing to do, right? It's the end of my day here, so I can only have a closer look tomorrow, but setting the time to 0 is something that I'm not sure about (also not that this was implemented intentionally).

This is the source of the bug reported here. I'm just trying to understand what the 0 should be replaced with.

@picca, who packages the software for debian, reported this feature breaks the automatic packaging.

@picca or @kif I now checked the linked bug reports, but it does not say what exactly breaks. It's a bit surprising, because we've had no complaints about this so far from any other packages. Could you elaborate, either here or on one of the linked silx-kit issues, what exactly is going wrong. That'll be helpful not only now, but in the future.

We could use the same mtime set by meson dist, which in turn is the same used by the underlying git archive.

This seems to be the time that the last commit was made for all files, and not the time at which a given file was last changed. It's documented to work like that: https://git-scm.com/docs/git-archive#Documentation/git-archive.txt---mtimelttimegt.  So that doesn't match the output of the conventional meaning of mtime (or ls -l) for files on disk either.

Therefore the current time would be a better choice.

 I think a clear requirement is that generating an sdist twice in a row, in the same environment, should give the same result. On the other hand, it's not yet clear to me what the additional requirement is that Debian seems to want here.

Is this related to pypa/build building an sdist first and a wheel from that? This behavior can be turned off, can't it?

I think so. One can directly build a wheel with python -m build --wheel. However, having the wheel contents depend on whether or not it was generated directly from a git repo or via an sdist is not good.
I now remember another reason, which is that both myself and other SciPy devs were confused multiple times that uncommitted changes were not being installed. This is confusing, since it's a "why aren't my changes showing" up kind of thing (especially when setup.py builds would include them) and having to commit each intermediate step can be annoying.
Here is an example of where we amend a license file with platform-specific info: https://github.com/scipy/scipy/blob/main/tools/wheels/cibw_before_build_win.sh#L8. That's now a one-liner. Having to do that via a dist script would be very clumsy, and committing the change would be in itself a source of non-reproducibility (since the git hash changes, and that's part of the sdist and wheel artifacts).
tl;dr it's not yet clear that there is actually a problem here that we should consider a bug. And discussing removing a feature that I really needed is certainly premature. Let's focus on the requirement on time stamps first.

We could use the same mtime set by meson dist, which in turn is the same used by the underlying git archive.

This seems to be the time that the last commit was made for all files, and not the time at which a given file was last changed. It's documented to work like that: https://git-scm.com/docs/git-archive#Documentation/git-archive.txt---mtimelttimegt. So that doesn't match the output of the conventional meaning of mtime (or ls -l) for files on disk either.

Therefore the current time would be a better choice.

 I think a clear requirement is that generating an sdist twice in a row, in the same environment, should give the same result. On the other hand, it's not yet clear to me what the additional requirement is that Debian seems to want here.

The only requirement Debian adds is that the mtime should not be zero (ie 1970-01-01 00:00:00).
If we include uncommitted changes, using the timestamp of the last commit is wrong. I don't think we should do that.

Is this related to pypa/build building an sdist first and a wheel from that? This behavior can be turned off, can't it?

I think so. One can directly build a wheel with python -m build --wheel. However, having the wheel contents depend on whether or not it was generated directly from a git repo or via an sdist is not good.

But this is precisely what you are asking. You want the sdist to be different from the content of the git repository.

I now remember another reason, which is that both myself and other SciPy devs were confused multiple times that uncommitted changes were not being installed. This is confusing, since it's a "why aren't my changes showing" up kind of thing (especially when setup.py builds would include them) and having to commit each intermediate step can be annoying.

Are you saying that including uncommitted changes in the sdist is a work-around for the choice made by pypa/build to build wheels via an intermediate sdist by default? I don't think it is a particularly strong reason. Also, I expect most developers to install with python -m pip install . rather than python -m build . && python -m pip install dist/*.whl. If they do the second, I don't see requiring an extra -w switch passed to build as problematic (it also spares them an extra meson setup step).

Here is an example of where we amend a license file with platform-specific info: https://github.com/scipy/scipy/blob/main/tools/wheels/cibw_before_build_win.sh#L8. That's now a one-liner. Having to do that via a dist script would be very clumsy, and committing the change would be in itself a source of non-reproducibility (since the git hash changes, and that's part of the sdist and wheel artifacts).

This scripts seems to be used to build wheels, not sdists, or are you saying that SciPy distributes different source packages on different architectures? Why would

tl;dr it's not yet clear that there is actually a problem here that we should consider a bug. And discussing removing a feature that I really needed is certainly premature. Let's focus on the requirement on time stamps first.

I'm just not sure that you need the feature, and it is absolutely confusing to have a big warning that says that uncommitted changes are not included in the sdist, but then include (some of) them.
From what I understand, you want to have uncommitted changes included in the sdist, and the members of the sdist archive to be assigned timestamps of the last git commit. We can certainly do that, but it does not make much sense.

Here is an example of where we amend a license file with platform-specific info: https://github.com/scipy/scipy/blob/main/tools/wheels/cibw_before_build_win.sh#L8.

Where is this script used? I haven't found it used where I expected it to be used ie in the wheel build CI jobs.

The only requirement Debian adds is that the mtime should not be zero (ie 1970-01-01 00:00:00).

Can we please focus on this first Daniele? I have not seen any evidence of this yet, and I'm really busy - Python 3.12.0rc1 came out yesterday, and everyone wants numpy wheels for it asap. So I am quite reluctant to go dig up old stuff right this minute and discuss whether or not the feature that I needed last year can be ripped out.

Hi, I tried to set the SOURCE_DATE_EPOCH environment variable but it is not used:
export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct)
echo $SOURCE_DATE_EPOCH
python3 -m build -s
tar -tvzf dist/pyfai-2023.6.0a0.tar.gz
[...]
-rw-r--r-- 0/0            3194 1970-01-01 01:00 pyfai-2023.6.0a0/pyproject.toml
-rw-r--r-- 0/0             146 1970-01-01 01:00 pyfai-2023.6.0a0/requirements.txt
-rwxr-xr-x 0/0           16959 1970-01-01 01:00 pyfai-2023.6.0a0/run_tests.py
-rw-r--r-- 0/0             281 1970-01-01 01:00 pyfai-2023.6.0a0/setup.cfg
-rwxr-xr-x 0/0            5402 1970-01-01 01:00 pyfai-2023.6.0a0/version.py
-rw-r--r-- 0/0           13697 2023-08-08 11:08 pyfai-2023.6.0a0/PKG-INFO

So apparently, meson-python does not "properly" use SOURCE_DATE_EPOCH...

Hi, I tried to set the SOURCE_DATE_EPOCH environment variable but it is not used:

No, it is not. As I was explaining before, and as it is shown by your experiment, it is used only for the PKG-INFO archive member.

The fix is waiting in #452.
@rgommers I had the impression that you wanted to land a fix for this quickly. Do you foresee having time to review the pending PRs?

Sorry for the delay @dnicolodi, and thank you for putting up a fix! I'll start reviewing now, and will try to get through the backlog of reviews this week.

@mathstuf The fix is waiting for review in #452. The timestamp of 0 is a bug and it has never been a conscious decision to use it for anything. meson-python creates source tarballs starting with the content of a version control repository (git or mercurial) thus the time of the last commit is always available.

Sorry, I guess I was misinterpreting the initial "decision" to use 0 in the first place. If a VCS is always available, then that is fine. I just wanted to add that 0 has other problems than the reported Debian issue.


Support thor install <uri> to install remote thor files

The previous code suggested that this was supported, but it was not really working as expected.

Tests seem to be failing. Also, can you please describe what the problem was and how this fixes it?

Yes, test are failing in the main branch. #780 should be merged first, and then I can rebase this to get it green hopefully :)
Sorry for not describing this enough.
As the title says, this PR intends to fix running thor install <uri>. The thor CLI provides an install command which receives a Thorfile as an argument. This argument can be a local filename, a directory (in which case Thor looks for a main.thor file inside) or an remote URI. However, passing a remote URI does not work at the moment and Thor raises an error like the following:
$ thor install https://raw.githubusercontent.com/rails/thor/main/Thorfile
Error opening file 'https://raw.githubusercontent.com/rails/thor/main/Thorfile'

To fix the problem, I detect whether the given argument is an uri or not. If it's an uri, I use URI.open, otherwise I use open like it's done now.
Let me know if there's more I should clarify!

@deivid-rodriguez I think the issue has to do with the changing of the functionality of open in Ruby 3.0. We'd need to make sure that older Rubies are still supported. https://stackoverflow.com/a/66032553/5199431

You're right, it sounds like this is broken since Ruby 3.0. And my new approach only works for rubies where URI.open is public.
I actually based this solution on what's done at https://github.com/rails/thor/blob/ab3b5be455791f4efb79f0efb4f88cc6b59c8ccf/lib/thor/actions.rb#L204-L234, so it sounds like that's already broken like in this PR.
Anyways, I will amend this to support old rubies once the repo gets some activity and CI in the main branch is back to green 👍.

@dorner This should be green now. As noticed, there's some code in thor/lib/thor/actions.rb where open-uri usage is also broken. But I'd rather investigate that on a separate PR.

For what it's worth, my initial motivation to change this was to avoid using
class Thor::Runner < Thor #:nodoc:
   autoload :OpenURI, "open-uri"
   # ...
end

because that just got deprecated and will now longer work as it works today in the future. See https://github.com/ruby/ruby/pull/5949.
But then when attempt to change the code to not use the above, I realized that the code was not actually working, so I went ahead and fixed that too.

Rebased!

By the way, I think this PR is maybe a bit complicated to review due to indentation changes, I recommend looking at the patch with w=1: https://github.com/rails/thor/pull/787/files?w=1.

Thanks so much @rafaelfranca!


pod install doesn't use cocoapods plugins

I have a Gemfile/Gemfile.lock that specifies CocoaPods and also specifies a specific version of cocoapods-binary, a CocoaPods plugin. The steps-cocoapods-install bitrise step seems to run pod install directly instead of using bundle exec pod install which leads to the cocoapods-binary plugin not being found since it was installed through bundler.
As a solution, I would suggest that bundle exec should be used for all pod commands if the Gemfile exists, since that is most likely the intent for any repo that specifies CocoaPods in the Gemfile.

Hi @kylefleming!
Thanks for the report and your suggestion! Can you please send us a build URL of this issue happening?

Sure thing: https://app.bitrise.io/build/98e31eeb2ad789f1

Hi @kylefleming,
Thanks for the report. As long the cocoapods version in the Podfile.lock and Gemfile.lock matches, it should not be a problem and indeed the preferred way. Additionally the step would run the bundle install command internally if implemented.
Can you share the specific Podfile.lock / Podfile  Gemfile.lock / Gemfile used?

Hi,
I agree with @kylefleming .
CocoaPods allows any plugins ( https://guides.cocoapods.org/plugins/setting-up-plugins.html ) and gems are required to run them.
In this case, failed to run the plugin ( cocoapods-binary ) installed by Gemfile.lock and cocoapods was excuted on system environment.
where the versions specified with this line ( https://github.com/bitrise-steplib/steps-cocoapods-install/blob/1a276f4ffcf6efd1fcff11fdbcacb9c08993723f/main.go#L340 ), but not specified environment.
So current my solutions:
Added Script Step and written gem install 'cocoapods-binary' and install cocoapods-binary into global environment.

@lpusok Sure thing. Here's an example repo that demonstrates the issue: https://github.com/kylefleming/CocoaPodsBitriseIssue

Hey @kylefleming !
Is this issue still persist? I tried with your sample project and it looks to work just fine.

The issue seems to be fixed and a new release is on the way out now with this PR: https://github.com/bitrise-steplib/steps-cocoapods-install/pull/55
So I close this issue as resolved but feel free to re-open if you still encounter any issues with it.


Footer is not correctly pinned to end

For example, at https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.read_table.html, it looks like this:

The footer is only about a third of a way down the page.

Actually looks like this is #79; it does fix itself by refreshing.

Yeah, it's an annoying issue. I renamed the other issue to better reflect the problem (although it is difficult to explain in words ;))


[CLI] wandb_logger.log_image DOES NOT EXIST

Description
Hello, I am trying to log_image but it says it doesn't exist.
Wandb features

Hi @tsuijenk,
What version of PyTorch lightning are you using currently? I just tried a simple test script on the latest version on pytorch lightning (1.5.9):
from pytorch_lightning.loggers import WandbLogger
import torch

wandb_logger = WandbLogger(project='log_image')

print(wandb_logger)
print(wandb_logger.log_image)

image = torch.rand((3, 64, 64))

wandb_logger.log_image('image', [image])

I saw the following output for the print statements and was successfully able to log an image into W&B:
<pytorch_lightning.loggers.wandb.WandbLogger object at 0x7fa8b2d8edf0>
<bound method WandbLogger.log_image of <pytorch_lightning.loggers.wandb.WandbLogger object at 0x7fa8b2d8edf0>>

which indicates to me that log_image exists and is functioning correctly.
If you are running the latest version of Lightning, I would recommend reinstalling Pytorch Lightning and wandb once. Please let me know if you still run into issues after reinstalling.
Thanks,
Ramit

I can confirm this feature was introduced in Lightning 1.5.0, so you will have to upgrade lightning to the latest version.
pip install --upgrade pytorch_lightning
Happy logging!

Closing this issue out. If you still experience issues with logging images, please let us know!


why I got this error when doing just go get

$ go get -v github.com/jmoiron/sqlx
github.com/jmoiron/sqlx (download)
github.com/jmoiron/sqlx/reflectx
github.com/jmoiron/sqlx
# github.com/jmoiron/sqlx
jmoiron/sqlx/named_context.go:41: n.Stmt.ExecContext undefined (type *Stmt has no field or method ExecContext)
jmoiron/sqlx/named_context.go:41: not enough arguments to return
jmoiron/sqlx/named_context.go:51: n.Stmt.QueryContext undefined (type *Stmt has no field or method QueryContext)
jmoiron/sqlx/named_context.go:51: not enough arguments to return
jmoiron/sqlx/sqlx_context.go:20: db.PingContext undefined (type *DB has no field or method PingContext)
jmoiron/sqlx/sqlx_context.go:122: cannot use db (type *DB) as type namedPreparerContext in argument to prepareNamedContext:
	*DB does not implement namedPreparerContext (missing PrepareContext method)
jmoiron/sqlx/sqlx_context.go:128: cannot use db (type *DB) as type ExtContext in argument to NamedQueryContext:
	*DB does not implement ExtContext (missing ExecContext method)
jmoiron/sqlx/sqlx_context.go:134: cannot use db (type *DB) as type ExtContext in argument to NamedExecContext:
	*DB does not implement ExtContext (missing ExecContext method)
jmoiron/sqlx/sqlx_context.go:182: undefined: sql.TxOptions
jmoiron/sqlx/sqlx_context.go:203: undefined: sql.TxOptions
jmoiron/sqlx/sqlx_context.go:134: too many errors

sorry I tried on another laptop and its fine, so the problem just in my VPS, closing this issue


enable sensor events in gaze controller

This fixes the regression with X3D touch sensors
GearVRF DCO signed off by: Nola Donato<EMAIL_ADDRESS>

For the record, the problem is:
X3D Touch Sensors no longer produce the callback when I hover or click on a 3d mesh.
In the Controller reform - integrate picking, fix sensors #1455
https://github.com/Samsung/GearVRf/pull/1455
Touch Sensors work for commit # b792933 and ba71c11 (same as I did my regression testing against).
Commit # 1af4c5f did not build for me (issue with DaydreamViewManager.java)
Commit # 5e3e9ed and c5aa4b0, TouchSensor did NOT work.
Begin testing...

Quick regression test on Test repo x3d-> touchSensor5.x3d and JavaScript_PerFrame_05_LightControls.x3d
Both involve isOver (hover) and isActive (click) objects, including children and a variety of multiple animations., grabbing and moving objects, 'slider bars', calling JavaScript.
Both demo's worked
Looks Good To Me (LGTM)

Completed a few more tests this morning (Thursday, Oct. 5) including LOD with TouchSensors, hyper-bowling and a few others, and all looked good to me (LGTM).


Implement unit tests for Book and Label

Description
closes #20

[x] Add unit tests for Book class methods.
[x] Add unit tests for Label class methods.

Thanks @NasKhalil !


TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/71105

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/89282

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/121625


Delete unused comment code.

Impact

[ ] Bug fix (non-breaking change which fixes expected existing functionality)
[X ] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Code that is commented out gets outdated very quickly and becomes misleading. It is better to delete commented out code completely and use the VCS history instead.
Things to be aware of

Describe the technical choices you made
Describe impacts on the codebase

Things to worry about

List any questions or concerns you have with the change
List unknowns you have

Additional Context
Add any other context about the problem here.

This one will take a little more to look through. I'll sometimes leave code commented that will be a useful reminder in an upcoming expected change. While deleting it does leave it in history, people don't think to look there when they end up needing it.
Sometimes that expected change never comes and it's good to clean out, sometimes that time came and went and it needs to be cleaned out, sometimes it should still stay. I'll have to see if any of these seem worth keeping for a while.

This one will take a little more to look through. I'll sometimes leave code commented that will be a useful reminder in an upcoming expected change. While deleting it does leave it in history, people don't think to look there when they end up needing it.
Sometimes that expected change never comes and it's good to clean out, sometimes that time came and went and it needs to be cleaned out, sometimes it should still stay. I'll have to see if any of these seem worth keeping for a while.

I like this PR and I think I have been also tempted to delete some commented code as well in the past months. @nvoxland I think it would be nice to start removing cases like this, and only in exceptional cases we can leave some commented-out code but leaving a comment/reason why it has not been/cannot be deleted. If we want to keep a record of some deleted code I'm thinking I can create a confluence page and track the deleted code in there with a GH reference to the commit where these changes have been applied. What would you think about it? (cc: @filipelautert )

@MalloD12 I verified some random samples,  and there is code that have been commented out since 2009. So I think it's fine to remove it, specially because there should be better ways to handle it nowadays :)

@MalloD12 I verified some random samples, and there is code that have been commented out since 2009. So I think it's fine to remove it, specially because there should be better ways to handle it nowadays :)

That's exactly what I was pointing out, but I think Nathan's point is valid. Although, I think we can implement a different idea/strategy (like the one I was talking about in my previous comment) if for some reason we would like to keep track of some specific code that has been commented out.


Regular/ on-demand backups

Two ideas for doing backups:

Save daily backups to a specific safe space, could be S3, could be Backblaze B2 or even on the host server.
Respond with a dump file on Telegram when requested like so /get-dump

This is very important as backups are currently manually taken in an unreliable fashion.

After moving to GCP, one can use a cron job to upload DB dump daily to Cloud Storage. Providing dump on Telegram is too risky.


What compiler does Android code use to write and compile jar ？

android Code What compiler to use write ？android studio write  compiler  jar,Ask how to write with what compiler, and then execute

Sorry, I don't understand the question. Maybe the answer is in BUILD.md.


feat(react-tinacms-inline): InlineBlocks children

Solves: https://community.tinacms.org/t/get-block-count-from-outside-inlineblocks/596

Hey @Jaza! Thanks for the contribution! This looks good to me, and we should be able to get this into the next release of react-tinacms-inline.
As Logan mentioned in that forum thread, we plan to revisit Inline Editing wholesale in the (hopefully near) future, though we don't have an exact timeline for that just yet. We are generally avoiding any feature development on react-tinacms-inline right now, and this specific feature may or may not make it into that future revision. But this is far off enough and not super clear just yet, so if this feature solves your problem there's no real harm in putting it out.
We definitely appreciate the contribution and discussion of your problem - this are things we will absolutely want to keep in mind!

@Jaza this is now available in prerelease<EMAIL_ADDRESS>

Cool, thanks for the run-down @dwalkr , and thanks for merging.


feat(thirdweb): accept ethers and viem accounts in sdk

#3787  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @gregfromstl and the rest of your teammates on  Graphite


Add Russian localization for dates

Add Russian language support. All three components are present, abbreviations correspond to conventional short forms in Russia.

Coverage remained the same at 99.611% when pulling e54f5e08f8aa475d51a862f12933d6c8b0895a78 on mgpnd:RussianLangSupport into ce30924746705e9a7f9473f4fd493699c53f0e24 on charliekassel:master.

Coverage remained the same at 99.611% when pulling ab2c31f93926e6095ecce18ef5de65d2124310ce on mgpnd:RussianLangSupport into ce30924746705e9a7f9473f4fd493699c53f0e24 on charliekassel:master.


Failing cases on sets of co-ordinates.

Recently discovered some failing cases in a project I'm working on. I'm not sure what the cause of the problem is but no distance is returned. The co-ordinates are real places on Earth.
Geopoint locations used: (3.44, -76.52), (-3.94, 103.8)
Geopoint locations used: (3.44, -76.52), (-3.29, 102.86)
Geopoint locations used: (3.44, -76.52), (-4.02, 103.25)
Geopoint locations used: (11.56, 104.92), (-12.07, -75.2)
Geopoint locations used: (11.56, 104.92), (-11.42, -75.69)
Geopoint locations used: (-6.23, 106.99), (5.82, -73.03)
Geopoint locations used: (-6.23, 106.99), (5.71, -72.93)
Geopoint locations used: (31.77, 119.95), (-31.73, -60.52)
Geopoint locations used: (3.03, 101.45), (-2.9, -79.0)
Geopoint locations used: (3.04, 101.58), (-2.9, -79.0)

A console Python example would be:
>>> loc1 = (3.44, -76.52)
>>> loc2 = (-3.79, 103.54)
>>> loc3 = (11.56, 104.92)
>>> loc4 = (-11.42, -75.69)
>>> vincenty(loc1,loc2)
>>> vincenty(loc3,loc4)
>>> vincenty(loc1,loc4)
1645.873288
>>>

Interestingly these cases fail even on http://www.gpsvisualizer.com/calculators
which makes me think the problem is one inherent to the formula or something I'm doing.

My apologies, I just realised those are near anti-podal sets of co-ordinates. That's what's causing the formula to fail to converge on a distance.


Move to Nuxt

TODO:

[x]  Background not working
[x]  Code snippets lost styling
[x]  Some errors appear in console on project page
[x]  Generation routes are hardcoded
[x] Make sure link lower/upper casing won't be a problem once we get to full static

Here is the real deal, deployed to a test project:
https://firestoresigelbaum.firebaseapp.com/


fix: error msg not match if condition

fix: error msg not match if condition,  VK_KHR_acceleration_structure vs VK_KHR_ray_tracing
#if **VK_KHR_acceleration_structure**
...
#else
    #error This include requires **VK_KHR_ray_tracing** support in the Vulkan SDK.
...

Hi joshuafc - thanks for the pull request! Could you sign off on your Git commit so that we're able to integrate it? DCO-Bot has the required action here: https://github.com/nvpro-samples/nvpro_core/pull/26/checks?check_run_id=3336936192
Thanks again!

Hi joshuafc - thanks for the pull request! Could you sign off on your Git commit so that we're able to integrate it? DCO-Bot has the required action here: https://github.com/nvpro-samples/nvpro_core/pull/26/checks?check_run_id=3336936192
Thanks again!

done

Thanks! Merging now.


e2e: trigger must-gather on failed BeforeTestSuiteSetup

Signed-off-by: Jose A. Rivera<EMAIL_ADDRESS>

/override ci/prow/ocs-operator-bundle-e2e-aws

/cherrypick release-4.6

/cherrypick release-4.6

/cherrypick release-4.7

/cherrypick release-4.7


Lire un user

L'application doit permettre de lire un User via un GET /user/<user_ID>

Current coverage is 81.56%

Merging #132 into master will decrease coverage by -0.25% as of 8f7f326

@@            master    #132   diff @@
======================================
  Files           32      32
  Stmts          319     320     +1
  Branches        12      12
  Methods          0       0
======================================
  Hit            261     261
  Partial          7       7
- Missed          51      52     +1

Review entire Coverage Diff as of 8f7f326

Powered by Codecov. Updated on successful CI builds.


Add MultiField support for Grids

The latest thinking here is that we might be able to decouple things, so that GridModel itself does not need to know about this, or get extra complexity.

We build a specialized multiField renderer, that looks for a config in its column of the following form: multiFieldConfig: {mainRenderer: numberRenderer(), subFields: ['exposure', 'mktValue'], subFieldsAlign: 'right'}`

The key thing here, is that the subFields would just look within the columns themselves for the specification of renderers.

We come up with an API whereby the column can optionally specify a minHeight.  So the grid does not need to know anything specific about multiField rendering

This was done and merged.


fix(collectionRepeat): Remove pixel padding for old display bug

This padding is causing some issues with item placement and borders. Removing it makes things add up correctly.
https://github.com/driftyco/ionic/commit/cd5a5ead57e62b8423345b02bbf2ff6cfecbca2e#commitcomment-10329756

Jamie
http://scaer.ru/metatrader_robot
24.03.2015, 14:49, "Jamie Sutherland" notifications@github.com:This padding is causing some issues with item placement and borders. Removing it makes things add up correctly.
You can view, comment on, or merge this pull request online at:
Commit Summary
fix(collectionRepeat): Remove pixel padding for old display bug
File Changes
M

(2)

Patch Links:
—Reply to this email directly or .

Thanks. That was deliberately put in to fix other issues. If it's causing a problem for you, I think a more elaborate solution is in order. Could you reopen this as an issue? Simply removing the -1px creates more issues than it fixes.


Allow for classes implementing more than one interface.

This is part of an effort to upstream the method as was suggested in the @todo. This now synchronizes the method with what is contained in the upstream PR.
Ref: https://github.com/squizlabs/PHP_CodeSniffer/pull/1098
Includes additional unit tests.

Please ping me when someone is ready to merge this and I'll rebase asap - see https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/pull/637#issuecomment-242906170

Closing as this PR is superseded by #656 now the related upstream PR has been merged and included in the PHPCS 2.7.0 release.


Add watchit to awesome-ipfs

What kind of PR is this?
Select only one to speed up review/approval; i.e., don't lump an addition and a removal into a single PR.

[x] Adding something new to awesome-ipfs
[ ] Editing something already listed on awesome-ipfs
[ ] Removing something from awesome-ipfs
[ ] Something else (if so, please explain in the "Additional details" section below)

Pre-submit checklist
Please confirm ALL of the following before submitting your PR.

[x] This PR includes only one addition, removal, or edit.
[x] I edited the /data directory instead of the README.md.
[x] I reviewed the content policy and the and the IPFS Community Code of Conduct to ensure my submission meets the requirements.
[x] I have followed the CONTRIBUTING.md guidelines.

Additional details
For new additions: How critical is IPFS to your project?

[x] Essential
[ ] Somewhat critical
[ ] Useful, but not critical

For new additions: What core goal(s) does your project address?

[ ] Big-data solutions
[x] Freedom from corporate/government interference
[ ] Data integrity
[ ] Dev tools or other ways to enable developers
[ ] Disaster resilience/recovery
[ ] File storage/retrieval
[x] File streaming
[ ] Permanent archiving
[ ] Self-sovereign identity
[ ] Platforms that utilize consensus, reputation, or incentivization
[ ] Other (please list)

@andrew Mind a look when you are able? Thank you!

@andrew Mind a look when you are able? Thank you!


Rest Catalog: table_exist does not succeed on 204 response code

Apache Iceberg version
main (development)
Please describe the bug 🐞
Currently table_exists only returns true on 200:
https://github.com/apache/iceberg-python/blob/20b7b5339a1a0ab59d884c7d042c4bc96a166b11/pyiceberg/catalog/rest.py#L793
According to the spec, it should return true on 204 (and probably 200 as well):
https://github.com/apache/iceberg/blob/ea916c1700ef37377d3e8bba1197b3fe32d1a248/open-api/rest-catalog-open-api.yaml#L820-L829

Sure - PR is coming. I'll have some more tricky great catches tomorrow ;)


Faster daemon startup for mobile use case

Over the last 9,000 new users that launched the LBRY mobile app, 4,000 quit the app before the daemon finished launching. Akin says it can take up to 30 seconds for this to happen.
Potential approach: start components in the order that the app needs them during startup. Make the jsonrpc api responsive right away, and defer as much of the slow stuff to later in the startup process.
Related: https://github.com/lbryio/lbry-android/issues/515

@akinwale what are the current stats for this?

Over the last 9,000 new users that launched the LBRY mobile app, 4,000 quit the app before the daemon finished launching. Akin says it can take up to 30 seconds for this to happen.

@kauffj Missed the notification for this message. We don't depend on the SDK being ready for the app to actually be usable upon startup any longer, so I haven't been tracking this.


Cannot compile, CMAKE cannot find config

Hello, i am trying to install Cork via compiling it but CMake gives me this error:
CMake Error: Could not read presets from /home/user/Downloads/Cork/build: File not found
I dont know why does it do that there is CPackConfig.cmake and CPackSourceConfig.cmake

Instructions for building on Linux were incorrect after some updates. I've updated them and they should now work.


SQL production

Adding the Json based result production such that nested and sibling nodes in graphql query can be processed with a single query. JOOQ support is needed for this to work with multiple databases

going to review and build this from master now.

going to review and build this from master now.

We'll need jooq release right? I am seeing a snapshot version is in use.

yes, currently we require 3.14 version of JOOQ which is not released yet, I have used the SNAPSHOT, for now, to check you would need to download their repo and build locally to succeed

Yep. Came here to mention the same problem I had. Any ETA on the JOOQ ?

With their past release cadence seem to be very soon, maybe couple weeks.


fix: Improved error message for google sheet insert/update empty body

Description

Improved error message for google sheet insert/update empty body

Fixes #17343
Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Manual

Checklist:
Dev activity

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Test plan has been approved by relevant developers
[ ] Test plan has been peer reviewed by QA
[ ] Cypress test cases have been added and approved by either SDET or manual QA
[ ] Organized project review call with relevant stakeholders after Round 1/2 of QA
[ ] Added Test Plan Approved label after reveiwing all Cypress test

/ok-to-test sha=72a616d

/ok-to-test sha=4b83e13

/ok-to-test sha=6bd51c9


Zenodo: change title of the record

Replace the current "poldracklab/fmriprep" by "FMRIprep: a robust preprocessing pipeline for task-based and resting-state fMRI data" to make it match the title of the OHBM poster.

I don't think this can be done easily with current setup. The issue is that the title should include both the name of the poster and the current version. This can be edited after the release (without changing the DOI). We would have to do this for each release.
Alternatively we can switch to pushing releases to zenodo via API, but that would require a lot of tooling.

Oh I see. It seemed easy at first. Can you make me admin of the repo at zenodo? Just in case we really get into this.

I could not find this feature https://github.com/zenodo/zenodo/issues/1325


Session is updated after being restored when loading the app

Possibly we need to put the loader in the app when it is loading for the first time.
Loader should be visible while the request to users/me endpoint is being submitted.

The bug is already resolved by the previous commits.


Vimeo video embedded on the homepage is not responsive

As a visitor,
When I view the homepage
The Vimeo embed code does not respond to the viewport width, potentially forcing a lot of whitespace to the right side of the page.
It should scale the video to fit the screen.
Additional Information (eg browser version, screenshots etc):
This can probably be handled by using (and adjusting) the embedresponsibly version of Vimeo's embed code:

I can try submitting a pull request to address this.

I dug more into this. It looks like Materialize offers a "video-container" class that does this same thing. It also looks like an attempt was made to use it previously that had layout issues. I investigated the layout issues and fixed them. Submitting a pull request shortly.


Indentation looks incorrect on the  tag

When you make the
 tag within a table, the auto indentation seems to be incorrect when you hit enter to move the
 tag to the next line.

Is this known/filed on Brackets upstream?  What happens in desktop Brackets 1.2?

It looks like this issue happens on desktop Brackets 1.2, I haven't been able to find this issue filed in Brackets.

@AJDBenner If you can isolate a simple set of STR (steps to reproduce) then you should file it upstream.

The basic premise of this issue is, when you make a  tag with autocomplete, it creates  after your cursor, so when you go to press enter, it puts u in the same column as  so:

thus when you start typing out  you'll be here:

then when you press enter between the  tag it'll end up looking like this:

It seems it might be upstreamable, they could basically just try to detect that you pressed enter within an empty  tag, not sure how complicated that'd be

This issue has been filed upstream https://github.com/adobe/brackets/issues/10770.
Here's a better representation of the issue.

peterflynn took a look at this bug upstream and said it's a bug/missing feature in CodeMirror. He also said it's expected that the opening
 tag is expected to be indented like this.

Do you want to see if it's filed upstream with CodeMirror and file if not?
On Mar 22, 2015 7:57 PM, Andrew Benner<EMAIL_ADDRESS>wrote:
peterflynn took a look at this bug upstream and said it's a bug/missing feature in CodeMirror. He also said it's expected that the opening  tag is expected to be indented like this.

—
Reply to this email directly or view it on GitHubhttps://github.com/humphd/brackets/issues/117#issuecomment-84734655.

This issue is filed in the CodeMirror repo as well https://github.com/codemirror/CodeMirror/issues/3147

I was directed to test this issue here and it doesn't seem to reproduce in codemirror/CodeMirror. This could possibly be that adobe Brackets instance of CodeMirror is pointing to an old commit.

https://github.com/humphd/brackets-browser-livedev/pull/40 fixes this issue.


[FLINK-25445] No need to create local recovery dirs when disabled loc…

…al-recovery in TaskExecutorLocalStateStoresManager
What is the purpose of the change
TaskExecutor will create file, check localRecoveryEnabled and load local state store for each task submission in method localStateStoreForSubtask. For batch jobs, the localRecoveryEnabled is always false, and there's no need to create these local files for task in TaskExecutor
Brief change log
When disable task local recovery, it will not create subtask state dirs.
Verifying this change
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

Could you help review? @dmvk Thanks

Thanks for your review @dmvk
By the way, why we make task local-recovery enabled defaultly? Only due to the uncompatility with unaligned checkpoint?

The behavior of the local recovery highly depends on the state backend. AFAIK heap state backend still doesn't support it. For RocksDB you can find some context in https://issues.apache.org/jira/browse/FLINK-15507

Thank very much @dmvk . I’ll take a look

Updated @dmvk Could you help review again? Thanks

@dmvk Gentle ping. If you have time, could you help review it? At weekends, i will have more time to deal with it.
Thanks

Updated @dmvk. Could you help check again?
Thanks~

Gentle ping @dmvk . Thanks :)

Rebase latest master and squash all commits. @dmvk If you have time, could you help review again? Thanks :)

@flinkbot run azure

@dmvk Gentle ping. Could u help review it ? Thanks


add the ability to roll dice (like !o roll 2d6)

Issue created by faul_sname#7965.

Done!

can be closed


add table for voting nodes

Ditto.

Can you make this a new Diesel migration?
Otherwise LGTM

Cool, thanks. I  added the new migration @FelipeRosa


"https://collector.callstats.io/clockSync Failed to load resource: the server responded with a status of 426 (Upgrade Required)

Details in https://bugs.chromium.org/p/chromium/issues/detail?id=646620
@karthikbr82 could you take a look? The odd thing it seems to affect one device only....

Hi Chris,
We fixed issue yesterday, this was some problem in backend nginx.
Regards,
On Thu, Sep 15, 2016 at 10:21 AM, Christoffer Jansson <
<EMAIL_ADDRESS>wrote:

Details in https://bugs.chromium.org/p/chromium/issues/detail?id=
@karthikbr82 https://github.com/karthikbr82 could you take a look? The
odd thing it seems to affect one device only....
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/webrtc/apprtc/issues/369, or mute the thread
https://github.com/notifications/unsubscribe-auth/AMGrs-QlA6z3ys4r4VWuI35va1M0tcS9ks5qqPH6gaJpZM4J9kVk
.

--
http://www.callstats.io
Analytics and Optimizations for WebRTC.

Great, thanks. Will ask them to retest.

Apprtc calls are now successfully established and no javascript errors are observed on Chrome device Pit with M54.


[WIP] Support Namespace Packages. Part 1: path resolver

This PR adds a structure that holds references to all python modules in a form of a tree that can be searched for packages and names that are available for each import. This is not equivalent to exact set of names, which is affected by previous imports (see, for instance, https://github.com/Microsoft/python-language-server/issues/288#issuecomment-432759994).

Test changes will follow


[moveOnly] Add a semi-generic _copy function similar to the semi-generic _move

The way this works is that:

I added a new instruction called explicit_copy_value. From the perspective of Copy Propagation it is just a copy_value that it can not remove. This ensures that we have a way of explicitly forcing a copy of a value. After ownership is lowered, it just becomes a retain.
I did the same trick that I did with _move to make this function able to be generically used only on values that are not address only (that is not generic or existential). We do this by allowing one level of specialization to occur. We error otherwise since to handle that other case we would need to support opaque values (which we do not yet).

NOTE: I also noted in a different PR I did not make _move public. I did this in this PR as well so we can get both of these operators together. Thanks to @glessard for helping me to catch that!

@swift-ci smoke test

Unhappily, I didn't clang-format this. So I just did that and now need to restart testing =---(.

@swift-ci smoke test


Make prometheus config files configurable

To make the role more reusable, I think we should be able to set user-defined file names for prometheus config and prometheus rules.

target:config


Make metallb setup works with ipv6

This does not work yet for the default domain setup because it also assumed IPv4 https://github.com/knative/serving/blob/2e5d17e9fc8b181f8e89050c447770317d0ebc61/cmd/default-domain/main.go#L219-L225

@tcnghia is this still relevant?


move serf to utilities

... need a look into commit history :wink:

@Moshe-Immerman What is the purpose of this? Why?

@veggiemonk my goal is to reduce the remote container managers/orchestrators down do just orchestrators - but I agree that utilities should be made smaller


Auto authenticate not work as manual login

In my intranet DNN 8.0.4 website, I used MS report RDLC format to export PDF output. The PDF is generated if I login Windows Domain manually, but if my intranet auto LDAP authenticated me, the report RDLC will not create PDF with the error System Security Permissions SecurityPermission. Is there any way possible solution? (ex. force user login to active directory, how to set report RDLC generate PDF without security permission, etc.).  When I try to click at login, the DNN auto authenticated me, and I can't logout. The Window login dialog display after I restart the website.

Reasons:

Enable Integrated Windows Authentication in IE from company.
To generate MS Report RDLC format at server side, the website required manual Windows Authentication login, otherwise, the report will not generated.
Solution:

Use Crystal Reports to generate at server side with Enable Integrated Windows Authentication in IE


Fix typo in "section"

Describe this PR
Fix typo in "section"
Changes

Fixed the typo

Thank you very much for the PR 😊


Separated username and email

Users can create a username when registering a new account

Usernames are used to log in to an account
Usernames can be changed in the profile page

Mentions of 2-factor authentication have been commented out
Mentions of phone number have been removed

Note: The test user still has the username<EMAIL_ADDRESS>but you can try changing it locally via the profile page before merging to make sure it works.


WIP: Togawa28 add advanced features#122

Fix and rebase for #179

Coverage increased (+0.4%) to 77.341% when pulling dfc045e7da7bef583bf8711cf97f83b985f0b74c on jarrodmillman:togawa28-add_advanced_features#122 into d82e0940cdfd809b458308c6e75c982d49593138 on berkeley-stat222:master.


PHP was better than NodeJS

Can't even get this to install on a fresh Debian 8 installation.
root@postleaf:/var/www/postleaf# node app.js
Error: Postleaf failed to start! ð
SequelizeUniqueConstraintError: Validation error
Maybe work on better installation guides?  The PHP version of PostLeaf was easy to install ... so far pretty disappointed in how the NodeJS version is thus far.

Try running gulp build twice, that fixed the problem un my local environment. If that didn't worked download the latest version from alpha.

running it twice did work ... guess thats good; but still way worse and less of a chance i will ever use postleaf in production with the complexity/inconvenience of NodeJS/NPM.

The alpha is intended for developers to work out bugs and improve the build/dist process. By their nature, Node apps are more difficult to install than PHP apps.
We're all learning here, so let's keep a positive tone and work through these early issues. 🙂
Although dev will probably remain the same, I haven't determined what the officially supported process for production will look like. One approach we're experimenting with is with Docker. It's still early, but I encourage anyone with container experience to help us improve it:
https://github.com/lukewatts/postleaf-docker
I'm not saying definitively that we're going to use Docker, but it looks like a promising approach that reduces these types of issues. I'm very much open to suggestions.
Ultimately, the goal is to find a solution that makes it easy and reliable to install Postleaf on a variety of platforms so anyone who wants to DIY can do so.

I've also just finsihed an Ansible playbook which is very straightforward to install and run on Debian/Ubuntu. No prior Ansible knowledge required.
https://github.com/lukewatts/postleaf-playbook

Nice. But by doing a product in docker or ansible will eliminate anyone using shared hosting. I feel that is a bad idea; because users that want something "easy" are also the ones that use shared hosting environments.

@doughnet I don't know of any shared hosts that run NodeJS apps.
I don't think every CMS needs to cater to the lowest common denominator. Nor should they. There are plenty of CMS options already out there that run on shared hosting.
Anyways, this isn't a forum so I'm going to leave it there. Basically if you want to give Postleaf another go you can try the Docker container or the Ansible playbook. If you have issues or questions about those please let me know.


Custom oauth2 error only returns error parameter

Defining input claims of errorCode and errorMessage as described on the page does not work. The error response just contains error=access_denied.
https://github.com/MicrosoftDocs/azure-docs/issues/91205 is an accurate description of what actually happens

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: fd546efd-9728-7a0f-a7cb-221d6ff2a545
Version Independent ID: a40faa51-9d92-b7ae-1f52-7fcfef7059e9
Content: Define an OAuth2 custom error technical profile in a custom policy - Azure AD B2C
Content Source: articles/active-directory-b2c/oauth2-error-technical-profile.md
Service: active-directory
Sub-service: b2c
GitHub Login: @kengaderdus
Microsoft Alias: kengaderdus

@guyaparker
Thanks for your feedback! We will investigate and update as appropriate.

@guyaparker
I'm going to assign this to the document author so they can take a look at it accordingly
@kengaderdus
Could you Please review this and update as appropriate.

@guyaparker
We apologize for the delay in our response. We'll review again, then update our documentation. For now, we'll close this issue, then track it internally. #please-close


EXTERNAL TABLE SUPPORT

Can you add support for external table for SQL API?
CREATE EXTERNAL TABLE cars
USING com.databricks.spark.csv
OPTIONS (path "cars.csv", header "true")

When you specify a path SparkSQL creates the table as external. There is no need for the EXTERNAL keyword.

If I understand correctly, "CREATE TABLE" command creates Hive internal table.
Internal tables work as immutable tables.
Here is an example how to reproduce it.
Initially my S# bucket has one file only

Create table
CREATE TABLE test_table (id string, text string)
USING com.databricks.spark.csv
OPTIONS (path "/mnt/processing/manual_tasks/*", header "true")

SELECT count(*) FROM test_table

Add another file to S3

SELECT count() FROM test_table   return the same number of row as first SELECT count() statement. It means that the new incoming data is not part of the table

If you create a table using "CREATE EXTERNAL TABLE" command, the new incoming data will be part of the table
CREATE EXTERNAL TABLE test_table (id string, text string)
USING com.databricks.spark.csv
OPTIONS (path "/mnt/processing/manual_tasks/*", header "true")

SparkSQL caches meta data about tables created using data sources (such as spark-csv), therefore it is necessary to call "REFRESH TABEL" with SparkSQL. Hive does not have this issue because it does not have the metadata cache.

spark-csv creates an INTERNAL HIVE table
REFRESH TABLE doesn't work also.
CREATE TABLE test_table(id string, text string)
USING com.databricks.spark.csv
OPTIONS (path "/mnt/testdata/*", header "true")

OK

DESCRIBE test_table

Registered as a temporary table	null	null
id	StringType	null
text	StringType

REFRESH TABLE test_table

Error in SQL statement: java.lang.RuntimeException: org.apache.spark.sql.hive.HiveQl$ParseException: Failed to parse: REFRESH TABLE test_table

Are you running Spark 1.3?

It's Spark 1.2. Databricks cloud is going to be updated to Spark 1.3 next
week.
On Sat, Apr 4, 2015 at 1:02 AM, Hossein Falaki<EMAIL_ADDRESS>wrote:

Are you running Spark 1.3?
—
Reply to this email directly or view it on GitHub
https://github.com/databricks/spark-csv/issues/45#issuecomment-89505501.

--
Best regards,
Sergey Semichev

Spark 1.3
"CREATE TABLE" command creates an external Hive table.
New incoming data are visible without "REFRESH TABLE"
"REFRESH TABLE" command works

No it doesnt for me, dont know where I am wrong :

hdfs.mkdirs('/some/dir')
create external table partition on dt loc '/some/dir'
spark write in parquet ('/some/dir/dt=20150909')
alter table add partition dt = '20150909' etc etc => throws
alidationFailureSemanticException table is not partitioned but partition spec exists: {dt="20150909"}


Non-output function parameters can be modified

From a bug report to the Blender bug tracker by Michel Anders.
int refinc(int n)
{
    n = 0; // n is not marked as output so this should be illegal
    n++;   // ditto
    return n;
}

shader test()
{
    int h = 0;
    refinc(h);
    printf("%d\n", h);
}

If you run this compile and run shader, it will print 1, but actually modifying n in refinc should not be allowed, according to section 4.4 of the specification, so it should give a compile error.

Parameters to functions are similar to shader parameters, except that they do not permit initializers. A function call must pass values for all formal parameters. Function parameters in Open Shading Language are all passed by reference, and are read-only within the body of the function unless they are also designated as output (in the same manner as output shader parameters).

This was fixed for OSL 2.0. It's a warning now (and an error if you compile with -Werror). Closing.


Issue 51

Wait for Issue 49 to be merged before reviewing

Blackduck scan failure details
Summary: 0 violations, 1 file pending approval, 0 files pending identification.

Protex Server Path: /home/blackduck/github/tasecureapi/53/rdkcentral/tasecureapi

Commit: 8656e334d52086e14a8238b516f765b55f8df0f5

Report detail: gist


Syntax changed?

Before a few weeks ago, I used tunnel.tunnel to map remote port to localhost. However, now the docs suggest to do just tunnel. However, when I just do tunnel instead of tunnel.tunnel, it gives me this error:
tunnel(config, function(e, sshTunnel) {
^

TypeError: tunnel is not a function

However, when I use tunnel.tunnel instead, it doesn't give a syntax error -- but, the callback in the function is not called at all.
I'm using version 3.2.1-beta. Is this a version issue?

Yes it is, please update to version4.


[Bug]: dlib.DLIB_USE_CUDA is true, but uses CPU inference

What Operating System(s) are you seeing this problem on?
Linux (x86-64)
dlib version
19.24.99
Python version
3.9
Compiler
gcc 10.2.1
Expected Behavior
Load the dlib using the GPU and reason
Current Behavior
I installed the cuda version of dlib, but it uses CPU inference
Steps to Reproduce
I used the following statement to install dlib
git clone https://github.com/davisking/dlib.git
cd dlib
mkdir build
cd build
cmake .. -DDLIB_USE_CUDA=1 -DUSE_AVX_INSTRUCTIONS=1
cmake --build .
cd ..
python setup.py install --set USE_AVX_INSTRUCTIONS=yes --set DLIB_USE_CUDA=yes

test:
python import dlib print(dlib.DLIB_USE_CUDA) print(dlib.cuda.get_num_devices())
The result is true and 4
But when I used DLIB to detect faces, I found that it wasn't using Gpus, none of the Gpus were being used, and I had 4 cards
Anything else?
no

We need more details:

which detector are you using? dlib ships with two, but only one of them uses the GPU.
during the build, did you see the message DLIB WILL USE CUDA? If you didn't, there's something wrong with your CUDA installation.

We need more details:

which detector are you using? dlib ships with two, but only one of them uses the GPU.
during the build, did you see the message DLIB WILL USE CUDA? If you didn't, there's something wrong with your CUDA installation.

We need more details:

which detector are you using? dlib ships with two, but only one of them uses the GPU.
during the build, did you see the message DLIB WILL USE CUDA? If you didn't, there's something wrong with your CUDA installation.

I'm the second reason. It's been taken care of. Thank you


Leptos Integration

Hi @photino
Are you planning to integrate with Leptos? For SSR use.

I don't know how to integrate with Leptos, since it does not provide a Router type. The integration with Dioxus works only since 0.4 because the Router is not used in a macro.


Add support for passing arguments to constructors by ref

Currently these are not found.
This is also an opportunity to consolidate the two implementations to match parameters for methods and constructors.

Well looks like this is currently not possible, and I'm not sure how to implement it.
Test case:
object obj = new object();

var type = typeof(TypeWithByRefConstructor).AsDynamicType();
var instance = type.New(ref obj);

Assert.NotNull(instance);

This will result in a MethodNotFoundException because the New(params object[] args) is not matched by the dynamic runtime, so it calls the TryInvokeMember method instead. Now, we can't call a method named New() when we went through AsDynamicType(), so we could special case this to look for constructors but I'm not really warming up to that idea.
I expect that I will leave this case unsupported for now and maybe revisit this some other time. I suspect that this is not a feature that will be used a lot (if at all).

I am leaving this scenario unsupported for now.


I'm trying to send IOTX to ioPay Desktop wallet using the Account Address under Action History in the wallet and I keep getting an error message that it's an invalid address. Please advise

I am trying to send IOTX to ioPay Desktop wallet using the Account Address under Action History in the wallet and I keep getting an error message that it's an invalid address. Can anyone advise me on this?

having the same issue

I tried sending IOTX from Coinbase to the ioPay desktop wallet using the Iotex address, and that address was refused.  I then tried the corresponding Web3 address from the Iotex explorer, and that worked, but the ioPay wallet doesn't see the tokens at the Web3 address yet.

https://community.iotex.io/t/official-ledger-hw-wallet-thread/1132

please send to<EMAIL_ADDRESS>for help.


Make selector negation more sophisticated

Think about this some more, including possible some heuristics
And examining the produced selectors

I actually think that improvements in use :any will substantially improve this.
Also, depending on results after adding :any I shall have a think about
negation specifically in relation to the LCS algorithm and see if there isn't some other
way we can improve it as well

Acutally I think the best way to do this is synthetically.
Yes, there is probably some way to capture any arbitrary negation ( of sets ) like
S - A - B - C ( S without A,B or C) using CSS selectors with :any()
But why not just make it synthetic?
As in
Store:
{
   add: [ S ],
   subtract: [ A, B, C ]
}

And then run querySelectorAll on each of these, and perform the subtraction with the resulting sets.

Okay, I'm gonna open a new issue for implementing this.


Update README.md to match new deploy scripts

@ycao56 Do the scripts need a Red Hat copyright on them? I could put that in this PR if so...

I don't really. Let's just keep it as is.


🐛 Bug Report: Support button on domains tab in Explore plugin wraps oddly

📜 Description
The support button on the explore page for domains has a very odd line break that I can't explain.
👍 Expected behavior
I would expect the sentence "Explore the domains in your ecosystem" to be listed on one line, like other support buttons and the  other two pages in the explore page.
👎 Actual Behavior with Screenshots

Domains
Tools
Groups

👟 Reproduction steps

Go to Demo site: http://demo.backstage.io
Go to Explore page: https://demo.backstage.io/explore/domains
Click the Support button at top right

📃 Provide the context for the Bug.
I thought I'd go try to fix this, but I actually can't figure out what is going wrong!
The relevant code is here:
https://github.com/backstage/backstage/blob/8444b0834f99233cd1ebca7e875b53902f884d1c/plugins/explore/src/components/DomainExplorerContent/DomainExplorerContent.tsx#L92
Which looks simple enough. So then I thought, maybe there's a bug in the SupportButton component?
And the SupportButton component here:
https://github.com/backstage/backstage/blob/8444b0834f99233cd1ebca7e875b53902f884d1c/packages/core-components/src/components/SupportButton/SupportButton.tsx#L150-L154
Interestingly, if I wrap the child like [ {child} ] then the button displays like,
[Discover the ]
[domains ]
[in your ecosystem]

So it seems like perhaps the loop is breaking up the sentence as different React child nodes?  But this DOESN'T seem to happen with this:
https://github.com/backstage/backstage/blob/8444b0834f99233cd1ebca7e875b53902f884d1c/plugins/explore/src/components/ToolExplorerContent/ToolExplorerContent.tsx#L73
:shrug:
🖥 Your Environment
Here's my info, but this happens as well if I clone off backstage/backstage and I can see it in your deployed demo.backstage.io app.

OS:   Darwin 22.4.0 - darwin/x64
node: v18.15.0
yarn: 1.22.10
cli:  0.22.6 (installed)
backstage:  1.13.0
Dependencies:
@backstage/app-defaults                          1.3.0
@backstage/backend-app-api                       0.4.2
@backstage/backend-common                        0.18.4
@backstage/backend-dev-utils                     0.1.1
@backstage/backend-plugin-api                    0.5.1
@backstage/backend-tasks                         0.5.1
@backstage/catalog-client                        1.4.1
@backstage/catalog-model                         1.3.0
@backstage/cli-common                            0.1.12
@backstage/cli-node                              0.1.0
@backstage/cli                                   0.22.6
@backstage/config-loader                         1.2.0
@backstage/config                                1.0.7
@backstage/core-app-api                          1.7.0
@backstage/core-components                       0.13.0
@backstage/core-plugin-api                       1.5.1
@backstage/errors                                1.1.5
@backstage/eslint-plugin                         0.1.3
@backstage/integration-aws-node                  0.1.2
@backstage/integration-react                     1.1.12
@backstage/integration                           1.4.4
@backstage/plugin-api-docs                       0.9.2
@backstage/plugin-app-backend                    0.3.44
@backstage/plugin-auth-backend                   0.18.2
@backstage/plugin-auth-node                      0.2.13
@backstage/plugin-catalog-backend-module-github  0.2.7
@backstage/plugin-catalog-backend                1.9.0
@backstage/plugin-catalog-common                 1.0.13
@backstage/plugin-catalog-graph                  0.2.29
@backstage/plugin-catalog-import                 0.9.7
@backstage/plugin-catalog-node                   1.3.5
@backstage/plugin-catalog-react                  1.5.0
@backstage/plugin-catalog                        1.10.0
@backstage/plugin-circleci                       0.3.17
@backstage/plugin-events-node                    0.2.5
@backstage/plugin-explore-backend                0.0.6
@backstage/plugin-explore-common                 0.0.1
@backstage/plugin-explore-react                  0.0.28
@backstage/plugin-explore                        0.4.2
@backstage/plugin-github-actions                 0.5.17
@backstage/plugin-home                           0.5.0
@backstage/plugin-org                            0.6.7
@backstage/plugin-permission-common              0.7.5
@backstage/plugin-permission-node                0.7.7
@backstage/plugin-permission-react               0.4.12
@backstage/plugin-proxy-backend                  0.2.38
@backstage/plugin-scaffolder-backend             1.13.0
@backstage/plugin-scaffolder-common              1.2.7
@backstage/plugin-scaffolder-node                0.1.2
@backstage/plugin-scaffolder-react               1.3.0
@backstage/plugin-scaffolder                     1.13.0
@backstage/plugin-search-backend-module-catalog  0.1.0
@backstage/plugin-search-backend-module-explore  0.1.0
@backstage/plugin-search-backend-module-pg       0.5.5
@backstage/plugin-search-backend-module-techdocs 0.1.0
@backstage/plugin-search-backend-node            1.2.0
@backstage/plugin-search-backend                 1.3.0
@backstage/plugin-search-common                  1.2.3
@backstage/plugin-search-react                   1.5.2
@backstage/plugin-search                         1.2.0
@backstage/plugin-tech-radar                     0.6.3
@backstage/plugin-techdocs-backend               1.6.1
@backstage/plugin-techdocs-module-addons-contrib 1.0.12
@backstage/plugin-techdocs-node                  1.7.0
@backstage/plugin-techdocs-react                 1.1.5
@backstage/plugin-techdocs                       1.6.1
@backstage/plugin-user-settings                  0.7.2
@backstage/release-manifests                     0.0.9
@backstage/test-utils                            1.3.0
@backstage/theme                                 0.2.19
@backstage/types                                 1.0.2
@backstage/version-bridge                        1.0.4
✨  Done in 1.44s.
👀 Have you spent some time to check if this bug has been raised before?

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

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, but I'm happy to collaborate on a PR with someone else

Yep that's silly, thanks for reporting. Iterating the children like that was probably not an awesome idea, but did the immediate fix for now. ^


loader with subscription mode poll

If I have the poll mode in the subscription configuration it cant load the targets from a file with the following error
gnmic-1    | Error: failed reading targets config: failed reading targets config: no targets found
The relevant configuration is
loader:
  type: file
  # path to the file
  path: /app/targets.yaml
  # watch interval at which the file
  # is read again to determine if a target was added or deleted.
  interval: 300s
  # if true, registers fileLoader prometheus metrics with the provided
  # prometheus registry
  enable-metrics: false

subscriptions:
  show_version:
    paths:
      - "cli:/show version"
    mode: POLL
    stream-mode: sample
    sample-interval: 30s
    encoding: json

If I am using a different subscription in mode stream it load the targets correctly
  optics_dom:
    paths:
      - "components/component/transceiver/physical-channels/channel/state/"
    stream-mode: sample
    sample-interval: 300s
    mode: STREAM

I'm not sure what the expectation is here but poll subscriptions are not supported when running gNMIc in daemon mode. The poll subscription has to be triggered by the client, there is no way to do that except when running in cli mode.
The error you see is due to gNMIc ignoring the loader section if the subscription has mode: poll.
If you expect gNMIc to run a poll subscription "periodically", that is not supported.


discussion: Roadmap

Sharing a bit of a higher level overview currently only in my brain so all
y'all know what's going on:
3.0 Use CPS

get nested effects and error / value propagation
streamline view api
trim bytes by making yo-yoify applicable

3.1 Performance

add request animation frame to cap updates and better handle burst updates
provide standalone bundles for inclusion in codepen and the like

3.2 Plugins

app.use() API (oh god)

3.2.1 fix path triggers

fix the send(location:href) call

3.3 Custom async paradigms

provide wrap hooks so alternative async implementations become
first-class citizens (e.g. choo-pull, choo-xstream, choo-rxjs, etc.)

4.0 Routing

upgrade sheet-router to handle hash routes by default; would make
handling routes a complete no-brainer (it can be a bit tricky rn when using
both hashes and normal routes)
update sheet-router to no longer use route()

4.1 Components
This is where we add one of the last large feature additions: choo/component.

add choo/component based on nanocomponent
replace const with var, all the way down

5.0 polish mode
I think at this point choo is quite stable. The syntax will probably not
change; we'll just keep making things smaller and faster.

switch over to nanomorph
allow querystrings to become part of routes
remove on-load from choo/html now that it's part of choo/component
remove prev from elements as nobody uses it anyway
change stack trace callback to keep history inside hooks

5.1 / 6.0 threads

use threaded effect and reducer execution using webworkers

Goals not (yet) bound to roadmap

[ ] look into trimming all .forEach() and .map() calls and replacing them
with ES3 equivalents - speed and less array allocations ftw
[ ] get (dev)tools out there that can visualize all action calls and lay
them out visually - would make debugging silky smooth
[ ] add a whole bunch of benchmarks so we know how choo is doing compared
to itself

Should choo include some way to wrtie plugins and/or mixins? I'm thinking in other frameworks that allow to write some sort of custom extensions, like Vue does

@YerkoPalma maybe? I wonder what kind of functionality you'd like to see that cannot be done with any of the existing / proposed hooks

@yoshuawuyts haha yeah. I was thinking something like that. The plugins/addons/mixins or whatever you call it could allow to.

Wrap some other libraries:

const chooFire = require('choo-fire')

// Wrap some firebase bindings and stuff
const app = choo()
app.use(chooFire)

Extend the actual choo schema

// extend just the model
app.model({
  state: {}
  style: { // this is a new one
    color: 'blue'
  }
})

// add a new function
app.test(avaChoo)

Replace some of the actual libraries used by choo (? I'm not pretty sure about this one :smile: )

// use flux as state manager
app.use(flux)

So, what do you think? are those good use cases? Is this be too hard to achieve?

@YerkoPalma hmm, so one of the things I like about choo is that we focus on modularity; once something is built it shouldn't be hard to break out. As a design pattern I'd prefer people create as many standalone widgets / sdks / purely functional components that reduce the need of glue as much as possible. I feel like extending the choo schema or adding methods might work against that goal.
Any customizations currently go through the hooks in const app = choo(); with possibly more hooks being added in #145 and #155. I feel that by improving the experience of using that functionality we might make it more pleasant to extend; but we must also steer clear of making it easy to modify choo - I really want to keep choo as dispensible as possible, not making people go down the road again of tying into a sticky framework that's hard to break out of.
Does that make sense?

I totally miss the async wrapper idea, it sounds good :+1: Well, thats why I was asking, I think that plugins are needed when the library is like a blackbox, but whene is easy to hack the core I guess they are not useful. If I found myself with a real world use case I'll let you know.

Just a friendly reminder plugins == peer dependencies and is why I down voted :)

@shama ah yeah, that's a solid point. What do you think of using .use() to streamline the usage of certain wrappers / handlers like in my example? It wouldn't expose new functionality, mostly drop handlers inside or an array rather than needing to combine them manually in the app() call.
I think to some extent peer dependencies can't be avoided, but I'm 100% with you that they should leak as little as possible into the application logic itself

@yoshuawuyts My primary worry is plugins creating flavored elements; elements that only work with some choo plugin enabled. My secondary worry is the ecosystem creating choo plugins which could have been just regular modules accessible to everyone.
Plugins by their nature are convenient and is why every framework implements an API for it. But my goal has been to try something different then what everyone else currently does. I want to see if a client side ecosystem can be built without peer deps.
Just my 2 cents, but what if we tried to achieve the individual desired app behaviors (logger, devtools, etc) without a plugin system first. Then fallback to implementing a plugin API if the behavior is useful and deemed impossible without it?

in case this helps anyone's thinking:
the approach i'm taking with the very similar project inu is that an inu app is really just a data structure, so it's possible to create plugin-y things with a function that takes your new flavored app and returns a plain inu app. for example, a function that takes choo models and returns an inu app would be awesome. :smile: in theory (awaiting more empirical experiments), this means that if you do want to make a re-usable micro-app in some sugary flavor (or maybe you like spicy), you just need to use your special function before you export the common flavor, so no peer dependencies! same goes for developer features like logging or devtools, they are just a function you call on the top-level app before starting it.

I just added an unbound agenda item for investigating using webworkers to move as much logic off main-thread as possible.
Right now there are no libraries that ship with an off-thread renderer implementation (rumor has it that angular2's webworker is mostly abandoned and might not make the ng2 cutoff).
This is something I think we could really accomplish.  We'd have to make some changes to morphdom to help us enable this -> the ability to extract a diff of the dom (which is actually provided via global/document in the web worker context) and then applying that dom patch to the real dom.
Ideally I'll have some time in the future to start seeing how this could be added to morphdom. We might have bubble up some of this implementation from yo-yo, but this also means the entire TCBY ecosystem could hook into this feature!

I really like the idea of using web workers in choo by default (or as an option). I'm just trying to develop something to make a pwa with choo, and in my research I found the pokedex.org app which is exactly what I was looking for. In the post about pokedex the author describes how he used web workers to manage the diff between the dom, so that app and specially the post, might be a good place to start looking at

@yerkopalma I have talked to @nolanlawson a few times re: web workers and choo (and he has said he's looking into choo a little!).
I know there was some hacking done for the pokedex stuff in terms of the diffing; might be interesting to see if we could use the same serialization format for morphdom that he implemented for vdom.
But it might be worthwhile to see if he has any suggestions of recommendations about this topic :)

Yeah this is a super under-researched area, but I did implement vdom-serialized-patch as a solution for virtual-dom anyway.
Best advice I can give is that you need to architect it such that the perf gains of multithreading are not outweighed by the cost of serializing and sending messages to the worker. I wrote about this a bit but to sum up:

Send stringified JSON in postMessage()
Batch the messages
Make the messages as small as possible

Also this works best when basically the entire app lives inside the web worker because otherwise you are sending messages back and forth from the worker to the main thread constantly.
There's also some research from Parashuram and from Chris Thoburn.

Ah no, fair enough then - I thought literally nobody was using it so then
it wouldn't make sense. But if both of you are well thennnn, yup maybs we
should hold off on it (:
On Sat, Jan 7, 2017 at 3:59 PM Arve Knudsen<EMAIL_ADDRESS>wrote:

@yoshuawuyts https://github.com/yoshuawuyts You mean removing the prev
argument to render functions? I use it sometimes, for example to compute
diffs between previous and current state in order to update D3 graphs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/yoshuawuyts/choo/issues/152#issuecomment-271088382,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACWlej-8pEFd7XJLoSCnx3J6dNjP3A74ks5rP6hBgaJpZM4JI16J
.

lmao, we're diverging so much from this rn - current status https://github.com/yoshuawuyts/playground-nanoframework

Pretty much everything on the roadmap is done. Closing because choo@5 will introduce a new API. See #425 for the merged PR. Thanks!


Category container is really big when no media is shown.

This was most likely introduced in https://github.com/google/web-stories-wp/pull/4115. When we fix this, we should double check in Safari as flexbox apparently behaves quite differently there (this issue might not even be happening there!)


OpenAPI 3.0 - Add support for root/top/global level tags

https://swagger.io/docs/specification/grouping-operations-with-tags
#87
I followed the current pattern of adding global tag functionality as an option. I can change it to always handle global tags if preferred.

Glad to see this PR approved. I'd love to have it. Is there anything blocking it being merged and released?


GUVNOR-2507: Guided Decision Table Editor: Add ability to open multiple decision tables in the same view

See https://issues.jboss.org/browse/GUVNOR-2507
This PR adds a UberView<P> equivalent for use with Element based Views and allows me to override a couple of bits in LockManagerImpl in a subclass I have in drools-wb (where I only want to fire the UpdatedLockStatusEvent if the lock has changed for the visible/active document - tied to opening multiple decision tables in the same editor).

Part of an ensemble:-
https://github.com/uberfire/uberfire/pull/387
https://github.com/droolsjbpm/kie-wb-common/pull/382
https://github.com/droolsjbpm/drools-wb/pull/194

+1


Patch for /TODO

dannsoon on 10 Aug 2012 at 9:37:
vsvfdvbdsf

Successfully auto-migrated from code.google.com:
https://code.google.com/p/google-api-go-client/issues/detail?id=13

Closing.  Nothing here.


panic: dial tcp [::1]:1883: getsockopt: connection refused

Just running through the setup process on the Wiki, and the process is failing to start with the following errors, any idea what could be causing the issue, port 1883 is open?
pi@raspberrypi:~ $ /home/pi/presence/presence -http_host_path=<IP_ADDRESS>:5555
panic: dial tcp [::1]:1883: getsockopt: connection refused

goroutine 1 [running]:
panic(0x390328, 0x10768750)
	/code/go/go/src/runtime/panic.go:481 +0x330
main.main()
	/code/happy-bubbles/presence-gh/main.go:608 +0x5d4

Ok, so it seems the install script installs and user Mosquito, I already have Mosquito installed, but running on a different port. I have now manually updated the port to 1883, and I no longer get that error, but I now get the following one, any ideas?
● presence.service - presence
   Loaded: loaded (/etc/systemd/system/presence.service; enabled)
   Active: failed (Result: start-limit) since Tue 2017-04-18 14:27:25 UTC; 19s ago
  Process: 1037 ExecStart=/home/pi/presence/presence -http_host_path=<IP_ADDRESS>:5555 (code=exited, status=2)
 Main PID: 1037 (code=exited, status=2)

Apr 18 14:27:25 raspberrypi presence[1037]: main.main()
Apr 18 14:27:25 raspberrypi presence[1037]: /code/happy-bubbles/presence-gh/main.go:647 +0xc00
Apr 18 14:27:25 raspberrypi systemd[1]: presence.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Apr 18 14:27:25 raspberrypi systemd[1]: Unit presence.service entered failed state.
Apr 18 14:27:25 raspberrypi systemd[1]: presence.service holdoff time over, scheduling restart.
Apr 18 14:27:25 raspberrypi systemd[1]: Stopping presence...
Apr 18 14:27:25 raspberrypi systemd[1]: Starting presence...
Apr 18 14:27:25 raspberrypi systemd[1]: presence.service start request repeated too quickly, refusing to start.
Apr 18 14:27:25 raspberrypi systemd[1]: Failed to start presence.
Apr 18 14:27:25 raspberrypi systemd[1]: Unit presence.service entered failed state.

 Can you subscribe to topics on your MQTT normally with the mosquitto_sub command?
The Presence server is trying to subscribe to happy-bubbles/ble/# where it crashed for you. Try to subscribe to it on port 1883 with no username/password using mosquitto_sub to figure out what might be happening.
But if you need a special port or something, run /home/pi/presence/presence -h and you'll see other command-line options you can pass to it to tell it to connect to a different server or port if you want.


Fix rhel build

rpmbuild on CentOS 6 is broken for two errors, detailed error messages can be found in each commit message. The first one, cannot remove <directory>: no such file or directory, can be securely fixed by patch 1.
But for the second one, File not found, I'm not sure the cause of the error, it's weird those binaries/man pages can't be found after the build succeeded. I guess those binaries are no longer being distributed, but the rpm build spec was left out-dated, if this is the case, then the second patch can be securely applied.

Here is some feedback via IRC.  "blp" is me, "fbl" is Flavio Leitner, a Red Hat employee:
blp: fbl: Any chance you could take a look at these rhel fixes? https://github.com/openvswitch/ovs/pull/65
blp: fbl: I find them a little puzzling because it seems like multiple users would be reporting them.
switchcade: incidentally, that pull request reports travis failures but they seem to be unrelated. I suspect no-one's followed up on travis failures in the last week or so.
blp: switchcade: You're probably right. If I could get travis to email me, I'd check on failures, but it's frustratingly unwilling to do that.
fbl: blp: I am not building rpm on centos6, but the rm command could be fixed to use -f or simply remove the missing files.  In the other patch, there is no reason to comment out a file that doesn't exist (assuming it's not broken), just take them out.
blp: fbl: I guess I don't see why the situation would be different here on RHEL vs. Centos or 6 vs. other versions.
fbl: blp: most people is probably using rhel7/centos7/or fedora14 and above, and then the openvsiwotch-fedora.spec is better.
blp: fbl: I didn't realize that. Thanks.
fbl: which is the one I am using to keep fedora and RHEL 7/OSP

Thanks for the feedback. Are the missing files

/usr/bin/ovs-parse-backtrace
/usr/bin/ovs-pcap
/usr/bin/ovs-tcpundump
/usr/bin/ovs-vlan-test
/usr/sbin/ovs-bugtool
/usr/share/man/man8/ovs-bugtool.8.gz
/usr/share/openvswitch/bugtool-plugins
/usr/share/openvswitch/python
/usr/share/openvswitch/scripts/ovs-bugtool-*
/usr/share/man/man1/ovs-sim.1.gz

really supposed to be missing? Sounds true for me based on Flavio's words. Just to make sure.
If it's true, I'll check rhel/openvswitch.spec against openvsiwotch-fedora.spec which is considered to be better and update my PR to remove those lines rather than commenting it out. Is that ok?

I guess that they are supposed to be missing because openvswitch-fedora.spec marks them as %exclude.  I don't know why they are excluded--looking back in the history, I see that they were excluded from the point that they were introduced.
I guess it might be worth asking on ovs-dev why these files are not packaged.  They are packaged in Debian, except for ovs-sim, which isn't meant to be installed at all.

Also fixed a new error when building kmod rpm.
I'll submit a patch hours later and see what ovs-dev will say about the missing files.

fixed with f929235bbe71e2abf330eaf93068b9814a6a2d4b and 43b6e7ca4c70c7fc0dfad0de49b1d907f4068289


Metadata

Message size 1024 -> 1023

In this case is correct 1024. TransferTransaction Message is 1023 because there is 1 byte reserved for the message type: https://nemtech.github.io/concepts/transfer-transaction.html#message-type


Focus on new section when created

What is the context of this PR?
Trello
Uses scrollIntoView to ensure any new items (section or pages) are scrolled into view of the questionnaire nav when added.
How to review
Add a variety of sections and pages from different starting scroll positions.

 Focus on new section when created (2)


fix: column parsing to include nested columns and  enclosing to adopt…

Description
Column parsing to include nested columns and `` enclosing to adopt 0.18.x)

Is meant to address https://github.com/delta-io/delta-rs/issues/2572


Switch to use independent classes to represent each state of parsing is succeed or not

Hi, @wavebeem !
I've read your implementation and most of design is looking good to me. IMHO, checking parsing state with string is not bad, but class-level type checking looks more sufficient and clean for me. I mean ParseOK<T> or ParseFail can be defined as classes, not as simple data structure, and it would be better for developer because easily understandable.

Hi @minamorl!
Thanks for reading 😄
I used to have classes for everything, but I changed the design.
New style
if (result.type === "ParseOK") {
  // ...
}

Old style
if (result.isOK()) {
  // ...
}

Alternative Old Style
if (result instanceof ParseOK) {
  // ...
}

I thought that using a type with | and no methods was easier to understand. If
it is a class instead, people will want various methods on it, I think.
I decided to only use classes for things that needed methods for readability
(Parser and Context).
You can see the old design with classes here: https://github.com/wavebeem/bread-n-butter/tree/a2f1fd9d143fa3a9541bc83c627b09e8b213ad3d/src

Thanks for quick and detailed reply. I read those old code and understand why you choose current design. In TypeScript world, that works perfectly I guess.
My concern is that people who use the ES as it is are not given the benefit of types. It might be a niche for a use case but from that point of view I prefer the old style. How do you think? :)

I think the new style is easier for plain JS users for a few reasons:

Using instanceof is not common in JS.
Using .isOK() method is not common in JS either. And you have to look at the prototype to see the method exists.
Using .type === should be easy to discover by looking at console.log(result) output.

I like both styles, but I think plain Object style will be easier to learn than custom classes.

Using .isOK() method is not common in JS either. And you have to look at the prototype to see the method exists.

As you mentioned, it requires looking up to the prototype and the cost developers pay will be mostly same as using plain object (or higher because of console logging issue). Thank you for sharing your thoughts on this. You can close this issue. 👍

Hi @wavebeem,
Why not defining a type guard, which could be useful for both Typescript and Javascript users ?
function isParseOK<T>(result: ParseOK<T> | ParseFail): result is ParseOK<T> {
  return result.type === "ParseOK"
}

As a side note, I wanted to tell you that I just successfully ported a small Parsimmon-based project to BnB… :smile:

EDIT: This is actually totally useless because both types contain type which is discriminent…

Yeah I initially thought about making one of these, but you don't need it as you found out 😄

As a side note, I wanted to tell you that I just successfully ported a small Parsimmon-based project to BnB… 😄

Oh cool! If you have any thoughts or feedback, please open an Issue and tell me 😄


[BACKLOG-35398] - Update README JDK to 11

:white_check_mark: Build finished in 1m 45s
Build command:
mvn clean verify -B -e -Daudit -amd

:exclamation: No tests found!
:information_source:  This is an automatic message


Generate PDF

Hi @cgachot,
Thanks for integrating these changes and fixing the remaining bugs for python3 and such :+1:
I tested it for our use-case and everything still works like a charm.
Cheers,
Gabriel


Extend functionality of the dylint to allow Debug formatting in trace-level logs

It's generally reasonable to allow Debug formatted data in trace! statements, since these are expected to be verbose and aren't particularly user-facing.
We could either have the dylint ignore all trace-level logs, or an allow could be provided to have the lint not check the associated statement.

Closing as this can be achieved via e.g.
// trace-level logging, so using Debug format is ok.
#[cfg_attr(dylint_lib = "tracing_debug_field", allow(tracing_debug_field))]
{
    trace!(?response);
}


MAINTAINERS: add danieldegrasse to display collaborators

Add myself to display collaborators list to aid in reviewing PRs, as I have been working with SPI based and parallel displays within Zephyr

Adding DNM until @jfischer-no has a chance to review


fix(examples): Remove conflicting React type definitions

What this PR solves

It solves the jsx type error problem in certain examples of official documents.

Type Error List

fixed
dynamic
table
window

Summary

I think the problem is that the type definition is duplicated.

Steps to Reproduce

Go to the example project page of the official document created above.
The package goes down and waits to run.
Check the type error in the jsx part.

How to Test the Solution
git clone https://github.com/TanStack/tanstack.com.git

cd ./tanstack.com

Go to the file
- app/routes/$libraryId.$version.docs.framework.$framework.examples.$.tsx

Change the value of the 'stackBlitzUrl' variable to
  'https://stackblitz.com/github/SaeWooKKang/virtual/tree/main/examples/react/fixed?embed=1&theme=light&preset=node&file=src/main.tsx'.

pnpm install

pnpm dev

Check example in browser

@piecyk Thank you for your quick feedback.
As you said, I corrected it by referring to the example and confirmed that it worked properly. Should I correct other examples that do not have errors for consistency?

@piecyk Thank you for your quick feedback. As you said, I corrected it by referring to the example and confirmed that it worked properly. Should I correct other examples that do not have errors for consistency?

Yes, please 🙌

@piecyk Thank you for your quick feedback. As you said, I corrected it by referring to the example and confirmed that it worked properly. Should I correct other examples that do not have errors for consistency?
Yes, please 🙌

@piecyk When I set the tsconfig.json to strict: true, there are errors in components that have not been interface-defined. How should I fix it?

set strict:false, modify it in another pr
set strict: true, define interface


how to increase the judge whether root or mobile phone jailbreak function

how to increase the judge whether root or mobile phone jailbreak function

Please use the provided issue template