DOC: Examples of monotonic/non-monotonic label-based indexing

Just ran into this gotcha and almost filed it as a bug report. Added a few examples to fill in the section header.

@nileracecrew Thanks for this nice contribution to the docs! (that title was indeed missing an explanation ;-))
It is certainly good to keep it here, but we maybe should also consider to include a similar explanation in the indexing docs itself.

You're welcoem @jorisvandenbossche. Seems like this behavior is most likely to show up when you have other problems (in my case corrupted data, as well as an in another issue I found), but it is surprising.
I made the suggested edits and re-committed.

instead a empty frame use a range for number (range(6))

Sorry, I don't quite understand your meaning. Do you mean fill the example DataFrame with numbers, or use range(6) as an index instead of the empty DataFrame example, or something else?

fill with numbers

@nileracecrew : If I'm not mistaken (unless the tests do check these files), since your fixes are purely documentation related, you should put [ci skip] in your commit message because you aren't changing any code.  Every time you make a change to your PR, you are adding another build to Travis (you currently have five).  Unless these .rst files are checked, I would suggest if someone could cancel all of your builds and you could put that "ci skip" tag in your commit.

pls squash when you update

Is there a quick way to render a single .rst file to see the output? GitHub doesn't render the ipython blocks.

http://pandas-docs.github.io/pandas-docs-travis/contributing.html#how-to-build-the-pandas-documentation

sorry, didn't mean to push that here

thanks!


SPINEPS : RuntimeError: CUDA error: out of memory

Following our discussion in issue #21:
After setting the TMPDIR shell variable to the directory where the data is stored, the "batch_processing.sh" script finally starts running and creates a tmp folder. Then, it exits with this error:
torch.cuda.OutOfMemoryError: """CUDA out of memory. Tried to allocate 128.00 MiB. GPU 0 has a total capacity
of 1.95 GiB of which 1.19 MiB is free. Process 7900 has 27.12 MiB memory in use. Including non-PyTorch
memory, this process has 1.28 GiB memory in use. Of the allocated memory 1.10 GiB is allocated by PyTorch,
and 139.26 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try
setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for
Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)"""

After exporting these variables export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True PYTORCH_NO_CUDA_MEMORY_CACHING=1, I got this new error:
RuntimeError: """CUDA error: out of memory
CUDA kernel errors might be asynchronously reported at some other API call, so the stacktrace below might be incorrect.
For debugging consider passing CUDA_LAUNCH_BLOCKING=1.
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions."""

I exported again this variable export=CUDA_LAUNCH_BLOCKING=1, and I end up with this error:
RuntimeError: """CUDA error: out of memory
Compile with `TORCH_USE_CUDA_DSA` to enable device-side assertions."""

Any insights? Thanks for your help!

