text:
Running docker without GPU support

Is it possible to run the simulator in a docker without GPU support, e.g. in no-renderring mode?
As I understand I can run a docker with the --gpus all flag and set no-rendering mode through PythonAPI. Is it possible to run on a machine without gpu access?

Hello umateusz,
I wanted to do exactly the same and I ended up writing the Dockerfile from scratch and building the image in order to achieve this.
You can try to the same (downloading from http://dist.carla.org/carla-0.9.9/ and installing with apt-get install carla-simulator. I could also share my Dockerfile with you if you write me an email to armando.miguel.garcia[at]gmail.com; because of an ongoing project, I'm not able to publish it here.
But that what you want to do is definitely possible!
Best regards

Sorry for the late response. Thank you, you encouraged me to create such adockerfile. The simulator is currently exiting without writing an error if the --gpus=all flag is not used.
I think this is a temporary solution. I think that such a solution would be very useful. I am not sure how many changes it requires to make it possible.

@umateusz chances are that the simulation won't work without a GPU, even in non_rendering_mode. If you achieve it, please report back.

@germanros1987 Unfortunately it seems not possible at the moment. We have access to a HPC cluster where Carla refuses to start due to a GPU issue:
[2020.06.25-16.35.56:623][  0]LogInit: Using SDL_WINDOW_OPENGL
[2020.06.25-16.35.56:632][  0]LogLinux: Warning: MessageBox: Warning: OpenGL is deprecated, please use Vulkan.: Message:
[2020.06.25-16.35.56:640][  0]LogLinux: Warning: MessageBox: Cannot create OpenGL-enabled SDL window. SDL error: 'Cannot create an OPENGL window invalid egl_data'.: Cannot create SDL window.:
[2020.06.25-16.35.56:640][  0]LogCore: FUnixPlatformMisc::RequestExit(1)

Starting in norendering mode leads to the same error. Also starting on a server without GPU in no rendering mode fails.
Would be really great if someone could work on making it possible to work without GPU, but maybe this is not possible due to PhysX?

@hh0rva1h we will make this a feature request. Hopefully, we will be able to take care of this in future releases.

Is it possible to run Carla with Intel GPUs? If yes, do you know the command to run the docker image?

Do you mean Intel integrated GPUs? I don't know if docker has a specific plugging to support integrated GPUs. This is not very conventional.

Do you mean Intel integrated GPUs? I don't know how mature is that. You can take a look at this : https://hub.docker.com/r/intel/intel-gpu-plugin

Thanks. Yes, I tried it. Did not work well.
Does Carla run in the native form, not the docker image, without Nvidia GPU? Just Intel CPU and Integrated GPUs.
I tried, but it was failing with segmentation fault, with opengl. With vulkan, it ran and showed the window but the computer got hang up. So I was wondering if anyone has tried with just Intel GPUs and what the experience is.

@umateusz chances are that the simulation won't work without a GPU, even in non_rendering_mode. If you achieve it, please report back.

I am aware of a team at a major institution that spent quite a bit of time trying to get CARLA/UnrealEngine working without GPUs (i.e. CPU only with dual-socket Xeon servers) and they did not succeed.

@qhaas
@germanros1987
It is indeed possible to run CARLA without a dedicated GPU, e.g. Nvidia.
I wrote two versions of a Dockerfile for a container with the simulation, which can perfectly run on Intel Mesa:
The first version downloads, installs and executes CARLA. On a simple computer this takes relatively long for the building (>25 min.) and the resulting image has over 9.5GB, but it works.
The second version mounts a packaged CARLA, which improves the building time and resulting image size by a great amount. This is my preferred way of deploying CARLA.
I could share those versions directly with you, just drop me an email at armando.miguel.garcia[at]gmail.com.
Best regards

It did ultimately work out for me with Intel's iGPU, although it is very slow. I have an Intel Coffee Lake processor.

@umateusz chances are that the simulation won't work without a GPU, even in non_rendering_mode. If you achieve it, please report back.

hi, I'm doing the same thing right now. And I have found a way to achieve this. If I run carla without camera sensor support, I can use the dedicated server mode, and it can run with a no rendering mode other than offline rendering. It's useful when I do the simulation for traffic world.

It did ultimately work out for me with Intel's iGPU, although it is very slow. I have an Intel Coffee Lake processor.

Hi @sohamm17 , Can you please share the solution . I am also trying to install Carla in  a similar system with Mesa Intel® HD Graphics 5500 (BDW GT2) and without Nvidia GPU.
Thanks,

Hi, I have just come across this thread looking for a solution to a similar issue. I wanted to run Carla on Ubuntu 22.04 (other parts of my project require this) but this isn't yet supported - so I then thought I could run it in docker instead, however my machine does not have a gpu, nor an intel processor (AMD Ryzen) - For those who have found solutions for the docker image without gpu - are you able to give some suggestions on ways to get this working? (if at all possible)

authors: Armandomiguel ShahudullahKhan SimonLeeGit germanros1987 hh0rva1h markomiz qhaas sohamm17 umateusz


text:
ShaderCompileWorker directory not found error when launching the Editor

Context
Some times this ShaderCompileWorker directory not found error appears when launching unreal Editor or Cooking:

We checked the local build of UnrealEngine5 and the ShaderCompileWorker binary is located here:
UnrealEngine5/Engine/Binaries/Linux/ShaderCompileWorker
Problem
Seems shaders are compiled properly when opening the editor, but we are not sure if this error could cause issues in the future.
Action
As UDN why we are seeing this error and if could cause issues in the future.

UDN TIcket:
https://udn.unrealengine.com/s/question/0D5QP00000JScic0AD/shadercompileworker-directory-not-found-error-when-launching-the-editor

UDN response:
This is a known issue but also innocuous and safe to ignore; it's unfortunately not been deemed a high enough priority to fix in the near term.

source: gharchive/issue

repo: carla-simulator/carla

license: MIT

license_type: permissive

license_source: github-api


text:
Updated detect_lane_obstacle()

Description

Changed implementation using sequentially sliced overlap detection.

Where has this been tested?

Platform(s): Ubuntu 18.04
Python version(s): 2.7
Unreal Engine version(s): 4.21
CARLA version: Carla overnight build of 1st April

Possible Drawbacks
None

This change is

Reference code to calculate the area of intersection of two rotated rectangles:
[(https://stackoverflow.com/questions/44797713/calculate-the-area-of-intersection-of-two-rotated-rectangles-in-python/45268241)]

@germanros1987  We tried running this functionality with more than 100 NPC's, everything seems to work to fine.

If @germanros1987 is fine, we can merge. With shapely it looks much better :)

source: gharchive/pull-request

authors: fabianoboril mohit-awana


text:
RoadPosition and RelativeRoadPosition Implementation

Description
In this PR i have changed

RelativeDistanceCondition: longitudinal, lateral distance calculation. But I tested this for only roads with left lanes and right lanes, but not sure about junctions.

RelativeRoadPosition and RoadPosition (new implementation): This is tested and work fine for me. If you find any cases where it does not work, let me know, I will fix it.

If anything is not clear in the code let me know, I will try to explain.
I am preparing diagrams for use case and will share it asap.

Where has this been tested?

Platform(s): Ubuntu 20.04
Python version(s):  3.8
Unreal Engine version(s): -
CARLA version: 0.9.11

Possible Drawbacks
None, I don't see any conflicts with existing code.
Regards,
Sagar GV

This change is

Hi, I have made the requested the changes.


text:
Suddenly, push as asking for Sqlite which cannot be found

I have been pushing code changes to Heroku for months without this problem. I then added the 'taps' gem two nights ago, and pushed code and that worked fine. When I tried to push code last night, I received the following problems about not being able to install Sqlite and so the push failed.  I commented out the taps gem, shut down and opened my local rails server to reset Gemfile. lock in case that was the problem.  However, the problem persists. I only have the Sqlite gem under my development environment, so it should not need to be installed by Heroku.  Below is the response I get from Heroku.  Thanks.
-----> Heroku receiving push
-----> Ruby/Rails app detected
-----> Installing dependencies using Bundler version 1.1.rc
Running: bundle install --without development:test --path vendor/bundle --deployment
Fetching gem metadata from http://rubygems.org/.......
Using rake (0.9.2)
Using multi_json (1.0.3)
Using activesupport (3.1.0)
Using bcrypt-ruby (3.0.1)
Using builder (3.0.0)
Using i18n (0.6.0)
Using activemodel (3.1.0)
Using erubis (2.7.0)
Using rack (1.3.4)
Using rack-cache (1.0.3)
Using rack-mount (0.8.3)
Using rack-test (0.6.1)
Using hike (1.2.1)
Using tilt (1.3.3)
Using sprockets (2.0.1)
Using actionpack (3.1.0)
Using mime-types (1.16)
Using polyglot (0.3.2)
Using treetop (1.4.10)
Using mail (2.3.0)
Using actionmailer (3.1.0)
Using arel (2.2.1)
Using tzinfo (0.3.30)
Using activerecord (3.1.0)
Using activeresource (3.1.0)
Using coffee-script-source (1.1.2)
Using execjs (1.2.9)
Using coffee-script (2.2.0)
Using rack-ssl (1.3.2)
Using rdoc (3.9.4)
Using thor (0.14.6)
Using railties (3.1.0)
Using coffee-rails (3.1.1)
Using daemons (1.1.4)
Using orm_adapter (0.0.5)
Using warden (1.0.5)
Using devise (1.4.7)
Using eventmachine (0.12.10)
Using jquery-rails (1.0.14)
Using pg (0.11.0)
Using bundler (1.1.rc)
Using rails (3.1.0)
Installing rest-client (1.6.7)
Using sass (3.1.8)
Using sass-rails (3.1.4)
Installing sequel (3.20.0)
Installing sinatra (1.0)
Installing sqlite3 (1.3.4) with native extensions Unfortunately, a fatal error has occurred. Please report this error to the Bundler issue tracker at https://github.com/carlhuda/bundler/issues so that we can fix it. Thanks!
/usr/local/lib/ruby/1.9.1/rubygems/installer.rb:483:in rescue in block in build_extensions': ERROR: Failed to build gem native extension. (Gem::Installer::ExtensionBuildError)        /usr/local/bin/ruby extconf.rb        checking for sqlite3.h... no        sqlite3.h is missing. Try 'port install sqlite3 +universal'        or 'yum install sqlite3-devel' and check your shared library search path (the        location where your sqlite3 shared library is located).        *** extconf.rb failed ***        Could not create Makefile due to some reason, probably lack of        necessary libraries and/or headers.  Check the mkmf.log file for more        details.  You may need configuration options.        Provided configuration options:        --with-opt-dir        --without-opt-dir        --with-opt-include        --without-opt-include=${opt-dir}/include        --with-opt-lib        --without-opt-lib=${opt-dir}/lib        --with-make-prog        --without-make-prog        --srcdir=.        --curdir        --ruby=/usr/local/bin/ruby        --with-sqlite3-dir        --without-sqlite3-dir        --with-sqlite3-include        --without-sqlite3-include=${sqlite3-dir}/include        --with-sqlite3-lib        --without-sqlite3-lib=${sqlite3-dir}/lib        --enable-local        --disable-local        Gem files will remain installed in /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/sqlite3-1.3.4 for inspection.        Results logged to /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/sqlite3-1.3.4/ext/sqlite3/gem_make.out        from /usr/local/lib/ruby/1.9.1/rubygems/installer.rb:486:in block in build_extensions'
from /usr/local/lib/ruby/1.9.1/rubygems/installer.rb:446:in each'        from /usr/local/lib/ruby/1.9.1/rubygems/installer.rb:446:in build_extensions'
from /usr/local/lib/ruby/1.9.1/rubygems/installer.rb:198:in install'        from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/source.rb:90:in block in install'
from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/rubygems_integration.rb:78:in preserve_paths'        from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/source.rb:89:in install'
from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/installer.rb:73:in block in install_gem_from_spec'        from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/rubygems_integration.rb:93:in with_build_args'
from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/installer.rb:72:in install_gem_from_spec'        from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/installer.rb:56:in block in run'
from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/installer.rb:55:in run'        from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/installer.rb:12:in install'
from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/cli.rb:219:in install'        from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/vendor/thor/task.rb:22:in run'
from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/vendor/thor/invocation.rb:118:in invoke_task'        from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/vendor/thor.rb:263:in dispatch'
from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/lib/bundler/vendor/thor/base.rb:386:in start'        from /tmp/build_3urfb7lxl1o98/vendor/bundle/ruby/1.9.1/gems/bundler-1.1.rc/bin/bundle:13:in <top (required)>'
from vendor/bundle/ruby/1.9.1/bin/bundle:19:in load'        from vendor/bundle/ruby/1.9.1/bin/bundle:19:in '
!
!     Failed to install gems via Bundler.
!
!     Heroku push rejected, failed to compile Ruby/rails app

See ISSUES, open a ticket with Heroku.

authors: indirect mciotola

repo: carlhuda/bundler


text:
Bump .NET 6.0 version in global.json

To get rid of the CI test failure when there are missing usings.

The "diagnostic" errors are showing up again, but at least the project builds now. Those errors happen when attempting to port from docs to triple slash comments. Roslyn is picky about this. I will address it in a separate issue.

Thanks for your help, @hoyosjs !

repo: carlossanlop/DocsPortingTool


text:
Fixing production.yml file

Some changes were completed in order for the repo to allow GitHub actions.

The POSTGRES_DB was updated to match the created DB for this repo.
The username and the corresponding docker repository were included so it will push to the correct repo.

No changes, this code could be merged.


text:
Criar uma rota post para avaliação de filmes

[ ] um usuário ter um endpoint para fazer uma avaliação de filme
[ ] um endpoint para pegar a avaliação média do filme

[ ] Criar Model
[ ] Criar Schema
[ ] Criar Rota
[ ]  Criar o Service

repo: carolineccorrea/movies-api


text:
Revert "add event hooks, change method names"

Reverts carpedm20/fbchat#134
Forgot to mention, not quite finished yet, will finish tomorrow or day after tomorrow. Sorry!

Thanks for let us know. I reverted the package as well. Let us know when you finished!

That's my bad, I'm not very experienced with Github yet ;)

license_source: bigquery


text:
Failed to parse brazil number

phone = '+5519988012345'
Phoner::Phone.parse(phone)

This returns a nil but it's a valid number

nvm it was false reprt, it's working fine

repo: carr/phone

license: mit


text:
Not rendering SVG

I did a standard install with CSS and JS (no Entypo as I don't think it's necessary anymore?) and no config options.
The share button pops up without icons:

I'm seeing errors like this in devtools:

+1

Which browser is this in?
--
Henry Snopek
On Thu, Sep 17, 2015 at 9:07 AM, gurumark notifications@github.com
wrote:

+1
Reply to this email directly or view it on GitHub:
https://github.com/carrot/share-button/issues/219#issuecomment-141097848

Firefox 40.0.3 on OSX 10.10

Chrome stable too (M45)

when you hover over the icon what's the message? I'm currently looking at master with Chrome (45.0.2454.93 ) and Canary (47.0.2511.3 canary) and both render this properly. However in Firefox (40.0.3) and FireFoxDeveloperEdition (42.0a2 (2015-08-18)) it isn't, after doing some research in firefox they do not support the "#" unless encoded as "%23". Also didn't realize that <= IE11 the whole string must be encoded. I'll get a PR going for these two fixes

"Invalid property value".
Is there a working demo? As the linked one at http://sharebutton.co/ I think is using the old Entypo model.
Here's a JSBin illustrating the problem

Actually it may be related to the use of double-quotes.
The JSBin does work once I fixed up quote marks (the background property is valid though I can't see it in the web page). http://jsbin.com/weluzi/3/edit?html,css,output
Likewise, in the CSS, it looks like double-quotes are nested, I presume there be escaping or single quotes used to avoid that.

Yes, that fixed it! I simply changed the surrounding double-quotes to single quotes, ie from url("data ... </svg>") to url('data ... ')`.
I see the Stylus already contains single-quotes, but the CSS in dist/ uses double-quotes?

Yeah so only compile stylus changes this over, not sure why
--
Henry Snopek
On Fri, Sep 18, 2015 at 12:40 AM, Michael Mahemoff
notifications@github.com wrote:

Yes, that fixed it! I simply changed the surrounding double-quotes to single quotes, ie from url("data ... </svg>") to url('data ... ')`.
I see the Stylus already contains single-quotes, but the CSS in dist/ uses double-quotes?
Reply to this email directly or view it on GitHub:
https://github.com/carrot/share-button/issues/219#issuecomment-141350939

Excuse the strange grammer, it was pretty late when I sent that. Basically stylus is processing the single quotes into double quotes. Locally when I was adjusting styles, encoding the # within the color made it viewable again.  in the compiled source everything is still double quoted.  As the quotes are technically optional we could remove them from our stylus, but this results in errors from stylus.

hey, i was having the same problem, i finally was able to solve it with those two changes:

converting all "data...." into single quote, like you guys suggested (thanks!), but that wasn't enough in my case, so i got to stage 2:
adding
top:12px;
left:30px;
in the same css file, to the class "share-button .sb-social ul li:before,
share-button .sb-social ul li:after"

only than the icons appeared.
hope this helps someone... :)

@hafi86 Strange; I have it in production now using only the single-quote change.

BTW I'm leaving this open though maybe only a patch to stylus would fix it? (short of a hacky post-processing string replace)

I'm thinking of switching the preprocessor (stylus) of to postcss or just creating a mixin to overwrite 'url()' which would then use JavaScript to remove quotes and encode the string with 'encodeComponentURI()'.
--
Henry Snopek
On Tue, Sep 22, 2015 at 9:59 AM, Michael Mahemoff
notifications@github.com wrote:

BTW I'm leaving this open though maybe only a patch to stylus would fix it? (short of a hacky post-processing string replace)
Reply to this email directly or view it on GitHub:
https://github.com/carrot/share-button/issues/219#issuecomment-142313901

got stylus and jade mixed up, your right it would have to use a post processing hack... I'm thinking of just moving this into postcss now

Yes, i find it strange too, but changing to signle-quote only helped for the icon on the button itself (the one that shows on the button before clicking 'share'), not sure why.
Thank you for your help.

I have a fix locally for this, I'll get this up within the next couple hours

@mahemoff wanna take a look at #227 before I merge?

Hi guys, I had issues today with SVG in Firefox (I started using the plugin yesterday), reviewed the quotation fix method and didn't work.
I found this solution in StackOverflow (http://stackoverflow.com/a/21626701) that actually makes the whole sense, removing every problem related with quotations just doing some pre-process with the SVG code (Base64 encoding).
It worked like a charm for me, so I hope you find this useful guys

I had the same issues with Chrome today. I solved it (but only for Chrome) by urldecode the SVG in the css and set the width and height to 100%. Maybe the issue is caused by the frameworks I use around. eg. Flexbox.
Unfortunately it doesn't run now in Firefox and Safari :)

Ya, the example seems to be broken again. It's not displaying the SVGs for me in Chrome Version 50.0.2661.94 (64-bit) and on MacBook Pro OS X Yosemite 10.10.5

Same here. Chrome 50.0.2661.94 on El Captain 10.11.1. Any news on this?

@perjonsson you may find an answer over at this issue. I ended up downloading the svg's and then referencing those instead of the data uri.
Another guy said he did the same on the other issue.

authors: Exclam gurumark hafi86 hhsnopek mahemoff natecook perjonsson raulhuelamo

repo: carrot/share-button


text:
Request Installation Guide For Denariiumx-server

Hi, Can you provide me a installation guide on ubuntu because from https://github.com/kyuupichan/electrumx/blob/master/docs/HOWTO.rst doesn't work for me nor I don't quit get it.

Yes that is the installation guide, its fairly straight forward, just Python3.6, denariusd, and some configuration, though Denariium is still a WIP and may not work properly yet, upon release, binaries will be provided for each OS. Compiling or installing from the git currently without development experience with Electrum or Python is not recommended and not supported.

I Managed to start the server but it stocks on this,
INFO:root:ElectrumX server starting WARNING:Env:lowered maximum sessions from 1,000 to 674 because your open file limit is 1,024 INFO:Controller:event loop policy: None INFO:FakeEstimateFeeDaemon:daemon #1 at 127.0.0.1:33339/ (current) INFO:BlockProcessor:switching current directory to /home/ubuntu/.electrumx/ INFO:BlockProcessor:using leveldb for DB backend INFO:BlockProcessor:opened DB for serving INFO:BlockProcessor:closing DB to re-open for sync INFO:BlockProcessor:opened DB for sync INFO:BlockProcessor:software version: ElectrumX 1.1 INFO:BlockProcessor:DB version: 5 INFO:BlockProcessor:coin: Denarius INFO:BlockProcessor:network: mainnet INFO:BlockProcessor:height: -1 INFO:BlockProcessor:tip: 0000000000000000000000000000000000000000000000000000000000000000 INFO:BlockProcessor:tx count: 0 INFO:BlockProcessor:flush count: 0 INFO:BlockProcessor:sync time so far: 00s INFO:BlockProcessor:reorg limit is 1,000 blocks INFO:BlockProcessor:flushing DB cache at 1,200 MB INFO:Controller:RPC server listening on localhost:8000 ERROR:FakeEstimateFeeDaemon:disconnected.  Retrying occasionally...

Yes it's still a WIP, the FakeFeeEstimateDaemon can be specified in the lib/coins.py, I need to get it corrected for DNR, if you end up finding a fix before me, feel free to put up a PR.

authors: carsenk knkrth

repo: carsenk/denariiumx-server


text:
remove gulp-util

https://medium.com/gulpjs/gulp-util-ca3b1f9f9ac5
remove gulp-util using the following API replacements:

gutil.File => https://www.npmjs.com/package/vinyl
gutil.replaceExtension => The .extname property on Vinyl objects or https://www.npmjs.com/package/replace-ext
gutil.colors => https://www.npmjs.com/package/ansi-colors
gutil.date => https://www.npmjs.com/package/date-format
gutil.log => https://www.npmjs.com/package/fancy-log
gutil.template => https://www.npmjs.com/package/lodash.template
gutil.env => https://www.npmjs.com/package/minimist
gutil.beep => https://www.npmjs.com/package/beeper
gutil.noop => https://www.npmjs.com/package/through2
gutil.isStream => Use the .isStream() method on Vinyl objects
gutil.isBuffer => Use the .isBuffer() method on Vinyl objects
gutil.isNull => Use the .isNull() method on Vinyl objects
gutil.linefeed => Use the string '\n' in your code
gutil.combine => https://www.npmjs.com/package/multipipe
gutil.buffer => https://www.npmjs.com/package/list-stream
gutil.PluginError => https://www.npmjs.com/package/plugin-error

It looks like this was fixed in #10, but the new version was never published on npm.

authors: mdawaffe simonmulser

repo: carstenschaefer/gulp-delete-lines


text:
Couldn't Achive the app purpose

after I Tried the following, Couldn't find the created point/points on the map or even the layer
Stage 1:
(user: ev, pass:123456)
Selected map: Map x
Selected Layer: animal_abuse_lacity
Form Customization: Default state
selected loge,
App Title: Testing Collection new points
abstract:At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium
accesss: em, vo
keywords: keyword1
navigation tools: default state,
App instance create successfullt,
Stage 2:
chosen the following:

Clicked next and Successfully: Your Data Saved Successfully
please Notice that I tried to do extra check up and launched cartoview feature list and found the points in the list of feature but not rendered on the map

fixed in the latest version

authors: hishamkaram khaledboka


text:
Update Contributing

Closes https://github.com/casesandberg/react-color/issues/266
@Prinzhorn does this provide enough information to get you started?

I guess. I got the docs running and can change code. That's all I needed.

authors: Prinzhorn casesandberg

repo: casesandberg/react-color


text:
Windows shebang recipe

I ran into a strange behavior running a shebang recipe on windows.
I currently don't have cygpath installed so I don't have "/" in the interpreter path as per documentation ("If the interpreter path does not contain a / it will be executed without being translated. ") here.
The following just script:
default:
    #!bash
    echo "Greetings from Just"

throws this error:
/bin/bash: C:UsersfabioAppDataLocalTempjust-9dsFivdefault: No such file or directory
error: Recipe `default` failed with exit code 127

While this modified scripts works just fine:
export DUMMY_VARIABLE := "DUMMY_VALUE"

default:
    #!bash
    echo "Greetings from Just"

My intuition is that the export command sorts of "bootstraps" the bash execution environment, but I was wondering if I'm missing something or what is the explanation for this behavior.
Thanks,
Fabio

Thanks for the report! I opened #2144 with a test for this, and is passes on windows CI. Are you able to run bash in the terminal by itself?

Yes but, I don't know if it's relevant, I've changed the default path in the dos terminal from where I run just to execute the bash shipped with git instead of the one in "C:\Windows\System32" which I suppose is the WLS one.
Maybe I messed up my environment is some other way...
No big deal, as the workaround is trivial, I was just curious to understand what happens under the hood.
Thanks - Fabio

Interesting, I'm thinking it must be some kind of configuration issue. Let me know if you run into problems again!

authors: casey fabiomoratti

repo: casey/just


text:
Null island bug (support for 0,0 co-ordinates)

support for 0,0 co-ordinates
GeoJSON.parse([{ lat: 0, lng: 0 }], {Point: ['lat', 'lng']}, function(geojson){
  console.log( JSON.stringify( geojson, null, 2 ) );
});

before:
{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {},
      "properties": {}
    }
  ]
}

