The model is not working using pre-resized images

In order to train the model, each initial raw image is resized to 100x100px and then reshaped.
I created a script to preprocess all the raw images. If you run it, it's going to resize all images (train and validation sets). For example, from the image data/raw/train/n03445777/ILSVRC2012_val_00002314.JPEG  is going to create this one:  data/prepared/train/resized/n03445777/ILSVRC2012_val_00002314.png` (100x100px)
The script to generate the resized images is:  python3 src/prepare_images.py
The problem is it seems it does not work. Running the evaluation script (python src/evaluate.py) I get only 50% accuracy.

I have added a long explanation for the issue and how I solved it here: https://github.com/josecelano/data-version-control/blob/master/docs/preparing-images-for-training.md


Add richer logging to container-app-operator

Fixes #43.
Added logs to be more detailed and chained together for easier debugging and tracebacks.

Overall looks fine, need to be tidy it up a bit with redundant spaces and inconsistent naming

Few small bits and we can merge

/lgtm
/approve


feat(LinearAlgebra/PiTensorProduct): make reindex dependently typed

used to be (⨂[R] _ : ι, M) ≃ₗ[R] ⨂[R] _ : ι₂, M, now M can vary according to the indexing set.

Thanks!
bors d+

bors r+


Identify Improvements (dev)

Codecov Report

Merging #731 (7a01168) into dev (945f846) will decrease coverage by 1.73%.
The diff coverage is 54.92%.

@@            Coverage Diff             @@
##              dev     #731      +/-   ##
==========================================
- Coverage   76.19%   74.46%   -1.74%
==========================================
  Files         135      127       -8
  Lines       12784    12156     -628
==========================================
- Hits         9741     9052     -689
- Misses       3043     3104      +61

Impacted Files
Coverage Δ

assemblyline/common/codec.py
0.00% <0.00%> (ø)

assemblyline/common/identify.py
45.88% <54.80%> (-7.75%)
:arrow_down:

assemblyline/common/forge.py
90.69% <100.00%> (+2.12%)
:arrow_up:

assemblyline/cachestore/__init__.py
67.27% <0.00%> (-7.28%)
:arrow_down:

assemblyline/filestore/__init__.py
83.88% <0.00%> (-3.34%)
:arrow_down:

assemblyline/common/str_utils.py
80.36% <0.00%> (-2.46%)
:arrow_down:

assemblyline/common/exceptions.py
85.71% <0.00%> (-2.39%)
:arrow_down:

assemblyline/common/heuristics.py
84.78% <0.00%> (-2.18%)
:arrow_down:

assemblyline/odm/random_data/__init__.py
87.31% <0.00%> (-1.92%)
:arrow_down:

assemblyline/filestore/transport/local.py
91.48% <0.00%> (-1.07%)
:arrow_down:

... and 10 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 945f846...7a01168. Read the comment docs.


Using encodeURI breaks some URLs

Background:
Since PR https://github.com/remy/inliner/pull/103 URLs are passed through encodeURI in get.js:
https://github.com/remy/inliner/blob/df3619f89b5b4b76bd1b1bca675a58b38bf7a5b7/lib/get.js#L74
Problem:
This can result in 404s for otherwise working URLs. Example:
<img src="http://example.com/img/ExampleImage%20Space.png" />

Passing it through encodeURI turns the encoded space character %20 into %2520:
encodeURI('http://example.com/img/ExampleImage%20Space.png')
"http://example.com/img/ExampleImage%2520Space.png"

Which breaks the URL, and now we get a 404 for the image when trying to inline it.

PR made: https://github.com/remy/inliner/pull/192

Anyone bumping into this issue could use my branch for the time being:
yarn add https://github.com/codeclown/inliner.git#encoded-space


Change examples to use MPO instead of toMPO

Fixes issue #299

Tests are passing except known issue with one MPO test


fix sql concat error

upgrade.*.sql not excluded. (duplicated column error occurred if run create-all-sql script.  )

sorry for spam. typo in branch name.

How is upgrade*.sql supposed to be used?
When there is a DB schema change does the change need to go to two places?


有jenkins 那么多插件吗?

有jenkins 那么多插件吗? 比如 上传蒲公英的 插件 编译安卓的插件

节点状态是可以连接上的，但是发布的时候节点上报object not found
{"timestamp":1544144907,"timestamp_format":"2018-12-07 09:08:27","millisecond":1544144907582,"millisecond_format":"2018-12-07 09:08:27.582","level":6,"level_string":"Info","body":"agent task service add task 9 success","file":"task.go","line":102,"function":"bzppx-agent-codepub/app/service.(*ServiceTask).Publish"} {"timestamp":1544144907,"timestamp_format":"2018-12-07 09:08:27","millisecond":1544144907677,"millisecond_format":"2018-12-07 09:08:27.677","level":6,"level_string":"Info","body":"agent task 9 publish start","file":"worker.go","line":42,"function":"bzppx-agent-codepub/container.(*Worker).StartTask.func1"} {"timestamp":1544144908,"timestamp_format":"2018-12-07 09:08:28","millisecond":1544144908504,"millisecond_format":"2018-12-07 09:08:28.504","level":3,"level_string":"Error","body":"agent task 9 publish faild: object not found","file":"worker.go","line":61,"function":"bzppx-agent-codepub/container.(*Worker).StartTask.func1"} {"timestamp":1544144908,"timestamp_format":"2018-12-07 09:08:28","millisecond":1544144908621,"millisecond_format":"2018-12-07 09:08:28.621","level":6,"level_string":"Info","body":"agent task 9 delete success","file":"task.go","line":151,"function":"bzppx-agent-codepub/app/service.(*ServiceTask).Delete"}


Inconsistent naming of stripParens and getProperExpr

The Java and JavaScript ql libraries have inconsistent naming for Expr member predicates that effectively do the same thing:
JavaScript: stripParens
https://github.com/Semmle/ql/blob/742c9708a9888c59391b49041ebb2f18ef2e1ffb/javascript/ql/src/semmle/javascript/Expr.qll#L83
Java: getProperExpr
https://github.com/Semmle/ql/blob/9012c3240f347655f859aa006817ff008b40aaf9/java/ql/src/semmle/code/java/Expr.qll#L50
I feel that we should unify the naming here, and deprecate whichever one we choose to no longer use, as this caused me some confusion when i was trying to find the Java version of this. IMO stripParens is a somewhat more obvious and intuitive name.

I've been considering changing the java extractor to model parentheses as a predicate that may hold for a given expression instead of manifesting them as actual AST elements.  This would remove the need for the getProperExpr predicate, and instead expose the information as an isParenthesized() predicate on Expr.

That sounds sensible for me, as it's a step that can be easily forgotten, and doesn't change the semantics. This would lose us some information though in the case where there is unnecessary nesting of parentheses (e.g. ((expr))). Would it make sense to model this as an integer that represents how many times an expression is directly wrapped in parentheses, and isParenthesized() would just check for a value > 0?

Yes, we might as well keep information about number of parentheses in case someone wants to query for that.  Then the only information that we discard is the location information of the parentheses, but that's probably fine.

SGTM


Upwork api Oauth2.0 redirect_url error in Authorization Request

1. I received credentials and run myapp.py
2. My code looks like
  def get_desktop_client():
      config = upwork.Config(
          {
              "client_id": "MYCLIENTID",
              "client_secret": "MYCLIENTSECRET",
              "redirect_uri": "https://a.callback.url",
          }
      )

    # If token data already known and saved, you can reuse them
    # by adding 'token' parameter to the config
    # token = {'access_token': 'xxxxxxxxxxxxxxxxxx', 'expires_at':<PHONE_NUMBER>.547947, 'expires_in': '86400', 'refresh_token': 'xxxxxxxxxxxxxxxxxxxxxxxx', 'token_type': 'Bearer'}
    # config = upwork.Config({'client_id': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'client_secret': 'xxxxxxxxxxxxx', 'token': token})

    client = upwork.Client(config)

    try:
        config.token
    except AttributeError:
        authorization_url, state = client.get_authorization_url()
        # cover "state" flow if needed
        authz_code = input(
            "Please enter the full callback URL you get "
            "following this link:\n{0}\n\n> ".format(authorization_url)
        )
        print("Retrieving access and refresh tokens.... ")
        token = client.get_access_token(authz_code)
        # WARNING: the access token will be refreshed automatically for you
        # in case it's expired, i.e. expires_at < time(). Make sure you replace the
        # old token accordingly in your security storage. Call client.get_actual_config
        # periodically to sync-up the data
        pprint(token)
        print("OK")

    # For further use you can store ``token`` data somewhere

    return client

if __name__ == "__main__":

    client = get_desktop_client()

    try:
        print("My info")
        pprint(auth.Api(client).get_user_info())
        # pprint(search.Api(client).find({'q': 'php'}))
        # pprint(team.Api(client).add_activity('mytestcompany', 'mytestcompany', {'code': 'team-task-001', 'description': 'Description', 'all_in_company': '1'}))
        # pprint(time.Gds(client).get_by_freelancer_full('mnovozhilov', {'tq': quote('SELECT task, memo WHERE worked_on >= "2017-06-01" AND worked_on <= "2017-06-02"')}))
    except Exception as e:
        # print("Exception at %s %s" % (client.last_method, client.last_url))
        raise e