Note from @joshuacwnewton: I added ``` formatting just for readability!

The first thing I would suggest is use nvidia-smi to check information about the GPU prior to the call to spineps. Here is some sample output from my own GPU:
PS:C:\Users\Joshua $ nvidia-smi
Tue Apr 23 13:12:41 2024
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 546.01                 Driver Version: 546.01       CUDA Version: 12.3     |
|-----------------------------------------+----------------------+----------------------+
| GPU  Name                     TCC/WDDM  | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|   0  NVIDIA GeForce GTX 1050      WDDM  | 00000000:01:00.0 Off |                  N/A |
| N/A   42C    P8              N/A / ERR! |      0MiB /  4096MiB |      2%      Default |
|                                         |                      |                  N/A |
+-----------------------------------------+----------------------+----------------------+

+---------------------------------------------------------------------------------------+
| Processes:                                                                            |
|  GPU   GI   CI        PID   Type   Process name                            GPU Memory |
|        ID   ID                                                             Usage      |
|=======================================================================================|
|  No running processes found                                                           |
+---------------------------------------------------------------------------------------+

I would be curious to see what the output of this is immediately prior to the spineps call. Would it be possible to add this to batch_processing.sh, then share the error log file for whichever subject fails? :)
At the very least, this will hopefully help us to isolate the problem, since we should be able to tell if this is due to SPINEPS' memory requirements, or if this is due to other processes using the GPU memory.

You may also want to set the following options in the spineps command: -sd -v. I'm not sure what sort of debug information SPINEPS provides, but it's possibly worth a try.

Thanks @joshuacwnewton ; this is the information about the GPU
Screenshot

And the log fileof the test subject  where you can see the output before calling SPINEPS
err.batch_processing_sub-BB277.log
I'm trying again to install the SCT on Compute Canada; I'll let you know how it works

@NathanMolinier can SPINEPS run on CPU only?

I don't think it is implemented yet in the command line, but I talked about that to Hendrik and he mentioned that the code is checking if a GPU is available before running so it should not be "too difficult" to change that. I will ask if it's possible to allow the code to run on cpu only.

Thanks @joshuacwnewton ; this is the information about the GPU

Ah!! That at least partially explains things. You have quite a few memory-intensive processes running on your GPU. Normally, I would expect these processes to run on your CPU's integrated GPU?
I am wondering -- are you SSH'ing into a remotet machine and forwarding the display, by chance?
Either way, you may want to look into help posts such as: https://askubuntu.com/questions/1279809/prevent-usr-lib-xorg-xorg-from-using-gpu-memory-in-ubuntu-20-04-server. The end goal is probably something like what is shown in this answer: https://askubuntu.com/a/1313440. Given that your GPU is quite old (GTX 750 is from 2014) and that your GPU has limited memory (2GB), you will want to take steps to conserve as much as the memory as you can when running inference on GPU.

Yes, I'm running the analysis on the server of the institute
I wasn't on any other process while running the script... Not sure I can spare GPU memory...

Won't fix (see #26)


DTO - Player

Rename Player to PlayerDB
Create PlayerDTO (Data Transfer Object)
Use PlayerDTO in PlayerService (to hide Password)

Zatvoreno jer će ove izmjene biti dodane u RegisterREST branch i pull request


Add basic navigation bar

We have a rough draft that should be added to the layout template. Current design:

@Abbe98 Should this wait until we have something to show on the country and subject pages or should I add it with only the first two links?

I would suggest adding it with only two links, it might be useful for user testing/retrieval tasks.


Client Allocation Request for: Maxius

Client Allocation Questions
Core Information

Name: Maxius
Website / Social Media: www.taejin.co.kr
Region: Asia excl. Greater China
DataCap Requested: 32TiB
Addresses to be Notarized: f12ojuuh62mdjadkox6ccgre5tw7coq2ydoc2vmwa
Notary Requested: MasaakiNawatani

@IsTandER Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Hello @IsTandER
Please respond to the questions below in paragraph form, replacing the text saying 'Please answer here'. Include as much detail as you can in your answer!
Please describe the nature of your organization, project, or use case. For organizations, please include your relationship with the organization the size of the organization, and time since inception. For projects and other use cases, please link to relevant web pages or Github. Please include as much relevant detail to provide contextual information (with external links). If you have any presentation document about your business, please provide it to me.
Please answer here.

Have you been approved for a DataCap previously? If so, can you share the details of the last allocation decision (who approved your DataCap, what your plan was for spending it, how you executed on that plan)?
Please answer here.

**Allocation Strategy
Do you intend to store your data in a single geography or many?
Please answer here.

Are you aware of and do you intend to use the features you may specify (e.g. Fast Retrieval) with your storage deals?
Please answer here.

How do you plan on securing the DataCap to ensure your organization (and its delegated members) are the ones allocating the DataCap?
Please answer here.

Do you plan on allocating a substantial portion of your DataCap to a single miner, or will you spread it across many miners?
Please answer here.

For application developers, will you be acting as the client on behalf of your users or you applying as a Notary on behalf of your users? If so, how much DataCap per user are you seeking to have approved?
Please answer here.

Do you agree to use the DataCap to only store data that abides by local regulations and in compliance with the recipient miner’s terms of service?
Please answer here.

**Track Record
Have you previously received DataCap to allocate before? If so, please link to any previous decisions that have been made.
Please answer here.

Are there any disputes open against you from your previous DataCap allocations?
Please answer here.

Closing this request due to no-response received after 15 days.


.*: spilt profile info from Interpreters::Join and implement PipelineExecutor::getRuntimeStatistics

What problem does this PR solve?
Issue Number: ref #6518
Problem Summary:
What is changed and how it works?

Let DAGContext no longer hold JoinPtr, so that JoinPtr can be destroyed after build/probe is executed, freeing memory from https://github.com/pingcap/tiflash/pull/7750

Check List
Tests

[ ] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Documentation

[ ] Affects user behaviors
[ ] Contains syntax changes
[ ] Contains variable changes
[ ] Contains experimental features
[ ] Changes MySQL compatibility

Release note

None

/run-all-tests

/run-unit-test

/approve

/run-unit-test


Initial commit for RxRust, porting existing code-base from https://github.com/12sidedtech/reactive-rs

Thanks! Let's get this going!


ESP32: Fix on-network commissioning issue on ESP32

Problem
#15952 On-network commissioning doesn't work because esp32 does not connect to the provided AP.
Change overview
Provison WiFi for on-network commissioning.
Testing
Tested on ESP32C3, on-network commissioning works well.

If we set ssid and pass through menuconfig ( Component config --> CHIP Device Layer --> WiFi Station Options ), device is connecting to AP.


Update sbt-typelevel, ... to 0.7.0

About this PR
📦 Updates

org.typelevel:sbt-typelevel
org.typelevel:sbt-typelevel-ci-release
org.typelevel:sbt-typelevel-github-actions

from 0.6.7 to 0.7.0
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.typelevel" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.typelevel" }
}]

labels: sbt-plugin-update, early-semver-major, semver-spec-minor, version-scheme:early-semver, commit-count:1

Superseded by #76.


April - Bug review, categorization, assignment

During April we want to get the bug count down. As a first step we will review the assigned issues. During the review pass please make sure to:

close obsolete/fixed issues
each issue needs a type label, that is one of: Bug, Feature-Request, Debt, Needs more Info, Question, Under-Discussion:

Bug - the implementation of a feature is not correct
Feature-Request - request to change the proper implementation of a feature or a request for a new feature that needs to be implemented.
Under Discussion - not decided whether the issue is a bug or feature
Debt - improve the implementation/architecture
Needs more info - not possible to assing a type label due to missing information
Question - we should direct questions to SO
Note: All type labels are white.

assign the important label to issues that

result in data loss
a breakage of extension
critical security, performance issues
UI issue that makes a feature unusable

each issue needs to be assigned to a feature area
Assign bugs that you plan to fix during April to the April milestone.

Tracking:

[ ] ...
[ ] ...

just a usability nit, I find labels without background a bit weird:

Hard to tell which issues don't have a label yet.

OKi, changed the background to SlateGrey


#17635 store functions SQL words in the original case

Please check different-case databases. Clickhouse - as mixed case, PostgreSQL as lower case, Oracle as upper case. Or other.
With Hippie Engine and without. With default case autocomplete and with upper/lower.

Let's keep originalo case for all keywords (not just functions) and all dialects (not just Clickhouse).
Turn TreeSet into TreeMap and hold original case in value.

Please move CH-related changes to https://github.com/dbeaver/dbeaver/pull/19706


move the cleanup function to lib

Other scripts might wan't to use that cleanup logic too so it makes sense to put it into lib.sh
the trap remains in build.sh though because we want scripts to be able to source lib.sh and execute to finish without cleaning up everything (pegin.sh for example)

build.sh

in latency-tests.sh we do this  source ./scripts/build.sh $FM_FED_SIZE source ./scripts/setup-tests.sh so build'd be called twice here which would be weired or we'd need to give setup-tests.sh args

@jkitman I just noticed it wouldnt hurt to just give setup-tests.sh optional args so good point


Update aws-sdk-go

The version which we currently have is vulnerable, according to Minder.
Summary
Provide a brief overview of the changes and the issue being addressed.
Explain the rationale and any background necessary for understanding the changes.
List dependencies required by this change, if any.
Fixes #(related issue)
Change Type
Mark the type of change your PR introduces:

[ ] Bug fix (resolves an issue without affecting existing features)
[ ] Feature (adds new functionality without breaking changes)
[ ] Breaking change (may impact existing functionalities or require documentation updates)
[ ] Documentation (updates or additions to documentation)
[ ] Refactoring or test improvements (no bug fixes or new functionality)

Testing
Outline how the changes were tested, including steps to reproduce and any relevant configurations.
Attach screenshots if helpful.
Review Checklist:

[ ] Reviewed my own code for quality and clarity.
[ ] Added comments to complex or tricky code sections.
[ ] Updated any affected documentation.
[ ] Included tests that validate the fix or feature.
[ ] Checked that related changes are merged.

coverage: 54.299%. remained the same
when pulling 5fe1bc19ccfb8a5abd35c23f9b42ca50db352edb on update-aws-sdk
into 0c7a14862f5b99dc3771a4d8c64b9a3e526dde49 on main.


make rpi and make clean-rpi rpi both fail

sudo apt-get update
pi@raspberrypi ~ $ sudo apt-get install cmake g++-4.7 libcurl4-openssl-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
cmake is already the newest version.
g++-4.7 is already the newest version.
libcurl4-openssl-dev is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 38 not upgraded.
pi@raspberrypi ~ $ cd ~
pi@raspberrypi ~ $ git clone https://github.com/tangrams/tangram-es.git
fatal: destination path 'tangram-es' already exists and is not an empty directory.
pi@raspberrypi ~ $ git pull
fatal: Not a git repository (or any of the parent directories): .git
pi@raspberrypi ~ $ cd tangram-es
pi@raspberrypi ~/tangram-es $ git pull
Already up-to-date.
pi@raspberrypi ~/tangram-es $ git clean -n
pi@raspberrypi ~/tangram-es $ git submodule update
pi@raspberrypi ~/tangram-es $ git submodule init && git submodule update
Submodule 'core/include/libtess2/libtess2' () registered for path 'core/dependencies/tess2/libtess2'
Submodule 'core/include/fontstash-es' () registered for path 'core/include/fontstash-es'
Submodule 'core/include/glm' () registered for path 'core/include/glm'
pi@raspberrypi ~/tangram-es $ make clean-rpi rpi
rm -rf build/rpi
-- The C compiler identification is GNU 4.7.2
-- The CXX compiler identification is GNU 4.7.2
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Platform chosen : RASPBERRYPI
-- Including raspberrypi dependent cmake file : /home/pi/tangram-es/toolchains/raspberrypi.cmake
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/tangram-es/build/rpi
make[1]: Entering directory '/home/pi/tangram-es/build/rpi'
make[2]: Entering directory '/home/pi/tangram-es/build/rpi'
make[3]: Entering directory '/home/pi/tangram-es/build/rpi'
Scanning dependencies of target libtess2
make[3]: Leaving directory '/home/pi/tangram-es/build/rpi'
make[3]: Entering directory '/home/pi/tangram-es/build/rpi'
[  2%] Building C object core/dependencies/tess2/CMakeFiles/libtess2.dir/libtess2/Source/geom.c.o
[  4%] Building C object core/dependencies/tess2/CMakeFiles/libtess2.dir/libtess2/Source/tess.c.o
[  6%] Building C object core/dependencies/tess2/CMakeFiles/libtess2.dir/libtess2/Source/priorityq.c.o
[  9%] Building C object core/dependencies/tess2/CMakeFiles/libtess2.dir/libtess2/Source/sweep.c.o
[ 11%] Building C object core/dependencies/tess2/CMakeFiles/libtess2.dir/libtess2/Source/dict.c.o
[ 13%] Building C object core/dependencies/tess2/CMakeFiles/libtess2.dir/libtess2/Source/bucketalloc.c.o
[ 15%] Building C object core/dependencies/tess2/CMakeFiles/libtess2.dir/libtess2/Source/mesh.c.o
Linking C static library ../../../lib/liblibtess2.a
make[3]: Leaving directory '/home/pi/tangram-es/build/rpi'
[ 15%] Built target libtess2
make[3]: Entering directory '/home/pi/tangram-es/build/rpi'
Scanning dependencies of target core
make[3]: Leaving directory '/home/pi/tangram-es/build/rpi'
make[3]: Entering directory '/home/pi/tangram-es/build/rpi'
[ 18%] Building CXX object core/CMakeFiles/core.dir/src/text/textBuffer.cpp.o
[ 20%] Building CXX object core/CMakeFiles/core.dir/src/text/fontContext.cpp.o
[ 22%] Building CXX object core/CMakeFiles/core.dir/src/util/mapProjection.cpp.o
[ 25%] Building CXX object core/CMakeFiles/core.dir/src/util/texture.cpp.o
[ 27%] Building CXX object core/CMakeFiles/core.dir/src/util/builders.cpp.o
[ 29%] Building CXX object core/CMakeFiles/core.dir/src/util/vertexLayout.cpp.o
[ 31%] Building CXX object core/CMakeFiles/core.dir/src/util/geoJson.cpp.o
[ 34%] Building CXX object core/CMakeFiles/core.dir/src/util/rectangle.cpp.o
[ 36%] Building CXX object core/CMakeFiles/core.dir/src/util/error.cpp.o
[ 38%] Building CXX object core/CMakeFiles/core.dir/src/util/shaderProgram.cpp.o
[ 40%] Building CXX object core/CMakeFiles/core.dir/src/util/geom.cpp.o
[ 43%] Building CXX object core/CMakeFiles/core.dir/src/util/vboMesh.cpp.o
[ 45%] Building CXX object core/CMakeFiles/core.dir/src/util/pbfParser.cpp.o
[ 47%] Building CXX object core/CMakeFiles/core.dir/src/data/dataSource.cpp.o
[ 50%] Building CXX object core/CMakeFiles/core.dir/src/data/geoJsonSource.cpp.o
[ 52%] Building CXX object core/CMakeFiles/core.dir/src/data/protobufSource.cpp.o
[ 54%] Building CXX object core/CMakeFiles/core.dir/src/tile/labels/label.cpp.o
[ 56%] Building CXX object core/CMakeFiles/core.dir/src/tile/labels/labelContainer.cpp.o
[ 59%] Building CXX object core/CMakeFiles/core.dir/src/tile/mapTile.cpp.o
[ 61%] Building CXX object core/CMakeFiles/core.dir/src/tile/tileManager.cpp.o
[ 63%] Building CXX object core/CMakeFiles/core.dir/src/tile/tileWorker.cpp.o
[ 65%] Building CXX object core/CMakeFiles/core.dir/src/style/polylineStyle.cpp.o
[ 68%] Building CXX object core/CMakeFiles/core.dir/src/style/style.cpp.o
[ 70%] Building CXX object core/CMakeFiles/core.dir/src/style/debugStyle.cpp.o
[ 72%] Building CXX object core/CMakeFiles/core.dir/src/style/polygonStyle.cpp.o
[ 75%] Building CXX object core/CMakeFiles/core.dir/src/style/debugTextStyle.cpp.o
[ 77%] Building CXX object core/CMakeFiles/core.dir/src/style/fontStyle.cpp.o
[ 79%] Building CXX object core/CMakeFiles/core.dir/src/view/view.cpp.o
/home/pi/tangram-es/core/src/view/view.cpp: In function âvoid scanLine(int, int, int, int, std::set&)â:
/home/pi/tangram-es/core/src/view/view.cpp:247:16: error: âclass std::setâ has no member named âemplaceâ
core/CMakeFiles/core.dir/build.make:675: recipe for target 'core/CMakeFiles/core.dir/src/view/view.cpp.o' failed
make[3]: *** [core/CMakeFiles/core.dir/src/view/view.cpp.o] Error 1
make[3]: Leaving directory '/home/pi/tangram-es/build/rpi'
CMakeFiles/Makefile2:112: recipe for target 'core/CMakeFiles/core.dir/all' failed
make[2]: *** [core/CMakeFiles/core.dir/all] Error 2
make[2]: Leaving directory '/home/pi/tangram-es/build/rpi'
Makefile:72: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/pi/tangram-es/build/rpi'
Makefile:160: recipe for target 'rpi' failed
make: *** [rpi] Error 2

I tried the same procedure above with g++ 4.8 and got a similar result

Thanks for reporting!
It seems to be working for me with g++ 4.8.2, can you please try the following steps:
make clean-rpi
export CXX=/usr/bin/g++-4.8            # or wherever you installed g++4.8
make rpi

the export statement made it go further to 97% bit it still crashed:
[ 97%] Building CXX object CMakeFiles/tangram.dir/rpi/src/main.cpp.o
/home/pi/tangram-es/rpi/src/main.cpp:49:2: warning: 'typedef' was ignored in this declaration [enabled by default]
};
^
/home/pi/tangram-es/rpi/src/main.cpp: In function 'void initOpenGL()':
/home/pi/tangram-es/rpi/src/main.cpp:179:124: warning: invalid conversion from 'int' to 'DISPMANX_TRANSFORM_T' [-fpermissive]
&src_rect, DISPMANX_PROTECTION_NONE, 0 /alpha/, 0/clamp/, 0/transform/);
^
In file included from /opt/vc/include/bcm_host.h:50:0,
from /home/pi/tangram-es/core/src/gl.h:30,
from /home/pi/tangram-es/rpi/src/main.cpp:14:
/opt/vc/include/interface/vmcs_host/vc_dispmanx.h:85:44: warning:   initializing argument 10 of 'DISPMANX_ELEMENT_HANDLE_T vc_dispmanx_element_add(DISPMANX_UPDATE_HANDLE_T, DISPMANX_DISPLAY_HANDLE_T, int32_t, const VC_RECT_T*, DISPMANX_RESOURCE_HANDLE_T, const VC_RECT_T*, DISPMANX_PROTECTION_T, VC_DISPMANX_ALPHA_T*, DISPMANX_CLAMP_T*, DISPMANX_TRANSFORM_T)' [-fpermissive]
VCHPRE_ DISPMANX_ELEMENT_HANDLE_T VCHPOST_ vc_dispmanx_element_add ( DISPMANX_UPDATE_HANDLE_T update, DISPMANX_DISPLAY_HANDLE_T display,
^
/home/pi/tangram-es/rpi/src/main.cpp:232:70: error: cannot allocate an object of abstract type 'VboMesh'
mouseMesh = std::shared_ptr(new VboMesh(vertexLayout));
^
In file included from /home/pi/tangram-es/rpi/src/main.cpp:18:0:
/home/pi/tangram-es/core/src/util/vboMesh.h:16:7: note:   because the following virtual functions are pure within 'VboMesh':
class VboMesh {
^
/home/pi/tangram-es/core/src/util/vboMesh.h:50:18: note:        virtual void VboMesh::compileVertexBuffer()
virtual void compileVertexBuffer() = 0;
^
/home/pi/tangram-es/rpi/src/main.cpp:233:20: error: 'class VboMesh' has no member named 'addVertices'
mouseMesh->addVertices((GLbyte*)vertices.data(), vertices.size());
^
/home/pi/tangram-es/rpi/src/main.cpp:234:20: error: 'class VboMesh' has no member named 'addIndices'
mouseMesh->addIndices(indices.data(), indices.size());
^
CMakeFiles/tangram.dir/build.make:54: recipe for target 'CMakeFiles/tangram.dir/rpi/src/main.cpp.o' failed
make[3]: *** [CMakeFiles/tangram.dir/rpi/src/main.cpp.o] Error 1
make[3]: Leaving directory '/home/pi/tangram-es/build/rpi'
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/tangram.dir/all' failed
make[2]: *** [CMakeFiles/tangram.dir/all] Error 2
make[2]: Leaving directory '/home/pi/tangram-es/build/rpi'
Makefile:72: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/pi/tangram-es/build/rpi'
Makefile:160: recipe for target 'rpi' failed
make: *** [rpi] Error 2

Just catched this one! Should be fixed by https://github.com/tangrams/tangram-es/pull/94.
If you want to give it a try now:
git pull
git checkout rpi-fix

And then compile again.

thanx, I'll give it a try and let you know

Nope, same problem

I tried again now theres a different problem at 100%
[100%] Building CXX object CMakeFiles/tangram.dir/rpi/src/platform_rpi.cpp.o
/home/pi/tangram-es/rpi/src/platform_rpi.cpp: In function 'bool isContinuousRendering()':
/home/pi/tangram-es/rpi/src/platform_rpi.cpp:26:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
Linking CXX executable bin/tangram
/usr/bin/ld: lib/libcore.a(tileWorker.cpp.o): undefined reference to symbol 'pthread_create@@GLIBC_2.4'
//lib/arm-linux-gnueabihf/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
CMakeFiles/tangram.dir/build.make:112: recipe for target 'bin/tangram' failed
make[3]: *** [bin/tangram] Error 1
make[3]: Leaving directory '/home/pi/tangram-es/build/rpi'
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/tangram.dir/all' failed
make[2]: *** [CMakeFiles/tangram.dir/all] Error 2
make[2]: Leaving directory '/home/pi/tangram-es/build/rpi'
Makefile:72: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/pi/tangram-es/build/rpi'
Makefile:160: recipe for target 'rpi' failed
make: *** [rpi] Error 2

Thanks, the linking with pthread library seems to be failing on your rasbperry pi. Can you also give the model of your raspberry pi?
If you can to give it another try, on branch rpi-fix:
git pull origin rpi-fix
make rpi

Its an RPI B
Ill try your new suggestion and let you know

It worked this time !
thanx

Nice! :)


Have you considered allowing SkLabel to support gradient colors?

@Leewx820 For Vcl or FMX? It is difficult to change the way the controls work now after this project has been integrated to the RAD Studio, since almost any changes above the implementation can only be made between major versions (due binary compatible). Furthermore, the use of gradients in texts is not so common.
However, if it is in FMX, there is another much more elegant and efficient way to implement this, which would be to create a TGradientEffect, which we would drop on the control whose color we want to replace with a gradient of our choice. This way, not only the TSkLabel would have the possibility of being painted with a gradient, but any other control such as TSkSVG or TCircle, TButton, etc...

@Leewx820 In case you are interested in this solution above, I have an implementation of a transparency gradient effect (similar to the normal gradient). Source:
unit CustomEffects.GradientAlpha;

interface

uses
  System.Classes, System.Types, FMX.Graphics, FMX.Filter, FMX.Effects;

type
  TGradientAlphaEffect = class(TEffect)
  private
    FAngle: Single;
    FOpaquePosition: Single;
    FSaveCount: Integer;
    FTargetCanvas: TCanvas;
    FTransparentPosition: Single;
    procedure SetAngle(AValue: Single);
    procedure SetOpaquePosition(AValue: Single);
    procedure SetTransparentPosition(AValue: Single);
  public
    constructor Create(AOwner: TComponent); override;
    function BeginLayer(const ATarget: TCanvas; const ADestRect: TRectF; const AOpacity: Single;
      const AHighSpeed: Boolean; var ACacheLayer: IFilterCacheLayer; out ACacheCanvas: TCanvas): Boolean; override;
    procedure EndLayer; override;
  published
    property Angle: Single read FAngle write SetAngle nodefault;
    property OpaquePosition: Single read FOpaquePosition write SetOpaquePosition nodefault;
    property TransparentPosition: Single read FTransparentPosition write SetTransparentPosition nodefault;
    property Trigger;
    property Enabled;
  end;

procedure Register;

implementation

uses
  System.UITypes, System.Math, System.Math.Vectors, System.Skia, FMX.Skia.Canvas;

{ TGradientAlphaEffect }

function TGradientAlphaEffect.BeginLayer(const ATarget: TCanvas; const ADestRect: TRectF; const AOpacity: Single;
  const AHighSpeed: Boolean; var ACacheLayer: IFilterCacheLayer; out ACacheCanvas: TCanvas): Boolean;
begin
  ACacheLayer := nil;
  ACacheCanvas := ATarget;
  Result := True;
  if not (ATarget is TSkCanvasCustom) then
    Exit;
  FTargetCanvas := ATarget;
  var LMatrix := TMatrix.CreateRotation(FAngle);
  var LShader := TSkShader.MakeGradientLinear(PointF(ADestRect.CenterPoint.X, 0) * LMatrix,
    PointF(ADestRect.CenterPoint.X, ADestRect.Height) * LMatrix, [TAlphaColors.Black, TAlphaColors.Null],
    [FOpaquePosition, FTransparentPosition]);
  var LSkiaCanvas := TSkCanvasCustom(ATarget).Canvas;
  var LPaint: ISkPaint := TSkPaint.Create;
  LPaint.ImageFilter := TSkImageFilter.MakeBlend(TSkBlendMode.SrcIn, TSkImageFilter.MakeShader(LShader, False));
  FSaveCount := LSkiaCanvas.SaveLayer(LPaint);
end;

constructor TGradientAlphaEffect.Create(AOwner: TComponent);
begin
  inherited;
  FEffectStyle := [TEffectStyle.DisablePaint];
  FOpaquePosition := 0.90;
  FTransparentPosition := 0.97;
end;

procedure TGradientAlphaEffect.EndLayer;
begin
  if FTargetCanvas <> nil then
  begin
    TSkCanvasCustom(FTargetCanvas).Canvas.RestoreToCount(FSaveCount);
    FTargetCanvas := nil;
  end;
end;

procedure TGradientAlphaEffect.SetAngle(AValue: Single);
begin
  if not SameValue(FAngle, AValue, TEpsilon.Angle) then
  begin
    FAngle := AValue;
    UpdateParentEffects;
  end;
end;

procedure TGradientAlphaEffect.SetOpaquePosition(AValue: Single);
begin
  if not SameValue(FOpaquePosition, AValue, TEpsilon.Vector) then
  begin
    FOpaquePosition := AValue;
    UpdateParentEffects;
  end;
end;

procedure TGradientAlphaEffect.SetTransparentPosition(AValue: Single);
begin
  if not SameValue(FTransparentPosition, AValue, TEpsilon.Vector) then
  begin
    FTransparentPosition := AValue;
    UpdateParentEffects;
  end;
end;

{ Register }

procedure Register;
begin
  RegisterComponents('Custom Effects', [TGradientAlphaEffect]);
end;

end.

Note: The effect above works only with Skia enabled.
Since the appropriate solution is not in changing the TSkLabel (as previously stated), I will close this issue as there is nothing we can do on our side. Remember that you can make this request for the gradient effect at qp.embarcadero.com


command-line arguments list link is dead

https://github.com/cloudflare/cloudflare-docs/blob/production/products/cloudflare-one/src/content/connections/connect-apps/configuration/config.md
Last line doesn't go anywhere

Fix was merged Feb 4. Closing issue.


fix tree component and update sqlservices

fix the null reference error noticed in sqlservices extension and update the readme and add reference to proposed typings files.

Pull Request Test Coverage Report for Build 486586913

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.008%) to 43.217%

Totals

Change from base Build 486359357:
0.008%

Covered Lines:
24390

Relevant Lines:
51756

💛  - Coveralls

Pull Request Test Coverage Report for Build 486586913

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.008%) to 43.217%

Totals

Change from base Build 486359357:
0.008%

Covered Lines:
24390

Relevant Lines:
51756

💛  - Coveralls


[FEATURE] Simple Website chatbot

Detailed description
When clicking on the chatbot logo
A window will be open
example:

As in the above image we can see, two options got displayed.

when a user clicks on a particular option, a specific answer should be displayed over there.

Example:
Option 1: Hello
user clicks on it and got a response: Hello
Open 2: I need help
after clicking on it, got a response: Hello, how we can help you?
Open 3: Need resources for learning:>
response: Here is your free resources list link.
Context
This will be very helpful for everyone
Possible implementation
If you have any doubts or questions, let us know below
Thanks.
Additional information
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Would like to contribute!

Would like to contribute!

Awesome,
I am assigning you this issue.
If you will have any doubts or questions, you can ask them below.
Thanks.

Would not be able to contribute to this, please assign someone else

Would not be able to contribute to this, please assign someone else

@Anjali2201
Okay, I will assign this to someone else
Thanks for your time.

Can I give it a try ?@kabir0x23

Can I give it a try ?@kabir0x23

Yeah, sure
I am assigning you this issue.

Hey @saimaheshtaduri ,
any progress?
If you need any help or have any doubts or questions let us know.
Thank you 😄.

If you still want to do this issue, let us know, and we will assign this issue to you.

👋🏻👋🏻👋🏻
So, where will this logo be located?
@kabir0x23

👋🏻👋🏻👋🏻 So, where will this chatbot logo be located? @kabir0x23

right bottom corner 👾.
and do you have any suggestions?

👋🏻👋🏻👋🏻 So, where will this chatbot logo be located? @kabir0x23

right bottom corner 👾. and do you have any suggestions?

I mean where on the website, will it be on every page?
Suggestion:

We have to identify the purpose of the chatbot.
Where on the website are users likely to wonder how to go about things?

I mean where on the website, will it be on every page?
Suggestion:
* We have to identify the purpose of the chatbot.

* Where on the website are users likely to wonder how to go about things?

Purpose something link FAQ
like when user click on the chat bot
they will get questions, when they click on specific one, they will get the specific ans.
What do you think,

should add a faq page or a bot.

I mean where on the website, will it be on every page?
Suggestion:
* We have to identify the purpose of the chatbot.

* Where on the website are users likely to wonder how to go about things?

Purpose something link FAQ
like when user click on the chat bot they will get questions, when they click on specific one, they will get the specific ans.
What do you think,

should add a faq page or a bot.

Having both will be great!
There will be a separate page for FAQ.
We just need to find a place on the website where the chatbot will be most effective.

Having both will be great! There will be a separate page for FAQ. We just need to find a place on the website where the chatbot will be most effective.

Nice
I have seen Chatbots are mostly on the right bottom of the screen.

Example:

Hi @kabir0x23 How do I navigate to the "Prep" section? It's no longer in the navbar dropdown.

Hi @abdullmustyy
Prep section got removed for now.
You can navigate manually by searching it on the search bar
Will add those categories in learn or somewhere else
thanks

Hi @kabir0x23
https://user-images.githubusercontent.com/87391935/196994851-f792b3d3-6aff-4932-9db8-c5dc7225c148.mp4
What do you think?

I'm glad you do. 😊
I'll make a PR now.


Mapnik 3.5.13 update incompatible

Following up on #2 - I bumped tilesplash to node-mapnik 3.5.13 and ran headlong into a known bug. Will try again on Ubuntu; it might just be OSX weirdness.

Punted for now by running mapnik v 3.4.19, which keeps us locked to node v4.5 for now: #19

v3.5.14 is released, opening up v6.x feasibility again. Suggested re-opening of this issue.

@abenrob Awesome - will take a look.

https://github.com/faradayio/tilesplash/pull/20

@abenrob All good here. Use 2.0.4 now. Thanks for the heads up!

Hi Im still getting install errors using the latest version of nodejs (6.x). I then tried again using version 4.5 and it worked with one small hiccup - I needed to install pug rather than jade.


Fix missing attribute handling in generator for Stubs

Problem
This PR fixes missing attributes on *Stub types.
This is crucial in case of higher platform requirements, especially when some properties have types available only on those required higher platforms.
Example type to mock:
import AVFoundation

@available(iOS 15.0, tvOS 15.0, *)
protocol TestedProtocol {
    var reason: AVCoordinatedPlaybackSuspension.Reason { get }
}

Generated mock before this PR's changes:
This fails to compile with error:

error: 'TestedProtocol' is only available in iOS 15.0 or newer

// ... redacted

 class TestedProtocolStub: TestedProtocol {

     var reason: AVCoordinatedPlaybackSuspension.Reason {
        get {
            return DefaultValueRegistry.defaultValue(for: (AVCoordinatedPlaybackSuspension.Reason).self)
        }

    }

}

Generated mock after this PRs changes:
// ... redacted

@available(iOS 15.0, tvOS 15.0, *)

 class TestedProtocolStub: TestedProtocol {

     var reason: AVCoordinatedPlaybackSuspension.Reason {
        get {
            return DefaultValueRegistry.defaultValue(for: (AVCoordinatedPlaybackSuspension.Reason).self)
        }

    }

}

I will not merge this until the PR for the same changes on the official repo is merged, otherwise the branch would be deleted.
See: https://github.com/Brightify/Cuckoo/pull/429


Broken Pipe

i get  a broken pipe error (called by multiprocessing/connection.py)
BrokenPipeError: [Errno 32] Broken pipe
occurs when MAX_BATCHES reaches its limit
i think it occurs  on 'behavioural_cloning_train' function when the following is called:
if batch_i > MAX_BATCHES:
break
do u have a suggestion to fix it?

Hey that is "kind of okey", as it is simply ending data loading process prematurely and things are not cleaned up properly. I recommend you catch the exception and ignore it if you want to continue code after that point.


GH-34971: [Format] Enhance C-Data API to support non-cpu cases

Rationale for this change
In order to support non-cpu devices and memory usage, we can add new ArrowDeviceArray and ArrowDeviceArrayStream structs to the C-Data API in order to allow for handling these types of memory without breaking the existing ABI.

What changes are included in this PR?
Definitions for a new ArrowDeviceArray, ArrowDeviceArrayStream and ArrowDeviceType enums.

Closes: #34971

@pitrou I think the other thing that hasn't been discussed in the above threads with regards to producer vs consumer provided stream is the development burden that will have to be incurred by the consumer in the different situations.
In producer provided stream / event:

The default behavior would be for the producer to return a stream or event in the struct if appropriate based on the producer
It forces the consumer to understand and handle device streams / events, which could be a non-trivial ask
There's no way for the consumer to ask for the data to be synchronized and safe to access from any stream and for the stream or event to be nullptr

In consumer provided stream:

The default behavior would be the consumer not providing a stream which would inform the producer to guarantee the data to be synchronized and safe to access from any stream
Someone could use consumer code that doesn't understand or utilize device streams or events in any way without issue

Ok, who is supposed to be the consumer of the C Device Data Interface? I would expect it to be an Arrow implementation, or an Arrow-compatible library. Realistically they probably already deal with CUDA streams if they support CUDA?

Ok, who is supposed to be the consumer of the C Device Data Interface? I would expect it to be an Arrow implementation, or an Arrow-compatible library.

I agree it would be primarily other libraries who want to exchange Arrow data. Users would likely initiate the exchange between the two libraries and the C Device Data Interface would be an implementation detail of how that exchange would work.
I do think there would be some users who want to directly interact with the C Device Data Interface structs though as well, as I had seen similar with __cuda_array_interface__ and dlpack.

Realistically they probably already deal with CUDA streams if they support CUDA?

Not necessarily. There's a bunch of CUDA code out in the wild that just uses the default stream implicitly. For example, most numba and cupy cuda code I've seen doesn't use streams. Numba and CuPy internally both support using CUDA Streams but I don't think it would make sense for either of them to directly support the Arrow C Device Data Interface since it doesn't match their memory layout. So that would become a library author or user's responsibility to handle it and CUDA Streams / Events may be a new concept to them.

@kkraus14 @pitrou Did you two reach a consensus on the question concerning the consumer passing of the stream/queue pointer into get_next or is this still an open question that needs to be discussed further?

@kkraus14 @pitrou Did you two reach a consensus on the question concerning the consumer passing of the stream/queue pointer into get_next or is this still an open question that needs to be discussed further?

I am still in favor of passing the stream/queue, but if @pitrou has a strong preference for returning it from the producer instead I would just ask that we use an Event instead of a Stream/Queue.

Thanks @gmarkall for the detailed insight! (also, hi :-))

I also think it would also have been more difficult to have the consumer supply the stream for CAI, because it is just a property containing a dict

This is also how the C Data Interface works, though of course it's a C struct rather than a Python dict.
This is also why I would originally prefer the CUDA stream to be provider-supplied, because it can be part of that interface...
So, to sum it up, we have:

in favour of the producer-supplied CUDA stream approach: allows to expose the CUDA stream in the C Data Interface (not only the C Stream Interface, which is more specialized - for example, it's sync not async)
in favour of the consumer-supplied CUDA stream approach: allows the consumer to ignore synchronization issues entirely, especially by passing a default stream

Am I missing something in this bullet list?

so, @gmarkall @pitrou @kkraus14 do we have a consensus on the best way forward here? You three definitely have a lot more insight into this than I do, so I'll move forward with whichever approach you all can agree on :smile:

so, @gmarkall @pitrou @kkraus14 do we have a consensus on the best way forward here? You three definitely have a lot more insight into this than I do, so I'll move forward with whichever approach you all can agree on 😄

I'm comfortable with either option assuming we use an Event pointer as opposed to a Stream pointer in the producer-supplied case, with a slight preference to the consumer-supplied case.

In that case, a bit more research is needed to find out what the equivalent of a CUDA Event would be for other backends.

cc @aregm @oleksandr-pavlyk
Any chance you could provide feedback from the SYCL perspective or ping someone who could?

@pitrou Do we need an equivalent for Event or just use a void* and let other backends use whatever they would need appropriately?
@aregm @oleksandr-pavlyk just poking again to see if either of you can respond to @kkraus14's comment? Thanks!
Just to clarify: are we considering that we'd add the Event to the ArrowDeviceArray struct and remove the stream argument from the get_next ?

@pitrou Do we need an equivalent for Event or just use a void* and let other backends use whatever they would need appropriately?

Probably a int64_t, so that the event can fit in the field regardless of the backend (some backends may use a pointer, but some may use some kind of opaque handle).
However, we should probably define what the field means for each backend. Otherwise we'll have a half-spec that nobody can implement rigorously.
Also, I think this means the device array must have its own release callback, to properly handle the lifetime of said event.

I assume we are talking about USM-based chunks. Dereferencing a USM pointer, generically, is only safe in kernels executed on the same device and using the same context that were used to perform the allocation. USM pointers of certain type (USM-shared and USM-host) can also be accessed from host. Deallocation of USM allocations requires a context.
SYCL provides a mechanism to recover the device where the allocation was made from the pointer and the context (see sycl::get_pointer_device, sec. 4.8.4). Therefore, a USM allocation should be thought of as a tuple of a pointer and the associated SYCL context.
To share USM allocations across libraries (modules) in the same process space, the same context must be used. Two context instances constructed from the same arguments (either SYCL device, or device selector callable) are going to be different.
To facilitate sharing USM allocations Intel has proposed an extension and implemented it in oneAPI DPC++ to define a canonical default context for each SYCL platform.
This extension allows to use USM pointer and a SYCL device to describe USM allocations bound to the default platform context.
The SYCL device in this tuple can be represented by an integer, which is the position of the device in the vector of all devices known to SYCL runtime, obtained using sycl::device::get_devices(). This position is guaranteed to be stable (same for different modules in a process, and the same between process runs).
Hence USM allocations (only if bound to the default platform context) can be shared using DLPack and represented in DLPack struct using a pointer and a integral device identifier. (DLPack support for USM allocations is implemented in IntelPython/dpctl).
I would therefore not recommend deleting information to reconstruct context from ArrowDeviceArray unless a Arrow were to restrict itself to heterogeneous systems in which SYCL only sees a single platform (i.e. only CUDA devices, only Level-Zero devices, or only HIP devices).
To support sharing of USM allocations which may still be due to be accessed by scheduled, but as yet unfinished kernels, one can use SYCL events (one may need to support providing more than one events). Consumer would then gate kernels accessing shared allocations to avoid race conditions.
@tchen suggested in https://github.com/dmlc/dlpack/issues/57#issuecomment-753696812 that instead of using events, a consumer would give a process a stream (or sycl::queue) that it would use to process shared USM allocation and the produce would insert a barrier gated by the events from submitted tasks that may yet modified the shared allocation.
Support for such barriers is yet to make it into the SYCL standard (see this oneAPI extension which is implemented in oneAPI DPC++ compiler). Such mechanism is implemented in IntelPython/dpctl (see here).

@oleksandr-pavlyk Thanks for the context and information there! Given the proposals so far here and what you mentioned in your comment. Do you have a preference between the concept of a producer-supplied event vs a consumer provided stream (or syscl::queue)?
Also, you said:

I would therefore not recommend deleting information to reconstruct context from ArrowDeviceArray....

What information were you referring to as deleting?

I was referring to the comment as I understood it:

Just to clarify: are we considering that we'd add the Event to the ArrowDeviceArray struct and remove the stream argument from the get_next ?

In SYCL, the stream corresponds to in-order sycl::queue which provides a way to retrieve the sycl::context associated with USM allocation. Now that I reread your comment, I see that I misunderstood the comment. It is not stating that stream is going to be removed from the ArrowDeviceArray structure, but rather only from arguments of get_next.
Focusing on the synchronization question part only from now on. Event-based synchronization is cheaper than stream-based one (since it requires submitting queue barriers), at least in the SYCL world. Additionally, stream-based synchronization is not even possible with current SYCL 2020 without leveraging oneapi_queue_barrier extension. This may be a weaker argument since the entire enterprise of sharing USM allocations without explicitly sharing underlying context requires an extensions too.

@oleksandr-pavlyk currently there isn't a stream that is a member of the ArrowDeviceArray struct. I appreciate the information and context, but can we boil it down to a conclusion/recommendation?
There are two questions that I can think of based on the information you've provided that I'd like to get a concrete opinion/conclusion from  you on if at all possible:

Should we include a event/stream/queue/some combination of these in the ArrowDeviceArray struct directly? If so, should it be some combination of these objects or should it just be one?
Would it be preferable to have the Producer provide an event inside the ArrowDeviceArray struct when it produces the array (consumer has to perform synchronization), or should we have the consumer provide a queue/stream to the producer that it would like the memory accessible from (producer performs synchronization)?

If there's something I'm not mentioning please let me know. I just want to try to move this proposal forward in a way that makes the most sense and is future proof-ed, so it would help to clarify precisely what your conclusions are in regards to those two questions. Thanks much!

@pitrou @lidavidm @paleolimbot @oleksandr-pavlyk @westonpace @leofang @gmarkall
I've updated the header and comments based on the discussions here for the past few weeks. If possible I'd like to reach a consensus here before the end of the week at which point I'll update the arrow dev mailing list for more discussion and hopefully a vote.

@pitrou @lidavidm @paleolimbot @oleksandr-pavlyk @westonpace @leofang @gmarkall
I've updated the header and comments based on the discussions here for the past few weeks. If possible I'd like to reach a consensus here before the end of the week at which point I'll update the arrow dev mailing list for more discussion and hopefully a vote.

Many thanks for the ping - I've no further comments.

cc: @shwina for vis

@pitrou I've added a full prose spec writeup for the documentation. Please have a look at your earliest convenience


chore(main): release 0.0.2

:robot: I have created a release beep boop
0.0.2 (2024-12-10)
Bug Fixes

handle provider state better (#6) (549c360)

This PR was generated with Release Please. See documentation.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 88.16%. Comparing base (549c360) to head (16ff9bd).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main       #7   +/-   ##
=======================================
  Coverage   88.16%   88.16%
=======================================
  Files           7        7
  Lines         473      473
=======================================
  Hits          417      417
  Misses         44       44
  Partials       12       12

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:robot: Created releases:

v0.0.2
:sunflower:


registerDevice error callback not fired when push notifications disabled in settings IOS

So, problem: "registerDevice error callback not fired when push notifications disabled in settings IOS"
How to repeat:
Disable application push notifications in phone settings.
Try to register device.
Result: no error and success callback fired.
If need, later i will write OS version.
Device: iphone 5

That's normal behavior since iOS gives you push token. You can use this token later when user re-enables push notification in settings without requiring user to open your app again.
The only way you will not receive push token is the following:

Fresh install (or previous app install has notification disabled in settings)
User presses "NO" on Allow notification alert
The app is not configured for "Background refresh" in Info.plsit

I think it is not normal behavior, because in common cases when you call function and pass inside this function(registerDevice) 2 callbacks error and success you are expecting that one of callbacks will fire. But in my case no one callback function is not fired. I think it is bug.

I see you mean no callbacks are fired at all. Let me check.

Yes, i mean this. No callback fired at all.

One more thing: when alert "allow notifications" has been displayed - did you press yes?
Then disabled notifications in settings?

Yes

But when i installed app first time and not opened it, then disable push notifications in setting there are was the same behaviour as previous.

Thanks. Checking.

Ok. Here are the results. Unfortunately as I suspected this is iOS documented behavior. Here is the description from the iOS header file:
// Calling this will result in either application:didRegisterForRemoteNotificationsWithDeviceToken: or application:didFailToRegisterForRemoteNotificationsWithError: to be called on the application delegate. Note: these callbacks will be made only if the application has successfully registered for user notifications with registerUserNotificationSettings:, or if it is enabled for Background App Refresh.

(void)registerForRemoteNotifications NS_AVAILABLE_IOS(8_0);

This means effectively that if you disable app notifications no callback (no success, no error) would be made to the app by iOS. Therefore the plugin simply have nothing to return. The delegate calls has not been made by iOS to the plugin.
You have to program your app logic to take this behavior into account.
I'm sorry, this is documented iOS behavior.

It is sad... But why phonegap pushwoosh plugin 3.4.1 calling error callback in such case?

It is sad... But why phonegap pushwoosh plugin 3.4.1 calling error callback in such case?

What is iOS version do you have? Did you check 3.4.1 on the same iOS version? What I see from debugging iOS9 is that no callback has been called at all from OS.

IOS 8.3 plugin version 3.4.1 here is next behavior: at first executed success callback next error callback. Maybe for fix this issue in ios while executing function "registerDevice" check if push notifications is available for current app, if not - call error callback?
http://stackoverflow.com/questions/1535403/determine-on-iphone-if-user-has-enabled-push-notifications

For history.. I am created plugin for checking push notifications enabled/disabled in phone settings
https://www.npmjs.com/package/push_status


e2e: Tests for Delayed removal.

We can reuse @kakkoyun 's tests he is implementing here: https://github.com/thanos-io/thanos/pull/2250
cc @khyatisoneji

This is done while we were fixing bugs (:


"Powershell not spawned"

I get an error now (on master) saying "'powershell' could not be spawned.  Is it installed on your path", with a sidebar opening with error
Window load time: 1219ms
events.js:141 Uncaught Error: spawn powershell ENOENT

cc @Varanas

Yay, I broke it...
@dlfivefifty What OS are you on? I'd guess it's a Linux since process.plattform seems to be problematic there.
But I'm installing a Linux as I write, so hopefully I'll be able to debug this soonish.

I am on windows 10.
From: Varanas<EMAIL_ADDRESS>Sent: 19-Sep-2015 11:16
To: JunoLab/atom-julia-client<EMAIL_ADDRESS>Subject: Re: [atom-julia-client] "Powershell not spawned" (#35)
Yay, I broke it...
@dlfivefifty https://github.com/dlfivefifty  What OS are you on? I'd guess it's a Linux since process.plattform seems to be problematic there https://github.com/JunoLab/atom-julia-client/issues/17 .
But I'm installing a Linux as I write, so hopefully I'll be able to debug this soonish.
—
Reply to this email directly or view it on GitHub https://github.com/JunoLab/atom-julia-client/issues/35#issuecomment-141643193 .  https://github.com/notifications/beacon/ANsIQaitPBjB9Jcv4_o_g-EM4pIqAddEks5ozS1dgaJpZM4GAPn8.gif

And you have the same problem with spawning Powershell, @SergeUK?

I don’t think so but to be honest with you I don’t really know how to try to spawn Powershell.
From: Varanas<EMAIL_ADDRESS>Sent: 19-Sep-2015 12:23
To: JunoLab/atom-julia-client<EMAIL_ADDRESS>Cc: SergeUK<EMAIL_ADDRESS>Subject: Re: [atom-julia-client] "Powershell not spawned" (#35)
And you have the same problem with spawning Powershell, @SergeUK https://github.com/SergeUK ?
—
Reply to this email directly or view it on GitHub https://github.com/JunoLab/atom-julia-client/issues/35#issuecomment-141653179 .  https://github.com/notifications/beacon/ANsIQW5owx98-oKkrLCwgztjmt74LQzBks5ozT0ngaJpZM4GAPn8.gif

Ran across this as well this morning. Changing the order of the process.platform switches to check for win32 first and default to linux seems to fix this on archlinux and windows 7 for me.
diff --git a/lib/connection/process.coffee b/lib/connection/process.coffee
index 93d9cd5..049909e 100644
--- a/lib/connection/process.coffee
+++ b/lib/connection/process.coffee
@@ -35,24 +35,24 @@ module.exports =

   spawnJulia: (port) ->
     switch process.platform
-      when 'darwin' || 'linux'
-        @proc = process.spawn(@jlpath(), [@jlargs()..., '-e', "import Atom; @sync Atom.connect(#{port})"])
-      else
+      when 'win32'
         @proc = process.spawn("powershell", ["-ExecutionPolicy", "bypass", "& \"#{__dirname}\\spawnInterruptibleJulia.ps1\" -port #{port} -jlpath \"#{@jlpath()}\" -jloptions \"#{@jlargs().join(' ')}\""])
+      else
+        @proc = process.spawn(@jlpath(), [@jlargs()..., '-e', "import Atom; @sync Atom.connect(#{port})"])

   interruptJulia: ->
     switch process.platform
-      when 'darwin' || 'linux'
-        @proc.kill('SIGINT')
-      else
+      when 'win32'
         @sendSignalToWrapper('SIGINT')
-
+      else
+        @proc.kill('SIGINT')

   killJulia: ->
-    if process.platform != 'darwin' && process.platform != 'linux'
-      @sendSignalToWrapper('KILL')
-    else
-      @proc.kill()
+    switch process.platform
+      when 'win32'
+        @proc.kill()
+      else
+        @sendSignalToWrapper('KILL')

   sendSignalToWrapper: (signal) ->
     wrapper = net.connect(port: 26992)
diff --git a/lib/julia-client.coffee b/lib/julia-client.coffee
index 1fcd948..b03716d 100644
--- a/lib/julia-client.coffee
+++ b/lib/julia-client.coffee
@@ -16,10 +16,10 @@ defaultTerminal =
   switch process.platform
     when 'darwin'
       'Terminal.app'
-    when 'linux'
-      'x-terminal-emulator -e'
-    else
+    when 'win32'
       'cmd /C start cmd /C'
+    else
+      'x-terminal-emulator -e'

 module.exports = JuliaClient =
   config:

Yeah, thought so. For some reason I thought that process.platform was behaving strangely on windows as well, but it works for me too.

Cool, I'll PR that diff in a moment.

Sweet, thanks!

It's a bit weird that process.platform on linux was underfined and not for other platforms... is there an upstream repo tracking this issue already? I've not managed to find one yet.

It’s fixed for now  (OS X).  Thanks!

On 19 Sep 2015, at 10:06 pm, Michael Hatherly<EMAIL_ADDRESS>wrote:
It's a bit weird that process.platform on linux was underfined and not for other platforms... is there an upstream repo tracking this issue already? I've not managed to find one yet.
—
Reply to this email directly or view it on GitHub https://github.com/JunoLab/atom-julia-client/issues/35#issuecomment-141659006.

@Varanas , I get the same message now, on Windows 10, and am ready to report details.
I have already tried various fixes of course. So this is not the start.

As a normal user, Atom seemed not have permission to start Julia.
I changed this user to have administrator privileges. Started up, and got success. Too optimistic, though.
On successive starts, I get no success. Start atom from the powershell -> Ctrl+Shift+P-> Julia client open console - > type e.g. homedir()

A red pop-up, says:
'powershell' could not be spawned. Is it installed and on your path? If so, please open an issue
on the package spawning the process.
I have two warnings and two messages:
Warning: /deep/  combinator is deprecated. See https://www.chromestatus.com/features/6750456638341120 for more details.
Warning: ::shadow     C:\Users\F\Appdata\Local\atom\app-1.3.1\resources\app.asar\src\text-editor-component.js:915 pseudo-element is deprecated. See https://www.chromestatus.com/features/6750456638341120 for more details.
Error:   Uncaught Error: spawn powershell ENOENT     event.js:141

Events.js is this: chrome-devtools://devtools/bundled/events.js
I can't seem to find it though, and I don't know this debugging tool.
...
Atom packages:
ink 0.1.1
julia-client 0.1.2
language-julia 0.4.1
Julia packages:
Atom 0.2.0+
CodeTools 0.2.0+
JuliaParser 0.6.3+

@hustf: Strange. Can you start powershell from a terminal? Also, you are on atom-julia-client master, right?

I can start powershell from a terminal. When I do, the Ms-dos prompt changes to PS C:\users....
I am probably not on julia-client master, but how to check that?

You did not follow the instructions from here when installing, right? Otherwise you wouldn't have any issues with powershell, methinks.
If so, it's just a matter of checking out the latest master, switching to that branch and restarting Atom.
Also, if that doesn't work: Is there more to that backtrace in the developer console (ctrl+alt+i)? I'm kinda puzzeled why Atom can't spawn ps...

Not quite, but I have read it. Regarding installation instructions, I looked at all the relevant places I could find first. I might end up building the whole thing. I made a new user, with fresh installations of Anaconda, Julia, the basic packages, github desktop, Visual Studio Code, updated python, even made sure to make an environment variable with visual studio version 2015. And PATH.
Then I followed
https://github.com/JunoLab/atom-julia-client/blob/master/docs/README.md#developer-install
I rebooted and Git shell - > cd julia-client -> atom ->console and got quite another error message. This time the error message was regarding an error in Ink. I ought to upgrade to Ink 0.1.2 according to the error message, which had something to do with strings. Sorry the details were lost on me. I tried to update from within Atom, but got feedback that everything is up to date. Still at Ink 0.1.1 though.
I am now unable to reproduce any of the errors. Everything works fine, at the moment. If there is an error log stored somewhere, I can provide it of course.

OK, all I had to do to reproduce was double-clicking a .jl file. I am back at 'powershell could not be spawned', and will try to proceed slowly with digging up this. The most effective way is probably that I answer your questions, starting wtih ctrl+alt+i.

ctrl+alt+i just opens the debugging interface from which I reported the errors above.
I don't understand why it matters in which github local directory I am when launching Atom?

How does that matter? You're getting no errors when launching from a certain directory?
Also, did you get that ink error again?

Yes? If that in deed explains why it works sometimes.
Just now I have an erroneous instance of Atom open, which I opened by double-clicking a .jl file. I do not know how to use this tool and find the contents of varable ENOENT (if it is a variable?).
The ink error has not reappeared.

Also, I have a normal Julia instance open. If that matters?

It can also be of interest what I have in my Julia-client settings:
Julia Arguments: Default: -q
Julia Path: C:\Users\F\AppData\Local\Julia-0.4.2\bin\julia.exe
Notifications: On
Terminal Command used to open a terminal:
cmd \c
(I have experimented with all of these settings)

I do not know if Atom opens as completely separate instances. If they do, I can of course test simultaneously by starting from the git shell command line in this Julia-client folder.

Nope, shouldn't matter. In those sessions where you weren't getting that error, did you have a julia file open or started Julia from within Atom?

Oh, wait. You were starting from the git shell? That might explain things. Could you try starting Atom with the shortcut or from the normal terminal (and opening a *.jl file and executing something in it so Juno tries to start julia)?

In order to check if this caused the issiue, I tried: 1) No power shell. 2) Power shells with active Julia sessions inside them. 3) Starting Atom directly on its .exe shortcut.
I will proceed to do what you told.

Also, you might want to try to start up a normal julia session from the terminal and typing ;powershell \$PSVersionTable.PSVersion.

There are two ways to start Atom directly: Atom Command and Atom Desktop App.
I try Desktop App. No messages. Then open a .jl file. Go to line 1+1. Ctrl+enter. And Fail, powershell thingie.
Atom Run Command (Windows-button, type Atom and you get both alternatives. Same procedure, same fail.
A normal Julia REPL is open in the background.

shell> powershell \$PSVersionTable.PSVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
5      0      10586  0

Mkay. I'm confused.
Next thing you could try: Open the dev interface in atom and type
cp = require('child_process')
cp.spawn("powershell")

into the console there. That will probably fail as well...

Will do. Just want to mention, when I start Julia from Git Shell and do the shell powershell check, I get the same powershell build.

Sorry, how do I open the dev interface? I know about ctrl+shift+p, and about the julia console.

Ah, I meant the ctrl+alt+i thingie ;)

cp = require('child_process')
Object {}
cp.spawn("powershell")
ChildProcess {domain: null, _events: Object, _eventsCount: 0, _maxListeners: undefined, _closesNeeded: 3...}

(we can't copy from the console, I have to retype)

So it didn't error?!
Does cp.spawnSync("powershell", ["$PSVersionTable.PSVersion.Major"]).output[1].toString() give 5 as a result (you can actually copy from that console, btw)?

Yes. "5 " (copied)

Hm. I am even more confused.
I quite honestly don't know how or why this happens -- the last snippet should be exactly the one  where it fails when it tries to start julia.

I have a hunch now. No explanation, but a hunch.
Every time I started Atom above, a certain .jl file was open.
C:\Users\F.julia\v0.4\GraphLayout\test\runtests.jl
I tried many times to close it, and start a new file. Then close atom. And open it again. This file was present at reopen. Finally, I double-clicked another .jl-file. And now I'm stuck with this file instead.
And with no errors.
So has this to do with another package? Language-julia or ink?

That's intended, I think. Atom remembers the file you had opened last and opens that again when restarting.

I've tried with 8-10 different files now.
I seem to get malfunction every time the startup-file is part of the julia packages.
And every .jl file outside it seems to work.
Is Atom colliding with github or something?

The above 'mystery fix' allowed me to work for a while, although I am not sure what works as intended (I can't make Julia REPL a visible application, it's always a hidded process).
The issue of this thread may be may be a symptom of the below, which I'll post on Julia issue tracker if I find it's not been reported already:
0.4.2 behaves differently from 0.4.1 with respect to shell commands. The behaviour is different depending on context, but here is an example:
From a git shell, Julia 0.4.1/bin, I can run Julia.exe and the shell commands 'ls', 'dir' and 'powershell $PSVersionTable.PSVersion' work fine.
In the same window, it quit() Julia, then move to the 0.4.2/bin folder, start Julia.exe and get this:
shell> ls
7z.dll (.....)
shell> dir
**ERROR: could not spawn `dir`: no such file or directory (ENOENT)
 in _jl_spawn at process.jl:262**
shell> powershell \$PSVersionTable.PSVersion
Major  Minor  Build  Revision
-----  -----  -----  --------
5      0      10586  0

We haven't got to the core of this here; this post is a follow-up from my side. Atom-julia-client is potentially great, but on my system it's not quite there yet.
https://groups.google.com/forum/#!topic/julia-users/pHonnw8X3iw

This seems to fix the issue with Julia 0.4.2 when git desktop is installed, and your git desktop shell preference is the powershell and not the old ms-dos style shell. The shell commands don't generally work.
Atom editor ->Packages->Settings View->Manage packages->Julia client->Settings->Terminal
Replace the default CMD \C by:
c:\users\YOURUSERNAMEHERE\documents\GitHub\GitHub.appref-ms --open-shell

So you're saying that changing the terminal setting of atom-julia-client helps?
Just to make sure I understood you correctly earlier:

You start Atom, load a .jl file.
If you then start the julia client, either by doing Ctrl+J Ctrl+S, by evaluating something in the editor or by evaluating something in the console, you get the 'powershell' could not be spawned. error.
You restart Atom, change the terminal setting to the github shell, open the same *.jl file as above and again start Julia as above, you get no error? Or were you trying to open a REPL via Ctrl+J Ctrl+R?

Also, I'm going to reopen this until I understand how this was solved and what we should improve to fix this.

Varanas, I corrected the path in the previous post, and tried to make the text more clear. I should also have mentioned that I set my Julia path to end with 'Julia.exe'. Not the intended use, but a dirty fix.
With these settings, I somehow bypassed the Julia / Git bug that makes me unable to run shell commands from 0.4.2. But I am not so far able to start a REPL client with these settings. Instead, I get a git/powershell when pressing ctrl+(j r)
I hope the above is clear now, and I will try to answer your questions precisely if I get more time tonight.

In my case, changing the terminal settings AND the julia path seemed to help, compared to some other combinations I tried. But having trouble to reproduce fully today, I see this is likely to be per chance.
Now with all three default settings (and Julia.exe on my PATH variable):

Start atom with a .jl file loaded AND a project file in the left tab. This matters.
ctrl+enter works. Restarting in the same way and pressing ctrl + (j s) yields a progress indicator for some seconds, which disappears. No output at all. ctrl+alt+i reveals the error message below. Note that Pkgdep.js is NOT a package or github folder. (This just happens sometimes, on a retry for checking it does not happen.) Evaluating something in the console works. But shell commands like ;ls or ;dir yield the second error message below.
I restart atom, change the terminal setting (only) to C:\Users\F\AppData\Local\GitHub\GitHub.appref-ms --open-shell. ctrl+enter in a .jl file works. Restarting, the ctrl+(j s) yields a progress indicator for some seconds, which disappears. ctrl+alt+i reveals just the two deprecation warnings that's always there. Evaluation works (with no wait). Shell commands do NOT work.

I probably tested all the various methods julia console commands yesterday, including starting Julia 'manually' (ctrl+(j+r), type julia in the git shell, type 'using atom', test the shell command ;ls (which works). But today, I am not able to make the connection back to Julia-atom-client. I can not make shell commands run from the atom-client-console, or get a visible REPL started automatically. Changing the default terminal parameter /C to /K will at least keep console visible, and this may help with debugging further.
Error message from bullet point 2. After this, I log off my windows accout and back on.
Error: Cannot find module 'C:\Users\F\PkgdepVis\src\PkgdepVis.jl\spec'
at Module._resolveFilename (module.js:336:15)
at Function.Module._resolveFilename (C:\Users\F\AppData\Local\atom\app-    1.3.1\resources\app.asar\src\module-cache.js:383:52)
at Function.Module._load (module.js:286:25)
at Module.require (module.js:365:17)
at require (C:\Users\F\AppData\Local\atom\app-1.3.1\resources\app.asar\src\native-compile-cache.js:41:21)
at requireSpecs (C:\Users\F\AppData\Local\atom\app-1.3.1\resources\app.asar\spec\jasmine-test-runner.js:101:7)
at module.exports (C:\Users\F\AppData\Local\atom\app-1.3.1\resources\app.asar\spec\jasmine-test-runner.js:49:7)
at module.exports (C:\Users\F\AppData\Local\atom\app-1.3.1\resources\app.asar\src\initialize-test-window.js:88:17)
at setupWindow (file:///C:/Users/F/AppData/Local/atom/app-1.3.1/resources/app.asar/static/index.js:85:5)
at window.onload (file:///C:/Users/F/AppData/Local/atom/app-1.3.1/resources/app.asar/static/index.js:40:9)
Second error message from bullet point 2.
could not spawn 'dir': no such file or directory (ENOENT) in jl.spawn at base\process.jl:262

FWIW, I saw that error today as well. And I couldn't reproduce it.
I'm afraid I still don't quite understand what's wrong here...

@hustf Just something that came to mind today: Are you on a slow computer? I've noticed some spurious errors that may be related to system load -- they occur much more often on my laptop than on my desktop machine.
The REPL-spawning problem should be fixed with https://github.com/JunoLab/atom-julia-client/pull/71.

@varanas , thanks for not giving up. #71 seems to have fixed the REPL-spawning problem!
The issue here was reported from a pretty decent 64 bit computer, just recently upgraded to Windows 10. Also with the julia Atom package in a precompiled state.
I bought a new gamer's laptop a week ago, with Windows 10. First thing I did was keep tongue-in-cheek and install Julia (Juno bundle and the command-line version), and follow the developer recipe. The PATH is already quite swollen in that state, but Atom and Julia just have to cope with that (in the future). Some PATH entries end in "" and some not. I tried a bit of twiddling with PATH endings, and checked that process.env.path reported the same as in the operating system (Julia->ENV["PATH"] is different.)
I was not able to neither spawn a REPL or run Julia in the background - until just now. Will try it out now.

The REPL spawning works now.
Also, starting a REPL client works (ctrl+alt +j+r). The window caption reads exactly:
C:\windows\system32\cmd.exe - "C:\Users\F\AppData\Local\Julia-0.4.2\bin\julia.exe" -q -P "import Atom;Atom.connect(51884)"

(starting took some time, for recompiling CodeTools). The REPL client lives on after Atom is closed. The settings were :
-q
C:\Users\F\AppData\Local\Julia-0.4.2\bin\julia.exe
Ctrl + j+s does not work, same old powershell spawn issue. There is a long history of similar issues.
With all three julia-client settings field equal to defaults, the response is exactly the same but the window caption is just
C:\Windows\System32\cmd.exe
I find this confusing: Why include Julia.exe at the end of the second setting? It would be more intuitive if the directory path had to be given when the julia PATH entry is missing.

Alright, so you can at least use Atom now, except for the built-in console. :)
I'm afraid the powershell issue still baffles me, especially since you can spawn it from the dev-console in Atom.

In deed, this is the way I would work anyway. I've always worked in an IDE before and produce a lot faster given this kind of environment, so thank you very much!

@hustf There is now an option to use Juno without the powershell wrapper on master. You might wanna try that and see if it helps you.

Hello, Varanas,
I have been meaning to report that powershell option started working. Unfortunately, I can`t say exactly why it did. The PATH variable seems to be split in two: Environment variables for your account, and system environment variables. It may also matter for some parser whether one ends the preceding folder names with or without a \ at the end - unix style.
Even though my path is now more ok, Ive seen this powershell message in other, related packages but I cant say where / in which versions that was. Hence this delay in reporting back. I currently use both "Atom-shell" (Juno /LT) and "Atom". Juno/Lt complains that (electron) ipc module is deprecated, I should use ipcRenderer. Is this related? I looked for the option without finding what you mean.