after:
{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [
          0,
          0
        ]
      },
      "properties": {}
    }
  ]
}

Thanks. Looks good. Do you mind rebasing on master and removing the merge commit? I'll merge this then publish a new release.

heya @caseypt how does that look now?

Thanks! Yeah, I'll take care of it.

Publish v0.2.1 to npm

awesome thanks!

authors: caseypt missinglink


text:
Add envelope encryptor

This is a module to use envelope encryption with Tink and Cloud KMS. Currently, only encryption is supported and DEKs are generated using AES256_GCM.

I think this is a very interesting addition to the open source misk framework.
A few comments/question:

Right now, this module is GCP centric - the config only supports using a GCP KMS. WDYT about trying to open up this abstraction to make it KMS agnostic?
What's the main use case for using KMS envelope encryption? Usually, KMS is used to encrypt other encryption keys - it's not meant to be used in high QPS ops.
Personally, I'd start with adding this binding in the Square version - skim, and see if you can generalize it afterwards to this project.

Closing to move to Skim

authors: choi-calvin yoavamit

repo: cashapp/misk


text:
mactex repeatedly re-downloading

The mactex formula was recently changed to not track its version and as a result a script I have that does updates by running brew cask install mactex repeatedly reinstalls mactex even though it is already up to date.

The title of this issue is misleading. It’s not mactext that is misbehaving.
brew cask install shouldn’t be installing something that is already installed, though (unless you give it the --force flag). brew cask list, however, is broken so the way of checking for the installation of mactex may be screwing up as well.
For now, you can try to brew cask uninstall --force mactex && brew cask install mactex and see if it fixes it, but more likely you’ll have to fix your script. mactex doesn’t provide a versioned download (if you don’t like that, you need to complain to the developers, not us) so there’s no way to know if your installed version is up to date or not, anyway.

