LoadBalancer with https port redirecting to wrong service

Rancher Version:
1.1.0-dev3
Docker Version:
1.11.2
OS and where are the hosts located? (cloud, bare metal, etc):
4 BareMetal Ubuntu 16.04
Setup Details: (single node rancher vs. HA rancher, internal DB vs. external DB)
Single Master / internal DB
Environment Type: (Cattle/Kubernetes/Swarm/Mesos)
Cattle
Steps to Reproduce:
Run More than one webservice using https with a loadbalancer listenting on port 443
Results:
The loadbalancer sometimes redirects to the wrong service.
Expected:
Correct routing.
We have a custom gitlab, a catalog registry (without the loadbalancer, because we have the global one) and another webservice.
The loadbalancer definition is:
loadbalancer-https:
  ports:
  - 443:443/tcp
  external_links:
  - git/gitlab:gitlab
  - fact-aux/auxservice:auxservice
  - registry/sslproxy:sslproxy
  labels:
    io.rancher.loadbalancer.target.git/gitlab: git.e5.physik.tu-dortmund.de:443=443
    io.rancher.scheduler.affinity:host_label: role=master
    io.rancher.loadbalancer.target.fact-aux/auxservice: auxdb.app.tu-dortmund.de:443=443
    io.rancher.loadbalancer.target.registry/sslproxy: registry.e5.physik.tu-dortmund.de:443=443
  tty: true
  image: rancher/load-balancer-service
  stdin_open: true

Any idea why this is happening? It also seems to just affect the loadbalancer on port 443.

For example, at the moment https://auxdb.app.tu-dortmund.de is pointing to our gitlab???
While http://auxdb.app.tu-dortmund.de is routed correctly.

Dam, seems that I forgot to EXPOSE 443 in the auxservice container and the loadbalancer just tries another services than.
Can you add an option, to not do that? And just fail if no services answering to a given url can be reached? I think this is more sane.

Also, when I delete my browsing cache and history, i reach the correct service. After a while, I get to the wrong service again. The I delete the cache again and I am routed correctly.

Can you exec into the loadbalancer and share the results of cat /etc/haproxy/haproxy.cfg? Can you also share the container IPs of your services? That is the 10.42.x.x of gitlab, auxservice and sslproxy?

This is the config (in the mean time, we replaced one service)
global
        log <IP_ADDRESS> local0
        log <IP_ADDRESS> local1 notice
        maxconn 4096
        maxpipes 1024
        chroot /var/lib/haproxy
        user haproxy
        group haproxy
        daemon
        nbproc 4
    cpu-map 1 0
    cpu-map 2 1
    cpu-map 3 2
    cpu-map 4 3

defaults
        log     global
        mode    tcp
        option  tcplog
        option  dontlognull
        option  redispatch
        option http-server-close
        option forwardfor
        retries 3
        timeout connect 5000
        timeout client 50000
        timeout server 50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http

frontend 7cf22e5c-e99f-4f52-8296-9e1c212e3d0e_443_frontend
        bind *:443
        mode tcp

        default_backend 7cf22e5c-e99f-4f52-8296-9e1c212e3d0e_443_0_backend

backend 7cf22e5c-e99f-4f52-8296-9e1c212e3d0e_443_0_backend
        mode tcp
        server 11b2d855-6a07-4dcd-93b4-fb89f187552f <IP_ADDRESS>:443
        server 396d8b2b-96b1-45e6-bdab-4023d152301b <IP_ADDRESS>:443
        server 20363eaa-007b-495b-858d-31b8b3b3daa3 <IP_ADDRESS>:443
        server 78ff95ff-7a3d-422f-a814-b8e726373da3 <IP_ADDRESS>:443

listen default
        bind *:42

IPs:
gitlab: <IP_ADDRESS>
owncloud: <IP_ADDRESS>
registry-sslproxy: 	<IP_ADDRESS>
rocket-chat_rocket-sslproxy:	<IP_ADDRESS>

Might be related https://github.com/rancher/rancher/issues/4604

Right now it's basically random. which service will be reached at which url. This makes it pretty unusable for us.

And I can stress again: It seems only to affect https (443). The http balancer works perfectly fine.

Maybe  your setup relies on SNI being available. This is not supported on the load Balancer.  (Yet)

My bad. It seems that the reason for this behaviour was that I accidentally set the protocol to tcp. In the LoadBalancer. Everything works fine now with http


Round-off error in RegularCartesianGrid produces ranges of wrong length

Noticed this because test_diffusion_cosine was failing in PR #462.
We should have that length(zC) == Nz but
julia> Nz = 16; Lz = π/2; Δz = Lz / Nz; zC = -Lz+Δz/2:Δz:-Δz/2; length(zC)
16

julia> Nz = 32; Lz = π/2; Δz = Lz / Nz; zC = -Lz+Δz/2:Δz:-Δz/2; length(zC)
32

julia> Nz = 64; Lz = π/2; Δz = Lz / Nz; zC = -Lz+Δz/2:Δz:-Δz/2; length(zC)
63

julia> Nz = 128; Lz = π/2; Δz = Lz / Nz; zC = -Lz+Δz/2:Δz:-Δz/2; length(zC)
127

julia> Nz = 256; Lz = π/2; Δz = Lz / Nz; zC = -Lz+Δz/2:Δz:-Δz/2; length(zC)
255

Looks like a scary effect of round-off error to me.
I'll make the switch to using the range function with a fixed length and add a test to check for this.

I think ‘range’ is clearer anyways!

Is this fixed?

Yes it's been fixed in PR #462 (had to fix it as the issue arose once the k index was reversed), just need to merge it.


AVRO-3603 dotnet reflect reader and writer refactoring

Jira

[ ] My PR addresses the following Avro Jira issues and references them in the PR title.

Tests
My PR do not add or update functionality, there is no new tests
Commits

[ ] My commits all reference Jira issues in their subject lines.

Documentation
Readme file is updated
https://github.com/KhrystynaPopadyuk/avro/tree/avro-3603-dotnet-reflect-refactoring/lang/csharp/src/apache/main/Reflect

Hi @KalleOlaviNiemitalo and @RyanSkraba ,
Please review my new PR. This is refactoring to reduce static class and fields and introduce DI.
This PR will allow further refactoring in future.
Thanks.

Hi @KalleOlaviNiemitalo  and @martin-g ,
Thank you for review and feedback.
I believe that at the end of day such refactoring is important and would be beneficial for both contributors (provide easier maintenance and extensibility) and end users (make it flexible, allow inject custom logic and override default behavior).
There is no goal to change serialization and deserialization. All changes are around reflection.
From your comments I understand that there are two main concerns: breaking changes and new dependency.
I agree with @KalleOlaviNiemitalo that we can easy resolve new dependency issue - do not add DI, create new project or leave it with end user.
About breaking changes. After second thought it looks like there is way to do refactoring without introducing breaking changes. The example and final state can be reviewed at https://github.com/apache/avro/pull/1823. As you can see in case if there is no breaking changes there are much more updates, that PR is massive.
I do not think that it is safe to deliver such massive PR. Also it is difficult to review them. Likely we can break down it to small pieces, implement, review and deliver it one by one. First such update are created and ready for review: https://github.com/apache/avro/pull/1824.
Thanks one more time for your time.
Khrystyna


v1.0 Release

Checklist for v1.0 release

[ ] Test on v1.0 Xbox
[ ] Test on v1.1-v1.3 Xbox
[X] Test on V1.4 Xbox - Ryzee119. This is my main dev xbox.
[ ] Test on V1.6 Xbox
[ ] Add FTP server/someother network interface
[ ] No known bugs/no new reports for a few weeks

Test should include a bit of use, i.e launch a few games, direct booting in dash (from cold boot), quick reset back into dash, system info screen shows correct version number/encoder info etc, generally trying to break it :)

Thank you for your feedback!
Scraping/downloading coverart is a goal eventually
All games should show text on the default coverart until a jpg is loaded (or will remain if no art is found).. hmm I need to look into that

It also looks quite horizontally stretched. Ill fix that. May not be helping that fuzzy text

It seems like the XBE in question doesnt have a title name - when loading it into CXBX-Reloaded, it comes up with the title "Desktop" as its stored on the desktop folder. xbedump reports a title name of Title name                          : "" and it seems i have two other titles that does this.
CXBX-Reloaded.txt
xbedump.txt

v0.3 now adds an FTP server. Please test it out!
Recommend setting your FTP client to use 1 concurrent connection.


Use of skill_discriminator.py

Hi,
Is the SkilDiscriminator class used at all in this project?  I can't find where it is ever called.
Thanks.

You can use it to construct different reward function, but it is not necessary for reproducing DADS.

Hi Archit,
Thanks for your quick reply.  From looking at the reward function, I'm guessing you mostly used it for reproducing the DIAYN results?

Yes! But, there would be subtle differences from the open-sourced version of DIAYN if you choose to use the skill-discriminator from this codebase.


Remove deprecated Factory.create methods with classLoader

I guess it's fine to remove these methods, I checked that the plugins, including the ant plugin no longer use them.
See #340 for the discussion about deprecating these methods.
It would be just great to also remove the implementations from JRubyAsciidoctor.

Thank! :)


force sensor problem

Hi,
I'm a student  and I'm trying to use MuJoCo for the task peg in hole using a manipulator(ur5).
I'm looking for some help with force sensor.
Currently i am working on force sensor task in MuJoCo(peg_in_hole),  but i have been struggling with some problems. i made some summaries below explaining.

i have write an 'xml'  adding a body,`` site (to work as a sensor) as mentioned in #399::

    <body name="dummy body" pos="0 0 0.045">
      <inertial pos="0 0 0" mass="0.0001" diaginertia="0 0 0" />
        <geom type="box" pos="0 0 0" size="0.01 0.01 0.01" rgba="0 1 0 0.5"/>
        <site name="ft_sensor" pos="0 0 0.0" rgba="1 0 0 0.3" size="0.01 0.01 0.01" type="box"/>
    </body>
.......
    <sensor>
        <force name = "force" site="ft_sensor" />
    </sensor>

with the changes made in xml file (as shown above) i run in the simulation to measure the force. but i there are some wrong data obtained.
a) to measure the force, i run the code as shown in a) to measure the force, i run the code as explained in  https://colab.research.google.com/github/google-deepmind/mujoco/blob/main/python/tutorial.ipynb#scrollTo=z-zoBCuBv2Xi:

     force=data.sensor("force").data
     print("-----print force--:  ", force)

b) running in to the simulation, i obtained a force information without making a contact with other body:
info. obtained [  6.98633476  -0.33842342 -28.42605504]

c) when there is a contact.  the force tends to be a huge  info. and the force direction reaction seems to be wrong:
info. obtained [-907020.62997521<PHONE_NUMBER>9864 1111326.38752532]

would you please help out whether the way i try to get a correct info is right? or, there are other methods i ignore.
best regards

I  meet same question

Could you please make a minimal example so that we can load and reproduce?

Could you please make a minimal example so that we can load and reproduce?
Thanks for your help!

There are my  description and code of minimal example:
We use hinge joints to directly fix the axis to the square, and the contact force is vertical upwards (I understand it to be the correct direction),as shown in  this fig(xml:peg_square.xml)

When we load the hinge joint of the axis onto UR5 and take the contact square at the same angle, the direction of force changes(xml:robot_square.xml,code:demo).

The code and xml:
mujoco_demo.zip