Is this still an issue, @hustf?
Juno/Atom is close to feature parity with Juno/LT, so I'd recommend using the former, especially since Juno/LT hasn't been updated in quite a while.

Varanas, thank you for following up.
Atom has been working like a charm for two months, and it's pleasant to work with. I only leave the environment when I need speed, or better readability in help texts. Juno stopped working after an LT update, this is mentioned elsewhere I believe. I have not actively updated lately and so I look forward to finding out about the new features.
To check if all is really really fixed we would need to fiddle with variables and user privileges, which is very time consuming due to the restarts involved. To new users who might perhaps run into this or a related issue, it would be a much bigger pain of course. So if I can be of any assistance with testing, just ask, otherwise I believe this can be closed.

Alright, glad it's working for you! Any specific issues with speed you're experiencing; if so, could you open an issue? The doc system will hopefully get a lot nicer soonish.
I'll close this -- if someone else experiences this they can just reopen or create a new issue.

@hustf Yes, thanks very much for the offer of assistance, but as @Varanas says I think we shouldn't take up your time now – we can always ping if this comes up again in case you're able to help out.


Importing using SPM: Reachability missing

I've added the git repo to my project, and when I do:
import Connectivity
I get:

Looking at the Package.swift and the source code, it looks like Reachability ought to be included.
Thanks!

