Name resolution failing on Docker 1.10.1 with Weave

DNS name resolution from weave is failing from docker host in new version of docker v1.10.1 and weave 1.4.4.
Probably related to these two issues https://github.com/docker/docker/issues/20026 & https://github.com/weaveworks/weave/issues/1266
Docker Info
[root@dockerHostCentOS7 ~]# docker info
Containers: 6
 Running: 5
 Paused: 0
 Stopped: 1
Images: 53
Server Version: 1.10.1
Storage Driver: btrfs
 Build Version: Btrfs v3.19.1
 Library Version: 101
Execution Driver: native-0.2
Logging Driver: json-file
Plugins:
 Volume: local
 Network: weavemesh null host bridge
Kernel Version: 3.10.0-229.11.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.066 GiB
Name: dockerHostCentOS7.localdomain
ID: FLAE:CNQB:JWSU:AJGO:SFQJ:4C3A:PPZS:RKBD:MFPA:AMTW:GBT7:XBGG
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Docker Version
[root@dockerHostCentOS7 ~]# docker version
Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   9e83765
 Built:        Thu Feb 11 19:18:46 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.5.3
 Git commit:   9e83765
 Built:        Thu Feb 11 19:18:46 2016
 OS/Arch:      linux/amd64

Docker Host
[root@dockerHostCentOS7 ~]# more /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
[root@dockerHostCentOS7 ~]# uname -a
Linux dockerHostCentOS7.localdomain 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Weave Status
[root@dockerHostCentOS7 ~]# weave status

        Version: 1.4.4

        Service: router
       Protocol: weave 1..2
           Name: e2:9c:7d:29:87:08(dockerHostCentOS7.localdomain)
     Encryption: disabled
  PeerDiscovery: enabled
        Targets: 0
    Connections: 0
          Peers: 1
 TrustedSubnets: none

        Service: ipam
         Status: ready
          Range: <IP_ADDRESS>-<IP_ADDRESS>
  DefaultSubnet: <IP_ADDRESS>/12

        Service: dns
         Domain: weave.local.
       Upstream: <IP_ADDRESS>, <IP_ADDRESS>
            TTL: 1
        Entries: 2

        Service: proxy
        Address: unix:///var/run/weave/weave.sock

        Service: plugin
     DriverName: weave