@yuvaltassa
thanks for your prompt reply:
here is  the xml file:
<mujoco model="ur5">
  <option gravity="0 0 0"/>
  <include file="scene.xml"/>
  <compiler angle="radian" meshdir="/home/marcos/Documents/mujoco/collision/"/>
  <statistic meansize="0.2" extent="0.4" center="-3.42017e-10 -0.0501512 -1.90133e-10"/>
  <asset>
    <mesh name="fk" file="fk.STL"/>
  </asset>
  <statistic meansize="0.161957" extent="1.0432" center="0.388318 0.0842553 0.0891814"/>
  <asset>
    <mesh name="base" file="base.stl"/>
    <mesh name="shoulder" file="shoulder.stl"/>
    <mesh name="upperarm" file="upperarm.stl"/>
    <mesh name="forearm" file="forearm.stl"/>
    <mesh name="wrist1" file="wrist1.stl"/>
    <mesh name="wrist2" file="wrist2.stl"/>
    <mesh name="wrist3" file="wrist3.stl"/>
    <mesh name="peg20231110" file="peg20231110.STL"/>
  </asset>
  <worldbody>
    <geom quat="0 0 0 1" type="mesh" contype="0" conaffinity="0" group="1" density="0" rgba="0.7 0.7 0.7 1" mesh="base"/>
    <geom quat="0 0 0 1" type="mesh" rgba="0.7 0.7 0.7 1" mesh="base"/>
    <body name="shoulder_link" pos="0 0 0.089159" quat="0 0 0 1">
      <inertial pos="0 0 0" mass="3.7" diaginertia="0.0149724 0.0149724 0.0104063"/>
      <joint name="shoulder_pan_joint" pos="0 0 0" axis="0 0 1" range="-6.28319 6.28319"/>
      <geom quat="0 0 0 1" type="mesh" contype="0" conaffinity="0" group="1" density="0" rgba="0.7 0.7 0.7 1" mesh="shoulder"/>
      <geom quat="0 0 0 1" type="mesh" rgba="0.7 0.7 0.7 1" mesh="shoulder"/>
      <body name="upper_arm_link" quat="0.707107 0.707107 0 0">
        <inertial pos="-0.2125 0 0.136" quat="0.707107 0 0.707107 0" mass="8.393" diaginertia="0.133886 0.133886 0.0151074"/>
        <joint name="shoulder_lift_joint" pos="0 0 0" axis="0 0 1" range="-6.28319 6.28319"/>
        <geom pos="0 0 0.136" quat="0.5 0.5 -0.5 -0.5" type="mesh" contype="0" conaffinity="0" group="1" density="0" rgba="0.7 0.7 0.7 1" mesh="upperarm"/>
        <geom pos="0 0 0.136" quat="0.5 0.5 -0.5 -0.5" type="mesh" rgba="0.7 0.7 0.7 1" mesh="upperarm"/>
        <body name="forearm_link" pos="-0.425 0 0">
          <inertial pos="-0.2125 0 0.0165" quat="0.707107 0 0.707107 0" mass="2.275" diaginertia="0.0312168 0.0312168 0.004095"/>
          <joint name="elbow_joint" pos="0 0 0" axis="0 0 1" range="-3.14159 3.14159"/>
          <geom pos="0 0 0.0165" quat="0.5 0.5 -0.5 -0.5" type="mesh" contype="0" conaffinity="0" group="1" density="0" rgba="0.7 0.7 0.7 1" mesh="forearm"/>
          <geom pos="0 0 0.0165" quat="0.5 0.5 -0.5 -0.5" type="mesh" rgba="0.7 0.7 0.7 1" mesh="forearm"/>
          <body name="wrist_1_link" pos="-0.39225 0 0.10915">
            <inertial pos="0 0 0" quat="0.5 0.5 -0.5 0.5" mass="1.219" diaginertia="0.00342844 0.00262426 0.00262426"/>
            <joint name="wrist_1_joint" pos="0 0 0" axis="0 0 1" range="-6.28319 6.28319"/>
            <geom pos="0 0 -0.093" quat="0.707107 0.707107 0 0" type="mesh" contype="0" conaffinity="0" group="1" density="0" rgba="0.7 0.7 0.7 1" mesh="wrist1"/>
            <geom pos="0 0 -0.093" quat="0.707107 0.707107 0 0" type="mesh" rgba="0.7 0.7 0.7 1" mesh="wrist1"/>
            <body name="wrist_2_link" pos="0 -0.09465 -1.9413e-11" quat="0.707107 0.707107 0 0">
              <inertial pos="0 0 0" quat="0.5 0.5 -0.5 0.5" mass="1.219" diaginertia="0.0021942 0.00178515 0.00178515"/>
              <joint name="wrist_2_joint" pos="0 0 0" axis="0 0 1" range="-6.28319 6.28319"/>
              <geom pos="0 0 -0.095" type="mesh" contype="0" conaffinity="0" group="1" density="0" rgba="0.7 0.7 0.7 1" mesh="wrist2"/>
              <geom pos="0 0 -0.095" type="mesh" rgba="0.7 0.7 0.7 1" mesh="wrist2"/>
              <body name="wrist_3_link" pos="0 0.0823 -1.688e-11" quat="0.707107 -0.707107 0 0">
                <inertial pos="0 0 -0.00627169" quat="0.5 0.5 -0.5 0.5" mass="0.3389" diaginertia="0.000132134 0.00011486 0.00011486"/>
                <joint name="wrist_3_joint"  pos="0 0 0" axis="0 0 1" range="-6.28319 6.28319"/>
                <geom pos="0 0 -0.0818" quat="0.707107 0.707107 0 0" type="mesh" contype="0" conaffinity="0" group="1" density="0" rgba="0.7 0.7 0.7 1" mesh="wrist3" friction=".33"/>
                <geom pos="0 0 -0.0823" quat="0.707107 0.707107 0 0" type="mesh" rgba="0.7 0.7 0.7 1" mesh="wrist3"/>
                <geom size="0.005 0.005 0.005" pos="0 0 -0.01" quat="0.5 0.5 -0.5 0.5" type="box"/>
                <geom pos="0 0 0.005" quat="0.5 0.5 -0.5 0.5" type="mesh" contype="0" conaffinity="0" group="1" density="0" rgba="0.7 0.7 0.7 1" mesh="peg20231110"/>
                <geom pos="0 0 0.005" quat="0.5 0.5 -0.5 0.5" type="mesh" rgba="0.7 0.7 0.7 1" mesh="peg20231110" friction=".33"/>
                <site name="endeff" pos="0. 0.0 0" size="0.001"/>
                <body name="dummy body" pos="0 0 0.045">
                  <inertial pos="0 0 0" mass="0.0001" diaginertia="0 0 0" />
                  <geom type="box" pos="0 0 0.0" size="0.01 0.01 0.01" rgba="0 1 0 0.5"/>
                  <site name="ft_sensor" pos="0 0 0.00" rgba="0 0 1 0.3" size="0.01 0.01 0.01" type="box"/>
                </body>
              </body>
            </body>
          </body>
        </body>
      </body>
    </body>
    <body name="FK_link"  pos = "-0.35  0.025 0.292"  euler="1.5707963267948966 0 0">
      <geom euler="0 0 0" type="mesh" rgba="0.7 0.7 0.7 1" mesh="fk" />
 	  </body>
    </worldbody>
        <actuator>
        <motor name="joint1_motor" joint="shoulder_pan_joint" />
        <motor name="joint2_motor" joint="shoulder_lift_joint"/>
        <motor name="joint3_motor" joint="elbow_joint"/>
        <motor name="joint4_motor" joint="wrist_1_joint"/>
        <motor name="joint5_motor" joint="wrist_2_joint"/>
        <motor name="joint6_motor" joint="wrist_3_joint"/>
        <position name="pos_1" joint="shoulder_pan_joint" kp="0"/>
        <position name="pos_2" joint="shoulder_lift_joint" kp="0"/>
        <position name="pos_3" joint="elbow_joint" kp="0"/>
        <position name="pos_4" joint="wrist_1_joint" kp="0"/>
        <position name="pos_5" joint="wrist_2_joint" kp="0"/>
        <position name="pos_6" joint="wrist_3_joint" kp="0"/>
    </actuator>
    <sensor>
		<framepos objtype="site" objname="endeff"/>
    <force name = "force" site="ft_sensor" />
	</sensor>
</mujoco>

and here is the code
import mujoco as mj
import time
import mujoco.viewer as mj_v
model = mj.MjModel.from_xml_path('/home/marcos/Documents/mujoco/ur5_rob.xml')
data = mj.MjData(model)
model.opt.gravity = (0, 0, -10)
viewer = mj_v.launch_passive(model, data)
pos0=[0.17362833300268518, -1.2121243987680486, -2.0725610962900856, -1.4074108764951834,
                               1.5662999346520339, 0.17348426293570066]
pos1=[0.17252430431081262, -1.217633869306532, -2.0744604343480257, -1.4202896089526071, 1.5707993308045025, 1.7432996650566035]
pos2=[0.17252427935127498, -1.2184529792114982, -2.0791066815703085, -1.4148242594646834, 1.5707993209176168, 1.7432996398162683]
#----------------------position 1
for i in range(6):
    data.qpos[i]=pos0[i]
    data.ctrl[i]= data.qpos[i]
mj.mj_step(model, data)
force=data.sensor("force").data
print("---print force: ", force)
viewer.sync()
#-----------------------position2
for i in range(6):
    data.qpos[i]=pos1[i]
    data.ctrl[i]= data.qpos[i]
mj.mj_step(model, data)
force=data.sensor("force").data
print("---print force: ", force)
viewer.sync()
#-----------------------position3
for i in range(6):
    data.qpos[i]=pos2[i]
    data.ctrl[i]= data.qpos[i]
mj.mj_step(model, data)
force=data.sensor("force").data
print("---print force: ", force)
viewer.sync()
time.sleep(10)

stl. files attached
arm_tool.zip
best regards!

@yuvaltassa
Hello!
Sorry for continuing to insist. but i am still struggling into the force sensor problem.
following the #399 . and after may attempts  i still get a wrong force data.
i use a ur5 robot manipulator added a peg(body) as an end-effector; at the same time i add the force sensor(site) at the end of the peg as shown in the follow figure.
but the force data received is force[-0.49101407  0.12644676  1.65185966] and ntf_force [-0.49101407  0.12644676  1.65185966]

As the contact is with a planar surface i kept receiving force in Fx Fy  isn't the force should be just in Fz direction?
if the data i have receive is not wrong. i wonder how to just get the force received at  the peg in order to assume the force just between the peg and the planar surface ?

No no, thanks for insisting!
I very much want to diagnose this. Do you think you could make an actually minimal test case? Pure XML, no meshes, no arm. Something like a worldbody with a floor (plane) geom, a single vertical slider joint moving a body up and down (position controlled?), one static body at the bottom that can touch the floor with a force sensor attached.
Context:

Having the arm creates ambiguity, I need to be able to precisely know what the force sensor is expected to measure (vs what it is measuring).
If I'm to write a proper test for this in mujoco/test/ I cannot have any meshes which come from a copyrighted source.

sure!
here is a xml file: simple peg and static body added the sensor at the bottom of the peg.
<mujoco model="ur5">
  <option gravity="0 0 0"/>
  <worldbody>
    <body name="peg_link" pos="0.02 0 0.24" >
      <joint pos="0 0 0.0" type="slide" axis="0 0 1"/>
      <geom euler="0 0 0" pos="0 0 0." name="peg" type= "cylinder" size="0.01 0.025" rgba="0.7 0.7 0.7 0.8" contype="0" conaffinity="0"/>
      <inertial pos="0 0 0.015" mass="0.424" diaginertia="0.00019875 0.00019875 0.00019080"/>
      <body name="dummy_body" pos="0 0 -0.025">
        <inertial pos="0 0 0" mass="0.000000001" diaginertia="0.000000001 0.000000001 0.000000001"/>
        <geom  pos="0 0 0.0025" size=".01 .01 .0025" type="box" rgba="0 0 1 0.3"/>
        <site name="contact_sensor" pos="0 0 0.0" rgba="1 0 0 1" size="0.0005 0.0005 0.0005" type="sphere"/>
      </body>
    </body>
    <body name="box_obj" pos="0 0 0.1">
      <geom pos="0 0 0.0" name="box_obj" type="box" size= "0.1 0.1 0.1" rgba="0.7 0.7 0.7 1" />
    </body>
  </worldbody>
  <sensor>
        <force name="contact_force" site="contact_sensor"/>
	</sensor>
</mujoco>