Hi @crspybits thanks for reporting this issue - quick question do you experience this if you added Connectivity via SPM to a brand new app project as well? Thanks in advance.

I have the same issue. Down library has solution, see https://github.com/johnxnguyen/Down/pull/266.

Thanks for reporting @larryonoff, @dwsolberg it would be great if you could some information on the issue itself. Are you trying to import Connectivity into a Package.swift without a Xcode project? Trying to work the circumstances necessary to recreate the issue.

@rwbutler Our team has SDK for all our apps. One of the dependency has Connectivity. So we're in the process of migrating to SPM and faced with the issue.
The solution that I has at the moment is on the screenshot below

I checked how Facebook manages dependencies https://github.com/facebook/facebook-ios-sdk/blob/master/Package.swift.

Please check https://github.com/rwbutler/Connectivity/pull/62

@larryonoff Thanks for the PR - have merged 👍

@larryonoff Thanks for the PR - have merged 👍

please release! 🥇

@larryonoff Done! 👍

@rwbutler awesome! thanks! 👍
@crspybits could you please confirm that your issue was fixed.

Closing this one for now - if it turns out that this is still an issue let me know and I'll re-open.

Thanks. I'm using Hyperconnectivity currently. I've made note. I may try Connectivity again later.


Adding Weaviate, Dalle2, FeatureBase tables, templates