Here’s the reason we switched it.

https://github.com/caskroom/homebrew-cask/pull/18908

authors: FranklinChen adidalal vitorgalvao

repo: caskroom/homebrew-cask


text:
add graffitipot

This is 2ch browser application.

Thank you for the contribution. It needed some fixes, so they were made in 1ad240e4f2d517422c04bdd38e03121039b65104. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.

Thanks for your help.


text:
Add Remomix.app v0.2.1

Adding a new cask

[x] Checked there aren’t open pull requests for the same cask.
[x] Checked there aren’t closed issues where that cask was already refused.
[x] When naming the cask, followed the token reference.
[x] Commit message includes cask’s name.
[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] brew cask install {{cask_file}} worked successfully.
[x] brew cask uninstall {{cask_file}} worked successfully.

Thank you for the contribution. It needed some fixes, so they were made in f8e1f004453c511a328ccafa2fb5c72e0d6f03c5. Your contribution is still included (and still credited to you), with the appropriate modifications. Please feel free to ask about any of the changes.

authors: jawshooah johndbritton


text:
Update navicat-for-postgresql to 11.2.15

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Closes #26320.

All the navicat casks need a version bump. There's a bash script in an older issue if you want that just calls cask repair on each

I am not sure what you mean @adidalal - according to their website version 11.2.15 is the latest?

All done @adidalal.

Thanks!

authors: adidalal miccal


text:
Update checksum in moneymoney.rb for v 2.2.14

Checksum changed though for some reason the software version did not.

The checkpoint also needs to be updated:
- appcast checkpoint mismatch
Expected: d818c995d76021e31156c296b69c175d77818a3e0506c49136ba2041d3ab4cef
Actual: f0f575e751df4210aaf8a27da3415fba286e20986fba70bbd3bd093495fb83a4

Just updated it ^^

authors: miccal rqelibari


text:
OWASP-ZAP 2.6.0 Checksum

Fix the checksum
If there’s a checkbox you can’t complete for any reason, that's okay, just explain in detail why you weren’t able to do so.
After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} reports no offenses.
[x] The commit message includes the cask’s name and version.

Additionally, if adding a new cask:

[ ] Named the cask according to the token reference.
[ ] brew cask install {{cask_file}} worked successfully.
[ ] brew cask uninstall {{cask_file}} worked successfully.
[ ] Checked there are no open pull requests for the same cask.
[ ] Checked the cask was not already refused in closed issues.
[ ] Checked the cask is submitted to the correct repo.

Thank you for your contribution.

authors: bdwyertech miccal


text:
Signer 1.3.0 shows no account selected

Issue: As in the screenshot if a user has multiple account and logs in after a lockout shows no account selected.

I wasn't able to repro this - @cspramit would you mind trying again with the new asset (I'm just about to attach it) to see if it's resolved?

@George-cl Yes seems to be a CNR, the defect can be closed.

authors: George-cl cspramit

repo: casper-ecosystem/signer


text:
Merge dev to feat-fast-sync 4.03.2022

This PR integrates the recent changes from the dev (as of 4.03.2022 11:00am CEST) branch into the feat-fast-sync branch.

bors r+

repo: casper-network/casper-node


text:
Reproducing Results for Anserini

Development Environment

Fresh WSL Ubuntu 20.04.4 on Windows 10
Python 3.8.13
Java 11.0.13
Apache Maven 3.8.6

@Pie31415 I assumed regressions checked out and all the numbers match?

btw, when I navigate to your commit id https://github.com/castorini/anserini/commit/8f3104af21b9e4c369b22d0b9af4bf423680c4c8 , I get:
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Please change this to the commit id of the anserini repo that you ran the regressions on?

@Pie31415 I assumed regressions checked out and all the numbers match?

Yes, my results matched the ones that appeared on the guide.

Codecov Report

Merging #1917 (3c90889) into master (308138e) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head 3c90889 differs from pull request most recent head 13cee56. Consider uploading reports for the commit 13cee56 to get more accurate results

@@            Coverage Diff            @@
##             master    #1917   +/-   ##
=========================================
  Coverage     58.67%   58.67%
  Complexity     1079     1079
=========================================
  Files           180      180
  Lines         10420    10420
  Branches       1429     1429
=========================================
  Hits           6114     6114
  Misses         3786     3786
  Partials        520      520

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 308138e...13cee56. Read the comment docs.

btw, when I navigate to your commit id 8f3104a , I get:
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Please change this to the commit id of the anserini repo that you ran the regressions on?

Alright, I fixed the commit id.

authors: Pie31415 codecov-commenter lintool

repo: castorini/anserini


text:
Switch from dev to main/nightly/stable branch structure.

Overview

Update docs and build scripts to reflect new branch structure.
Run builds every night, but only if there are changes.
Rename nightly-build-outputs.catalyst.coop bucket to builds.catalyst.coop.
Remove docker/.env file and define those envvars elsewhere.
Add some basic release notes about our new branches / workflow