after running with simple xml (one peg with an static body ) the obtained force  data seems to be right. but the problem comes ; when i want to add the peg into the robot manipulator( added at ee_link), the force data and the force direction tends to be wrong(not the same as when i run a simple peg and static body).
perhaps after adding the peg into the manipulator.  the manipulator  robot affects the expected force data we want to obtain? if that so, is there a method or a way to ignore  it, and just obtain the force data between the peg and the box.
thanks for your time!
regards.

Hmm, so this example does not really reproduce the issue, right?
I wonder if there are small vibrations coming from the arm controller? Could you try reducing the timestep to see if that changes anything?

yes.
I just run a simple mj_forward with data.qpos joint position,  as shown below.  And still the force data seems to be wrong.

-model = mj.MjModel.from_xml_path('.........../ur5_rob.xml')
data = mj.MjData(model)
viewer = mj_v.launch_passive(model, data)
pos0=[0.169, -1.224, -2.087, -1.400, 1.57, 1.74]
pos1=[ 0.16880386, -1.22476103, -2.08876971, -1.39885805,  1.57080307,
        1.73958779]
#----------------------position 1
for i in range(6):
    data.qpos[i]=pos0[i]
mj.mj_forward(model, data)
force=data.sensor("contact_force").data
print("---print force: ", force)
viewer.sync()
#-----------------------position2
for i in range(6):
    data.qpos[i]=pos1[i]
mj.mj_forward(model, data)
force=data.sensor("contact_force").data
print("---print force: ", force)
viewer.sync()

I appreciate your time and help.
Regards!

Okay, could you try to make the simplified model slightly more elaborate, say two hinge joints rather than one slider, and see if you can reproduce the issue?

after a modification in the simply model( changing the joints), the results are right ( as show in the fig. )

the problem is still when i add the peg at the arm; instead of use mj_step i use mj_forward.  or am i using in a wrong way the functions(mj_step, mj_forward) so that can affect the force results?

mj_forward is fine, doesn't affect the results.
I have a suspicion: do you understand that the measured values are in the frame of the sensor site ?
Visualize your site frames in the original model, perhaps that will illuminate.


Fix test build errors

Thanks, but I’m not sure if it is a good idea yet to switch to crates.io. Can you please invert the comments in Cargo.toml?

Never mind, let’s see how stable Rust got…


Unable to build under Windows

I can't build it in Windows (7 x64): after cloning it and npm i, I get the following error when I try to grunt all or grunt test:
Running "tape:files" (tape) task
Fatal error: spawn C:\react-templates\node_modules\grunt-tape\node_modules\tape
\bin\tape ENOENT

Task default and pgall do work anyway. Any idea? I would like to contrib, but it's hard it I can't run tests :-)

please try running
npm run all

Ok, with npm run all tape does work and the build step is completed correctly.
But there seems to be another issue: I've just cloned the new 0.4.0/gh-pages and grunt pgall that previously worked now throws this:
Running "uglify:my_target" (uglify) task
JS_Parse_Error {
  message: 'Unexpected token: name (RTCodeError)',
  filename: 'rt-main.browser.js',
  line: 57572,
  col: 6,
  pos: 1936103, ... }
>> Uglifying source playground/dist/rt-main.browser.js failed.

Looking at rt-main.browser.js at the indicated line revealed some ES6 "class" code.
Thank you for your precious help, I look forward to collaborate with this great project (I have some nice ideas).

I will check it, however, that grunt task is for the playground web page and is not required for react-templates contribution so it should not block you.

I'm closing this and opening a specific issue for the playground one.


location is undefined here and I'm not sure what the proper input should be

https://github.com/biglocalnews/court-scraper/blob/f89b86d07d39d99c8c123717227fbc773d4933c3/court_scraper/base/parse.py#L54

@palewire Heads up that we're doing some house-cleaning prior to v0.1.0 release and this file is going to be deleted as part of #96. Hoping to drop that release by end of week. Would love a once-over after we've merged and released changes. You can see what's on the menu by checking out tix flagged with the v0.1.0. milestone


feat: support parallel compress snapshot

improve #2116

Hi, thanks for the contribution, for better review and reduce a lot of time in code-style problem
It's highly recommended to use our style config if u use IDEA, import the style file and reformat your code 📑
and also fix the CI problems & add license header as the CI alerts
and @JackyYangPassion could check the reason why it blocks the action comment in PR (maybe lack some permission?)

also remove  the RAT Check in ci.yml, because it will block the ci progress & we could do it separately

and @JackyYangPassion could check the reason why it blocks the action comment in PR (maybe lack some permission?)

for this PR #2139

Hi, thanks for the contribution, for better review and reduce a lot of time in code-style problems, It's highly recommended to use our style config if u use IDEA, import the style file and reformat your code 📑
and also fix the CI problems -> add license header & fix security problem as the CI alerts (could copy from the exist file)

Thanks for your review, code style has fixed, but fix security problem as the CI alerts I don't know how to fix it

CI error:
[INFO] Running org.apache.hugegraph.api.ApiTestSuite
Error:  Tests run: 69, Failures: 32, Errors: 1, Skipped: 0, Time elapsed: 2,511.93 s <<< FAILURE! - in org.apache.hugegraph.api.ApiTestSuite
Error:  testTruncate(org.apache.hugegraph.api.GremlinApiTest)  Time elapsed: 1.173 s  <<< FAILURE!
java.lang.AssertionError: Response with status 500 and content {"exception":"java.lang.IllegalStateException","message":"The snapshot future can't be null","cause":"[java.lang.IllegalStateException]"} expected:<200> but was:<500>
	at org.apache.hugegraph.api.GremlinApiTest.testTruncate(GremlinApiTest.java:139)


Sonoff does not load entities without internet

Hello dear,
I have HA running on windows 10 hyperv.
I bought Sonoff products as these are the only ones available in the market here.
I got one Sonoff RF Bridge and one Mini Switch and one Camera GK-200
Using the below code in configuration.yaml, HA is loading all of the three entities together with the RF sensors:
sonoff:
  username: xxx
  password: xxx
  rfbridge:
    Door Sensor:  # sensor name in eWeLink application
      name: Door Sensor # optional, you can change sensor name
      device_class: door  # e.g. door, window
      timeout: 60
    Motion Sensor:  # sensor name in eWeLink application
      name: Motion Sensor # optional, you can change sensor name
      device_class: motion
      timeout: 60  # optional (default 120), timeout in seconds for auto turn off

I disconnected the DSL plug from the router to test loading entities locally, the above three entities were not loaded.
I added the below code to the configuration file but with no avail:
mode: local
reload: always

Can you please advise what is wrong or missing here as i tried all possible ways I know.
Thank you.
Michel

Can you please post your config again, using the 'insert code' tag, so its formatted properly?
reload: always forces the code to check the cloud on each startup. This should only been needed if you need to check the cloud every single time.
mode: local forces only local (LAN) mode. This should not be needed either, as by default the code will use cloud and local automatically as is needed. You would only need to force 'local' only if you really really don't want the devices potentially talking to the internet.

Hey wishie,
Here is the code i used:
sonoff:   username: xxx   password: xxx   rfbridge:     Door Sensor:  # sensor name in eWeLink application       name: Door Sensor # optional, you can change sensor name       device_class: door  # e.g. door, window       timeout: 60     Motion Sensor:  # sensor name in eWeLink application       name: Motion Sensor # optional, you can change sensor name       device_class: motion       timeout: 60  # optional (default 120), timeout in seconds for auto turn off
Here is the debug log when there is an internet connection:
2020-09-14 06:47:21  DEBUG    main          SysInfo: {'version': '0.114.4', 'dev': False, 'hassio': True, 'virtualenv': False, 'python_version': '3.8.3', 'docker': True, 'arch': 'x86_64', 'os_name': 'Linux', 'os_version': '5.4.63', 'supervisor': '243', 'host_os': 'HassOS 4.13', 'chassis': 'vm', 'docker_version': '19.03.11'} 2020-09-14 06:47:21  DEBUG    main          AUTO mode start 2020-09-14 06:47:23  DEBUG    sonoff_cloud  Redirect to region: as 2020-09-14 06:47:27  DEBUG    sonoff_cloud  3 devices loaded from the Cloud Server 2020-09-14 06:47:27  DEBUG    main          1000c4909b == Init   | {'uiid': 1, 'extra': {'manufacturer': 'SONOFF', 'model': 'MINI', 'sw_version': 'PSF-BD1-GL v3.6.0'}, 'params': {'version': 8, 'sledOnline': 'on', 'switch': 'off', 'fwVersion': '3.6.0', 'rssi': -73, 'staMac': '...', 'startup': 'stay', 'init': 1, 'pulse': 'off', 'pulseWidth': 60000, 'swMode': 2, 'bindInfos': {'scene': 2}, 'swCtrlReverse': 'off', 'cloud': 'online'}} 2020-09-14 06:47:27  DEBUG    main          a640002ac8 == Init   | {'uiid': 87, 'extra': {'manufacturer': 'coolkit', 'model': 'GK-200MP2B', 'sw_version': 'GK-200MP2B'}, 'params': {'romVersion': '24520191030', 'version': 7, 'cloud': 'offline'}} 2020-09-14 06:47:27  DEBUG    main          1000bd4c9a == Init   | {'uiid': 28, 'extra': {'manufacturer': 'SONOFF', 'model': 'RFBridge', 'sw_version': 'PSF-BRA-GL v3.5.0'}, 'params': {'version': 8, 'sledOnline': 'on', 'ssid': 'blink921', 'bssid': 'c4:6e:1f:58:8f:a0', 'init': 1, 'fwVersion': '3.5.0', 'rssi': -53, 'staMac': '...', 'setState': 'arm', 'rfList': [{'rfChl': 0, 'rfVal': '2698015E03F2C9CE0E'}, {'rfChl': 1, 'rfVal': '262A01680406AA4329'}], 'cmd': 'trigger', 'rfChl': 1, 'rfTrig1': '2020-09-13T18:07:47.000Z', 'rfTrig0': '2020-09-13T18:07:23.000Z', 'cloud': 'offline'}} 2020-09-14 06:47:29  DEBUG    sonoff_cloud  Cloud init: {'error': 0, 'apikey': '...', 'config': {'hb': 1, 'hbInterval': 145}, 'sequence': '1600055249043'}
and this one without internet connection:
2020-09-14 06:51:13  DEBUG    main          SysInfo: {'version': '0.114.4', 'dev': False, 'hassio': True, 'virtualenv': False, 'python_version': '3.8.3', 'docker': True, 'arch': 'x86_64', 'os_name': 'Linux', 'os_version': '5.4.63', 'supervisor': '243', 'host_os': 'HassOS 4.13', 'chassis': 'vm', 'docker_version': '19.03.11'} 2020-09-14 06:51:13  DEBUG    main          AUTO mode start 2020-09-14 06:51:18  ERROR    sonoff_cloud  Coolkit API error: Cannot connect to host eu-api.coolkit.cc:8080 ssl:default [Try again]

Remove the reload: always and how me the logs please.
You should have a file called .sonoff.json in your config directory.. can you confirm it is there please

@mishoco read readme "common problems in only LAN mode" section

@wishie I confirm that .sonoff.json file is there. Here is the log with mode: local and without the reload: always
2020-09-14 16:02:54  DEBUG    main          SysInfo: {'version': '0.114.4', 'dev': False, 'hassio': True, 'virtualenv': False, 'python_version': '3.8.3', 'docker': True, 'arch': 'x86_64', 'os_name': 'Linux', 'os_version': '5.4.63', 'supervisor': '243', 'host_os': 'HassOS 4.13', 'chassis': 'vm', 'docker_version': '19.03.11'}
2020-09-14 16:02:54  DEBUG    main          LOCAL mode start

@AlexxIT I checked the readme and i have the below:
Devices are not displayed
Only supported devices with firmware v3+: i have firmware 3.5
Common problems with Multicast:
two routers: I have only one router
virtual machine with port forwarding. you must use bridge virtual network mode (not NAT mode): i am using HyperV External Network Bridge mode