This is general refactoring of the sample query work branch of Slothbot for merging into main.
This PR adds prompt templating support, basic logging of interactions in Weaviate, and methods to query FeatureBase.
SQL queries are not turned on in this PR. Flow for creating the SQL queries will be added soon.

Going for it.


LogProxyConsumer should inherit from ConsumerBase

Change the inheritance of LogProxyConsumer so Alert Rules can
be pulled to the existing machinery.
Add docstrings for the LogProxyConsumer class explaining the
arguments and possible exceptions.

What, no integration test? :-)


Discussion on dictionary based callback

Hi,
A few months ago, I wrote a wrapper around callback to support dictionary handing of inputs and outputs in Dash. Unbeknownst to me you all ad a parallel effort. After many months of internal vetting, we determined it was ready for prime time and I submitted it as a PR https://github.com/plotly/dash/pull/1646.
I haven't had a chance to look at the dash-labs approach yet, but the method I propose is very simple to use and intuitive IMHO. It also supports pattern matching. (Took a while to see how to incorporate it). Some documentation is provided in the PR plus I've ported virtually every example in the Dash documentation using this callback. I'd be happy to see how we could potentially take the best of both and create a new better callback.
I've used this extensively inhouse so I'd be happy to show the various ways this can be used. In a way we use it to manage the problem of outputs being driven by many inputs for which the proscribed solution by dash is to create conglomerated callback.