Closes #3140
Closes #3179
Testing
Ran a test build on the branch before it got merged into dev and all went well. The real test will be... do the nightly builds run the way we think they should.
# To-do list
- [ ] Make sure full ETL runs & `make pytest-integration-full` passes locally
- [ ] For major data coverage & analysis changes, [run data validation tests](https://catalystcoop-pudl.readthedocs.io/en/latest/dev/testing.html#data-validation)
- [ ] If updating analyses or data processing functions: make sure to update or write data validation tests
- [ ] Update the [release notes](../docs/release_notes.rst): reference the PR and related issues.
- [ ] Review the PR yourself and call out any questions or issues you have

Goodbye dev 😭

repo: catalyst-cooperative/pudl


text:
Add support for  keyword

Python doctest is using the keyword <BLANKLINE> for declaring empty lines within a doctest result. Using such a keyword helps the doctest parser finding connected blocks of tests.
See

https://docs.python.org/3.7/library/doctest.html#how-are-docstring-examples-recognized
https://github.com/catch22/octave-doctest/pull/236#issuecomment-537386844

This would only matter with -NORMALIZE_WHITESPACE---by default, we match any whitespace.
But I don't see any problem with some minimal support for these, e.g., replacing them with empty strings in want before comparing to got.

Right, I thought of this to be a helper for the regex searching and seperating the doctests. In the end <BLANKLINE> gets replaced by a newline character.

I don't think we've needed this one so far (and we default to normalizing whitespace since there are differences between Octave and Matlab IIRC). Is this solving any problem that arises when using Sphinx?

Right. Rethought this. Matlab prints out lots of blank lines, so legability would definitly suffer from such a keyword. But, without having looked at the code; when do you decide what line is still part of the doctest output and what part is of the helptext. Like in this test:
https://github.com/catch22/octave-doctest/blob/master/test/test_whitespace.m
Is it the two empty lines?

That's right.


text:
chore(master): release 3.4.0

:robot: I have created a release beep boop
3.4.0 (2024-08-07)
Features

directive: move directive to define (2ba450b)

This PR was generated with Release Please. See documentation.

:robot: Created releases:

v3.4.0
:sunflower:

repo: cathaysia/tree-sitter-idl


text:
ShareX Themes

added themes and renamed the previous theme folder to image effect

hm

repo: catppuccin/sharex


text:
🛑 BA Anglers is down

In 581bfe7, BA Anglers (https://www.buenosairesanglers.com/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: BA Anglers is back up in 42a251e.

repo: cavalicenti/upptime


text:
Add support for Optimism

The Multicall contract is deployed and verified:

Kovan Optimism: https://kovan-optimistic.etherscan.io/address/0x4afaa782d74825a267e40ae2a231c271d1c392c3
Optimism: https://optimistic.etherscan.io/address/0x7cbc68dc836e05833cf88b6676715db805b5c0a2

resolves #26

Can this get merged? Seems like a straight-forward addition

ping @cavanmflynn can we get this merged please?

For anyone who is interested to use this library w/ Optimism support, I have temporarily forked to @kargakis/ethers-multicall until this PR gets merged.

are you alive?

For anyone looking for a live, tested and maintained alternative to ethers-multicall, please move to ethers-multicall-provider

authors: 0xtaf CarlGocht Rubilmax damianmarti kargakis

repo: cavanmflynn/ethers-multicall


text:
Renderer process can not import electron

I add below code to renderer/app.vue
import {ipcRenderer} from 'electron';

then npm run watch report errors index.js:4 Uncaught ReferenceError: __dirname is not defined
npm run compile success, but load failed and report errors index.html:1 Uncaught TypeError: Failed to resolve module specifier "electron". Relative references must start with either "/", "./", or "../".

Fixed by Using electron API in renderer.

Hey. I have the same question now. How to access to electron from vue template now right way? Fix description already removed ;(

@ErriourRU. Docs. In preload you should create global function or something. And just use it in renderer from global scope

authors: ErriourRU cawa-93 xiaohulu


text:
🛑 Mis Revistas is down

In 3b1df56, Mis Revistas (https://www.misrevistas.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Mis Revistas is back up in dc6cc67.

repo: cayepezg/status


text:
bolt: Performance degradation while loading Freebase dump

Description
I'm trying to load full Freebase dump into cayley, but load performance is degrading, and it looks like the load process will never finish.
At first I've run a series of experiments to determine the fastest way to load the data. Here are the results (cells contain minutes needed to load the number of quads from the column header). As we can see Bolt + pq + nosync + 2.5M had the best performance (not sure though that nosync contributed at all)
| 5M | 10M | 15M | 20M | 25M
-- | -- | -- | -- | -- | --
Bolt + nq + 10k | 2 | 7 | 16 | 20 | 29
Bolt + nq + 50k | 2 | 5 | 13 | 15 | 23
Bolt + nq + 100k | 2 | 5 | 12 | 14 | 20
Bolt + nq + 200k | 2 | 5 | 10 | 12 | 17
Bolt + nq + 500k | 2 | 5 | 8 | 10 | 13
Bolt + nq + 500k | 2 | 5 | 8 | 9 | 12
Bolt + nq + 1.25M | 2 | 5 | 7 | 9 | 12
Bolt + nq + 2.5M | 2 | 5 | 7 | 9 | 12
Bolt + nq + 5M | 3 | 5 | 8 | 9 | 12
Bolt + nq + 1M + nosync | 2 | 5 | 7 | 9 | 12
Bolt + nq + 2.5M + nosync | 2 | 5 | 7 | 9 | 11
Bolt + pq.gz + 1.25M | 2 | 4 | 7 | 8 | 10
Bolt + pq + nosync + 1.25M | 2 | 4 | 6 | 7 | 10
Bolt + pq + nosync + 2.5M | 2 | 4 | 6 | 7 | 9
Leveldb + nq + buffer 20 + 10k | 4 | 12 | 26 |   |
Leveldb + pq.gz + buffer 20M + 1.25M | 1 | 8 | 16 | 18 | 27
Leveldb + nq + buffer 20M + 5M | 2 | 18 |   |   |
Leveldb + pq.gz + buffer 200M + 1.25M | 1 | 8 | 16 | 18 | 27
Leveldb + pq.gz + buffer 1G + 1.25M | 1 | 8 | 16 | 18 | 27
Leveldb + pq.gz + buffer 1G + 500k | 1 | 5 | 11 | 13 | 19
Leveldb + pq.gz + buffer 4G + 500k | 1 | 5 | 11 | 13 | 19
Leveldb + pq.gz + buffer 4G + 1.25M | 1 | 8 | 16 | 18 | 27
Leveldb + pq.gz + buffer 4G + cache 200M + 1.25M | 1 | 8 | 16 | 18 | 28

Steps to reproduce the issue:

cayley load -c bolt.yml --verbose=3 -i freebase.pq
bolt.yml:

store:
  backend: bolt
  address: bolt
load:
  batch: 2500000

Received results:
At first, everything was ok, but then load started to slow down. The graph can demonstrate it better:

Then I've decided to make smaller batches and add nosync:

cayley load -c bolt.yml --verbose=3 -i freebase.pq
bolt.yml:

store:
  backend: bolt
  address: bolt
  options:
    nosync: true
load:
  batch: 500000

Things became a bit better, but not for long:

htop says the process consumes more and more memory (58gb after 2 days)
Expected results:
Freebase loaded in less than infinity
Output of cayley version or commit hash:
Cayley version: 0.7.5
Git commit hash: cf576babb7db

Environment details:
CPU: 8 x Intel(R) Xeon(R) CPU @ 2.30GHz
Memory: 29Gb
OS: Ubuntu 16.04.6 LTS
Disk: SSD
Backend database: (database and version)
Bolt, not sure about version - cayley handled that for me
So the question is - am I doing it wrong or is there some bug?

Yes, this can be considered a performance-related bug in the import implementation.
Can you please try 79d7d62393142cfd7035e942cc705f6947e7bcbb? It should improve import performance considerably.
But we may need other changes as well to make it faster for those large dumps specifically. For example, a two-stage import process may be faster because we can pre-compute nodes table during the first pass and then resolve quads during the second pass, so the nodes table is mostly in read-only mode during the second pass.

I tried to load data using the latest master (I believe the commit you've referenced is already in there), and probably things became a bit better, but the pattern seems to be the same:

Also, the docker was killed with 137 code (OOM) in 1.5h (98M quads was processed)

On another try received this:
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x150ab5f, 0x16)
	/usr/local/go/src/runtime/panic.go:608 +0x72
runtime.sysMap(0xc68c000000, 0x3c000000, 0x22e1738)
	/usr/local/go/src/runtime/mem_linux.go:156 +0xc7
runtime.(*mheap).sysAlloc(0x22c0640, 0x3c000000, 0x7f16c9bdaf80, 0x7f16a3013bc0)
	/usr/local/go/src/runtime/malloc.go:619 +0x1c7
runtime.(*mheap).grow(0x22c0640, 0x1d6b2, 0x0)
	/usr/local/go/src/runtime/mheap.go:920 +0x42
runtime.(*mheap).allocSpanLocked(0x22c0640, 0x1d6b2, 0x22e1748, 0x2030b500000000)
	/usr/local/go/src/runtime/mheap.go:848 +0x337
runtime.(*mheap).alloc_m(0x22c0640, 0x1d6b2, 0xffffffffffff0100, 0x7f16a3013c78)
	/usr/local/go/src/runtime/mheap.go:692 +0x119
runtime.(*mheap).alloc.func1()
	/usr/local/go/src/runtime/mheap.go:759 +0x4c
runtime.(*mheap).alloc(0x22c0640, 0x1d6b2, 0x7f16a3010100, 0x418415)
	/usr/local/go/src/runtime/mheap.go:758 +0x8a
runtime.largeAlloc(0x3ad64000, 0x450001, 0x7f1732460000)
	/usr/local/go/src/runtime/malloc.go:1019 +0x97
runtime.mallocgc.func1()
	/usr/local/go/src/runtime/malloc.go:914 +0x46
runtime.systemstack(0xc067a6fe00)
	/usr/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
	/usr/local/go/src/runtime/proc.go:1229

goroutine 1 [running]:
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:311 fp=0xc004d1efd0 sp=0xc004d1efc8 pc=0x459700
runtime.mallocgc(0x3ad64000, 0x141dca0, 0x1, 0xffffffffffffffff)
	/usr/local/go/src/runtime/malloc.go:913 +0x896 fp=0xc004d1f070 sp=0xc004d1efd0 pc=0x40e2e6
runtime.growslice(0x141dca0, 0xc5d8d58000, 0xbc4700, 0xbc4700, 0xbc4701, 0x0, 0xc000170000, 0xc004d1f178)
	/usr/local/go/src/runtime/slice.go:204 +0x145 fp=0xc004d1f0d8 sp=0xc004d1f070 pc=0x444445
github.com/boltdb/bolt.(*node).put(0xc0002483f0, 0xc2ad76f168, 0x8, 0x8, 0xc2ad76f168, 0x8, 0x8, 0xc462a3f120, 0x1b, 0x1b, ...)
	/go/pkg/mod/github.com/boltdb/bolt@v1.3.1/node.go:131 +0x3dd fp=0xc004d1f188 sp=0xc004d1f0d8 pc=0x908bed
github.com/boltdb/bolt.(*Bucket).Put(0xc3cddf2a00, 0xc2ad76f160, 0x8, 0x8, 0xc462a3f120, 0x1b, 0x1b, 0x30, 0x12e4ae0)
	/go/pkg/mod/github.com/boltdb/bolt@v1.3.1/bucket.go:309 +0x26d fp=0xc004d1f238 sp=0xc004d1f188 pc=0x8ff9ad
github.com/hidal-go/hidalgo/kv/bolt.(*Tx).Put(0xc03e41b620, 0xc2d68d9950, 0x2, 0x2, 0xc462a3f120, 0x1b, 0x1b, 0x1, 0x10f14ea)
	/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/bolt/bolt.go:161 +0x13f fp=0xc004d1f2a0 sp=0xc004d1f238 pc=0x9125ff
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).addToLog(0xc000281900, 0x174aa20, 0xc03e41b620, 0xc004d1f428, 0x2, 0x2)
	/cayley/graph/kv/indexing.go:886 +0x245 fp=0xc004d1f358 sp=0xc004d1f2a0 pc=0xad8075
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).indexLink(0xc000281900, 0x174aa20, 0xc03e41b620, 0xc004d1f428, 0x0, 0x0)
	/cayley/graph/kv/indexing.go:636 +0x1a1 fp=0xc004d1f3d8 sp=0xc004d1f358 pc=0xad5701
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).indexLinks(0xc000281900, 0x1744b20, 0xc0000b2028, 0x174aa20, 0xc03e41b620, 0xc4ec708000, 0x7a114, 0x7a120, 0x0, 0x0)
	/cayley/graph/kv/indexing.go:614 +0x113 fp=0xc004d1f4e8 sp=0xc004d1f3d8 pc=0xad5483
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).applyAddDeltas(0xc000281900, 0x174aa20, 0xc03e41b620, 0x0, 0x0, 0x0, 0xc13b3d0ea0, 0x22d0001, 0x173a2a0, 0xc32781cbe0, ...)
	/cayley/graph/kv/indexing.go:484 +0x6e4 fp=0xc004d1f8e8 sp=0xc004d1f4e8 pc=0xad38f4
github.com/cayleygraph/cayley/graph/kv.(*quadWriter).WriteQuads(0xc004d30060, 0xc004d5a000, 0x7a120, 0x7a120, 0xc0000c00a0, 0xc004d5a000, 0x7a120)
	/cayley/graph/kv/indexing.go:388 +0xa1 fp=0xc004d1f960 sp=0xc004d1f8e8 pc=0xad2dc1