3. I click on link in console, It redirects me to Upwork login page. I paste login and password. Instead of successfull logining I receive next error

Why I receive this error and how to fix it?

hi @Sofia-Oles ,
The redirect_uri you specified in the config must be the same you specified in the oauth2 key configuration.
If you continue experiencing the same issue, please, contact our Support Team at https://support.upwork.com/

hi @Sofia-Oles ,
The redirect_uri you specified in the config must be the same you specified in the oauth2 key configuration.
If you continue experiencing the same issue, please, contact our Support Team at https://support.upwork.com/

Thank you sooo much!


Don't build raml-rb gem in pre-install script

Since version 0.0.5 of raml-rb is now released, it no longer needs to be cloned and built in the travis environment prior to running bundle install.

Coverage remained the same at 99.184% when pulling 9e2b162abf623af8080132278e4e4f5630f60707 on update-raml-rb into 09f690e58a5bc657217c9259591c6f70083a240a on master.


LSTM example with training and inference

Description
can you provide an LSTM example code with training and inference, preferably with time series data
Will this change the current api? How?
no
Who will benefit from this feature?
any one who wants to build an LSTM model using the api
References

list reference and related literature
list known implementations

We created an example on the LSTM branch at https://github.com/awslabs/djl/blob/lstm/examples/src/main/java/ai/djl/examples/training/TrainMnistWithLSTM.java. It currently depends on a different Engine version, so we will wait to close this issue until the Engine issue is resolved and the branch is merged

LSTM example has been merged into master branch now:
https://github.com/awslabs/djl/blob/master/examples/src/main/java/ai/djl/examples/training/TrainMnistWithLSTM.java


Groupmap docs

Added groupmap description to README.md and added some preliminary comments to groupmap lib.rs from snarky Ocaml implementation.

@aaronsens CI is failing because of a formatting error; could you run cargo fmt?


add quick sort, armstrong number, number guess in RUST

added quick sort code which is written in rust.
plz merge.

I am interested in your repository. Also, I am studying rust-lang. I found out that there isn't much rust codes in this repository so that I want to contribute here by rewritting various funny algorithm codes into rust! Plz somebody review my codes..!
@Marcosschwaab @marlonchalegre @tricinel @melko

I made new version of number guess. Difference is that if you make wrong guess, it tells you whether your guess is big or small.

I found out that NumberGuess.py has bugs and it doesn't work.
Therefore I fixed it and just committed it.


Updating Images to SVG format

Working with Christy Su and Phoebe Hu on updating .jpg and .png to high quality, scalable .svg for this article.

@gsprad : Thanks for your contribution! The author(s) have been notified to review your proposed change.


LSP Client generates "Cannot find module" error

👓 What did you see?
When I review the log file for the LSP, I see
[ERROR][2023-05-01 08:57:04] .../vim/lsp/rpc.lua:734	"rpc"	"cucumber-language-server"	"stderr"	"Error: Cannot find module '../src/version'
Require stack:
-<EMAIL_ADDRESS>    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
    at Function.Module._load (node:internal/modules/cjs/loader:778:27)
    at Module.require (node:internal/modules/cjs/loader:1005:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at Object.<anonymous> (/Users/stagr005/.local/share/lvim/mason/packages/cucumber-language-server/node_modules/@cucumber/language-server/bin/cucumber-language-server.cjs:7:21)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1157:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:77:12)

✅ What did you expect to see?
no errors
📦 Which tool/library version are you using?
java version 1.8.0_181
cucumber version 1.2.5
neovim 0.9.0
🔬 How could we reproduce it?
open a cucumber file in neovim.  The version of cucumber should be 1.2.5
📚 Any additional context?

Hi there,
Thank you for your work; indeed, it's appreciated. Could you please help me? I'm still encountering issues with cucumber-language-server 1.4.0 (and also 1.3.0) installed with Mason on both Mac and Termux.
:MasonInstall<EMAIL_ADDRESS>If I install version 1.2.0, I encounter issue #72.
Do you have any hacks or suggestions to resolve this, please?
Thank you.

Hi @restagner and @johnbunky,
The latest version is experiencing a startup problem when used outside of VS Code. I've just released a temporary package, @binhtran432k/cucumber-language-server, based on the latest update from Git that includes the startup fix from #74.
Could you please test it? Use npm install -g @binhtran432k/cucumber-language-server to install it instead of the Mason version. This temporary package will be in place until #74 is merged and a new version is released by @cucumber.
However, it is not working properly in all of the newest Node.js versions. I've tested it and listed the status of the package for each Node.js version here. I hope this information helps both of you.

Node.js version
Status

v16.20.2
Work

v17.9.1
Work

v18.19.0
Work

v19.9.0
Failed

v20.11.0
Failed

v21.5.0
Work

Hi @binhtran432k
Thank you for the update. And it works but not a perfect, tested against nodejs 18.16.1 and 21.5.0.
On mac I got log:
[START][2024-01-15 22:00:41] LSP logging initiated
[WARN][2024-01-15 22:00:41] ...lsp/handlers.lua:113	"The language server cucumber_language_server triggers a registerCapability handler despite dynamicRegistration set to false. Report upstream, this warning is harmless"
[ERROR][2024-01-15 22:00:42] ...lsp/handlers.lua:485	"Failed to reindex: undefined is not iterable (cannot read property Symbol(Symbol.iterator))"
[ERROR][2024-01-15 22:00:42] ...lsp/handlers.lua:485	"Failed to reindex: undefined is not iterable (cannot read property Symbol(Symbol.iterator))"
[WARN][2024-01-15 22:00:44] .../lua/vim/lsp.lua:1065	"server_request: no handler found for"	"workspace/semanticTokens/refresh"
[ERROR][2024-01-15 22:00:44] ...lsp/handlers.lua:485	"Cucumber Language Server 2024.01.13: Unhandled Rejection at promise: [object Promise], reason: Error: MethodNotFound"
[WARN][2024-01-15 22:00:46] .../lua/vim/lsp.lua:1065	"server_request: no handler found for"	"workspace/semanticTokens/refresh"
[ERROR][2024-01-15 22:00:46] ...lsp/handlers.lua:485	"Cucumber Language Server 2024.01.13: Unhandled Rejection at promise: [object Promise], reason: Error: MethodNotFound"

I'm trying to integrate this language to Emacs' lsp-mode, but experiencing the same issue. 🤔


pyspec makes tests with pre state accounts having zero value storage keys

At least Pyspecs/cancun/eip1153_tstore.tload_after_tstore still contains zero storage entries
this better be removed to better parsing in alloc.json by t8n