Here's the documentation I prepared with the pull request.
The dictionary based callback decorator @app.dict_callback operates similarly to the normal @app.callback decorator. With two additional  options strict and allow_missing. The invocation of the decorator is virtually identical.
Basic Example with State
This example is the same basic example given in the documentation
except using dict_callback.
import dash
import dash_core_components as dcc
import dash_html_components as html
from dash.dependencies import Input, Output, State

external_stylesheets = ['https://codepen.io/chriddyp/pen/bWLwgP.css']

app = dash.Dash(__name__, external_stylesheets=external_stylesheets)

app.layout = html.Div([
    dcc.Input(id='dcinp-1-state', type='text', value='Montréal'),
    dcc.Input(id='dcinp-2-state', type='text', value='Canada'),
    html.Button(id='dc-submit-button', n_clicks=0, children='Submit'),
    html.Div(id='dc-output')
])

@app.dict_callback(Output('dc-output', 'children'),
                   Input('dc-submit-button', 'n_clicks'),
                   State('dcinp-1-state', 'value'),
                   State('dcinp-2-state', 'value'))
def update_output(inputs, states):
    return {'dc-output.children': u'''
        The Button has been pressed {} times,
        Input 1 is "{}",
        and Input 2 is "{}"
    '''.format(inputs['dc-submit-button.n_clicks'],
               states['dcinp-1-state.value'],
               states['dcinp-2-state.value'])}

