Impossible AbstractBigQueryInputFormat expectations when specifying a query

When using AbstractBigQueryInputFormat and its descendants:
If a query is specified via BigQueryConfiguration.INPUT_QUERY_KEY, and the table from which you are issuing the query against is specified as INPUT_TABLE_ID_KEY, QueryBasedExport.runQuery will fail with Already Exists: Table [tablename].
If you specify a new table name as INPUT_TABLE_ID_KEY, which will be used by QueryBasedExport.runQuery as @param tableRef the table to write the results to, the following failure will be experienced at com.google.cloud.hadoop.io.bigquery.AbstractBigQueryInputFormat.constructExport(AbstractBigQueryInputFormat.java:191):
{
  "code" : 404,
  "errors" : [ {
    "domain" : "global",
    "message" : "Not found: Table [tablename]",
    "reason" : "notFound"
  } ],
  "message" : "Not found: Table [tablename]"
}

It appears there is a mismatch of expectations. Both QueryBasedExport and the other Exports use the same table name / table reference, but they have mutually exclusive preconditions.
QueryBasedExport expects the table to not exist, while the logic of the AbstractBigQueryInputFormat expects that same table reference to already exist (https://github.com/GoogleCloudPlatform/bigdata-interop/blob/master/bigquery/src/main/java/com/google/cloud/hadoop/io/bigquery/AbstractBigQueryInputFormat.java#L191).

My current workaround is to create a new empty table with REQUIRED fields set to NULLABLE on job start (before utiliziing the InputFormat), then destroy that table as part of the job cleanup.

INPUT_QUERY_KEY has been deprecated for years and will probably not receive bug fixes.
I would encourage you to perform the query yourself at the top of your driver using google-cloud-bigquery or JDBC and then use the inputformat as normal.


issue with evolve_model in Gadget-2

Hi,

I made a gas cloud (with SPH particles) and used Gadget-2 to evolve, when I use some particles to evolve the system I have this problem.
 Traceback (most recent call last):
 File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/rfi/core.py", line 120, in __call__
  dtype_to_result = self.interface.channel.recv_message(call_id, self.specification.id, handle_as_array)
 File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/rfi/channel.py", line 1164, in recv_message
  raise exceptions.CodeException("Error in code: " + error_message)
amuse.support.exceptions.CodeException: Error in code: no error message - code probably died, sorry.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "paulo_newsMerger.py", line 643, in <module>
   accret1, t1, num1, acc_rate1 = main(N,mtot,rvir,t,T,Rsink,dt,20,1|units.MSun)
     File "paulo_newsMerger.py", line 374, in main
      hydro.evolve_model(time)
     File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/support/methods.py", line 168, in __call__
     result = self.method(*list_arguments, **keyword_arguments)
     File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/support/methods.py", line 168, in __call__
     result = self.method(*list_arguments, **keyword_arguments)
  File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/support/methods.py", line 168, in __call__
  result = self.method(*list_arguments, **keyword_arguments)
 File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/support/methods.py", line 267, in __call__
  return self.method(*list_arguments, **keyword_arguments)
 File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/rfi/core.py", line 123, in __call__
 raise exceptions.CodeException("Exception when calling function '{0}', of code '{1}', exception was '{2}' ".format(self.specification.name, type(self.interface).__name__, ex))
amuse.support.exceptions.CodeException: Exception when calling function 'evolve_model', of code 'Gadget2Interface', exception was 'Error in code: no error message - code probably died, sorry.'

I used redirection = "none" to be able to know what happened, they are the last 2 steps before the problem
Begin Step 939, Time: 9.65308, Systemstep: 0.00165722
domain decomposition...
 NTopleaves= 106
work-load balance=1   memory-balance=1
 domain decomposition done.
 begin Peano-Hilbert order...
 Peano-Hilbert done.
 Start force computation...
 Tree construction.
 Tree construction done.
  Begin tree force.
   tree is done.
    Start density computation...
     Start hydro-force computation...
     force computation done.
  Start time-stepping evaluation ...

 ---> number of timestep active gas particles:      1000
0) ---> number of timestep shrinked gas neighbors:       0
1.43741797656e+13 s
mass+gas right after acc= 100011.0
no density_threshold

Begin Step 940, Time: 9.66343, Systemstep: 0.00140862
domain decomposition...
NTopleaves= 106
work-load balance=1   memory-balance=1
domain decomposition done.
begin Peano-Hilbert order...
Peano-Hilbert done.
Start force computation...
Tree construction.
task 0: maximum number 1200 of tree-nodes reached.
for particle 996
task 0: endrun called with an error level of 1

the initial condition for the gas cloud is:

number SPH particles : 1000
time max : 1.0e6 yr
time step : 1000 or 10000 [yr]

-if I have 500 SPH particles the code run but this particles are very few. Do you have any idea what happened ?
Thanks in advance :), Cheers
Paulo

Dear Paulo,
It would help to see the script. But, simply stated, I thinkt hat your particle number is simply too small..
Almien
Simon
On Nov 26 2020, at 4:29 am, pasolar<EMAIL_ADDRESS>wrote:

Hi,
I made a gas cloud (with SPH particles) and used Gadget-2 to evolve, when I use some particles to evolve the system I have this problem.
Traceback (most recent call last):
File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/rfi/core.py", line 120, in call
dtype_to_result = self.interface.channel.recv_message(call_id, self.specification.id, handle_as_array)
File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/rfi/channel.py", line 1164, in recv_message
raise exceptions.CodeException("Error in code: " + error_message)
amuse.support.exceptions.CodeException: Error in code: no error message - code probably died, sorry.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "paulo_newsMerger.py", line 643, in
accret1, t1, num1, acc_rate1 = main(N,mtot,rvir,t,T,Rsink,dt,20,1|units.MSun)
File "paulo_newsMerger.py", line 374, in main
hydro.evolve_model(time)
File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/support/methods.py", line 168, in call
result = self.method(*list_arguments, **keyword_arguments)
File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/support/methods.py", line 168, in call
result = self.method(*list_arguments, **keyword_arguments)
File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/support/methods.py", line 168, in call
result = self.method(*list_arguments, **keyword_arguments)
File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/support/methods.py", line 267, in call
return self.method(*list_arguments, **keyword_arguments)
File "/Users/paulo/Amuse-env/lib/python3.6/site-packages/amuse/rfi/core.py", line 123, in call
raise exceptions.CodeException("Exception when calling function '{0}', of code '{1}', exception was '{2}' ".format(self.specification.name, type(self.interface).name, ex))
amuse.support.exceptions.CodeException: Exception when calling function 'evolve_model', of code 'Gadget2Interface', exception was 'Error in code: no error message - code probably died, sorry.'
I used redirection = "none" to be able to know what happened, they are the last 2 steps before the problem
Begin Step 939, Time: 9.65308, Systemstep: 0.00165722
domain decomposition...
NTopleaves= 106
work-load balance=1 memory-balance=1
domain decomposition done.
begin Peano-Hilbert order...
Peano-Hilbert done.
Start force computation...
Tree construction.
Tree construction done.
Begin tree force.
tree is done.
Start density computation...
Start hydro-force computation...
force computation done.
Start time-stepping evaluation ...
---> number of timestep active gas particles: 1000
0) ---> number of timestep shrinked gas neighbors: 0
1.43741797656e+13 s
mass+gas right after acc= 100011.0
no density_threshold
Begin Step 940, Time: 9.66343, Systemstep: 0.00140862
domain decomposition...
NTopleaves= 106
work-load balance=1 memory-balance=1
domain decomposition done.
begin Peano-Hilbert order...
Peano-Hilbert done.
Start force computation...
Tree construction.
task 0: maximum number 1200 of tree-nodes reached.
for particle 996
task 0: endrun called with an error level of 1
the initial condition for the gas cloud is:
number SPH particles : 1000
time max : 1.0e6 yr
time step : 1000 or 10000 [yr]
-if I have 500 SPH particles the code run but this particles are very few. Do you have any idea what happened ?
Thanks in advance :), Cheers
Paulo
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub (https://github.com/amusecode/amuse/issues/705), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ABCPFTEDZIGEODJHFM4UAFLSRXDQZANCNFSM4UDFVE7A).

Hi @spzwart

this is a fragment of my script
def gas(self):
  li_CPU= 10
  converter=nbody_system.nbody_to_si(self.Mtot,self.Rvir)
  gas=new_plummer_gas_model(self.N,convert_nbody=converter)
  hydro=Gadget2(converter, InitGasTemp=self.T ,EnergyFile = "energy.txt",redirection="none")
  hydro.parameters.begin_time = 0.0 | units.yr
  hydro.parameters.time_max = 2*self.t_end
  hydro.parameters.max_size_timestep = 0.5*self.dt
  return hydro,converter,gas`

'while time<t_end:
      #time = float(i)*dt
      time += dt/2.
      hydro.evolve_model(time)
      print (hydro.model_time)`

The problem is when I use a lot of SPH particles, for example, the code works fine when I use 500 SPH particles, but if I have 700 SPH particles, I have the problem, so the problem occurs when I evolve the script to 1.e6 [yr] but if I evolve to 1.e5 [yr] the code works fine with any number of particles

Cheers
Paulo

In SPH, 700 particles is a very small number. Remember that density etc are calculated by smoothing over 50 or so neighbouring particles. If you have few particles, this may be difficult to calculate correctly due to fragmentation. You should probably try with at least a factor 10 more particles.

Hi @rieder
Thanks for answer my question. I Know that I used few particles, so the problem is when I have a lot of particles, for example, the script breaks when I have 10.000 or 300.000 SPH particles, so more than 1000 SPH particles I have the problem when I evolve the code to 1.e6[yr], but if I evolve the code to 1.e5 [yr] the script work fine with 100.000 or more SPH particles.
Cheers


Bluetooth: BAP: Shell: BA fix add_pa_sync command

The command would attempt to parse the BASE and enter the subgroup information in a NULL pointer.
The BASE copy was also done incorrectly, as it did not properly take the UUID into account (which should be moved to a helper function if we expect users to do this).

@Thalley Is this labelled bug because it is one? Should it be backported to the 3.6 branch?
if so, please create a bug report and add the backport label

@Thalley Is this labelled bug because it is one? Should it be backported to the 3.6 branch? if so, please create a bug report and add the backport label

It does fix a bug, but it was not a reported bug, so I don't think the severity of this is high enough to warrant a backport.


Issue #407 - "invisible" text

The font color should be inherited to avoid "invisible" text.

Hey @frazjp65 ! Any ETA for merging this then pushing it in production?

@olivierlambert One of the project maintainers has to approve and merge this. I cannot. I did, however, fix some conflicts since I proposed the PR.

Thanks for the news @frazjp65 ! Keep up the good work 👍


Erratic memory problems in UCCSD & UCCSD(T)

I've been trying to set up some high-throughput generation of reference data at the UCCSD(T) level, but I've run into a wall of erratic memory problems that cause different behavior in different computing environments and with different memory settings (e.g. mol.max_memory or direct CCSD). Most crashes on Linux-based HPC end with a terse Killed output and an out-of-memory error in the dmesg log, but some also produce more explicit errors of attempting to generate hdf5 files in scratch that exceed scratch space (with enormous sizes that perhaps suggest negative workspace sizes reinterpreted as unsigned ints). These problems get worse when multiple calculations are run sequentially in the same Python script even after some basic attempts at forcing garbage collection to reduce the memory footprint. The value of Python-based quantum chemistry goes down a lot if you can't script a long sequence of multiple, dependent calculations...
A minimal example that is Killed on the 3rd calculation on a Linux-based HPC machine (and immediately Killed without cc.direct = True):
import gc
from pyscf.gto import Mole
from pyscf.scf import UHF
from pyscf.cc import UCCSD

mol = Mole()
mol.atom = '''
H 0.000000 0.000000 0.000000
H -2.096283 0.353834 -1.040359
H 2.644837 -1.118336 0.582054
H 1.887918 -2.260872 0.366561
H -1.280994 -1.732123 1.289924
H -2.264361 -5.267511 1.479492
'''
mol.basis = 'def2-QZVPP'
mol.charge = 1
mol.spin = 3
mol.build()
mol.max_memory = 800

for i in range(3):
    mf = UHF(mol).run()
    cc = UCCSD(mf)
    cc.direct = True
    cc.verbose = 9
    cc.conv_tol = 1e-3
    cc.conv_tol_normt = 1e-2
    cc.kernel()
    t = cc.ccsd_t()
    del mf, cc
    gc.collect()

For whatever reason, this example is able to run fine on my Mac laptop with much more limited memory and disk space. Both Mac and Linux are using pip-installed PySCF 2.1.1 from the binary wheel. I'm not familiar with memory leaks in Python, but this problem seems like a combination of memory leaks and workspace sizing errors.

I have an update. I see no evidence of memory leaking from tracemalloc, but I am seeing signs of deviation between PySCF's internal system of memory management and tracemalloc's more direct assessment of memory usage. This seems to be going both ways - total allocated memory is greatly exceeding max_memory in some places and PySCF's assessment of dwindling available memory is inconsistent with a relatively constant usage from tracemalloc in other situations. There is also a weird OS dependence to this as the assessment of memory usage in CCSD (max_memory xxx MB (current use yyy MB)) only ever reports zero for current use on my Mac laptop but produces growing, non-zero values on Linux. The reason for Killed outcomes instead of Python interpreter errors is because some of the out-of-memory events are occurring on the C side, such as within line 198 of _ao2mo.py.
The immediate fix seems like there needs to be some extra memory-related barriers in the code and I might need to forcibly reset PySCF's estimate of used memory after each completed calculation in a long script in lieu of actually fixing the memory management carefully.

Ok, so on Linux current_memory is an accurate measure of total memory usage of the process running PySCF, while it just returns zero on non-Linux machines. A growing discrepancy between current_memory and tracemalloc is then potentially a sign of memory leaking in the non-Python components of a PySCF calculation.

I'm going to close this issue for now. The problems I've been seeing are the result of compounded confusion from running unfamiliar software on unfamiliar hardware. The HPC test environment that I've been using had severe restrictions on memory usage that I was unaware of: I was requesting only a single core on a node rather than a full node and was limited to a proportionately small slice of memory.
While UCCSD & UCCSD(T) in PySCF seem to be "unfriendly" in a very memory-restricted environment relative to other features, this is very understandable. These calculations have an inherently much larger memory footprint, and planning a tight memory footprint of such calculations is probably a much more difficult task than the calculations themselves. While PySCF may not be doing an amazing job of it, I don't think any code is going to behave well in this regime.
I suspect that the "memory leak" I was seeing was just an "optical illusion" of CCSD calculations not strictly respecting the max_memory limit, switching between logical branches that have differing memory footprints, and possibly there might be instances of what were supposed to be lower-memory branches using more memory in some circumstances.
While I was hoping to run each instance of my workflow on 1 core, I will probably have to separate out the CCSD & CCSD(T) components to work with threading on several cores so as to have access to a larger memory footprint.


Stacks should prob have some sort of count indicator next to its sprite (in inventory)

Do a count indicator OR do the stackvisualizer idea like original ss13?
reported by @"Grandma#0105"

Nah

Doesn't IItemStatus already have the count?

Doesn't IItemStatus already have the count?

Yeah but I think they meant an overlay over the sprite when in your hand which is ???

They meant a stack number/indicator when inside a StorageComponent like a backpack.


Eunomo is causing issue with Mix.Tasks.Format

We recently tried to implement the new version of Eunomo in our app and ran into issues with it causing ElixirLS to return unable to fetch formatter_options errors. There is something weird happening because when I tried to reproduce it in a small application what ended up happening when I hit my format keybinding in a file in my editor is that Eunomo would sort the alias, import, and require blocks, but then it wouldn't do the usual formatting afterward. I wrote a simple test that can be run in the Eunomo project as an example of the issue:
defmodule FileTest do
  use ExUnit.Case

  test "sorts alias blocks, import blocks, require blocks, and also formats the file" do
    content = """
        defmodule Foo do
        alias Eunomo.Z.{L, I}
        alias Eunomo.Z

        def foo do
          1
        end
      end
    """

    IO.inspect(content, label: :content)

    assert :ok = File.write("foo.ex", content)

    {formatter, _opts} = Mix.Tasks.Format.formatter_for_file("foo.ex")

    {:ok, file} = File.read("foo.ex")

    formatted_string =
      formatter.(file) |> IO.iodata_to_binary() |> IO.inspect(label: :formatted_file)

    expected_result = """
      defmodule Foo do
        alias Eunomo.Z
        alias Eunomo.Z.{L, I}

        def foo do
          1
        end
      end
    """

    assert :ok = File.rm("foo.ex")

    IO.inspect(expected_result, label: :expected_result)
    formatted_properly? = String.equivalent?(formatted_string, expected_result)

    assert formatted_properly?
  end
end

My understanding is that this should sort the aliases alphabetically then also fix the indentation I added before the defmodule in content.

Hi @wilkinson4 thanks for the report! I will look into it over the weekend.

The issue is that the plugin system does not handle multiple formatters for the same extension. I did not notice that because it is not documented & I only tested the individual formatters. Unfortunate :(
v 1.14:
https://github.com/elixir-lang/elixir/blob/eb43a6a444c4aa9446ec1a7ad9801cedc897ab9d/lib/mix/lib/mix/tasks/format.ex#L511
  defp find_formatter_for_file(file, formatter_opts) do
    ext = Path.extname(file)

    cond do
      plugin = find_plugin_for_extension(formatter_opts, ext) ->
        &plugin.format(&1, [extension: ext, file: file] ++ formatter_opts)

    # We never match here :(
      ext in ~w(.ex .exs) ->
        &elixir_format(&1, [file: file] ++ formatter_opts)

      true ->
        & &1
    end
  end

In current main that already was partially fixed by allowing it for plugins. But still not in the combination with .ex/s files.
What to do?

Replace all three plugins with one plugin that also dispatches to the default Elixir formatter & passes opts along. Starting with Elixir 1.14.2 you should be able to split into 3 again (but have to run default formatter 3 times)— not good.
Ask upstream about intention & possible fixes (e.g. treat the default formatter as something that always runs before plugins)

For now, I would recommend staying with the previous release. I'll implement a fix in the coming week.

Published new version that should fix the issue. Note the slightly different config format in formatter.exs to avoid formatting every file 3 times.
Let me know if there are any problems.

Nice! Thank you!


styled-components not working.

styled-components does not work. Emotion works.
The versions are
    "rebass": "^4.0.7",
    "styled-components": "^5.1.1"

I have a simple component like below, when I import the styled-components version it crashes. Whereas if I do an import without styled-components(emotion). It works allright. This is for SSR with nextJS configured with styled-components.
The componet is
import * as React from 'react';
import { Box } from 'rebass/styled-components'

const Header: React.FC = (props) => {
  return (
      <Box>
        Hi this is a box
      </Box>
  )
}

export default Header;

The error is :
TypeError: (0 , _styledComponents.default) is not a function
./node_modules/reflexbox/styled-components/index.js
./node_modules/reflexbox/styled-components/index.js:40
  37 |   return (0, _css["default"])((0, _css.get)(theme, tx + '.' + variant, (0, _css.get)(theme, variant)))(theme);
  38 | };
  39 |
> 40 | var Box = (0, _styledComponents["default"])('div', {
  41 |   shouldForwardProp: _shouldForwardProp["default"]
  42 | })({
  43 |   boxSizing: 'border-box',
View compiled
__webpack_require__
./webpack/bootstrap:855
  852 | // Execute the module function
  853 | var threw = true;
  854 | try {
> 855 | 	modules[moduleId].call(module.exports, module, module.exports, hotCreateRequire(moduleId));
      | ^  856 | 	threw = false;
  857 | } finally {
  858 | 	if(threw) delete installedModules[moduleId];
View compiled

Can you provide a minimal version of your code?
styled-components works pretty well in my Blog (using Next.js with Rebass for quick bootstrapping)
for example, for Nav component

@Howard86 I just started having a look at rebass and the following reproduces this issue:
https://github.com/justin-calleja/rebass-styled-components
Thanks

hey @justin-calleja
In general, the following works pretty well with my next.js project.
import { Box } from "rebass/styled-components";

I have quickly tried your project and got the same error. I am afraid this is probably not related to rebass itself.
rebass/flexbox use defaultShouldForwardProp which is a helper function in styled-system, maybe you should leave an issue regarding to snowpack there.


functional tests: start rkt from a systemd service file

This test requires systemd on the host. It will be disabled when systemd is not running on the host.
You can start it manually with:
cd tests && ./test -run=TestServiceFile

It prints "HelloWorld" repetitively until the test stops it after 10 seconds.

Semaphore says SKIP: TestServiceFile (0.00s): it skips the test because Semaphore does not have systemd.

@alban can you drop f13d7a0 and bump the go-systemd dep instead please?

@jonboulle : updated.

LGTM


Combining progressive-controls + a-locomotor + physics

Is there an example on making this work? Is it supposed to work?
I tried every permutation of progressive-controls, a-locomotor and manual or autogenerated child entities and cameras, but i just can't figure it out.
Using Oculus Rift + Touch for testing at the moment, can try on Vive as well if necessary.
Having the a-locomotor inside of the progressive-controls entity with explicit .right-controller and .left-controller children nested below the locomotor (taken from the defaults in the readme) is the closest i got, in this case the right controller works as intended (being able to translate yourself) but the left controller doesn't, neither for translation nor for scaling when it is enabled.
      <a-assets>
        <a-mixin id="touch"
                 physics-collider
                 static-body="shape: sphere; sphereRadius: 0.02"
                 super-hands="colliderEvent: collisions;
                              colliderEventProperty: els;
                              colliderEndEvent: collisions;
                              colliderEndEventProperty: clearedEls"
                 collision-filter="group: hands; collidesWith: default; collisionForces: false" />
        <a-mixin id="interactable"
                 dynamic-body
                 collision-filter="collidesWith: default, hands"
                 grabbable="startButtons: triggerdown; endButtons: triggerup" />
        <a-mixin id="static"
                 static-body />
      </a-assets>

      <a-entity progressive-controls="touchMixin: touch; override: true">
        <a-locomotor horizontal-only="false"
                  grabbable="startButtons: gripdown; endButtons: gripup"
                  stretchable="startButtons: gripdown; endButtons: gripup">
          <a-camera>
            <a-entity class="gazecaster"></a-entity>
          </a-camera>
          <a-entity class="right-controller"></a-entity>
          <a-entity class="left-controller"></a-entity>
        </a-locomotor>
      </a-entity>

Without having explicit controller child nodes, the locomotor does not work at all.
Having the a-locomotor outside of the progressive-controls does not work at all.
Previously without the progressive-controls with manual super-hands on the controllers the locomotion worked as expected (obviously not progressive, but that is fine for now) but the physics colliders did not scale properly with the scaling locomotion, prompting me to try all sort of things to get this working.
Is there a working example that combines physics, a-locomotor and progressive-controls anywhere? Where have i screwed up?
Bonus question: With the setup snippet above the translation is very jittery, in the previously working version without progressive-locomotion it was fairly smooth. What could be the cause for that?

Howdy. I have to confess I've never tried combining them. Have you tried with the locomotor and progressive controls on the same entity?
        <a-locomotor progressive-controls="touchMixin: touch; override: true"
                  horizontal-only="false"
                  grabbable="startButtons: gripdown; endButtons: gripup"
                  stretchable="startButtons: gripdown; endButtons: gripup">
          <a-camera>
            <a-entity class="gazecaster"></a-entity>
          </a-camera>
          <a-entity class="right-controller"></a-entity>
          <a-entity class="left-controller"></a-entity>
        </a-locomotor>

As for why the physics bodies weren't scaling, I have a fix for scaling complex and nested physics bodies on the master branch. It is stable at present, and I am working towards a (long overdue) fresh release.
Also, maybe check out aframe-camera-transform-controls-component by @fernandojsg as a more polished alternative to a-locomotor (although I haven't tried combining it with super-hands yet - if you go that route and have trouble, I would want to help troubleshoot to get them compatible)

To be honest i hadn't even thought of putting them on the same entity, but after a quick try just now it doesn't seem to make a difference.
Thanks for the info though about the scaling fix, and i will certainly try the mentioned component. I will get back to you with my experiences.

@wmurphyrd You may be pleased to hear that aframe-camera-transform-controls-component seems to work without issue with super-hands. It took a bit of finagling and studying the source and examples to get it to work.
A working setup starting from the complete default super-hands DOM using it:
<a-scene environment physics="debug: true" camera-transform-controls>
      <a-assets>
        <!-- ... -->
      </a-assets>

      <a-entity id="cameraRig" progressive-controls="touchMixin: touch; override: true">
      <!-- <a-entity id="cameraRig"> -->
        <a-camera id="camera">
          <a-entity class="gazecaster"></a-entity>
        </a-camera>
        <!-- <a-entity id="righthand" hand-controls="right" class="right-controller"></a-entity> -->
        <a-entity id="righthand" camera-transform-controls-hand="hand:right" class="right-controller"></a-entity>
        <!-- <a-entity id="lefthand" hand-controls="left" class="left-controller"></a-entity> -->
        <a-entity id="lefthand" camera-transform-controls-hand="hand:left" class="left-controller"></a-entity>
      </a-entity>
</a-scene>

The important key parts are all ids on the entities, the library currently has no robust method of sourcing the camera or controllers and gets them by hardcoded id, as well as the camera-transform-controls-hand component on the hand entities, something that is not apparent from the readme but can be found in the examples (and the source).
The collider scaling issue is obviously still there, but disregarding that it works pretty much as expected.

Thanks for reporting back. I think I'll move towards retiring a-locomotor and recommending this instead. Perhaps we can contribute to make it easier to use as well.

I wouldn't mind porting a similar solution that is tailored specifically to be easy to setup with super-hands as a replacement for the a-locomotor, the actual logic of the component is not that complicated and i do have some experience with similar stuff in other platforms. I will open a pull request if i have something ready :)

Awesome!


Support for UE4 4.25 ?

Hi,
is it in plans to update this plugin to support  UE4 4.25  ?
Regards

Just open the .uplugin file and change the version of Unreal Engine to 4.25

Just open the .uplugin file and change the version of Unreal Engine to 4.25

While that gets the plugin to work to some degree, I've found it to be incredibly unstable and prone to crashing after ~10-15 seconds of playback on streaming video/.m3u8 files.

I don't know, I use it with MP4 and it seems to be stable, however I forked the repo and within a few days I make it completely compatible with 4.25 as others have asked me

For reference I see the following in my output before it crashes:
LogVlcMedia: Error: mmdevice: cannot initialize COM (error 0x80010106)
LogPresenterElement: Display: Set material to screen element.
LogPresenter: Display: Found a media player already using this entr
LogPresenterElement: Display: Set material to screen element.
LogTemp: Resetting audio stream to device id
LogAudioMixer: Display: 0: FrontLeft
LogAudioMixer: Display: 1: FrontRight
LogTemp: Resetting audio stream to device id
LogVlcMedia: Warning: faad: decoded zero sample
LogAudioMixer: Display: 0: FrontLeft
LogAudioMixer: Display: 1: FrontRight
LogVlcMedia: Error: vmem: missing lock callback
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: vmem: missing lock callback
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: vmem: missing lock callback
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: vmem: missing lock callback
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: vmem: missing lock callback
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: main: buffer deadlock prevented
LogVlcMedia: Error: main: Failed to set on top
LogVlcMedia: Warning: avcodec: plane 1: pitch not aligned (208%32): disabling direct rendering
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: main: playback way too early (-614999): playing silence
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Warning: h264: waiting for SPS/PPS
LogVlcMedia: Error: vmem: video format setup failure (no pictures)
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: vmem: video format setup failure (no pictures)
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: main: Failed to set on top
LogVlcMedia: Warning: avcodec: plane 1: pitch not aligned (208%32): disabling direct rendering
LogSlate: Took 0.000739 seconds to synchronously load lazily loaded font '../../../Engine/Content/Slate/Fonts/DroidSansMono.ttf' (77K)
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0x7 (pid=17)
LogVlcMedia: Error: ts: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 7) for PID 17
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0x4 (pid=257)
LogVlcMedia: Warning: faad: decoded zero sample
LogVlcMedia: Error: vmem: video format setup failure (no pictures)
LogVlcMedia: Warning: main: cannot reuse provided vout
LogVlcMedia: Error: vmem: video format setup failure (no pictures)
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: vmem: video format setup failure (no pictures)
LogVlcMedia: Error: main: video output creation failed
LogVlcMedia: Error: main: failed to create video output
LogVlcMedia: Error: main: Failed to set on top
LogVlcMedia: Warning: avcodec: plane 0 not aligned: disabling direct rendering
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0x6 (pid=17)
LogVlcMedia: Error: ts: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 6) for PID 17
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0xf (pid=0)
LogVlcMedia: Error: ts: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 15) for PID 0
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0xf (pid=4096)
LogVlcMedia: Error: ts: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 15) for PID 4096
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0x9 (pid=257)
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0x9 (pid=256)
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0xa (pid=17)
LogVlcMedia: Error: ts: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 10) for PID 17
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0x2 (pid=0)
LogVlcMedia: Error: ts: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 2) for PID 0
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0x2 (pid=4096)
LogVlcMedia: Error: ts: libdvbpsi error (PSI decoder): TS discontinuity (received 0, expected 2) for PID 4096
LogVlcMedia: Warning: ts: discontinuity received 0x0 instead of 0xf (pid=257)

