text:
[CAM-10087] enable XML secure processing

related to https://app.camunda.com/jira/browse/CAM-10087
related to https://github.com/camunda/camunda-bpm-platform/pull/366

updates on https://github.com/camunda/camunda-xml-model/pull/8 by handling if the external schema property can not be set on the parser

repo: camunda/camunda-xml-model


text:
Autotranslation

Using the google translate API to allow users to translate content in English or French.

I think this is a duplicate of #612

You are right!

source: gharchive/issue

authors: fredericlestage-vdm smellems

repo: canada-ca/ore-ero

license: MIT

license_type: permissive

license_source: github-api


text:
Use versioned sequence identifiers from SeqRepo

The SeqRepo datastore has been updated to use versioned Ensembl identifiers (see https://github.com/biocommons/biocommons.seqrepo/issues/80). VarLex will fail to find protein sequences for users  doing fresh installs / seqrepo pulls.
We should revise VarLex to use versioned identifiers for SeqRepo client queries. We should also build in some QA to identify when an alias is not present in the SeqRepo client (as opposed to when a query is outside of the range of a given sequence).

Per @acoffman:

Ah-ha that makes sense. I believe the transcript file we're using has versioned and unversioned columns (if i'm remembering correctly) so just changing which column we import may fix it for now. I was importing the ones without versions because that's what Seqrepo supported at the time
Yeah, so here: https://github.com/GenomicMedLab/varlex/blob/master/varlexapp/data_sources/transcript_mappings.py#L17
protein_transcript = row['Protein stable ID']

We now use protein_transcript = row['Protein stable ID version'] this change can be seen here.

authors: ahwagner korikuzma

repo: cancervariants/variant-normalization


text:
Update README.md

Updated Supported API's sections
Removed Future support!
Now in MVP!

Codecov Report

Merging #30 (82d1d09) into main (7e927d2) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #30   +/-   ##
=======================================
  Coverage   98.21%   98.21%
=======================================
  Files          76       76
  Lines        3189     3189
  Branches      285      285
=======================================
  Hits         3132     3132
  Misses         39       39
  Partials       18       18

Continue to review full report at Codecov.

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

source: gharchive/pull-request

authors: canhorn codecov-io


text:
Fix default value for json.loads

Issue
#132 itest is currently failing for a JSONDecodeError becaus a fix in #114 didn't quite fix the problem.
Solution
Instead of
https://github.com/canonical/loki-k8s-operator/blob/c7e25d66ad8d5f158378910e3e54f33a71f1462b/lib/charms/loki_k8s/v0/loki_push_api.py#L2009
it should be get("endpoints", "[]")), similar to elsewhere in the same file:
https://github.com/canonical/loki-k8s-operator/blob/c7e25d66ad8d5f158378910e3e54f33a71f1462b/lib/charms/loki_k8s/v0/loki_push_api.py#L1611
Context
#114 was merged with a red itest after confirming the tests pass locally. Seems like they passed due to timing coincidence that avoided raise_on_error.
Testing Instructions

Checkout cassandra, copy over the loki_push_api from this PR, and pack.
From the loki dir, cp ../cassandra-k8s-operator/cassandra-exporter-agent.jar .
Modify test_rerelate to upgrade the cassandra charm from local path immediately after deployment. See suggested diff below.
tox -e integration -- -k test_rerelate

diff --git a/tests/integration/test_rerelate.py b/tests/integration/test_rerelate.py
index 33920af..e4ebe0c 100644
--- a/tests/integration/test_rerelate.py
+++ b/tests/integration/test_rerelate.py
@@ -60,6 +60,14 @@ async def test_build_and_deploy(ops_test: OpsTest, loki_charm):
         *[app.deploy(ops_test) for app in related_apps],
     )

+    await ops_test.model.applications["cassandra"].upgrade_charm(
+        path="/home/ubuntu/code/cassandra-k8s-operator/cassandra-k8s_ubuntu-20.04-amd64.charm",
+        resources={
+            "cassandra-image": "cassandra:3.11",
+            "cassandra-prometheus-exporter": "cassandra-exporter-agent.jar"
+        }
+    )
+
     await asyncio.gather(
         *[ops_test.model.add_relation(app_name, app.name) for app in related_apps],
     )
@@ -112,6 +120,15 @@ async def test_rerelate_app(ops_test: OpsTest):
     await asyncio.gather(
         *[app.deploy(ops_test) for app in related_apps],
     )
+
+    await ops_test.model.applications["cassandra"].upgrade_charm(
+        path="/home/ubuntu/code/cassandra-k8s-operator/cassandra-k8s_ubuntu-20.04-amd64.charm",
+        resources={
+            "cassandra-image": "cassandra:3.11",
+            "cassandra-prometheus-exporter": "cassandra-exporter-agent.jar"
+        }
+    )
+
     await asyncio.gather(
         *[ops_test.model.add_relation(app_name, app.name) for app in related_apps],
     )

Unfortunately the itest will still fail on github workflow because:

cassandra has loki_push_api with the bug this PR is fixing.
cassandra may fail due to #51.

Release Notes
Fix default value for json.loads in loki_push_api.

As a general pattern of the "testing pyramid" which has been discussed to death, integration tests for individual charms should not be dependent on other charms which use the same libraries for exactly this reason.

This, very much this. We need to remove all dependencies to "real" charms from our charm-local integration tests asap.
That goes for Cassandra, Avalanche, and any other I've forgotten alike. Tester charms used as part of integration tests should live near the charm, preferably in the same repository.

Currently, loki-tester is only loki_push_api tester.
Is the intention to have one tester for all relations or one tester charm per relation?
@rbarry82 @simskij

Superseded by #139

authors: sed-i simskij


text:
test-branch/execute-job/wrong-commit-sha-on-pr/45605347-c706-418a-b251-dd10254a5d1d

PR for testing 2330601dfa938ea01ace6f34e407593ee40481e2

/canonical/self-hosted-runners/run-workflows 931ad21dd9ace68aaa0a7d341e94de96ad93fa6b

repo: canonical/repo-policy-compliance-tests


text:
test-branch/execute-job/wrong-comment-on-pr/a288d080-2a51-47e7-ae1d-bc78f34e3b2e

PR for testing f72327ae8255a3ea7c58a3472e8ef743d64b04f7

comment 1


text:
test-branch/execute-job/wrong-comment-on-pr/fcfdb54e-91ee-40bc-ac0e-d2db119d321f

PR for testing 0577fc3280c28576f267a000bcede317d7dadf5d

comment 1

repo: canonical/repo-policy-compliance


text:
test-branch/execute-job/quoted-authorization/dbbb412a-59ad-4e1c-b21b-819def315ac4

PR for testing be3e3c053f726070187f2f9858f8526871123a64

/canonical/self-hosted-runners/run-workflows be3e3c053f726070187f2f9858f8526871123a64


text:
Tickets Aguardando aparece para todos usuarios

Nos tickets aguardando, não deveria aparecer apenas para suas respectivas filas sem q outros usuários de outras filas ou conexões vejam?

Ola @wammachado,
Não sei se eu entendi exatamente, mas acho que ele já tem este comportamento, porém, os tickets que não possuem uma  fila definida, vai aparecer sempre para todos os usuários.

Entao, exemplo:
Usuario Wender esta vinculado às filas A, B e C.
A conexao 9999-9999 esta vinculado à fila D
o usuario Myllena esta vindulado apenas a fila D
Quando a myllena esta logada e vai na aba de tickets aguardando ela ve as
mensagens aguardando nas filas A, B, C e D (Todas as FIlas) pois quando
chega um ticket no numero 9999-9999 o sistema ja entende q estes
atendimentos estao na fila D.
Porem mesmo assim, ela ve as mensagens aguardando nas filas q nao pertence
à ela, e isso nao é legal , pois ela pode acabar assumindo um atendimento
que nao pertence à ela.
Em qui., 2 de fev. de 2023 às 21:19, Lucas Silva @.***>
escreveu:

Ola @wammachado https://github.com/wammachado,
Não sei se eu entendi exatamente, mas acho que ele já tem este
comportamento, porém, os tickets que não possuem uma fila definida, vai
aparecer sempre para todos os usuários.
—
Reply to this email directly, view it on GitHub
https://github.com/canove/whaticket-community/issues/509#issuecomment-1414542416,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJKLQIYG457RY5JKGTZZS5LWVRFIVANCNFSM6AAAAAAUMZFT4E
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

seguem exemplos em prints
o usuario @.*** nao pertence a fila Finder IT e
quando loga ele ve os tickets aguardando na fila finder it
[image: image.png]
[image: image.png]
[image: image.png]
[image: image.png]
[image: image.png]
Em qui., 2 de fev. de 2023 às 21:19, Lucas Silva @.***>
escreveu:

Ola @wammachado https://github.com/wammachado,
Não sei se eu entendi exatamente, mas acho que ele já tem este
comportamento, porém, os tickets que não possuem uma fila definida, vai
aparecer sempre para todos os usuários.
—
Reply to this email directly, view it on GitHub
https://github.com/canove/whaticket-community/issues/509#issuecomment-1414542416,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJKLQIYG457RY5JKGTZZS5LWVRFIVANCNFSM6AAAAAAUMZFT4E
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

@wammachado, não consigo visualizar as imagens, acho que o Github não mostra as imagens enviadas quando se responde por e-mail, perderia encaminha-las pelo próprio Github ?

@Luskan777 agora q vi, q as mensagem q chegam realmente nao tem nehuma fila atribuida, apenas conexao atribuida, eu confundi a conexão com a fila, ele so identifica a fila caso o cliente ja tenha sido atendido por alguma fila anteriormente.
Obrigado pelo retorno

@Luskan777  Retomando esse assunto, gostaria de saber se tem como os tickets aguardando que ficam atribuídos à uma conexao especifica so aparecer para os usuarios q estiverem atribuídos a esta conexão?
Ou seja, caso o usuario nao tiver nenhuma conexao atribuida ele possa ver todos os tickets aguardando normalmente.
Porem caso o usuario seja atribuido à uma conexao especifica ele so ve os tickets aguardando pertecentes à esta conexao.

Ola @wammachado ,
Acredito que não amigo, pelo o que eu pude entender da aplicação, a permissão dos ticket é feita apenas pela Fila em que o ticket é vinculado, e não pela conexão que a mensagem é recebida. Se o ticket não for  vinculado a nenhuma fila, então todos tem permissão, isso indefere da conexão padrão em que o usuário é vinculado, pelo menos até onde eu sei.
Agora, se isso não for possível, e acredito que não seja mesmo, seria uma melhoria interessante a se ter. Transformaria a conexão como se fosse uma entidade pai, de forma com que os usuários que sejam vinculados a X conexão, só tenham permissão para ver e operar nos tickets que a conexão X recebe, em suas respectivas filas em que o usuário é atribuído também.

Eu ainda não tive essa necessidade, eu acho que a permissão dos tickets de acordo com a  fila que é vinculado funciona muito bem.
Sendo que eu vincule as conexões as respectivas filas, dificilmente terei tickets em aguardo sem filas vinculadas.

Seria sim interessante:
1-se o usuario nao estiver atribuido a nenhuma conexao ele tem acesso as
mensagens de todas as conexoes, mas caso ele tenha atribuido a uma conexao
ele so veria as mensagens dessa conexao a nao ser q outra conexao tenha
encaminhado a mensagem para o departamento dele
2- exemplo: um usuario do suporte so tem acesso a conexao do numero do
suporte, entao ele pode atender ao cliente tratar o suporte e depois
encaminha ao financeiro, a partir dai ele nao tem mais acesso as mensgens
exceto a conexao dele receba algum encaminhamento do financeiro, pois pode
ter conversa do departamento financeiro que o suporte nao tenha q ver.
Em ter., 7 de fev. de 2023 às 10:52, Lucas Silva @.***>
escreveu:

Eu ainda não tive essa necessidade, eu acho que a permissão dos tickets de
acordo com a fila que é vinculado funciona muito bem.
Sendo que eu vincule as conexões as respectivas filas, dificilmente terei
tickets em aguardo sem filas vinculadas.
—
Reply to this email directly, view it on GitHub
https://github.com/canove/whaticket-community/issues/509#issuecomment-1420808292,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJKLQI7OT5NKN7JY27X4INDWWJHSDANCNFSM6AAAAAAUMZFT4E
.
You are receiving this because you were mentioned.Message ID:
@.***>

--

Neste caso, não sei se seria possível essa parte da transferencia, pois seriam 2 conexões diferentes, ou seja, 2 números de WhatsApp, transferir uma conversa de uma conexão para outra não seria possível dentro da infraestrutura da aplicação, pois teria que transferir uma conversa de um número para o outro. A transferencia seria possível apenas por filas.
Neste cenário, você teria que ter um número geral, e filas separadas para cada departamento, mas basicamente a aplicação já funciona desta forma.
Analisando a fundo, não sei se possuímos motivos viáveis para melhorias nessa parte.  O problema em questão aqui é o fato das mensagens que não possuem filas vinculadas aparecerem para todos, e isso de fato é um problema.  Geralmente isso ocorre quando você adiciona uma conexão e não atribui uma fila para ela, então ao receber novas mensagens, elas ficam sem fila, aparecendo assim para todos, estando em aguardo ou não.
Porém, a aplicação nos fornece formas de resolver isso, que seria transferir para a fila correta.  No caso das mensagens que ficam em aguardo sem fila definida,  como eu já mencionei, uma vez que você atribui a conexão a uma única fila, todas as mensagens futuras que essa conexão (número) receber, automaticamente já serão designadas para a respectiva fila.

Acho que estou com o mesmo problema, eu atribui 3 conexões a 3 filas diferentes, porem quando alguem manda mensagem, meio que aparece para todos, existe alguma forma de que, a pessoa X mandou msg para a conexão 1 só seja vista pela pessoas que estão definitas pela conexão 1 e fila atribuiada a conexão 1?

Entendi, parece correto mesmo. Vou tentar fazer.
Me incomoda esconder todos tickets sem fila atribuída pq tem gente que nao responde corretamente o botzin das filas.
Mas com a sugestão do @wammachado, dá pra fazer um filtro para que os usuários que possuem determinada conexão como padrão possam ver os tickets sem fila apenas daquela conexão.
É util quando ja existem numeros de whatsapp divulgados para diferentes setores.
Mas como o @Luskan777 apontou, pode ficar confuso se misturar as filas entre as conexões.

TicketsList/index.js

TicketsManager/index.js
Estou testando uma abordagem frontend:
Se showAll estiver desabilitado, só mostra os tickets sem fila da mesma conexão que a padrão do usuário.
Se showAll estiver habilitado, mostra tudo.
O ticket ainda vem na requisição ao backend eu só escondo ele no front mesmo.

authors: Horgun Luskan777 codsec wammachado

repo: canove/whaticket-community


text:
users management ?

Hi,
I'm unable to find out how do we manage users in huginn, as the admin user ?

Hey @calimou.  We don't currently have a user management UI.  You could configure them in the Rails console, which is obviously not ideal.

+1 for this feature.

I've added a bounty to this issue.

I will be working on that as part of my contract with www.kreuzwerker.de
Features we have planned:

List users
Create new users from the admin interface
Edit existing users
Make devise options configurable (lockable variables, confirmable durations, etc.)
Manually de- and reactivate a user (should also stop the agents from running)

One other feature request for something I think would be useful: the ability for admin users to directly make changes to a user's agents.

Awesome @dsander!

@albertsun That is a great idea, I might work on this after we have the initial version merged.

@cantino @dsander It seems like the admin user management panel has already been done according to the merged pr referenced here. Is this ticket still open because of @albertsun request?

That should really be moved into a separate issue.

Then I guess this ticket should close then.

Yup, thanks to @dsander!

authors: Jngai albertsun calimou cantino dsander kirantpatil

repo: cantino/huginn

license: mit

license_source: bigquery


text:
For for Map

Hello. I tried to use Map in a for-loop
let keySet = map.keySet();
// doesn't work
for (let key of keySet) {
  // ...
}
// doesn't work
for (let key in keySet) {
  // ...
}

I have set all the necessary parameters
javetProxyConverter.getConfig().setProxyMapEnabled(true);
javetProxyConverter.getConfig().setProxySetEnabled(true);

Map object
Map<String, Object> map = new HashMap<>() {{
                put("x", 1);
                put("y", 2);
            }};

How can I do this?

I removed
javetProxyConverter.getConfig().setProxyMapEnabled(true);
javetProxyConverter.getConfig().setProxySetEnabled(true);
And everything worked
But I don't have access to .keySet(). I need for-loop for Map, and .keySet(). How to do it?

Have you tried the bridge converter?
The proxy converter tries to apply JS native array, set, object to the Java counterparts so that getting both JS and Java behaviors altogether is very challenging. But, you can polyfill the JS object with the Java API.

authors: PyXiion caoccao

repo: caoccao/Javet


text:
A fatal error has been detected by the Java Runtime Environment

Hello, please see the following error created on a Ubuntu 20.04.2 LTS test server running Wildfly 20 with JDK 11. The OS has 32GB of memory with 50% assigned to Java.
The Javet code version is the latest artifact from GitHub actions for the project, as of today.
I do not have a simple test case; For now I can offer a concise example of the code and the error generated. The method below matches the link of the logs below from the Java error though it is obviously not a full test case.
The logs of my code show "Javet can't setMaxHeapSize, flags are sealed" . I didn't notice that in my last comment in the other issue. The monitoring we use for the server doesn't indicate low memory and the Linux OOM killer is not a factor though the server is getting hit hard so free memory is reduced. This code is executed many times across three servers via web services that are load balanced.
Thank you for your time and promising project. Please set me straight if this is a matter of a simple coding error. The following code is migrated from J2V8.
                   private V8Runtime runtime;

public String runMyCalculations(Long deptID, ATUserBO requestUserBO, Date historicalDate, ATUserViewStateDTO viewStateDTO, List requestedGroupStatsFieldList,  Map criteria, Map inputData, List<Map<String,Object>> overrides, Boolean saveToFAR, Boolean anonymize, Boolean verboseLogging,  String uuid, RAPIDiagnostics rapiDiagnostics) throws Exception {
try {
V8Host v8Host = V8Host.getV8Instance();
V8Flags flags = v8Host.getFlags();
if (!flags.isSealed()) {
flags.setMaxHeapSize(2048);
} else {
logger.error(logPrefix + "Javet can't setMaxHeapSize, flags are sealed");
}
                            runtime = v8Host.getV8Instance().createV8Runtime();
                            String calculationOutput = runtime.getExecutor(script).executeString();
                        } finally {
                           if (runtime != null) {
                               logger.debug(logPrefix + "starting release ... ");
                               runtime.close();
                               runtime=null;
                               logger.debug(logPrefix + "done release ... ");
                        }
                    }

Link of file hs_err_pid2779254.log
https://drive.google.com/file/d/1iSc4ZVVJ2HjjMGqGG4xkPrZ5_wSSwQ0q/view?usp=sharing

For further clarification, the error seems related to close() , in a nutshell the above link should be quick to spot this error in the native code error:
R13={method} {0x00007fb3464b98d8} 'closeV8Runtime' '(J)V' in 'com/caoccao/javet/interop/V8Native'
R14=0x00007fb3460cc717: <offset 0x00000000011d0717> in /tmp/javet/2779254/libjavet-v8-linux-x86_64.v.0.9.13.so at 0x00007fb344efc000
R15=0x00007fb38ca4b6d0 points into unknown readable memory: 0x000017f6bc509169 | 69 91 50 bc f6 17 00 00

Thank you for reporting this. It's the first time that Javet was reported to fail with the following call stack.
Stack: [0x00007fb3ad0f9000,0x00007fb3ad1fa000],  sp=0x00007fb3ad1f7ab0,  free space=1018k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libjavet-v8-linux-x86_64.v.0.9.13.so+0x5b7194]
C  [libjavet-v8-linux-x86_64.v.0.9.13.so+0x5b7401]  v8::Context::SetEmbedderData(int, v8::Local<v8::Value>)+0x21
C  [libjavet-v8-linux-x86_64.v.0.9.13.so+0x58fbe9]  Javet::V8Runtime::Unregister(v8::Local<v8::Context> const&)+0x69
C  [libjavet-v8-linux-x86_64.v.0.9.13.so+0x58f1fe]  Javet::V8Runtime::CloseV8Context()+0x80
C  [libjavet-v8-linux-x86_64.v.0.9.13.so+0x58f9ea]  Javet::V8Runtime::~V8Runtime()+0x2e
C  [libjavet-v8-linux-x86_64.v.0.9.13.so+0x58fa50]  Javet::V8Runtime::~V8Runtime()+0x1c
C  [libjavet-v8-linux-x86_64.v.0.9.13.so+0x56c402]  Java_com_caoccao_javet_interop_V8Native_closeV8Runtime+0x64
j  com.caoccao.javet.interop.V8Native.closeV8Runtime(J)V+0
j  com.caoccao.javet.interop.V8Host.closeV8Runtime(Lcom/caoccao/javet/interop/V8Runtime;)V+42
j  com.caoccao.javet.interop.V8Runtime.close(Z)V+20
j  com.caoccao.javet.interop.V8Runtime.close()V+13