The strict and allow_missing options
For performance reasons, the dict_callback decorated callback doesn't by default check to  make sure all keys in the output dictionary correspond to actual output ids and output  properties declared in the invocation. The strict option enforces that. If the output contains  a key not corresponding to a declared output id and property a KeyError is thrown. A good practice is to set strict to try while developing and debugging to catch possible errors. The allow_missing option is set to True by default. This options
allows for an incomplete output dictionary. All missing properties are unchanged. This is particularly useful for a complex callback where helper functions may be responsible for some outputs and not all outputs need to be updated.
In the following example, a KeyError is thrown since output-2-children is missing from the dictionary but if allow_missing were set to True it would be allowed. This pattern is very useful. Due to the constraints on outputs belonging to a single callback, you can easily be forced to conglomerate a bunch of callbacks into one. This pattern allows you to subdivide the callback into separate functions and one only needs to merge the dictionaries at the end.
app = dash.Dash(__name__)
app.layout = html.Div([
    dcc.Input(id="input1", value="initial value"),
    dcc.Input(id="input2", value="state"),
    html.Div([html.Div(id="output-1"), html.Div(id="output-2")])
])

@app.dict_callback([Output("output-1", "children"), Output("output-2", "children")],
                   [Input("input1", "value")],
                   [State("input2", "value")], allow_missing=False)
def update_output(inputs, states):
    output = {"output-1.children": inputs['input1.value']
    }
    return output

In this example, strict is set. This will throw a KeyError as there is no output called output-3.children. While this is usually a good thing, it requires a separate check so could impact performance.
app = dash.Dash(__name__)
app.layout = html.Div(
    [
        dcc.Input(id="input1", value="initial value"),
        dcc.Input(id="input2", value="state"),
        html.Div([html.Div(id="output-1"), html.Div(id="output-2")])
    ]
)

@app.dict_callback([Output("output-1", "children"), Output("output-2", "children")],
                   [Input("input1", "value")],
                   [State("input2", "value")], strict=True)
def update_output(inputs, states):
    output = {"output-1.children": inputs['input1.value'],
              "output-2.children": states['input2.value'],
              "output-3.children": "Another Value",
    }
    return output