Closing as there is a new issue that should track this problem (#475).


yubikey-manager dependency is broken and won't build

Describe the bug
yubikey-manager fails to build with the following:
error: builder for '/nix/store/jad7ilsxs5393kh0msp91b96i58vblr9-python3.9-yubikey-manager-4.0.7.drv' failed with exit code 1;
       last 10 log lines:
       > Finished executing pipBuildPhase
       > installing
       > Executing pipInstallPhase
       > /build/source/dist /build/source
       > Processing ./yubikey_manager-4.0.7-py3-none-any.whl
       > Requirement already satisfied: pyscard<3.0,>=1.9 in /nix/store/4r3xjl2qjjp771vxf8zh5f8lcb5i07fx-python3.9-pyscard-2.0.2/lib/python3.9/site-packages (from yubikey-manager==4.0.7) (2.0.2)
       > Requirement already satisfied: pyOpenSSL>=0.15.1 in /nix/store/kxm0wp6x06bv3six4vfjh46lz1jnwasd-python3.9-pyopenssl-20.0.1/lib/python3.9/site-packages (from yubikey-manager==4.0.7) (20.0.1)
       > Requirement already satisfied: click<9.0,>=6.0 in /nix/store/nckfzfxmw7ywdzzsp1h06w8k94ryc7m5-python3.9-click-8.0.3/lib/python3.9/site-packages (from yubikey-manager==4.0.7) (8.0.3)
       > ERROR: Could not find a version that satisfies the requirement cryptography<4.0,>=2.1 (from yubikey-manager) (from versions: none)
       > ERROR: No matching distribution found for cryptography<4.0,>=2.1

Steps To Reproduce
Add yubikey-manager to your environment.systemPackages and try to build (on nixos-unstable).
Expected behavior
Successful builds.
Notify maintainers
@benley  @Mic92
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.12, NixOS, 22.05 (Quokka)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.6.0pre20211217_6e6e998`
 - nixpkgs: `/nix/store/bwvj37279glrmh4bipw0lw0dqgsl7gfi-source`

Duplicate of #154673?

@TilCreator I think so, yes. Sorry, I searched but didn't find that!


replace skip_embed with input_embeds

This PR replace the arg skip_embed: bool with input_embeds: torch.Tensor in the forward functions of all the language models.
This fixes the bug raised by LogitsProcessor when using llava in Extend mode and return log_prob, such as using gen(choices=[...]) with llava, where LogitsProcessor need to receive input_ids and uses it to get the token logprob. However, the input_ids given to LogitsProcessor by llava is actually the input embedding, which will cause a Tensor dimension mismatch error.

With this fix, we can use gen(choices=[...]) with llava in text-only mode but can not give images, such as:
@function
def test(s,img_path,question):
    s += user(image(img_path)+question+" Please answer yes or no.")
    s += assistant(gen('answer',choices=['yes','no']))

This will raise Runtime error, and it seems to be caused by the cache system not working well with image input.

Same observation with runtime error for image inputs


added Soybean Breeders Workshop imgs

I need to add the images to main because I need these images for multiple branches I am working on.

The three personnel pics would increase the size of the git repo (main branch) by about ~25%. Could those be linked to from other public/official sources? The hotel PDF might not be needed as an asset for building the core site; perhaps it could be sourced from a file-hosting service (like Box)?

How about in a subdirectory in /usr/local/www/data/annex/Glycine/max/meetings

e.g.:
https://plantpathology.ca.uky.edu/sites/plantpathology.ca.uky.edu/files/bradley_carl_2015.jpg
https://plpa.cfans.umn.edu/sites/plpa.cfans.umn.edu/files/styles/cfans_profile_photo/public/2020-07/cory_hirsch.jpg
https://phytobiomesalliance.org/wp-content/uploads/2020/02/Jan_Leach.jpg

I am closing this PR.


Update to java 8 and migrate to gradle

Add notes like the docker plugin "Note: For the plugin to work properly, your IDE should be started using Java 7 or a later version. For corresponding instructions, see Selecting the JDK version the IDE will run under."

Gradle is prerequisite for unit tests https://www.jetbrains.org/intellij/sdk/docs/basics/testing_plugins.html?search=test. For a fixture test (see https://www.jetbrains.org/intellij/sdk/docs/tutorials/writing_tests_for_plugins/formatter_test.html) it launches intellij headless, so the test needs all intellij dependencies.


Setting cookies in context does not appear to be working

I am trying to set and test cookies. I have a simple test that loads a page where the only content is the value of a cookie. In the browser, it works even with server-side rendering, but in the test, I am not able to get the cookie value to appear.
I have tried using the Playwright context, hoping that the Nuxt test utils would recognize it somehow. I have also tried using the storageState.cookies to set the cookies, but the test always fails.
Can anyone point me in the right direction?
Example using context:
it('renders cookie value', async () => {
  await createBrowser()
  const browser = await getBrowser()
  const context = await browser.newContext()
  await context.addCookies([
    {
      name: 'test',
      value: 'test cookie',
      path: '/',
      domain: 'localhost'
    }
  ])

  const page = await createPage('/')

  expect(await page.innerHTML('body')).toContain('test cookie')
  await context.close()
  await browser.close()
})

Example using storageState.cookies
it('renders cookie value', async () => {
  const page = await createPage('/', {
    storageState: {
      cookies: [
        {
          name: 'test',
          value: 'test cookie',
          path: '/',
          domain: 'localhost',
          expires: -1,
          httpOnly: false,
          secure: false,
          sameSite: 'None'
        }
      ],
      origins: []
    }
  })

  expect(await page.innerHTML('body')).toContain('test cookie')
})

You can pass a options object to createPage which includes a way to configure cookies (via storageState.cookies).

That's what I tried, in the second example above, test still fails. Is there any documentation for this?
Thanks

Ah, serves me right for not reading to end. 😆
I would guess the issue is that you haven't specified the port in the domain. You can get a full URL from url('/') and extract the domain from that.

Will try that, thanks!

Unfortunately still no success. this should set the domain as localhost:PORT but test still fails. No idea why
it('renders test cookie value', async () => {
  const page = await createPage('/', {
    storageState: {
      cookies: [
        {
          name: 'test',
          value: 'test-cookie',
          path: '/',
          domain: new URL(url('/')).host,
          expires: -1,
          httpOnly: false,
          secure: false,
          sameSite: 'None'
        }
      ],
      origins: []
    }
  })

  expect(await page.innerHTML('body')).toContain('test-cookie')
})

This is the frontend, but again, everything works in the browser when I set the cookie manually and refresh page.
<script setup lang="ts">
import { useCookie } from '#imports'
const test = useCookie<string>('test')
</script>

<template>
  <div>
    {{ test }}
  </div>
</template>

I tried to put together a reproduction example on StackBlitz, but they may be blocking cookies or something because I could not make it work.
If you have any ideas, please let me know. I'm starting to get kind of desperate 😅.

Reopened - I'll try to have a look later.

yes, I'm using Nuxt3.


Use the trustStore only when client authentication is enabled

Added the condition as @JPercivall suggested on issue #262

Changes Unknown when pulling 41ba46b47c29daa98995951673dffd228d10c827 on danjee:fix-issue262 into ** on decebals:master**.

Thanks!

Just tested out this commit and it works as expected, thanks @danjee


Should JoinHandle be exported?

The executor crate exports spawn_with_handle and SpawnWithHandle but not JoinHandle. Should it be? (If not, then references to it should be removed from the documentation, currently they are broken links).

Dupe of #850, closing.


YubiKey keeps disappearing and reappearing

Yubico Authenticator version: 5.0.1 - linux.AppImage
Operating system and version: Debian 10
YubiKey model and version: Yubikey5 NFC
Bug description summary: Yubioath starts from terminal without problems and also recognizes the yubikey. However, shortly after detecting it for the first time, the Yubikey disappears from display if I click on settings and then reappears shortly after. The LED turns on and off accordingly. Everytime this happens, terminal gives me the following error message:
"qml: calculateAll failed: open_device_failed"

I have the same issue on my Gentoo Linux OS with yubioath-desktop-5.0.1-linux.AppImage and a YubiKey5 NFC.
In my case, the main window first displays a menu with the vertical three-dots label in the top left and a message in the center of the main window saying "Insert your YubiKey" below a graphic of 5 different form factors of Yubikeys.
When I insert my YubiKey5 NFC, the message and graphic disappear and every 6 seconds or so the terminal shows the same "qml: calculateAll failed: open_device_failed"
If I click the three-dots menu in the top left, the main window contents change to "Settings" and the "Device" and "Application" sections are populated....in "Device" it shows my key and info, including serial number and options to  "Set Password"and "Reset".  In "Application" it shows options for "Appearance," "Interface" and "System Tray."  But every time the error message is generated, this window briefly replaces the contents of the "Device" section with only "Insert you YubiKey" and "No device found" for about 1.5 seconds before going back to the previous contents.

@jharvell That is exactly the same thing I am experiencing, but with a much more precise description!

Thanks for the report. Seems like something is blocking the device. Could you try running the AppImage from a terminal with the debug flag?
$ yubioath-desktop-5.0.1-linux.AppImage --log-level DEBUG
Also make sure pcscd is installed and running.

It seems that I was missing the libccid driver. Everything works fine after the installation.
Just for reference, this was the message I got after running the AppImage with the debug flag:
2020-01-07T08:41:46+0100 INFO [ykman.logging_setup.setup:59] Initialized logging for ykman version: 3.1.0
2020-01-07T08:41:46+0100 DEBUG [ykman.driver_otp.open_devices:224] Success in opening key at position 0
2020-01-07T08:41:46+0100 DEBUG [ykman.device.init:198] Read config from device...
2020-01-07T08:41:46+0100 DEBUG [ykman.device.init:200] Success!
2020-01-07T08:41:46+0100 DEBUG [ykman.device.init:289] Identified YubiKey 5
2020-01-07T08:41:46+0100 DEBUG [ykman.driver_otp.open_devices:222] Failed to open key at position 1
2020-01-07T08:41:46+0100 DEBUG [ykman.driver_otp.del:208] Destroy <ykman.driver_otp.OTPDriver object at 0x7f54dd069f10>
2020-01-07T08:41:46+0100 DEBUG [ykman.driver_otp.close:203] Close <ykman.driver_otp.OTPDriver object at 0x7f54dd069f10>
2020-01-07T08:41:46+0100 DEBUG [ykman.descriptor._open_driver:173] Opening driver for transports: TRANSPORT.CCID, serial: 11343406, key_type: None, mode: None
2020-01-07T08:41:46+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 1 of 10
2020-01-07T08:41:46+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.100000 s
2020-01-07T08:41:46+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:46+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 2 of 10
2020-01-07T08:41:46+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.200000 s
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 3 of 10
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.300000 s
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 4 of 10
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.400000 s
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 5 of 10
2020-01-07T08:41:47+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.500000 s
2020-01-07T08:41:48+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:48+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 6 of 10
2020-01-07T08:41:48+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.600000 s
2020-01-07T08:41:48+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:48+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 7 of 10
2020-01-07T08:41:48+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.700000 s
2020-01-07T08:41:49+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:49+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 8 of 10
2020-01-07T08:41:49+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.800000 s
2020-01-07T08:41:50+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:50+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 9 of 10
2020-01-07T08:41:50+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.900000 s
2020-01-07T08:41:51+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
2020-01-07T08:41:51+0100 DEBUG [ykman.descriptor._open_driver:175] Attempt 10 of 10
2020-01-07T08:41:51+0100 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 1.000000 s
2020-01-07T08:41:52+0100 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: ..., key_type: None, mode: None
qml: calculateAll failed: open_device_failed

jharvell@wolfhound yubi$ ./yubioath-desktop-5.0.1-linux.AppImage --log-level DEBUG
2020-01-07T14:01:45-0700 INFO [ykman.logging_setup.setup:59] Initialized logging for ykman version: 3.1.0
2020-01-07T14:01:46-0700 DEBUG [ykman.driver_otp.open_devices:224] Success in opening key at position 0
2020-01-07T14:01:46-0700 DEBUG [ykman.device.init:198] Read config from device...
2020-01-07T14:01:46-0700 DEBUG [ykman.device.init:200] Success!
2020-01-07T14:01:46-0700 DEBUG [ykman.device.init:289] Identified YubiKey 5
2020-01-07T14:01:46-0700 DEBUG [ykman.driver_otp.open_devices:222] Failed to open key at position 1
2020-01-07T14:01:46-0700 DEBUG [ykman.driver_otp.del:208] Destroy <ykman.driver_otp.OTPDriver object at 0x7f279a4f5710>
2020-01-07T14:01:46-0700 DEBUG [ykman.driver_otp.close:203] Close <ykman.driver_otp.OTPDriver object at 0x7f279a4f5710>
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:173] Opening driver for transports: TRANSPORT.CCID, serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 1 of 10
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.100000 s
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 2 of 10
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.200000 s
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 3 of 10
2020-01-07T14:01:46-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.300000 s
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 4 of 10
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.400000 s
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 5 of 10
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.500000 s
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 6 of 10
2020-01-07T14:01:47-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.600000 s
2020-01-07T14:01:48-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:48-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 7 of 10
2020-01-07T14:01:48-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.700000 s
2020-01-07T14:01:49-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:49-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 8 of 10
2020-01-07T14:01:49-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.800000 s
2020-01-07T14:01:50-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:50-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 9 of 10
2020-01-07T14:01:50-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.900000 s
2020-01-07T14:01:50-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:50-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 10 of 10
2020-01-07T14:01:50-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 1.000000 s
2020-01-07T14:01:51-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
qml: calculateAll failed: open_device_failed
2020-01-07T14:01:52-0700 DEBUG [ykman.driver_otp.open_devices:224] Success in opening key at position 0
2020-01-07T14:01:52-0700 DEBUG [ykman.device.init:198] Read config from device...
2020-01-07T14:01:52-0700 DEBUG [ykman.device.init:200] Success!
2020-01-07T14:01:52-0700 DEBUG [ykman.device.init:289] Identified YubiKey 5
2020-01-07T14:01:52-0700 DEBUG [ykman.driver_otp.open_devices:222] Failed to open key at position 1
2020-01-07T14:01:52-0700 DEBUG [ykman.driver_otp.del:208] Destroy <ykman.driver_otp.OTPDriver object at 0x7f279a3da210>
2020-01-07T14:01:52-0700 DEBUG [ykman.driver_otp.close:203] Close <ykman.driver_otp.OTPDriver object at 0x7f279a3da210>
2020-01-07T14:01:52-0700 DEBUG [ykman.descriptor._open_driver:173] Opening driver for transports: TRANSPORT.CCID, serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:52-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 1 of 10
2020-01-07T14:01:52-0700 DEBUG [ykman.descriptor._open_driver:198] Sleeping for 0.100000 s
2020-01-07T14:01:52-0700 DEBUG [ykman.descriptor._open_driver:201] No driver found for serial: 11409520, key_type: None, mode: None
2020-01-07T14:01:52-0700 DEBUG [ykman.descriptor._open_driver:175] Attempt 2 of 10

On Gentoo Linux I resolved this by installing the package app-crypt/ccid-1.4.31

Ok, sounds like this might be related to Yubico/yubikey-manager#284 then? Anyway, seems like the issues are resolved, so I'll close this. You're welcome to re-open it if there's anything more to do here.

Also make sure pcscd is installed and running.

This solution worked for me on Linux Mint 20.1 Cinnamon

Also make sure pcscd is installed and running.

Thank you @dagheyman !  ``// Ubuntu 20.04 LTS`

For arch/manjaro it's pacman -S acsccid


bytes::BytesMut::extend_from_slice or mio::net::TcpSocket produces unexpected result

Ok, so I have extracted a "minimum" amount of code to replicate it and posted it on HackMD with details of cargo toml and actual error message. This is quite a bit of code to go thought but here is the overall structure

This has one example file called /examples/bytes_bug.rs

The file has two #[test]'s so you can run each one independently
a) test 1
called test_emulated() and it writes a fixed size, random bytes frame but arbitrarily splitting it in "half" and then tries to reconstruct the frame but checking if enough bytes are available in the bytes::BytesMut buffer. It seems to never fail on either linux or Mac
b) test 2
called test_socket() and this test has two thread
a new thread which runs server socket, it will read bytes and try to reassemble and count frames.
the main thread has a client socket and will write N frames, N has to be set pretty high, to get a failure.
Note: in this test, both read_frame & write_frame take place via a helper struct which will indicate whether io operation completed or socket was not ready. This is due to socket being intentionally non-blocking.