Possible Root Cause
I suspect there might be an OOM issue as you pointed out. Could you follow the recommendations listed below to help me further analyze what the root cause was?
Recommendations
V8Flags
V8Flags only can be set before any V8 runtime is created. Once V8Flags is set, the settings are applied to all V8 runtime created till the library is unloaded or JVM is closed.
V8 GC
The sample code seems to be fine to me. I wonder if you could insert one line of code.
    } finally {
       if (runtime != null) {
           logger.debug(logPrefix + "starting release ... ");
           runtime.lowMemoryNotification(); // Enforce a GC.
           runtime.close();
           runtime=null;
           logger.debug(logPrefix + "done release ... ");
    }

The major difference between J2V8 and Javet in this case is J2V8 enforces a GC per invocation whereas Javet doesn't. Javet believes applications shall get more flexibility in terms of balancing the performance and resource. In low pressure scenarios, skipping the GC gives better performance to the applications. However, that may cause issues similar to what happened in your high pressure case. So, enforcing the GC may help. Also, applications may call V8Flags.setExposeGC(true) to expose gc() in JavaScript so that the JavaScript code can decide when to call the gc().
Javet Engine Pool
Creating ad-hoc V8 runtimes gives much more pressure to both JVM and C++ runtime than Javet engine pool does especially when the applications are on the edge of exhausting the system resource. Javet engine pool caches the V8 runtime and can be configurated to perform GC in a daemon thread. As V8 is single-threaded, if applications explicitly call the GC, the GC blocks the application thread. In your case, that could be a considerable performance penalty. By using Javet engine pool, that performance penalty is gone and the applications usually don't need to call close() explicitly any more. Instead, the actual close() is called when Javet engine pool is being closed. Please refer to this doc for detail.
As you are using Spring, Spring finds the Javet engine pool implements AutoClosable and closes the Javet engine pool automatically when the Spring applications are exiting. Please refer to this doc for detail.
Java GC
I noticed ShenandoahGC was turned on. I suspect the parallel GC might be slightly incompatible with the way Javet works. Could you try some other GC algorithms to see if this issue can be reproduced? Also, could you try -Xlog:gc to analyze the GC log?
-XX:ConcGCThreads=2 -XX:ParallelGCThreads=2 -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC

Support Channel
I wonder in your application there might be more tricky things some of which might damage the memory model. The major reason could be Javet brings some new concepts / patterns compared to J2V8. I strongly encourage Javet users to read this How to Think in Javet? and refactor the code accordingly.
I've helped many application developers complete the migration from J2V8 to Javet. The efficient way I recommend is to turn to discord (for global developers) or WeChat (for Chinese developers). I look forward to seeing you at discord.

authors: caoccao robertlazarski


text:
ci: Add Java snippet checker

Similar to the CDS snippet syntax checker, add a Java version. It only checks for syntax errors using a Java parser written in JavaScript.  No code is compiled at any point.

Unrelated build failure:
Found 1 broken link(s) to internal targets in 1 source(s):
in: /about/features
Unresolved hash link: /advanced/odata #odata-v2-proxy-node

repo: cap-js/docs


text:
[IOS] [FirebaseAnalytics][I-ACS013000] Screen parameter value must be of type NSString: (nil)

Describe the bug
I faced with an issue related to
FirebaseAnalytics.setScreenName({
  screenName: 'The screen name',
});

What I see in logs

10.15.0 - [FirebaseAnalytics][I-ACS013000] Screen parameter value must be of type NSString: (nil)
10.15.0 - [FirebaseAnalytics][I-ACS031028] Received invalid class for screen: (nil)

To Reproduce
Steps to reproduce the behavior:

Run setScreenName method with some string value
You won't see an error in your app but you will see this error in Xcode logs. And, eventually you won't receive screen_view event.

Expected behavior
The library shouldn't have this error.
Screenshots

Smartphone (please complete the following information):

Device: iPhone 12 Pro
OS: 17.2.1

Additional context
Android handles this without any errors.
Also, I had a chance to debug this a little bit and maybe it will be useful:
I removed nameOverride to check if it can resolve the issue.

Same problem here. Tried to downgrade to this plugin in 4.0 and pod install and got the same result.
If someone can help us 🙏

authors: Sulorb edshkliaruk

repo: capacitor-community/firebase-analytics


text:
lock your Gem version for Capistrano v2 does not work!

In my project's gemfile I have set:
gem 'capistrano', '~> 2.15'

I also tried bundle install. My Gemfile.lock is:
GEM
  remote: http://rubygems.org/
  specs:
    capistrano (2.15.6)
      highline
      net-scp (>= 1.0.0)
      net-sftp (>= 2.0.0)
      net-ssh (>= 2.0.14)
      net-ssh-gateway (>= 1.1.0)
    highline (1.7.2)
    magentify (0.1.0)
      capistrano (~> 2, >= 2.5.10)
    net-scp (1.2.1)
      net-ssh (>= 2.6.5)
    net-sftp (2.1.2)
      net-ssh (>= 2.6.5)
    net-ssh (2.9.2)
    net-ssh-gateway (1.2.0)
      net-ssh (>= 2.6.5)

PLATFORMS
  ruby

DEPENDENCIES
  capistrano (~> 2.15.6)
  magentify

But it still tries to use v3.
cap
(Backtrace restricted to imported tasks)
cap aborted!
NoMethodError: undefined method `map' for :except:Symbol
/Users/ccarnell/Sites/xxx/Capfile:3:in `load'
/Users/ccarnell/Sites/xxxCapfile:3:in `<top (required)>'
(See full trace by running task with --trace)

cap -v
Capistrano Version: 3.4.0 (Rake Version: 10.2.2)

gem list
em list

*** LOCAL GEMS ***

addressable (2.3.6)
bigdecimal (1.2.0)
bundle (0.0.1)
bundler (1.6.0)
capifony (2.8.1)
capistrano (3.4.0, 2.15.6, 2.15.5)
capistrano-composer (0.0.6)
capistrano-ext (1.2.1)
capistrano-file-permissions (0.1.1)
capistrano-maintenance (0.0.3)
capistrano-rsync (1.0.2)
capistrano-scm-gitcopy (0.0.8)
capistrano-symfony (0.4.0)
capistrano-withrsync (0.1.2)
capistrano-wp (0.4.10)
capistrano_rsync_with_remote_cache (2.4.0)
CFPropertyList (2.2.8)
chunky_png (1.3.1)
colored (1.2)
colorize (0.7.7)
compass (0.12.6)
erubis (2.7.0)
fssm (0.2.10)
highline (1.7.2, 1.7.1, 1.6.21)
i18n (0.6.9)
inifile (3.0.0)
io-console (0.4.2)
json (1.7.7)
launchy (2.4.2)
libxml-ruby (2.6.0)
lunchy (0.7.0)
magentify (0.1.0, 0.0.7)
minitest (4.3.2)
net-scp (1.2.1, 1.1.2)
net-sftp (2.1.2)
net-ssh (2.9.2, 2.7.0)
net-ssh-gateway (1.2.0)
nokogiri (1.5.6)
psych (2.0.0)
puppet-lint (1.1.0)
railsless-deploy (1.1.3)
rake (10.2.2, 0.9.6)
rdoc (4.0.0)
ruby-progressbar (1.4.1)
sass (3.2.19)
sqlite3 (1.3.7)
sshkit (1.3.0)
term-ansicolor (1.3.0)
test-unit (2.0.0.0)
tins (1.0.1)

Hey @craigcarnell
I don't know anything about this, but top result on google for that error pointed me to this issue which points to a bug in Magentify up to version 0.7:
http://stackoverflow.com/questions/20754060/capistrano-undefined-method-map
Are you picking up an old version of Magnetify somehow?
Could you post the full stack trace that results from cap --trace?
Do you need to call bundle exec cap instead of just cap?

Whatever is going on is not a Capistrano bug. You didn't post your command line, but if you are not running bundle exec ________________  then you have no guarantees that your shell is finding the binaries as defined in your bundle!

authors: craigcarnell leehambley robd

repo: capistrano/capistrano


text:
Ruby 3.1: Can't run rubocop on capistrano repo

Steps to reproduce

Install Ruby 3.1.
In the capistrano repo, run bundle install.
Run bundle exec rubocop

Expected behavior
Rubocop should run successfully.
Actual behavior
$ ruby -v
ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20]
$ bundle exec rubocop
wrong number of arguments (given 5, expected 1)
ruby/3.1.0/psych.rb:323:in `safe_load'
ruby/gems/3.1.0/gems/rubocop-0.48.1/lib/rubocop/config_loader.rb:192:in `yaml_safe_load'
ruby/gems/3.1.0/gems/rubocop-0.48.1/lib/rubocop/config_loader.rb:175:in `load_yaml_configuration'

Seems like the solution is to upgrade to a more recent version of rubocop.


text:
when and how are the deployment collections created in the mongodb ?

I was experimenting with the jenkins plugin for deployment . But I checked the required collection classes where not present in the db and hence the data related to deployment was never saved. Will jenkins-plugin work for deployment collector without running a deployment collector before ?

Yes. Jenkins plug in for deployment will work - the api actually creates a collector in the background.

authors: raynaya tabladrum

repo: capitalone/Hygieia


text:
Document how to use with GCP

Would be great to have a docs section for how to get started with the Google Cloud Platform plugin similar to the Azure section of the docs.

agreed, we need a getting started with gcp section.

repo: capitalone/cloud-custodian


text:
recognize singlequote strings

not sure if the syntax is correct.
skip=+\\\\\|\\"+ this part you have on double quoted strings is quite confusing.
But  anyways, it would be nice to also recognize singlequoted strings as strings.

You're right.
Thanks for your contribution!

authors: afreakk cappyzawa


text:
Downgrade React Redux

Opening this to get a Netlify build to compare perf.

Seems to be about the same order of magnitude perf for the marquee step case.

repo: captbaritone/webamp


text:
chore(test): replace es6-weak-map with core-js

Changed
Usage of es6-weak-map (used for tests to support PhantomJS) with core-js/modules/es6.weak-map.
Testing / Reviewing
Testing should make sure no test is broken.

👍  LGTM

👍

authors: asudoh chrisdhanaraj hellobrian

repo: carbon-design-system/carbon-components


text:
fix(percy): fix for percy false positives

Related Ticket(s)
No related issue
Description
This is another attempt to fix the false positives in percy snapshots.
Changelog
Changed

Add cy.wait before every percy snapshot
Updated translation fixture to be the pre-transformed output

@kennylam @annawen1 @ariellalgilmore @emyarod @IgnacioBecerra this looks much more stable now, I think this is ready for review.


text:
[Module not found]: Compiling error when using DDSLightboxVideoPlayerContainer

Description
For our project, we use the DDSLightboxVideoPlayerContainer by importing it like so:
import DDSLightboxVideoPlayerContainer from '@carbon/ibmdotcom-web-components/es/components-react/lightbox-media-viewer/lightbox-video-player-container'

and we use it like so:
<DDSLightboxVideoPlayerContainer video-id={src} open={open} />

all works well when using @carbon/ibmdotcom-web-components": "^1.37.0
however, when we update to @carbon/ibmdotcom-web-components": "^2.0.0, we encounter this error:
Module not found: Can't resolve '../mixins/on'

https://nextjs.org/docs/messages/module-not-found

Import trace for requested module:
./node_modules/@carbon/ibmdotcom-web-components/lib/components-react-node/lightbox-media-viewer/lightbox-video-player-container.js
./components/LightboxMediaViewer/index.tsx
./app/(home)/HomeLeadSpace/index.tsx
 ○ Compiling /(home)/page ...
 ⨯ ./node_modules/@carbon/web-components/lib/globals/wrappers/createReactCustomElementType.js:12:0

any thoughts on what might be causing this issue?
Screenshot

Component(s) impacted
DDSLightboxVideoPlayerContainer / C4DLightboxVideoPlayerContainer
Browser
Chrome
Carbon for IBM.com version
2.0.0
Severity
Severity 1 = The design is broken in a critical way that blocks users from completing tasks or damages the brand. Affects major functionality, no workaround.
Application/website
ibm.com/quantum
Package
@carbon/ibmdotcom-web-components
CodeSandbox example
(the storybook is using 1.38)
Steps to reproduce the issue (if applicable)
No response
Release date (if applicable)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

Facing similar issue for Footer component:
unhandledRejection Error: Cannot find module '/Users/spandan.banerjee/Projects/DSTM/node_modules/@carbon/ibmdotcom-web-components/lib/components-react-node/footer/footer-container'     at createEsmNotFoundErr (node:internal/modules/cjs/loader:1171:15)     at finalizeEsmResolution (node:internal/modules/cjs/loader:1159:15)     at resolveExports (node:internal/modules/cjs/loader:584:14)     at Module._findPath (node:internal/modules/cjs/loader:658:31)     at Module._resolveFilename (node:internal/modules/cjs/loader:1120:27)     at /Users/spandan.banerjee/Projects/DSTM/node_modules/next/dist/server/require-hook.js:55:36     at Module._load (node:internal/modules/cjs/loader:975:27)     at Module.require (node:internal/modules/cjs/loader:1225:19)     at mod.require (/Users/spandan.banerjee/Projects/DSTM/node_modules/next/dist/server/require-hook.js:65:28)     at require (node:internal/modules/helpers:177:18) {   type: 'Error',   code: 'MODULE_NOT_FOUND',   path: '/Users/spandan.banerjee/Projects/DSTM/node_modules/@carbon/ibmdotcom-web-components/package.json' }

Facing similar issue for Footer component:
unhandledRejection Error: Cannot find module '/Users/spandan.banerjee/Projects/DSTM/node_modules/@carbon/ibmdotcom-web-components/lib/components-react-node/footer/footer-container'
    at createEsmNotFoundErr (node:internal/modules/cjs/loader:1171:15)
    at finalizeEsmResolution (node:internal/modules/cjs/loader:1159:15)
    at resolveExports (node:internal/modules/cjs/loader:584:14)
    at Module._findPath (node:internal/modules/cjs/loader:658:31)
    at Module._resolveFilename (node:internal/modules/cjs/loader:1120:27)
    at /Users/spandan.banerjee/Projects/DSTM/node_modules/next/dist/server/require-hook.js:55:36
    at Module._load (node:internal/modules/cjs/loader:975:27)
    at Module.require (node:internal/modules/cjs/loader:1225:19)
    at mod.require (/Users/spandan.banerjee/Projects/DSTM/node_modules/next/dist/server/require-hook.js:65:28)
    at require (node:internal/modules/helpers:177:18) {
  type: 'Error',
  code: 'MODULE_NOT_FOUND',
  path: '/Users/spandan.banerjee/Projects/DSTM/node_modules/@carbon/ibmdotcom-web-components/package.json'
}

also same problems when using c4d image

authors: bluephoeniiix sban2009 techtolentino


text:
[npm vulnerabilities]: dependency marked needs to be update

Description
There is a high npm vulnerability associated with the package marked: ^2.0.0.
https://github.com/carbon-design-system/carbon-for-ibm-dotcom/blob/0026aa45d9033f049902fbc790bdb33797a90bb7/packages/utilities/package.json#L56
npm requires marked version 4.0.10 or greater where in the vulnerability is patched.

Component(s) impacted
N/A
Browser
No response
Carbon for IBM.com version
1.11.0
Severity
Severity 4 = The problem is not visible to or noticeable to an average user. Affects minor functionality, no workaround needed.
Application/website
cloud.ibm.com/docs
Package
@carbon/ibmdotcom-web-components
CodeSandbox example
N/A
Steps to reproduce the issue (if applicable)
No response
Release date (if applicable)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

Hi @markkulube! We have a PR open for this https://github.com/carbon-design-system/carbon-for-ibm-dotcom/pull/8037

@ariellalgilmore thanks.
So closing this issue as resolution is in PR #8037

authors: ariellalgilmore markkulube


text:
feat(tutorial): complete step 3

Closes #
{{short description}}
Changelog
New

{{new thing}}

Changed

{{change thing}}

Removed

{{removed thing}}

Hi, I have updated my code. Please have a look again. Thanks!

And, how about we update the step 3 for our tutorial. It's just a suggestion. Because I found other students still make the mistake on this step.

repo: carbon-design-system/carbon-tutorial


text:
fix(connect): look at store in initialization

Related Ticket(s)
Refs #3589.
Description
This change ensures that <dds-footer-container>, etc. properties are populated from Redux store when the component is initialized, in addotion to reacting to changes in Redux store.
Lack of such mechanism caused empty footer data when a new instance of <dds-footer-container> is created after Redux store has already loaded all data from the service.
Changelog
New

"Store to component props" logic at component initialization in <dds-footer-container>, etc.

@asudoh fyi, I opened up PR https://github.com/carbon-design-system/ibm-dotcom-library/pull/3595 that has update snapshot files to fix the CI issues.

Superseded by: #3595

authors: asudoh jeffchew

repo: carbon-design-system/ibm-dotcom-library


text:
Datagrid tooltip component hover issue

Package
Carbon for IBM Products
Description

Create a Datagrid table
Add  tooltip component  next to the header name.
Expected : on hover of the tooltip , the tooltip description should show up
Current behavior : Tooltip hover doesn't show anything

https://github.com/user-attachments/assets/19b69d10-1bda-4086-abb8-77217e2484fe
Component(s) impacted
Datagrid
Browser
No response
@carbon/ibm-products (previously @carbon/ibm-cloud-cognitive) version
"@carbon/ibm-products": "2.40.0",
Suggested Severity
Severity 2 = Aspects of design is broken, and impedes users in a significant way, but there is a way to complete their tasks. Affects major functionality, has a workaround.
Product/offering
NA
CodeSandbox or Stackblitz example
https://codesandbox.io/p/sandbox/datagridfilter-forked-26hqww?file=%2Fsrc%2FExample.js%3A41%2C25
Steps to reproduce the issue (if applicable)
No response
Release date (if applicable)
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct
[X] I checked the current issues for duplicate issues

There is one more issue when we have a component rendered as a Header, when we try to resize there is no Ellipsis . Attached video below for reference
https://github.com/user-attachments/assets/e0eb2076-3660-4d1a-9713-1ec738331cf1

This tooltip hover works with autoAlign in Chrome but not on Safari browser

Hi @marinamas, can you try using the autoAlign prop now? We've made some dependency updates which have included @carbon/reacts support for this.

We've been investigating TanStack Table, a third-party, open-source offering, which provides extensive data table capabilities surpassing what our Carbon Datagrid offers. It provides much more flexibility and customization. TanStack Table is headless which means it can easily be added alongside Datagrid component in your product or application. The benefits of more flexibility for product teams and less maintenance for Carbon makes it a win win. Lastly, it is available in multiple frameworks including React and Web Component so it provides an option to non-React product teams.
For these reasons, we have decided to transition from building our own custom table component to using an example-based approach with TanStack Table. Datagrid will still exist in our library for existing teams but we are announcing the deprecation* of the Datagrid component in v2.54.0 release so teams can begin to work through the transition. Details about how to use both Datagrid and TanStack together can be found here.
*Deprecation means that no new features will be added however sev 1 and sev 2 bugs will be supported.

authors: ljcarot marinamas matthewgallo

repo: carbon-design-system/ibm-products


text:
Update Android SDK with latest source code

Guys,
First of all, thank you for your awesome API.
I realize that some EXTRAS is not available in the latest SDK (3.2.0), but it is available in the source code (https://github.com/card-io/card.io-Android-source).
Properties like EXTRA_HIDE_CARDIO_LOGO, EXTRA_SCAN_INSTRUCTIONS  etc.
Would you update the build with this new source code please?
Regards

We're going to update the official build with a 4.0 release, but we're doing some update work in sync with that. Once the package is ready, we'll release it.

Hi Tom
Here is my updated result:

"RESULT_SCAN_SUPPRESSED" is the result code passed to onActivityResult() method, not something we can pass to CardIOActivity. This means the "capture image only" mode is not available, you can only scan payment card.
Even we can set EXTRA_USE_CARDIO_LOGO param, this version can only switch between "card.io" logo and "Paypal" logo not hiding them.

Best Regards
Xiao Lu
On Jan 7, 2015, at 2:30 PM, Tom Whipple notifications@github.com wrote:

We're going to update the official build with a 4.0 release, but we're doing some update work in sync with that. Once the package is ready, we'll release it.
—
Reply to this email directly or view it on GitHub.

Thank you Tom,
We will wait. Do you have an estimate of a new release date?

Yeah, I'm interested in the release date too.

authors: andresmafra shawnlu123 tomwhipple


text:
I get it,thank you

General information

SDK/Library version:
iOS Version and Device:
Integration type and version:

Issue description

You might take a look at the code/fork and discussion at https://github.com/card-io/card.io-iOS-source/issues/88

authors: josharian xiesha


text:
🛑 mainnet - API is down

In 0a10a8f, mainnet - API (https://api.beta.explorer.cardano.org/api/v1/epochs) was down:

HTTP code: 200
Response time: 672 ms

Resolved: mainnet - API is back up in 66f6662 after 14 minutes.

repo: cardano-foundation/cf-explorer-status


text:
Non repeatable build / broken dependency propogation

I'm not sure exactly whats up here, but cargo2nix appears broken.
I've been building in CI, and running to successful completion. Getting hold of master and issuing nix-build pulls everything from the binary cache, which no build, as expected.
However:
echo " " >> ./crates/xrfdc/Cargo.toml
cargo clean
cargo generate-lockfile
cargo2nix -f
nix-build .

results in the error below. Cargo is presumably unhappy with the metadata within encoding_rs.
I haven't bottomed out the cause yet (otherwise there would be an accompanying PR).
The fact that this has built successfully indicates there is an ordering type bug at play here? Or that cargo is emitting metadeta which renders the build invalid
   Compiling async-graphql v2.8.2 (/build/async-graphql-2.8.2)
{
    "reason": "compiler-message",
    "package_id": "xrfdc 0.1.0 (path+file:///build/source)",
    "target": {
        "kind": [
            "lib"
        ],
        "crate_types": [
            "lib"
        ],
        "name": "xrfdc",
        "src_path": "/build/source/src/lib.rs",
        "edition": "2018",
        "doc": true,
        "doctest": true,
        "test": true
    },
    "message": {
        "rendered": "error[E0460]: found possibly newer version of crate `encoding_rs` which `async_graphql` depends on
 --> src/schema.rs:2:5
  |
2 | use async_graphql::*;
  |     ^^^^^^^^^^^^^
  |
  = note: perhaps that crate needs to be recompiled?
  = note: the following crate versions were found:
          crate `encoding_rs`: /nix/store/md0bfvsf39ch8vki443wsib7sc44vcjd-crate-encoding_rs-0.8.28/lib/libencoding_rs.rlib
          crate `async_graphql`: /nix/store/akgk0qdl4fzn32mhpg54zwjgxh7nzc9a-crate-async-graphql-2.8.1/lib/libasync_graphql.rlib

",
        "children": [
            {
                "children": [],
                "code": null,
                "level": "note",
                "message": "perhaps that crate needs to be recompiled?",
                "rendered": null,
                "spans": []
            },
            {
                "children": [],
                "code": null,
                "level": "note",
                "message": "the following crate versions were found:
crate `encoding_rs`: /nix/store/md0bfvsf39ch8vki443wsib7sc44vcjd-crate-encoding_rs-0.8.28/lib/libencoding_rs.rlib
crate `async_graphql`: /nix/store/akgk0qdl4fzn32mhpg54zwjgxh7nzc9a-crate-async-graphql-2.8.1/lib/libasync_graphql.rlib",
                "rendered": null,
                "spans": []
            }
        ],
        "code": {
            "code": "E0460",
            "explanation": null
        },
        "level": "error",
        "message": "found possibly newer version of crate `encoding_rs` which `async_graphql` depends on",
        "spans": [
            {
                "byte_end": 31,
                "byte_start": 18,
                "column_end": 18,
                "column_start": 5,
                "expansion": null,
                "file_name": "src/schema.rs",
                "is_primary": true,
                "label": null,
                "line_end": 2,
                "line_start": 2,
                "suggested_replacement": null,
                "suggestion_applicability": null,
                "text": [
                    {
                        "highlight_end": 18,
                        "highlight_start": 5,
                        "text": "use async_graphql::*;"
                    }
                ]
            }
        ]
    }
}
{
    "reason": "compiler-message",
    "package_id": "xrfdc 0.1.0 (path+file:///build/source)",
    "target": {
        "kind": [
            "lib"
        ],
        "crate_types": [
            "lib"
        ],
        "name": "xrfdc",
        "src_path": "/build/source/src/lib.rs",
        "edition": "2018",
        "doc": true,
        "doctest": true,
        "test": true
    },
    "message": {
        "rendered": "error: aborting due to previous error

",
        "children": [],
        "code": null,
        "level": "error",
        "message": "aborting due to previous error",
        "spans": []
    }
}
{
    "reason": "build-finished",
    "success": false
}

cargo generate-lockfile
cargo2nix -f

This step is expected to be non-reproducible as the package index will be consulted.  Still, the build should succeed if cargo can succeed (Definitely point out if this is not the case).
Among search results, this link seems pointing in the right direction:

It produces a crate with incompatible symbol names (a "different version"). There's a "strict version hash" derived by hashing a representation of the structure of a crate's entire external interface. That hash value is appended to every symbol name as part of the name mangling process.

A mechanism I could believe to be at work here is if Nix evaluation thinks a dependency doesn't need rebuild when it actually does.  The compiler catches our error due to the wrong interface hashes.  To simplify, we might be ignoring part of the input when writing the Nix expressions.  If this theory is correct, cleaning out the store paths should result in Nix not finding the (broken) cached rlib and being able to succeed.  Can you give this a shot?
You can find the paths that might need rebuilding using a similar workflow:
nix-store -q  --deriver /nix/store/32d9pc56axxrc2830q5cz1iwifjbar2m-crate-cargo2nix-0.9.0-bin
nix show-derivation /nix/store/ddwgw69slmx1ajdcyjrj2z53c4kfw3ml-crate-cargo2nix-0.9.0.drv | grep '/nix.*crate.*drv

  "/nix/store/ddwgw69slmx1ajdcyjrj2z53c4kfw3ml-crate-cargo2nix-0.9.0.drv": {
      "/nix/store/3inhij8bmn3qzpn1m18j2f48bvwlil2r-crate-anyhow-1.0.35.drv": [
      "/nix/store/3l1la0qrsgwyzx6nvpxlb8kz8l98jgi0-crate-semver-0.9.0.drv": [
      "/nix/store/9lid9ypd34zxyp697ajx92qwn9bkzshf-crate-tera-1.5.0.drv": [
      "/nix/store/ixv0163kk08nyjwjk22p2z990z4335wy-crate-cargo-0.48.0.drv": [
      "/nix/store/jjkvilw9283576lxysgkyrng2v5myf33-crate-tempfile-3.1.0.drv": [
      "/nix/store/js8lidv52qbdflgnjrqbv9hnhairsd66-crate-colorify-0.2.3.drv": [
      "/nix/store/l5l4anxvgpj6kxvp9h3g2dgi37glabql-crate-serde-1.0.118.drv": [
      "/nix/store/n08g1s2v3kgcir8z06f45hn2a32ybm0k-crate-toml-0.5.7.drv": [
      "/nix/store/qyivqx0j3g4gikbf7y9gn1wfan1xl0ds-crate-pathdiff-0.2.0.drv": [
      "/nix/store/vgdpa0vxdw1yh88xbgmbdvijhm2mdl95-crate-cargo-platform-0.1.1.drv": [

To confirm, the build does not succeed. I'll have a go with what you've suggested - thanks for the pointer. It'll be next week now before i get a chance.

Assuming cargo build works but nix build fails.  Please correct me if that's not the case.

Yes, cargo works fine, nix does not. I can simplify the failure case to:
git checkout master
# confirm build is as CI - everything is pulled from binary cache
nix-build .
# Invalidate build for 1 of the crates in workspace
echo " " >> ./crates/xrfdc/Cargo.toml
nix-build .

The resultant error message is then on a downstream crate:
 found possibly newer version of crate `cvt` which `xrfclk` depends on

so here, we have crate xrfdc and xrfclk which are both dependencies of a downstream binary crate. xrfdc builds correctly with the whitespace modified toml.
I can confirm that deleting all store paths, then rebuilding with nix-build . --option substitute false results in a successful build

Guessing that you've already implemented flushing the CI cache as a workaround for now.
Based on first example, there's strong evidence that the newly generated Cargo.nix did not react to the "modified" Cargo.toml.
Question is, how does the inconsequential change to the Cargo.toml result in rustc deciding that the rlib is no longer good...

Our workaround was nota subtle one - CI is ignoring all entries in the binary cache containing our crates. We warm it up by building hello-world with the cache for all cross-compilation targets, to avoid rebuilding the universe.
I'm equally baffled. I don't understand the internals of cargo sufficiently to know where to inspect the metadata.

My leading (only) candidate for this is a single binary crate, which shares a many of the dependencies of the failing ones. Its the only override aside from some fairly straightforward sys crates including build inputs on the libraries. We have
    my_bin = pkgs.rustBuilder.rustLib.makeOverride {
      name = "my_bin";
      overrideAttrs = drv: {
        # Rust flags were being ignored: this is a workaround.
        configureCargo = ''
          mkdir -p .cargo
          cargo_config=${./.cargo/config.toml}
          cp $cargo_config .cargo/$(stripHash $cargo_config)
        '';
      };
    };

This is being done to set linkage flags for static cross compilation. I'm unaware of any other way to inject these in cargo2nix - i'd love to been shown to be incorrect.
[target."aarch64-unknown-linux-musl"]
linker = "aarch64-unknown-linux-musl-ld"
rustflags = ["-C", "target-feature=+crt-static", "-C", "link-arg=-s"]

Building the dependencies for this target will have different flags than building those dependencies for other targets, which if encoded in metadata would cause what i'm seeing if those dependencies were reused. I don't have a great handle on what metadata cargo stores, but i'd believe link flags were amongst them.
Does this seem likely? If so what would be a better method for injecting these rust flags for this target and its deps?

We've come to hit this issue as well. We use crates2nix however.

@Fuuzetsu Is there a related issue in that project? Also, are you doing cross compilation?

@Fuuzetsu Is there a related issue in that project? Also, are you doing cross compilation?

No issue on cargo2nix that I know of.
w.r.t. reproduction, sadly it's a closed source project that has been working well up until recently when we hit this issue. We have a workspace with maybe like 20 crates (not at PC to check) and when we added one more, the new crate is having the problem. I found this ticket by Googling.
We are not doing cross compilation.

@Fuuzetsu Is there a related issue in that project? Also, are you doing cross compilation?

No issue on cargo2nix that I know of.
w.r.t. reproduction, sadly it's a closed source project that has been working well up until recently when we hit this issue. We have a workspace with maybe like 20 crates (not at PC to check) and when we added one more, the new crate is having the problem. I found this ticket by Googling.
We are not doing cross compilation.

Sorry, first line meant to say crate2nix, not cargo2nix

@Fuuzetsu Are you able to share how you invoke crate2nix?
My working assumption for this error is its something in the manner in which I'm setting the linkage flags not propagating correctly. However, that could be completely unrelated, and there is some more fundamental bug here.
The way this first manifested itself for us was very similar to what your describe - we've 15 or so crates in a workspace (closed source), and adding a new one caused this problem.

@Fuuzetsu Are you able to share how you invoke crate2nix?
My working assumption for this error is its something in the manner in which I'm setting the linkage flags not propagating correctly. However, that could be completely unrelated, and there is some more fundamental bug here.
The way this first manifested itself for us was very similar to what your describe - we've 15 or so crates in a workspace (closed source), and adding a new one caused this problem.

We're not doing anything strange with the crates I think: I am adding things like buildInputs to a bunch and setting some env vars to the others but once we get past that, it's fairly vanilla. I'm not messing with linking (except for a single crate where I use extraLinkFlags to deal with https://github.com/NixOS/nixpkgs/issues/119382).
I don't really think it's an issue with how we're invoking the builder nor with what you're doing. I initially was blaming non-determinism of rustc but it doesn't explain why changing the whitespace in the upstream crate makes it work sometimes... The issue happening when a crate is added is also very strange: they ought to be just separate derivations, I don't understand why they would be affecting each other.
Honestly I'm a bit lost as to how to deal with this. I was going to try and examine what's happening during the build in detail when I got some time but I haven't gotten to that point yet. If we have a way to replicate the issue then change some whitespace and have a working build, it should presumably be possible to examine what rustc is doing during the build and find the difference...

@Fuuzetsu Are you able to share how you invoke crate2nix?
My working assumption for this error is its something in the manner in which I'm setting the linkage flags not propagating correctly. However, that could be completely unrelated, and there is some more fundamental bug here.
The way this first manifested itself for us was very similar to what your describe - we've 15 or so crates in a workspace (closed source), and adding a new one caused this problem.

We're not doing anything strange with the crates I think: I am adding things like buildInputs to a bunch and setting some env vars to the others but once we get past that, it's fairly vanilla. I'm not messing with linking (except for a single crate where I use extraLinkFlags to deal with NixOS/nixpkgs#119382).
I don't really think it's an issue with how we're invoking the builder nor with what you're doing. I initially was blaming non-determinism of rustc but it doesn't explain why changing the whitespace in the upstream crate makes it work sometimes... The issue happening when a crate is added is also very strange: they ought to be just separate derivations, I don't understand why they would be affecting each other.
Honestly I'm a bit lost as to how to deal with this. I was going to try and examine what's happening during the build in detail when I got some time but I haven't gotten to that point yet. If we have a way to replicate the issue then change some whitespace and have a working build, it should presumably be possible to examine what rustc is doing during the build and find the difference...

Oh, I wanted to add something. One thing that's different on say my machine where build works vs coworker's machine where build failed vs CI where build failed is the codegen-units rustc parameter that basically comes from the environment. This parameter is very suspicious and I think easily can lead to different build results. This could explain why it builds on one machine but fails in CI. I have not yet tried tuning NIX_BUILD_CORES but I wonder if it'd work to set it to say 1 in CI or something.

I think you may have something with codegen-units. I hadn't considered this, but our errors started around the time we bumped our CI machines from 8 to 16 cores.
I'm not sure of the exact correlation, because the CI infrastructure was done out of band from our commit history. Perhaps codegen-units should be a build parameter in cargo2nix / crate2nix.

The docs suggest this is not the case though:

I'm not sure what you mean by this. The defaults aren't used in nix builds. See build-crate.nix and configure-crate.nix.

For now I'm going to send MR to nixpkgs to make codegen-units configurable. Will need changes in crates2nix and cargo2nix to make use of it of course but have to start somewhere.

The docs suggest this is not the case though:

I'm not sure what you mean by this. The defaults aren't used in nix builds. See build-crate.nix and configure-crate.nix.

Cargo2nix uses cargo to do the building

The docs suggest this is not the case though:

I'm not sure what you mean by this. The defaults aren't used in nix builds. See build-crate.nix and configure-crate.nix.

Cargo2nix uses cargo to do the building

Ah, I see. I still am not sure what you mean by "this is not the case" in this situation but as I understand, this means that probably cargo2nix is using the value of 16 as release builds are non-incremenal by default as of few rust versions ago (and nix builds aren't able to be incremental anyway so one would hope it's doing non-incremental settings anyway).
I guess the patch to nixpkgs doesn't matter for cargo2nix and for your usecase you should just either patch cargo2nix to set the flag explicitly or set it in Cargo.toml, assuming it gets honoured properly.

We started doing codegen-units=1 in our codebase recently in hopes that it'd fix the issue. Sadly, I just hit this again even with codegen-units=1 so it doesn't make the issue go away. I guess this needs some real debugging ;/

Need to look at the drv's between success & failure.  In the tree of dependencies, there's got to be some extra drv's that show up (along with old ones) or else the impurity is a non-determinism that's leaking in, meaning the intensional store winds up with multiple results at the same nix path.  It's a great help to spot the propagation of differences in the drvs

0.9.1 has fixed a behavior where trivial features were leaking down into dependencies.  This might actually help the behavior.

After reading more into Fuuzetsu's experience, it's pretty clear that this issue is with Rust, non-deterministic binary outputs.  In general, we can't protect from non-determinism.  I guess would could recommend an override workflow for the specific crate to always trigger rebuild.  A workaround is the right answer if there's unavoidable non-determinism in the Rust dependency or some rustc behavior.

Yes, rustc 1.55 seems OK and issues there lie with macro crates that produce non-deterministic output.
In rustc 1.56, there are issues with compiler (rather, LLVM) itself in general so I would wait for 1.57 where there are bunch of fixes.
There's a nix config flag that you can set to rebuild all packages multiple times and check hashes: this can help catch non-deterministic packages ahead of time, hopefully before they go into your binary caches etc. Another is to override your rust deps with preferLocalBuild or whatever it is.
For us, we are just on 1.55 for now.

so I would wait for 1.57 where there are bunch of fixes.

@Fuuzetsu   Did you see any fixes land as expected?

so I would wait for 1.57 where there are bunch of fixes.

@Fuuzetsu Did you see any fixes land as expected?

Yes, there were a bunch. We ran into another issue but it turned out to be a derive crate producing code from a macro in non-deterministic way. It's looking like we're going to be upgrading from 1.55 to 1.57, skipping the broken 1.56.
You can see some issues getting fixed in https://github.com/rust-lang/rust/issues/90301 – it's all LLVM stuff.

Then I think it's appropriate to handle this issue as errata, noting it in the common issues on the README but not attempting to hunt it down as a nix or cargo2nix issue.  With no objections, I'll include this note in my open PR and close this issue on merge.

Then I think it's appropriate to handle this issue as errata, noting it in the common issues on the README but not attempting to hunt it down as a nix or cargo2nix issue. With no objections, I'll include this note in my open PR and close this issue on merge.

Yes, there is nothing on the nix side that's broken or that one can do beyond something like "disable binary caches because binaries are randomly not compatible". Definitely nothing cargo2nix or crate2nix or anything can do (except somehing crazy like enabling preferLocalBuild or something).

authors: Fuuzetsu ollie-etl psionic-k


text:
Carla 0.9.15 additional map seem still be 0.9.14 link

in the tag 0.9.15 the additional map seems still be the old 0.9.14 link
https://carla-releases.s3.us-east-005.backblazeb2.com/Linux/AdditionalMaps_0.9.14.tar.gz

issue fixed

repo: carla-simulator/carla


text:
Failed to find XercesC (missing: XercesC_VERSION)

CARLA version: 0.9.13
Platform/OS: Ubuntu 20.04
Problem you have experienced: Failed to find XercesC (missing: XercesC_VERSION)
What you expected to happen: building PythonAPI
Steps to reproduce: make PythonAPI
Other information (documentation you consulted, workarounds you tried): i have Xerces 3.2.5 installed instead of 3.2.3 and changed Setup.sh and BuildOSM2ODR.bat accordingly.
Error message that i got:
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Failed to find XercesC (missing: XercesC_VERSION)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.16/Modules/FindXercesC.cmake:99 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:71 (find_package)
-- Configuring incomplete, errors occurred!
See also "/media/michal/7eeeb763-63f0-425a-88b3-041b93352d7a/carla/Build/libosm2dr-build/CMakeFiles/CMakeOutput.log".
make: *** [Util/BuildTools/Linux.mk:152: osm2odr] Error 1

Hi,
In your situation, I would try using Carla 0.9.15.2
There are many different bug fixes since version 0.9.13, and one of them is a changed download link.
If you can't change to Carla 0.9.15.2, I could look at the problem at a later time.

Hi, thanks for responding.
I can't use 0.9.15 version, as i need to use a ROS Bridge after that, and this is configured on 0.9.13 version. Unless there is a way of making it work on 0.9.15 that i am not aware of?

Hi,
open the following file
path/to/carla/Utils/BuildTools/Setup.sh
and search for this line
line 432
XERCESC_REPO=https://ftp.cixug.es/apache//xerces/c/3/sources/xerces-c-${XERCESC_VERSION}.tar.gz

and change it to
XERCESC_REPO=https://archive.apache.org/dist/xerces/c/3/sources/xerces-c-${XERCESC_VERSION}.tar.gz

The download link has changed, and I hope this is the only problem.

authors: PatrickPromitzer SirMichcik


text:
Agent support for all scenarios in one class

Currently, when trying to run all the scenarios of one class, manual_control.py needs to be run separately whenever a scenario in the class is prepared. Is there any existing methods to keep the agent wait for ego vehicle while the other scenarios are getting prepared? If no, can you please add this feature?
OS: [Windows 10]
CARLA Version [CARLA 0.9.10]
Python version [3.9.0]
Scenario_runner Version [0.9.10]

That's currently not supported as right now the manual control automatically shuts down when the ego is destroyed. In order to add your feature, some kind of reset should have to be implemented, but I don't think it is as easy as it sounds. I'm sorry but there are no plans to do so right now, but feel free to do so and do a PR :slightly_smiling_face:

That's currently not supported as right now the manual control automatically shuts down when the ego is destroyed. In order to add your feature, some kind of reset should have to be implemented, but I don't think it is as easy as it sounds. I'm sorry but there are no plans to do so right now, but feel free to do so and do a PR

@glopezdiest  Thank you for the response. Will do a PR for this and will also try this from my side.

authors: TeeManiac glopezdiest


text:
Disable drive activity LED by default

For compatibility with Pico W, disable use of Pico LED by default.
The W uses GPIO 25 for SPI communication to the CYW43439.  In the old days, the Pico default LED pin (PICO_DEFAULT_LED_PIN in pico-sdk\src\boards\include\boards\pico.h) was 25.
You can still enable the drive activity light by putting something like
    add_compile_definitions(USE_LED=1)

in CMakeLists.txt, for example.

Relevant to #15 and #74


text:
HitBTC error in live trading

As soon as backfilling completes after running the live trade command:
An error occurred { Error: hitbtc GET http://api.hitbtc.com/api/1/trading/balance?nonce=1508296556989&apikey=YOUR-API-KEY 401 Unauthorized {"error":{"code":1002,"message":"Authorisation failed","description":""}}
    at response.text.then.text (/app/node_modules/ccxt/ccxt.js:675:19)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7) constructor: [Function: AuthenticationError] }

 HitBTC API is down! unable to call getBalance, retrying in 10s

Also when backfilling before live trading it tries to backfill the data from all time, so 1391 days or so for BTC-USD.

You didn't enter your API key.
It's throwing a 401 (Unauthorized).
http://api.hitbtc.com/api/1/trading/balance?nonce=1508296556989&apikey=YOUR-API-KEY (From the error you're having. Note the YOUR-API-KEY)
You can change your API Key in conf.js
Also backfilling that 1000+ is normal.

My API is in there. @nedievas is submitting a PR to fix the problem. Also no it's not normal to backfill 1000+ days of data its completely unnecessary for live trading.


text:
Remove direct reference to OSRE vs GSoC

Realized that this link is supposed to also be on the GSoC application and think it would be confusing if it talked about OSRE and not GSoC. To simplify just referred to everything more generally ("summer contributors") and changed OSRE admin to Org admin.

I only wanted to change this one which is directly linked as part of the GSoC application. If accepted then we can revert this page back to make them consistent with the other pages.  Just trying not to confuse/muddle GSoC application.

repo: carlosmalt/ucsc-ospo


text:
TEST Fail || HELP

after training, i get this message when i try to test
(tf_gpu) S:\Pagmer\DCGAN\DCGAN-tensorflow-master\DCGAN-tensorflow-master>python main.py --dataset Doors --input_height=250 --crop
{'G_img_sum': <absl.flags._flag.BooleanFlag object at 0x000001A603246F98>,
'batch_size': <absl.flags._flag.Flag object at 0x000001A601E230F0>,
'beta1': <absl.flags._flag.Flag object at 0x000001A601EA23C8>,
'checkpoint_dir': <absl.flags._flag.Flag object at 0x000001A603246978>,
'ckpt_freq': <absl.flags._flag.Flag object at 0x000001A603246E10>,
'crop': <absl.flags._flag.BooleanFlag object at 0x000001A603246AC8>,
'data_dir': <absl.flags._flag.Flag object at 0x000001A6032467B8>,
'dataset': <absl.flags._flag.Flag object at 0x000001A6032466A0>,
'epoch': <absl.flags._flag.Flag object at 0x000001A67BFD8320>,
'export': <absl.flags._flag.BooleanFlag object at 0x000001A603246BA8>,
'freeze': <absl.flags._flag.BooleanFlag object at 0x000001A603246C18>,
'h': <tensorflow.python.platform.app._HelpFlag object at 0x000001A60324D048>,
'help': <tensorflow.python.platform.app._HelpFlag object at 0x000001A60324D048>,
'helpfull': <tensorflow.python.platform.app._HelpfullFlag object at 0x000001A60324D0B8>,
'helpshort': <tensorflow.python.platform.app._HelpshortFlag object at 0x000001A60324D128>,
'input_fname_pattern': <absl.flags._flag.Flag object at 0x000001A603246710>,
'input_height': <absl.flags._flag.Flag object at 0x000001A6021F9208>,
'input_width': <absl.flags._flag.Flag object at 0x000001A603246518>,
'learning_rate': <absl.flags._flag.Flag object at 0x000001A600727898>,
'max_to_keep': <absl.flags._flag.Flag object at 0x000001A603246CC0>,
'out_dir': <absl.flags._flag.Flag object at 0x000001A603246828>,
'out_name': <absl.flags._flag.Flag object at 0x000001A6032468D0>,
'output_height': <absl.flags._flag.Flag object at 0x000001A603246588>,
'output_width': <absl.flags._flag.Flag object at 0x000001A603246630>,
'sample_dir': <absl.flags._flag.Flag object at 0x000001A6032469E8>,
'sample_freq': <absl.flags._flag.Flag object at 0x000001A603246D68>,
'train': <absl.flags._flag.BooleanFlag object at 0x000001A603246A20>,
'train_size': <absl.flags._flag.Flag object at 0x000001A601EA2B00>,
'visualize': <absl.flags._flag.BooleanFlag object at 0x000001A603246B38>,
'z_dim': <absl.flags._flag.Flag object at 0x000001A603246EB8>,
'z_dist': <absl.flags._flag.Flag object at 0x000001A603246F60>}
2019-05-15 18:50:27.450608: I tensorflow/core/platform/cpu_feature_guard.cc:141] Your CPU supports instructions that this TensorFlow binary was not compiled to use: AVX AVX2
2019-05-15 18:50:27.609271: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1433] Found device 0 with properties:
name: GeForce GTX 1070 major: 6 minor: 1 memoryClockRate(GHz): 1.7465
pciBusID: 0000:01:00.0
totalMemory: 8.00GiB freeMemory: 6.64GiB
2019-05-15 18:50:27.614137: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1512] Adding visible gpu devices: 0
2019-05-15 18:50:28.136045: I tensorflow/core/common_runtime/gpu/gpu_device.cc:984] Device interconnect StreamExecutor with strength 1 edge matrix:
2019-05-15 18:50:28.140202: I tensorflow/core/common_runtime/gpu/gpu_device.cc:990]      0
2019-05-15 18:50:28.141478: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1003] 0:   N
2019-05-15 18:50:28.142812: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1115] Created TensorFlow device (/job:localhost/replica:0/task:0/device:GPU:0 with 6389 MB memory) -> physical GPU (device: 0, name: GeForce GTX 1070, pci bus id: 0000:01:00.0, compute capability: 6.1)
WARNING:tensorflow:From C:\ProgramData\Anaconda3\envs\tf_gpu\lib\site-packages\tensorflow\python\framework\op_def_library.py:263: colocate_with (from tensorflow.python.framework.ops) is deprecated and will be removed in a future version.
Instructions for updating:
Colocations handled automatically by placer.
Variables: name (type shape) [size]
generator/g_h0_lin/Matrix:0 (float32_ref 100x524288) [52428800, bytes: 209715200]
generator/g_h0_lin/bias:0 (float32_ref 524288) [524288, bytes: 2097152]
generator/g_bn0/beta:0 (float32_ref 512) [512, bytes: 2048]
generator/g_bn0/gamma:0 (float32_ref 512) [512, bytes: 2048]
generator/g_h1/w:0 (float32_ref 5x5x256x512) [3276800, bytes: 13107200]
generator/g_h1/biases:0 (float32_ref 256) [256, bytes: 1024]
generator/g_bn1/beta:0 (float32_ref 256) [256, bytes: 1024]
generator/g_bn1/gamma:0 (float32_ref 256) [256, bytes: 1024]
generator/g_h2/w:0 (float32_ref 5x5x128x256) [819200, bytes: 3276800]
generator/g_h2/biases:0 (float32_ref 128) [128, bytes: 512]
generator/g_bn2/beta:0 (float32_ref 128) [128, bytes: 512]
generator/g_bn2/gamma:0 (float32_ref 128) [128, bytes: 512]
generator/g_h3/w:0 (float32_ref 5x5x64x128) [204800, bytes: 819200]
generator/g_h3/biases:0 (float32_ref 64) [64, bytes: 256]
generator/g_bn3/beta:0 (float32_ref 64) [64, bytes: 256]
generator/g_bn3/gamma:0 (float32_ref 64) [64, bytes: 256]
generator/g_h4/w:0 (float32_ref 5x5x3x64) [4800, bytes: 19200]
generator/g_h4/biases:0 (float32_ref 3) [3, bytes: 12]
discriminator/d_h0_conv/w:0 (float32_ref 5x5x3x64) [4800, bytes: 19200]
discriminator/d_h0_conv/biases:0 (float32_ref 64) [64, bytes: 256]
discriminator/d_h1_conv/w:0 (float32_ref 5x5x64x128) [204800, bytes: 819200]
discriminator/d_h1_conv/biases:0 (float32_ref 128) [128, bytes: 512]
discriminator/d_bn1/beta:0 (float32_ref 128) [128, bytes: 512]
discriminator/d_bn1/gamma:0 (float32_ref 128) [128, bytes: 512]
discriminator/d_h2_conv/w:0 (float32_ref 5x5x128x256) [819200, bytes: 3276800]
discriminator/d_h2_conv/biases:0 (float32_ref 256) [256, bytes: 1024]
discriminator/d_bn2/beta:0 (float32_ref 256) [256, bytes: 1024]
discriminator/d_bn2/gamma:0 (float32_ref 256) [256, bytes: 1024]
discriminator/d_h3_conv/w:0 (float32_ref 5x5x256x512) [3276800, bytes: 13107200]
discriminator/d_h3_conv/biases:0 (float32_ref 512) [512, bytes: 2048]
discriminator/d_bn3/beta:0 (float32_ref 512) [512, bytes: 2048]
discriminator/d_bn3/gamma:0 (float32_ref 512) [512, bytes: 2048]
discriminator/d_h4_lin/Matrix:0 (float32_ref 524288x1) [524288, bytes: 2097152]
discriminator/d_h4_lin/bias:0 (float32_ref 1) [1, bytes: 4]
Total size of variables: 62093700
Total bytes of variables: 248374800
[] Reading checkpoints... ./out\20190515.185027 - data - Doors\checkpoint
[] Failed to find a checkpoint
Traceback (most recent call last):
File "main.py", line 147, in
tf.app.run()
File "C:\ProgramData\Anaconda3\envs\tf_gpu\lib\site-packages\tensorflow\python\platform\app.py", line 125, in run
_sys.exit(main(argv))
File "main.py", line 124, in main
raise Exception("Checkpoint not found in " + FLAGS.checkpoint_dir)
Exception: Checkpoint not found in ./out\20190515.185027 - data - Doors\checkpoint
anyone knows whats up?

Hi. I also faced exact same problem.. Can any one suggest on this how to resolve.
Thanks in advance.

By default, the checkpoint is saved every 200 epochs. If you train during less epochs, no checkpoint will be saved and you won't be able to test your generator.
You can control the checkpoint frequency with --ckpt_freq and the number of iterations with --epoch.
Hope it helps!

Thanks for the answer!
is there a possibility to get different test results? I'm getting only the same one

@Shnoogy I am facing the same issue. The generated images are always almost the same with minor change like pixel intensity. I have a small dataset of only 40 images, it may be the cause (overfitting?) but I'm not sure. Do you have a small dataset too ? I tried to change the option of visualize() to 0 but it didn't resolve the issue. (#204)

Hi..
I am still not able to test .. I trained with 300 epochs then  too i
got : exception:
Checkpoint not found in ./out/20190712.103742 - data - face/checkpoint
what to do now .. please help me.
command to test was: python main.py --input_height 96 --input_width 96
--output_height 96 --output_width 96 --dataset face --crop  --epoch 300
--input_fname_pattern ".jpg*"
command to train was : python main.py --input_height 96 --input_width 96
--output_height 96 --output_width 96 --dataset face --crop  --train --epoch
300 --input_fname_pattern ".jpg*"
On Thu, Jun 20, 2019 at 2:36 PM Guillaume Fradet notifications@github.com
wrote:

@Shnoogy https://github.com/Shnoogy I am facing the same issue. The
generated images are always almost the same with minor change like pixel
intensity. I have a small dataset of only 40 images, it may be the cause
(overfitting?) but I'm not sure. Do you have a small dataset too ? I tried
to change the option of visualize() to 0 but it didn't resolve the issue.
(#204 https://github.com/carpedm20/DCGAN-tensorflow/issues/204)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/carpedm20/DCGAN-tensorflow/issues/339?email_source=notifications&email_token=AFLNCW2GLZDKWVWKLRNZKPLP3NCBFA5CNFSM4HNE24X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYEZL2I#issuecomment-503944681,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFLNCW2APYXJDVX5EF2GY6LP3NCBFANCNFSM4HNE24XQ
.

--
With Best Wishes and Regards
Anishi Gupta

Did anyone get the solution? I tried training with 250 epochs but still getting the same error.

No I tried with 300 epochs still not working.
On Mon, 22 Jul 2019, 13:38 matak07, notifications@github.com wrote:

Did anyone get the solution? I tried training with 250 epochs but still
getting the same error.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/carpedm20/DCGAN-tensorflow/issues/339?email_source=notifications&email_token=AFLNCW7KNUKBY5W5PYP3ZWLQAVTHPA5CNFSM4HNE24X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2PD3RQ#issuecomment-513686982,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFLNCWZ5D2A2RE4GV5NZE5DQAVTHPANCNFSM4HNE24XQ
.

What I did was "hardcoded" the saved checkpoint file into line 122 of main.py file and set visualization to True, and now I can generate test images

Its throwing syntax error, when I am hardcoding it.
This is my location of check point. what should I write inside dcgan.load()
/root/Desktop/DCGAN-tensorflow-master/out/20190712.163251 - data - face -
x96.z100.uniform_signed.y96.b6
On Sat, Jul 27, 2019 at 11:24 AM Muhammad057 notifications@github.com
wrote:

What I did was "hardcoded" the saved checkpoint file into line 122 of
main.py file and set visualization to True, and now I can generate test
images
[image: 1]
https://user-images.githubusercontent.com/40855134/61990593-c92a8e80-b05c-11e9-8ffd-166322c1c1f3.PNG
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/carpedm20/DCGAN-tensorflow/issues/339?email_source=notifications&email_token=AFLNCW6ZNMNRGDKHTRFLNV3QBPPIDA5CNFSM4HNE24X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD26EL7A#issuecomment-515655164,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFLNCWY26AUK76AS4FP6R2DQBPPIDANCNFSM4HNE24XQ
.

--
With Best Wishes and Regards
Anishi Gupta

I write inside dcgan.load()
/root/Desktop/DCGAN-tensorflow-master/out/20190712.163251 - data - face - x96.z100.uniform_signed.y96.b6

Add \checkpoint after - x96.z100.uniform_signed.y96.b6, example
/root/Desktop/DCGAN-tensorflow-master/out/20190712.163251 - data - face - x96.z100.uniform_signed.y96.b6/checkpoint
The checkpoint file shall point out to the last checkpoint which is saved after every "x" number of iterations.

Hi
I did this, still fail to test.
The error screenshot is attached in this email.
plus when I am running command to test, other black check points folder are
created.
Please help me with this.
On Thu, Aug 1, 2019 at 3:15 AM Muhammad057 notifications@github.com wrote:

I write inside dcgan.load()
/root/Desktop/DCGAN-tensorflow-master/out/20190712.163251 - data - face -
x96.z100.uniform_signed.y96.b6
Add \checkpoint after - x96.z100.uniform_signed.y96.b6, example
/root/Desktop/DCGAN-tensorflow-master/out/20190712.163251 - data - face -
x96.z100.uniform_signed.y96.b6/checkpoint
The checkpoint file shall point out to the last checkpoint which is saved
after every "x" number of iterations.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/carpedm20/DCGAN-tensorflow/issues/339?email_source=notifications&email_token=AFLNCW6HCCZXD65FGFG3GCLQCKERVA5CNFSM4HNE24X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3JSGRA#issuecomment-517153604,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFLNCW4XEE6MUWWQXPA4BETQCKERVANCNFSM4HNE24XQ
.

--
With Best Wishes and Regards
Anishi Gupta

Hi
I think error lies in mismatch between current graph and the graph.
File "/root/Desktop/DCGAN-tensorflow-master/model.py", line 547, in
load    self.saver.restore(self.sess, os.path.join(checkpoint_dir,
ckpt_name))  File
"/root/anaconda2/envs/venv/lib/python2.7/site-packages/tensorflow/python/training/saver.py",
line 1322, in restore
err, "a mismatch between the current graph and the
graph")tensorflow.python.framework.errors_impl.InvalidArgumentError:
Restoring from checkpoint failed. This is most likely due to a mismatch
between the current graph and the graph from the checkpoint. Please ensure
that you have not altered the graph expected based on the checkpoint.
Original error:Assign requires shapes of both tensors to match. lhs shape=
[100,8192] rhs shape= [100,18432]     [[node save/Assign_38 (defined at
/root/Desktop/DCGAN-tensorflow-master/model.py:161) ]]Errors may have
originated from an input operation.Input Source operations connected to
node save/Assign_38: generator/g_h0_lin/Matrix (defined at
/root/Desktop/DCGAN-tensorflow-master/ops.py:99)
Is there any problem with input size or something?
On Thu, Aug 1, 2019 at 3:30 PM anishi gupta anishi.anishi@gmail.com wrote:

Hi
I did this, still fail to test.
The error screenshot is attached in this email.
plus when I am running command to test, other black check points folder
are created.
Please help me with this.
On Thu, Aug 1, 2019 at 3:15 AM Muhammad057 notifications@github.com
wrote:

I write inside dcgan.load()
/root/Desktop/DCGAN-tensorflow-master/out/20190712.163251 - data - face -
x96.z100.uniform_signed.y96.b6
Add \checkpoint after - x96.z100.uniform_signed.y96.b6, example
/root/Desktop/DCGAN-tensorflow-master/out/20190712.163251 - data - face -
x96.z100.uniform_signed.y96.b6/checkpoint
The checkpoint file shall point out to the last checkpoint which is saved
after every "x" number of iterations.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/carpedm20/DCGAN-tensorflow/issues/339?email_source=notifications&email_token=AFLNCW6HCCZXD65FGFG3GCLQCKERVA5CNFSM4HNE24X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3JSGRA#issuecomment-517153604,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFLNCW4XEE6MUWWQXPA4BETQCKERVANCNFSM4HNE24XQ
.

--
With Best Wishes and Regards
Anishi Gupta

--
With Best Wishes and Regards
Anishi Gupta

send me the screenshot

Hi attached the screenshot pluse send over gmail too

Hi
Please find attached. Screenshot.
On Thu, Aug 1, 2019 at 4:00 PM Muhammad057 notifications@github.com wrote:

send me the screenshot
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/carpedm20/DCGAN-tensorflow/issues/339?email_source=notifications&email_token=AFLNCW3HKDU5TOVIFLKU2T3QCK3MLA5CNFSM4HNE24X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3KEAHI#issuecomment-517226525,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFLNCW2FZ5VO4B5N3L3TBTTQCK3MLANCNFSM4HNE24XQ
.

--
With Best Wishes and Regards
Anishi Gupta

Moreover I am using tensorflow version 1.14.0.. i dont think it will be a problem.

please check the size of train and test images

Its near about 100 images for training. I have used no folder for test iamges

Minimum how many images should i keep for training, epochs I kept = 300. Is there any need of test images folder. I thing it will be generated automatically.

Dimension of images are already given in command terminal.
I dont know where damn problem is.
Please help me.

Hi
I am using 100 images for training with 300 epochs. Still fails to test
On Thu, 1 Aug 2019, 16:54 Muhammad057, notifications@github.com wrote:

please check the size of train and test images
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/carpedm20/DCGAN-tensorflow/issues/339?email_source=notifications&email_token=AFLNCW6WN7TCJT5J6U6RBQLQCLBWHA5CNFSM4HNE24X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3KH3XA#issuecomment-517242332,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFLNCW7ESW2LHI33OODOXKDQCLBWHANCNFSM4HNE24XQ
.

I found that the problems happened in main.py. Specifically with these lines:
FLAGS.out_dir = os.path.join(FLAGS.out_dir, FLAGS.out_name)
FLAGS.checkpoint_dir = os.path.join(FLAGS.out_dir, FLAGS.checkpoint_dir)
FLAGS.sample_dir = os.path.join(FLAGS.out_dir, FLAGS.sample_dir)
Notice how the first os.path.join concatenates a directory and a folder name, while the latter two concatenate two directories. On MacOS, I was getting two directories jammed together into one long directory that didn't exist.
I commented out these lines and added my own string manipulation to get it working, but its messy. I doubt others are using a Mac, so my recommendation is, add some printouts of FLAGS.checkpoint_dir and FLAGS.sample_dir before the checkpoint check in the code. See if what you're getting is actually the directory you want.

Hi I am using 100 images for training with 300 epochs. Still fails to test
…
On Thu, 1 Aug 2019, 16:54 Muhammad057, @.***> wrote: please check the size of train and test images — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#339?email_source=notifications&email_token=AFLNCW6WN7TCJT5J6U6RBQLQCLBWHA5CNFSM4HNE24X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3KH3XA#issuecomment-517242332>, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLNCW7ESW2LHI33OODOXKDQCLBWHANCNFSM4HNE24XQ .

I met similar problems as you. Have you got the solution?
Thanks


text:
No good documentation

I am unable to use this as there is no documentation and the issue talking about it being in the code is just as unhelpful.

The code itself is pretty self explanatory. Just have a look at send, getThreadInfo, getUnread and listen.
Don't be lazy.

When I run listen() it just stays there, it prints the data to the screen but doesn't actually advance my code to do anything with said data.

It doesn't seem to me you have any experience in coding (python, at least). Study up a bit on classes and overriding them

Yes I do. I have several years, you just have no documentation.

authors: PidgeyL nicolas-martin pingpong1109


text:
Training Status should be "Failed" rather than "Ask to Repeat"

This follows up on #1808
While training status for the three checkout steps (DC/LC/SWC Homework, Demo, and Discussion) should be Asked to Repeat rather than Failed we do want the Training to be Failed rather than Asked to Repeat.
I think this would require an update such as
SELECT *
FROM workshops_trainingprogress
WHERE requirement_id = 1
  AND state = 'a';

UPDATE workshops_trainingprogress
SET state = 'f'
WHERE requirement_id = 1
  AND state = 'a';

@maneesha I'm not 100% clear on what is required by this ticket. Do you want me to run 1-off query and change values in production database?

Yes, this reflects a change to data, not a change to code.

Done. I'll upload the first query results to you on Slack.

authors: maneesha pbanaszkiewicz

repo: carpentries/amy


text:
IDs trocados

A4
R DA SOCIEDADE 95 010087 e 010088
Estas duas paragens tem na realidade os ids trocados

Paragem Sul R DA SOCIEDADE 95 com o id 010087 no GTFS

Paragem Norte R DA SOCIEDADE 95 com o id 010088 no GTFS

Mais quatro com IDs trocados
Estr Lagoa da Cheia Agropecuária 010049 e 010050
Estr Lagoa da Cheia 610010051 e 010052
É mais pratico trocar diretamente no GTFS sendo preciso tambem trocar os sentidos das linhas que servem

Olá @DiogoBaptista98, acredito que este erro já esteja corrigido. Se não estiver peço por favor que o Issue seja re-aberto. Obrigado!

repo: carrismetropolitana/gtfs


text:
🛑 Back Office is down

In f3e500f, Back Office (https://bo.cartelmatic.com/) was down:

HTTP code: 503
Response time: 630 ms

Resolved: Back Office is back up in 0f22c2d after 19 minutes.

repo: cartelmatic/upptime


text:
Problems with 3D local SLAM

Hi, I am having problems with the 3D local SLAM tuning. I am using 2x VLP-16 and a Microstrain 3dm-gx5-45. The main issue that I have is that the local trajectory slightly oscillates, as you can see in the picture below. My configuration is the following:
options = {
map_builder = MAP_BUILDER,
trajectory_builder = TRAJECTORY_BUILDER,
map_frame = "map",
tracking_frame = "microstrain_imu_link",
published_frame = "base_link",
odom_frame = "odom",
provide_odom_frame = true,
publish_frame_projected_to_2d = false,
use_odometry = false,
use_nav_sat = false,
use_landmarks = false,
num_laser_scans = 0,
num_multi_echo_laser_scans = 0,
num_subdivisions_per_laser_scan = 1,
num_point_clouds = 2,
lookup_transform_timeout_sec = 0.2,
submap_publish_period_sec = 0.3,
pose_publish_period_sec = 5e-3,
trajectory_publish_period_sec = 30e-3,
rangefinder_sampling_ratio = 1.,
odometry_sampling_ratio = 1.,
fixed_frame_pose_sampling_ratio = 1.,
imu_sampling_ratio = 1.,
landmarks_sampling_ratio = 1.,
}
--TRAJECTORY BUILDER PARAMS
--Providing full 360 scans with two lidars (and per-point stamp)
TRAJECTORY_BUILDER_3D.num_accumulated_range_data = 6
--Setting up a voxel filter to reduce the density of the data
VOXEL_SIZE = 0.05
TRAJECTORY_BUILDER_3D.voxel_filter_size = VOXEL_SIZE
MAP_BUILDER.use_trajectory_builder_3d = true
MAP_BUILDER.num_background_threads = 12
POSE_GRAPH.optimization_problem.huber_scale = 5e2
POSE_GRAPH.optimize_every_n_nodes = 200
POSE_GRAPH.constraint_builder.sampling_ratio = 0.03
POSE_GRAPH.optimization_problem.ceres_solver_options.max_num_iterations = 20
POSE_GRAPH.constraint_builder.min_score = 0.62
POSE_GRAPH.constraint_builder.global_localization_min_score = 0.66
Changing the num_accumulated_range_data from 2 to 6 helped reduce the oscillation, but it is still present. Thanks for your help!

Sounds like a tuning question - if you are using the ROS velodyne driver have you tried setting npackets to 1? That would provide ~75 packets per rotation to Cartographer, so you would need to increase TRAJECTORY_BUILDER_3D.num_accumulated_range_data appropriately, the original authors had it set to 160 for two velodynes.

I am working offline with recorded data and I can't test this right now, I will try this as soon as I can. However, I fail to understand how should this produce a different effect to the mapping, since it should be equivalent to providing full 360º scans with per-point timestamp, right?
Thanks for your help!

authors: halops tyhowell

repo: cartographer-project/cartographer


text:
Incorrect scan matching during a robot rotation

My lua-option is defined like following:
map_frame = "map",
tracking_frame = "base_link",
published_frame = "base_link",
odom_frame = "odom",
provide_odom_frame = false,
publish_frame_projected_to_2d = false,
use_pose_extrapolator = true,
use_odometry = false,

Currently, I just plug my RPlidar A2 to my PC and testing the map, wihtout odometry/IMU sensor. If I rotate the lidar scanner, I can see that the topic /scan_matched_points2 is somehow drifted and distorts the map generation. Please see the picture below ( red is the laser scanner, green is the scan_matched_point2:

If I see the demo from the Deutsches Museum bagfile, I don't see such a drift. What did I do wrong? Since the Laser frame is the same as the robot frame (base_link). Is it because I don't have odometry sensor? If I change the lua setting to odom_frame = "base_link", I see the same result.
Thanks!

tuning is tricky and maybe you find a way to improve it if you play around long enough.
However, rotations are extremely hard to handle (for almost any SLAM) without odometry info or an IMU.  Adding either of these will help you deal with this much easier.

tuning is tricky and maybe you find a way to improve it if you play around long enough.
However, rotations are extremely hard to handle (for almost any SLAM) without odometry info or an IMU. Adding either of these will help you deal with this much easier.

Thank @johuber for the hint. I'll get an IMU sensor then.

authors: johuber ywiyogo


text:
kctrl: Allow users to watch for changes while using dev

kctrl dev could have a flag that asks it to watch the resources it is deploying for changes (maybe --watch).
kctrl would perform a dev reconciliation whenever it detects changes.

Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.

@100mik the proposed feature would be really useful! Could we reopen the issue?

repo: carvel-dev/kapp-controller


text:
fix :set default tab or last used tab

fix the default tab display
new feature of default opening the last used tab

Replaced by: https://github.com/casbin/casbin-forum/pull/96

authors: hsluoyz noneback

repo: casbin/casbin-forum


text:
docs: Add false collapsed parameter.

Signed-off-by: ErikQQY 2283984853@qq.com

@hsluoyz Plz review

repo: casdoor/casdoor-website


text:
Casdoor as SAML SP with keycloak login not work

Hi! I try to use Casdoor as SAML SP  with keycloak different version and casdoor can't login.
In Keycloak 12.0.4 (version of our test environment)

Create realm

Configure client connection

Download metadata files in moq auth format

Create new provider in casdoor

Try to login

In Keycloack 21.1.1 (latest version running in docker with start-dev parameter)

create realm

Configure client connection

Copy metadata SP from realm settings
Create new provider in casdoor

Try to login

I also tried to change the client ID from  full path to relative /api/acs, but that didn't help

@leo220yuyaodog

@yamaritta please try keycloack v6.0.1. High version is unavailable.

authors: hsluoyz leo220yuyaodog yamaritta

repo: casdoor/casdoor


text:
Electrum protocol support

ord could gain even more traction if it could use the Electrum protocol instead of bitcoin RPC.

Unless I'm mistaken, I don't think the electrum protocol is suitable for this type of application. ord needs to process all transactions of all blocks to index sats. Electrum is mostly used for fast lookups of address balances and transactions, and is very slow at serving blocks (if it serves them at all, I think most servers will only serve headers).

Thanks for the issue! @brandonblack Can you clarify what you're looking for? Is the desire some kind of light client? Or the ability to use public servers to download block data?

Sorry, I'm just getting up to speed on ord here, and I think what I'm getting toward is alluded to in this comment on the overall redb sync performance: https://github.com/casey/ord/issues/1377#issuecomment-1418005263
In short, I think we have < 10 years until fragmentation in the sat space makes fully indexing all ordinal sat ranges out of the reach of most users, so we should probably plan for that future now. To do so, we'd want to produce a lighter weight ord which has probably 2 modes:

When directly connected to a full -txindex bitcoin node, it indexes all inscriptions to date (along with potentially some other rare stats of interest).
When connected to an Electrum server, it only supports queries for specific sats or UTXOs, eg. "make sure I'm not sending something rare by sending this transaction", and "inscribe this sat and tell me what it's number was, then index it for future".

Sorry, I'm just getting up to speed on ord here, and I think what I'm getting toward is alluded to in this comment on the overall redb sync performance: #1377 (comment)
In short, I think we have < 10 years until fragmentation in the sat space makes fully indexing all ordinal sat ranges out of the reach of most users, so we should probably plan for that future now. To do so, we'd want to produce a lighter weight ord which has probably 2 modes:
1. When directly connected to a full `-txindex` bitcoin node, it indexes all inscriptions to date (along with potentially some other rare stats of interest).

2. When connected to an Electrum server, it only supports queries for specific sats or UTXOs, eg. "make sure I'm not sending something rare by sending this transaction", and "inscribe this sat and tell me what it's number was, then index it for future".

This issue seems somewhat related to issue https://github.com/casey/ord/issues/1501 since both suggest a need for additional code modularization (which I think would be required to support point 2 above).
Additionally, this privacy-focused project might be of interest if Electrum is used: https://github.com/chris-belcher/electrum-personal-server

I'm not keen on introducing a dependency on the electrum protocol, or re-implementing it ourself. I think this is really about "make syncing fast" and "create new security trade-offs", and I think those things can be supported without introducing a dependency on electrum. Users already have a hard time getting bitcoind running and connecting to bitcoind, and getting ord running correctly. I don't want to add functionality where getting things running requires configuring an additional service, or which requires complex configuration, so you need Docker or something like it to get started.

In short, I think we have < 10 years until fragmentation in the sat space makes fully indexing all ordinal sat ranges out of the reach of most users, so we should probably plan for that future now.

Years away is a long time! We definitely have bigger fish to fry, like making the current sync model fast.
I'm going to convert this to a discussion so that conversation can continue!

authors: andrewtoth brandonblack casey tyjvazum

repo: casey/ord


text:
Expansion of CONTRIBUTING

Still requires documentation for Translation/Localization efforts and a PR template.

I'll convert to Draft since it's not ready for review yet

Absolutely should be a draft, I have no knowledge of any translation/localization being worked on currently and would love an assist if you know who is doing so (assuming it is being done).
I have a PR template (based on GitHub template) that I typically use, can be seen on #1669. If this is acceptable as a starting point I will include it in documentation for now.

Localization and PR templates were put in backlog. Documentation ready, but a proof-read or grammatical review would be appreciated.

authors: Psifour raphjaph