github.com/cayleygraph/cayley/internal.(*batchLogger).WriteQuads(0xc0000c00c0, 0xc004d5a000, 0x7a120, 0x7a120, 0x7a120, 0x0, 0x0)
	/cayley/internal/load.go:146 +0x59 fp=0xc004d1f9c8 sp=0xc004d1f960 pc=0x75fe09
github.com/cayleygraph/cayley/quad.CopyBatch(0x1731b40, 0xc0000c00c0, 0x7f172d9f8ae0, 0xc0000c00a0, 0x7a120, 0xc0000c00a0, 0x0, 0x0)
	/cayley/quad/rw.go:145 +0x1dc fp=0xc004d1fa70 sp=0xc004d1f9c8 pc=0x746d1c
github.com/cayleygraph/cayley/internal.DecompressAndLoad(0x173bfa0, 0xc004d30060, 0x7a120, 0x7ffdb3958f78, 0x14, 0x0, 0x0, 0x0, 0x0)
	/cayley/internal/load.go:133 +0x17c fp=0xc004d1fae8 sp=0xc004d1fa70 pc=0x75fc7c
github.com/cayleygraph/cayley/internal.Load(0x173bfa0, 0xc004d30060, 0x7a120, 0x7ffdb3958f78, 0x14, 0x0, 0x0, 0x14fc8ff, 0xa)
	/cayley/internal/load.go:21 +0x71 fp=0xc004d1fb40 sp=0xc004d1fae8 pc=0x75ec31
github.com/cayleygraph/cayley/cmd/cayley/command.openForQueries(0xc00027cc80, 0x0, 0x0, 0x0)
	/cayley/cmd/cayley/command/database.go:259 +0x2bb fp=0xc004d1fc48 sp=0xc004d1fb40 pc=0x8d2ceb
github.com/cayleygraph/cayley/cmd/cayley/command.NewHttpCmd.func1(0xc00027cc80, 0xc000100fd0, 0x0, 0xb, 0x0, 0x0)
	/cayley/cmd/cayley/command/http.go:24 +0x9f fp=0xc004d1fce8 sp=0xc004d1fc48 pc=0x8d860f
github.com/spf13/cobra.(*Command).execute(0xc00027cc80, 0xc000100f20, 0xb, 0xb, 0xc00027cc80, 0xc000100f20)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:826 +0x473 fp=0xc004d1fdd8 sp=0xc004d1fce8 pc=0x5c0fa3
github.com/spf13/cobra.(*Command).ExecuteC(0x2124ae0, 0x2124d60, 0xc00023db80, 0xc000191f88)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914 +0x2f8 fp=0xc004d1ff20 sp=0xc004d1fdd8 pc=0x5c1998
github.com/spf13/cobra.(*Command).Execute(0x2124ae0, 0xc00027ca00, 0xc00027cc80)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864 +0x2b fp=0xc004d1ff50 sp=0xc004d1ff20 pc=0x5c167b
main.main()
	/cayley/cmd/cayley/cayley.go:187 +0x31 fp=0xc004d1ff98 sp=0xc004d1ff50 pc=0x10c8061
runtime.main()
	/usr/local/go/src/runtime/proc.go:201 +0x207 fp=0xc004d1ffe0 sp=0xc004d1ff98 pc=0x42f197
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc004d1ffe8 sp=0xc004d1ffe0 pc=0x45b7e1

goroutine 19 [syscall, 191 minutes]:
os/signal.signal_recv(0x0)
	/usr/local/go/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 20 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0x22b7240)
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:882 +0x8b
created by github.com/golang/glog.init.0
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:410 +0x203

@eawer Thanks a lot for providing the stack trace and new test results! I can confirm that the new code path is used.
Can you please try setting --batch to lower values? The new code path should behave differently with the same parameters, so the table in the first post may show a different optimal batch size. Setting batch too high will lead to OOM with certainty, since the whole transaction of that size will be buffered to memory by BoltDB.
In general, BoltDB does not perform well with random writes which happen frequently during import of a dataset of this size. You may also try switching to Badger instead for this import. You may need to set the --batch to even lower values because the way transactions work in Badger, but the write performance should be much better. Note, however, that Badger backend is not fully tested yet.

Badger failed with such error:
I0821 08:20:19.862643       1 cayley.go:63] Cayley version: v0.7.x-dev (300dcf1f8503)
I0821 08:20:19.862868       1 cayley.go:76] using config file: etc/cayley.json
I0821 08:20:19.862959       1 database.go:193] using backend "badger" (/data/badger)
2019/08/21 08:20:19 Replaying from value pointer: {Fid:0 Len:0 Offset:0}
2019/08/21 08:20:19 Iterating file id: 0
2019/08/21 08:20:19 Iteration took: 23.881µs
2019/08/21 08:20:20 Replaying from value pointer: {Fid:0 Len:42 Offset:225}
2019/08/21 08:20:20 Iterating file id: 0
2019/08/21 08:20:20 Iteration took: 17.805µs
I0821 08:20:20.536147       1 load.go:149] Wrote 5000 quads.
I0821 08:20:20.604970       1 load.go:149] Wrote 10000 quads.
I0821 08:20:20.680754       1 load.go:149] Wrote 15000 quads.
I0821 08:20:20.752241       1 load.go:149] Wrote 20000 quads.
I0821 08:20:20.809708       1 load.go:149] Wrote 25000 quads.
I0821 08:20:20.838822       1 load.go:149] Wrote 25000 quads.
Error: db: failed to load data: Txn is too big to fit into one request
...
E0821 08:20:21.287193       1 cayley.go:188] db: failed to load data: Txn is too big to fit into one request

After replacing badger 1.5.5 with 1.6.0 docker build fails with
# github.com/hidal-go/hidalgo/kv/flat/badger
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:46:5: opt.Dir undefined (type func(string) badger.Options has no field or method Dir)
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:47:17: cannot use opt (type func(string) badger.Options) as type badger.Options in argument to Open
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:77:21: too many arguments in call to tx.tx.Commit
	have (nil)
	want ()
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:149:9: assignment mismatch: 2 variables but 1 values
/go/pkg/mod/github.com/hidal-go/hidalgo@v0.0.0-20190814174001-42e03f3b5eaa/kv/flat/badger/badger.go:149:30: not enough arguments in call to it.it.Item().Value
	have ()
	want (func([]byte) error)

Regarding smaller batches - I put it on test and will paste the results here right after I have them.

db: failed to load data: Txn is too big to fit into one request

This is expected, and this is exactly the reason why I suggested lowering --batch even more for Badger. It may be way below the default of 10K.
Regarding 1.6, we can update Hidalgo later to support it.

Reducing batch size to 10k for bolt did not help a lot, process ended with no trace, but because of OOM with something like this https://github.com/cayleygraph/cayley/issues/815#issuecomment-523063489 in the journal

Badger started to work as expected only on 1k batch size, but after all crashed like this:
I0821 13:46:05.629259       1 load.go:149] Wrote 91399000 quads.
fatal error: runtime: out of memory
runtime stack:
runtime.throw(0x150ab5f, 0x16)
	/usr/local/go/src/runtime/panic.go:608 +0x72
runtime.sysMap(0xc6e4000000, 0x8000000, 0x22e1738)
	/usr/local/go/src/runtime/mem_linux.go:156 +0xc7
runtime.(*mheap).sysAlloc(0x22c0640, 0x8000000, 0x0, 0x7fb6928a7b98)
	/usr/local/go/src/runtime/malloc.go:619 +0x1c7
runtime.(*mheap).grow(0x22c0640, 0x20fa, 0x0)
	/usr/local/go/src/runtime/mheap.go:920 +0x42
runtime.(*mheap).allocSpanLocked(0x22c0640, 0x20fa, 0x22e1748, 0x0)
	/usr/local/go/src/runtime/mheap.go:848 +0x337
runtime.(*mheap).alloc_m(0x22c0640, 0x20fa, 0x101, 0x1871dd8)
	/usr/local/go/src/runtime/mheap.go:692 +0x119
runtime.(*mheap).alloc.func1()
	/usr/local/go/src/runtime/mheap.go:759 +0x4c
runtime.(*mheap).alloc(0x22c0640, 0x20fa, 0x7fb692010101, 0x43694f)
	/usr/local/go/src/runtime/mheap.go:758 +0x8a
runtime.largeAlloc(0x41f3ce6, 0xc000040101, 0xc03cec4180)
	/usr/local/go/src/runtime/malloc.go:1019 +0x97
runtime.mallocgc.func1()
	/usr/local/go/src/runtime/malloc.go:914 +0x46
runtime.systemstack(0xc000000f00)
	/usr/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
	/usr/local/go/src/runtime/proc.go:1229

goroutine 131304 [running]:
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:311 fp=0xc102bc8c90 sp=0xc102bc8c88 pc=0x459700
runtime.mallocgc(0x41f3ce6, 0x12f6c20, 0xc094429801, 0xa8)
	/usr/local/go/src/runtime/malloc.go:913 +0x896 fp=0xc102bc8d30 sp=0xc102bc8c90 pc=0x40e2e6
runtime.makeslice(0x12f6c20, 0x41f3ce6, 0x41f3ce6, 0x7fb6952da000, 0x0, 0xc102bc8dd8)
	/usr/local/go/src/runtime/slice.go:70 +0x77 fp=0xc102bc8d60 sp=0xc102bc8d30 pc=0x444277
github.com/dgraph-io/badger/table.(*Table).loadToRAM(0xc01fb1ee00, 0x41f3ce6, 0x7a6)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/table/table.go:351 +0x4a fp=0xc102bc8de8 sp=0xc102bc8d60 pc=0x9757fa
github.com/dgraph-io/badger/table.OpenTable(0xc012a122a8, 0x1, 0x0, 0x0, 0x0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/table/table.go:139 +0x374 fp=0xc102bc8eb0 sp=0xc102bc8de8 pc=0x9743e4
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x7a6, 0xc0001320e0, 0xc3f4f19080, 0xc114e604e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:461 +0x22f fp=0xc102bc8fc0 sp=0xc102bc8eb0 pc=0x99e9cf
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc102bc8fc8 sp=0xc102bc8fc0 pc=0x45b7e1
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 1 [running]:
	goroutine running on other thread; stack unavailable

goroutine 19 [syscall, 79 minutes]:
os/signal.signal_recv(0x0)
	/usr/local/go/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 20 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0x22b7240)
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:882 +0x8b
created by github.com/golang/glog.init.0
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:410 +0x203

goroutine 21 [chan receive, 79 minutes]:
github.com/dgraph-io/badger/y.(*WaterMark).process(0xc000274c98)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/y/watermark.go:125 +0x15b
created by github.com/dgraph-io/badger/y.(*WaterMark).Init
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/y/watermark.go:54 +0xc1

goroutine 214 [chan receive]:
github.com/dgraph-io/badger/y.(*WaterMark).process(0xc000274b18)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/y/watermark.go:125 +0x15b
created by github.com/dgraph-io/badger/y.(*WaterMark).Init
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/y/watermark.go:54 +0xc1

goroutine 128689 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x77c, 0xc0001320e0, 0xc2b7dcc000, 0xc251d95da0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128945 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x788, 0xc0001320e0, 0xc2b7dcc000, 0xc0784fd9e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 215 [select]:
github.com/dgraph-io/badger.(*DB).updateSize(0xc000170000, 0xc005632540)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:928 +0x125
created by github.com/dgraph-io/badger.Open
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:267 +0x7d7

goroutine 28 [select]:
github.com/dgraph-io/badger.(*levelsController).runWorker(0xc0001320e0, 0xc00024c040)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:248 +0x151
created by github.com/dgraph-io/badger.(*levelsController).startCompact
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:233 +0x82