@mishoco maybe your HA and devices in different VLAN. Or you have block traffic between LAN devices. Or HyperV has problems with Multicast like VirtualBox.

I can confirm that they are on the same LAN subnet. Alex is there a way to troubleshoot Multicast?

You can try enable zeroconf logs...
logger:
  default: warning
  logs:
    zeroconf: debug

Thank you Alex for the feedback. I got one related error to sonoff from the log when i restarted HA with no internet as below:
Log Details (ERROR)
Logger: homeassistant.setup
Source: custom_components/sonoff/sonoff_cloud.py:282
First occurred: 9:28:36 PM (1 occurrences)
Last logged: 9:28:36 PM
Error during setup of component sonoff
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/setup.py", line 191, in _async_setup_component
result = await task
File "/config/custom_components/sonoff/init.py", line 102, in async_setup
if await registry.cloud_login(config[CONF_USERNAME],
File "/config/custom_components/sonoff/sonoff_main.py", line 110, in cloud_login
return await self.cloud.login(username, password)
File "/config/custom_components/sonoff/sonoff_cloud.py", line 282, in login
if resp.get('error') == 406:
AttributeError: 'NoneType' object has no attribute 'get'

I also have this detailed log when mode: local is used
DetailedLog.txt

Probably fixed in latest master-version


Increase role time required for CE,CMO,HOS by 5 times.

🆑 Emisse

add: Role Time Requirements for CE,CMO,HOS increased by 5x

this should probably have an actual player facing changelog.

Take it this was discussed somewhere? Seems very MRP when the originals were designed to be very light, and high timers were very opposed?

This brings the timer from the current 5 hours to 25 hours. This seems a bit unreasonably high. There are outstanding issues with role timers saving, and it's going to be frustrating working up the hours again. This also doesn't address the root issue, which is that unfortunately it's possible to fill role time without understanding what's going on in the department. It doesn't address idling for role time.
If what we really want is to demonstrate role competency suitable for a high(er) roleplay environment, then we should have a different mechanism of assessing competence. Maybe an online quiz? Something a bit more nuanced than making the numbers on the timers bigger.
If this is change happens, count me out of playing these roles.

25 hours is gross overkill.

There are outstanding issues with role timers saving

No there isn't?

25 hours is gross overkill.

There are outstanding issues with role timers saving

No there isn't?

See #10655. Just because the issue isn't easily reproducible, and because complaints have died down, doesn't mean the issue has quietly gone away. I don't care about this issue (anymore) because I'm no longer impacted.

I don't care about this issue

You're the only one I've seen report it so if you don't provide more info then nothing is happening.

I don't care about this issue

You're the only one I've seen report it so if you don't provide more info then nothing is happening.

Multiple admins are aware of the issue. If you want me to name them out by name, I can. The OCC copied on Discord is also searchable. Just because I'm the only one to file a Github issue doesn't mean I'm the only reporter. I don't have server-side access to debug the issue. I've tried multiple times to reproduce the issue locally, to no avail. I'm out of the limited resources I have.

5 hours, is probably somewhere between 5 - 11 rounds doing a single department. Assuming this is a new player, they probably have tried playing some other role as well. If they don't get how to play by that point, they probably aren't going to do well at the job, regardless of how high the wait time is. While setting it to 25 hours might prevent some bad eggs from getting into command positions, I think this is much more likely to make new people who might of liked the roles quit before they get there, and cause other new players to be intimidated by the game. It will also greatly increase the desire to cheat the AFK system, or find other ways to waste time, because people will feel forced to keep the game playing to unlock these roles. I think this will hurt the game, so I am closing this.

I think 5 hours is too short considering the sheer amount of command staff players we see daily who do not know how to do the basics of the job or even what the job entails. These players actively degrade round quality from everyone else and contribute basically nothing being a learner in a role which should already know these things. When a CMO doesn't know how to clone or a CE doesn't know how to setup a power is a daily occurrence that is proof the current timer length is too short. I think the notion of trying to make every area of this game as accessible as possible to new players at the detriment of round quality and player experience is hurting the game. I also think making timers short makes time wasting/macroing more enticing since they think 'don't have to do it for that long'. I would honestly consider setting head roles to upwards of 50+ hours. Reluctance to do anything about this will further impact round quality daily as well with current administration issues, player culture, and maintainers not actually playing the game to know what the player experience even is right now.

Maybe a longer total play time requirement, along with this shorter department specific one, or some kind of minimum rounds played requirement, or a minimum account life requirement, or something like that would work better.

5 hours, is probably somewhere between 5 - 11 rounds doing a single department. Assuming this is a new player, they probably have tried playing some other role as well. If they don't get how to play by that point, they probably aren't going to do well at the job, regardless of how high the wait time is. While setting it to 25 hours might prevent some bad eggs from getting into command positions, I think this is much more likely to make new people who might of liked the roles quit before they get there, and cause other new players to be intimidated by the game. It will also greatly increase the desire to cheat the AFK system, or find other ways to waste time, because people will feel forced to keep the game playing to unlock these roles. I think this will hurt the game, so I am closing this.

Hi. You're not the administration team, this is an admin discussion.

I hope my two cents will be considered here:
I think we all agree we want a more fun game, whatever that means. It's just that we disagree how to get there. Clearly incompetent heads are demoralizing for players playing around them. We want a way to make sure that heads are reasonably competent.
Admins have a slider (role timers) that they can increase to increase competency, even if marginally. On the other hand, as a (I like to consider myself) competent player, increasing role timers, especially if I have to get more hours again, feels patronizing. It might also be a barrier to incoming players as @wrexbe has already stated.
On the other hand, the existing role timers are clearly not doing enough. I'm going to list a few alternatives, let's pretend we can fiat them into existence (code wise):

Roleban more incompetent heads (probably too taxing on the admin team)
Whitelist admin heads (might take a long time for admins to get around, admins don't see everything)
An online quiz to demonstrate basic job competency (people might cheat on quizzes)
An in-game performance review mechanic, e.g. only existing heads can promote others into head positions (players might spoil it)

I've brought up some of the drawbacks I could think of for each alternative, there are likely more. But I hope this gets the discussion headed off in the right direction.

I disagree with raising the role limits for the previously mentioned reasons, and I believe the core of the problems is that new players don't have any way of actually learning their role in-game, no matter how long they spend on it. We can't rely on them being told what to do by other players to learn how to perform their roles, so we need to estabilish some root knowledgebase that players will be able to build upon when learning how to play the game.
My preferred way of doing this is having in-game, in-world guidebooks for roles that should entirely cover the basics of each role and touch on advanced topics, as opposed to the wiki culture that has appeared on some SS13 servers.
That said, in the short term, raising role timers for head roles is a way to paper over the problem, but 25 hours is extreme for players who don't take the game super seriously, which they shouldn't have to. The same players who managed to not learn anything about a role while playing it for 5 hours will manage to repeat that feat however many times they need to in order to get higher access on their ID card, while people who want to spice up their gameplay by taking on more responsibility will be faced with a dull "grind" of playing the same role over and over until the timer is fulfilled so they can actually play something new.

Is this even a major issue on the MRP server? I think this will mostly be solved by having an in game tutorial per role, while increasing the amount of hours judt completely counts out casual players and locks even more of the limit job content that we have for newer players.

this also means roles that require time played in heads require many more hours

Too early, maybe in 2 to 4 years.


Question: docker compose pull type functionality

This is a fantastic project, and I love that it exists!
I'm used to being able to say docker compose pull to make sure all my containers are up to date, especially with tags like latest. How can I do the same thing with nerdctl?
I already tried nerdctl compose pull and that wasn't in the list of supported commands. I also didn't find a command option that I could say "always pull" or something like that to ensure my images are up to date.
Thanks!

Hi @dkowis ,
I assume that docker-compose pull don't ensure up to date images.  This can be done with docker-compose build --pull.
nerdctl compose pull and nerdct compose build --pull are not yet implemented

Added naive implementation in #546

Thanks @afbjorklund


Add rewriting for Concept URIs in wikibases

Following the same scheme proposed in T58307 for wikidata and
using an adapted version of operations/apache-config main.conf
but adapted for .htaccess rather than apache config file

This was only added to 1.30/base/htaccess
I guess this needs to also be in the other images?!!!


Visually separate errors from non-zero exits

RIght now they are both red, having non-zero exitcodes a different color makes it easier to visually identify them. Could be combined with --expect-code 1 to specify which code(s) we want to see.

Done in #75


feat(logs): allow for a specific query of one to n containers

so you can pass in any number of log ids to the log command to only filter on those containers

I just tested locally and it works when specifying container ids, but otherwise returns nothing...
$ ./harbor-compose logs 3fd6d79
Logs For:  mss-poc-thingproxy2 dev
[3fd6d79]
mss-poc-thingproxy2:3fd6d79  | ><EMAIL_ADDRESS>start /usr/src/app
mss-poc-thingproxy2:3fd6d79  | > node server.js
mss-poc-thingproxy2:3fd6d79  | thingproxy started
mss-poc-thingproxy2:3fd6d79  | 2016-10-26T20:41:18.911Z <IP_ADDRESS> GET /health2
mss-poc-thingproxy2:3fd6d79  | 2016-10-26T20:42:18.910Z <IP_ADDRESS> GET /health2
$ ./harbor-compose logs
Logs For:  mss-poc-thingproxy2 dev
[]
$ ./harbor-compose logs -s
Logs For:  mss-poc-thingproxy2 dev
[]
$ ./harbor-compose logs -t
Logs For:  mss-poc-thingproxy2 dev
[]
^C

updated @jritsema to fix that bug

LGTM


SQLITE_CANTOPEN: unable to open database file / RPI 4

Checklist

Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?

Yes / No

Are you sure you're not using someone else's docker image?

Yes / No

Have you searched for similar issues (both open and closed)?

Yes / No

Describe the bug

With option DB_SQLITE_FILE enabled the system gets a failure and the Login got Bad Gateway.
[5/23/2021] [7:48:28 PM] [Global   ] › ✖  error     SQLITE_CANTOPEN: unable to open database file
Nginx Proxy Manager Version

2.9.3
To Reproduce
Docker-Compose
    container_name: Proxy-Manager
    image: jc21/nginx-proxy-manager:latest
    restart: always
    environment:
        - DB_SQLITE_FILE="/data/npm.sqlite"
    volumes:
        - ./data:/data
        - ./letsencrypt:/etc/letsencrypt
    networks:
        internal:
            ipv4_address: XXX.XXX.XXX.7
        br0:
            ipv4_address: XXX.XXX.XXX.9
    ports:
        - 443:443
        - 80:80
        - 81:81

Expected behavior

System should work.
Operating System

Raspberry PI 4 8GB
Additional context

I was reading for hours now but don't find a solution which is working for me.
Coming from jlesage/nginx-proxy-manager but is not working on RPI.
I don't want a additional DB externally.

I have the same problem, I updated a few days ago to the latest version of nginx and alpine-mariadb, result :
✖  error  connect ECONNREFUSED IP:port     ( thy IP:port  is the alpine-mariadb)

@dabm-git Your problem is entirely different from the original issue, since you are using a mariaDB and this issue is about an SQLite database.
@Karatekid2407 Can you check if the file /data/npm.sqlite exists? And what the permissions of this file are? You can connect inside the container and execute the command ls -la inside the /data directory, and paste the line containing npm.sqlite here.

When I create the container there will be no sqlite file created.
I tried it to add it from my previous container on Unraid with "jlesage/nginx-proxy-manager" BUT this does also not work.
chmod and chown was added with 777 and root:root
Will be add a screenshot afterwards.

Could you check if /app/config/production.json file is created successfully? Is there anything else in the log which could have to do with this issue?

Yes its generated. The log which I get in Docker.
Log from Docker
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.

[s6-init] ensuring user provided files have correct perms...exited 0.

[fix-attrs.d] applying ownership & permissions fixes...

[fix-attrs.d] done.

[cont-init.d] executing container initialization scripts...

[cont-init.d] 01_s6-secret-init.sh: executing...

[cont-init.d] 01_s6-secret-init.sh: exited 0.

[cont-init.d] done.

[services.d] starting services

[services.d] done.

❯ Enabling IPV6 in hosts: /etc/nginx/conf.d

  ❯ /etc/nginx/conf.d/include/proxy.conf

  ❯ /etc/nginx/conf.d/include/block-exploits.conf

  ❯ /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf

  ❯ /etc/nginx/conf.d/include/ssl-ciphers.conf

  ❯ /etc/nginx/conf.d/include/assets.conf

  ❯ /etc/nginx/conf.d/include/ip_ranges.conf

  ❯ /etc/nginx/conf.d/include/force-ssl.conf

  ❯ /etc/nginx/conf.d/include/resolvers.conf

  ❯ /etc/nginx/conf.d/production.conf

  ❯ /etc/nginx/conf.d/default.conf

❯ Enabling IPV6 in hosts: /data/nginx

sqlite does not support inserting default values. Set the `useNullAsDefault` flag to hide this warning. (see docs http://knexjs.org/#Builder-insert).

[5/25/2021] [11:04:19 AM] [Global   ] › ✖  error     SQLITE_CANTOPEN: unable to open database file

Maybe it has to do something with https://github.com/jc21/nginx-proxy-manager/issues/700. You can try to create your own production.json with the content as in the aforementioned issue including the useNullAsDefault line. Have a look at the documentation for information on how to mount it into the container

You are right. This fixed the Issue! Can you insert the fix in the repo?

Sure, but I will close this in favor of https://github.com/jc21/nginx-proxy-manager/issues/700.

Problem started again and fix from above now did not work anymore.
Tried multiple versions and did not find any solution.
Config is working and websites are visible but admin panels says bad gateway

Fixed by delete

USER_ID=99
GROUP_ID=100
DB_SQLITE_FILE="/data/database.sqlite"

Uncomment this if IPv6 is not enabled on your host

DISABLE_IPV6=true


Uncaught InvalidCharacterError: Failed to execute 'add' on 'DOMTokenList': The token provided ('P...

[Enter steps to reproduce:]

define a variable that looks like this:
directorio = r'C:\Users\YLope\OneDrive\Documentos\UPV\Python Projects\TFM\Datos\'

Atom: 1.35.1 x64
Electron: 2.0.18
OS: Microsoft Windows 10 Home
Thrown From: Atom Core
Stack Trace
Uncaught InvalidCharacterError: Failed to execute 'add' on 'DOMTokenList': The token provided ('Projects\TFM\Datos'
"') contains HTML space characters, which are not valid in tokens.
At C:\Users\YLope\AppData\Local\atom\app-1.35.1\resources\app\static\<embedded>:14

Error: Failed to execute 'add' on 'DOMTokenList': The token provided ('Projects\TFM\Datos\'
"') contains HTML space characters, which are not valid in tokens.
    at SuggestionListElement.addClassToElement (C:/Users/YLope/AppData/Local/atom/app-1.35.1/resources/app/static/<embedded>:14:1970103)
    at SuggestionListElement.renderItem (C:/Users/YLope/AppData/Local/atom/app-1.35.1/resources/app/static/<embedded>:14:1971395)
    at SuggestionListElement.renderItems (C:/Users/YLope/AppData/Local/atom/app-1.35.1/resources/app/static/<embedded>:14:1967760)
    at ViewRegistry.performDocumentUpdate (C:/Users/YLope/AppData/Local/atom/app-1.35.1/resources/app/static/<embedded>:11:326599)

Commands
     -8:16.8.0 core:move-right (input.hidden-input)
     -8:12.7.0 hydrogen:run-all (input.hidden-input)
     -7:50.8.0 core:move-left (input.hidden-input)
     -7:46 hydrogen:run-all (input.hidden-input)
     -7:21.7.0 core:backspace (input.hidden-input)
     -7:18 autocomplete-plus:confirm (input.hidden-input)
  2x -7:13.7.0 hydrogen:run-all (input.hidden-input)
     -3:35 core:cut (input.hidden-input)
 24x -3:12.9.0 core:backspace (input.hidden-input)
     -2:54.8.0 core:paste (input.hidden-input)
 12x -2:43.3.0 core:copy (input.hidden-input)
     -2:30.5.0 core:paste (input.hidden-input)
     -2:29.3.0 core:move-left (input.hidden-input)
     -2:04.6.0 editor:newline (input.hidden-input)
     -0:44.2.0 core:move-left (input.hidden-input)
     -0:43.8.0 core:backspace (input.hidden-input)

Non-Core Packages
atom-material-syntax 1.0.8
atom-material-ui 2.1.3
autocomplete-python 1.14.0
block-comment-plus 0.5.1
file-icons 2.1.31
framer-syntax 1.1.0
framer-ui 2.0.0
highlight-selected 0.16.0
Hydrogen 2.8.0
kite 0.153.0
minimap 4.29.9
minimap-highlight-selected 4.6.1
python-autopep8 0.1.3
script 3.18.1

Thanks for the report! I'm guessing this isn't reproducible in safe mode (atom --safe)?
I think this is likely a duplicate of #16164 - based on that issue and #16305, my guess would be that autocomplete-python might be causing the error?
If you can reproduce in safe mode however, please let us know.

It appears that this is being caused by the autocomplete-python package, not Atom itself. It may be that there is still a bug in Atom. If so, we'll need the maintainer of the package that is causing the problem to help track that down. You should file this issue on their repository so they can either fix the problem or tell us where the problem is coming from. The Atom FAQ has information on how to contact the maintainers of any Atom community package or theme.


Charts as Inputs

Feature Description
The ability to click on a part of the data in one chart, and have the filter applied to all other charts.
Goal of Feature
Cross-filtering lets you interact with one chart and apply that interaction as a filter to other charts in the report.
Current Solution
Click through charts and having dedicated pages with the filters applied.
Alternative Ideas
NA
Examples / Screenshots
https://support.google.com/looker-studio/answer/9173401?hl=en#zippy=%2Cin-this-article
https://learn.microsoft.com/en-us/power-bi/create-reports/power-bi-reports-filters-and-highlighting#cross-filter-and-cross-highlight-visuals
Are you interested in contributing this feature?
Likely not

With the release of Universal SQL, this is now unblocked

Any update on this feature?


CMU Preprocessed Dataset

Great work @Samleo8 ! Is it possible of you could share the preprocessed data of the cmu panoptic dataset? Thanks

@Samleo8 I am having this issue while trying to generate labels for the cmu dataset. Could you please guide me how to resolve this? Thanks
Traceback (most recent call last):
File "generate-labels-npy.py", line 421, in
retval['table'] = np.concatenate(retval['table'])
File "<array_function internals>", line 6, in concatenate
ValueError: need at least one array to concatenate

Hello, have you solved the problem? How did you use detectron2 to pre-process the video?


resample doesn't work

MWE:
using Rasters, RasterDataSources, ArchGDAL
using Rasters, RasterDataSources, ArchGDAL
A = Raster(WorldClim{BioClim}, 5)
Rasters.resample(A; crs = "+proj=stere +lat_0=90 +lat_ts=75")
ERROR: MethodError: no method matching Projected(::LinRange{…}, ::DimensionalData.Dimensions.Lookups.ForwardOrdered, ::DimensionalData.Dimensions.Lookups.Regular{…}, ::DimensionalData.Dimensions.Lookups.Intervals{…}, ::DimensionalData.Dimensions.Lookups.NoMetadata, ::String, ::Nothing, ::X{…})

Closest candidates are:
  Projected(::A, ::O, ::Sp, ::Sa, ::MD, ::PC, ::MC, ::D) where {T, A<:AbstractVector{T}, O<:DimensionalData.Dimensions.Lookups.Order, Sp<:DimensionalData.Dimensions.Lookups.Span, Sa<:DimensionalData.Dimensions.Lookups.Sampling, MD, PC<:Union{Nothing, GeoFormat}, MC<:Union{Nothing, GeoFormat}, D}
   @ Rasters ~/.julia/dev/Rasters/src/lookup.jl:58
  Projected(::Any; order, span, sampling, metadata, crs, mappedcrs, dim)
   @ Rasters ~/.julia/dev/Rasters/src/lookup.jl:67

Stacktrace:
  [1] setproperties_object(obj::Projected{…}, patch::@NamedTuple{…})
    @ ConstructionBase ~/.julia/packages/ConstructionBase/Am9w7/src/ConstructionBase.jl:219
  [2] setproperties(obj::Projected{…}, patch::@NamedTuple{…})
    @ ConstructionBase ~/.julia/packages/ConstructionBase/Am9w7/src/ConstructionBase.jl:133
  [3] rebuild(x::Projected{…}; kw::@Kwargs{…})
    @ DimensionalData.Dimensions.Lookups ~/.julia/dev/DimensionalData/src/Lookups/Lookups.jl:65
  [4] setcrs(l::Projected{…}, crs::String; dim::X{…})
    @ Rasters ~/.julia/dev/Rasters/src/crs.jl:58
  [5] setcrs(dim::X{Projected{…}}, crs::String)
    @ Rasters ~/.julia/dev/Rasters/src/crs.jl:56
  [6] (::Rasters.var"#144#145"{String})(d::X{Projected{…}})
    @ Rasters ~/.julia/dev/Rasters/src/crs.jl:54
  [7] map
    @ ./tuple.jl:292 [inlined]
  [8] setcrs(dims::Tuple{X{Projected{…}}, Y{Projected{…}}}, crs::String)
    @ Rasters ~/.julia/dev/Rasters/src/crs.jl:54
  [9] setcrs(x::Raster{Float32, 2, Tuple{X{…}, Y{…}}, Tuple{Rasters.Band{…}}, Matrix{Float32}, Symbol, DimensionalData.Dimensions.Lookups.Metadata{Rasters.GDALsource, Dict{…}}, Float32}, crs::String)
    @ Rasters ~/.julia/dev/Rasters/src/crs.jl:53
 [10] resample(A::Raster{Float32, 2, Tuple{…}, Tuple{…}, Matrix{…}, Symbol, DimensionalData.Dimensions.Lookups.Metadata{…}, Float32}; to::Nothing, res::Nothing, crs::String, size::Nothing, method::Symbol, kw::@Kwargs{})
    @ RastersArchGDALExt ~/.julia/dev/Rasters/ext/RastersArchGDALExt/resample.jl:98
 [11] top-level scope
    @ REPL[100]:1

Yeah, GeoFormatTypes wrapped crs only so it doesn't need parsing.
Its actually working but the afterwards trying to set the crs in your lookups back to your proj string instead of the WKT gdal returns. But it fails cos it cant be a string.
Maybe we need a GeoFormatTypes.guess_format function.

Ah,  Rasters.resample(A; crs = GeoFormatTypes.ProjString( "+proj=ortho +type=crs")) works.  I'll PR to at least add an informative error if it's a string.

GeoFormatTypes.guess_format

I think we can at least guess for WKT and maybe proj string / proj json, and then potentially authorities?

epsg strings too, just start with epsg:

We should have had that forever omg

Oh the reason why I didn't is its not a real parser and wont actually check the string is correct, but gives the impression that it does.

Ah yeah that's fair.  Maybe we can have a method stub and the real implementation lives in Proj.jl or ArchGDAL?


Deleting profile things

When deleting a thing of your profile the (optional) photo of the thing is not deleted with the object/thing.

[master 7fb0275] hubzilla issue #868

Fixed in 7fb02752de4e3ee62d84eaf30bcb4c155ebabf30


Default Params related error

I have these defaults on my Vagrantfile:
config.user.defaults = {
    php: {
      folders: [],
      ports: [],
      networks: {
        private: [
          ip_address: '<IP_ADDRESS>'
        ]
      },
      cpus: 1,
      memory: 1024
    },
    ruby: {
      folders: [],
      ports: [],
      networks: {
        private: [
          ip_address: '<IP_ADDRESS>'
        ]
      },
      cpus: 1,
      memory: 1024
    }
  }

And here i define my vms:
  config.user.each do |node_id, node_config|
    config.vm.define node_id do |node|
      node_config.ports.each do |item|
        node.vm.network :forwarded_port, guest: item['guest'], host: item['host']
      end

      node_config.networks.private.each do |item|
        node.vm.network :private_network, ip: item['ip_address']
      end

      node_config.folders.each do |item|
        node.vm.synced_folder item['host'], item['guest']
      end

      node.vm.provider :virtualbox do |vb|
        vb.name = "#{node_id}-box"
        vb.cpus = node_config.cpus
        vb.memory = node_config.memory
      end

      node.vm.hostname = "#{node_id}-box.dev"
      node.vm.provision :hostmanager

      node.vm.provision :ansible do |ans|
        ans.playbook = "provisioning/#{node_id}.yml"
      end
    end
  end

The .vagrantuser file is empty.
When i run vagrant up i get this error:
Bringing machine 'php' up with 'virtualbox' provider...
Bringing machine 'ruby' up with 'virtualbox' provider...
==> php: Couldn't find Cheffile at ./Cheffile.
==> php: Clearing any previously set network interfaces...
/opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/util/network_ip.rb:24:in `ip_parts': undefined method `split' for nil:NilClass (NoMethodError)
	from /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/util/network_ip.rb:8:in `network_address'
	from /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/plugins/providers/virtualbox/action/network.rb:254:in `hostonly_config'
...

The output of the vagrant user parameters command is:
vagrant user parameters
/home/pablocrivella/.vagrant.d/gems/gems/nugrant-2.1.0/lib/nugrant/vagrant/v2/command/env.rb:5: warning: already initialized constant EnvExporter
/home/pablocrivella/.vagrant.d/gems/gems/nugrant-2.1.0/lib/nugrant/vagrant/v2/action/auto_export.rb:5: warning: previous definition of EnvExporter was here
# Vm 'php'
 All Parameters
 --------------------------------------------------
 config:
   user:
     php:
       folders: []
       ports: []
       networks:
         private:
         - :ip_address: <IP_ADDRESS>
       cpus: 1
       memory: 1024
     ruby:
       folders: []
       ports: []
       networks:
         private:
         - :ip_address: <IP_ADDRESS>
       cpus: 1
       memory: 1024

# Vm 'ruby'
 All Parameters
 --------------------------------------------------
 config:
   user:
     php:
       folders: []
       ports: []
       networks:
         private:
         - :ip_address: <IP_ADDRESS>
       cpus: 1
       memory: 1024
     ruby:
       folders: []
       ports: []
       networks:
         private:
         - :ip_address: <IP_ADDRESS>
       cpus: 1
       memory: 1024

Note the colon at the beginning of :ip_address:.
If i change that part of the defaults to use the old ruby hash syntax like this:
config.user.defaults = {
    php: {
      folders: [],
      ports: [],
      networks: {
        private: [
          'ip_address' => '<IP_ADDRESS>'
        ]
      },
      cpus: 1,
      memory: 1024
    },
    ruby: {
      folders: [],
      ports: [],
      networks: {
        private: [
          'ip_address' => '<IP_ADDRESS>'
        ]
      },
      cpus: 1,
      memory: 1024
    }
  }

I can run vagrant up with no issues.
The updated output of the vagrant user parameters command now is:
vagrant user parameters
/home/pablocrivella/.vagrant.d/gems/gems/nugrant-2.1.0/lib/nugrant/vagrant/v2/command/env.rb:5: warning: already initialized constant EnvExporter
/home/pablocrivella/.vagrant.d/gems/gems/nugrant-2.1.0/lib/nugrant/vagrant/v2/action/auto_export.rb:5: warning: previous definition of EnvExporter was here
# Vm 'php'
 All Parameters
 --------------------------------------------------
 config:
   user:
     php:
       folders: []
       ports: []
       networks:
         private:
         - ip_address: <IP_ADDRESS>
       cpus: 1
       memory: 1024
     ruby:
       folders: []
       ports: []
       networks:
         private:
         - ip_address: <IP_ADDRESS>
       cpus: 1
       memory: 1024

# Vm 'ruby'
 All Parameters
 --------------------------------------------------
 config:
   user:
     php:
       folders: []
       ports: []
       networks:
         private:
         - ip_address: <IP_ADDRESS>
       cpus: 1
       memory: 1024
     ruby:
       folders: []
       ports: []
       networks:
         private:
         - ip_address: <IP_ADDRESS>
       cpus: 1
       memory: 1024

P.S. I also had problems accessing the default params using symbols instead of strings, when i have values on the .vagrantuser file.

@pablocrivella Thanks for your links. I had already investigated this implementation (and two others). In general, there were two problems. First, they are usually not recursively enabling indifferent access meaning they work on the first level of keys but not deeply.
Also, I wanted to enable method access (like config.user.node[0].ip) for this project. It was sometimes problematic with some of the implementations I checked. In the end, I decided to go with a custom implementation fulfilling all my requirements.
Indifferent access was already working, just not for hashes inside arrays which were to converted to Bag (the class implementing all this). I released 2.1.3 which solves the issue.
Thank you for all your reports so far.
Best regards,
Matt

I released 2.1.2, not 2.1.3.

Great @maoueh, thank you!
My work-around until now was making everything a symbol on the params file :sweat_smile:
---
:ruby:
  :memory: 2048
  :folders:
    -
      :host: /Users/pablocrivella/Workspace/rails-apps/
      :guest: /home/vagrant/apps/


add tagged releases on hub.docker.com for 5.3.1 and 5.3.2

https://github.com/DataDog/dd-agent/releases/tag/5.3.2

Tag 5.3.2 got deployed on the Hub (not 5.3.1 since it is the same as 5.3.0 for Unix systems). Thanks for the warning!


[MRG] Early stop

This pull request resolves #288 .
The pull request is ready to be merged.
The details of the pull request:

Pull Request Test Coverage Report for Build 847

41 of 47 (87.23%)  changed or added relevant lines in 3 files are covered.
8 unchanged lines in 5 files lost coverage.
Overall coverage decreased (-0.5%) to 94.425%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

autokeras/nn/model_trainer.py
39
45
86.67%

Files with Coverage Reduction
New Missed Lines
%

autokeras/nn/model_trainer.py
1
92.97%

autokeras/cnn_module.py
1
94.92%

autokeras/net_transformer.py
1
97.53%

autokeras/search.py
1
97.28%

autokeras/bayesian.py
4
95.02%

Totals

Change from base Build 840:
-0.5%

Covered Lines:
2151

Relevant Lines:
2278

💛  - Coveralls


More Python for Mac OS X

More work in response to comments about Macports compatibility on opscode ticket for #25

Was using the python cookbook on my macbook and forked it and fixed my issue. Did a quick search of the issue queue to see if anyone else had run into this, and it turns out I did!
Updated to fix merge conflicts.

With homebrew as the default provider now, this should work out of the box with https://github.com/poise/poise-python using the system provider. I can't do automated tests on it though, so confirmation would be good.


Universal Control Plane (UCP) enhancements

Overview of roadmap item
Enhancements to the Universal Control Plane (UCP), including UCP Proxy, memory/CPU optimizations, and more.
Related issues
### Related issues
- [ ] https://github.com/radius-project/radius/issues/4878
- [ ] https://github.com/radius-project/radius/issues/351
- [ ] https://github.com/radius-project/radius/issues/6922
- [ ] https://github.com/radius-project/radius/issues/4943
- [ ] https://github.com/radius-project/radius/issues/5090
- [ ] and more...

Additional context

@kachawla @sylvainsf These work items are UCP security-related as I mentioned in the call.


Missing Transform2D and Quat  constructors

Godot version:
3.2.alpha.custom_build .ed9fe4587
OS/device including version:
Ubuntu 19.04
Issue description:
In Godot two constructors which are present in docs not working correctly:
Quat constructor not working(I can't even run project)
var q_Quat : Quat = Quat(Vector3(randf(),randf(),randf()))

Transform2D always return null
var q_Transform2D = Transform2D(Transform( Vector3(randf(),randf(),randf()),Vector3(randf(),randf(),randf()),Vector3(randf(),randf(),randf()),Vector3(randf(),randf(),randf()) ))
q_Transform2D.affine_inverse()

Error - Invalid call. Nonexistent function 'affinite_inverse' in base 'Nil'

Did these work previously?
What is the desired behavior of constructing a Transform2D from a Transform? For just copying values, to be in the same orientation, you'd need to flip Y. Should the constructor do this?
https://github.com/godotengine/godot/blob/master/core/variant_call.cpp#L1923 doesn't seem to have any code for this operation.

It is fixed in 4.0


Any limits on the size of the schema?

Really nice project, thank you!
Anyone tried it with large schemas and seen 1) performance degradation or 2) tsc using more relaxed typings because of the size?

Hello Alexander !
Thanks for the feedback 🤗
I use json-schema-to-ts on a large backend project (~200 routes, one schema each, small to medium-size), and did not notice any performance degradation. Our type test runs in ~20s.
I haven’t received any other feedback on performance degradation for the moment, so I think it’s ok.
I also never saw tsc relaxing the types.
The only issue I found on (very) large schemas is that you can sometimes encounter the following error: « Type instantiation is excessively deep and possibly infinite ».
That error is raised in the IDE but the types are still correctly inferred and it doesn’t happen on compilation 🤷♂ It is a bit annoying and I’d be happy to have examples if you encounter some.
It can be avoided by splitting the schema into smaller schemas and recombining the types by hand.
Cheers
Thomas Aribart
Developer
+33 6 75 44 45 48
48 bd des Batignolles
75017 Paris
Le 2 mars 2021 à 04:34 +0100, Alexander Rose<EMAIL_ADDRESS>a écrit :

Really nice project, thank you!
Anyone tried it with large schemas and seen 1) performance degradation or 2) tsc using more relaxed typings because of the size?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Thanks, @ThomasAribart, for the answer and for the suggestion of splitting and recombining schemas


623 ci with cml runtimes

Summary
Updating workflow to use cml runtimes to build and test the package when a pull request is created
Checklists

This pull request meets the following requirements:

[ ] installable with all dependencies recorded
[ ] runs without error
[ ] follows PEP8 and project specific conventions
[ ] appropriate use of comments, for example no descriptive comments
[ ] functions documented using Numpy style docstings
[ ] assumptions and decisions log considered and updated if appropriate
[ ] unit tests have been updated to cover essential functionality for a reasonable range of inputs and conditions
[ ] other forms of testing such as end-to-end and user-interface testing have been considered and updated as required
[ ] tests suite passes (locally as a minimum)
[ ] peer reviewed with review recorded

If you feel some of these conditions do not apply for this pull request, please
add a comment to explain why.

The workflow failed because of :
FAILED tests/staging/test_data_cleaning.py::test_clean_and_merge - TypeError:...
FAILED tests/utilities/test_constrains.py::test_replace_values_index_base - A...
More details in the workflows


websockets 14.0 support

See #1766
The websockets package released 14.0 which breaks us when using shiny run --reload.

As @gadenbuie noticed, the process_requests callback has changed.
Even with that fixed (as in this PR's first commit), it prints a scary looking error message: EOFError: stream ends after 0 bytes, before end of line and EOFError: connection closed while reading HTTP request line. I think this is happening because Shiny's VS Code extension connects via a raw socket just to see if a newly launched Shiny process is listening for requests yet, and if the connection is successful, it immediately closes the connection. The new websockets seems not to like this.

Once we get this working, I think we also need to decide whether to require 14.0, or to allow older versions and adapt to whatever version is being used.

Oh I forgot to mention how I solved the scary error message: by defaulting the websocket logger to CRITICAL. In theory this could squash legit error messages (that are specific to auto-reloading).
https://github.com/posit-dev/py-shiny/pull/1769/files#diff-be8712ed65f19637d0738c3495776b73a667e8f9e32a6ae4dea92328fe906259R173-R182
You can set SHINY_AUTORELOAD_LOG_LEVEL=DEBUG if you need to reveal those messages.

Oh I forgot to mention how I solved the scary error message: by defaulting the websocket logger to CRITICAL. In theory this could squash legit error messages (that are specific to auto-reloading).

It's hard to set this environment variable when you're debugging in VS Code, but I spent a while looking at both sides and I think ultimately this is the right choice, at least for now. I doubt Shiny users need to see any of the websockets debug messages; in fact, I'd think these messages are more likely to be noise or intimidating than useful. And in the edge cases where we or power users need to see them we still can.

LGTM, thank you!
@karangattu A note for QA: we should do some quick smoke tests in GitHub Codespaces, Posit Workbench, etc. before release just to be sure.

Yes, I can test it as soon as it is merged. Or. do you want me to checkout the branch and test it against that?

@gadenbuie Yeah, I ended up setting the environment variable in my ~/.zshrc. I was thinking about just leaving it on but it really is so distracting to have two stack traces appear every time you launch an app 😞
Wonder if websockets would be open to a PR that silences this particular case...

Wonder if websockets would be open to a PR that silences this particular case...

They might be open to it. It's very similar to another case where this kind of error appears that was fixed in 14.1 released last night. https://github.com/python-websockets/websockets/issues/1513


(iOS) CarouselView 4.4.3 Vertical XF ScrollView inside template is automatically disabled.

I have a Xamarin Forms project where I use a Vertical ScrollView on one of the templates inside of the CarouselView control.  I set the CarouselView to scroll only horizontally purposefully and set the XF ScrollView to only scroll vertically inside the template.  iOS does not permit me to scroll the ScrollView control at all; while Android has no problems and can scroll vertically.

If you take a look at the Demo, I use Horizontal carouselControl with Views that have Vertical ScrollView and they works.

Alex..  thanks for the quick response.  I'm going to borrow your code and see what the difference is between how I implemented my logic vs your demo.  I will let you know if I notice anything.

Alex ...  I think I figured it out.  Hopefully you find this helpful.  In my ContentPage, I was using a StackLayout control where I only had two controls in its content.  One of them was the CarouselView and the other was just a top label.  When I followed your code sample in the demo project in GitHub, I noticed you used the Grid control instead.  I replaced the StackLayout control with a Grid control for my own layout and it worked.
To be sure it wasn't something unintended, I modified your Demo pages and referenced a StackLayout control instead of the Grid and ran into the same issue (where I can't get the scrollview to work in iOS).  BTW, it works fine in Android.  I am including the demo pages that I modified so that you can see what I mean.  Thank you for the time you put into making a rather robust control.
DemoPageReplacement.zip

I ran into issues with StackLayout and MasterDetailPage before and couldn't find ways to solve them. They are related to Xamarin.Forms layout engine.

I will continue working on this control 'til it gets included in XF code base for version 3. Thanks


How to work dynamic property keys in valtio

Hi,
I got into a situation where I'm loading datasets into a Valtio proxy, but since I'm using dynamic property keys to store the dataset I'm getting the following error: TypeError: Cannot read property 'dataset' of undefined
I think this has something to do with how the proxies work.
This is the whole code:
import { proxy, useSnapshot } from 'valtio'

export interface DataSet {
  name: string
  dataset: Record<string, any>[]
}

type State = { sets: Record<string, DataSet>}

const state = proxy<State>({
  sets: {
    soccer: {
      dataset: [],
      name: 'Soccer Games',
    }
  },
})

export const useDataAggregator = () => {
  const snapshot = useSnapshot(state)

  const addData = ({ name, dataset }: DataSet) => {
    state.sets[name].dataset = [...dataset, ...state.sets[name].dataset]
  }

  return {
    state: snapshot,
    actions: {
      addData,
    },
  }
}

Any thoughts about what I’m missing?

Isn't it just how JS works?
  const addData = ({ name, dataset }: DataSet) => {
    if (!state.sets[name]) {
      state.sets[name] = {}
    }
    state.sets[name].dataset = [...dataset, ...state.sets[name].dataset]
  }

Closing as answered. Feel free to continue discussion.


Small prettierrc fix and addition + added .env example file

I had some issues with building the app-next, and after I fixed these issues I was able to succesfully build the app. There are still some problems left (10-20 warnings with the linter, a font woff2 file not available etc.), I will see if I can fix that.
I also added a dist/example .env file.

Thanks @matthijsthoolen! 👏
Quick question, what settings do you have in VSCode for Prettier/Vetur? I wasn't able to fix the formatting issue packages/app-next/src/modules/onboarding/components/Illustration.vue until now as something was always overwriting.

@morkro I am using PHPStorm for developing. Didnt change anything for prettier rc, just building it with the commands in the command line.
I do still need to change some things in my editor to match the prettierrc settings though

Right, got it. Thanks @matthijsthoolen 👏


[OpenCL] Compile error: casting changes address space of pointer

I am trying to get xsuite running on an AMD GPU with the OpenCL context using the simple example from the getting started guide. I get the following error:
Traceback (most recent call last):
  File "/xsuite/example.py", line 32, in <module>
    tracker = xt.Tracker(_context=context, line=line)
  File "/xsuite/xtrack/xtrack/tracker.py", line 101, in __init__
    self._init_track_no_collective(
  File "/xsuite/xtrack/xtrack/tracker.py", line 351, in _init_track_no_collective
    self._build_kernel(save_source_as, compile=compile)
  File "/xsuite/xtrack/xtrack/tracker.py", line 722, in _build_kernel
    context.add_kernels(
  File "/xsuite/xobjects/xobjects/context_pyopencl.py", line 271, in add_kernels
    prg = cl.Program(self.context, specialized_source).build()
  File "/usr/local/lib/python3.10/dist-packages/pyopencl/__init__.py", line 535, in build
    self._prg, was_cached = self._build_and_catch_errors(
  File "/usr/local/lib/python3.10/dist-packages/pyopencl/__init__.py", line 583, in _build_and_catch_errors
    raise err
pyopencl._cl.RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE - clBuildProgram failed: BUILD_PROGRAM_FAILURE - clBuildProgram failed: BUILD_PROGRAM_FAILURE

Build on <pyopencl.Device 'gfx906:sramecc+:xnack-' on 'AMD Accelerated Parallel Processing' at 0x564a3eb54d60>:

/tmp/comgr-f5172f/input/CompileSource:244:10: error: casting '__global char *' to type '__private char *' changes address space of pointer
  return (char*)(( __global char*) obj+offset);
         ^      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/comgr-f5172f/input/CompileSource:4612:10: error: casting '__global char *' to type '__private char *' changes address space of pointer
  return (char*)(( __global char*) obj+offset);
         ^      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/comgr-f5172f/input/CompileSource:4672:31: error: initializing '__private void *__private' with an expression of type '__global void *' changes address space of pointer
                        void* el = ElementRefData_member_elements(elem_ref_data, elem_idx);
                              ^    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/comgr-f5172f/input/CompileSource:4687:56: error: casting '__private void *' to type 'DriftData' (aka '__global struct DriftData_s *') changes address space of pointer
                            Drift_track_local_particle((DriftData) el, &lpart);
                                                       ^           ~~
/tmp/comgr-f5172f/input/CompileSource:4693:60: error: casting '__private void *' to type 'MultipoleData' (aka '__global struct MultipoleData_s *') changes address space of pointer
                            Multipole_track_local_particle((MultipoleData) el, &lpart);
                                                           ^               ~~
/tmp/comgr-f5172f/input/CompileSource:4699:67: error: casting '__private void *' to type 'ParticlesMonitorData' (aka '__global struct ParticlesMonitorData_s *') changes address space of pointer
                            ParticlesMonitor_track_local_particle((ParticlesMonitorData) el, &lpart);
                                                                  ^                      ~~
6 errors generated.
Error: Failed to compile source (from CL or HIP source to LLVM IR).

(options: -I /usr/local/lib/python3.10/dist-packages/pyopencl/cl)
(source saved as /tmp/tmp3o3ucscd.cl)

tmp3o3ucscd.cl.txt
My setup is an Ubuntu 22.04 with AMD OpenCL drivers (amdgpu-install --usecase=opencl), python 3.10 and the latest xsuite modules (git clone and pip install -e with the fix described in xsuite/xobjects#68 applied):
numpy               1.21.5
cffi                1.15.1
Cython              0.29.32
xdeps               0.0.10
xfields             0.8.4
xobjects            0.1.26
xpart               0.9.2
xsuite              0.4.0
xtrack              0.21.0
pyopencl            2022.2.4

If I select the CPU as device in the opencl context (<pyopencl.Device 'pthread-12th Gen Intel(R) Core(TM) i5-1235U' on 'Portable Computing Language' at 0x5559ba82e500>) I get the same error message.

In order to resolve this problem for now I suggest indeed building against OpenCL v2 which should be accomplished by https://github.com/xsuite/xobjects/pull/80. I will test the PR on an AMD machine myself, but please let me know if you have any issues with this.
In principle it should be possible to make this work with CL 1.2, but I am not sure if there is a need. What do you think?

It looks like a bug in the C side. A change of the address space does not seem intentional to me. In addition, OpenCL 2.0 is not supported by many vendors.

Indeed it was a bug in the tracker source (tolerated by cuda and OpenCL 2.0)
Pull request https://github.com/xsuite/xtrack/pull/263 should fix the bug and restore compatibility with OpenCL 1.3

Compare the two outputs for _getp1:
print(xo.Float64[:]._gen_c_api())
print(xo.String[:]._gen_c_api())

/*gpuglmem*/ is missing in a few places. Probably also 4 errors.

There is also a bug in gen_method_getp. It should be if is_scalar(lasttype) or is_string(lasttype). But I need to add a test.

I agree.
Pull request https://github.com/xsuite/xtrack/pull/263 should solve these ones:
/tmp/comgr-f5172f/input/CompileSource:4672:31: error: initializing '__private void *__private' with an expression of type '__global void *' changes address space of pointer
                        void* el = ElementRefData_member_elements(elem_ref_data, elem_idx);
                              ^    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/comgr-f5172f/input/CompileSource:4687:56: error: casting '__private void *' to type 'DriftData' (aka '__global struct DriftData_s *') changes address space of pointer
                            Drift_track_local_particle((DriftData) el, &lpart);
                                                       ^           ~~
/tmp/comgr-f5172f/input/CompileSource:4693:60: error: casting '__private void *' to type 'MultipoleData' (aka '__global struct MultipoleData_s *') changes address space of pointer
                            Multipole_track_local_particle((MultipoleData) el, &lpart);
                                                           ^               ~~
/tmp/comgr-f5172f/input/CompileSource:4699:67: error: casting '__private void *' to type 'ParticlesMonitorData' (aka '__global struct ParticlesMonitorData_s *') changes address space of pointer
                            ParticlesMonitor_track_local_particle((ParticlesMonitorData) el, &lpart);
                                                                  ^                      ~~

While these ones come from xobjects:
/tmp/comgr-f5172f/input/CompileSource:244:10: error: casting '__global char *' to type '__private char *' changes address space of pointer
  return (char*)(( __global char*) obj+offset);
         ^      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/comgr-f5172f/input/CompileSource:4612:10: error: casting '__global char *' to type '__private char *' changes address space of pointer
  return (char*)(( __global char*) obj+offset);
         ^      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

We should probably find a way of testing regularly on AMD

The problem was not only amd, I could reproduce on intel opencl as well!

I found a fix in #82. The PR is messy because there are many changes on the pipeline for xobjects, it is two lines.
I added also a test in test_capi that tests GPUs and that can be extended to test part of the C Api on gpus.
The fix was particularly tricky. Initially, I thought to return char ** for ArrayNString_getp1 which explicitly should become __global char * __global * , then I opted for a simpler _global char *

Should be solved. Don't hesitate to reopen if needed.


download error

in use
savePDF({ fileURL, data, name: fileName });
But defining
export const savePDF = async ({ fileUrl, data, name = "download.pdf" })
fileURL fileUrl is inconsistent

to fix your trouble check this solution click
maybe this will solve your problem.


black areas in line/area chart, and NaN's in the TSV data

Hi, we're getting some black areas in a few charts. Any idea what we could be doing wrong? Would having an empty value in the csv for some cells be a problem? I noticed when using the TSV export that there are "NaN" values in the exported data in some spots, and in other spots there is simply no value at all. The CSV input does not contain nulls or NaN's anywhere, but again a numeric cell might be empty at times.
Any ideas?
Example Chart:

Example Generated TSV data:
chart.xlsx

That's... interesting :) Can you provide a URL to a running example of this so I can poke at it a bit?

You are using the C3 renderer and the CSS files are missing (not included in DIST)
e.g.
https://cdnjs.cloudflare.com/ajax/libs/c3/0.4.11/c3.min.css
see Documentation:
https://github.com/nicolaskruchten/pivottable/wiki/Optional-Extra-Renderers


Checkpoint 1

What update/changes:

Complete UI
Complete modeling (embeded)
Complete Authentication/Authorization
Complete Integrate Database

Please review we're code coach, thankyou.


alpha border issue

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Ubuntu 17.04 - Godot v3.0.alpha.custom_build.3ae1cff
Issue description:

Sprites alpha border seems to be bit strange:

I used a completely white sprite in the example, there shouldn't be any gray outline.

Is "Fix Alpha Border" turned on in your import settings?

Yes I tried all options in the import docker, nothing fixes the issue

Don't forget to click on "Re-import"?

 So turns out I forgot about the stroke (in inkscape) so that's why there was the dark border. That being said, after fixing the images there still seems to be a problem here.
See attached project; both in editor & running game (for the complete solid white sprite - no blur):
godot-dbg.zip

FIxed by https://github.com/godotengine/godot/pull/12072?

Fixed by #12072.


Remove hard dependencies that live outside PyPI

Running baseplate actions against a vanilla virtualenv with just the PyPI install of baseplate breaks with a hard dependency on thrift (which is an optional requirement).  Upon installing thrift the error changes but appears to be due to a dependency on a different version of the thrift library.
Stacktrace from within a virtualenv:
$ python -m baseplate
Traceback (most recent call last):
  File "/usr/lib64/python2.7/runpy.py", line 163, in _run_module_as_main
    mod_name, _Error)
  File "/usr/lib64/python2.7/runpy.py", line 111, in _get_module_details
    __import__(mod_name)  # Do not catch exceptions initializing package
  File "<$PWD>/.venv/lib/python2.7/site-packages/baseplate/__init__.py", line 10, in <module>
    from .core import Baseplate
  File "<$PWD>/.venv/lib/python2.7/site-packages/baseplate/core.py", line 12, in <module>
    from thrift.util import Serializer
ImportError: No module named util

installed packages:
$ pip freeze
baseplate==0.23.1
certifi==2017.11.5
chardet==3.0.4
enum34==1.1.6
idna==2.6
posix-ipc==1.0.0
PyJWT==1.5.3
requests==2.18.4
six==1.11.0
thrift==0.10.0
urllib3==1.22

This should be fixed now that we're on Apache Thrift and 0.13 is available on PyPI.


Fix Image Path and Replace Images for the Calendar Icons

Here are the icons in light mode:

Here are the icons in dark mode:

Fixes #698

This PR actually additionally resolves #683!


Add TextControl to unify code of TextEdit and TextLine

Fixes #85511
Added TextControl as the parent of TextEdit and TextLine to consolidate code all the code between them, starting with the parts in listed in #85511
There's a lot more code that could be consolidated, but started with the sections listed in the bug report, just to test whether this is a viable solution.

I'm not sure about the usefulness of changing the inheritance for a single method, which as far as I know breaks compatibility as it rearranges the inheritance, but more importantly moves the enum which breaks compatibility as well
I think a less disruptive change is warranted here unless more shared code is unified

I'm not sure about the usefulness of changing the inheritance for a single method,
There are other methods, such as menu_option(int p_option), various selection methods (eg is_selecting_enabled()). and a lot of other methods/variables. where similar things are done but worded differently. Reducing this repetition would need to be an ongoing process with a bit being done at a time.

but more importantly moves the enum which breaks compatibility as well
Conceptually, the bug requires this break to be resolved. The entire issue is that there are two identical enums in separate classes. Either one is going to be removed or both are going to be merged in a separate place. Either way, at least one enum gets moved.

I think a less disruptive change is warranted here unless more shared code is unified
I'm open to suggestions.

Further the new class should be abstract as you shouldn't be able to instance it as it's incomplete
Makes sense.

tbh this is the least breaking change regarding the enums, because you can still use them directly in both classes and they retain their values.

It presumes that the change is needed in this form without adding all the shared code, if all the shared code is added in one PR that change makes sense, but otherwise it's assuming we need this compatibility breakage here instead of doing it some other way yet locking us into this change

I get what you're saying. You want the PR to do it all in one go so it can be evaluated on its own merits.
I'm gonna have to give this more thought. In the meantime I don't mind if anyone else wants to try their own approach or work off of what I've done.

For the menu one option would be to create a dedicated popup menu to share between these two, and provide it a method to call, similar to how ViewPanner works

That's actually the approach I'm looking into right now, I'm glad you think it would be a good solution to. Also thanks for mentioning ViewPanner, I didn't know about it before and it'll be very useful having a comparison.

The linked issue already covers the question of whether it would be rational to try and unify these controls. So I think going into this direction would be counter-productive. At the very least, it's a controversial and contested idea, and so doing a breaking change over it would be hard to justify.
There are shared bits of code, and I believe most of that duplication can be reduced without affecting user-facing facilities. I would suggest efforts to be put towards this solution.

I've noticed that LineEdit does a lot of things poorly compared to TextEdit and thought a lot about this, but I think these two classes are super different in everything aside from the part where you edit text. I've thought about having some kind of unexposed API for text editing operations that all these classes call to for basic things like text selections, drawing carets, and undo/redo. I'm not sure that's a good idea either, because it would make LineEdit a 1D wrapper dealing with unnecessarily complicated logic for 2D text, but I don't think it's a bad idea either as it would largely actually guarantee that there are no differences between the classes.


Failed to resolve: com.yalantis:contextmenu:1.0.2

Error:(27, 13) Failed to resolve: com.yalantis:contextmenu:1.0.2
Show in FileShow in Project Structure dialog
This Error occurred during adding this library in Gradle - Android Studio

You have an error somewhere inside you gradle.property files.
Works great with just created project.
build.gradle
buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.1.0'

        // NOTE: Do not place your application dependencies here; they belong
        // in the individual module build.gradle files
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

app module build.gradle
apply plugin: 'com.android.application'

android {
    compileSdkVersion 21
    buildToolsVersion "20.0.0"

    defaultConfig {
        applicationId "com.example.aleksandr.myapplication"
        minSdkVersion 15
        targetSdkVersion 21
        versionCode 1
        versionName "1.0"
    }

}

dependencies {
    compile 'com.yalantis:contextmenu:1.0.2'
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

I guess you missed repositories block. Just add the default one as in the general build.gradle above or add below block to your module build.gradle:
repositories {
    mavenCentral()
}

All the changes you described above have been done earlier by me in build.gradle file but the issue is same .

    build.gradle

    apply plugin: 'com.android.application'

    android {
    compileSdkVersion 21
    buildToolsVersion "21.1.2"

    defaultConfig {
        applicationId "hp_hp.example.com.application"
        minSdkVersion 14
        targetSdkVersion 21
        versionCode 1
        versionName "1.0"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
      }
    }

    repositories {
    mavenCentral()
    }

    dependencies {
    compile fileTree(include: ['*.jar'], dir: 'libs')
    compile 'com.android.support:appcompat-v7:21.0.3'
    compile 'com.google.android.gms:play-services:6.5.+'
    compile 'com.android.support:cardview-v7:21.0.3'
    compile 'com.yalantis:contextmenu:1.0.2'

    }

Try clean and sync gradle:
http://dl2.joxi.net/drive/0007/4089/520185/150225/807b27f805.jpg
http://dl2.joxi.net/drive/0007/4089/520185/150225/94c232aadb.jpg

Thank You so much, I think this error may be occurring as Gradle was running in offline mode.

Can i use minimum SDK 9 ???


Remove preview feature extendedIndexes

Final step of https://github.com/prisma/prisma/issues/12376

Branch ready to merge when the time comes.


bug_report.yaml: update links for HDProject 1.1

Included a link to the BIO4.sfv that came with 1.1, since I'm not sure whether that SFV is included in the update-only release.
E: ugh it got made as a draft PR again, should be fixed I think

Thank you, I was about to do that as well :p


Scroll to section with id from a hashed url

Describe the bug
It happened to me like in the issue 83 report https://github.com/solidjs/solid-app-router/issues/83 that luckily I solved it. Since I can scroll from the same page to the section with id. Eg
...
 using Link or NavLink.
But the problem is when I load the page from a url in a new tab, for example localhost:3000/#contact or localhost:3000#contact, the scroll is always positioned at the top.
I appreciate if you can tell me if I'm doing something wrong.
Your Example Website or App
https://digichanges.com/#about
Steps to Reproduce the Bug or Issue
If you click on the links, you will see that it scrolls correctly
If you load the url in the browser you will see that it does not scroll to the corresponding section https://digichanges.com/#about
Expected behavior
I would expect that when accessing the site, it would scroll to the section identified in the url after the #
Screenshots or Videos
No response
Platform

OS: [macOS, Linux]
Browser: [Chrome, Safari]

Additional context
Without the router it worked fine.

I've been testing for this and believe it has improved in the latest versions - albeit still an issue with one case.
I've tested

using a link/a to #contact with the same route - worked.
refreshing a page with #contact in the url - worked.
using a link from one route to another that includes #contact.  Weirdly that doesn't seem to work the first time - but then does scroll to #contact if going back to the original route and trying again.

The last case needs further investigation.

Looks like the reproduction doesn't use Solid anymore. So I can't reproduce currently. If this issue comes up again more than happy to look at it.


Standardize resource creation store logic

This change does the following:

Ensures ID and CreateAt values are generated as part of the
store logic. This standardizes the process and also resolves
a bug where the CreateAt value was not entered on the pointer
that was passed in.
Change the timestamp logic to match the cloud provisioner. The
previous logic did not calculate timestamps in the same way as
our standard GetMillis() implementation.

Note: Changing the time logic should be safe for two reasons: we
haven't officially started doing customer imports and only the
sorting logic may be affected.
Fixes https://mattermost.atlassian.net/browse/MM-41204

@Szymongib Migrations have been added. Also, the server startup did not check schema version which was dangerous so I added this as well.


Generate datamatrix barcodes

Encoding failing on Windows because some functions are not exported by the Windows DLLs. See https://github.com/NaturalHistoryMuseum/libdmtx-windows

@kursancew - apologies for the delay getting this merged and released. I need to compile new DLLs for Windows but, as I no longer have a Windows VM, it will likely take me some time to get done.


Just use markdown list for plain text backend

Markdown is already easy to read in plain text format.

bors merge


entrypoint does not exist

Hi,
I am failry new to both linux and docker. I think I have the basics under control though but apologies if I am missing something obvious.
When I try to lanuch the container after running the docker build command I get the following error:
exec /docker-entrypoint.sh: no such file or directory
I did some debugging and managed to rebuild the image so I could get the container to start up and debug it. The file IS there, and when i try to cat or execute I get the same error. I even ran a chmod 777 first.
Am i missing something obvious here? I am running docker for windows if that helps.

It turned out to be windows for Docker issue


Support Windows Runtime and mock libs that work on it i.e. SimpleStubs

Description
Windows Runtime libraries (UWP) and components are not supported by majority of testing tools properly. It would be great to have it supported by this generator. Unfortunately the only mock library which supports WinRT is SimpleStubs library by Microsoft (if I am wrong pls correct me).
Jacek

I added support for SimpleStubs in 1.4.1. Though if you want, you can still use Moq on UWP projects if the components you want to test are in PCL projects.