Firewalld is disabled and selinux is set to enforcing
[root@dockerHostCentOS7 ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
[root@dockerHostCentOS7 ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28
[root@dockerHostCentOS7 ~]#

How to reproduce
[root@dockerHostCentOS7 ~]# weave ps
weave:expose e2:9c:7d:29:87:08
[root@dockerHostCentOS7 ~]# eval $(weave env)
[root@dockerHostCentOS7 ~]# docker run -dti --name n1 busybox:latest sh
0c6a8651b12bf8755e4afc01175d60217a61d4b717fc0e7458565d6922f27061
[root@dockerHostCentOS7 ~]# docker run -dti --name n2 busybox:latest sh
fa5ddf0483918109514be58590a6931c44fee04e3748db635050a1393a3a087d
[root@dockerHostCentOS7 ~]#
[root@dockerHostCentOS7 ~]# ping -c2 twitter.com
PING twitter.com (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=54 time=260 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=54 time=260 ms

--- twitter.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1212ms
rtt min/avg/max/mdev = 260.048/260.311/260.574/0.263 ms
[root@dockerHostCentOS7 ~]#

Ping works from docker host with container IP and not with host name
[root@dockerHostCentOS7 ~]# docker inspect -f '{{ json .NetworkSettings.IPAddress }}' n1
"<IP_ADDRESS>"
[root@dockerHostCentOS7 ~]# docker inspect -f '{{ json .NetworkSettings.IPAddress }}' n2
"<IP_ADDRESS>"
[root@dockerHostCentOS7 ~]# ping -c2 "<IP_ADDRESS>"
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.160 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.111 ms

--- <IP_ADDRESS> ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.111/0.135/0.160/0.027 ms
[root@dockerHostCentOS7 ~]# ping -c2 "<IP_ADDRESS>"
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.110 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.108 ms

--- <IP_ADDRESS> ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.108/0.109/0.110/0.001 ms
[root@dockerHostCentOS7 ~]#
[root@dockerHostCentOS7 ~]# weave ps n1
n1 b6:2f:82:21:3b:7a <IP_ADDRESS>/12
[root@dockerHostCentOS7 ~]# weave ps n2
n2 96:32:2c:f5:2f:78 <IP_ADDRESS>/12
[root@dockerHostCentOS7 ~]# ping n1
ping: unknown host n1
[root@dockerHostCentOS7 ~]# ping n2
ping: unknown host n2
[root@dockerHostCentOS7 ~]# ping n2.weave.local
ping: unknown host n2.weave.local

Ping works from inside container with hostname
/ # hostname
n1.weave.local
/ # ping -c3 n1
PING n1 (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: seq=0 ttl=64 time=0.098 ms
64 bytes from <IP_ADDRESS>: seq=1 ttl=64 time=0.196 ms
64 bytes from <IP_ADDRESS>: seq=2 ttl=64 time=0.122 ms

--- n1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.098/0.138/0.196 ms
/ # ping n2
PING n2 (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: seq=0 ttl=64 time=0.354 ms
64 bytes from <IP_ADDRESS>: seq=1 ttl=64 time=0.158 ms
64 bytes from <IP_ADDRESS>: seq=2 ttl=64 time=0.111 ms
^C
--- n2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.111/0.207/0.354 ms

/ # ping -c5 <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: seq=0 ttl=64 time=0.246 ms
64 bytes from <IP_ADDRESS>: seq=1 ttl=64 time=0.123 ms
64 bytes from <IP_ADDRESS>: seq=2 ttl=64 time=0.123 ms
64 bytes from <IP_ADDRESS>: seq=3 ttl=64 time=0.123 ms
64 bytes from <IP_ADDRESS>: seq=4 ttl=64 time=0.124 ms

--- <IP_ADDRESS> ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.123/0.147/0.246 ms
/ #
/ #
/ #
/ # ping -c5 <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: seq=0 ttl=64 time=0.150 ms
64 bytes from <IP_ADDRESS>: seq=1 ttl=64 time=0.155 ms
64 bytes from <IP_ADDRESS>: seq=2 ttl=64 time=0.194 ms
64 bytes from <IP_ADDRESS>: seq=3 ttl=64 time=0.150 ms
64 bytes from <IP_ADDRESS>: seq=4 ttl=64 time=0.146 ms

--- <IP_ADDRESS> ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.146/0.159/0.194 ms

/ # ping -c2 n2.weave.local
PING n2.weave.local (<IP_ADDRESS>): 56 data bytes
64 bytes from <IP_ADDRESS>: seq=0 ttl=64 time=0.106 ms
64 bytes from <IP_ADDRESS>: seq=1 ttl=64 time=0.152 ms

--- n2.weave.local ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.106/0.129/0.152 ms

DNS name resolution from weave is failing from docker host in new version of docker v1.10.1 and weave 1.4.4.

Does it work for you with older versions of Docker (or weave)?

Probably related to these two issues docker/docker#20026 & #1266

Yes. Though note that docker's DNS is not in use in your example - it only gets enabled when using docker's network commands to attach containers to custom networks. So really this just looks like #1266...
The resolution to #1266 was that we issue warnings on weave launch when detecting iptable rules that break weaveDNS. Did you get that warning on weave launch?

No, there was no warning message from weave launch
After a very long time attempting something with weave, so I am not sure if it worked before.
Probably that is the expected behaviour, But earlier i didn't have to disable firewalld

WARNING: bridge-nf-call-iptables is disabled

That is suspicious.
Anyway, it turns out I completely misread your problem report...

Ping works from docker host with container IP and not with host name

That is expected. Making this work requires changing the host's name resolution, which is a far too intrusive step for weave to perform.

In that case, I guess we can close this issue.


Optimize active products (improves navigation performance)

This PR makes further optimisations to improve navigation performance - primarily optimising the behaviour of the activeProducts getter in the store.
Essentially, rather than always check whether every product is active, we more intelligently only check the top-level products for the app bar and the root products and its child products in the side nav.
Note, this improves performance, so there were a couple of areas where race conditions mean that things worked, where as with the improved performance, they don't.
On note is the call to onEnter - KubeWarden uses this and access the cluster store, but this was being called before loadCluster was called, so cluster schemas were not available.

Investigated the issue where refreshing whilst in the KubeWarden extension causes a schema not found error

auth middleware loads management store --> extension onEnter --> loads cluster store
the KW onEnter makes a request to cluster resources before cluster store loaded and throws an schema not found error

This does not happen in master

auth middleware --> setProduct --> currentProduct --> type-map/activeProducts --> "rootGetters${ module }/all" --> mutations.registerType(state, type) will create a cluster store schema section (before load cluster store)
when KW onEnter then tries to find a schema the cluster schema section exists so no error is thrown

The optimisation in this PR means currentProduct does not call activeProducts and thus the cluster store doesn't get a schema section by the time KW onEnter calls it. TBH this worked by luck, we shouldn't initialise cluster store stuff before the cluster store is set up, and probably need to update kw onEnter given onEnter does not have access to the cluster (we could improve onEnter to handle both post mgmt store and cluster store setup... or improve notifications of this type so extensions can react to other parts of auth middleware process... or something better).

Once Vue3 is landed, we should revisit if this is required.


Empty files report FILE_ERROR

One could argue that empty files are useless - more than fair enough. However, then we should have a proper rule/description for them - something like: AVOID_EMPTY_FILES with appropriate messages. FILE_ERROR looks more like an actual problem parsing empty files.
<issue severity="ERROR" id="FILE_ERROR" message="FILE_ERROR" category="CFLint" abbrev="FE"><location file="/Users/kai/Documents/Code/.../fusebox.appinit.cfm" fileName="fusebox.appinit.cfm" function="" column="1" line="1" message="" variable=""><Expression><![CDATA[]]></Expression></location>
</issue>

TCO.  Thanks @TheRealAgentK

Works as expected for me now, too!

@ryaneberly I added AVOID_EMPTY_FILES to
https://github.com/cflint/CFLint/wiki/Built-In-Rules
and
https://github.com/cflint/CFLint/wiki/Rule-Groups
Not sure if they're in the right place, could you please double-check (and in "Built In Rules" put it into the proper category)? Just wanted to make sure that the rule is documented somewhere in the first place.


endpoint: node-publication

const params = { db: "pubmed", retmode: "json", id: ids.join(",") };
const url = ${entrez}/esummary.fcgi;
const { result } = await request<_Summary>(url, params);
--
const params = { db: "pubmed", retmode: "text", rettype: "abstract", id };
const url = ${entrez}/efetch.fcgi;
return await request(url, params, {}, "text");

Since this doesn't call biolink api, I don't think we have any changes to make


Fixed #21936 -- Refactored DeleteView to be compatibale with SuccessMessageMixin

docs and release notes remain

@timgraham needs your kind review and after fixing from review how would I squash all commits in a single commit?

buildbot, add to whitelist.

Can you get the tests passing?

Closing due to inactivity.

@auvipy @timgraham
I realise this has been closed due to inactivity, but should it pick up again it's got a :+1: from me (as a Django user).  We've seen the effect of not having this in several places and although it is easy to workaround it would be nice for the functionality to be innate.  Cheers!

@lskillen yeah!!! but sorry I couldnt manage time to complete the pr! but will resend again!

running messages_tests gives the follwing error
File "/usr/lib/python3.4/multiprocessing/reduction.py", line 50, in dumps
cls(buf, protocol).dump(obj)
_pickle.PicklingError: Can't pickle <class 'unittest.loader.ModuleImportFailure'>: attribute lookup ModuleImportFailure on unittest.loader failed

and generic_views tests give following
File "/home/asif/dj/tests/generic_views/test_edit.py", line 432, in test_delete_with_form_as_post
self.assertRedirects(res, 'http://testserver/list/authors/')
File "/home/asif/dj/django/test/testcases.py", line 315, in assertRedirects
RemovedInDjango20Warning, stacklevel=2)
django.utils.deprecation.RemovedInDjango20Warning: assertRedirects had to strip the scheme and domain from the expected URL, as it was always added automatically to URLs before Django 1.9. Please update your expected URLs by removing the scheme and domain.

Ran 203 tests in 3.821s
FAILED (errors=1)

@auvipy Please pick this up again. Would be good to have this implemented.

@bittner yes I am reopening it again within 2-3 days :)

Status report?

https://github.com/django/django/pull/8138 this was the last update. you could give some feed back or take over if interested


updated the 404 Readmi and programming languages readmi

removed the message from 404.md and added the detailed in it
Programming language/READMe.md

added definition of programing language  --previously missing
added assembly to the list of languages
removed c, cpp ,c# as they are backend scripting languages and not true scripting languages --can cause confusion for beginners
added bash ruby and pearl instead
added section for markup languages, styling languages, and Generation of programming languages with examples
also added some example code where they are missing

@shhossain sir hope it looks good

@shhossain thanks
dont know how but i was not seeing any messages here


Implement ReadWriteAction using new interface

Issue #, if available:
NA
Description of changes:
Implement ReadOnlyAction using new interface
CheckList:

[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #228 (73ff8cf) into development-extension (715ae2b) will increase coverage by 0.28%.
The diff coverage is 89.79%.

@@                     Coverage Diff                     @@
##             development-extension     #228      +/-   ##
===========================================================
+ Coverage                    60.08%   60.37%   +0.28%
- Complexity                    1322     1338      +16
===========================================================
  Files                          249      249
  Lines                         9386     9426      +40
  Branches                      1441     1444       +3
===========================================================
+ Hits                          5640     5691      +51
+ Misses                        3066     3055      -11
  Partials                       680      680

Impacted Files
Coverage Δ

...ent/indexstatemanagement/action/ReadWriteAction.kt
83.33% <75.00%> (+83.33%)
:arrow_up:

...statemanagement/step/readwrite/SetReadWriteStep.kt
89.47% <89.18%> (+89.47%)
:arrow_up:

...anagement/indexstatemanagement/ISMActionsParser.kt
77.14% <100.00%> (+0.67%)
:arrow_up:

...dexstatemanagement/action/ReadWriteActionParser.kt
100.00% <100.00%> (+100.00%)
:arrow_up:

...anagement/indexstatemanagement/model/Transition.kt
16.90% <0.00%> (-1.41%)
:arrow_down:

...earch/indexmanagement/transform/model/Transform.kt
86.00% <0.00%> (-1.00%)
:arrow_down:

.../opensearch/indexmanagement/rollup/model/Rollup.kt
83.96% <0.00%> (+0.47%)
:arrow_up:

...rch/indexmanagement/rollup/model/RollupMetadata.kt
84.52% <0.00%> (+1.78%)
:arrow_up:

...t/indexstatemanagement/model/ManagedIndexConfig.kt
77.14% <0.00%> (+2.85%)
:arrow_up:

... and 2 more

Continue to review full report at Codecov.

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


chore(deps): update module cloud.google.com/go/secretmanager to v1.13.6

This PR contains the following updates:

Package
Type
Update
Change

cloud.google.com/go/secretmanager
require
patch
v1.13.5 -> v1.13.6

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

ℹ Artifact update notice
File name: go.mod
In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

6 additional dependencies were updated

Details:

Package
Change

golang.org/x/oauth2
v0.21.0 -> v0.22.0

google.golang.org/api
v0.189.0 -> v0.191.0

cloud.google.com/go/auth
v0.7.2 -> v0.8.0

github.com/google/s2a-go
v0.1.7 -> v0.1.8

golang.org/x/sync
v0.7.0 -> v0.8.0

golang.org/x/time
v0.5.0 -> v0.6.0


[SPARK-46120][CONNECT][PYTHON] Remove helper function DataFrame.withPlan

What changes were proposed in this pull request?
Remove helper function DataFrame.withPlan
Why are the changes needed?
this helper function just invoke the constructor, should be redundant
    @classmethod
    def withPlan(cls, plan: plan.LogicalPlan, session: "SparkSession") -> "DataFrame":
        """
        Main initialization method used to construct a new data frame with a child plan.
        This is for internal purpose.
        """
        return DataFrame(plan=plan, session=session)

Does this PR introduce any user-facing change?
no
How was this patch tested?
ci
Was this patch authored or co-authored using generative AI tooling?
no

thanks @itholic @HyukjinKwon for reviews


Unexpected behavior: able to click while scrolling on iOS 10 (probably lower versions as well...)

There's an unexpected behavior with "fastclick"--that is you are able to register click events when scrolling. This is bad because it has the potential to break people's external scripts (as it continually breaks my code).

Interesting. But is fastclick really needed in iOS 10? My preliminary studies shows that a part of a mobile site i'm working with suddenly is quick even without fastclick. But the issue you're mentioning is happening, but only with the Fullcalendar script. I suspected fastclick, but even without it, it's still happening. So it's very weird..


Block rendering and clickability

Expected behavior: Clicking anywhere on a module in the statusbar should run the corresponding command.
Actual behavior: The rendering of the modules seem to be affected by the status2d patch. This in turn also affects the clickability of the modules. There seems to be some kind of off-set of where the modules are drawn and where you can click. This makes it hard to predict what module you actually clicked.
A side effect of this is also that the names of the colors in the statusbar scripts are counted towards the character limit of a module. As a temporary fix modules have a 100 char length limit as opposed to the default 50.

Further investigation shows that right-clicking can cause modules to disappear shortly. Left-clicking will sometimes move the module slightly.

Maybe this is not caused by status2d, but rather the way dwmblocks is handling signals. When modules are clicked, other modules might disappear and reload when they are updated, either by interval update or signal update.

The clickability issue seems to be related to the systray. However, even with nothing in the systray, it seems like you can still click a little to the right of the modules.

Fixed the issue of modules being drawn in the wrong place. This had to do with the systray patch. See https://github.com/askeko/dwm/commit/e3e130c2080a30faad091281e135ea25045c0deb

Regarding the disappearance and rendering of modules it also seems like if I spam too many signals (like holding down super+ + for increasing volume), it also makes modules disappear/reappear.


Errno::E2BIG: Arg list too long

Hey guys,
Recently I've been working in a C project that has a long folder structure. With that, in my first compilation attempt, I got the error "Errno::E2BIG: Arg list too long" due to the big include argument list generated for the project.
My question is: Have you already faced it? How did you manage to solve that?
I was thinking in some kind of tool to generate the include arguments and then pass to the GCC (compiler that I'm using). But it would require a new process on the building system to generate the includes file.
What do you think?

@mvandervoord help me out here! Is there any solution already done for that?

Maybe not related, but I wonder how linux does it... The link list is probably really long, so there might be some trick to avoid that.
Are you using windows? Is that error message from Ruby?

Maybe not related, but I wonder how linux does it... The link list is probably really long, so there might be some trick to avoid that.
Are you using windows? Is that error message from Ruby?

Yes I'm using windows.
I'm no really sure, but I'm guessing that this is an issue from the command prompt. It happens right after the ruby calls the entire command with gcc.exe and its arguments, including the very long include directories.

Can you count number of arguments you have, and we can maybe get a limit?

I think it's less about the number of arguments and more about total line length? (which is 8191 characters on Windows)

Yes, the point is that since the start of the command "gcc.exe" until the end of it with "-DTEST -DGNU_COMPILER", the complete command has almost 37.815 characters.
So, I see that this can be a pretty common issue to the tool. It's not too hard to find big projects on the industries and other applications, that could easily overflow the 8191 digits.
Any thoughts on how to solve that?
From my side, I'm trying to modify the ceedling in other to not pass the include directories through the command line, but by the environment variable 'CPATH' that could be a possibility to the GCC, but it doesn't seem like a global solution for other compilers.
Let me know your comments!

is that what most of the characters are in your setup? include directories?

Yes, the biggest part of the characters comes from the include directories.

Any suggestion on that guys?

I've hit this before on linux when having globs in paths with a lot of directories. My gut is that we can give a smarter error for this, but it would take some edge testing. If you can trim down your include paths to be more specific it would take care of itself, but I agree ceedling should be a bit smarter and give a better error message.

I have the same issue trying to use ceedling for an embedded linux project. All of the includes generate a line that is 200K characters long.
Have you found a solution for this? Is there a way to keep my includes and run ceedling?

Hi, I'm in a similar situation, which I didn't account for when establishing ceedling for a big project.
Additionally to what has been said in this issue, I observed that the whole list of all the values defined in the :paths: variable in the project.yml file, are always included in all the operations with gcc, regardless if they pertain to the test or not.
For example, let's say that we have two test files in different folders

driver1/unit_test/test_driver1.c
driver2/unit_test/test_driver2.c

And a file structure such as:
.
├── driver1
│   ├── inc
│   ├── src
│   └── unit_test
├── driver2
│   ├── inc
│   ├── src
│   └── unit_test

Where the inc and src folders contain the .h and .c files, as you might expect.
Let's say that both drivers are completely independent of each other, they don't requiere headers from each other.
with a project.yml file such as
:paths:
  :tests:
    - driver1/unit_test
    - driver2/unit_test
  :source:
    - driver1/src
    - driver2/src
  :include:
    - driver1/inc
    - driver2/inc

When running ceedling verbosity[4] test:all I found that for each test ran, the preprocess/compilation/linker steps all have the whole list of includes (omitting other gcc options):
gcc.exe ... -I"driver1/inc" -I"driver1/src" -I"driver1/unit_test" -I"driver2/inc" -I"driver2/src" -I"driver2/unit_test" ... test_driver1.c
Even though test_driver1 does not need all the includes from driver2, but it does anyway.
This of course, does not affect in small projects, but on bigger ones, as some of you folks have mentioned, provoking the Errno::E2BIG error.
I was trying the CPATH approach by @beckerzito, but had no success so far.
Have any of you reached a solution or a workaround to this predicament?
This issue seems to be more related to the way Ceedling organizes all the include paths in every operation it makes, so I think it is a more fundamental problem that we might think at first.
If there is no known workaround, do you guys have any proposal or idea on how we could implement a way in which only certain paths are included exclusively for certain tests.
I would really appreciate your help. I'll keep trying to find a work around in the meantime.
Thank you!

I suggest you make two separate projects (yml files).  It's easy to switch between projects.

I am trying to use ceedling to build and run units tests for an esp32 project. The esp-idf/components/ directory has 2651 directories, 15354 files some of which are include files needed to build or at least be mocked.
I also get the "Errno::E2BIG: Arg list too long" if I try to include the esp-idf/components directory, and this is when building on the throwtheswitch docker image of ubuntu.
I tried to narrow it down a bit (see code snippet below) but still end up with "no such file or directory" type errors. Has anyone successfully solved this issue or can point me to an example of building unit tests for esp32 with ceedling? I don't need to use the esp-idf toolchain to build for target within ceedling, my plan is to keep unit tests on the host via ceedling and target builds via esp-idf. I don't want to use espressif's half baked linux example either. Thanks!
if it helps this is what my project.yml is turning into
    - +:/esp-idf/*/include/**
    # the below shouldn't be necessary but "ceedling files:include" output shows they are omitted if not included explicitly...
    - +:/esp-idf/esp_system/include/*
    - +:/esp-idf/esp_common/include/*
    - +:/esp-idf/soc/**

I'm disappointed this still isn't fixed. It seems like it's probably pretty common for anyone using larger projects in windows with it's long paths.
Trying the work around. But the silence on the issues here is really a bummer.

This is not a Ceedling problem - this is Windows problem.
You have some workarounds on top, but I think best advice is: switch to Linux. Much more developer friendly.

@Letme, really? that's not very helpful on your part.
The error itself is from GCC itself, not windows, although the windows build of GCC might be more susceptible to it, some folks on this very thread said that this has happened also on linux, and on the following issue it is reported for linux as well: https://github.com/ThrowTheSwitch/Ceedling/issues/480
The main reason this happens is the way ceedling takes every single path in the .yaml configuration and appends it to every single compilation step for every single file, which may be unnecessary for most of the test files.
It is a fundamental issue on how ceedling works, but a proper solution might be quite cumbersome to produce, to only include the necessary -I paths on each compilation step (I'm not really an expert on the project, take that with a grain of salt).
@jnz86 were you able to solve the issue with the workaround?

Yes and No.
I used the exact workaround and still had the error, but before double checking anything. I realized that Ceedling was compiling very slowly, so I removed the all inclusive source line from my project. I much more narrowly include files now, its faster and I'm no longer at the limit.
However, I agree with you that this isn't really a solution and if I keep using this I'll hit the limit again. I've kicked the can down the road a little bit.
The workaround may be flawless and I messed up somewhere else. I have at least two installs of Ruby and both have Ceedling.


Or against two fields returns incorrect result when some values not present

If you have two fields a and b on measurement foo. Then you have points where a is set or both a and b are set or just b is set. When you have filters in the WHERE clause on those fields, the results returned will be incorrect.
To reproduce and see behavior in the CLI:
> create database test
> use test
Using database test
> insert foo a=3
> insert foo a=2,b=5
> insert foo a=4
> insert foo b=3
> select * from foo
name: foo
time                a b
----                - -
1491340640166342532 3
1491340650223407506 2 5
1491340661844277686 4
1491340665602537847   3
> select * from foo where a > 2
name: foo
time                a b
----                - -
1491340640166342532 3
1491340661844277686 4
> select * from foo where a > 2 or b > 3
name: foo
time                a b
----                - -
1491340650223407506 2 5
>

Notice that the last query select * from foo where a > 2 or b > 3 should have returned three records:
time                a b
----                - -
1491340640166342532 3
1491340650223407506 2 5
1491340661844277686 4

The a records that matched the where clause weren't present because b wasn't there. Similarly, if we had asked for a > 2 or b > 2 it leaves out the record where b is set to 3 and a isn't set.

This issue brings up a more broad question about how null should be handled, especially in boolean expressions. I think previously we have not implicitly cast null to false and that's what has created the current behavior. At the moment, this isn't really defined very well so there's a bunch of inconsistency. For example, looking at the code, null OR true will return null and true OR null will return false. Obviously, that's incorrect. But should we be implicitly casting null to false for boolean expressions and maybe more? It would certainly make the logic a lot easier to deal with.
The comparison operators are likely less controversial, but what happens when you have something like false = null?

We could either have null evaluate to false, or like Go we could have it evaluate to whatever the zero value is. In the case of the numeric comparisons I had above, they would return the same results, which would be correct and not the current behavior.
Even if we don't evaluate null to some value, it still doesn't make sense that null > 2 OR 3 > 2 would evaluate to null. The left hand would be false because null isn't greater than 2 and the right hand would be true so the entire statement should evaluate to true.

Hm, I'm not sure I'm in favor of the zero value thing since, while I like it in Go, it does produce some problems in that the empty string is different than the string not being present. At the same time, we have no way to check for the difference anyway and missing tag values are treated as if they were the empty string so that might be more consistent for fields too.
I agree that comparisons do seem like they are different. As a side note, we do not appear to support comparison operators for strings, but we also don't produce any message that indicates that's why it failed.

Ok, so I guess in the context of expression evaluation, null should evaluate to false unless we later add an expression is null or = null.
I logged #8265 for the string issue.


add better error message when the tableinfo method return too much info

I did this PR because the current error message (a 400 from the API) is not really helping to debug and I was asked for help to debug this kind of error on discord.

The python error message is a bit better but we could also back port this in the python version. ping @hwchase17

The new error message looks like this.

Thanks!


Show publication date at beginnig of blog entry

In general it is common for (news) articles to display their publication date at the beginning so that it's clear to the reader whether that content might actually still be relevant or not.
We do have a thing at the end for last updated

But something that says "published on" would be nice. Would put it somewhere like here:

Addressed with 05a4966a83c2a7eafd90b4c22c3e12953ded5880.

Confirmed :D


More multi clock 2

Minor update for multi-clock
removes older ignored test
uses annotations to control test

Oops, had a fix, just pushed it now.

Added fixes to dangling commas


ERROR SYNCING

i've got new instances and cant make it work. Im getting an error when sync:
ive got two server:
1: BareMetal - adguard primary(origin)
2: CasaOS where docker is installed. (replica)
both srv are in different Vlans but connection is wokring between those vlans.
ERROR:
2022-12-04T17:37:02.157Z	INFO	root	cmd/root.go:118	Using config file:/config/adguardhome-sync.yaml
2022-12-04T17:37:02.158Z	INFO	sync	sync/sync.go:29	AdGuardHome sync	{"version": "v0.4.10", "build": "2022-11-18T17:51:40Z"}
2022-12-04T17:37:02.158Z	INFO	sync	types/features.go:70	Disabled features	{"features": ["DHCP.ServerConfig", "DHCP.StaticLeases"]}
2022-12-04T17:37:02.158Z	INFO	sync	sync/sync.go:55	Setup cronjob	{"cron": "*/1 * * * *", "next-execution": "2022-12-04T17:38:00.000Z"}
2022-12-04T17:37:02.158Z	INFO	sync	sync/http.go:52	Starting API server	{"port": 443}
2022-12-04T17:37:02.159Z	INFO	sync	sync/sync.go:65	Running sync on startup
2022-12-04T17:37:02.305Z	INFO	sync	sync/sync.go:113	Connected to origin	{"from": "<IP_ADDRESS>:443", "version": "v0.107.19"}
2022-12-04T17:37:03.844Z	INFO	sync	sync/sync.go:196	Start sync	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000"}
2022-12-04T17:37:33.863Z	ERROR	sync	sync/sync.go:200	Error getting replica status	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000", "error": ": Get "http://<IP_ADDRESS>:3000/control/status\": dial tcp <IP_ADDRESS>:3000: i/o timeout"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/go/src/app/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(worker).sync
/go/src/app/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func3
/go/src/app/pkg/sync/sync.go:66
2022-12-04T17:37:59.332Z	INFO	root	cmd/root.go:118	Using config file:/config/adguardhome-sync.yaml
2022-12-04T17:37:59.333Z	INFO	sync	sync/sync.go:29	AdGuardHome sync	{"version": "v0.4.10", "build": "2022-11-18T17:51:40Z"}
2022-12-04T17:37:59.333Z	INFO	sync	types/features.go:70	Disabled features	{"features": ["DHCP.ServerConfig", "DHCP.StaticLeases"]}
2022-12-04T17:37:59.333Z	INFO	sync	sync/sync.go:55	Setup cronjob	{"cron": "/1 * * * *", "next-execution": "2022-12-04T17:38:00.000Z"}
2022-12-04T17:37:59.333Z	INFO	sync	sync/http.go:52	Starting API server	{"port": 3000}
2022-12-04T17:37:59.333Z	INFO	sync	sync/sync.go:65	Running sync on startup
2022-12-04T17:37:59.480Z	INFO	sync	sync/sync.go:113	Connected to origin	{"from": "<IP_ADDRESS>:443", "version": "v0.107.19"}
2022-12-04T17:38:00.001Z	INFO	sync	sync/sync.go:87	Sync already running
2022-12-04T17:38:01.001Z	INFO	sync	sync/sync.go:196	Start sync	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000"}
2022-12-04T17:38:31.003Z	ERROR	sync	sync/sync.go:200	Error getting replica status	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000", "error": ": Get "http://<IP_ADDRESS>:3000/control/status\": dial tcp <IP_ADDRESS>:3000: i/o timeout"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/go/src/app/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/go/src/app/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func3
/go/src/app/pkg/sync/sync.go:66
2022-12-04T17:39:00.195Z	INFO	sync	sync/sync.go:113	Connected to origin	{"from": "<IP_ADDRESS>:443", "version": "v0.107.19"}
2022-12-04T17:39:01.698Z	INFO	sync	sync/sync.go:196	Start sync	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000"}
2022-12-04T17:39:31.699Z	ERROR	sync	sync/sync.go:200	Error getting replica status	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000", "error": ": Get "http://<IP_ADDRESS>:3000/control/status\": dial tcp <IP_ADDRESS>:3000: i/o timeout"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/go/src/app/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/go/src/app/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func2
/go/src/app/pkg/sync/sync.go:49
github.com/robfig/cron/v3.FuncJob.Run
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:136
github.com/robfig/cron/v3.(*Cron).startJob.func1
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:312
2022-12-04T17:40:00.161Z	INFO	sync	sync/sync.go:113	Connected to origin	{"from": "<IP_ADDRESS>:443", "version": "v0.107.19"}
2022-12-04T17:40:01.650Z	INFO	sync	sync/sync.go:196	Start sync	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000"}
2022-12-04T17:40:31.657Z	ERROR	sync	sync/sync.go:200	Error getting replica status	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000", "error": ": Get "http://<IP_ADDRESS>:3000/control/status\": dial tcp <IP_ADDRESS>:3000: i/o timeout"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/go/src/app/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/go/src/app/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func2
/go/src/app/pkg/sync/sync.go:49
github.com/robfig/cron/v3.FuncJob.Run
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:136
github.com/robfig/cron/v3.(*Cron).startJob.func1
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:312
2022-12-04T17:41:00.182Z	INFO	sync	sync/sync.go:113	Connected to origin	{"from": "<IP_ADDRESS>:443", "version": "v0.107.19"}
2022-12-04T17:41:01.697Z	INFO	sync	sync/sync.go:196	Start sync	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000"}
2022-12-04T17:41:31.699Z	ERROR	sync	sync/sync.go:200	Error getting replica status	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000", "error": ": Get "http://<IP_ADDRESS>:3000/control/status\": dial tcp <IP_ADDRESS>:3000: i/o timeout"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/go/src/app/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/go/src/app/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func2
/go/src/app/pkg/sync/sync.go:49
github.com/robfig/cron/v3.FuncJob.Run
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:136
github.com/robfig/cron/v3.(*Cron).startJob.func1
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:312
2022-12-04T17:42:00.176Z	INFO	sync	sync/sync.go:113	Connected to origin	{"from": "<IP_ADDRESS>:443", "version": "v0.107.19"}
2022-12-04T17:42:01.675Z	INFO	sync	sync/sync.go:196	Start sync	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000"}
2022-12-04T17:42:31.676Z	ERROR	sync	sync/sync.go:200	Error getting replica status	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000", "error": ": Get "http://<IP_ADDRESS>:3000/control/status\": dial tcp <IP_ADDRESS>:3000: i/o timeout"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/go/src/app/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/go/src/app/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func2
/go/src/app/pkg/sync/sync.go:49
github.com/robfig/cron/v3.FuncJob.Run
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:136
github.com/robfig/cron/v3.(*Cron).startJob.func1
/go/pkg/mod/github.com/robfig/cron/v3@v3.0.1/cron.go:312
2022-12-04T17:43:00.184Z	INFO	sync	sync/sync.go:113	Connected to origin	{"from": "<IP_ADDRESS>:443", "version": "v0.107.19"}
2022-12-04T17:43:01.679Z	INFO	sync	sync/sync.go:196	Start sync	{"from": "<IP_ADDRESS>:443", "to": "<IP_ADDRESS>:3000"}

I am having the same issue, but I am on the same vlan.
I can reach both of instance's web interfaces, and they both work for dns, but I am getting a destination host unreachable on my replica instance.
I noticed that my origin instance responds to icmp but my replica does not. That should not matter, right?
`To support LSIO projects visit:
https://www.linuxserver.io/donate/
GID/UID
User uid:    99
User gid:    100
[custom-init] No custom files found, skipping...
[ls.io-init] done.
2022-12-04T14:47:48.499-0600    INFO    root    cmd/root.go:118 Using config file:/config/adguardhome-sync.yaml
2022-12-04T14:47:48.501-0600    INFO    sync    sync/sync.go:29 AdGuardHome sync        {"version": "0.4.10", "build": "2022-11-18T17:51:16Z"}
2022-12-04T14:47:48.501-0600    INFO    sync    sync/sync.go:55 Setup cronjob   {"cron": "*/10 * * * *", "next-execution": "2022-12-04T14:50:00.000-0600"}
2022-12-04T14:47:48.502-0600    INFO    sync    sync/http.go:52 Starting API server     {"port": 8080}
2022-12-04T14:47:48.502-0600    INFO    sync    sync/sync.go:65 Running sync on startup
2022-12-04T14:47:48.519-0600    INFO    sync    sync/sync.go:113        Connected to origin     {"from": "<IP_ADDRESS>:853", "version": "v0.107.17"}
2022-12-04T14:47:48.680-0600    INFO    sync    sync/sync.go:196        Start sync      {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000"}
2022-12-04T14:47:51.786-0600    ERROR   sync    sync/sync.go:200        Error getting replica status    {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000", "error": ": Get "http://<IP_ADDRESS>:3000/control/status\": dial tcp <IP_ADDRESS>:3000: connect: no route to host"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func3
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:66
2022-12-04T14:50:00.048-0600    INFO    sync    sync/sync.go:113        Connected to origin     {"from": "<IP_ADDRESS>:853", "version": "v0.107.17"}
2022-12-04T14:50:00.199-0600    INFO    sync    sync/sync.go:196        Start sync      {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000"}
2022-12-04T14:50:03.305-0600    ERROR   sync    sync/sync.go:200        Error getting replica status    {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000", "error": ": Get "http://<IP_ADDRESS>:3000/control/status\": dial tcp <IP_ADDRESS>:3000: connect: no route to host"}`

I was able to solve my issue. Just had to change network type from "Bridge" to "HOST" and then it started to communicate. But there is also a lthing that i had some surces which couldnt be synced cuz source wasnt avaiable anymore - and adguardSync were in loop and didnt wanted to skip that source and try further options :) But i did some cleanup and all is working fine right know :)

I am having the same issue, but I am on the same vlan.
I can reach both of instance's web interfaces, and they both work for dns, but I am getting a destination host unreachable on my replica instance.
I noticed that my origin instance responds to icmp but my replica does not. That should not matter, right?
Also, i am able to browse directly to the link "[http://<IP_ADDRESS>:3000/control/status](http://<IP_ADDRESS>:3000/control/status\)" and see the results, minus the backslash at the end.

To support LSIO projects visit:
https://www.linuxserver.io/donate/
GID/UID
User uid:    99
User gid:    100
[custom-init] No custom files found, skipping...
[ls.io-init] done.
2022-12-04T14:47:48.499-0600    INFO    root    cmd/root.go:118 Using config file:/config/adguardhome-sync.yaml
2022-12-04T14:47:48.501-0600    INFO    sync    sync/sync.go:29 AdGuardHome sync        {"version": "0.4.10", "build": "2022-11-18T17:51:16Z"}
2022-12-04T14:47:48.501-0600    INFO    sync    sync/sync.go:55 Setup cronjob   {"cron": "*/10 * * * *", "next-execution": "2022-12-04T14:50:00.000-0600"}
2022-12-04T14:47:48.502-0600    INFO    sync    sync/http.go:52 Starting API server     {"port": 8080}
2022-12-04T14:47:48.502-0600    INFO    sync    sync/sync.go:65 Running sync on startup
2022-12-04T14:47:48.519-0600    INFO    sync    sync/sync.go:113        Connected to origin     {"from": "<IP_ADDRESS>:853", "version": "v0.107.17"}
2022-12-04T14:47:48.680-0600    INFO    sync    sync/sync.go:196        Start sync      {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000"}
2022-12-04T14:47:51.786-0600    ERROR   sync    sync/sync.go:200        Error getting replica status    {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000", "error": ": Get "[http://<IP_ADDRESS>:3000/control/status](http://<IP_ADDRESS>:3000/control/status\)": dial tcp <IP_ADDRESS>:3000: connect: no route to host"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func3
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:66
2022-12-04T14:50:00.048-0600    INFO    sync    sync/sync.go:113        Connected to origin     {"from": "<IP_ADDRESS>:853", "version": "v0.107.17"}
2022-12-04T14:50:00.199-0600    INFO    sync    sync/sync.go:196        Start sync      {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000"}
2022-12-04T14:50:03.305-0600    ERROR   sync    sync/sync.go:200        Error getting replica status    {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000", "error": ": Get "[http://<IP_ADDRESS>:3000/control/status](http://<IP_ADDRESS>:3000/control/status\)": dial tcp <IP_ADDRESS>:3000: connect: no route to host"}

I am having the same issue, but I am on the same vlan.
I can reach both of instance's web interfaces, and they both work for dns, but I am getting a destination host unreachable on my replica instance.
I noticed that my origin instance responds to icmp but my replica does not. That should not matter, right?
Also, i am able to browse directly to the link "[http://<IP_ADDRESS>:3000/control/status](http://<IP_ADDRESS>:3000/control/status\)" and see the results, minus the backslash at the end.

To support LSIO projects visit:
https://www.linuxserver.io/donate/
GID/UID
User uid:    99
User gid:    100
[custom-init] No custom files found, skipping...
[ls.io-init] done.
2022-12-04T14:47:48.499-0600    INFO    root    cmd/root.go:118 Using config file:/config/adguardhome-sync.yaml
2022-12-04T14:47:48.501-0600    INFO    sync    sync/sync.go:29 AdGuardHome sync        {"version": "0.4.10", "build": "2022-11-18T17:51:16Z"}
2022-12-04T14:47:48.501-0600    INFO    sync    sync/sync.go:55 Setup cronjob   {"cron": "*/10 * * * *", "next-execution": "2022-12-04T14:50:00.000-0600"}
2022-12-04T14:47:48.502-0600    INFO    sync    sync/http.go:52 Starting API server     {"port": 8080}
2022-12-04T14:47:48.502-0600    INFO    sync    sync/sync.go:65 Running sync on startup
2022-12-04T14:47:48.519-0600    INFO    sync    sync/sync.go:113        Connected to origin     {"from": "<IP_ADDRESS>:853", "version": "v0.107.17"}
2022-12-04T14:47:48.680-0600    INFO    sync    sync/sync.go:196        Start sync      {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000"}
2022-12-04T14:47:51.786-0600    ERROR   sync    sync/sync.go:200        Error getting replica status    {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000", "error": ": Get "[http://<IP_ADDRESS>:3000/control/status](http://<IP_ADDRESS>:3000/control/status\)": dial tcp <IP_ADDRESS>:3000: connect: no route to host"}
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).syncTo
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:200
github.com/bakito/adguardhome-sync/pkg/sync.(*worker).sync
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:184
github.com/bakito/adguardhome-sync/pkg/sync.Sync.func3
/home/bakito/go/src/github.com/bakito/adguardhome-sync/pkg/sync/sync.go:66
2022-12-04T14:50:00.048-0600    INFO    sync    sync/sync.go:113        Connected to origin     {"from": "<IP_ADDRESS>:853", "version": "v0.107.17"}
2022-12-04T14:50:00.199-0600    INFO    sync    sync/sync.go:196        Start sync      {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000"}
2022-12-04T14:50:03.305-0600    ERROR   sync    sync/sync.go:200        Error getting replica status    {"from": "<IP_ADDRESS>:853", "to": "<IP_ADDRESS>:3000", "error": ": Get "[http://<IP_ADDRESS>:3000/control/status](http://<IP_ADDRESS>:3000/control/status\)": dial tcp <IP_ADDRESS>:3000: connect: no route to host"}

Well if you are on the same vlan then it should be problem with host firewall. Check your host for it :)


The first node doesn't accept inputs other than InputState, but other nodes can

Checked other resources

[X] I added a very descriptive title to this issue.
[X] I searched the LangGraph/LangChain documentation with the integrated search.
[X] I used the GitHub search to find a similar question and didn't find it.
[X] I am sure that this is a bug in LangGraph/LangChain rather than my code.
[X] I am sure this is better as an issue rather than a GitHub discussion, since this is a LangGraph bug and not a design question.

Example Code
from typing import TypedDict

from langgraph.graph import END, START, MessagesState, StateGraph

class OverallState(MessagesState):
    pass

class InputState(TypedDict):
    question: str

class OutputState(TypedDict):
    answer: str

class PrivateState(TypedDict):
    secret: str

def first(state):
    # Without type hint, the node following `__start__` only accepts
    # `InputState` as the initial input.
    print("=====This is First=====")
    # At this point, the filter will be handled by `OverallState`, not `InputState`.
    print(state)  # {"messages": []}
    return {"answer": "Foo"}

def middle(state):
    # Without a type hint, non the node following `__start__` can accept at least one of
    # `OverallState`, `InputState`, or `OutputState` as input.
    print("=====This is Middle=====")
    print(state)
    # return {"secret": "Bar"}  # ok
    return {"question": "Bar"}

def last(state: PrivateState):
    # With a type hint, it will additionally accept the extra key as a private state input,
    # even if the previous node may not include this input.
    # It will still act as a filter in this function, filtering out inputs that do not match this hint.
    print("=====This is Last=====")
    print(state)
    # Output = {}; Because the output of the previous node doesn't include PrivateState.
    return {"messages": [("human", "World!")]}

graph_builder = StateGraph(OverallState, input=InputState, output=OutputState)

graph_builder.add_node(first)
graph_builder.add_node(middle)
graph_builder.add_node(last)

graph_builder.add_edge(START, first.__name__)
graph_builder.add_edge(first.__name__, middle.__name__)
graph_builder.add_edge(middle.__name__, last.__name__)
graph_builder.add_edge(last.__name__, END)
app = graph_builder.compile()
# print("output: ", app.invoke({"messages": [("human", "Hello")]})) # it will raise an error
print("output: ", app.invoke({"question": "What is your name?"}))

Error Message and Stack Trace (if applicable)
Only the first node doesn't accept three states; the other nodes can accept three states and extended states.

Is this a feature or a bug?
Because it is very inconsistent with the state output in the same function (using `OverallState` as a filter).

Description
Here is my understanding of the states: all nodes can accept OverallState, InputState, and OutputState as inputs, even if you don't include type hints.
If your type hint is not one of the above three, it will be considered an additional acceptable input. However, the previous node output must still include at least one key from these four states.
If you don't include type hints and you input the three states (StateGraph(OverallState, input=InputState, output=OutputState)), the filter will select OverallState.
If you don't include type hints and you input two states (StateGraph(input=InputState, output=OutputState)), the filter will select InputState.
System Info
langgraph==0.2.16
langchain-core==0.2.37
platform==linux
python-version==3.12.5

I think that's correct
from typing import TypedDict, List

from langgraph.graph import END, START, MessagesState, StateGraph

class OverallState(MessagesState):
    pass

class InputState(TypedDict):
    question: str

class OutputState(TypedDict):
    answer: str

class PrivateState(TypedDict):
    secret: str
    answer: str
    question: str

def first(state):
    # Without type hint, the node following `__start__` only accepts
    # `InputState` as the initial input.
    print("=====This is First=====")
    # At this point, the filter will be handled by `OverallState`, not `InputState`.
    print(state)  # {"messages": []}
    return {"answer": "Foo","dui":"65dui"}

def middle(state):
    # Without a type hint, non the node following `__start__` can accept at least one of
    # `OverallState`, `InputState`, or `OutputState` as input.
    print("=====This is Middle=====")
    print(state)
    # return {"secret": "Bar"}  # ok
    return {"question": "Bar"}

def last(state: PrivateState):
    # With a type hint, it will additionally accept the extra key as a private state input,
    # even if the previous node may not include this input.
    # It will still act as a filter in this function, filtering out inputs that do not match this hint.
    print("=====This is Last=====")
    print(state)
    # return {"answer": "hoo"}
    # Output = {}; Because the output of the previous node doesn't include PrivateState.
    return {"messages": [("human", "World!")]}

graph_builder = StateGraph(OverallState, input=InputState, output=OutputState)

graph_builder.add_node(first)
graph_builder.add_node(middle)
graph_builder.add_node(last)

graph_builder.add_edge(START, first.__name__)
graph_builder.add_edge(first.__name__, middle.__name__)
graph_builder.add_edge(middle.__name__, last.__name__)
graph_builder.add_edge(last.__name__, END)
app = graph_builder.compile()
# print("output: ", app.invoke({"messages": [("human", "Hello")]})) # it will raise an error
print("output: ", app.invoke({"question": "What is your name?"}))

because this will return
=====This is First=====
{'messages': []}
=====This is Middle=====
{'messages': []}
=====This is Last=====
{'answer': 'Foo', 'question': 'Bar'}
output:  {'answer': 'Foo'}

@Deadsec69
Yes, you have to change the last line to execute the second-to-last line to get an exception, but I think the input for the second-to-last line should also be accepted.
Otherwise, its logic is inconsistent with other nodes.

@gbaian10 current behavior is by design, addressing your comment below:

Here is my understanding of the states: all nodes can accept OverallState, InputState, and OutputState as inputs, even if you don't include type hints.

This is incorrect. In the way you defined your graph (with both state_schema, as well as input and output), all nodes can accept OverallState as input only if no input schema is set on the node (either via type hint or via add_node), in other words state_schema (OverallState) is used as a fallback when no input schema is set. Nodes cannot accept OutputState as inputs.

If your type hint is not one of the above three, it will be considered an additional acceptable input. However, the previous node output must still include at least one key from these four states.

This is partially correct -- previous node output must include keys that the current node needs in the input schema. for the last node, its output must include keys from either output schema (if provided) or from state_schema.

If you don't include type hints and you input the three states (StateGraph(OverallState, input=InputState, output=OutputState)), the filter will select OverallState.

If you don't include type hints and you input two states (StateGraph(input=InputState, output=OutputState)), the filter will select InputState.

Those are not exactly correct. This is how you should think about these:

if input and output schema are provided, input is used only for the START node (i.e. for the graph as a whole), output is used for all node outputs
if no state_schema is provided, but input is provided, it's used as state_schema
if node input schema is defined, it's used as inputs for that node, otherwise state_schema is used as a fallback for the node inputs
otherwise, if only state_schema is provided, it's used as both input and output everywhere


xRING ([Darwinia=>)) on Crab need to be migrated to new xRING token ([Darwinia Smart=>))

Related #7
Some xRING are located in Ethereum pallet account id (root_transact)? need to take of it when doing migration.

Enable Darwinia Smart <> Crab Smart, and register new xWRING (decimal 18).
Disable old Darwinia <> Crab Smart, xRING(decimal 9) need to be migrated.
Use the backing RING asset in backing pallet on Darwinia side, and cross-chain transfer them through Darwinia Smart <> Crab Smart(Might need assistance of migration). Same amount of xWRING will be created for old xRING migration.
Deploy a new migration contract for xRING holders to burndrop/exchange xRING to xWRING in 1:1 ratio.  Old xRING will be be burned, same amount of xWRING will be withdrawn to same holder.

Old xRING token holder list: https://crab.subscan.io/erc20_token/0x7399ea6c9d35124d893b8d9808930e9d3f211501?tab=holder
This holder is the pallet account of ethereum and sender of root_transact, so kind of special and need to take care of during migration(governance proposal).
https://crab.subscan.io/account/0x6D6F646C6461722f64766D700000000000000000?tab=erc20_transfer


Edited files in order to respect "ESLINT" rules

Simple contribution by removing some trailing commas and semicolons, and also adding spaces between function parenthesis.
Eslint for React-Native: https://www.npmjs.com/package/eslint-plugin-react-native

Sorry, this is not the code style we use in this project

Thanks. It isn't personal choice. It's just to avoid headaches in projects that use Eslint, like some of mine.

Can you use https://github.com/exponent/eslint-config-exponent instead?

Why not to use the proposed package?
If this repository proposes to serve the community, then the most used library should be used.

I don't agree with that. You're free to fork this repository if you feel strongly about it.


Add security-group SelfReference filter option

SelfReference boolean filter option for security groups
Fixes #724

travis is setup to do additional validation of test policies, and is also run afoul of the test policy name  not working with the policy regex req.


receiving lots of Timed out receiving message from renderer: 0.100

Hi,
I'm running your latest image, in headless mode, and I get a lot of  warning like this:
[1585150564.457][SEVERE]: Timed out receiving message from renderer: 0.100
Do you get the same in your testing ?

Hi, yes I'm afraid so. You can read more about it here:
https://stackoverflow.com/questions/60114639/timed-out-receiving-message-from-renderer-0-100-log-messages-using-chromedriver

Do you plan to use chrome v81 ?

Yes, once it's out of beta.

Upgraded the image to Chrome 83 and these warnings have now gone.


fix typo Typo in section "Bell's Inequalities" #1675

Replaced the word has with hash in section 2.1 Bell test for classical variables

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


WIP: Fix #389 - Integrate with ocaml-language-server

Initial support for OCaml / ReasonML, based on https://github.com/freebroccolo/ocaml-language-server (WIP)

Glad to see someone trying this. Please let me know if you run into any problems.

FYI: You can set the environment variable export MERLIN_LOG=~/Desktop/log which will have merlin log its internal steps/logic to that file (assuming your Oni picks up the environment vars).

Nice! Thanks for that tip, @jordwalke ! I'm seeing an issue where the Js namespace isn't picked up (in both VSCode and Oni), so I'm wondering if it is a merlin configuration issue. Will see if that logging can help me get more info.

Yeah, if you're building with bucklescript, the project must first be built in order for the Js namespace to be picked up. Does that help?

Yep, building using BuckleScript - I followed the getting started tutorial here:  https://facebook.github.io/reason/gettingStarted.html
So I have a project with a bsconfig.json and using bsb -w to compile. I replaced the print_endline with this: let promise = Js.Promise.resolve(1);, and it compiles OK, giving me:
var promise = Promise.resolve("a");

exports.promise = promise;

But in VSCode, I see this:

With the message Unbound module 'Js'.
I'll try out the merlin logging - maybe that will give a clue. I wonder if I need to have a .merlin file for it to pick up the BuckleScript modules?

Think I need to a .merlin file - maybe https://github.com/BuckleScript/bucklescript/issues/939 is relevant. Adding "generate-merlin": true to my bsconfig.json doesn't seem to be quite enough.

Actually, the .merlin file is there now - will try and get the logs. I wonder if I need to call out the JS library. It looks like it is only including the ocaml library but not any of the js or es6 ones. Probably something missing in my bsconfig.json.

Working now - I restarted the language service and it is picked up (in both Oni and VSCode). Looks like the "generate-merlin": true was the only change that was needed in my bsconfig.json. I wonder if it is worth calling out in the "Getting Started" section of the Reason documentation?

BTW, @freebroccolo , nice work on the language server! It's great. All the problems so far have been on the Oni side 😉

Fixes #379 as well with the latest changes.

Logged this issue to track the Python issue with document symbols: https://github.com/palantir/python-language-server/issues/73
For now, I'll just disable textDocument/documentSymbol for python.


stack using array in go

assigned issue no.
#1608
##Language opted
#go
##number of file added or updated
#1
Assigned Issue Number ?
#Issue_Number
Language(s) Opted ?
C/C++/Python/Java ...
Number of file(s) added or updated ?
1/2/3/4/...
Name and location of the file(s) ?
Folder => Sub_Folder => ... => File.extension
Checklist

[X] I've followed the contributing guidelines
[X] The content added isn't directly copied from any sources like gfg, tutorialpoint, etc.
[X] Input has been taken dynamically.
[X] I've referred the correct issue number.
[X] Comments have been added
[X] I've  synced-up my forked repo.
[X] Ain't pushing from the main branch.

updated name according to naming convention

i have updated the naming convention kindly merge it

merge this  code and add hactober fest tag happy coding

@ahampriyanshu

please add hactoberfest tag

and why it's showing ❌ tag help me about this issue


Could not register device plugin: context deadline exceeded

Hi all
Environmental Info:
K3s Version: v1.19.4+k3s1 (2532c10f)

Node(s) CPU architecture, OS, and Version: Linux demeter-w1 5.4.0-56-generic #62-Ubuntu (20.04 LTS) SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Cluster Configuration: 1 master 6 worker

Describe the bug:

Unable to register nvidia gpu
Steps To Reproduce:

Installed Docker on gpu node
Installed nvidia driver and nvidia-docker2
Set nvidia as default runtime
Tested docker with: docker run --rm nvidia/cuda:10.0-base nvidia-smi (works)
Started master with --kubelet-arg="feature-gates=DevicePlugins=true" (is this needed?)
Installed K3s agent with --docker and --kubelet-arg="feature-gates=DevicePlugins=true"
Modified nvidia device plugin daemonset so that hostPath points to: /var/lib/rancher/k3s/agent/kubelet/device-plugins
Check if nvidia.sock found in pod under: /var/lib/kubelet/device-plugins/ (found)

Expected behavior:

Registered gpu
Actual behavior:

Pod logs:
2020/12/09 13:30:40 Loading NVML
2020/12/09 13:30:41 Starting FS watcher.
2020/12/09 13:30:41 Starting OS watcher.
2020/12/09 13:30:41 Retreiving plugins.
And then every 5s this:
2020/12/09 13:30:41 Starting GRPC server for 'nvidia.com/gpu'
2020/12/09 13:30:41 Starting to serve 'nvidia.com/gpu' on /var/lib/kubelet/device-plugins/nvidia.sock
2020/12/09 13:30:46 Could not register device plugin: context deadline exceeded
2020/12/09 13:30:46 Stopping to serve 'nvidia.com/gpu' on /var/lib/kubelet/device-plugins/nvidia.sock
2020/12/09 13:30:46 Could not contact Kubelet, retrying. Did you enable the device plugin feature gate?
2020/12/09 13:30:46 You can check the prerequisites at: https://github.com/NVIDIA/k8s-device-plugin#prerequisites
2020/12/09 13:30:46 You can learn how to set the runtime at: https://github.com/NVIDIA/k8s-device-plugin#quick-start
Additional context / logs:

I read trough #988 and #443. I am using v0.7.1 of https://github.com/NVIDIA/k8s-device-plugin.
Thanks in advance for any help.
Regards
Marco

Where did you see that you should use /var/lib/rancher/k3s/agent/kubelet? This was changed to the standard path of /var/lib/kubelet in https://github.com/k3s-io/k3s/pull/901 over a year ago.

I read it in #988 and #442 but yeah you are absolutely right. With standard path it does work. Thank you very much!


[doc] Add the list of the platform components to the documentation

Add a comprehensive list of the platform components to the EPAM Delivery Platform documentation. This list will significantly enhance user understanding of the overall platform architecture and how its various components interact.
For clarity and ease of use, please ensure the list adheres to the following guidelines:
Simplicity: Present the information clearly and concisely, avoiding unnecessary complexity.
Organization: Structure the list logically, potentially grouping components by category or function.
Links: Include direct links to the detailed documentation for each component.
Examples of potential component categories include:

Core Platform
Delivery Tools
Integrations
Extensions

implemented https://epam.github.io/edp-install/developer-guide/


Add UnsignedInteger/SignedInteger mapping operators

Background
struct MyModel: Mappable {
  var value: UInt = 0

  mutating func mapping(map: Map) {
    self.value <- map["value"]
  }
}

let json: [String: Any] = ["value": 123]
MyModel(JSON: json)?.value // 0 (expected 123)

<- operator for mapping UInt uses basic type mapping function. Basic type mapping uses Map.value() function to get type-casted value], but Int cannot be casted to UInt using as.
Workaround
There are two protocols that wrap integer types: SignedInteger and UnsignedInteger. This PR adds <- operator functions to support mapping of both protocols.
Related Issues

Thie PR resolves #751

Hmm test fails on Release build 🤔 I'll check it

I have no idea why tests are failing. Tests are succeeded in my machine 🤔🤔🤔

It fails on Xcode 8.0 environment (https://travis-ci.org/Hearst-DD/ObjectMapper/builds/202295374) but passes in Xcode 8.2 environment (https://travis-ci.org/Hearst-DD/ObjectMapper/builds/204318738) :(

@devxoul is this PR ready to go? or are you making updates?

@tristanhimmelman No problem! It's ready to go :)


Group Index Quantization Support

This PR is a precursor to #97 which adds support for out-of-order group quantization specified by g_idx.

Weights are permuted before and after quantization to account for new group quantization parameters

Note that some datatypes such as torch.float8_e4m3fn do not implement index_put_ and therefore must be permuted manually (this also prohibits group masking implementations

g_idx is passed to quantization operations

The group quantization cases tested are

in-order group quantization, which is the case which has already been implemented
out-of-order group quantization with dtypes which support index_put_ operations
out-of-order group quantization with dtypes which do not support index_put_ operations

A follow-up PR could explore the potential performance/code simplicity benefits of fully vectorized operations, which would require more memory and preprocessing but be more parallelizable

Looks great, superb job!

I did not test quantization/dequantization for accuracy. However, I have regression tested the accuracy of models quantized using fake_quantization.


No output on SWO pin (STM32L4)

Describe the bug
I'm not quite sure if this is a bug, but by default the SWO pin is not enabled to output data. I thing the debugger could do this, but I feel like asking the question though.
As a workaround, I added this line:
diff --git a/subsys/logging/log_backend_swo.c b/subsys/logging/log_backend_swo.c
index 203896ccd0..8e2e3da5cc 100644
--- a/subsys/logging/log_backend_swo.c
+++ b/subsys/logging/log_backend_swo.c
@@ -98,6 +98,8 @@ static void log_backend_swo_init(void)
         ITM->TCR  = 0x0001000D;
         /* Enable stimulus port used by the logger */
         ITM->TER  = 1 << ITM_PORT_LOGGER;
+        /* Enable the SWO pin */
+        DBGMCU->CR |= 0x20;
 }

 static void log_backend_swo_panic(struct log_backend const *const backend)

To Reproduce

Enable SWO logging as backend
Log simple messages in loop
No output is present on pin

Expected behavior
SWO pin outputs the logging data
Environment (please complete the following information):

OS: ArchLinux
Toolchain Zephyr SDK
BlackMagicProbe (Bumpy)
Version 9f858ac1b6bcf7f9262906f6719d51d5be4404ac

Additional context
Testing SWO with STM32L4

@andresmanelli can you send a PR with this.

@galak submitted #34436

If so, maybe using the LL_DBGMCU_SetTracePinAssignment of the stm32l4xx_ll_system.h  could help.


send_to_stroom.sh

Doesn't require System and Environment args for newer versions of Stroom

Discussed with 10 and 66, they need to be removed as they are not required anymore, as you say.
May be worth adding a new optional multiple arg, ie. --header to take headers.  This would be in addition to the one that accepts a file of headers.  Would need precedence rules e.g. --header trumps the file based headers.

Fixed in #6


[Feature Request]

The current recovery mechanism has a flaw ... if you didn't think to save your token anywhere before needing it, there isn't anything you can do.
Under Setting -> Sharing, in addition to Sex and Birth Date, could an optional field be added to allow entering email address?
Not required, but if it is set, the email address would be included as part of statistic, and could be used as a means of searching for tokens belonging to the same user.
No password would be required, as we'd use the same mechanism as before, where a one time password would be emailed to the person to login and view their TOKENs.
The only way to recover settings in the app would still remain the token itself, so to find your token, you would need to go to the site and login.
As mentioned above, this would be a totally optional field ... everything would continue to work as is without it ... this is only mean to give the ability for people, who so choose, to be able to find their old TOKENs if needed for recovery purposes.

Currently the only recovery used in iAPS was created for version 5.6.0 to avoid any lost settings when updating to this version. This recovery is semi-automatic, you only need to tap a button to confirm. For this recovery you don’t need to know or enter your token.

The profiles branch, if I recall correctly, was going to add the ability to enter a TOKEN on starting up new iAPS, but even without that, the ability to search for and be able to see older settings via the web site would allow for, at least, someone to see and manually enter their old settings on a reset.
Waiting for something like profiles to be added means that this would only be useful going forward from that point, while adding it now means that this would be useful now, even if for accessing and manually setting.


Adding elements to the beginning/end of the zipper without changing focus

Thank you for this library. I want the user to be able to view an element of the zipper, but at the same time new elements may be pushed onto the end of the zipper. Would it be possible to add something like cons or append which don't change the focus?

It would be possible to add the function though it would most likely have linear complexity (depending on the number of previous or next items) so Zipper might not be the best data-structure if this is the operation you're primarily looking for.
Anyway it still might make sense to add it. Thanks for the input. I already have this messy issue with functions I would wish to have on Zipper as I'm using it. I'll add this one to the list https://github.com/turboMaCk/non-empty-list-alias/issues/16

@turboMaCk  Thanks for your quick reply. Apologies if I'm misunderstanding, but would cons be something like:
cons : a -> Zipper a -> Zipper a
cons a (Zipper prev current next) =
    Zipper (a :: prev) current next

Which is not linear?

yes indeed the previous list is in reverse order so the functions like prev are constant time.
This post on discorse has some additional explanations https://discourse.elm-lang.org/t/representing-nonempty-list-as-pair-a-list-a/5771/4?u=turbomack
Yes adding the information to the docs should be fine. That's being said if I would  consider defining zipper with deck instead of list if I would be in need of using these operations a lot. But it always depend on a context. Certainly linear is not that bad and it's fine to use linear operations (it doesn't even matter unless the length of the data is quite significant).

@turboMaCk Sounds good! at the moment I just need a cons, and I'm only holding up to 200 items. I'd be happy to give a PR a shot.

Shall we stick to calling it cons or call it insertStart to go with the theme that all insertX functions don't move focus?

@Kurren123 yes I think we will need some other name (like insertStart). With naming I usually like to give it some time once thoughts settle but feel free to recommend names if you have some ideas.

1.1.0 https://github.com/turboMaCk/non-empty-list-alias/releases/tag/1.1.0 includes prepend and append functions.


Generating strong dhparam secret for enabling TLS

Hello all,
Just wondering if you have an idea for a solution to this.
To enable TLS connections, we must create a Diffie-Hellman parameters file (dhparam). This process is pretty computationally expensive and requires openssl.
I wonder how do you recommend automating the creation of the secret while automating deployments of new environments in K8s using stack tools like Argo, Helm etc.
Thanks!

BTW, Diffie-Hellman (DH) file is optional, if not specified or empty, the default parameters are used.


render the bundle images outside of the container

github does not allow to use secrets in the pull requests. Which
prevent us to login to quay and push images to it. That can be pulled
inside the container while making a container image.
using opm outside of the container does allow to use the local bundle
images as well. Which help to pull odf bundle image from the local
registry.
Signed-off-by: Nitin Goyal<EMAIL_ADDRESS>Related PR: https://github.com/red-hat-storage/odf-operator/pull/258

/retest

/retest


Update updates page for DCP 33

New projects (8):

A spatially resolved single-cell genomic atlas of the adult human breast
An Optimized Tissue Dissociation Protocol for Single-Cell RNA Sequencing Analysis of Fresh and Cultured Human Skin Biopsies
Classification of human chronic inflammatory skin disease based on single-cell immune profiling
Crosstalk of astrocyte, microglia, and neuronal subtypes correlates to Alzheimer’s disease pathology
Neuronal defects in a human cellular model of 22q11.2 deletion syndrome.
Single cell transcriptional zonation of human psoriasis skin identifies an alternative immunoregulatory axis conducted by skin resident cells
Transcriptomic analysis of the ocular posterior segment completes a cell atlas of the human eye
αβγδ T cells play a vital role in fetal human skin development and immunity

Updated Projects (4):

Cell atlas of the human ocular anterior segment: Tissue-specific and shared cell types
Immunophenotyping of COVID-19 and influenza highlights the role of type I interferons in development of severe COVID-19
Harnessing Expressed Single Nucleotide Variation and Single Cell RNA Sequencing To Define Immune Cell Chimerism in the Rejecting Kidney Transplant
Single-cell RNA sequencing reveals the effects of chemotherapy on human pancreatic adenocarcinoma and its tumor microenvironment

Complete


Replace ImageView dependancy with Makie

Currently the pixel picture creating scripts don't even need Makie, when an image is returned it is automatically displayed by VScode


bug fix: partials do not render on Windows 7.

This is my first pull request for Punch.
I was attempting to follow the Punch setup tutorial but partials weren't rendering. I found the fix for the
problem here: https://github.com/laktek/punch/issues/102
My system is Windows 7 64bit.
Partials are now rendering after applying the fix. I have no idea what effects the changes will have when run on OSX and other operating systems. Sorry.

Thanks for the PR. I'll try to review and test it over the weekend.
Any idea why the diff changes all lines in the file? Can you try to format it to only show the lines that were changed?

I'm not sure why the diff shows all lines as changed. Maybe the line endings have changed?
Anyway, I noticed the problem with the diff on my first attempt to commit the changes.  Here you can see the two lines that were changed:
https://github.com/veryangrymobster/punch/compare/laktek:master...master
I didn't expect the diff to still have problems when being compared to your files. To fix it I'll need to delete my fork and start from scratch. As it's only two lines would you mind copying the changes manually?

You don't have to delete your fork. You can close the previous PR and open
a new PR with this diff.
On Thu, Jan 22, 2015 at 8:54 AM, Shannon Oram<EMAIL_ADDRESS>wrote:

I'm not sure why the diff shows all lines as changed. Maybe the line
endings have changed?
Anyway, I noticed the problem with the diff on my first attempt to commit
the changes.
Here you can see the two lines that were changed:
veryangrymobster@laktek:master...master
https://github.com/veryangrymobster/punch/compare/laktek:master...master
I didn't expect the diff to still have problems when being compared to
your files. To fix it I'll need to delete my fork and start from scratch.
As it's only two lines would you mind copying the changes manually?
—
Reply to this email directly or view it on GitHub
https://github.com/laktek/punch/pull/118#issuecomment-70952714.

Alright, I'll give it a go.


Cluster failure after election timeout

Just seen on Circle.  If this still exists on the other side we will address it then.


Readjust the CheckBox & Radio Buttons style

According on issue #41, after the meeting we confirmed the third-party Icon Font scheme: "Fluent System Icons".
I will consummate this part.

TASK COMPLETE!
Please select the icon object first, check the name of the icon from the Code section in the Inspect Panel on the right side of the screen, it will correspond to the Fluent System Icons.
→ Here's the current Figma file.
Like this:


fix: spurious rebuilds of whole repo on unrelated file changes

Update crane to include fix for https://github.com/ipetkov/crane/issues/242

Codecov Report
Base: 63.78% // Head: 63.76% // Decreases project coverage by -0.02% :warning:

Coverage data is based on head (2c44555) compared to base (72b6e03).
Patch has no changes to coverable lines.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1720      +/-   ##
==========================================
- Coverage   63.78%   63.76%   -0.02%
==========================================
  Files         132      132
  Lines       24372    24372
==========================================
- Hits        15545    15541       -4
- Misses       8827     8831       +4

Impacted Files
Coverage Δ

fedimint-server/src/multiplexed.rs
88.75% <0.00%> (-2.50%)
:arrow_down:

fedimint-server/src/net/peers.rs
90.71% <0.00%> (-0.90%)
:arrow_down:

fedimint-server/src/lib.rs
76.75% <0.00%> (-0.28%)
:arrow_down:

fedimint-core/src/core.rs
91.43% <0.00%> (-0.24%)
:arrow_down:

modules/fedimint-ln/src/lib.rs
73.79% <0.00%> (-0.14%)
:arrow_down:

modules/fedimint-mint/src/lib.rs
77.95% <0.00%> (+0.11%)
:arrow_up:

fedimint-server/src/consensus/mod.rs
81.41% <0.00%> (+0.16%)
:arrow_up:

crypto/tbs/src/poly.rs
24.43% <0.00%> (+0.20%)
:arrow_up:

fedimint-server/src/net/connect.rs
94.64% <0.00%> (+0.24%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[BUG] Connecting sessions to server

Describe the bug
When scanning a QR code the server responds with a 500 internal server error. message body is bad-request
To Reproduce
Steps to reproduce the behavior:

Created a new connection by scanning the QR code

Expected behavior
should respond without 500 error
Environment (please complete the following information):

Is this on a server? yes
What do your connectOptions look like?  default settings
Do you have multiple clients on the same IP? yes
Are you using a proxy? no

Additional context
I tested this on multiple servers and get the same outcome on each. If you don't have same problem please tell me so I can test it further if its something on my end

?????????????????

err: {
  "type": "Error",
  "message": "bad-request",
  "stack":
      Error: bad-request
          at assertNodeErrorFree (C:\Users\Administrator\Desktop\baileys-api-main\node_modules\@whiskeysockets\baileys\lib\WABinary\generic-utils.js:56:15)
          at query (C:\Users\Administrator\Desktop\baileys-api-main\node_modules\@whiskeysockets\baileys\lib\Socket\socket.js:140:48)
          at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
          at async fetchProps (C:\Users\Administrator\Desktop\baileys-api-main\node_modules\@whiskeysockets\baileys\lib\Socket\chats.js:623:28)
          at async Promise.all (index 1)
          at async executeInitQueries (C:\Users\Administrator\Desktop\baileys-api-main\node_modules\@whiskeysockets\baileys\lib\Socket\chats.js:709:9)
  "data": 400,
  "isBoom": true,
  "isServer": true,
  "output": {
    "statusCode": 500,
    "payload": {
      "statusCode": 500,
      "error": "Internal Server Error",
      "message": "An internal server error occurred"
    },
    "headers": {}
  }
}