goroutine 27 [chan receive]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables(0xc0001320e0, 0x2, 0x174ad20, 0xc000182d00, 0xc00564b680, 0xc00564b6e0, 0xc08c20de68, 0x1, 0x1, 0xc08c20de70, ...)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:472 +0x1103
github.com/dgraph-io/badger.(*levelsController).runCompactDef(0xc0001320e0, 0x2, 0x174ad20, 0xc000182d00, 0xc00564b680, 0xc00564b6e0, 0xc08c20de68, 0x1, 0x1, 0xc08c20de70, ...)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:638 +0xd3
github.com/dgraph-io/badger.(*levelsController).doCompact(0xc0001320e0, 0x2, 0x3ff00cadb9666666, 0x0, 0x0, 0x0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:705 +0x498
github.com/dgraph-io/badger.(*levelsController).runWorker(0xc0001320e0, 0xc00024c040)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:254 +0x1c9
created by github.com/dgraph-io/badger.(*levelsController).startCompact
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:233 +0x82

goroutine 29 [running]:
	goroutine running on other thread; stack unavailable
created by github.com/dgraph-io/badger.(*levelsController).startCompact
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:233 +0x82

goroutine 33 [chan receive, 79 minutes]:
github.com/dgraph-io/badger.(*valueLog).waitOnGC(0xc000170148, 0xc00024c4a0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/value.go:1186 +0x61
created by github.com/dgraph-io/badger.Open
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:328 +0xcde

goroutine 30 [chan receive, 1 minutes]:
github.com/dgraph-io/badger.(*DB).flushMemtable(0xc000170000, 0xc00024c140, 0x0, 0x0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:806 +0xd3
created by github.com/dgraph-io/badger.Open
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:280 +0xf3e

goroutine 32 [select]:
github.com/dgraph-io/badger.(*DB).doWrites(0xc000170000, 0xc00024c480)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:670 +0x404
created by github.com/dgraph-io/badger.Open
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/db.go:325 +0xc81

goroutine 130260 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x798, 0xc0001320e0, 0xc2b7dcc000, 0xc296d15020)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130056 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x78a, 0xc0001320e0, 0xc2b7dcc000, 0xc01c1aaf60)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131302 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x7a3, 0xc0001320e0, 0xc2b7dcc000, 0xc113d06060)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130249 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x790, 0xc0001320e0, 0xc2b7dcc000, 0xc020507aa0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 127571 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x775, 0xc0001320e0, 0xc2b7dcc000, 0xc296d14120)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131303 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x7a5, 0xc0001320e0, 0xc2b7dcc000, 0xc094429800)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130251 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x79c, 0xc0001320e0, 0xc2b7dcc000, 0xc02c45c5a0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128293 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x771, 0xc0001320e0, 0xc2b7dcc000, 0xc296d156e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130338 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x78d, 0xc0001320e0, 0xc2b7dcc000, 0xc05b4bc060)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 129072 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x77e, 0xc0001320e0, 0xc2b7dcc000, 0xc114e61740)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131176 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x7a0, 0xc0001320e0, 0xc2b7dcc000, 0xc1b16205a0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128151 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x773, 0xc0001320e0, 0xc2b7dcc000, 0xc118c22fc0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128624 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x780, 0xc0001320e0, 0xc2b7dcc000, 0xc010d74000)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131055 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x79a, 0xc0001320e0, 0xc2b7dcc000, 0xc118c22000)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131057 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x79e, 0xc0001320e0, 0xc2b7dcc000, 0xc010585320)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130259 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x792, 0xc0001320e0, 0xc2b7dcc000, 0xc113d076e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128222 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x76f, 0xc0001320e0, 0xc2b7dcc000, 0xc0c16bc2a0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128495 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x77a, 0xc0001320e0, 0xc2b7dcc000, 0xc113d07440)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 131238 [running]:
	goroutine running on other thread; stack unavailable
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 129196 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x785, 0xc0001320e0, 0xc2b7dcc000, 0xc06f42d0e0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 130596 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x795, 0xc0001320e0, 0xc2b7dcc000, 0xc251d95080)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128941 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x783, 0xc0001320e0, 0xc2b7dcc000, 0xc00cd0f8c0)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

goroutine 128493 [chan send]:
github.com/dgraph-io/badger.(*levelsController).compactBuildTables.func2(0x777, 0xc0001320e0, 0xc2b7dcc000, 0xc1b1621b60)
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:463 +0x353
created by github.com/dgraph-io/badger.(*levelsController).compactBuildTables
	/go/pkg/mod/github.com/dgraph-io/badger@v1.5.5/levels.go:447 +0xec3

Thanks a lot for testing it @eawer. This definitely looks like a memory issue in the new code path. I will investigate it.

After a few short tests, I think the OOM is related to how the quad indexing works in all KV backends. The dataset of this size leads to an extremely large index entries for supernodes. Modifying this kind of index entry requires loading it into the memory.
A quick workaround may be to take a physical size of the transaction into account when auto-committing during batch import. However, this will only delay an issue.
The mid-term fix is to allow disabling those list indexes and switch to a single value indexes. This may lead to a larger DB size, but will solve the issue completely. Query performance may also suffer to some degree.
The long-term solution is to allow both kinds of indexes. This will complicate the design, however, and must be tested carefully in comparison with the previous proposed solution.

@eawer I made a few changes to indexing in https://github.com/cayleygraph/cayley/pull/816. It should help with the OOM issue, but at the same time it will increase the size of the index on disk, so write performance may suffer. But it's hard to make any statements because the new indexing strategy should also improve quad lookup performance, which may remove the need for multiple reads during the import process.
I will continue looking into it and will run a few tests locally as well. But the help with the testing is highly appreciated.

Cayley version: v0.7.x-dev (88cbd1564ad0)
badger died after 20min and 14M quads (batch size 1k) with Error: db: failed to load data: Txn is too big to fit into one request
Bolt failed after 13.5h and 207M quads with error:
fatal error: runtime: out of memory

runtime stack:
runtime.throw(0x1534adf, 0x16)
	/usr/local/go/src/runtime/panic.go:608 +0x72
runtime.sysMap(0xc6c4000000, 0x4000000, 0x23407b8)
	/usr/local/go/src/runtime/mem_linux.go:156 +0xc7
runtime.(*mheap).sysAlloc(0x231f6c0, 0x4000000, 0x231f8c8, 0x7fcff738c4d8)
	/usr/local/go/src/runtime/malloc.go:619 +0x1c7
runtime.(*mheap).grow(0x231f6c0, 0x30, 0x0)
	/usr/local/go/src/runtime/mheap.go:920 +0x42
runtime.(*mheap).allocSpanLocked(0x231f6c0, 0x30, 0x23407c8, 0x9800)
	/usr/local/go/src/runtime/mheap.go:848 +0x337
runtime.(*mheap).alloc_m(0x231f6c0, 0x30, 0x101, 0x7fcfeaf6ffff)
	/usr/local/go/src/runtime/mheap.go:692 +0x119
runtime.(*mheap).alloc.func1()
	/usr/local/go/src/runtime/mheap.go:759 +0x4c
runtime.(*mheap).alloc(0x231f6c0, 0x30, 0x7fcfea000101, 0x7fd0284c9130)
	/usr/local/go/src/runtime/mheap.go:758 +0x8a
runtime.largeAlloc(0x60000, 0x450100, 0x7fd0284c9130)
	/usr/local/go/src/runtime/malloc.go:1019 +0x97
runtime.mallocgc.func1()
	/usr/local/go/src/runtime/malloc.go:914 +0x46
runtime.systemstack(0xc000001380)
	/usr/local/go/src/runtime/asm_amd64.s:351 +0x66
runtime.mstart()
	/usr/local/go/src/runtime/proc.go:1229

goroutine 1 [running]:
runtime.systemstack_switch()
	/usr/local/go/src/runtime/asm_amd64.s:311 fp=0xc0000c91f8 sp=0xc0000c91f0 pc=0x459700
runtime.mallocgc(0x60000, 0x0, 0x3c000, 0xc6c3f74000)
	/usr/local/go/src/runtime/malloc.go:913 +0x896 fp=0xc0000c9298 sp=0xc0000c91f8 pc=0x40e2e6
runtime.growslice(0x1318ee0, 0xc6c3f74000, 0x9800, 0x9800, 0x9801, 0xc6c3f74000, 0x7800, 0x9800)
	/usr/local/go/src/runtime/slice.go:197 +0x219 fp=0xc0000c9300 sp=0xc0000c9298 pc=0x444519
github.com/cayleygraph/cayley/graph/kv.decodeIndex(0x7fcb35042040, 0x43f1f8, 0x43f1f8, 0xc1b8a96f30, 0x2, 0x2, 0xc1b8a96e70, 0x2)
	/cayley/graph/kv/indexing.go:753 +0x131 fp=0xc0000c9378 sp=0xc0000c9300 pc=0xaece71
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).getBucketIndexes(0xc000273900, 0x176f900, 0xc000038048, 0x1777160, 0xc3c1e8e008, 0xc1b8a96c30, 0x2, 0x2, 0x410029, 0x132a520, ...)
	/cayley/graph/kv/indexing.go:720 +0x176 fp=0xc0000c9418 sp=0xc0000c9378 pc=0xaecab6
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).hasPrimitive(0xc000273900, 0x176f900, 0xc000038048, 0x1777160, 0xc3c1e8e008, 0xc0000c9880, 0x968c42f20953f800, 0x837bace2, 0x0, 0x0)
	/cayley/graph/kv/indexing.go:860 +0x216 fp=0xc0000c94e8 sp=0xc0000c9418 pc=0xaedd36
github.com/cayleygraph/cayley/graph/kv.(*QuadStore).applyAddDeltas(0xc000273900, 0x1777160, 0xc3c1e8e008, 0x0, 0x0, 0x0, 0xc1c0dc01e0, 0x2330001, 0x1765240, 0xc4aa122a80, ...)
	/cayley/graph/kv/indexing.go:507 +0x94c fp=0xc0000c98e8 sp=0xc0000c94e8 pc=0xaea8ac
github.com/cayleygraph/cayley/graph/kv.(*quadWriter).WriteQuads(0xc0002753e0, 0xc004d26000, 0x186a0, 0x186a0, 0xc00000c0c0, 0xc004d26000, 0x186a0)
	/cayley/graph/kv/indexing.go:439 +0xa1 fp=0xc0000c9960 sp=0xc0000c98e8 pc=0xae9b11
github.com/cayleygraph/cayley/internal.(*batchLogger).WriteQuads(0xc00000c0e0, 0xc004d26000, 0x186a0, 0x186a0, 0x186a0, 0x0, 0x0)
	/cayley/internal/load.go:146 +0x59 fp=0xc0000c99c8 sp=0xc0000c9960 pc=0x75fe09
github.com/cayleygraph/cayley/quad.CopyBatch(0x175caa0, 0xc00000c0e0, 0x7fd080409068, 0xc00000c0c0, 0x186a0, 0xc00000c0c0, 0x0, 0x0)
	/cayley/quad/rw.go:145 +0x1dc fp=0xc0000c9a70 sp=0xc0000c99c8 pc=0x746d1c
github.com/cayleygraph/cayley/internal.DecompressAndLoad(0x1766f40, 0xc0002753e0, 0x186a0, 0x7ffff4cc0f78, 0x14, 0x0, 0x0, 0x0, 0x0)
	/cayley/internal/load.go:133 +0x17c fp=0xc0000c9ae8 sp=0xc0000c9a70 pc=0x75fc7c