Post:
bytes_bug - HackMD

It never fails on macOS

closing in favor of https://github.com/rust-lang/rust/issues/115451


Dropdown auto width doesn't detect right window edge

Hello. When a select or input is near the right side and dropdownAutoWidth is set to true, select2 does not account for the window's width.
A JSFiddle reproducing the issue: http://jsfiddle.net/JELEF/
Hopefully this is an easy(ish) fix.

This should be fixed in 4.0.
If it is not fixed, please add a :+1: to the ticket to bring it to our attention. Please also include an example that we can test to verify that it is not actually working.

It seems not working in 4.0.3 too. =/
Here is the updated JSFiddle: http://jsfiddle.net/401dmrhk/
Any workaround?
Thanks!

not working too


TokenRefresh stalls app on iOs

Hey everyone!
So i'm facing an issue here on iOs. Once the app is in the background for a few minutes, and it's opened up, the token need to be refreshed or something, and when that request doesn't go through properly, the app is unusable for like 30 seconds.
How can i avoid that? Is there a way for me to move the whole refreshing process into the background? As of now it completely blocks the further execution of the app.

closing for now, reopen if still an issue with the latest version of the plugin


As a liquidity provider I want to see the price range for the market so I know where my orders need to be in to count towards my commitment

Story
As a liquidity provider
I want see the market.liquidity.priceRange (in GQL market.lpPriceRange)
So that I know where I need to place my orders to count towards my obligation.
Acceptance Criteria

[ ] I can see the value for the price range
[ ] the value is correctly formatted as a percentage with the decimal in the correct place
[ ] I can see a tool tip as an explanation of the value

(not the ACs for liquidity providers have not yet been created, this should be included)
Tasks

[x] Explore and sketch
[ ] Team and stakeholder review
[ ] Visual Design
[ ] Team review
[ ] Etc.

Sketch

under market value proxy
tool tip: (taken from docs)

the maximum distance from the mid price that a liquidity providers orders need to be to count towards their commitment

Additional details / background info
Background on concept: https://docs.vega.xyz/testnet/concepts/liquidity/provision#price-range-for-liquidity-orders
Requested by @davidsiska-vega

Need to get some feedback on the tooltip wording and check if this needs to be formatted with asset dp too.


How is it different from react-native-config?

Congratz on your project.
I think it would save newcomers some precious research time if you could include some information in the README on how it differs from luggit/react-native-config and the potential benefits of switching over for projects that already use that other solution.

@jay-jlm I put some comparison here https://github.com/maxkomarychev/react-native-ultimate-config/blob/master/docs/alternatives.md (also linked from README).
Please feel free to suggest if more that page needs to contain more information, closing this meanwhile.
Thanks!


Add method to gracefully remove worker(group) from project

Reported by atze on 5 Sep 2014 20:38 UTC
When removing the assignment of a WG to a project, there is currently no choice how the tracker handles tickets that are still owned by workers of that group. The current behaviour is to not allow any action from a "disabled" WG in a project - wich is fine!
Nevertheless, a possible improvement to this situation is to have the choice of "gracefully deselecting" a WG at a project, which just means that the workers of this WG can call setTicketDone or setTicketFailed on tickets they own. So a worker can be gently taken out of project without the need to look for tickets that hang there for some hours.

Comment by texec on 20 Oct 2014 15:03 UTC
I don't really like the proposed solution (let "unassigned" workers finish tickets).
So a worker can be gently taken out of project without the need to look for tickets that hang there for some hours.
The tickets should probably fail, when the worker doesn't have a working group, but the ticket he tries to touch is still assigned.
Another idea would be to remove workers from tickets when the working group is removed. In this case the ticket should probably be reset, maybe just fail.