Just a quick update for our issue, it seems like VLC plugin crashes when a live stream VLC switches from its initial resolution to a higher resolution. Unfortunately it hard crashes with no stack. This also only happens when in a packaged build and not in the editor.

I'm seeing the same crash after a few seconds with m3u8 in packaged build


The page flickers when viewing the model instance logs

Describe the bug

https://github.com/user-attachments/assets/f502cbf6-b40f-4383-88f3-7ff48045c7c4
Environment

GPUStack version: 0.4.0-rc1
OS: Ubuntu 22.04
GPU: NVIDIA 4090

Additional context
Add any other context about the problem here.

Verified on UI 2ddeca8


.sprites needs a save function

hello,
ive been working, again on a tutorial. but have ran into quite an annoying bug.
on making a .sprite, i make all the directions, do all the naming, sizes blah blah blah. but on running and saving the project. i exit and then open polycode, open the project, and all my .sprite setting are completely gone. so have to do it again.
i see on the .sprites menubar, that a symbol [*] does not show to say that this has not been saved, that edits have been made.
i think it would be good to have just so things have been saved.
[idea for saving]
even what would be good, is have a setting that saved settings if you moved to another window. say im on the .sprites setting, but then click on a .lua file. the .sprites file has saved automatically from clicking on the other file. that would be nice, it wouldnt kill the flow

It might also be nice to have File -> Save Project which saves all modified files in the current project.

this is fixed in latest master


[CodeCompletion] Fix crasher and missing completion for generic arguments to nested type

Completing a generic parameter to a nested type Outer.Nested<#^COMPLETE^#> crashed when used to initialize a local variable and returned no results when initializing a global variable.
This is because the generic argument parsing logic for nested types inside parseExprPostfixSuffix didn’t match that of global types in parseExprIdentifier. Make sure they do the same thing semantically.
Fixes rdar://77909679 [SR-14627]

@swift-ci Please smoke test

@swift-ci Please smoke test macOS


appRTC on xampp server

We have integrate this code and install related package some issue and not found url which run in browser.