github.com/cayleygraph/cayley/internal.Load(0x1766f40, 0xc0002753e0, 0x186a0, 0x7ffff4cc0f78, 0x14, 0x0, 0x0, 0x15266d9, 0xa)
	/cayley/internal/load.go:21 +0x71 fp=0xc0000c9b40 sp=0xc0000c9ae8 pc=0x75ec31
github.com/cayleygraph/cayley/cmd/cayley/command.openForQueries(0xc000270c80, 0x0, 0x0, 0x0)
	/cayley/cmd/cayley/command/database.go:259 +0x2bb fp=0xc0000c9c48 sp=0xc0000c9b40 pc=0x8e908b
github.com/cayleygraph/cayley/cmd/cayley/command.NewHttpCmd.func1(0xc000270c80, 0xc0000eefd0, 0x0, 0xb, 0x0, 0x0)
	/cayley/cmd/cayley/command/http.go:24 +0x9f fp=0xc0000c9ce8 sp=0xc0000c9c48 pc=0x8ee9af
github.com/spf13/cobra.(*Command).execute(0xc000270c80, 0xc0000eef20, 0xb, 0xb, 0xc000270c80, 0xc0000eef20)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:826 +0x473 fp=0xc0000c9dd8 sp=0xc0000c9ce8 pc=0x5c0fa3
github.com/spf13/cobra.(*Command).ExecuteC(0x2183b40, 0x2183dc0, 0xc000231b80, 0xc000187f88)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:914 +0x2f8 fp=0xc0000c9f20 sp=0xc0000c9dd8 pc=0x5c1998
github.com/spf13/cobra.(*Command).Execute(0x2183b40, 0xc000270a00, 0xc000270c80)
	/go/pkg/mod/github.com/spf13/cobra@v0.0.5/command.go:864 +0x2b fp=0xc0000c9f50 sp=0xc0000c9f20 pc=0x5c167b
main.main()
	/cayley/cmd/cayley/cayley.go:187 +0x31 fp=0xc0000c9f98 sp=0xc0000c9f50 pc=0x10e9381
runtime.main()
	/usr/local/go/src/runtime/proc.go:201 +0x207 fp=0xc0000c9fe0 sp=0xc0000c9f98 pc=0x42f197
runtime.goexit()
	/usr/local/go/src/runtime/asm_amd64.s:1333 +0x1 fp=0xc0000c9fe8 sp=0xc0000c9fe0 pc=0x45b7e1

goroutine 5 [syscall, 834 minutes]:
os/signal.signal_recv(0x0)
	/usr/local/go/src/runtime/sigqueue.go:139 +0x9c
os/signal.loop()
	/usr/local/go/src/os/signal/signal_unix.go:23 +0x22
created by os/signal.init.0
	/usr/local/go/src/os/signal/signal_unix.go:29 +0x41

goroutine 6 [chan receive]:
github.com/golang/glog.(*loggingT).flushDaemon(0x23162c0)
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:882 +0x8b
created by github.com/golang/glog.init.0
	/go/pkg/mod/github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b/glog.go:410 +0x203

Thanks for taking the time to test the new version!

badger died after 20min and 14M quads (batch size 1k) with Error: db: failed to load data: Txn is too big to fit into one request

I think we may give up for now on Badger. I'll need to change the way how we import data into it to avoid those large transaction.

Bolt failed after 13.5h and 207M quads

We are getting somewhere. But it seems like the SP index may also build up over time. I wonder what in the Freebase schema may cause it? I guess we will find out after a successful import :)
In any case, I will get back to you after making a few more changes.
First, I want to add instrumentation, so me can get more insights from the import process. I will add a "time per batch" metric, so we can get the same graph as you've built from Prometheus/Grafana directly. Also, I'm particularly interested in seeing the sizes of those index entries on each index. Also, things like lookup durations may be useful to speed up the import further.
And second, I will add an option to set custom indexes for KV, so we can try "SPO" index instead of "SP". Since the import was able to proceed further than before, I think the "O" index was indeed the case for previous OOM.

@eawer The patch with metrics and improved write performance was pushed upstream. It now optimizes the first batch write (e.g. cayley load) to minimize reads from the disk.
However, as I mentioned before, this improves performance only to some extent. I'm now working on a two-stage import tool that should improve write speed significantly. It will first use Badger to build a node index, and then export it to the target backend (e.g. Bolt).
From the first prototype, metrics show that the import process speed is constant and doesn't degrade over time, thanks to Badger's write optimizations. Building nodes index for the whole dataset takes < 10h. I will post precise test results later.

Just happened upon this issue. Have you guys considered using WriteBatch for Badger? It can deal with txn sizes and automatically commit them as needed.

@manishrjain Thanks for a suggestion, we will definitely consider that API :)
The problem is not with Badger specifically, as I mentioned. It's a problem with Cayley's legacy write API which tries to be suitable both for batch uploads and regular transactions. The new importer can take advantage of a WriteBatch in Badger directly and it work really well so far!

For info on my system

the orginial data "30kmovie-SampleData.nq" is 26,8 Mo
-When imported  indexes.bolt is 154Mo

5 X the size of the original data seems a little big.

@hubyhuby Note that Bolt pre-allocates some space, so not all of it is actually used by the database.

Just a follow up, but does now work to import freebase on Cayley?

authors: dennwc eawer hubyhuby manishrjain mazzespazze

repo: cayleygraph/cayley


text:
chore: bdd-gh-1576802597 to 0.0.1

chore: Promote bdd-gh-1576802597 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


text:
Blank slate

Thanks for all your work in this project.
For an app which normally loads using a storyboard, is it possible to use your patterns here to test ONLY one view controller at a time? i.e. the app starts completely black and then the test suite presents the target view controller onto the screen?
Currently the test suite loads the main storyboard and then other stuff is pushed on top, which is not the level of isolation I want.

Hey @fulldecent, in general, the approach presented here in most of the samples with ViewControllers - is that there is one TestCase class for each ViewController class.
To test a View Controller, I do the following:
Step 1. Use @testable.  For example:
https://gist.github.com/ccabanero/b92197516342c0147688#file-unit-testing-samle-uibutton-swift-L3
Step 2: Create a property for your target view controller.  For example:
https://gist.github.com/ccabanero/b92197516342c0147688#file-unit-testing-samle-uibutton-swift-L7
Step 3: Fetch your view controller from a storyboard:
https://gist.github.com/ccabanero/b92197516342c0147688#file-unit-testing-samle-uibutton-swift-L7

This is excellent. I see you have
self.viewControllerUnderTest.loadView()
self.viewControllerUnderTest.viewDidLoad()

You are not actually presenting the VC and are not using make key and visible. Are there any special considerations needed when doing it this way?

authors: ccabanero fulldecent

repo: ccabanero/ios-unit-testing-patterns


text:
配置了回调地址，但没有收到请求

Question and Steps to reproduce

在通知设置界面，配置了回调地址，但是当触发了告警规则的时候，回调地址并没有接收到请求，是什么原因？
Relevant logs and configurations
无相关错误日志

Version
前端版本：v7.0.0
后端版本：v7.0.0-17dbb3ec778f84aa8687ac4fda91b7370ba32c7c

是否还有其他原因不知道，仅从这个图上来看，这个回调没启用

可以了，就是那个开启按钮没有打开

repo: ccfos/nightingale


text:
The redirect_uri URL is not supported!

'I'm testing the login from the desktop, and it's giving this error!
The popup link that opens is this:
https://www.facebook.com/dialog/oauth?client_id=XXXXXXXXXX&redirect_uri=file:///C:/Users/SERVIDOR/Desktop/sample/www/oauthcallback.html&response_type=token&display=popup&scope=email
If it is by localhost:8000 (Phonegap Test), it works normally!
oauthcallback.html:
<script>     window.opener.openFB.oauthCallback(window.location.href);     window.close(); </script>
openfb.js: http://pastebin.com/KsJzNFnN
Where is the error?
Thanks!