Comment by texec on 21 Dec 2014 18:09 UTC
As there seems to be demand for this, a solution maybe to add the ability to ''pause'' a worker group. This would disable handling tickets to this worker group (via assignNextUnassignedForState), but not change any other behavior or code paths. getAssignedForState would still return assigned tickets, queues in the web interface would still be visible, but show a warning or notice.

Comment by texec on 23 Dec 2014 07:22 UTC
Added ability to pause worker groups in [changeset:47bc6cc132]. Future versions may expose an API interface for this.


Add maven profile to skip broker unit tests

Add a maven profile to skip pulsar-broker tests specifically.

//pulsarbot run-failure-checks

/pulsarbot run-failure-checks


Nav: wheel encoder code

Draft PR of navigation system which deals with the wheel encoders.

Codecov Report

Merging #119 (30ae338) into master (b4144b8) will increase coverage by 0.16%.
The diff coverage is 22.22%.

@@            Coverage Diff             @@
##           master     #119      +/-   ##
==========================================
+ Coverage   34.01%   34.18%   +0.16%
==========================================
  Files          67       67
  Lines        3545     3621      +76
==========================================
+ Hits         1206     1238      +32
- Misses       2339     2383      +44

Impacted Files
Coverage Δ

src/data/data.hpp
100.00% <ø> (ø)

src/utils/io/spi.cpp
0.00% <ø> (ø)

src/navigation/navigation.cpp
12.23% <22.22%> (+0.32%)
:arrow_up:

src/navigation/main.cpp
28.94% <0.00%> (-1.61%)
:arrow_down:

src/sensors/imu.cpp
0.00% <0.00%> (ø)

src/navigation/kalman_filter.cpp
51.89% <0.00%> (+0.17%)
:arrow_up:

src/propulsion/main.cpp
22.41% <0.00%> (+0.59%)
:arrow_up:

src/brakes/main.cpp
35.81% <0.00%> (+9.09%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b4144b8...30ae338. Read the comment docs.


Update whats-new.md

change to the dc sync update text, verify this with Daniel

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

File
Status
Preview URL
Details

ATPDocs/whats-new.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Hardcode databricks runtimes to use python 3.8 for cudf_udf ENV [databricks]

per https://docs.rapids.ai/notices/rsn0022/, and related issue https://github.com/rapidsai/cudf/issues/12764
hardcode the databricks python ENV version to 3.8
followup fix for #7737

build

build

build

build

Suppose skipping cudf-udf test on DB113 is a temp workaround way. Is there any issue following up pandas import failure on DB113? Or are we good not skipping it?
incorrect pandas version during required testing partially initialized
module 'pandas' has no attribute '__version__'
(most likely due to a circular import)


Refs 2711: upgrade to postgres 15

Summary
Upgrade to Postgres 15
Testing steps
tests pass?
Checklist

[x] Tested with snapshotting feature disabled and pulp server URL not configured if appropriate

https://issues.redhat.com/browse/HMS-2711

⚠ This task currently requires qe-approval, but this PR does not fully resolve the task.  Please contact QE to determine appropriate testing required.

/retest

/retest


Bad cookie (?) causing looping issue in some cases

I personally cannot reproduce this issue, but https://github.com/mauzel/mproxy-gbf/pull/13#issuecomment-377572152 is describing some remaining issues.
This issue needs further triaging before I can figure out what needs to be done. But most likely it will involve blacklisting some more authentication-related requests in the PAC file.

the thing is.. it just looping on game.granbluefantasy.jp
for how to fix it: remove whole cookies for game.granbluefantasy.jp
so that's why i earlier suggest to add some script to ignore cookies (or somehow deliver it)

the thing is.. it just looping on game.granbluefantasy.jp

I believe that it will be making other specific requests which will show in the proxy log. So seeing your log would help me a lot.

to ignore cookies (or somehow deliver it)

This is how I implemented it, and it seems to work for me. But, it's not working for you, so I need your help to fix it. The help I need is to please see your proxy logs with debug output so I can better understand what it is actually doing for you.

@mauzel i'll post the result tmr if i get the issue again, since triggering it wasn't easy

the issue didn't appear anymore, looks like i just have to wipe cookies if im using old PAC, when im trying to use NEW PAC, the page just load normally even when its try to make you relogin.
(i think this issue are fixed, i'll be posting if anything happen)

@mauzel found the issue that make Error Respond 500. Cookies "ln" and "t", delete that and page will load again.. funny


Fix missing origin

closes #43

CI seems to be failing for the usual docker-compose version issue, so if fixed and tests pass, we can merge and relase.


Why does the inclusion of punctuation in the emphasis be rendered incorrectly?

Example：

https://spec.commonmark.org/dingus/?text=**incorrectly%3A**result
Works as original implementation.
Probably, some combination of punctuation + missed space. Please, see commonmark spec for details. It's describes all possibilities.


write consolidated stylesheet for all MAPs

see #10

See https://github.com/uwlib-mig/contentdm_maps/commit/fd86f87f97d6ea1be5769cd18e619151df00e001

RELATED: Updated structure for XML MAP - xsd/xml_map

Big commit for this was https://github.com/uwlib-mig/contentdm_maps/commit/81081d2c9e6be809b32d0f34fe455584a96c3b85


Type Classes

It might be interesting to evaluate the addition of type classes to the language.

Duplicate of #66


Remove auto scheduling for backend without dt

Summary
Fixes #5962
Details and comments
After #5563, circuits with delays are automatically scheduled in transpile() even if backend has no dt configuration (including backend == None), that results in failing to execute circuits with delays on simulator backends (#5962).
This PR fixes it by skipping the automatic scheduling of circuits with delays when the specified backend does not have dt.

Ok I went back and checked how we got here. I now regret saying that full scheduling should happen behind the scenes when a single delay is inserted.
@lcapelluto's comment made me realize that it ought to be ok to use delays like gates (no-op gates). We can put a delay between two gates without requiring anything about the timing of the full circuit. In fact users may not expect that inserting a single delay creates this whole other circuit with lots of delays.
So I made a new PR based on @itoko branch here (same tests): #6084
If you agree we can close this one.

Thank you for your comment, @lcapelluto.
I now understand my suggested categorization (in #5563) was not correct.
We just have two types of circuits: normal circuit or scheduled circuit. Normal circuits are scheduled in the backend and scheduled circuits are scheduled in the frontend, that's all (there is no "partially-scheduled circuit"). A circuits with delays is a normal circuit.
I also like @ajavadia's solution (#6084, TimeUnitConversion without/before scheduling) to the original issue (who should convert the unit of delays?). I agree this PR should be taken over by #6084.


Revert "refactor bluespace crystals, fix scram implant"

>"fix bluespace crystals"
>"it will not teleport you to space guaranteed"
>use bluespace crystal
>

Summary by CodeRabbit
Release Notes

New Features

Introduced the ScramImplantComponent and BluespaceCrystalComponent, enabling random teleportation of entities with configurable properties.
Added new subdermal implants, enhancing gameplay with unique functionalities.

Improvements

Enhanced teleportation mechanics in the implant system for better user experience.
Reduced action delays for quicker interactions with the ScramImplant.

Bug Fixes

Removed deprecated teleportation components to streamline functionality.

i'll come up with a new solution to that

"(less often into space, whereas the current solution will teleport you into space every time) and runs 20 to 50 times faster (and the current solution can take milliseconds to run at the full intended radius)"

just increase tries count, it's in the RandomTeleportComponent
actually that component was probably a mistake i should've really just let the 2 components hold their own teleport data


Add bookmarks from ComicInfo.xml as chapters for EPUB output

I didn't know how to do 2 pull requests from one branch so I include the fix for #129
I also don't know much about the GUI, so the option to disable the parsing is on commandline only for now.
Thanks for responding so quickly :+1:

You tested it with files/directories that contain wide unicode chars?

No, I haven't tested wide unicode chars. I am not sure why you ask for testing files. Do you think sorting them will be a problem?

Well considering that I made hundreds of files with KCC and never had any sorting problem I want to be sure :-)
For now I will merge only that fix. I'm pulling rest to separate branch and check later.

I see. It does seem weird. I have converted quite a few files myself in Windows Vista and 7. My source directories were mostly flat though, so I haven't actively used the chapter feature. Just to clear any misunderstanding: filelist is sorted. The issue I found lies in that the chapter list is created from filelist before the filelist is sorted. The same goes for the already fixed cover-issue.
The thing is, even though this issue exists, it may be noticeable, but it does not affect the reading experience like a crash or an empty page would.
Info on walk():
walk() from scandir says to work exactly like os.walk(). The python docs say that os.walk() uses os.listdir() which returns The list is in arbitrary order
Thanks for KCC. :)

Before merging this feature into master, please be aware that my code only works on conversions that do not split images. The chapter-links are calculated based on the original image index number. If you convert comics with big images chapter links might be shifted. Conversions of web-comics are most affected.
Example:
Bookmark to Chapter:
 img-0 [bookmark 1] => img-0 [chapter 1]
 img-2              => img-2
 img-3 (big image)  => img-3-a
                    => img-3-b [chapter 2]
 img-4 [bookmark 2] => img-4
 img-5              => img-5

Making it work with all conversions, deeper changes are required.

I will try to fix it.


Update Litecoin

This project is a fork Litecoin but I see that it is not the current version. Among other things, the following error has been corrected in Litecoin (appears when compiling):
https://github.com/litecoin-project/litecoin/commit/2ede6b7142cb57c422126722f845b36da7d3c4ef
In file included from net.cpp: 24: 0:
/usr/include/miniupnpc/miniupnpc.h:62:1: note: DECLARED here

I will be grateful for updated fork or patch so that the compilation work correctly :)