we have download file and paste folder localhost xampp then again install python,grunt dependency package but not run apprtc please suggest proper sollution.


DOC: Add PyPI and Conda-forge install instructions

c.f.

https://pypi.org/project/array-api-compat/
https://anaconda.org/conda-forge/array-api-compat

@asmeurer this is ready for review.


GTK3 (gnome-terminal) crashing

 Issue by Manouchehri
Monday Nov 16, 2015 at 01:34 GMT
Originally opened as https://github.com/Cloudef/wlc/issues/85

I've also posted a ticket with sway as I'm not sure of the source. I'm not that experienced in software debugging, so I apologize if there's information missing.
Getting random crashes with gnome-terminal (GTK3) when I left/right click a lot and move between windows (haven't narrowed down the exact cause). It's difficult to trigger, but does happen frequency enough to be an issue.
~ > gdb --args /usr/lib/gnome-terminal/gnome-terminal-server --app-id my.foo
GNU gdb (GDB) 7.10
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/gnome-terminal/gnome-terminal-server...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/lib/gnome-terminal/gnome-terminal-server --app-id my.foo
[New LWP 12011]
[New LWP 12012]
[New LWP 12013]
/usr/lib/gnome-terminal/gnome-terminal-migration: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
Profile migrator exited with status 127

(gnome-terminal-server:12007): Gdk-WARNING **: Error 22 (Invalid argument) dispatching to Wayland display.
[LWP 12012 exited]
[LWP 12011 exited]
[LWP 12007 exited]
[Inferior 1 (process 12007) exited with code 01]
(gdb) q

Source of error message (if it's any help): https://github.com/GNOME/gtk/blob/5ea692df23cf6caed7624554be46b8f39fe008ce/gdk/wayland/gdkeventsource.c#L167
@sce https://github.com/SirCmpwn/sway/issues/229#issuecomment-156751190

 Comment by Cloudef
Monday Nov 16, 2015 at 09:16 GMT

Do you have wlc output as well? Most likely the terminal crashes due to unimplemented wayland protocol features in wlc.

 Comment by Manouchehri
Monday Nov 16, 2015 at 12:38 GMT

Not yet, wasn't sure how to get it. Does it output messages in stdout or do
I have set a flag first?

 Comment by SirCmpwn
Monday Nov 16, 2015 at 12:39 GMT

See the FAQ for how to get a log.

 Comment by SirCmpwn
Monday Nov 16, 2015 at 14:20 GMT

Nah, sway will pull in the wlc logs for you, too.

 Comment by Manouchehri
Monday Nov 16, 2015 at 14:19 GMT

@SirCmpwn That's only for sway and not wlc, no?

 Comment by Manouchehri
Monday Nov 16, 2015 at 14:35 GMT

https://gist.github.com/Manouchehri/cb23ad1ba27ac550cffc
I think it starts at line 2400 or 2180. I don't see any obvious error messages though except for [wlc] libinput bug: Unable to find topmost touch.

 Comment by Kinokoio
Tuesday Nov 17, 2015 at 03:37 GMT

Before everything, do you know if you have libgconf-2.so.4 in your system? Have you tried reproducing the bug in Xorg?

 Comment by Cloudef
Monday Nov 16, 2015 at 15:31 GMT

The log looks quite ok, this may be very likely bug in gnome-terminal. Is this reproducable in weston?

 Comment by Manouchehri
Tuesday Nov 17, 2015 at 03:43 GMT

@Kinokoio The GDK error explicitly says it's an error in Wayland, so I'm pretty sure I won't be able to reproduce it in Xorg.
@Cloudef My guess GTK is trying to use something that's not implemented and/or encountering a non-fatal error, but then quitting anyways. It's being triggered by wl_display_dispatch (display_wayland->wl_display) < 0, any idea what might cause that?

 Comment by Kinokoio
Tuesday Nov 17, 2015 at 03:43 GMT

Do you have the file and/or function where it crashes?

 Comment by Manouchehri
Tuesday Nov 17, 2015 at 03:45 GMT

@Kinokoio It's listed in the first post, or click here.

 Comment by Manouchehri
Tuesday Nov 17, 2015 at 03:48 GMT

@Kinokoio Re: libgconf-2.so.4, GConf is not used in GTK3 (or GNOME).

 Comment by Kinokoio
Tuesday Nov 17, 2015 at 03:50 GMT

Indeed, it is good info but, you don't have the complete backtrace. You get it using the command bt in gdb. Still, what trills me is the following error:
usr/lib/gnome-terminal/gnome-terminal-migration: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory

 Comment by Manouchehri
Tuesday Nov 17, 2015 at 03:58 GMT

@Kinokoio I don't use gdb too often, what exactly do I need to do to get the stack at the moment it crashes? I usually just debug line-by-line for my own asm programs, but that's not gonna work with a huge application.
gnome-terminal-migration is expected to fail, it happens during the application's startup and doesn't do anything harmful (from what I can tell). The package should probably be built with --disable-migration, but I'm not the maintainer so it's not my call.

 Comment by Kinokoio
Tuesday Nov 17, 2015 at 04:05 GMT

When the program crashes, it takes you to the gdb command prompt. There, you can use "bt" to get the current backtrace. Unfortunately, you don't have debugging symbols, so you would get only hex addresses.
You can use the command "x" combined with a form of representation (use the help command for more) like "x/10i" "address", which will get you the next 10 asm instruction starting from that address.
Edit: Changed "<" to """

 Comment by Manouchehri
Tuesday Nov 17, 2015 at 04:06 GMT

The program does exit with 1 though, so won't the stack be empty?

 Comment by Kinokoio
Tuesday Nov 17, 2015 at 04:09 GMT

Sorry, I forgot about that. Place a break at the exit instruction or the gwarning macro.
Also, just installed gnome-terminal on ArchLinux and tested it both in orbment and Xorg with gconf installed. It works perfectly.

 Comment by Kinokoio
Tuesday Nov 17, 2015 at 04:11 GMT

 Comment by Manouchehri
Tuesday Nov 17, 2015 at 04:13 GMT

Ah, thanks. I'll give that a shot this week.
It runs quite well for me too, it's a rather difficult bug to trigger reliably. You have to start copy-pasting, left/right clicking and move between windows rapidly for several minutes.

 Comment by Cloudef
Tuesday Nov 17, 2015 at 08:27 GMT

wl_display_dispatch (display_wayland->wl_display) < 0, any idea what might cause that?

Usually if wl_display_dispatch fails, it means connection to the compositor is broken.

 Comment by nicman23
Wednesday Apr 06, 2016 at 09:12 GMT

is there an update to this? copying/ pasting is quite unreliable.


For demo

Thanks for your contribution! Please let us know what problems this PR addresses or what functionality it adds. Please link to other related issues and PRs to speed up review. Thank you!

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

This appears to be an accidental PR so closing. If not, please reopen and can you explain your goals? Thanks!


Page constantly reloading

Hi
If I activate service-workers the page starts to reload as soon as it is loaded. It will do it in an endless loop until I unregister the service worker in my developer tools.

I don't have such problem, did you check that you correctly copied the code, did you tried on another clean meteor project ?

I have not checked with a clean project. It happens on my Mac and on my Mobile. You can try it yourself at https://dev.caveconditions.com. wonder if you see the same behaviour.

Nevermind... Clearing all browser data cache seemed to have helped. Tested it now on various browsers and computers.
Thanks for the hint.

Okay I'm glad your issue is solved ;)


Fix stack.yaml syntax for a specific revision

See also https://github.com/haskell/haskell-ide-engine/pull/1694#issuecomment-627456134
Ping @jneira @fendor @gdziadkiewicz

Hm actually hold on, I looked into this because of https://github.com/input-output-hk/haskell.nix/issues/550, but I'm not sure it fixes it now

Alright it's just a separate bug in nix-tools, this change here is good :)

See https://github.com/input-output-hk/nix-tools/pull/90 for the fix of the other bug


Utilize ParmEd to simplify GROMACS workflows and parameter conversion

This swaps the interior of several functions on the gromacs side with equivalent functionality (same API) utilizing ParmEd. Additionally, import statements are modified for the new layout of parmed which now is invoked via import parmed rather than import chemistry. Additionally, a new amber_to_gromacs conversion functionality is implemented using ParmEd. The ParmEd slicing and splitting functionality makes various operations much easier.
Additional discussion on this is available here: https://github.com/MobleyLab/openmoltools/pull/7
Still to do: implement an energy evaluation test to validate AMBER-to-GROMACS conversion.

It's worth noting that ParmEd makes acpype obsolete; for the time being the acpype functionality is retained, though I should probably deprecate it and it can be removed at a later date.

Nice work with tackling this, taking a look now.

OK, things look reasonable to me.  However, I'm not a gromacs expert and I also haven't done very much with the parmed gromacs stuff, so YMMV.

@kyleabeauchamp - I've fixed the version requirement, sort of (except it's overly complicated at the moment - will fix again when there is a better solution). In terms of molecule_name - I actually like this reasonably well as in some cases I can see having molecule_name would simplify the workflow. So I don't necessarily want to change at this point.

Sounds good
On Jun 9, 2015 1:35 PM, "David L. Mobley"<EMAIL_ADDRESS>wrote:

@kyleabeauchamp https://github.com/kyleabeauchamp - I've fixed the
version requirement, sort of (except it's overly complicated at the moment

will fix again when there is a better solution). In terms of
molecule_name - I actually like this reasonably well as in some cases I
can see having molecule_name would simplify the workflow. So I don't
necessarily want to change at this point.

—
Reply to this email directly or view it on GitHub
https://github.com/choderalab/openmoltools/pull/124#issuecomment-110442009
.

Added pytables as a dependency for travis to address this issue: https://github.com/mdtraj/mdtraj/issues/852#issuecomment-110184684

I cut a new MDTraj release that fixes the tables bug -- the fixed binaries should be up on binstar in the next hour or so.

I also just determined that ParmEd now requires OpenMM 6.3 which is not released yet, so travis will presumably fail until either it is released or I switch to installing openmm-dev temporarily. Probably that means I won't merge this until it is released, which I am told will hopefully be in the next couple weeks.

I'm fine either way, a temporary Travis downtime is ok
On Jun 10, 2015 12:35 PM, "David L. Mobley"<EMAIL_ADDRESS>wrote:

I also just determined that ParmEd now requires OpenMM 6.3 which is not
released yet, so travis will presumably fail until either it is released or
I switch to installing openmm-dev temporarily. Probably that means I
won't merge this until it is released, which I am told will hopefully be in
the next couple weeks.
—
Reply to this email directly or view it on GitHub
https://github.com/choderalab/openmoltools/pull/124#issuecomment-110887159
.

Added energy cross-comparison to the test for format conversion. Probably can merge once I decide what to do about travis.

I will probably merge once ParmEd updates its conda channel to a more recent version with the current package organization (i.e., needs import parmed rather than import chemistry). This is currently causing problems in the Travis tests.
There is still the issue that ParmEd needs OpenMM later than 6.2 and 6.3 is not out yet, but since conda install openmm-dev works, I am OK with temporarily (partially) broken travis tests until the release of 6.3.

Travis-CI is unhappy because of this issue, apparently: https://github.com/ParmEd/ParmEd/issues/181 - the parmed.py script in the parmed package is not playing nice with Travis-CI. I'll need to ask @swails to make his 2.0beta2 release and update the omnia package. Raising issue on ParmEd momentarily.

I think Travis-CI will be happy now, as a new ParmEd binary was just released. We'll see. I'm going to have to merge very soon (i.e. tonight) one way or the other as the current main branch is incompatible with the current releases of ParmEd (since import chemistry in utils.py is no longer valid), breaking stuff my people are doing.
Presumably we could work around that by specifying that an older version of ParmEd is required, though that would be silly since the fix is already in this PR.
I just updated setup.py to change the version tag to 0.6.8 in preparation for doing an 0.6.8 release once this is merged (hopefully shortly).

Python 2 passed as far as expected (up to the issue involving the requirement for OpenMM 6.3) but I had an issue with Python 3. Fixed now, hopefully.

OK, that seems to do it. I'm merging - getting Travis to be completely happy will have to wait for OpenMM 6.3.


Made Webcam.reset() idempotent

So it's safe to call it several times without errors. Also safe to call without calling initializing Webcam itself, which is what I'm doing.
Use case here is that Webcam is used within a dialog and once that dialog closes I want the Webcam to reset, but not all dialogs use Webcam.

Seems safe enough.  Thanks!


Feedback for "Getting Started with a Trial Account"

https://help.sap.com/webcomponents/products/SAP Business Application Studio/9d1db9835307451daa8c930fbd9ab264/48ed55ec07e04a02b2218236c336321b.html?locale=en-US
On Trial users can access SAP Business Application Studio via Quick Tool Access.

Hi @iwonahahn,
Thank you for your feedback.
I will update the document with the reference to the Quick Tool Access.
You will see the changes on our next release.

https://people.sap.com/iwona.hahn


Android -> notification observe returning less data than characteristic read

Hi,
Apologies if this is the wrong place. Feels like it might be an issue with the library but not 100% sure.
The issue I am having feels similar to https://github.com/JuulLabs/kable/issues/112
We have a characteristic we start to observe when connected to our device.
It eventually gets written to, however when observing the flow it only returns 20 bytes (this feels oddly specific).
If we read straight from the characteristic it gets the full value of 74 bytes (We have a delay which lets our device write to the characteristic after we have asked it to).
When poking at logs the only interesting thing i could see was below where it changes the notification settings.
D/BluetoothGatt: setCharacteristicNotification() - uuid: a7d06ce0-2e84-485f-9c25-3d4ba6fe7319 enable: false
Do you have any insights on this one?
Thanks a ton!

Hi @nathan-castlehow, can you try the latest snapshot in the issue you mentioned (0.5.1-issue-112-2-SNAPSHOT) and use the onObservationStarted option in the observe lambda? And report back if it works as expected, if not, then logs produced from that snapshot would be helpful.
Thanks!

Hmm so the example you have is writing to the same characteristic we are then observing. We only read from this characteristic. The observing gets setup as soon as we connect to the device and then later on it gets written to.
I added the snapshot but doesn't appear to log anything as we are interested in the reading (and the logs from the other issue appear to be for the writing).

Let me know if I'm missing some obvious step to help trouble shoot this.
Thanks again!

@nathan-castlehow can you make sure that under "External Libraries" it is showing the SNAPSHOT version, for example:

Hmmm seems to match.
The only thing interesting seems to be the fact that "setCharacteristicNotification" is being called with false

Not sure if this adds any value but if I both read from and observe the characteristic I get a not ready exception.

Bizarre that you're not getting logging from Kable, it is using the standard Android Log.* methods. You're able to log via Android's Log.* from your app?

Haven't had any issues with logging.
I was chatting to a colleague and he suggested that this might actually be the desired / default behavior.
The size of the value we want is 74 bytes which is larger than our MTU (we can't increase the MTU due to a bug on some samsung devices with BLE). He suggested that notifications can only return values up to the MTU size and for larger observing the notification and then reading the characteristic is the default behaviour.
Does that make sense to you?

we can't increase the MTU due to a bug on some samsung devices with BLE

I personally haven't encountered issues with increasing the MTU, but BLE on some phones is super wonky, so it doesn't surprise me that there are limitations on some Samsung phones. It may be worth trying to figure out what specific Samsung models suffer from the MTU limits? Perhaps (and perhaps just wishful thinking) that the offending models are pre-Android 21, or their prevalence is so low it may not be worth supporting them?

He suggested that notifications can only return values up to the MTU size and for larger observing the notification and then reading the characteristic is the default behaviour.

Seems like a reasonable workaround (if needed), you could fairly easily write something in Kable to implement that workaround, for example:
peripheral
    .observe(characteristic)
    .map { peripheral.read(characteristic) }
    .collect { data -> /* todo: process `data` */ }

I ended up with something pretty close to what you suggested above.
We can probably close this one as "by design"
I wish we could drop support but some specific customers were using the phones in question. One can dream ;)

I ended up with something pretty close to what you suggested above.
We can probably close this one as "by design"

Sounds good. 👍

I wish we could drop support but some specific customers were using the phones in question. One can dream ;)

Haha, yeah, I know how that goes. 😉

Thanks again for all your help and for maintaining such a great library! Will try give back when I can.

Thanks for the kind words. 😄
Feel free to reach out if you have any other questions or issues.


Fix publish CI process

Checks were failing during publication. Was an oversight, that new memory model was enabled for CI but not publications.

Blocked by #192.


Deduplication configuration still not showing up for HDDs

I'm running DSM as a Proxmox VM with passed-trough SATA controller for the drives.

I have run both enable deduplication with --hdd parameter and hdd_db script. Rebooted multiple times. Everything is healthy, performance analysis is enabled, and I've waited more than 10 minutes for the menu to show up. Like #79 but I still can't get it to work.

Any ideas about what I'm missing??

It is looking like it's a an issue with virtual disks. Xpenology, proxmox and virtual disks are all beyond my level of knowledge.

Definitely not. As I've mentioned, the sata controller is passed through, meaning that the drives are communicating with DSM exactly as they would in a real bare metal hardware DSM system.

As far as virtual disks are concerned. Actually, the deduplication for those was ironically easily available even before running your scripts, despite me not needing it.

Would you mind sending me your patched StorageManager 1.0.0-00502 storage_component.js file to compare it to mine?

@007revad There's a different js file that's being sent to the DSM web clients than the one your script is modifying, or something like that. Because, even if the &&e.dedup_info.show_config_btn is deleted in the file correctly, the browser is still getting storage_panel.js that still contains the check. I have 100% confirmed that that's the culprit by using proxy and swapping the js Synology is sending with the modified js. And the deduplication menu was available right there and then.
It's not browser cache, and I have rebooted Synology - multiple times, and cold booted it as well.
Now I can't say what to do now. Maybe there's another caching going on in the Synology itself or something? I really don't feel like grepping entire file system just to find where is the other file / string hiding, but that's my last resort for now.
Let me know if you happen to have any ideas~!

After a reboot is the &&e.dedup_info.show_config_btn still deleted?
I just searched DSM 7.2.2 update 2 for file named storage_panel.js on a DS720+ and only found 2 storage_panel.js files
storage_panel.js               <-- the edited file
storage_panel.js.1.0.0-00502   <-- backup of the original file

I wonder if DSM is loading the backup storage_panel.js.1.0.0-00502 file as storage_panel.js. You could moving, renaming or deleting storage_panel.js.1.0.0-00502.

root@DSM1:/usr/local/packages/@appstore/StorageManager/ui# sha256sum storage_panel.js*
bdab05da7e550fd4696e9e9f7a54694d40ee71f1711799ec64078a7a601d0a94  storage_panel.js
bdab05da7e550fd4696e9e9f7a54694d40ee71f1711799ec64078a7a601d0a94  storage_panel.js.1.0.0-00502
9dec4942926cc8ec184c9575aa5d35cbb1ab10f7f6888d881b4c0f0ea5405e03  storage_panel.js.gz
cbf8f3709fcc43f1e5cc360e726bbb6e739e8176d3fd52b41f237a9400694280  storage_panel.js.gz.bak

I removed the check, and made both files the same. There has to be some other place where it's pulling it from still…
And btw, yes, the modifications do survive reboots.

Oh, and maybe this will help, this is the file that Synology is sending despite having the files above modified: storage_panel_sentBySyno.zip

And btw, yes, the modifications do survive reboots.

Do you have syno_enable_dedupe.sh scheduled?
My real Synology NAS don't have the storage_panel.js.gz (or storage_panel.js.gz.bak) files. I assume they are created by the xpe loader. Does the storage-panel.js in storage_panel.js.gz contain &&e.dedup_info.show_config_btn?
I suspect what is happening is your xpe loader, or trcp-addons etc, is recreating storage-panel.js during the junior boot stage and then syno_enable_dedupe is editing it. But where the ui is loading an unedited copy from is a mystery.
A quick look at storagepanel.sh and install.sh shows they are creating the gzipped copy of storage-manager.js

Do you have syno_enable_dedupe.sh scheduled?

I don't.

My real Synology NAS don't have the storage_panel.js.gz (or storage_panel.js.gz.bak) files.

Oh, I didn't know that!
I've tried to modify the archives, and it seems to have worked!
I think they're there because the DSM loader allows choosing things such as HDD bays graphics etc., so I guess it's achieving that by modifying the storage_panel.js as well.

I've tried to modify the archives, and it seems to have worked!

If you reboot does the storage_panel.js.gz still contain your edits?
I might change the script to delete the existing storage_panel.js.gz and gzip storage_panel.js
But before I do that can you provide a zip file containing everything in /usr/local/packages/@appstore/StorageManager/ui

If you reboot does the storage_panel.js.gz still contain your edits?

So far, yes they do. However, I suspect that updates to the loader can easily break it / revert the changes.

But before I do that can you provide a zip file containing everything in /usr/local/packages/@appstore/StorageManager/ui

Sure can do. Here you go, should be in more-less unmodified (xpenology / loader) state:
StorageManagerui.tar.gz


Add worker node to Tetronic Sandbox

Issue Report Template
Tectonic Version
Environment
What hardware/cloud provider/hypervisor is being used with Tectonic?
Expected Behavior
Tetronic Sandbox is coming with one worker & one controller node. Had tweak the vagrant file to add in new worker node, but the default license which is 2, had limit it. May I know how we can tweak this?
Thanks
Actual Behavior
Reproduction Steps

...
...

Other Information
Feature Request
Environment
What hardware/cloud provider/hypervisor is being used with Tectonic?
Desired Feature
Other Information

This is not a targeted use-case for the Sandbox at this time. It's just not tested for this and as you found out the license is not large enough. If you sign up for a 10 node license, you should be able to replace the default sandbox license with it, and have 10 nodes to play with.

Thanks for the info. However, due to the default license is 2, even tweaking the vagrant file to add another worker node, there is only one controller and one worker after run the vagrant. I had sign up for 10 node license. How I can replace the default sandbox license at vagrant file? Or if not at vagrant, where should I replace the default sandbox license?

It would really be great to have at least two worker nodes in Sandbox - that way you can test things like automatic failover.
Otherwise, you're just getting a prettier minikube.


Parameter order changed between 5.4.0 and 6.0.0 with logcapture and mock.patch

I have a unittest that uses both mock.patch and log_capture decorator.
@mock.patch('evmanagement.iter_entry_points')
@log_capture('evmanagement', level=logging.INFO)
def test_main_entrypoint_callable(self, mock_iep, logs):
    print mock_iep
    print logs

with textfixtures 5.4.0 it prints
<MagicMock name='iter_entry_points' id='34698917264'>
No logging captured
with textfixtures 6.0.0 it prints
No logging captured
<MagicMock name='iter_entry_points' id='34698917776'>
as you can see the parameter order has changed with the update.

There is no mention of this is the changes. At least a change like this should listed there

Admittedly, it could have been a bit more explicit, but this is covered by the 8th bullet point on http://testfixtures.readthedocs.io/en/latest/changes.html#march-2018.
I do semver quite strictly, so a major version increase should also suggest that there are likely to be changes in behaviour such as this.


Configurable Manager endpoint

In monitor template ocrdmonitor/server/templates/jobs.html.j2 there is following js function with a fixed manager endpoint call. The manager endpoint should be configurable from outside.
function killjob(pid) {
    console.log(fetch(`http://ocrd-manager:4004/cancel_job/${pid}`));
}

Additionally the fetch should be a await call.

Additionally the fetch should be a await call.

Yes, @SvenMarcus noticed that as well.

The manager endpoint should be configurable from outside.

Why? Monitor cannot run without Manager, so we can rely on the Docker network for the name resolution and internal port here.

Yes, @SvenMarcus noticed that as well.

Indeed, due to this suggestion, I initiated the issue to complete the pull request without incorporating additional fixes and detailed enhancements.

Why? Monitor cannot run without Manager, so we can rely on the Docker network for the name resolution and internal port here.

I have some uncertainties regarding this matter. The image can function independently, without requiring the ocrd_kitodo repository or specific names in the Docker Compose setup. This opens up alternative possibilities. It's plausible that the containers operate on distinct networks or that a reverse proxy has been implemented to manage various services separately.

I have some uncertainties regarding this matter. The image can function independently, without requiring the ocrd_kitodo repository or specific names in the Docker Compose setup. This opens up alternative possibilities. It's plausible that the containers operate on distinct networks or that a reverse proxy has been implemented to manage various services separately.

Indeed. And for the same reason, we already introduced CONTROLLER_HOST and CONTROLLER_PORT_SSH for the Manager. Since we already did introduce MANAGER_HOST and MANAGER_PORT_WEB, let's use it here.


Misformulated text

This page needs to be remade.
The first example of conditional formulas doesn't hide the column if true, but instead shows it.
Please fix this!

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 536f88e0-51aa-9a3a-20da-64b4a8b155a1
Version Independent ID: efa34015-6402-a024-ae62-3b0c6c0865ea
Content: Show or hide columns in a list form
Content Source: docs/declarative-customization/list-form-conditional-show-hide.md
Product: sharepoint
GitHub Login: @VesaJuvonen
Microsoft Alias: vesaj

Hi @TonieStark ,
What type of column are you using in the conditional formula？
I test with a single line of text column, it works well. When the judgment condition is true, the column is hidden in the edit form.
Test result for your reference:

Unsupported column type in the formula:

Person columns with multiple selections
Multiple choice column
Time calculations in DateTime column
Currency columns
Location columns
Calculated columns
Managed Metadata columns

Amos Wu
Microsoft SharePoint Community Support

Hi @TonieStark ,
What type of column are you using in the conditional formula？
I test with a single line of text column, it works well. When the judgment condition is true, the column is hidden in the edit form.
Test result for your reference:

Unsupported column type in the formula:

Person columns with multiple selections
Multiple choice column
Time calculations in DateTime column
Currency columns
Location columns
Calculated columns
Managed Metadata columns

Amos Wu
Microsoft SharePoint Community Support

Hi,
Hmm, that is really weird, I have the opposite behaviour and use the same type of columns, single text for show/hide and choice in the actual formula.
But also, look at these blog posts (from well known sites):
https://www.c-sharpcorner.com/blogs/conditional-formula-to-show-hide-columns-in-sharepoint-list
https://sharepointmaven.com/how-to-hide-a-field-in-sharepoint-lists-and-libraries-with-the-conditional-formula/
As well as this "First look at Microsofts Lists" by Miceile Barett-MSFT (look from 12:45)
https://www.youtube.com/watch?v=plshQSoe_OY
And this one with Lincoln DeMaris (look from 29:45)
https://www.youtube.com/watch?v=Zj998RFWMdw
Sooo, they all say, including me, that when the condition is true, show the selected column, otherwise hide it.
Please review this internally, thanks!
/TS

Hi,
Hmm, that is really weird, I have the opposite behaviour and use the same type of columns, single text for show/hide and choice in the actual formula.
But also, look at these blog posts (from well known sites):
https://www.c-sharpcorner.com/blogs/conditional-formula-to-show-hide-columns-in-sharepoint-list
https://sharepointmaven.com/how-to-hide-a-field-in-sharepoint-lists-and-libraries-with-the-conditional-formula/
As well as this "First look at Microsofts Lists" by Miceile Barett-MSFT (look from 12:45)
https://www.youtube.com/watch?v=plshQSoe_OY
And this one with Lincoln DeMaris (look from 29:45)
https://www.youtube.com/watch?v=Zj998RFWMdw
Sooo, they all say, including me, that when the condition is true, show the selected column, otherwise hide it.
Please review this internally, thanks!
/TS

Any progress on the internal discussions?

@TonieStark this should now be resolved, following the update to the documentation made in PR #6594


M-x straight-use-package does not respect existing recipes?

When using M-x straight-use-package on a deferred-install package that has a custom recipe, I get a warning about incompatible recipes. straight.el should just be using the previously registered recipe.

I do not understand the details very well, but from reading the straight.el documentation I decided that this was the correct way to use my own fork in a recipe (perhaps I'm doing it wrong)
(use-package lispy
  :straight
  (lispy :type git :files (:defaults "lispy-clojure.clj") :host github :repo "blak3mill3r/lispy" :branch "fix/cider-may-not-be-loaded-yet"
         :upstream (:host github
                    :repo "abo-abo/lispy")))

And I get a warning:
Warning (straight): Package "lispy" has two incompatible recipes (:repo cannot be both "abo-abo/lispy" and "blak3mill3r/lispy")

Oh, and I do
(straight-use-package 'use-package)
(setq straight-use-package-by-default t)

right after the straight.el bootstrap code, at the very top of my init.el

Ah, I figured it out. I also have
(use-package lispyville
  )

above the (use-package lispy ...) block. The lispyville recipe must name lispy as a dependency causing straight.el to fetch it using the default recipe.
I commented out the (use-package lispyville) and rebuilt and now everything is fine.

and now I can use lispyville again, provided that I put the (use-package lispyville) after my own custom-recipe (use-package) for lispy itself. I apologize if I missed that in the thorough documentation, which I have not read cover to cover. I'm documenting it on this issue in case it saves someone else some trouble.

Is it a pitfall of straight.el? I also feel confused. For example, I have already a package installed via its default recipe, then I want to modify the recipe such as changing :repo, how can I make the new recipe take effect?

I apologize if I missed that in the thorough documentation, which I have not read cover to cover.

No problem. For future reference, this case is documented here.

Is it a pitfall of straight.el?

Not really. It's unfortunate that the behavior can be confusing, but I don't think there is any way to make it more intuitive other than by reporting a better error message.
Although for people who aren't interested in dealing with all the complexity of a more powerful package management model, I am thinking about creating a wrapper for straight.el that makes it behave similarly to package.el (i.e. with a list of installed packages stored persistently outside the init-file, etc.) except that at any point you could drop down to the straight.el interface.

I have already a package installed via its default recipe, then I want to modify the recipe such as changing :repo, how can I make the new recipe take effect?

That depends what you mean.

If you mean earlier in your init-file, you request a package with the default recipe (or that package is requested implicitly as a dependency), and then later in your init-file, you want to request it again with a different recipe, this is clearly impossible. The package will already be installed. (What would you want? Install the package, then delete it and install a different version? Do this on every Emacs init?)
If you mean that you only request the package once in your init-file, but you'd like to change the recipe that is used to do so, then just do that and then run M-x straight-normalize-package. straight.el doesn't modify anything on disk during init; you have to ask for that. Normalization causes the correct branch to be checked out. (You may also want M-x straight-fetch-package.)


Add dropdown button macro

Description
Add dropdown button macro from Tabler
Code
{% from<EMAIL_ADDRESS>import dropdown_button %}

{{ dropdown_button(
    {icon: 'plus', title : 'Actions'},
    [
        {icon: 'plus',      title : 'Add more'},
        {                   title : 'Help needed'},
        {icon: 'delete',    title : 'Delete'}
    ]
) }}

{{ dropdown_button(
    {icon: 'plus'},
    [
        {title : 'Add more'},
        {title : 'Help needed'},
        {title : 'Delete'}
    ]
) }}

{{ dropdown_button(
    {title : 'Actions'},
    [
        {title : 'Add more'},
        {title : 'Help needed'},
        {title : 'Delete'}
    ]
) }}

Result

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] I updated the documentation (see here)
[x] I agree that this code will be published under the MIT license

Nice 👍


Update state-and-lifecycle.md

Hello @Timibadass,
From what I can see the sentence you update in this PR no longer exists in the latest version of docs, so I will close this PR as outdated.
Thank you for taking the time to contribute!


[DDCE-3222] Mongo Upgrade to 0.68.0

Could you fix platops comments?

Could you fix platops comments?

The remaining dependency upgrades still have an open story, so for this story they aren't necessary as this is just a quick security improvement.


Function not found when modifying entire collection

The docs would lead me to believe that I can call modify on an entire collection, but the function doesn't exist unless I use some kind of where clause. I have tried the below line of code both with and without a transaction.
Docs: http://dexie.org/docs/Collection/Collection.modify()
// Convert all shoeSize from european to american size:
db.friends.modify(function(friend) {
    friend.shoeSize *= 0.31; // (very approximate formula...., but anyway...)
});

If I remember correctly friends is a Table and not a Collection. You could use toCollection () on the Table to get a Collection. I'm guessing the example in the docs is wrong.

Nice catch, that does appear to be the case and after using toCollection modification worked as intended. I'll leave this open in the event the docs should be updated to clarity.


Handling start_datetime and end_datetime?

There's some datasets that do not have a datetime, but instead have a start_datetime and end_datetime. For example, a landcover dataset that represents a year of data - there's no single datetime to represent the data. STAC specifies that in this case datetime is null and the start_datetime and end_datetime is set.
How can pgstac handle these types of items?

We can create a composite that stores/indexes the datetime as a tstzrange datatype that is set to an instant (range start = range end) and use postgresql inbuilt range operators (similar to postgis bbox operators) to query between the stac record time range and the passed in start/end times.
We could also keep the start/end of the stac record as separate start/end where we merge in the datetime such that start_datetime = coalesce(datetime, start_datetime) and end_datetime = coalesce(datetime, end_datetime) and use appropriate bilateral less than and greater than statements.
I think the biggest question is do we always want to use some sort of "merged" time to query against or only with a flag or in certain circumstances.

The tztsrange solution would certainly be more flexible for queries.


go/types, cmd/compile: "invalid type loop" depending on declaration order

types2 currently rejects the test case below with "invalid recursive type A". Swapping the order of declarations for A and B makes the error go away.
package p

type A interface{ M(B[T]) }
type B[_ A] struct{}

type T struct{}
func (T) M(B[T]) {}

/cc @findleyr @griesemer @ianlancetaylor

Will investigate. I suspect that the fix in https://go.dev/cl/361922 may be incomplete.

Ok, I looked into it and the fix from CL 361922 was indeed incomplete.
I have experimented with a couple solutions, and mailed one in https://go.dev/cl/386718. Reproducing the commit message here for discussion:
The check for invalid cycles through type parameter lists was too
coarse, resulting in inconsistent reporting of errors depending on
type-checking order.

Consider the following example:

  type A interface{ M(B[T]) }
  type B[_ A] struct{}

In this example, if we type-check A first, we will subsequently
type-check B, and encounter the cycle to A while inside the type
parameter list for B. However, if we type-check B first, we will
encounter the cycle to B while type checking the declaration of A (i.e.
not while inside a type parameter list). This means that our existing
heuristic for invalid cycles through type parameter lists depends on the
location of that type parameter list in the type-checking cycle.

As I understand it, we have two options to resolve this inconsistency:

1. Make the ambient type parameter list a global property of the
   type-checking pass, rather than scoped to the current object
   declaration (via types.environment). This would result in more
   invalid cycles.
2. Only raise an invalid cycle error if we are cycling back to the
   generic type that holds the current type parameter list. This would
   result in fewer invalid cycles, but still avoids the deadlock of
   [#49439](https://golang.org/issue/49439).

That CL implements option #2, which feels more correct but is also riskier. We should perhaps implement option #1 for 1.18 (if anything).

@griesemer I think we decided not to fix this for 1.18, correct? Shall I move to the 1.19 milestone?

Yes, I think pending CL may have subtle repercussions; any change in the cycle detection algorithm may have non-local effects. We decided to wait for 1.19 as this is not a release blocker.
Moving to 1.19.

Just grooming issues, this may have fallen through the cracks.
@griesemer let's discuss whether to bump this to 1.20, or land a fix for 1.19.

@griesemer do we want to fix this for 1.20? I can revisit my CL.

@findleyr We still have some time, so yes, let's see if we can address this.

This was a complicated one, and we had higher priorities (even higher priority fixes to validType). I think we should aim for early-in-cycle 1.21 (but actually early, this time).

I thought about this more today, and while I think the fix in https://go.dev/cl/386718 is OK, I actually think we could go one step further: why can't we just allow cycles through constraints? If a cycle occurs through a constraint, that constraint is still well-defined, and we only need to verify instances that occur in the source, which is by definition a finite number of instances.
I think the guard was originally added to avoid infinite recursion, but we have since developed better mechanisms for this.

Not happening for 1.21, but I think we know what to do. Should land this early in 1.22 cycle.


Adding proper links

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.03%) to 61.039%

Files with Coverage Reduction
New Missed Lines
%

pynapple/io/neurosuite.py
1
15.37%

Totals

Change from base Build<PHONE_NUMBER>:
-0.03%

Covered Lines:
1798

Relevant Lines:
2860

💛  - Coveralls


Mergeback after v3.7.0 release

Proposed v3.7.0 mergeback
NOTES:

[ ] if we change the citation text, see #5453 , then that should also be included here (before merging)
[ ] must be merged with a MERGE COMMIT (not squashed) -- requires a temporary settings change by an Iris maintainer

Consult Iris pull request check list

if we change the citation text, see https://github.com/SciTools/iris/pull/5453 , then that should also be included here (before merging)

Personally I'd rather this not be delayed by that, especially if it is going to be much longer. Currently the latest Iris docs looks like:

Which is out of date and may be confusing to a user. At least I was temporarily confused by it!

Bump for this to happen!
#5526 removed the release candidate ref but added the wrong release date.
This at least needs to go in before the Iris 3.8 release. But really should have gone in as part of the 3.7 work

Bump for this to happen!
#5526 removed the release candidate ref but added the wrong release date.
This at least needs to go in before the Iris 3.8 release. But really should have gone in as part of the 3.7 work

Hahah that was also a jinx moment! @pp-mo @HGWright how come this is still here? Do you need help from any of us?


Configuring VS Code on Local servers with Tenerife CTP16 for Extensions 2.0

I am trying to set up the environment for publishing Extensions 2.0 from visual studio code on local servers but with no success to connect from VS Code to NAV.
Tenerife service (CTP16 build 18843 for NA) is setup with enabled development endpoint (port 7049), and I can open Win client on address:
devnav20181:7046/dynamicsnavdemo
Visual Studio code is using extension for AL Language 0.10.13928 (October Update).
When I try to download symbols I get the following message:
[2017-11-02 08:38:34.03] Using reference symbols cache path: c:\Users\idordevic\Documents\AL\ALProject2\.alpackages
[2017-11-02 08:38:34.03] Sending request to http://devnav20181:7049/dynamicsnavdemo/dev/packages?publisher=Microsoft&appName=US&versionText=<IP_ADDRESS>
[2017-11-02 08:38:34.03] Sending request to http://devnav20181:7049/dynamicsnavdemo/dev/packages?publisher=Microsoft&appName=System&versionText=<IP_ADDRESS>
[2017-11-02 08:38:34.05] The request for path /dynamicsnavdemo/dev/packages?publisher=Microsoft&appName=US&versionText=<IP_ADDRESS> failed with code NotFound. Reason: No published package matches the provided arguments.
[2017-11-02 08:38:34.06] Could not download reference symbols. Please ensure that:
1. The correct server name and instance are specified in the launch.json file.
2. The correct application locale and version are specified in the app.json file.

This is mine launch.json file:
"version": "0.2.0",
	"configurations": [
		{
			"type": "al",
			"request": "launch",
			"name": "devnav20181",
			"server": "http://devnav20181",
			"serverInstance": "dynamicsnavdemo",
			"tenant": "",
			"authentication": "Windows",
			"startupObjectId": 22
		}
	]

And app.json:
{
  "id": "cc3dc56d-6f23-4d98-a2c5-1f61b2cefaaa",
  "name": "ALProject2",
  "publisher": "Default publisher",
  "brief": "",
  "description": "",
  "version": "<IP_ADDRESS>",
  "compatibilityId": "<IP_ADDRESS>",
  "privacyStatement": "",
  "EULA": "",
  "help": "",
  "url": "",
  "logo": "",
  "capabilities": [],
  "dependencies": [],
  "screenshots": [],
  "platform": "<IP_ADDRESS>",
  "application": {
    "version": "<IP_ADDRESS>",
    "locale": "US"
  },
  "idRange": {
    "from": 50100,
    "to": 50149
  }
}

You are using outdated AL Language extension. CTP16 build is newer than October Update so you need to use the AL Language from the same build. There was another issue for this recently with instructions how to get the right .vsix file.

I see there are #878 and #802. If I try with docker to download devpreview image in order to get new .vsix file with:
docker run -m 3G -e ACCEPT_EULA=Y -e USESSL=N -e navdocker.azurecr.io/dynamics-nav:devpreview-finus

I still get the same version of al extension 0.10.13928:
http://f91d59709e0c:8080/al-0.10.13928.vsix

Might be that I have to first delete existing image locally and download new one from navdocker.azurecr.io server

Think of AL Language as a client. If you're using server from CTP16 you should be using a client from CTP16. Therefore you should use vsix from docker image from CTP16, not from October Update.

Understand, thanks. Will try that. It'd be easier if AL Language extension is then shipped with Tenerife CTP DVD.

That was it. Work with AL Extension version 14380:
al-0.11.14380.vsix
Thanks!


Merge main into dev 1.29

Merging main into dev-1.29 to maintain sync

/approve

This appears to also require approval from Steering.
/assign @justaugustus @palnabarun @mrbobbytables @BenTheElder @pacoxu @soltysh @pohly

/approve

/approve


docs: Deprecate jaeger exporter

Description
I am working on a pull request for a deprecate issue for Jaeger exporter.
Steps:

[x] Add a Deprecated tag from Documents to Jaeger
[x] Add OTLP Http Support

Fixes:
https://github.com/cerbos/cerbos/issues/1784
Checklist

[ ] The PR title has the correct prefix
[ ] PR is linked to the corresponding issue
[x] All commits are signed-off (git commit -s ...) to provide the DCO

@haines Hey ✋ ,
This PR Example is for your comment on the issue. Can you check this?

Hi,
I see your comments and I will make the adjustments. I will do additional tests for the HTTP part and see what you say

We're doing a full migration to OTLP at the moment and this area has already been covered by one of those updates. Therefore, I am going to close this PR. Thank you very much for your efforts and continued support for Cerbos.


Module build failed: Error: Couldn't find preset "latest" relative to directory

Just installed the plugin and added it to my app.js file. I'm doing SSR.
import Notifications from 'vue-notification/dist/ssr.js'
Vue.use(Notifications)

Now I'm getting this error:

Module build failed: Error: Couldn't find preset "latest" relative to directory "/src/app/node_modules/vue-notification"

I guess this is easily solvable using:
npm install --save-dev babel-preset-latest
However this preset is deprecated, so we should avoid it in this plugin and use babel-preset-env instead.

I dont think it's plugin's issue. It is already "babeled" and transpiled .


apt-get update calls fails during image build

Output of docker version:
Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:47:50 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:47:50 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 5
 Running: 0
 Paused: 0
 Stopped: 5
Images: 8
Server Version: 1.11.2
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 58
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge null host
Kernel Version: 3.19.0-49-generic
Operating System: Ubuntu 14.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.954 GiB
Name: osboxes
ID: SIY5:LBAC:EVBS:R2FL:XATS:LUYR:HL35:SERV:OIDS:UDLW:ENBX:NWXR
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support

Additional environment details (AWS, VirtualBox, physical, etc.):
Steps to reproduce the issue:
Building the following DockerFile on an Ubuntu image using VirtualBox on a Mac
FROM ubuntu:14.04
MAINTAINER Jonathan Alvarsson<EMAIL_ADDRESS>RUN apt-get update && apt-get install -y --fix-missing \
  default-jre \
  gunicorn \
  nginx \
  python.pip \
 && rm -rf /var/lib/apt/lists/*

Describe the results you received:
docker build .
Sending build context to Docker daemon 2.048 kB
Step 1 : FROM ubuntu:14.04
 ---> 38c759202e30
Step 2 : MAINTAINER Jonathan Alvarsson<EMAIL_ADDRESS> ---> Using cache
 ---> 3f472bd5003f
Step 3 : RUN apt-get update && apt-get install -y --fix-missing   default-jre   gunicorn   nginx   python.pip  && rm -rf /var/lib/apt/lists/*
 ---> Running in 4ca6a21defda
Err http://archive.ubuntu.com trusty InRelease

Err http://archive.ubuntu.com trusty-updates InRelease

Err http://archive.ubuntu.com trusty-security InRelease

Err http://archive.ubuntu.com trusty Release.gpg
  Could not resolve 'archive.ubuntu.com'
Err http://archive.ubuntu.com trusty-updates Release.gpg
  Could not resolve 'archive.ubuntu.com'
Err http://archive.ubuntu.com trusty-security Release.gpg
  Could not resolve 'archive.ubuntu.com'
Reading package lists...
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/InRelease

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-updates/InRelease

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-security/InRelease

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty/Release.gpg  Could not resolve 'archive.ubuntu.com'

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-updates/Release.gpg  Could not resolve 'archive.ubuntu.com'

W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-security/Release.gpg  Could not resolve 'archive.ubuntu.com'

W: Some index files failed to download. They have been ignored, or old ones used instead.
Reading package lists...
E: Unable to locate package default-jre
E: Unable to locate package gunicorn
E: Unable to locate package nginx
E: Unable to locate package python.pip
E: Couldn't find any package by regex 'python.pip'
Building dependency tree...
Reading state information...
The command '/bin/sh -c apt-get update && apt-get install -y --fix-missing   default-jre   gunicorn   nginx   python.pip  && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100

Describe the results you expected:
I was expecting it to be able to access the repositories and install the packages during build
Additional information you deem important (e.g. issue happens only occasionally):
From the VM I have full access to internet and can run, e.g., "sudo apt-get update". I have seen this similar problem: http://stackoverflow.com/questions/24151129/docker-network-calls-fail-during-image-build-on-corporate-network and suspected a DNS problem. From my network settings of my mac I was able to pull out some DNS servers that I have tried. I have also tried what I think are the google ones. My /etc/default/docker file looks like this:
# Docker Upstart and SysVinit configuration file

#
# THIS FILE DOES NOT APPLY TO SYSTEMD
#
#   Please see the documentation for "systemd drop-ins":
#   https://docs.docker.com/engine/articles/systemd/
#

# Customize location of Docker binary (especially for development testing).
#DOCKER="/usr/local/bin/docker"

# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="--dns <IP_ADDRESS> --dns <IP_ADDRESS>"
DOCKER_OPTS="-H tcp://<IP_ADDRESS>:2376"

# If you need Docker to use an HTTP proxy, it can also be specified here.
#export http_proxy="http://<IP_ADDRESS>:3128/"

# This is also a handy place to tweak where Docker's temporary files go.
#export TMPDIR="/mnt/bigdrive/docker-tmp"

It is possibly an MTU issue? Can you try adding --mtu 1420 to the daemon flags andsee if that makes a difference (it may not but worth checking).

sure, how do I do that? :)

I get the same error on a new VirtualBox image running Ubuntu 16.04 as well

Changed /etc/systemd/system/docker.service to have line: ExecStart=/usr/bin/docker daemon -H fd:// --mtu 1400. Made no difference

Did you do a sudo systemctl daemon-reload and sudo systemctl restart docker after changing?

I did sudo service docker restart, those other ones I have never seen. If I do RUN cat /etc/resolv.conf in the Dockerfile after having changed dns settings to other servers though I get this:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
search farmbio.uu.se

nameserver <IP_ADDRESS>
nameserver <IP_ADDRESS>

so I am guessing that it didn't take...

$ sudo systemctl daemon-reload
[sudo] password for jonathan:
sudo: systemctl: command not found

After some google:ing it seems that Ubuntu doesn't use systemctl (systemd) but something called upstart. Could this be related to why it seems my DNS changes are not having effect? Can I perhaps get Docker to get the DNS settings from the host system somehow?

OK, it works on Ubuntu 16.04 but not on Ubuntu 14.04


Importing a cgo package messes with line numbers

Please answer the following before submitting your issue:
Note: Please include any substantial examples (debug session output,
stacktraces, etc) as linked gists.

What version of Delve are you using (dlv version)?

Version: 1.0.0-rc.2
Build: a5b230b81d0d23bf3f0681235de6bb90d6a956d0

What version of Go are you using? (go version)?

go version go1.9.2 darwin/amd64

What operating system and processor architecture are you using?

macOS 10.12.6
Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64

What did you do?

Attempted to stop on a breakpoint after importing go-sqlite3.

What did you expect to see?

Stopping on the breakpoint, as usual.

What did you see instead?

Breakpoint was not recognized.

I realize there are a lot of issues about cgo, and that you're hard at work on them already. For the most part it seemed to work, except line numbers are all over the place, and mess with source mapping. Here is a simple example, I built:
package main

import (
	"fmt"
)

func sayHello() {
	fmt.Println("Hello World!")
}

func main() {
	sayHello()
}

I want to break inside sayHello. Here is my debugger session:
$ dlv debug .
Type 'help' for list of commands.
(dlv) b main.go:8
Breakpoint 1 set at 0x10b26c1 for main.sayHello() ./main.go:8
(dlv) c
> main.sayHello() ./main.go:8 (hits goroutine(1):1 total:1) (PC: 0x10b26c1)
     3:	import (
     4:		"fmt"
     5:	)
     6:
     7:	func sayHello() {
=>   8:		fmt.Println("Hello World!")
     9:	}
    10:
    11:	func main() {
    12:		sayHello()
    13:	}

Adding a breakpoint using the func name works too.
(dlv) b sayHello
Breakpoint 2 set at 0x10b26b3 for main.sayHello() ./main.go:7

Now I add the following import:
import(
    "fmt"

    _ "github.com/mattn/go-sqlite3"
)

Here is my debugger session:
$ dlv debug .
Type 'help' for list of commands.
(dlv) b main.go:9
Command failed: no code at /Users/chrales/Work/go-workspace/src/dlv-cgo-bug/main.go:9
(dlv) b sayHello
Breakpoint 1 set at 0x410bf03 for main.sayHello() ./main.go:1320062
(dlv) c
> main.sayHello() ./main.go:1320062 (hits goroutine(1):1 total:1) (PC: 0x410bf03)

Issues:

couldn't set a breakpoint at a valid line number
setting a breakpoint using function name works, but indicates an invalid line number (main.go:1320062)
when dlv stops at the breakpoint, it is unable to show the corresponding Go source

This can not be reproduced with a development version of go. It's likely that this is a different manifestation of https://github.com/golang/go/issues/22068 (fixed during 1.10 cycle).

Is there a workaround for this besides using a development version of go? That's not a great option for me.

@aarzilli Hmm I'm still seeing this even with a binary produced with go tip. Do I need to recompile delve against the new go as well, or something?

No, you don't need to recompile delve. Make sure you are really using the go version compiled from tip, if you are I would need to see the compiled binary.

On second thought this is a bug in delve.


Find best way of installing Docker

There are too many ways Docker install can fail.
Today I noticed the apt repo was down (at least briefly), and apt-get update timed-out causing everything else to fail. Besides, we have seen https://github.com/docker/docker/issues/22599, which remains unresolved. In GCE we have curl https://get.docker.com | sh and in EC2 we install the official Debian package. I think that we should define some kind of standard way, and whatever we do probably should keep retrying until it succeeds.

An alternative would be to use pre-baked images, which could work for some user, but makes certain things harder, and potentially leads to the route where root filesystem is considered immutable... For example, when user wishes to use their own images, they would have to be comfortable with our tooling, and understand what needs to be done when they wish to amend such images and if they should  trigger an update when publish updates, if they chose to keep on the immutable route; or what's the proper way for them to make any changes on running instances. I think that pre-baked images are a great optimisation, but it's something that needs to be very explicit, so I'd rather leave this to the user to implement they way they wish to, and instead rely on upstream distro channels to provide base images.

ref #137

@errordeveloper we came into this problem ourselves delivering our Kubernetes/swarm bundles. We have just started adopting the pattern of delivering the Docker binary ourselves. The idea is to only support point in time releases, and always move the users forward just like Docker Inc. has been encouraging with their upstream repos.
Its a little onerous to just take over all the packaging, but its like this: We're putting a binary blob on disk that does everything we need it to (thanks docker peeps for the dynamic bin!), and some dependency packages. Those are all served up by the distro backing the installation. Additionally some configuration files around the filesystem.
Seems straight forward enough unless the CGROUPS mounts get a drastic change, but its less likely to break or be unavailable if you're shipping that configuration+payload yourself, rather than relying on the extant sources. I'm pretty sure terraform has some mechanisms for delivering binary payloads during provisioning. [needs citation]