I`m using JSConsole.com for tests! Return:
Connection established with file:///android_asset/www/login.html Mozilla/5.0 (Linux; U; Android 4.1.2; pt-br; ST27i Build/6.2.A.1.100) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Ok, but when I click the login button, it gives the following error:

Someone to help me?

I'm having this issue too.

Apparently file:// URL is not valid...

I wonder to know why you guys are trying to use a local url like
file:///C:/Users/SERVIDOR/Desktop/sample/www/oauthcallback.html&response_type=token&display=popup&scope=email
Of course this is not a valid url, the limitation is because Facebook.

authors: guilhermelirio josvaler lf94

repo: ccoenraets/OpenFB


text:
BCC (Bitcoin Cash) symbol in Binance exchange should be BCH

In fact, most Chinese exchanges use BCC for Bitcoin Cash. It's better if we correct this in CCXT to make it less confusing.

Hi, thx for opening this issue! I will correct that right away, very soon.
References:
https://github.com/ccxt-dev/ccxt/wiki/Manual#naming-consistency
https://github.com/ccxt-dev/ccxt/issues/83
https://github.com/ccxt-dev/ccxt/issues/129

This issue has been fixed in 1.9.267+. Thx again for your feedback!

issue came back

@eniuz can you elaborate, please?

I think he means that when you search on the Binance exchange, "BCH" shows no results but "BCC" shows a result representing bitcoin cash.

@abagh0703 in that case it's explained here: https://github.com/ccxt/ccxt/wiki/Manual#symbols-and-market-ids

Can this be fixed? All large exchanges use the BCH symbol instead of BCC.

@cookiemonster846 this has been fixed long ago... Just use the most recent version of CCXT and make sure to read this carefully: https://github.com/ccxt/ccxt/wiki/Manual#symbols-and-market-ids

No, it has not been fixed. The Binance official Android app doesn't recognize BCH, but only shows BCC in every trading related view and tab.

@kroitor The topic of this issue is 'bitcoin cash' symbol in Binance exchange should be BCH".. thus I commented that in Binance exhange viewed either via their website or official Android app that coin's symbol is BCC everywhere, and not BCH as it should.
Thus, it has not been fixed (in Binance).

Thus, it has not been fixed (in Binance).

Yes, in Binance it has not been fixed, but if you look into other exchanges as well, they have all sorts of inconsistencies with symbols, as described by those links above. And we have fixtures and remapping for those cases to bring them to consistency within CCXT. So we don't see it as an issue with the CCXT lib. Therefore, if some exchange shows a weird symbol in some of their software products – it's beyond our library, I'm afraid, and in that case we can't help, unfortunately, as we're not responsible for those exchanges' products. Hope this clarifies my previous answer.

The conflict of BCC vs BCH has been fixed in CCXT implementation of Binance here: https://github.com/ccxt/ccxt/blob/master/js/binance.js#L260.
So, "this issue opened in CCXT has been fixed" === "it is fixed in CCXT". As for their website or mobile apps not showing symbols properly – the question about BCC should be forwarded to Binance, rather than CCXT.

Sorry for late answer. I'm a developer I got lost in my editor for a while. it's obviously not an issue for someone who has time to think for a moment. is a bad UX for anybody who doesn't live in China if that matters to anybody. We're forced to live in global world with global economy. I don't remember why have I posted this here. So sorry if this is wrong place. In the same time I can see that many people know about the issue :) All the Best!

authors: abagh0703 cookiemonster846 eniuz guopengliang jjaone kroitor

repo: ccxt-dev/ccxt


text:
部分RSS，转换书籍成功，亚马逊推送失败

作者您好，该RSS源：https://www.archdaily.com/feeds/rss
电子书可能正常生成，下载到本地也能阅读，但自动推送不能成功。单独或是合并成册均如此。
使用Sigil检查，提示：This EPUB has HTML files that are not well formed or are missing a DOCTYPE, html, head or body elements. Sigil can automatically fix these files, although this may very rarely result in minor data loss in extreme circumstances.
使用kindlegen转换生成的epub，提示如下：
*************************************************************
 Amazon kindlegen(MAC OSX) V2.9 build 0000-kdevbld
 命令行电子书制作软件
 Copyright Amazon.com and its Affiliates 2015
*************************************************************

信息(prcgen):I1047: 已添加的元数据dc:Title        "ArchDaily"
信息(prcgen):I1047: 已添加的元数据dc:Date         "2024-06-02T03:18:08.800961+00:00"
信息(prcgen):I1047: 已添加的元数据dc:Creator      "KindleEar"
信息(prcgen):I1047: 已添加的元数据dc:Publisher    "KindleEar"
信息(prcgen):I1047: 已添加的元数据dc:Contributor  "calibre (7.2.0) [https://calibre-ebook.com]"
信息(prcgen):I1047: 已添加的元数据dc:Description  "Articles in this issue:
Life Ladprao Valley Residential Building / Openbox Architects
The oblique Sunshine / Man Office
Sendero Hotel / LOOP Design Studio
Pizzeria 22k / destilat
RizA ii House / React Architects
Houses in Peru: 5 Projects That Use Cement Blocks in Their Constructio
信息(prcgen):I1002: 解析文件  0000020
信息(cssparser):I10004: 不支持@规则，但 @import、@charset 和 @font-face 除外
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_0/index_u4.html     行： 0000009
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_0/index_u4.html     行： 0000019
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_1/index_u11.html     行： 0000009
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_1/index_u11.html     行： 0000019
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_2/index_u1.html     行： 0000009
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_2/index_u1.html     行： 0000115
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_3/index_u12.html     行： 0000009
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_3/index_u12.html     行： 0000093
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html     行： 0000009
警告(inputpreprocessor):W29007: 不使用的未知标签为： <picture>
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html     行： 0000019
警告(inputpreprocessor):W29007: 不使用的未知标签为： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_10/index_u9.html
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html     行： 0000019
警告(inputpreprocessor):W29007: 不使用的未知标签为： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/page_styles.css
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html     行： 0000019
警告(inputpreprocessor):W29007: 不使用的未知标签为： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/stylesheet.css
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html     行： 0000019
警告(inputpreprocessor):W29007: 不使用的未知标签为： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_8/index.html
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html     行： 0000019
警告(inputpreprocessor):W29007: 不使用的未知标签为： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_6/index_u3.html
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html     行： 0000019
警告(inputpreprocessor):W29007: 不使用的未知标签为： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html
      文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_4/index_u10.html     行： 0000019
错误(prcgen):E21018: 解析文件中的内容时，创建改进的 Mobi 域名失败。内容：<data-AmznRemoved> 文件中： /var/folders/v8/2l04mcqn7lb0p7szq7czzq6c0000gn/T/mobi-x4k7V5/feed_0/article_0/index_u4.html 行： 4294967295

不知是否是压缩图片后导致的异常，烦请您帮忙查看，是否在calibrek中设置什么参数能够解决？
谢谢～

如果是这个错误的话，
此页面使用的picture 是html5新标签，可能kindle 不支持，待升级kindleear 将其转换为img

谢谢，期待升级

推送错误的原因是kindle不支持svg内嵌的title标签。
不过我发现svg在kindle上真的很烦人，因为网站上的svg大多数是图标，在kindle上会自动放大，占满一屏，特别丑的同时对阅读也是没有价值的。
所以除了修改这个bug，我干脆默认将svg去掉了。
如果有某些rss需要svg图像，可以在网页的calibre选项中填写 {"keep_svg":true}
代码已更新，如果是GAE部署，可以直接部署即可使用新代码。
如果是Docker，可以等我之后更新Docker镜像，因为昨天才更新了一个大版本，支持在Kindle上在线阅读而不用推送到Kindle。

这个bug更改后south china morning post可以接收到了，不过还是有问题，标题前面会有一些无关的信息，看起来有点乱。另一个问题是有些print edition的recipe文章标题抓不到，标题不在正文中显示，只能在功能框下面显示，在此次更新前是没有这种问题的

是的，我修改了title的正则表达式，因为之前有些标题提取不出来
你出问题的是哪个源，我看一下

这几个我都测试了，没有明显问题，你说的有的标题有问题，我没有找到，可以给出有问题的文章和文章的url吗？
至于文章不全的问题，KindleEar算是一个通用爬虫项目，面对着复杂的网络条件，具有非常大的挑战。

如果是recipe格式，可以修改提取内容规则而提取完整内容
如果是自定义RSS模式，因为是使用readabilit/justext尝试提取文章正文，各种文章结构不一，如果高效准确的提取文章正文是世界性难题，各种库琳琅满目，没有一个库能适合所有的情况，要不提取了不必要的内容，要不漏掉部分内容，我基于平衡复杂性和有效性的考虑选择了这两个库，所以如果有的不能很好的提取，还是需要写一个recipe，分析html结构进行有针对性的提取，我写的哪个浏览器扩展可以协助减小一些工作量。
没有推送内容可能有两种情况，一种是源已失效，另一种是网站防爬虫，还有就是提取正文失败（要不就是完全的动态网页，全部使用js生成，要不就是文章结构太过复杂导致算法无所适从）。  具体来说南方周末的问题是一个依赖库feedparser的bug，我先暂时规避。

总的来说，只能碰到一个问题解决一个问题，估计一行一旦AI成熟和足够便宜，使用AI提取正文应该是一个趋势。
现在的AI要不太贵，要不上下文长度不够，所以很多事情还需要等等。

今天的华盛顿邮报所有front page的文章，目录中的标题都在工具栏下边显示，文章正文的标题更类似于小标题。the hindu的第一篇文章，也是同样的，只不过正文标题只写了today's paper news,breaking news,top headlines-the hindu businessline，这就显然不是小标题了。
其实我觉得不改也没什么的，并不影响阅读，既然已经知道标题了，也没必要纠结在哪个位置

你能给我rss地址和截图吗，我测试发现没你所说的问题，不管在电脑上看还是在kindle上看，我怀疑我们所说的不是同一个rss。
https://feedx.net/rss/washingtonpost.xml

谢谢，问题已解决，辛苦您了！

咱们说的确实不是一个，feedx的源没有任何问题。我说的是recipe里面的源。

能看出区别吧，目录里面的标题和功能框下面的标题是一致的，但是和正文中的标题是不一致的。截图为，the hindu的目录第一篇文章，washington post的目录第二篇文章

你查看recipe的源代码就可以知道了，这个排版是recipe代码中故意这样写的（体现这个recipe作者的某种意图吧），你完全可以将这个源码下载下来，改成你需要的排版，然后再上传就好。
如果recipe有问题，反馈给我没什么用，建议给calibre提一个pull request，calibre的recipe好像也不是其作者亲自维护的，都是其他人发现问题而pull request到github的。

好的，多谢解答

authors: Spaiol cdhigh zangjingwei

repo: cdhigh/KindleEar


text:
Added NoToggle param to Mute cmdlet

Hi there - please forgive the intrusion, I've never contributed a pull request to any project before so I'm not sure if I'm out of order by sending this unsolicited. However I wanted to offer my thanks for this project which I've found extremely useful. There's one use case where I wanted the Set-DefaultAudioDeviceMute command to always mute the sound, not toggle it on and off, so I've added this -NoToggle switch parameter which does the trick for me. This is in the attached pull request: if you're happy to accept it I don't mind also contributing a change to the help document. Cheers! Daniel

I think there is a more PowerShell-y way to accomplish this using an optional parameter.
Set-DefaultAudioDeviceMute -Mute $true or Set-DefaultAudioDeviceMute -Mute $false wound force it to that state, but omitting the switch would just toggle.

Closing this in favor of #14. Thank you.

authors: FearNotDaniel cdhunt


text:
errors

Arduino: 1.6.5 (Windows 8.1), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"
Build options changed, rebuilding all
C:\Users\OneDrive\Pictures\arduino-1.6.5-r5\libraries\DFRobot_EnvironmentalSensor\src\Wire.cpp: In member function 'uint8_t TwoWire::requestFrom(uint8_t, uint8_t, uint8_t)':
C:\Users\OneDrive\Pictures\arduino-1.6.5-r5\libraries\DFRobot_EnvironmentalSensor\src\Wire.cpp:85:68: error: too many arguments to function 'uint8_t twi_readFrom(uint8_t, uint8_t*, uint8_t)'
uint8_t read = twi_readFrom(address, rxBuffer, quantity, sendStop);
^
In file included from C:\Users\amr42\OneDrive\Pictures\arduino-1.6.5-r5\libraries\DFRobot_EnvironmentalSensor\src\Wire.cpp:26:0:
C:\Users\OneDrive\Pictures\arduino-1.6.5-r5\libraries\DFRobot_EnvironmentalSensor\src\twi.h:43:11: note: declared here
uint8_t twi_readFrom(uint8_t, uint8_t*, uint8_t);
^
C:\Users\OneDrive\Pictures\arduino-1.6.5-r5\libraries\DFRobot_EnvironmentalSensor\src\Wire.cpp: In member function 'uint8_t TwoWire::endTransmission(uint8_t)':
C:\Users\OneDrive\Pictures\arduino-1.6.5-r5\libraries\DFRobot_EnvironmentalSensor\src\Wire.cpp:140:76: error: too many arguments to function 'uint8_t twi_writeTo(uint8_t, uint8_t*, uint8_t, uint8_t)'
int8_t ret = twi_writeTo(txAddress, txBuffer, txBufferLength, 1, sendStop);
^
In file included from C:\Users\amr42\OneDrive\Pictures\arduino-1.6.5-r5\libraries\DFRobot_EnvironmentalSensor\src\Wire.cpp:26:0:
C:\Users\OneDrive\Pictures\arduino-1.6.5-r5\libraries\DFRobot_EnvironmentalSensor\src\twi.h:44:11: note: declared here
uint8_t twi_writeTo(uint8_t, uint8_t*, uint8_t, uint8_t);
^
Error compiling.
This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.

Is it a version problem?


text:
feat(deps): upgrade runtime dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-runtime-dependencies-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1711

Questions ?
Please refer to the Backport tool documentation


text:
chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1244

Questions ?
Please refer to the Backport tool documentation


text:
chore(deps): upgrade compiler dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-compiler-dependencies-1.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 2667

Questions ?
Please refer to the Backport tool documentation


text:
chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-k8s-25-main" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1458

Questions ?
Please refer to the Backport tool documentation


text:
Add missing extension

Hello! Could you add this extension to the marketplace
https://github.com/coderoad/coderoad-vscode
Cheers!

Done!

authors: AdamZaczek kylecarbs

repo: cdr/code-server


text:
Blank form responses show up as "No Response" (EN) after filling out a FR form

Description
Blank form responses show up as "No Response" (EN) in email delivery, after filling out a FR form
Flagged from client: Support Ticket 16930
Steps to reproduce

Go to any Form (with responses set to email delivery)
Toggle to the French interface
Leave some blank questions and submit the form
See error in the email: it shows as "No Response"

Expected behaviour
Blank answers should show in French if filling out the French form?
Screenshots or videos

This is no longer an issue, blank answers have been replaced by a -.

A potential solution: use a dash - instead of a string of words so that it work in EN and FR if translation isn't possible?

authors: Abi-Nada anikbrazeau

repo: cds-snc/platform-forms-client