The current release is now a fork of Bitcoin,
Unfortunately, one is not able to update the github details to reflect that :)
The current build was tested using miniupnpc 1.6 (original)
To resolve the error looks like a trivial fix.
Let me take a look

I have just pushed the following commit (81b71123e94ec06c5733cc25c2bb5c9624113259) onto master branch (which also contains a few extra fixes)

This error no longer displays but now appear other: x Screenshot terminal attached.

This is an issue with the newer versions of boost and compiling with c++11
Referencing against the issue on bitcoin. https://github.com/bitcoin/bitcoin/commit/a2b04ddfe6452e7d6274f4096bf3f2aee695a6d9
I can patch this in tonight,

I have pushed this update to my personal Reddcoin repo first.
https://github.com/reddink/reddcoin
Can you test it against your system?

It works a little better but still in one place, now a little later, there are problems with the make.

What is the error now reported?

./autogen.sh

make

Thanks for that.
The first screen is ok.. these warnings are expected
Second screen,
The warning is triggered in the version of boost you have installed (1.61?)
https://github.com/libbitcoin/libbitcoin/issues/582
It is a known issue and should be resolved in boost 1.62
These should be warnings only, there must be an error also in the output

You're right, there is a fault. Nothing else appears.

Ok, compiling with QT5 support. The error relates to QT5 build hardening
can you run configure with the following CXXFLAGS="-fPIC"
./configure CXXFLAGS="-fPIC"
in the current Reddcoin configure, it is using -fPIE as default.
I will need to pull the updated configure scripts from bitcoin to pull into our build

Hmm, I checked this. Not work. I used  ./configure CXXFLAGS="-fPIC". Makefile contains fPIC instead fPIE but error is the same.

Ok.. thanks for testing.
I have found the relevant commits on bitcoin..
They will need a bit of work to pull into Reddcoin.. stand-by

Pulling the relevant build updates is going to take longer than expected.
Can you try running:
make clean
./configure CXXFLAGS="-fPIC" CFLAGS="-fPIC"
make

Clean git repository https://github.com/reddink/reddcoin and  ./configure CXXFLAGS="-fPIC" CFLAGS="-fPIC" the error this same.
No hurry about it. Take care of more important matters, and to find the time to come back to this, I prefer to compile own wallets but currently I use the downloaded binaries for Linux so it's okay.

Problem solved.
./configure CXXFLAGS="-fPIC" CFLAGS="-fPIC" – add fPIC on root folder Makefile but not change ./src/qt/Makefile.
I edited ./src/qt/Makefile CXXFLAGS and manually change fPIE to fPIC.
Btw, please update official branch with previous commit: https://github.com/reddink/reddcoin/commit/2ab654109b69a69c1f4197d4727011afab7d7440
And maybe update ./configure to work with all makefiles not only root?

Thanks, glad you got it working. Will make these changes

Thanks   I hope I can get this to work. If not I'll be back.

This ticket should be closed.


Standard error (stderr) is truncated

This issue was partly discussed on gitter; I'm posting it here for reference and for people that encounter the same problem. It could be related to Docker version (see this message), although I'm not able to verify it at the moment.

First of all, thanks for this excellent software. I've been using it for 6 months and love it.  But I'm hitting a problem since I updated to 0.5. I understand it is in beta and I'm willing to solve it myself and make a patch if needed.
Sometimes, logs in stderr get lost and are never displayed neither on Drone web interface, nor in the API (/api/repos/{owner}/{name}/logs/{number}/1?full=true).
This bug can be reproduced with the following .drone.yml file:
pipeline:
  test:
    image: alpine
    commands:
      - echo This goes to stdout
      - echo This goes to stderr >&2

On some builds This goes to stderr is displayed, on others it's not.  I've tested different images (centos:7, node:6...), same result.  It looks like stderr is truncated when the test series ends.  The more commands in the test series, the more likely the bug appears (on one of my long builds, the bug occurs every time).
It's very annoying when the tests outputs on stderr, because I just see exit code 1 without any explanation.
Drone version: 0.5 (e5f13b794c11)
Docker version: 1.10.3
OS: CentOS 7

I was unable to reproduce with the sample yaml. Anyone else able to reproduce?

@adrienverge I believe this was the regression in docker 1.10.3 that impacted log output https://github.com/docker/docker/issues/22502

@bradrydzewski Thanks for following this up. I'll try Docker 1.12 and keep you informed.

I manually updated to Docker 1.12 and it solves the problem.
Thanks!


A hangs close to ten minutes in qpdf

hi,I find something maybe wrong in the newest qpdf.
the poc file will cause the program to be hanged about ten minutes.
Maybe this is a bug or feature?
poc.pdf
and I found that it maybe caused by the unparseObject in libqpdf/PDFWriter.cc,here are some backtrace:
#0  QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x25, flags=0x0) at libqpdf/QPDFWriter.cc:1182
#1  0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#2  0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#3  0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x24, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#4  0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#5  0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#6  0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x23, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#7  0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#8  0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#9  0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x22, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#10 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#11 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#12 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x21, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#13 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#14 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#15 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x20, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#16 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#17 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#18 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x1f, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#19 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#20 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#21 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x1e, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#22 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#23 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#24 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x1d, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#25 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#26 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#27 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x1c, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#28 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#29 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#30 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x1b, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#31 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#32 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#33 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x1a, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#34 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#35 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#36 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x19, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#37 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#38 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#39 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x18, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#40 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#41 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#42 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x17, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#43 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#44 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#45 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x16, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#46 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#47 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#48 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x15, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#49 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#50 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#51 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x14, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#52 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#53 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#54 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x13, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#55 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#56 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#57 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x12, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#58 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#59 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#60 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x11, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#61 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#62 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#63 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x10, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#64 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#65 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#66 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0xf, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#67 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#68 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#69 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0xe, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#70 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#71 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#72 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0xd, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#73 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#74 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#75 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0xc, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#76 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#77 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#78 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0xb, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#79 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#80 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#81 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0xa, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#82 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#83 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#84 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x9, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#85 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#86 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#87 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x8, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#88 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#89 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#90 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x7, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#91 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#92 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#93 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x6, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#94 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#95 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#96 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x5, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#97 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#98 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#99 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x4, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#100 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#101 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#102 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x3, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#103 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#104 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#105 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x2, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#106 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#107 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#108 0x00007ffff7a4dcf0 in QPDFWriter::unparseChild (this=0x7fffffffe070, child=..., level=0x1, flags=0x0) at libqpdf/QPDFWriter.cc:1195
#109 0x00007ffff7a62cf0 in QPDFWriter::unparseObject (this=0x7fffffffe070, object=..., level=<optimized out>, flags=0x0, stream_length=0x0,
    compress=0x0) at libqpdf/QPDFWriter.cc:1544
#110 0x00007ffff7a4e4cb in QPDFWriter::unparseObject (this=0x7ffff7fe8030, object=..., level=0x64edd0, flags=0xe799) at libqpdf/QPDFWriter.cc:1310
#111 0x00007ffff7a7b8b8 in QPDFWriter::writeObject (this=0x7fffffffe070, object=..., object_stream_index=<optimized out>)
    at libqpdf/QPDFWriter.cc:1967
#112 0x00007ffff7a90c17 in QPDFWriter::writeStandard (this=0x7fffffffe070) at libqpdf/QPDFWriter.cc:3397
#113 0x00007ffff7a8580f in QPDFWriter::write (this=0x7fffffffe070) at libqpdf/QPDFWriter.cc:2526
#114 0x0000000000412eb2 in write_outfile (pdf=..., o=...) at qpdf/qpdf.cc:2618
#115 main (argc=<optimized out>, argv=<optimized out>) at qpdf/qpdf.cc:2700
#116 0x00007ffff694ad20 in __libc_start_main () from /lib64/libc.so.6
#117 0x0000000000405ba9 in _start ()

Looking forward to you reply,thx : )

@jberkenbilt