Finally, the dict_callback decorator works with pattern matching as in this Pattern Matching Example (taken from the documentation). Note that dict_callback works with a callback_dict which is a subclass of dict that provides pset and pget that allows access to the dictionary using pattern matching keys without having to worry about the underlying hashing or the order.
app = dash.Dash(__name__)

app.layout = html.Div([
    html.Button("Add Filter", id="dynamic-add-filter", n_clicks=0),
    html.Div(id='dynamic-dropdown-container', children=[]),
])

@app.dict_callback(
    Output('dynamic-dropdown-container', 'children'),
    Input('dynamic-add-filter', 'n_clicks'),
    State('dynamic-dropdown-container', 'children'))
def display_dropdowns(inputs, states):
    new_element = html.Div([
        dcc.Dropdown(
            id={
                'type': 'dynamic-dropdown',
                'index': inputs['dynamic-add-filter.n_clicks']
            },
            options=[{'label': i, 'value': i} for i in ['NYC', 'MTL', 'LA', 'TOKYO']]
        ),
        html.Div(
            id={
                'type': 'dynamic-output',
                'index': inputs['dynamic-add-filter.n_clicks']
            }
        )
    ])
    states['dynamic-dropdown-container.children'].append(new_element)
    return states

@app.dict_callback(
    Output({'type': 'dynamic-output', 'index': MATCH}, 'children'),
    Input({'type': 'dynamic-dropdown', 'index': MATCH}, 'value'),allow_missing=False
)
def display_output(inputs, states):
    id_, _ = inputs.pkeys()[0]
    output=dash.Dash.callback_dict()

    div = html.Div('Dropdown {} = {}'.format(id_['index'], inputs.pget(id_,'value')))
    output.pset(type='dynamic-output', index=id_['index'], property='children', value=div)
    return output

Hi @summerswallow-whi, thanks for sharing your work here. Yeah, there is a bit of overlap here.
Since you've thought about this a good bit already, it would be helpful to hear your feedback on https://github.com/plotly/dash-labs/blob/main/docs/02-CallbackEnhancements.md if you're interested in looking it over.

I have taken a look at the callback enhancement though not in great code detail and compared our approaches. I think fundamentally there is a difference in philosophy. You mentioned in the code that for now it is a wrapper about the old callback. So to illustrate the difference if we were to pseudo-code your callback enhancement with decorators it might look something like this
@enhancement (...)
@app.callback(...)
def callback {
}

If I were to refactor my code as a decorator (which is actually how I did start out), it would look more like this
@app.callback(...)
@dictonary(...)
def callback() {
}

Despite addressing the same problem, the solutions actually don't overlap. You wrap the encompassing callback mechanism including the callback decorator whereas my approach encompasses the underlying callback.
Both approaches have their advantages and disadvantages. The chief advantage of your existing approach is that you can mix and match dictionary vs tuples and there are cases where that can be a significant advantage. If someone has an array of inputs a tuple makes iteration over them much easier. My approach commits to using a dictionary, plus I have found with my approach in simple cases forcing the output into a dictionary is a little cumbersome.
I think the two chief advantages to my approach is first it doesn't build up another framework for the callback mechanism. You already have tuples, and recently pattern matching. I would be a little concerned that adding dictionaries on top of this would make maintaining compatibility and maintenance down the road more complicated. The second advantage is that the coder doesn't have to conceive and construct a dictionary as input or output. It comes for free as an id.property' key.
All this being said, even though the two approaches are philosophically different, they are not incompatible and could coexists. As such there may even be an opportunity for some a-b testing. In fact one alternative would be for me to refactor the code back to a decorator.
I haven't looked at the code in detail but mostly at your documentation. Two things aren't clear to me. First how does this work with pattern matching? Looks like maybe simple cases should just work, but I'm not as clear on how that would work on more complicated cases. (I originally wrote this code probably 6 or 7 months ago and pattern matching threw me for a loop) It took a while to figure out a way to make my code compatible. If you have issues here, maybe somethings I wrote might address this and would be happy to apply what I've learned. The second thing (and I apologize if it is apparent from the code) how does the dictionary structure reflect in the callback_context input_lists and output_lists.
As for direct feedback on that document, I think showing some pattern-matching examples with keywords would be good. Also, I think the interchanging of inputs and states is a great idea. I've found that when I use my callback code, the first two lines of the callback are
def callback(inputs, states):
   inputs.update(states)

So putting they into the same bucket makes a lot of sense to me.

I took a broader look at your documentation, I think your templates is a fantastic idea. I had some thoughts but didn't know whether to create a separate issue. One of Dash's shortcomings in building complicated complicated dashboards and interactions has been the ability to abstract sets of components. Looks like templates can fill that shortcoming.

Thanks for the rundown. And yeah, I do need to do some more testing with pattern matching callbacks, so that's a good reminder.
When actually integrating this into Dash, it may not keep the same design of being a wrapper around the callback mechanism, that that's still TBD.  On idea, have you thought about implementing your dict_callback as a Dash plugin?  The plugin API isn't really documented, but it's pretty simple, and you could probably pretty much copy what I did with the FlexibleCallback callback plugin here.  This would make it possible to distribute what you have as separate package that folks could try out and discuss more on the forums.
And actually, an advantage of my current approach of wrapping the Dash 1 callback decordator is that your Plugin could do the same thing, without needing to unify the plugin functionality right away.
Thanks for taking a look at the template. The goal is certainly to address some of the shortcomings you mentioned. The best place to discuss templates right now would be this forum thread: https://community.plotly.com/t/dash-labs-0-2-0/52952/12.  Looking forward to hearing your thoughts!

I'll give the plugin a go. Is there a forum thread for this topic?

Yes, as Jon said, the thread is here: https://community.plotly.com/t/dash-labs-0-2-0/52952/12
Please note that the dash-labs plugin-based system is an interim state, and the end-goal here is that the "real" app.callback will be modified for the 2.0 release to adopt the behaviour currently being demo'ed by the plugin, so in the end there will be no decorator to implement the changes that dash-labs exposes.
Maybe you'll want to implement your proposed behaviour as a separate plugin for demonstration/distribution/adoption as well?

Had to jump through a few approvals at work but I open sourced the dict_callback as a plugin.
It's now available at Pypi pip install dash-dict-callback if anyone wants to kick the tires on it. More examples are forthcoming in the repo. You can find the source at https://github.com/WestHealth/dash-dict-callback.


[BUG] - VASIL cardano-cli query leadership-schedule Error

External
Summary
When running the leadership schedule on a block producing node in VASIL on testnet it will error out and not complete
Steps to reproduce
Steps to reproduce the behavior:

on a block producing node in testnet running  cardano-cli 1.35.0
run the cardano-cli query leadership-schedule --testnet-magic<PHONE_NUMBER> ... --current
See error
Error: Failed to successfully decode the current epoch state: DecoderErrorDeserialiseFailure "EpochState (BabbageEra StandardCrypto)" (DeserialiseFailure 31063970 "Decoding TxIx: too many bytes.")

Expected behavior
Leadership schedule for block production for the current Epoch
System info (please complete the following information):

OS Name: Ubuntu
OS Version: 20.04.4 LTS
Node version:
cardano-node 1.35.0 - linux-x86_64 - ghc-8.10
git rev 9f1d7dc163ee66410d912e48509d6a2300cfa68a
CLI version:
cardano-cli 1.35.0 - linux-x86_64 - ghc-8.10
git rev 9f1d7dc163ee66410d912e48509d6a2300cfa68a

on Testnet ALTZ PO confirmed same issue on CentOS 7.x

cardano-cli query stake-snapshot --testnet-magic<PHONE_NUMBER> --stake-pool-id xxxxxx    has similar issue on Testnet as well. Runs out of memory, or if you have the 60GB ram or so that it needs, some errors start showing as well.

And to add, somebody just mentioned they had a problem with ledger when restarting a node, similar message:
"cardano.node.ChainDB:Error:5] [2022-07-04 20:26:44.93 UTC] Invalid snapshot DiskSnapshot {dsNumber = 62523736, dsSuffix = Nothing}InitFailureRead (ReadFailed (DeserialiseFailure 31045716 "Decoding TxIx: too many bytes."))"

Same problem.
Command failed: query leadership-schedule  Error: Failed to successfully decode the current epoch state: DecoderErrorDeserialiseFailure "EpochState (BabbageEra StandardCrypto)" (DeserialiseFailure 31553459 "Decoding TxIx: too many bytes.")

62523736

This one will fix leadership-schedule for babbage era
https://github.com/input-output-hk/cardano-node/pull/4106

Resolved in https://github.com/input-output-hk/cardano-node/pull/4106


small window for pudb

Does pudb interactive debugger compatible with sacred library?
I encounter problem of small window while using pudb with sacred.

Hmm, not sure. I have never used pudb.
I suspect this might be a side-effect of stdout-capturing. You could try to run with both debug mode -d and disable the stdout capturing -C no.

I found problem.
My mistake was to use
ex.captured_out_filter = sacred.utils.apply_backspaces_and_linefeeds
in my code

@dmitrysarov , can you close this issue if it's resolved? thanks.


FreeBSD : SIGFPE on changing fonts

Description
SIGFPE on startup related to fonts:
Environment

Contour Version or Git commit hash: 8e6591605764acee4282b9761bc822fad76b845e
Operating System (name / distribution / version): FreeBSD triton.herrhotzenplotz.geek 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #6 releng/13.0-n244760-940681634ee: Wed Oct 20 16:21:16 CEST 2021     nico@triton.herrhotzenplotz.geek:/usr/obj/usr/src/amd64.amd64/sys/TRITON13  amd64
Contour configuration: change font to 'JetBrains Mono' or 'Termingus'
TERM environment variable: xterm-256color
Compiler version:

nico@triton:~/src/contour $ cc --version
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
nico@triton:~/src/contour $

Steps to Reproduce
Change the font to anything other than the default 'monospace'.
You get a deep stacktrace which isn't helpful at all.
Issue seems to be in open_shaper.cpp:402 (int computeAverageAdvance(FT_Face _face) noexcept):
FT_Get_Char_Index(_face, i) never returns an ok code leaving the maxAdvance at 0 causing divisions by zero later.
No idea what's going here, but seems to be related to Freetype2.

Just as a side note, the error code from freetype is very creative : 0xdb. Upon which FT_Error_String returns a null pointer.

Looking at this (https://github.com/golang/freetype/blob/e2365dfdc4a05e4b8299a783240d4a7d5a65d4e4/truetype/opcodes.go#L231) it makes sense why it's null pointer


Usage of Windows Cryptography Next Generation

I'm developing an ASP.NET API on macOS and I'm running it on Linux. When trying to push a notification I'm receiving an exception that WinCNG is not supported.
Is there a way I can work around this somehow?

@eimantas which version of the package do you use?

It's 2.0.1 from nuget.org

@eimantas yes apparently I still have CngKey.Import call for Apple sender. Not exactly sure how to get rid of it atm.

@eimantas I asked a question on stackoverflow. Let's see if we get some help on this https://stackoverflow.com/questions/58856658/cngkey-import-fails-on-linux-and-macos

Thanks for your efforst! Have an upvote ;)

@eimantas I've just released version 2.1.0 targeting netstandard2.1 with new cryptography and without WinHttpHandler. It should be working on Mac and Linux now. Would you be able to test it?