This is a pretty heavily damaged PDF file, but I think qpdf is handling it in a reasonable way.
@carnil For what it's worth, when I run the latest qpdf on this on my Linux VM running on my mac, it finishes in under a minute, uses a reasonable and constant amount of memory, and does not crash. When I run it under address sanitizer, it shows no incorrect memory access, unfreed objects, etc. I doubt a CVE is justified here. As far as I can tell, qpdf is robustly handling a very broken file. Is there a specific reason this has been assigned a CVE?

FWIW, I do not know, I was only the messenger here (I noticed the CVE assignment while reviewing the feed update from MITRE referincing for qpdf this bug and the respective CVE assignment to CVE-2018-18020. I think this needs to be answered by the requestor, @Krace did you request the CVE?

Hello,I run this on another machine Centos7.0 ,it still have a hangs about ten minutes.
Does the OS matters?thx

On the ubuntu 14.04 i686 ,it also hangs for almost 3mins rather less than 1min.

I think the cpu cores and memory maybe have some influence.
But in the first comment,I use Centos6.5 with 16cores and 32G memory,so what exactly the problem is ?some dependence too old?

Okay, let's leave this open, and I can see if I can track down why it performs so badly. I'll leave it to others' judgment as to whether there should be a CVE for this. There are some things inherent to PDF that, in the absence of arbitary caps, will cause any PDF interpreter to behave in certain ways. Clearly though qpdf is taking a longer time to reject this file than other viewers. I'm not sure whether it's because it's giving up more slowly or whether I've implemented something in an inefficient way. It's also possible that my arbitrary cap of 500 levels of nesting is much larger than it should be. It's hard to imagine any legitimate PDF file that would require more than maybe 10 or 15 levels. Maybe 100 would be a better cap that would make this more tolerable, or maybe there's just something dumb in the error handling code. I would agree that RAM and CPU should determine the performance, so I'm confused as to why my linux VM running on a mac laptop should outperform 16 cores and 32 GB of RAM. I don't think old dependencies would matter. Maybe CentOS compiles things with memory guards that have a higher overhead or something.
I'm not going to treat this as urgent unless there's a good case as to why I should, but I will get to it when I can.

thanks for your relpy,I will read the code carefully later to find the
reason.
When I find anything interesting I will inform you.
:P
Jay Berkenbilt<EMAIL_ADDRESS>周二下午9:52写道：

Okay, let's leave this open, and I can see if I can track down why it
performs so badly. I'll leave it to others' judgment as to whether there
should be a CVE for this. There are some things inherent to PDF that, in
the absence of arbitary caps, will cause any PDF interpreter to behave in
certain ways. Clearly though qpdf is taking a longer time to reject this
file than other viewers. I'm not sure whether it's because it's giving up
more slowly or whether I've implemented something in an inefficient way.
It's also possible that my arbitrary cap of 500 levels of nesting is much
larger than it should be. It's hard to imagine any legitimate PDF file that
would require more than maybe 10 or 15 levels. Maybe 100 would be a better
cap that would make this more tolerable, or maybe there's just something
dumb in the error handling code. I would agree that RAM and CPU should
determine the performance, so I'm confused as to why my linux VM running on
a mac laptop should outperform 16 cores and 32 GB of RAM. I don't think old
dependencies would matter. Maybe CentOS compiles things with memory guards
that have a higher overhead or something.
I'm not going to treat this as urgent unless there's a good case as to why
I should, but I will get to it when I can.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/qpdf/qpdf/issues/243#issuecomment-428200079, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Afb_giyn0csmYRdEwcW9JMjAMPmik_Juks5ujKn_gaJpZM4XLQKJ
.

I've been look at this a bit, and I think it's just inherent slowness of the way I use STL combined with the pathological nature of this file. qpdf's performance is good but not superb...mostly I have focused on ease of maintainability and robustness over speed. I'm going to leave this open, but I don't think I'm going to try to work on a fix. There doesn't seem to be any specific bug here. This would have to be addressed in the context of an overall effort to improve qpdf's performance.

After recent fixes, this file no longer hangs for a long time. I recently added code to qpdf (not yet released, but it will be in version 9) that bails out if it encounters too many consecutive parsing errors. Thanks for the report.

Hi @jberkenbilt , could you please point out where the fix was made ? (what commit)
Thanks :) !

Hi @NicoleG25 . How important is it to do that? It would be possible to find the commit, but it would require using bisect. I could do it, but it would take time and effort since I didn't specifically target this particular issue. The way it would work would be to use git bisect on the range of commits from the most recent release prior to this bug report up to the commit that was current on master at the time of my previously reply. At each step, run the command on the file and see if it hangs or finish quickly. This would identify the commit that fixed it.
If you can explain why you want to know this, it would help me determine whether it's worth it for me to spend the time doing this. Alternatively, anyone can do this analysis with git bisect. At each step, you could rebuild with ./autogen.sh && configure --disable-shared && make -j$(nproc) build_qpdf, then run the test with ./qpdf/buildf/qpdf poc.pdf /tmp/out.pdf

Since @NicoleG25 and I both frequently ask developers this, I will give my input. There are times where a vendor has implemented a library and made significant changes to it. Instead of just integrating a new version, they do one-off code patches based on your fixing commits. In other cases, a vendor may have integrated the library as-is, but won't upgrade it without verifying the need to do so. In those cases, a vendor may not upgrade just because there was a 'security fix', as the functionality that was found vulnerable wasn't implemented in their integration, or it was and there is no user code path to reach a vulnerable function. So the ability to independently evaluate a fix for multiple reasons leads me to ask for the fixing commit often times.
For many projects, issues are closed out in the PR with the fixing commit, or even linking to the fixing PR that has the commit that was merged into master is all we need.  So I certainly appreciate the time involved and your consideration in doing so. For my company's purpose, it is very helpful to have it, but not mandatory. Thanks!

@attritionorg @NicoleG25 You'll notice that I almost always close issues with commits that fix them, and I think it's a good practice. In this particular case, I was fixing a series of issues, and when I got to this one, it was no longer an issue. I don't know which commit fixed it. Most likely it was similar to a different issue that was fixed by a nearby commit. Do a git log --oneline | grep '(fixes #
Also, I have been a debian developer for a long time and was frequently in the business of backporting security patches, so I definitely get what you are saying and fully appreciate this.
Obviously you fully understand the issue and the situation, as do I. This project is mostly a hobby for me though, and since anyone can do the git bisect to figure this out, I'm not inclined to spend my time doing it. But please understand it's not because I don't appreciate the value. It's just because there are only so many hours in a day. :-)
Looking at the ChangeLog, from around June 13 until around June 22, 2019, I took time off work to do a full integration of qpdf with Google's OSS-Fuzz. There are very large changes including some ABI changes, hence the next release being 9.0.0. During that week, I went through and fixed many issues found by fuzzers, and I also did a bit cleanup on integer type conversions. After fixing those issues, I rechecked other open issues of similar nature and was pleased to find that most were fixed. In this particular instance, I can say the fix was most likely one of the commits I did during that period, and I can also say that it would be difficult to backport the changes in isolation.
Hopefully this helps.

Hi @jberkenbilt , thank you for your input and reply.
As stated previously by @attritionorg , it is helpful to have in order to help our customers identify whether or not they are still using a version that might be vulnerable. In addition we advise them to upgrade to the fixed version if one exist.
This is why it would be beneficial for us to know where & when it was fixed
If you could point out the vulnerable file for us, we would take care of the rest :)
Thanks in advance !

@NicoleG25 The vulnerable file is linked in the issue at the top in the original report. Let me know if you run into trouble, and I'll jump in and help out.

Hi @jberkenbilt !
After some reviewing I've encountered the following commits and was wondering if you could confirm which one fixes the issue :)

https://github.com/qpdf/qpdf/commit/b07ad6794eea175ee7f4b8c505995bdb4f397ce6#diff-ebd1e6eca7d2c72d8f0fb006a5b9e204
https://github.com/qpdf/qpdf/commit/eb7948876b896f7d351ca4e9817522c71678cd43#diff-ebd1e6eca7d2c72d8f0fb006a5b9e204

Thanks in advance !

The commit that fixed this was cf469d789024cdda41684f1ea48b41829b98c242.
I found it using git bisect, bisecting between the 8.4.2 and 9.0.0 release tags.

@NicoleG25 forgot to tag you -- see previous comment. It's cf469d789024cdda41684f1ea48b41829b98c242

Thanks @NicoleG25 for digging up that commit, and @jberkenbilt for the discussion and confirmation!

@NicoleG25 forgot to tag you -- see previous comment. It's cf469d7

Thank you @jberkenbilt for the confirmation ! :)
Have a good day !


dynamic linking

Hello,
I use dynamic linking (-D dll_link) to link haxe-c-bridge dynamic library to my dynamic library.
Linking works, haxe-c-bridge extern C functions are called successfully in my dynamic library, but app is crashing at exit (detected using post-mortem debugger feature).
I tried using exit(0) at the end, hoping system gets another route for cleanup, but that doesn't solve the issue. Any idea?

Never mind. If I compile haxe-c-bridge dynamic library using cl, and then link such library against gcc, it is working fine. Maybe is -fPIC, or some other gcc switch needed.

Are you using Main_stopHaxeThreadIfRunning(false); before exiting? Otherwise, the haxe thread might be still busy. Pass true if you want to wait for haxe to execute any events it has scheduled

Hello,
no, I'm using haxe-c-bridge differently because I don't want threads in my app, and I don't want callbacks/locks.
Basically, first I initialize main thread (using __hxcpp_lib_main()) and then call external haxe-c-bridge functions. This is working perfectly if app is statically linked, while dynamic linking have some issue which is not important now. I can debug and I can make release if dll is built using cl.


Linking to or packaging native libraries with a Flet app

Duplicate Check

[X] I have searched the opened issues and there are no duplicates

Describe the requested feature
What is the recommended approach to linking a needed system library into my Flet app?
I depend on libsodium (through pysodium), a popular cryptography library, at /usr/local/lib/libsodium.23.dylib yet get the runtime code signing error
OSError: dlopen(/usr/local/lib/libsodium.dylib, 0x0006): tried: '/usr/local/lib/libsodium.dylib' (code signature in <0541E863-5412-3036-A49C-84E95E4A0C98> '/usr/local/lib/libsodium.23.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs)

This is after doing the codesigning and notarization to build my .dmg file for distribution.
I see the Flutter discussion of Flutter tools support for packaging/linking to native libraries and am wondering if I need to take some FFI approach or just include the libsodium.23.dylib as a part of my build and codesigning process, as in

download source,
compile for target architecture, and
sign the libsodium.23.dylib file along with signing the entire Flet app bundle.

This seems a bit heavyweight, though if that's what I must do, then that's what I will do.
A relevant issue from the Flutter repo is https://github.com/flutter/flutter/issues/33227 (Flutter tools support for packaging/linking to native libraries)
This flet issue is probably related: https://github.com/flet-dev/flet/issues/2823 (libmpv.so.1 not found (when libmpv is already installed) - fixable but hacky)
Suggest a solution
I suggest creating a strong recommendation in the Flet documentation to do static linking:
downloading and building dependent libraries for each target architecture and linking them to the built Flutter app during the build process.
Screenshots
No response
Additional details
No response

I was able to get a workaround functional for pysodium by modifying the DYLD_LIBRARY_PATH and LD_LIBRARY_PATH variables as well as symlinking to the correct binary in a libsodium library directory in my repository.
This works because the entire app repo is copied to the app cache directory of ~/Library/Caches/myapp/app/ when running the app from the .dmg I build after making flet build macos.
Here's sample code of what I had to do to get pysodium to load my libsodium dynamic library from the libsodium/ directory in my repository.
################################# Custom Libsodium Loader ############################################
# This code has to be in the main module to avoid a partially initialized module error
# for the main app module.

def load_custom_libsodium(appdir):
    """
    Instruct the pysodium library to load a custom libsodium dylib from the appdir/libsodium
    """
    set_load_path_or_link(appdir)
    set_load_env_vars(appdir)

    custom_path = os.path.expanduser(f'{os.path.dirname(os.path.abspath(__file__))}/libsodium/libsodium.dylib')
    logger.info(f'Loading custom libsodium from {custom_path}')
    if os.path.exists(custom_path):
        logger.info(f'Found custom libsodium at {custom_path}')
        sodium = ctypes.cdll.LoadLibrary(custom_path)
    else:
        logger.info('Custom libsodium not found, loading from system')
        libsodium_path = find_library('sodium')
        if libsodium_path is not None:
            logger.info(f'Found libsodium at {libsodium_path}')
            sodium = ctypes.cdll.LoadLibrary(libsodium_path)
            logger.info(f'Loaded libsodium from {libsodium_path}')
        else:
            raise OSError('libsodium not found')

def set_load_path_or_link(appdir):
    """
    Symlinks the correct libsodium dylib based on the architecture of the system.
    """
    lib_home = f'{appdir}/libsodium'
    arch = platform.processor()

    if platform.system() == 'Windows':
        match arch:
            case 'x86' | 'i386' | 'i486' | 'i586' | 'i686':
                sodium_lib = 'libsodium.26.x32.dll'
            case 'AMD64' | 'x86_64':
                sodium_lib = 'libsodium.26.x64.dll'
            case _:
                raise OSError(f'Unsupported Windows architecture: {arch}')
    elif platform.system() == 'Darwin':
        match platform.processor():
            case 'x86_64':
                sodium_lib = 'libsodium.26.x86_64.dylib'
            case 'arm' | 'arm64' | 'aarch64':
                sodium_lib = 'libsodium.23.arm.dylib'
            # doesn't work
            case 'i386':
                sodium_lib = 'libsodium.23.i386.dylib'
            case _:
                raise OSError(f'Unsupported architecture: {platform.processor()}')
    else:
        # Linux and other Unix-like systems
        sodium_lib = 'libsodium.so.23'  # not yet supported
        raise OSError(f'Unsupported architecture: {platform.processor()}')

    lib_path = Path(os.path.join(lib_home, sodium_lib))

    logger.info(f'Arch: {platform.processor()} Linking libsodium lib: {sodium_lib} at path: {lib_path}')

    if platform.system() == 'Windows':  # if windows just set the PATH
        logger.info(f'Setting PATH to include {lib_path}')
        os.environ['PATH'] = f'{lib_path};{os.environ["PATH"]}'
    elif platform.system() == 'Darwin':  # if macOS, symlink the dylib
        if not lib_path.exists():
            logger.error(f'libsodium for architecture {platform.processor()} missing at {lib_path}, cannot link')
            raise FileNotFoundError(f'libsodium for architecture {platform.processor()} missing at {lib_path}')

        link_path = Path(os.path.join(lib_home, 'libsodium.dylib'))
        logger.info(f'Symlinking {lib_path} to {link_path}')
        try:
            os.symlink(f'{lib_path}', f'{link_path}')
        except FileExistsError:
            os.remove(f'{link_path}')
            os.symlink(f'{lib_path}', f'{link_path}')
        logger.info(f'Linked libsodium dylib: {link_path}')

def set_load_env_vars(appdir):
    """
    Sets the DYLD_LIBRARY_PATH and LD_LIBRARY_PATH that pysodium uses to find libsodium to the custom libsodium dylib.
    """
    if platform.system() == 'Windows':
        return  # Windows doesn't need this

    local_path = appdir

    logger.info(f'Setting DYLD_LIBRARY_PATH to {local_path}/libsodium')
    os.environ['DYLD_LIBRARY_PATH'] = f'{local_path}/libsodium'

    logger.info(f'Setting LD_LIBRARY_PATH to {local_path}/libsodium')
    os.environ['LD_LIBRARY_PATH'] = f'{local_path}/libsodium'

################################### End Custom Libsodium Loader ######################################

This is just for MacOS machines. I haven't tested the Windows support yet.
Static linking would completely remove the need to do this dynamic module loading.


Configure the TSLint formatter?

Is it possible to configure the formatter for TSLint? It seems like the linting is being executed via the ForkTsCheckerWebpackPlugin Webpack plugin, but I'm not seeing any way to determine which formatter is used. Is there a better way to specify the formatter?

Not sure why it created multiple duplicates of this issue when I saved it the first time... Apologies, closing now.


Error while trying to use pretrained tensorflow model

Hey, thanks for the nice work!
I was trying to use the TF checkpoint (provided here ).
Steps used:

Create a ./files.txt in which each line is a path to an image to be embedded
Downloaded the checkpoint provided in Releases and put in './checkpoints/
Ran the following command:
python embed.py --experiment_root ./checkpoint/   --dataset ./files.txt   --filename test_embeddings.h5
However, the following error comes:

raise IOError('args.json could not be found in: {}'.format(args_file))
OSError: args.json could not be found in: ./checkpoint/args.json

Could you please help on how to use the checkpoint of Market to extract features from images?

Hi @ml2345 ,
you can find the args file here, we should have put it in the release but I sadly forgot about it when making it. Just paste it into args.json and put it in the experiment root.

I'm closing this. It should be fairly obvious how to get it to work. If not please re-open it.

Hi,
After adding args.json.when embed.py is run

jsondecodeerror is popping up.Kindly guide on how to go about this.
Thanks.


Update travis node versions

I'm in the process of checking why the Rollup builds are failing in NodeJS v6 and v4 only, and if it is related to a regression here, and it would help to have these checked here.

Ahh, I see the tests aren't adapted to work in older Node.


Usage with AppEngine

The documentation says:
 ctx := appengine.NewContext(r)
 c, err := gitkit.NewWithContext(ctx, client)

But gitkit.NewWithContext requires a context.Context
not an appengine.Context
But even with suppying a context.Context does make it work.

10 lashes!
Heed the different imports:
"google.golang.org/appengine"
aeOrig "appengine"


Fix minor typos.

Great post! Feel free to make these changes on your own (or to ignore them) and delete my PR.
Thanks so much for sharing your knowledge.

Oh, thank you so much! Sorry for the late reply, I'd missed your PR!
Merging it in!