write mp4  to stream

I have a strange isssue when converting a file to an mp4 stream and sending it out via express.
The following code works with vlc but if I try to add it to a <video> element in a browser the encoding starts but after a few seconds the browser closes the stream.
Idon*t now if these is an issue of fluent-ffmeg or express but thanks for any hints
This is the output:

file starting
Processing: 4.4418372838431095% done
Processing: 8.214935198486385% done
Processing: 12.22033205190434% done
an error happened: Output stream closed
ffmpeg stdout: undefined
ffmpeg stderr: undefined

This is the code
app.get('/video/:filename', function(req, res) {
    var pathToMovie = jsonobj[req.params.filename];
   res.writeHead(206, { "Content-Type":"video/mp4"});
   console.log("encoding movie",pathToMovie );
   var outStream  = fs.createWriteStream(__dirname + '/player/moviestream.mp4');
    var readstream = 0;
    var proc = ffmpeg(pathToMovie)
        .audioCodec('aac')
        .videoCodec('libx264')
        .addOption('-strict', 'experimental')
        .addOption('-movflags', 'faststart')
        .toFormat('flv')
        .size('640x480').autopad()
        // setup event handlers
        .on('end', function() {
            console.log('file has been converted succesfully');
        })
        .on('progress', function(progress) {
            console.log('Processing: ' + progress.percent + '% done');
        })
        .on('error', function(err,stdout,stderr) {
            console.log('an error happened: ' + err.message);
            console.log('ffmpeg stdout: ' + stdout);
            console.log('ffmpeg stderr: ' + stderr);
        })
        .on('start', function() {
            console.log('file starting');
        });
    var ffstream = proc.pipe(res);

});```

I think the problem is in the way browsers do requests.
Can you log the requests done by the browser when trying to play the video ?

I think the problem of the server part ist solved by this gist:
https://gist.github.com/lleo/8614403
ok so far
but what is a bit strange to me:
none of your samples for piping a mp4 to a write stream seem to work for me:
code from the docs
fmpeg(__dirname +'/player/movie.mp4')
    .videoCodec('libx264')
    .audioCodec('libmp3lame')
    .size('320x240')
    .on('error', function(err,stdout,stderr) {
        console.log('an error happened: ' + err.message);
        console.log('ffmpeg stdout: ' + stdout);
        console.log('ffmpeg stderr: ' + stderr);
    })
    .on('end', function() {
        console.log('Processing finished !');
    })
    .on('progress', function(progress) {
        console.log('Processing: ' + progress.percent + '% done');
    })
    .pipe(outStream, { end: true });

produces:

an error happened: ffmpeg exited with code 1: pipe:1: Invalid argument
Unable to find a suitable output format for 'pipe:1'

if i add a format:
fmpeg(__dirname +'/player/movie.mp4')
    .videoCodec('libx264')
    .audioCodec('libmp3lame')
    .size('320x240')
    .format('mp4')
    .on('error', function(err,stdout,stderr) {
        console.log('an error happened: ' + err.message);
        console.log('ffmpeg stdout: ' + stdout);
        console.log('ffmpeg stderr: ' + stderr);
    })
    .on('end', function() {
        console.log('Processing finished !');
    })
    .on('progress', function(progress) {
        console.log('Processing: ' + progress.percent + '% done');
    })
    .pipe(outStream, { end: true });

produces:

an error happened: ffmpeg exited with code 1: Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
[mp4 @ 0x7fae138d3a00] muxer does not support non seekable output

Yeah, unfortunately that example is flawed. As you pointed out a format specification is missing. But you may not use mp4 when outputting to a stream, as mp4 requires a seekable output (it needs to go back after having written the video file to write the file header).

Oh yeah that was obvious!
Thanks for the answers, I will close the issue

Can I ask real quick if I understand this right; Streaming as mp4 is impossible because it needs to set file / stream headers (I assume something like the length of the video) before the stream starts? If so, is there any way to generate a stream that can be read by the native <video> element and not via flash?


Use BONSAI for the execution engine BesuNode in ATs

Affects tests extending AbstractJsonRpcTest
relates to #5721

@siladu closing this one in favour of #6619


Cache the results of machete-status-branch hook based ALSO on the hook contents

See com.virtuslab.gitmachete.backend.impl.hooks.StatusBranchHookExecutor#hookOutputByBranchNameAndCommitHash for the current caching rules... I'd add hook content as well to be extra-protected against stale cache issues

Note that the values of com.virtuslab.gitmachete.backend.impl.hooks.StatusBranchHookExecutor#hookOutputByBranchNameAndCommitHash are hook outputs (the stdouts from execution), not hook contents (bytes of the hook script itself). What I propose in this issue to add hook content to the key. Values are to remain unchanged.

Is the desired behaviour to not cache the None hook content, so as to rerun the hook in a subsequent enquiry, for obtaining Some(value)?

I'd leave the logic in com.virtuslab.gitmachete.backend.impl.hooks.StatusBranchHookExecutor#deriveHookOutputFor as is. None value suggests that the hook execution failed for the given input, and is hence not to be rerun.

One more thing, as the hook contents might theoretically be quite large, it might be better to use a hash (like MD5 or whatever) instead the full contents.

Got it: you mean the hashed content of the hookFile itself


Disable error hover  message

Is it possible to disable the error popup that shows beneath the cursor (1 line down) whenever I type something that is not valid like a partial function name?
I would like to either disable this altogether or have it only show when I hover over the error text. In general, having the error shown in the footer like it does now is sufficient.

Sorry, this is a duplicate of https://github.com/TypeStrong/atom-typescript/issues/129


Refactor ooVQE

What is the expected enhancement?
The ooVQE did not make it into the last release because it needs to undergo a major refactoring to fit into the framework of Qiskit Nature. The most up-to-date (but WIP) version of ooVQE can be found here
I am replicating a (non-exhaustive) TODO list from that file below:

[ ] removal of molecular_problem from __init__ (this will only be given to solver())
[ ] actual use of MolecularProblem.second_q_ops() rather than hard-coded build_fermionic_op
[ ] unification with BaseProblem.solve()
[ ] general refactorings of flow
[ ] fix freeze-core support based on FreezeCoreTransformer
[ ] fix dependence on num_parameters handling within Terra's VQE and Optimizer

I think that this could be a good first issue for me, but it might take more than one sprint with my current bandwidth. Would you like me to work on it?

@ElePT that would be great. I will split in multiple issues and assign them to you. Thank you very much!

Changing this issue into an epic for better tracking, as it will be divided in 2.


History saved incorrectly in multiline mode

shell history when working in multiline mode is broken - each line is saved separately instead of waiting for the semicolon.
Additionally, single line items are saved twice - once with the trailing semicolon and once without.

Resolved in v0.10.2


Implement fifth theme - Inventory Management System

Description
Develop the fifth theme "Inventory management system" as the designs.
References: https://www.figma.com/file/rX1jl4pa04VD9itnzneeih/Webiu?node-id=1%3A5
Changes proposed in the pull request

Implement full Inventory management system
Add README to the theme
Implement functionalities

Screenshots (In case of UI changes):

Types of changes

[x] New feature (non-breaking change which adds functionality)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests have passed and it does not give any unexpected error for the same.

Steps to test

cd themes/inventory-management-system
yarn
yarn develop

Resolves: https://github.com/scorelab/Webiu/issues/373

@dinithminura can you review the PR please :)


file names and directories

Please move ustream and ulog files to the directory src, and change the file name of all related files to add the prefix az_ulib.

https://github.com/Azure/azure-ulib-c/pull/44

Fixed with #44


feat: RP for plugin-tee-verifiable-log

Relates to:

Run verifiable Eliza in the TEE.
Verifiable log for Eliza in the TEE

Add a verifiable log plugin to enable Eliza to sign verifiable logs and provide an interactive query interface. So external parties can query the verifiable logs and verify Eliza's execution process through signature validation.
Risks
Low
Background
What does this PR do?
Eliza running in a TEE (Trusted Execution Environment) is verifiable, ensuring that the AI agent operates strictly according to the code.
However, further development is needed for external parties to verify what Eliza specifically did: external parties should be able to access Eliza's operation logs, and Eliza must use a key pair derived from the TEE to sign these logs. This enables the logs to be verified as authentically originating from Eliza within the TEE.

For example, in the case of an Eliza AI agent running a Twitter client, it could be verified which tweets were posted by Eliza and which were directly posted by a human manually operating the Twitter account.
Future: Based on this plugin, other clients and plugins can generate verifiable logs that need to be authenticated externally. We can further develop a verifiable terminal for TEE Eliza to display signed, verifiable logs in real-time.
What kind of change is this?

Feature
TEE plugin
Verifiable feature

Documentation changes needed?
Yes, we will add documentation for using this plugin, including the guide on how other plugins can import it and generate verifiable logs.
Testing
Where should a reviewer start?

Understand the existing plugin-tee

We rely on Eliza's existing plugin-tee and use its key derivation interface.

Understand what plugin-tee-verifiable-log does

Derive a key pair for verifiable logs: It uses the TEE to derive a key pair specifically for signing verifiable logs.
Remote attestation: The public key of verifiable logs is embedded in the remote attestation report, making it accessible for external verification.
Sign logs: This plugin accepts logs passed in from external modules (e.g., tweets sent and received by a Twitter client, or executed actions), signs them with the TEE-derived key pair, and stores them in the database.
Verification: External entities can use the remotely attested public key to verify these logs, ensuring that certain actions were indeed performed by TEE Eliza.

What is not included in this PR

Adding RPC interfaces for the direct client: For example, support for remote attestation and querying the public key for verifiable logs. This feature will be submitted in a separate PR that depends on plugin-tee-verifiable-log and modifies the direct client.
Support for plugin-tee-verifiable-log in existing clients: Enhancements for existing clients to generate verifiable logs that need external validation. For instance, modifying the Twitter client to depend on plugin-tee-verifiable-log and produce logs that are worthy of external verification.

Detailed testing steps
It have completed the integration tests and can run the pnpm test file in the test directory.

@odilitime  @shakkernerd Could you please help resolve the code conflicts? I’ve already submitted the code several times, but I noticed that the conflicts and the file changes display different content, and I’m not sure how to handle it.

Hi @gene-zhan alright, I will look into it.

@shakkernerd Thank you. By the way, is there anything else I need to update or adjust in this pull request to get it merged?


Added french FAQ

I've incorporated a French FAQ and provided detailed explanations for arguments and commands to run the program without the web interface. Additionally, I initiated a pull request on HuggingFace to update the myinfer.py file, which I've revised to include all arguments and accommodate new models. I've also proactively detailed the new arguments in a dedicated section of the README. If necessary, I can provide an English translation.
Here is the faq : https://github.com/SECRET-GUEST/Retrieval-based-Voice-Conversion-WebUI/blob/main/docs/fr/faq_fr.md

You're welcome ^^ I'll keep an eye on the doc updates and will be tweaking the French section along the way.


fix(CrosshairsTool.js): Fixed mousedown callback name

Crosshairs would not work on click or mousedown because the callback name had been misspelled.
fix #1375
The tool makes use of the preMouseDownCallback but in the original implementation the method name was mistakenly written without the prefix "pre"
https://github.com/cornerstonejs/cornerstoneTools/blob/94b728359171d9cd9ffa17d1fa9d167ee5d9f6f1/src/tools/base/BaseTool.js#L254

:tada: This PR is included in version 5.1.5 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


File uploaded resources of type application/zip not working

Create a new ressource
when creating the resource on the "Representation" page upload a zip file and set file type to application/zip
Finish creating the resource
Download resource from another connector
-> Opening the downloaded zip file fails. It is not recognized as a zip file

I have tested the functionality to upload zip files with a python script that puts the file in the DSC. It worked fine.
I believe this is a problem in the DSC-UI @SebastianOpriel, probably the encoding on file upload.

Persisting a ZIP file the DSC UI produces a corrupt ZIP file. The file that is returned on request is bigger than the original file, which means they can't be possibly equal. I believe 1) some zip file headers are maybe persisted as well instead of only the file or 2) the file is persisted in a different encoding.
This leads to the ZIP file being corrupt when dowloading it.
I've been experimenting with different results and managed to write a method where the content length doesnt change on output, but didnt reach a solution where the zip file is not corrupt.
There is also the possibility that the frontend is encoding the files before sending it to the DSC.
A possible consideration could be to create a separate endpoint for zip file handling. Part of the problem is that the DSC handles all input files the same (all use the same REST endpoint).  It might make it easier to handle ZIP files differently than normal files. Storing the whole file content in one database entry also doesnt seem to be the best practice. I'll keep looking for alternatives.

It could be due to the UI, there the method readAsBinaryString() is used [1], which doesn't seem to work with binary data [2], the same happens in my tests for example also with a PNG file.
[1] https://github.com/International-Data-Spaces-Association/DataspaceConnectorUI/blob/a723eb0109283a219f5b273d25c30a1ee7cf4793/src/pages/dataoffering/resources/addresource/representation/ResourceRepresentationPage.js#L129
[2] https://stackoverflow.com/a/17512132


Allow adminAuth to auto-login users when using passport strategy

Adds an option to adminAuth when using a strategy type scheme to automatically redirect the user to the required auth system rather than prompt with a dialog to click a button first.
The dialog will still get shown if there are any errors whilst handling the login.
adminAuth: {
    type: 'strategy',
    strategy: {
        ...
        autoLogin: true,
        ...
    }
}

Coverage decreased (-0.04%) to 68.722% when pulling b8435efc97f2e1ecc43d30d11277d1518841e5c9 on auto-login into cb88409102e9ecf4ff7521579f1b77cf0cbf8774 on dev.


Beamdyn use

Hi, I am a new student to Beamdyn and I have some questions about with Beamdyn module. Can I use the new version of the code directly? And I guess if I open it in VS2017 it should require some configuration or settings? So where can I find a clear and intuitive tutorial to use it please. Thank you.

Dear @chenyw-299,
I'm not sure what you mean be "new version", but when using BeamDyn, I would recommend using OpenFAST v3.5.3 (https://github.com/OpenFAST/openfast/releases/tag/v3.5.3) or newer.
The much faster version of BeamDyn, made faster through the use of the new tight coupling implementation in the OpenFAST glue code, will be available in the upcoming release of OpenFAST v5.0.  You can track the progress here: https://github.com/OpenFAST/openfast/pull/2439.
Best regards,

Dear @jjonkman,
Do you have an updated schedule for v5.0? Since it was mentioned that v5.0 would be released in this fall as I recall.
Kind regards

Dear @jjonkman  Thank you for your answer. I will download OpenFAST v3.5.3.

Dear @yangpy88,
The release of OpenFAST v4.0 is expected very soon, which will be followed shortly by the release of OpenFAST v5.0, hopefully within the next month.
Best regards,

Dear @jjonkman ,
That sounds really good! Thank you. BTW, is the paper of the tight coupling algorithm available online?
Kind regards,

Dear @yangpy88,
While we have drafted this paper, we are awaiting the final results from our tight coupling implementation before we submit it to the Wind Energy Science journal–hopefully that is within the next month.
Best regards,


Logging system setup

From el-proyecte-grande-sprint-1-java-szplkflrn created by IPHUN1989: CodecoolGlobal/el-proyecte-grande-sprint-1-java-szplkflrn#1
Logging system implementation to the project by using Logback.

Adding options for logging:
Error, Info, Debugging and other levels are available.
To use it, instantiate a Logger with the same method you can see on the picture.


Concurrent use of portals and simple queries invalidates portals

To reproduce:
//from CursorTest.scala
  sessionTest("invalidation") { s =>
    cursor(s).use { c =>
      for {
        _ <- c.fetch(1)
        _ <- s.execute(sql"select 1;".query(int4))
        _ <- c.fetch(1)
      } yield ()
    }
  }

This will fail with exception Problem: Portal "portal_2" does not exist.
From what is seen on tcpdump and wireshark, Portal get invalidated implicitly and server takes it as a given and not sends any message for its invalidation.
expected behavior:
This is hard to say, as it is exactly what postgres do which is inconvenient IMO, but this is issue can be mitigated by warnings on document, method docs etc.

By the way you can add debug = true to your Session configuration and you'll get a transcript of all the messages that go between client and server. No need for Wireshark, etc.

related document which specifies this behavior:
https://www.postgresql.org/docs/10/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY

If successfully created, a named portal object lasts till the end of the current transaction, unless explicitly destroyed.

No need for Wireshark, etc.
I was trying to capture server communication itself to see if other clients behaviors are different, but it turns out to be fruitless :smile:

I suspect Im hitting this or a related problem.

When I do them serially with traverse it works. When I try in parallel with parTraverseN(8), I get postgres errors like Portal "portal_35" does not exist.

I would need to see some code I guess, but it sounds like you need to operate inside a transaction if you want to have multiple active portals.

Thanks for the pointer, issue solved :)
I added a session pool and ran each of my parallel insert jobs in a separate session & transaction. Stable and very fast! 🏎

Don't the Postgres docs indicate the prepared statement should be good for the life of the connection?

Prepared statements only last for the duration of the current database session. When the session ends, the prepared statement is forgotten, so it must be recreated before being used again. This also means that a single prepared statement cannot be used by multiple simultaneous database clients; however, each client can create their own prepared statement to use. Prepared statements can be manually cleaned up using the DEALLOCATE command.

I don't know.  Reading through their docs I don't get a clear session of whether session = tx or session = connection.

I still get this randomly even inside explicit transactions.  I'm not doing anything parallel as far as I can tell.  Will try to experiment with debug to see if I can reproduce.

I don't know. Reading through their docs I don't get a clear session of whether session = tx or session = connection.

@matthughes  From what I remember, the word session in pg docs is used broadly, and in this case, the term refers to a live transaction.
If the transaction is terminated (for whatever reason it be), the session is also closed and all of the prepared statements are destroyed, while the connection is still alive and functional.
This seems to be an implicit protocol behavior, as there are no messages transferred between the client and server in this scenario.

I still get this randomly even inside explicit transactions. I'm not doing anything parallel as far as I can tell. Will try to experiment with debug to see if I can reproduce.

It's probably an implicit failure in the transactions. e.g. a merging two streams together.

Here's an example log showcasing the failure.  I have a service that obtains a session, opens a transaction and does a session.prepare call.  I hit this service in parallel to exhibit the behavior:
 → Query(BEGIN)
 ← CommandComplete(Begin)
 ← ReadyForQuery(Active)
 → Query(select txid_current(), pg_backend_pid())
 ← RowDescription(Field(txid_current, 20); Field(pg_backend_pid, 23))
 ← RowDate()
 ← CommandComplete(Select(1))
 ← ReadyForQuery(Active)
 → Bind(portal_1275,statement_29,List(Some(73bc60f8-3cce-4080-8958-d064ca93651e)))
 → Flush
 ← BindComplete
 → Execute(portal_1275,2147483647)
 → Flush
 ← RowDate()
 ← CommandComplete(Select(1))
 → Sync
 ← ReadyForQuery(Active)
 → Close(P,portal_1275)
 → Flush
 ← CloseComplete
 → Query(COMMIT)
 ← CommandComplete(Commit)
 ← ReadyForQuery(Idle)
 → Query(UNLISTEN *)
 ← CommandComplete(Unlisten)
 ← ReadyForQuery(Idle)
 → Query(RESET ALL)
 ← CommandComplete(Reset)
 ← ReadyForQuery(Idle)
 → Bind(portal_1276,statement_31,List(Some(SomeParam)))
 → Flush
 ← BindComplete
 → Execute(portal_1276,2147483647)
 → Flush
 ← RowDate()
 ← CommandComplete(Select(1))
 → Sync
 ← ReadyForQuery(Idle)
 → Close(P,portal_1276)
 → Flush
 ← CloseComplete
 → Bind(portal_1277,statement_21,List(Some(SomeParam)))
 → Flush
 ← BindComplete
 → Query(BEGIN)
 ← CommandComplete(Begin)
 ← ReadyForQuery(Active)
 → Execute(portal_1277,2147483647)
 → Flush
 ← RowDate()
 ← CommandComplete(Select(1))
 → Sync
 ← ReadyForQuery(Active)
 → Query(select txid_current(), pg_backend_pid())
 ← RowDescription(Field(txid_current, 20); Field(pg_backend_pid, 23))
 ← RowDate()
 ← CommandComplete(Select(1))
 ← ReadyForQuery(Active)
 → Close(P,portal_1277)
 → Flush
 ← CloseComplete
 → Bind(portal_1278,statement_29,List(Some(73bc60f8-3cce-4080-8958-d064ca93651e)))
 → Flush
 ← BindComplete
 → Bind(portal_1279,statement_52,List(Some(SomeParam), Some(73bc60f8-3cce-4080-8958-d064ca93651e)))
 → Flush
 ← BindComplete
 → Execute(portal_1278,2147483647)
 → Flush
 ← RowDate()
 ← CommandComplete(Select(1))
 → Sync
 ← ReadyForQuery(Active)
 → Execute(portal_1279,2147483647)
 → Flush
 ← RowDate()
 ← CommandComplete(Select(1))
 → Sync
 ← ReadyForQuery(Active)
 → Close(P,portal_1278)
 → Flush
 ← CloseComplete
 → Close(P,portal_1279)
 → Flush
 ← CloseComplete
 → Query(COMMIT)
 ← CommandComplete(Commit)
 ← ReadyForQuery(Idle)
 → Bind(portal_1280,statement_40,List(Some(SomeParam), Some(73bc60f8-3cce-4080-8958-d064ca93651e)))
 → Flush
 ← BindComplete
 → Query(UNLISTEN *)
 ← CommandComplete(Unlisten)
 ← ReadyForQuery(Idle)
 → Execute(portal_1280,2147483647)
 → Flush
 ← ErrorResponse(F -> postgres.c, M -> portal "portal_1280" does not exist, V -> ERROR, L -> 2074, C -> 34000, R -> exec_execute_message, S -> ERROR
 → Sync
 ← ReadyForQuery(Idle)
 → Query(RESET ALL)
 ← CommandComplete(Reset)
 ← ReadyForQuery(Idle)
 → Close(P,portal_1280)
 → Flush
 ← CloseComplete
 → Bind(portal_1281,statement_31,List(Some(SomeParam)))
 → Flush
 ← BindComplete
 → Execute(portal_1281,2147483647)

This UNLISTEN right after the BindComplete looks wrong but it's hard to know since this (I believe) is messages from two different connections being interspersed.  Is there a relatively easy way to add some sort of connection identifier to the debug log?
Or can we somehow use MessageSocket.history in an error message so we can replay the last N failed logs before a failure?

Note that turning commandCache = 0 makes this problem go away.

Ok I finally found what was causing the issue in my code and was able to reproduce in Skunk PR.
https://github.com/typelevel/skunk/pull/904
Seems calling .flatMap(identity) or .flatten "outside" of session/tx resource acquisition causes this problem.  I don't know if that's a bug in Skunk or a bug in CE or just a bug in my understanding.

Hi, we have hit the same problem.
we have something like this
Stream(getStuffFromDb1, getStuffFromDb2 ).parJoin(1)
  .through(KafkaProducer.pipe(producerSettings, kafkaProducer))
  .evalTap(_ => commitOffsets(Chunk(record)))
  .flatMap(r => Stream.chunk(r.records.map(_._1.value)))

getStuffFromDb1 and getStuffFromDb2  goes to db and streams some data from here and there:
does something like:
for {
        session <- Stream.resource(database.makeSession)
        r <- getStuffFromDb(session)(id)
      } yield r

when using parJoinUnbounded we had the same portal_X closed.
using .parJoin(1) "fixed" the problem, but obviously not ideal
so did  using queryCache = 0

another example:
    val pool: Resource[IO, Resource[IO, skunk.Session[IO]]] = ... make the pool resource ...

    pool.use { p =>
      p.use { sesh =>
        Range(0, 10, 1)
          .toList
          .parTraverse { i =>

            val cmd = sql"""INSERT INTO wonk values($int4)"""
              .command

            sesh
              .prepare(cmd)
              .flatMap(_.execute(i))
              .void
          }
      }
    }

running this results in:
ReadyForQuery(Idle)
 → Execute(portal_20,0)
 → Flush
 ← ErrorResponse(F -> postgres.c, M -> portal "portal_20" does not exist, V -> ERROR, L -> 2074, C -> 34000, R -> exec_execute_message, S -> ERROR


训练bge-m3和bce-embedding-base_v1报错

使用train_embedding.sh训练上述两个模型报错：
Traceback (most recent call last):
File "train_embedding.py", line 182, in
main()
File "train_embedding.py", line 109, in main
model = accelerator.prepare(model)
File "/home/nlp/miniconda3/envs/rag-retrieval/lib/python3.8/site-packages/accelerate/accelerator.py", line 1292, in prepare
result = tuple(
File "/home/nlp/miniconda3/envs/rag-retrieval/lib/python3.8/site-packages/accelerate/accelerator.py", line 1293, in
self._prepare_one(obj, first_pass=True, device_placement=d) for obj, d in zip(args, device_placement)
File "/home/nlp/miniconda3/envs/rag-retrieval/lib/python3.8/site-packages/accelerate/accelerator.py", line 1169, in _prepare_one
return self.prepare_model(obj, device_placement=device_placement)
File "/home/nlp/miniconda3/envs/rag-retrieval/lib/python3.8/site-packages/accelerate/accelerator.py", line 1443, in prepare_model
self.state.fsdp_plugin.set_auto_wrap_policy(model)
File "/home/nlp/miniconda3/envs/rag-retrieval/lib/python3.8/site-packages/accelerate/utils/dataclasses.py", line 1182, in set_auto_wrap_policy
raise Exception("Could not find the transformer layer class to wrap in the model.")
Exception: Could not find the transformer layer class to wrap in the model.

参考：https://github.com/NLPJCL/RAG-Retrieval/issues/5

谢谢，解决了！


Fix api-reference pages

Fix the issues left in #11870. This PR uses css to overwrite the style of the api-reference pages, so we can remove the code that alter style in _tools/.
see the effects here:
http://caesarxuchao.github.io/v1.0/
@thockin @RichieEscarez  @nikhiljindal @lavalamp

This whole thing is a total mess, but at least it appears consistent now.
LGTM

Is this just a temporary fix until we have a better process for the API reference docs?
To fix this for the long term, I dont think the API specific files (any of the new or changed _layout files) are necessary. With the changes that you are delivering here, you are overriding all the wrong CSS embedded in the API .html files, but instead, we need to delete it all and provide valid k8s.io specific CSS for these API files.
I think the long term solution would be to extract all the necessary CSS thats used to generate the tables in the API .html files, modify the CSS so that its k8s.io specific, move the modified CSS into the new _sass/_api_reference.scss file, modify the api_reference.scss file so that it targets the id or class "api-reference", and then rename the id or class in a div within the API .html files to apply the API CSS (for example, rename id=contents (at current line 364 in the definitions.html file) to "api-reference" ("article" is too general)).

@RichieEscarez, thank you! This is intended to be a permanent fix. I try to avoid modifying the API html files, because the way we modify the html files in _tools/release_docs/api-reference-process.go using html package is brittle. Why are you against overriding? I think that's a cleaner approach and solve the problem once for all.
Regarding this comment: "(rename id=contents (at current line 364 in the definitions.html file) to "api-reference" ("article" is too general))", these fields are generated by the tool that we use to generate the html files from swagger-spec. I don't have a clean way to automatically modify them. I think it's better to adapt _api_reference.scss to these html files, rather than the other way around.

@caesarxuchao thanks for clarifying. Ive commented on a few things that might simplify this. Can you try to see if that works because if this is how we will maintain these files long term, id prefer to avoid maintaining javascript across several files.
If my proposed changes dont work, one alternative would be to move all the javascript into separates "_includes" files so that they get pulled in from one location?

Thank you @RichieEscarez , I'll try to use the "sect1" class and will let you know!

Hi @RichieEscarez, the PR uses "sect1" class now, it looks much cleaner. Thank you!
I was worrying about "sect1" to be a too general tag so I didn't want to override this class, but it seems to work just fine. PTAL.

Thanks @caesarxuchao, i made one more nitpick comment but otherwise LGTM

This should go in soon.  Someone commented on the fonts today.

@RichieEscarez, can I get a LGTM? Thank you.

Hey, we just had a user bug report:
https://twitter.com/JayRWren/status/626847520312922112
Related to a CSS property: *zoom which should be zoom can we fix that here too.
Thanks!

In both files i see *zoom: 1, so both operations.html and definitions.html should be updated.

Let me try if a CSS override can fix this. Otherwise I'll just fix it using golang.

Added an ugly search & replace in _tools/release_docs/api-reference-process.go to remove * from * zoom. PTAL. Thank you.

This all feels very brittle and a little bit like we're just guessing.
Does this actually seem to fix the refresh loop?

Unfortunately, yes. This fix is necessary. I reproduced Brendan's bug and Safari was reloading the page because of this.
We still need to fix cse though, which also causes Safari to reload forever. That's a separate issue/

Then let's get this change in.  I still have a hunch we';re going to pay
for it later ;)
On Thu, Jul 30, 2015 at 11:03 PM, Chao Xu<EMAIL_ADDRESS>wrote:

Unfortunately, yes. This fix is necessary. I reproduced Brendan's bug and
Safari was reloading the page because of this.
We still need to fix cse though, which also causes Safari to reload
forever. That's a separate issue/
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11913#issuecomment-126577431
.

Im looking into the console error that CSE causes in chrome, it might have something to do with whats happening in Safari too.

Fwiw, I fixed the error at caesarxuchao.github.io, but the nab bar is still
reloading.
On Friday, July 31, 2015, RichieEscarez<EMAIL_ADDRESS>wrote:

Im looking into the console error that CSE causes in chrome, it might have
something to do with whats happening in Safari too.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11913#issuecomment-126716668
.

--
Regards,
Chao Xu


Closure based commands can't be called from code using Artisan::call

Laravel Version: 5.3.18
PHP Version: 7.0.4
Database Driver & Version: none

Description:
If you call a command from routes.console.php using Artisan::call() it throws CommandNotFoundException
Steps To Reproduce:
Install new laravel and
Route::get('/', function () {
    return Artisan::call('inspire');
});

check the documentation:
https://laravel.com/docs/5.3/artisan#closure-commands
I think you are doing a mixing, better read above


Statistics dashboard

On the dashboard, most active studies and most active participants are very useful (with the number of jobs done), could they list all the studies and participants rather than just a few? That would be long lists but they can be put below the participation trend? Ideally they would be in decreasing order of number of jobs done. Most recent participations are not very informative and can be removed I think. Finally, it’s hard to make sense of 7-day participation trend (see below, it doesn’t make much sense to me, why is it bumpy?). What would be fantastic would be to have a graph with the number of jobs done by participant and by day and a y-axis to know what the scale is.

Marking this as won't fix for now since it's a feature request rather than a bug fix.

Note from Nicolas:

Same with participants tab, in participations it is nice to have the studies and the number of trials done (not % complete) and it could also list the studies for the last week by default (then option for month, year or all)

Hi @n@nclaidiere
Can you please have a look at the video. I removed the 'Most recent participations'. And let the 'Most active studies' and 'Most active participants' load up to 1000 entries each (the limit is just for safety and as far as I know unlikely to be reached). The two lists are scollable and ordered by most active first. Are you happy with these changes?
Then about the graph. We use Vuetify and this framework only supports sparklines. Vuetify's sparklines are pretty limited. I did my best: reduced 'bumpiness' and abolished the flashy colors - but it's impossible to add a y-axis (which I personally dislike since one cannot see how many jobs were done on each day). What do you think, is this enough?
https://github.com/user-attachments/assets/923c409f-bd1a-41a7-8c3b-5a5d32a0028d

Hi Kristian,
Thanks for the video.
'Most active studies' and 'Most active participants' load up to 1000 entries each (the limit is just for safety and as far as I know unlikely to be reached). The two lists are scollable and ordered by most active first. Are you happy with these changes?
Yes, that sounds good, will there be an option to change the timespan (day, week, month, year?) as planned?
For the sparkline, if it isn't possible to know how many jobs were done on each day, then it's not useful. If a graphic is not possible, a table instead would be great, you could have list of participants with number of trials each day and total on each day. Something like this:

| 10/10/2024 | 09/10/2024 | 08/10/2024 | 07/10/2024 | 06/10/2024 | 05/10/2024 | 04/10/2024
-- | -- | -- | -- | -- | -- | -- | --
Total | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000
p1 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p2 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p3 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p4 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p5 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p6 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p7 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p8 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p9 | 100 | 100 | 100 | 100 | 100 | 100 | 100
p10 | 100 | 100 | 100 | 100 | 100 | 100 | 100

Is that possible? and in fact, the same table for studies maybe.

It seems vuetify as a data table component:
https://vuetifyjs.com/en/components/data-tables/basics/#virtual-tables

Yes, that sounds good, will there be an option to change the timespan (day, week, month, year?) as planned?

I can't remember this option to change the timespan. Where this planned? It's possible. Internally it's just a parameter. But in the GUI it would need additional input fields. But are additional input fields something you envisioned or am I misunderstand you?
Then about the table instead of the sparkline. Let me have a look whether it's possible with the data we have already. I wouldn't like to change another API endpoint for this.

I can't remember this option to change the timespan. Where this planned? It's possible. Internally it's just a parameter. But in the GUI it would need additional input fields. But are additional input fields something you envisioned or am I misunderstand you?
Yes, it was planned. My idea was to have something like the google Ngram plots (https://books.google.com/ngrams/), you can choose the period and visualise the data. But if you don't have a y-axis and can't see the values it doesn't work (although there seems to be a way to put the values as text below the points, see https://vuetifyjs.com/en/components/sparklines/#custom-labels).
Re. input fields: my idea was like buttons or drop down menu, choosing btw data for days, weeks, months. You could have the same thing in table format of course.
If it's not clear we can meet to discuss.

I just went to check on my electricity bill, here is what would be awesome.
DAY (you can see every hour)

WEEK (you can see every day)

and so on for months and year.
Note the arrows that allow you to change days, weeks, months, years? and the total and timespan?

Hi,
I agree sparklines are too limited to be useful and a table would do just fine.
Columns would vary, past day would give you the number of trials per hour, past week the number of trials per day for last 7 days, per month would be nb trials for last 30 days and past year would be nb trials by month for last 12 months.
Rows would be total and then either by participant or by study, two different tables on top of each other.
Is that what you have in mind? dropdown menu or 4 buttons, as you prefer.

Yes, that should be doable! :+1: @kristian-lange Is that clear, and do you agree?

Hi @nclaidiere, hi @smathot I worked pretty hard on this one. Please have a look. I combined Vuetify's sparkline with a simple table and this way I was able to show a graph + values + labels. The only downside I can see is that it still has no y-axis but the values are underneath the labels. It also has an selector for 'Past day', 'Past week', 'Past month' (actually always past 30 days), and 'Past year'. The data handling in the background was pretty difficult for me.
https://github.com/user-attachments/assets/7b75b3fe-6d79-4c1e-892f-46537e54c230

Ok that looks much better!


Fix graylog connecting issue

Closes: #1479
Feedback from @mszyzdek
ref. https://github.com/fluent/fluentd-kubernetes-daemonset/issues/1479#issuecomment-1996018837

graylog flavour of fluentd-kubernetes-daemonset uses gelf 3.0.0 and this version of gelf gem has Fixnum in code, https://github.com/graylog-labs/gelf-rb/commit/7cc3cbb63556f54967699e034b1d51cf30bf1c6f
in ruby 3.2 Fixnum was removed after previous deprecation in version 2.4 https://www.ruby-lang.org/en/news/2022/12/25/ruby-3-2-0-released/
ruby in newest fluentd was upgraded to 3.2 https://github.com/fluent/fluentd-docker-image/commit/4f1d5e8dcdbbed10d1458edaecfb771f6ba9f05e so it also happened in fluentd-kubernetes-daemonset
gelf 3.0.0 cannot work with ruby 3.2+ so we can see sad error on container start

https://github.com/fluent/fluentd-kubernetes-daemonset/issues/1479#issuecomment-2222335839
Sorry, I don't understand #219.
Can we revert #219 now?

Oh, gelf-rb/issues/63 is still brocker.

For graylog, fluent-plugin-json-in-json-2 depends on yajl-ruby...

Thanks. I see...

TODO: eliminate yajl-ruby (yajl/json_gem)

Purge yajl/json_gem explicitly from image?

https://github.com/fluent/fluentd-kubernetes-daemonset/issues/1479#issuecomment-2224777455
The issue of gelf-rb 3.1.0 remains partially.

Thanks, after #1507 was merged, let's ship it.


DocsArchive-<IP_ADDRESS>Auto archive content

Auto archive content from https://github.com/OPS-E2E-PPE/docs-archive-test

Docs Build status updates of commit a8d8e65:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error]

Cannot sync git repo to specified commit because branch Archive_master_2019-09-25-06-38-49 has been deleted or has been force pushed: fatal: Couldn't find remote ref Archive_master_2019-09-25-06-38-49

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Does this project have a consistent maintenance?

Is it okay to use this project in production applications?
Is this project being maintained regularly?
Will this project follow the next releases of gqlgen? Or is it just for this forked version only?
English is not my first language. So If something is not clear, please reply, I will describe it again.

Hi @hsblhsn
Sorry for late response
Personally, I've not used it in production yet
Yes I try to keep it up to date on each gqlgen release

I close this issue but feel free to open issues if you encounter any bugs


Hive QL key word support

such as distribute by...

merged ...

key word “distribute by” is not support at 0.9.6-SNAPSHOT


Update commonly_proposed.md to include ! deprecation

As suggested by the core team, this PR adds a link to and summarizes the core team's feedback on removal or deprecation of the force-unwrap operator.

This LGTM, any concerns with this wording @airspeedswift ?

This LGTM, any concerns with this wording @airspeedswift ?

This looks great @xwu, thank you for doing this.


How do we enable graceful-etcd-shutdown?

The docs say:

The contrib/user-data.example provides 2 units, graceful-etcd-shutdown.service and graceful-ceph-shutdown.service, that contain some experimental logic to clean-up a Deis node’s cluster membership before reboot, shutdown or halt events. The units can be used independently or together.

root@deis-1:/# systemctl enable graceful-etcd-shutdown
root@deis-1:/# systemctl start graceful-etcd-shutdown

But I get:
$ sudo systemctl enable graceful-etcd-shutdown
Failed to execute operation: No such file or directory

I provisioned my cluster using provision-aws-cluster.sh.

This was only merged in #4554 18 days ago, so it's only provisioned on hosts that were launched as of Deis v1.12.3.

Ahh. Can I fit it into my 1.12.2 provisioned hosts somehow?
On Monday, February 15, 2016, Chris Armstrong<EMAIL_ADDRESS>wrote:

This was only merged in #4554 https://github.com/deis/deis/pull/4554 18
days ago, so it's only provisioned on hosts that were launched as of Deis
v1.12.3.
—
Reply to this email directly or view it on GitHub
https://github.com/deis/deis/issues/4918#issuecomment-183991611.

@rstacruz you can re-provision your hosts from master, then manually set the platform version to v1.12.2 but be warned that we don't "officially" test that scenario.

Considering that @carmstrong answered your question, I'm going to go ahead and close this issue, but please re-open if you need help getting that working. Thanks! :)


docs: clarify how to choose proxy type

I think there is room for improvement in the documentation with regards to explaining how to choose between transparent and UUPS proxies.  Let me give you my perspective as someone who is a newbie to upgradeable contracts, but otherwise an experienced developer.
Firstly I read https://docs.openzeppelin.com/contracts/4.x/api/proxy#transparent-vs-uups and several other good resources (including relevant EIPs), to learn the technical differences between transparent and UUPS proxies.
Next I read this overview:

https://docs.openzeppelin.com/upgrades-plugins/1.x/

and then followed these instructions to make one of my OpenZeppelin ERC721 contracts upgradeable:

https://docs.openzeppelin.com/upgrades-plugins/1.x/writing-upgradeable

and adjusted my Hardhat tests and deployment scripts according to:

https://docs.openzeppelin.com/upgrades-plugins/1.x/hardhat-upgrades

I also consulted the contracts documentation which offered very similar info:

https://docs.openzeppelin.com/contracts/4.x/upgradeable

and also this guide:

https://docs.openzeppelin.com/learn/upgrading-smart-contracts

However none of these six resources mention that there is a way to choose between transparent and UUPS proxies!  It was clear to me that there must be, because Transparent vs UUPS Proxies says:

The original proxies included in OpenZeppelin followed the Transparent Proxy Pattern. While this pattern is still provided, our recommendation is now shifting towards UUPS proxies, which are both lightweight and versatile.

So I kept hunting, with no luck.
Eventually I resorted to searching in the source, and found:
https://github.com/OpenZeppelin/openzeppelin-upgrades/blob/c73d34724238f04a91b248c3b345103a45945cda/packages/plugin-hardhat/src/deploy-proxy.ts#L61-L78
which led me to:
https://docs.openzeppelin.com/upgrades-plugins/1.x/api-hardhat-upgrades#common-options
where I finally realised that the trick is to pass { kind: 'uups' } to upgrades.deployProxy().  (I also see that the Truffle upgrades API offers the same thing.)
After more hunting, I eventually found UUPS Proxies: Tutorial (Solidity + JavaScript) - Smart Contracts / Guides and Tutorials - OpenZeppelin Community which is linked from https://docs.openzeppelin.com/openzeppelin/upgrades and is the clearest explanation.  But ideally I would have found this information much more easily.
So I would suggest that at least some, if not all, of the first 6 links listed above should be modified to mention the mechanism for choosing the proxy type, and cross-link to the API docs and/or that tutorial.
Hope that feedback makes sense and is useful!

Agreed, take me tons of time to figure out all these.
Especially the { kind: 'uups' } and initializer args in upgrades.deployProxy()


CME during completion

Something to do with model loading, @davidfestal ?
java.util.ConcurrentModificationException
	at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:901)
	at java.util.ArrayList$Itr.next(ArrayList.java:851)
	at com.redhat.ceylon.ide.common.completion.completionManager_.isTypeCaseOfSwitch$priv$(IdeCompletionManager.ceylon:1497)
	at com.redhat.ceylon.ide.common.completion.completionManager_.isCaseOfSwitch$priv$(IdeCompletionManager.ceylon:1409)
	at com.redhat.ceylon.ide.common.completion.completionManager_.isProposable$priv$(IdeCompletionManager.ceylon:1366)
	at com.redhat.ceylon.ide.common.completion.completionManager_.constructCompletions$priv$(IdeCompletionManager.ceylon:912)
	at com.redhat.ceylon.ide.common.completion.completionManager_.getContentProposals$canonical$(IdeCompletionManager.ceylon:282)
	at com.redhat.ceylon.ide.common.completion.completionManager_.getContentProposals(IdeCompletionManager.ceylon:108)
	at com.redhat.ceylon.eclipse.code.complete.CeylonCompletionProcessor$CompletionJob.run(CeylonCompletionProcessor.ceylon:159)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Ah, I never had this one. Thanks to for your try.  Yes, that might be it. More precisely I think that might be related to the completion being run during a typechecking.

there's now the possibility of limited completion during the model udpate,

Yeah great but I guess it means copying lists before iterating them.
Sent from my iPhone

On 12 Sep 2016, at 15:43, David Festal<EMAIL_ADDRESS>wrote:
there's now the possibility of limited completion during the model udpate,
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

exactly


Fix go code spacing in configuration-a-resource.md

Description of your changes

Fixes minor spacing issue in one of the Go examples.
I have:

[x] Read and followed Upjet's contribution process.
[x] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR if necessary.

How has this code been tested

Thanks for the fix @jaylevin


signature tests being misled by **kwargs

The meshgrid signature test fails with cupy:
E           AssertionError: Argument 'indexing' missing from signature
E           assert 'indexing' in odict_keys(['xi', 'kwargs'])
E            +  where 'indexing' = <Parameter "indexing: str = 'xy'">.name
E            +  and   odict_keys(['xi', 'kwargs']) = <built-in method keys of mappingproxy object at 0x7fc946212170>()
E            +    where <built-in method keys of mappingproxy object at 0x7fc946212170> = mappingproxy(OrderedDict([('xi', <Parameter "*xi">), ('kwargs', <Parameter "**kwargs">)])).keys
E            +      where mappingproxy(OrderedDict([('xi', <Parameter "*xi">), ('kwargs', <Parameter "**kwargs">)])) = <Signature (*xi, **kwargs)>.parameters

array_api_tests/test_signatures.py:92: AssertionError

cupy.meshgrid does have the indexing keyword, but its signature is meshgrid(*x, **kwargs). If we can't check a keyword argument directly, we should assume it is present with **kwargs, and let the individual tests suss out whether it really supports it.

Interesting scenario!

cupy.meshgrid does have the indexing keyword, but its signature is meshgrid(*x, **kwargs). If we can't check a keyword argument directly, we should assume it is present with **kwargs, and let the individual tests suss out whether it really supports it.

Personally I'd rather skip here (after testing everything else first so the test still could fail), as we can't confidently say the test "passes", with a skip reason like "keyword not found, but star-kwargs could consume keyword".


[Docs] Switch renderer for restructured text (rst2html.py -> pandoc)

rst2html.py create artifacts:

pandoc works as you expect:
demo

@silverwind done

Codecov Report

Merging #15659 (fbb61cc) into master (2e85165) will increase coverage by 0.00%.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #15659   +/-   ##
=======================================
  Coverage   43.90%   43.90%
=======================================
  Files         678      678
  Lines       81756    81756
=======================================
+ Hits        35898    35899    +1
+ Misses      40010    40009    -1
  Partials     5848     5848

Impacted Files
Coverage Δ

services/pull/pull.go
43.47% <0.00%> (-0.46%)
:arrow_down:

modules/util/timer.go
85.71% <0.00%> (+42.85%)
:arrow_up:

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 2e85165...fbb61cc. Read the comment docs.


bumping to version 1.1.25

Coverage decreased (-0.08%) to 92.149% when pulling 6e840022fbf7eb2bd248f0107a7148bbd3c7720e on JackDanger:version-1.1.25 into 871625998c41bf90233c294382976c2554206a39 on spulec:master.

Coverage remained the same at 92.231% when pulling 2b9e834e8400fb80b8df41669ce737369f163cca on JackDanger:version-1.1.25 into 871625998c41bf90233c294382976c2554206a39 on spulec:master.

Coverage remained the same at 92.231% when pulling 2b9e834e8400fb80b8df41669ce737369f163cca on JackDanger:version-1.1.25 into 871625998c41bf90233c294382976c2554206a39 on spulec:master.

Coverage decreased (-0.08%) to 92.149% when pulling 0f3c6df8368505f82e5c6c069cac526342448db3 on JackDanger:version-1.1.25 into 871625998c41bf90233c294382976c2554206a39 on spulec:master.


Benchmark and optimize sparse matrix assembly kernels

Task:  Benchmark our new sparse matrix assembly kernels on CPU and GPU for a few different problem sizes.  Perform optimization as necessary.
Why:  The current implementations of these assembly kernels are focused on correctness, but may or may not be leaving performance on the table.  This story is to figure out if they can be improved and improve them.
Done means:  Benchmarks have been performed on CPU and GPU for both a long running 3 blade problem with constraints and a 3000 blade problem with constraints.  If the new assembly stages are a significant contributor to the runtime, optimizations are applied to fix that.

Dense lapack solver was implemented before getting back into this.
Required rebuilding TPLs in CI.
For this Issue, in progress
CPU benchmarks completed; only slowdown contribute to sparse matrix kernels.  3 sec to 7 sec
May be due to atomics being used in assembly, which will add some slowdown
Currently building trilinos with CUDA to do more testing.

No slowdown was observed when running on GPU.
Optimizations for the serial run were applied, resulting in the code running about as fast as before the change was made - about 3 seconds for ContribueElementsToSparseMatrix for our large benchmarks.
summary of optimizations (in approximate order of how much speed up they gave for the serial build):

Turned off atomics when running in serial mode (they aren't necessary)
Tell KokkosKernels to assume that the components are in sorted order rather than random order
Move populating col_idx out one loop, which should decrease the number of copies done there and improve memory access patterns.


is ratchet any test on iOS9?

No, it hasn't been tested on iOS 9 specifically.
See also #792.

Please let me know if any issue found on iOS9. I forked this project and actively developing on it. As long as no action taken on the master branch of this project, welcome to create issues / pull requests at my forked repository: https://github.com/mazong1123/ratchet-pro


Broken link

There is link from README.md which leads to 404 - https://docs.jitsu.com/jitsu-classic

Fixed


Wrong order of generated JS code

I stumbled over this issue during my development. Provided Elm code is dumbed down version of what I was working on so it might looks nonsensical:
import Html exposing (Html, text)
import List exposing (filter, head)
import Maybe

pageIndex : String -> Html
pageIndex attr =
    text "Main Page"

page1 : String -> Html
page1 attr =
    text (first "NOTHING")

notFound : String -> Html
notFound attr =
    text "Not Found"

pages : List (String -> Html, String)
pages =
    [ (pageIndex, "pageIndex")
    , (page1, "page1")
    ]

first : String -> String
first alter =
    case head pages of
        Just p -> snd p
        Nothing -> alter

view : Html
view =
    let
        filteredPages name =
            filter (\p -> snd p == name) pages
        v = fst (Maybe.withDefault (notFound, "notFound") (head (filteredPages "page1")))
    in
        v "cat"

main : Html
main =
    view

Assuming we have above code in file named BadMain.elm:
elm make BadMain.elm --output bad_index.html
Executing elm make does not gives any errors but when you run bad_index.html in your web browser you will get:

TypeError: v is not a function

I looked into generated JS code and debugged it a little. I found this particular code to be wrong:
var notFound = function (attr) {    return $Html.text("Not Found");};
var pageIndex = function (attr) {    return $Html.text("Main Page");};
var pages = _U.list([{ctor: "_Tuple2",_0: pageIndex,_1: "pageIndex"},{ctor: "_Tuple2",_0: page1,_1: "page1"}]);
var page1 = function (attr) {    return $Html.text(first("NOTHING"));};
var first = function (alter) {    var _p0 = $List.head(pages);if (_p0.ctor === "Just") {    return $Basics.snd(_p0._0);} else {    return alter;}};

var page1 is declared after pages but pages references page1. This will result in storing undefined in pages and breaking things later one.
Additionally, I noticed that when you change definition of page1 to:
page1 : String -> Html
page1 attr =
    text "NOTHING"

JS code in bad_index.html will be generated in correct order and everything will work correctly.
Used Elm version: elm-make 0.16 (Elm Platform 0.16.0)

This is just another instance of #873. Maybe the twentieth or thirtieth that got reported. :smile:
You can safely close the issue here, just as all the others get closed until the "mother issue" #873 will eventually be resolved.

Very well then, closing as specific case of #873.


Integrate more tightly with UI

Why not make gitkraken launch in a windowed or full mode (maybe with context menu) when clicking or hovering the branch info here:

I'll look into it when I get chance. PR welcome in the mean time 😉


PostgreSQL version list out of date

The versions list at https://github.com/aiven/aiven-operator/blob/72d8c6d2c009455ff19df8ffbc4850968744b42c/config/crd/bases/aiven.io_postgresqls.yaml#L489 stops at 12, but 13 and 14 are now available.  I'm not sure if that list needs to be updated elsewhere as well, hence opening this as an issue rather than a PR.

Looks like #191 will fix this


Demo for CRNN

change the demo for crnn

I deleted the branch crnnctc by mistake which automatically closed this pr.
But I have created a new pr RELATED PR68.


new peers cannot join when connection limit has been reached

We've since increased the default limit to 30.
If you have 11 peers all fully-connected, then a 12th peer is unable to make a connection.  This is because there is a limit of 10 connections per peer and all of them are at that limit.
Evidence:
weave status from one of 11 connected peers:
weave router git-495419e28c2d
Encryption off
Our name is 7e:ac:3f:97:e5:4d (testweave1)
Sniffing traffic on &{2513 1500 ethwe 7e:ac:3f:97:e5:4d up|broadcast}
MACs:
7e:ac:3f:97:e5:4d -> 7e:ac:3f:97:e5:4d (2015-02-26 11:08:16.482111269 +0000 UTC)
3e:0e:81:a4:96:8f -> 2a:7a:39:40:c1:d8 (2015-02-26 11:08:20.977117117 +0000 UTC)
32:28:c3:82:3e:1b -> a6:e6:bd:a7:b8:a0 (2015-02-26 11:08:21.188593636 +0000 UTC)
02:f9:02:d8:5f:38 -> c2:30:43:55:19:5f (2015-02-26 11:08:21.775328828 +0000 UTC)
a2:c1:e7:e1:96:d8 -> 7e:ac:3f:97:e5:4d (2015-02-26 11:08:17.32618667 +0000 UTC)
ce:42:ec:fe:e2:51 -> c2:e1:f5:a0:42:01 (2015-02-26 11:08:20.846974172 +0000 UTC)
f2:df:f3:4f:84:6e -> 5a:34:38:a6:05:8f (2015-02-26 11:08:21.193589022 +0000 UTC)
56:a9:91:8d:95:b3 -> 46:25:59:ec:27:5c (2015-02-26 11:08:21.200578214 +0000 UTC)
fa:11:59:92:31:b4 -> 0a:9a:bd:ac:d7:16 (2015-02-26 11:08:21.200831703 +0000 UTC)
7e:ad:b1:79:a4:7e -> fe:37:85:f1:94:99 (2015-02-26 11:08:21.201126642 +0000 UTC)
a6:5f:db:b4:0e:65 -> 62:7c:f7:a2:40:8b (2015-02-26 11:08:21.201333412 +0000 UTC)
ce:77:55:85:a0:c8 -> 2a:5a:9c:ac:05:a9 (2015-02-26 11:08:21.794248927 +0000 UTC)
Peers:
Peer 0a:9a:bd:ac:d7:16 (testweave7) (v28) (UID<PHONE_NUMBER>5536853396)
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:56900]
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:6783]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:46153]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:6783]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:6783]
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:47788]
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:44456]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:6783]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:6783]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:6783]
Peer 7e:ac:3f:97:e5:4d (testweave1) (v28) (UID<PHONE_NUMBER>251632325)
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:6783]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:6783]
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:6783]
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:55913]
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:6783]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:43878]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:50433]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:6783]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:6783]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:6783]
Peer c2:30:43:55:19:5f (testweave3) (v28) (UID<PHONE_NUMBER>5233588601)
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:6783]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:41621]
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:37034]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:34423]
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:45018]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:6783]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:46177]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:40224]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:6783]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:58442]
Peer 2a:5a:9c:ac:05:a9 (testweave4) (v34) (UID<PHONE_NUMBER>6669939436)
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:58075]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:48261]
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:6783]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:48315]
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:40917]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:33079]
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:6783]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:36718]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:6783]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:6783]
Peer fe:37:85:f1:94:99 (testweave0) (v27) (UID<PHONE_NUMBER>713649865)
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:49958 (unestablished)]
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:50302]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:55964]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:6783]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:6783]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:6783]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:6783]
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:6783]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:56589]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:6783]
Peer a6:e6:bd:a7:b8:a0 (testweave6) (v28) (UID<PHONE_NUMBER>43995687)
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:57992]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:56465]
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:43702]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:33599]
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:6783]
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:6783]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:6783]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:51252]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:59566]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:6783]
Peer 2a:7a:39:40:c1:d8 (testweave9) (v26) (UID<PHONE_NUMBER>184792905)
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:6783]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:6783]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:36469]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:6783]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:6783]
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:60148]
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:6783]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:57432]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:6783]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:6783]
Peer 62:7c:f7:a2:40:8b (testweave10) (v33) (UID<PHONE_NUMBER>864029143)
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:56714]
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:38057]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:47515]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:6783]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:6783]
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:6783]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:6783]
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:6783]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:42999]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:56942]
Peer 5a:34:38:a6:05:8f (testweave8) (v30) (UID<PHONE_NUMBER>387776875)
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:6783]
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:6783]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:46493]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:52245]
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:6783]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:55504]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:6783]
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:6783]
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:35803]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:6783]
Peer c2:e1:f5:a0:42:01 (testweave2) (v34) (UID<PHONE_NUMBER>6843464028)
   -> 46:25:59:ec:27:5c (testweave5) [<IP_ADDRESS>:41859]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:45829]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:6783]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:34186]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:42741]
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:6783]
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:39211]
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:6783]
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:42466]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:49836]
Peer 46:25:59:ec:27:5c (testweave5) (v28) (UID<PHONE_NUMBER>0879598741)
   -> 2a:5a:9c:ac:05:a9 (testweave4) [<IP_ADDRESS>:52043]
   -> 7e:ac:3f:97:e5:4d (testweave1) [<IP_ADDRESS>:59420]
   -> c2:30:43:55:19:5f (testweave3) [<IP_ADDRESS>:55530]
   -> a6:e6:bd:a7:b8:a0 (testweave6) [<IP_ADDRESS>:6783]
   -> fe:37:85:f1:94:99 (testweave0) [<IP_ADDRESS>:49016]
   -> 0a:9a:bd:ac:d7:16 (testweave7) [<IP_ADDRESS>:45583]
   -> 62:7c:f7:a2:40:8b (testweave10) [<IP_ADDRESS>:6783]
   -> 2a:7a:39:40:c1:d8 (testweave9) [<IP_ADDRESS>:47410]
   -> 5a:34:38:a6:05:8f (testweave8) [<IP_ADDRESS>:6783]
   -> c2:e1:f5:a0:42:01 (testweave2) [<IP_ADDRESS>:6783]
Routes:
unicast:
46:25:59:ec:27:5c -> 46:25:59:ec:27:5c
c2:e1:f5:a0:42:01 -> c2:e1:f5:a0:42:01
2a:7a:39:40:c1:d8 -> 2a:7a:39:40:c1:d8
a6:e6:bd:a7:b8:a0 -> a6:e6:bd:a7:b8:a0
2a:5a:9c:ac:05:a9 -> 2a:5a:9c:ac:05:a9
fe:37:85:f1:94:99 -> fe:37:85:f1:94:99
c2:30:43:55:19:5f -> c2:30:43:55:19:5f
62:7c:f7:a2:40:8b -> 62:7c:f7:a2:40:8b
0a:9a:bd:ac:d7:16 -> 0a:9a:bd:ac:d7:16
7e:ac:3f:97:e5:4d -> 00:00:00:00:00:00
5a:34:38:a6:05:8f -> 5a:34:38:a6:05:8f
broadcast:
c2:e1:f5:a0:42:01 -> []
46:25:59:ec:27:5c -> []
0a:9a:bd:ac:d7:16 -> []
7e:ac:3f:97:e5:4d -> [c2:e1:f5:a0:42:01 46:25:59:ec:27:5c a6:e6:bd:a7:b8:a0 2a:5a:9c:ac:05:a9 fe:37:85:f1:94:99 c2:30:43:55:19:5f 62:7c:f7:a2:40:8b 0a:9a:bd:ac:d7:16 5a:34:38:a6:05:8f 2a:7a:39:40:c1:d8]
c2:30:43:55:19:5f -> []
2a:5a:9c:ac:05:a9 -> []
fe:37:85:f1:94:99 -> []
a6:e6:bd:a7:b8:a0 -> []
2a:7a:39:40:c1:d8 -> []
62:7c:f7:a2:40:8b -> []
5a:34:38:a6:05:8f -> []
Reconnects:

Log from new peer:
weave 2015/02/26 11:11:58.716929 Command line options: map[iface:ethwe name:7a:91:bb:cb:02:e6 nickname:number12 wait:20]
weave 2015/02/26 11:11:58.717151 Command line peers: [<IP_ADDRESS>]
weave 2015/02/26 11:11:59.717809 Communication between peers is unencrypted.
weave 2015/02/26 11:11:59.718067 Our name is 7a:91:bb:cb:02:e6 (number12)
weave 2015/02/26 11:11:59.753879 Sniffing traffic on &{2557 65535 ethwe b6:a8:01:69:e4:a2 up|broadcast|multicast}
weave 2015/02/26 11:11:59.753929 Discovered our MAC b6:a8:01:69:e4:a2
weave 2015/02/26 11:11:59.755044 ->[<IP_ADDRESS>:6783] attempting connection
weave 2015/02/26 11:11:59.756032 ->[<IP_ADDRESS>:6783] completed handshake with c2:e1:f5:a0:42:01
weave 2015/02/26 11:11:59.756510 ->[c2:e1:f5:a0:42:01]: connection shutting down due to error: write tcp4 <IP_ADDRESS>:6783: connection reset by peer
weave 2015/02/26 11:11:59.756913 ->[c2:e1:f5:a0:42:01]: connection added
weave 2015/02/26 11:11:59.757022 Removed unreachable Peer c2:e1:f5:a0:42:01 (testweave2) (v0) (UID<PHONE_NUMBER>6843464028)
weave 2015/02/26 11:11:59.757130 ->[c2:e1:f5:a0:42:01]: connection deleted
weave 2015/02/26 11:12:00.377456 Discovered local MAC 4a:c9:42:10:f3:14
weave 2015/02/26 11:12:02.533374 ->[<IP_ADDRESS>:6783] attempting connection
weave 2015/02/26 11:12:02.534473 ->[<IP_ADDRESS>:6783] completed handshake with c2:e1:f5:a0:42:01
weave 2015/02/26 11:12:02.535093 ->[c2:e1:f5:a0:42:01]: connection shutting down due to error: write tcp4 <IP_ADDRESS>:6783: connection reset by peer
weave 2015/02/26 11:12:02.535223 ->[c2:e1:f5:a0:42:01]: connection added
weave 2015/02/26 11:12:02.535269 Removed unreachable Peer c2:e1:f5:a0:42:01 (testweave2) (v0) (UID<PHONE_NUMBER>6843464028)
weave 2015/02/26 11:12:02.535290 ->[c2:e1:f5:a0:42:01]: connection deleted

weave status from new peer:
weave router git-495419e28c2d
Encryption off
Our name is 7a:91:bb:cb:02:e6 (number12)
Sniffing traffic on &{2557 65535 ethwe b6:a8:01:69:e4:a2 up|broadcast|multicast}
MACs:
b6:a8:01:69:e4:a2 -> 7a:91:bb:cb:02:e6 (2015-02-26 11:11:59.753923742 +0000 UTC)
4a:c9:42:10:f3:14 -> 7a:91:bb:cb:02:e6 (2015-02-26 11:12:00.377420763 +0000 UTC)
Peers:
Peer 7a:91:bb:cb:02:e6 (number12) (v14) (UID<PHONE_NUMBER>5766780103)
Routes:
unicast:
7a:91:bb:cb:02:e6 -> 00:00:00:00:00:00
broadcast:
7a:91:bb:cb:02:e6 -> []
Reconnects:
<IP_ADDRESS>:6783 (next try at 2015-02-26 11:12:58.046571925 +0000 UTC)

Logs from existing peer:
weave 2015/02/26 11:11:59.755390 ->[<IP_ADDRESS>:42194] connection accepted
weave 2015/02/26 11:11:59.756041 ->[<IP_ADDRESS>:42194] completed handshake with 7a:91:bb:cb:02:e6
weave 2015/02/26 11:11:59.756138 ->[7a:91:bb:cb:02:e6]: connection shutting down due to error: Connection limit reached (10)
weave 2015/02/26 11:12:02.533778 ->[<IP_ADDRESS>:42196] connection accepted
weave 2015/02/26 11:12:02.534486 ->[<IP_ADDRESS>:42196] completed handshake with 7a:91:bb:cb:02:e6
weave 2015/02/26 11:12:02.534626 ->[7a:91:bb:cb:02:e6]: connection shutting down due to error: Connection limit reached (10)

As an interim improvement, any objections to raising the connection limit to 100? That's 10k connections in a fully connected network, which I should think modern network kit has no trouble handling.
Beyond that... some algorithm that decides whether to "bump" existing connections for new ones based on "connectivity":

a connection to a new peer, i.e. one that no other peer is connected to, bumps any connection to a peer that is connected to other peer(s).
a connection to a peer which provides the sole route to/from that peer for some other peer, bumps any connection for which that isn't the case.

and a few more like that. The objective is to maximise routability between peers and to minimise hop count. That should do for starters; we can get more clever later, taking into account latencies, bandwidth, congestion, etc, etc.

Sounds a reasonable solution. If I can get weave working well for my test senario we could easily have a network of thousands.

+1 to allow more than 11 peers to join the network ;-)

Note that there is a command-line parameter -connlimit which lets you override the default (I didn't know that when I filed this issue).
However, when testing with higher peer numbers we saw other issues - #445 - so leaving the default limit of 10 unchanged until we are confident they are resolved.

Recent changes have made weave much better behaved when there are large numbers of fully-connected peers. I can run 50 fully-connected weaves on my laptop, and could no doubt go much further if each weave was on a separate machine, as is typically the case.
Therefore in most deployments of >30 peers it should be possible to avoid the problems described in this issue by supplying an increased connlimit. I doubt one would be able to wire up hundreds of peers that way, but there are probably other issues with such large deployments anyway.

Just hit this issue, new nodes can not join, took some time to debug, wondering if our machine has network issues...
This limit really should be well documented, especially in site/troubleshooting.md

Please make it possible to set this -connlimit in a way that is compatible with how to configure the Kubernetes Add-on, because as it stands, that is needlessly hard to do.

@bboreham About this issue ...

We should really set the default a bit higher - it's set very cautiously because we were interested to hear from users what sorts of sizes and topologies they had, ...

We had a cluster scale up to 33 nodes yesterday. 2 nodes could not connect to the rest of the cluster. We fixed it by setting the CONN_LIMIT to 100. We're not 💯% sure of the implications of this.

However, when testing with higher peer numbers we saw other issues - https://github.com/weaveworks/weave/issues/445 - so leaving the default limit of 10 unchanged until we are confident they are resolved.

Should we worry about this? 😅

No, don't worry, that comment was nearly three years ago, and the bug was fixed.
Default limit will be raised to 100 by #3234.

@bboreham Perfect! Thanks. 🙌


Tests Clean Up

This makes sure that we have uniform test names. Cleaned up some other things (I can't really say why though).

Coverage decreased (-0.2%) to 66.168% when pulling 469c5a94fc70f85a1b6d6fe5f019c33477a57291 on apavlo:master into e187418826599085f67115baafe47d32400e44bf on cmu-db:master.

Coverage decreased (-0.1%) to 66.246% when pulling a081a5666093e015fd49e321173cb61d887ab54c on apavlo:master into e187418826599085f67115baafe47d32400e44bf on cmu-db:master.

Coverage increased (+0.03%) to 66.398% when pulling a081a5666093e015fd49e321173cb61d887ab54c on apavlo:master into e187418826599085f67115baafe47d32400e44bf on cmu-db:master.

Coverage decreased (-0.3%) to 66.114% when pulling a081a5666093e015fd49e321173cb61d887ab54c on apavlo:master into e187418826599085f67115baafe47d32400e44bf on cmu-db:master.

Coverage decreased (-0.1%) to 66.233% when pulling f7e06d64c040f83e15265a4d4399b57440a60d2c on apavlo:master into e187418826599085f67115baafe47d32400e44bf on cmu-db:master.

Coverage decreased (-0.003%) to 66.392% when pulling 64b70c8423c1c03d54b99a9dc67572f59fd4f5a4 on apavlo:master into e37bd3b9f5519aee86a937d6d2da607945daec0d on cmu-db:master.


Action Button - transition bug

Description
Transitions on action button are not working properly because the following line
https://github.com/adobe/spectrum-css/blob/89c4f233abcaf74c69fd166a77a1cc1c0f03e947/components/actionbutton/index.css#L155
overwrites the transition from base button
https://github.com/adobe/spectrum-css/blob/89c4f233abcaf74c69fd166a77a1cc1c0f03e947/components/commons/basebutton.css#L44-L47
Expected behavior

Transitions from base button should be used.

The full transition is being shipped in the latest.


Last Week in Pony - September 29, 2019

We had small turnout, so we canceled the sync meeting this week. We'll go over this week's issues and next week's issues next week.

CudaText editor ( uvviewsoft.com ) now has lexer for Pony. To install: Plugins / Addon Manager / Install, find "pony".

Pony 0.32.0 has been released. Full details are available in the release notes.


style: adhere to naming scheme

Description

This PR overhauls all the naming schemes for the files, based on #282. These changes are done because we decided to follow a naming scheme to have more predictability and overview of where we are and where we need to be (from a file level).
In the process of renaming/converting things over, I found several issues and code overlap/repetition, which spawned other PRs, like #289.
I tried to fix the testing errors, but they are crazy confusing to me so maybe @philter87 you could take a look at how to resolve them? I tried to look through the traceback stack but damn it is big and intimidating!
Related Issues

Closes #281
See also Issues #196
Testing

[x] Yes
[ ] No, not needed (give a reason below)
[ ] No, I need help writing them

Reviewer Focus

This PR requires an in-depth review.

Checklist

For all PRs that are not general documentation

[x] Tests accompany or reflect changes to the code
[ ] Tests ran and passed locally
[x] Ran the linter and formatter
[x] Build has passed locally
[x] Relevant documentation has been updated

@seedcase-project/developers done! Please check this out 😁

@lwjohnst86 I have fixed the tests

@lwjohnst86 I have fixed the tests

@philter87 What was the issue?

Fixed things based on your comments @signekb plus updated from  main.

@lwjohnst86 I have fixed the tests

@philter87 What was the issue?

Small things.

Missing 's' in "projects-id-metadata-id"
And space around equals sign is apparently not allowed in a Django template


February 28 Checkpoint

Major design changes and improvements to the layout of the game.
Final (feature) checkpoint before Game Jame submission.

 GitHub Power-up Test


[VCDA-3254] checking for bootstrap success and logging cloud init output

Signed-off-by: ltimothy7<EMAIL_ADDRESS>TODO: testing

This change is

controllers/cluster_scripts/cloud_init_control_plane.yaml, line 30 at r1 (raw file):
Previously, sahithi (Sahithi Ayloo) wrote…
When is this file actually created and updated - while the script is being executed (or) once it is fully completed?
Have you tested this out?

Per my earlier understanding, this file will be there but the contents may not yet be flushed out. As in, we will see old details and not our script details in the file. We need to test it out.

controllers/cluster_scripts/cloud_init_node.yaml, line 45 at r2 (raw file):

      if [[ ! -f /run/cluster-api/bootstrap-success.complete ]]
      then
        echo "file /run/cluster-api/bootstrap-success.complete not found" &>> /var/log/capvcd/customization/error.log

Is it guaranteed that this path will be present?

controllers/cluster_scripts/cloud_init_node.yaml, line 48 at r3 (raw file):
Previously, sahithi (Sahithi Ayloo) wrote…
What IP will it hold if it is a multimaster cluster? Loadbalancer IP (or) its own master node IP?
In the case of worker node join, what IP will it hold?

LoadBalancerIP will be the IP for a single and multu-master cluster.


Custom trackView dataLayer.push object

I was trying to implement a custom tracking pageview event using vue-router, to try to use the router meta params to generate the custom object that I need to send to my data team.
Although I find out that I can't do that with the way is is coded right now.
So in order to fix that, my suggestion would be to change the trackView method from what it is right now
trackView(screenName, path) {
    if (inBrowser && pluginConfig.enabled) {
      logDebug('Dispatching TrackView', { screenName, path })
      let dataLayer = (window.dataLayer = window.dataLayer || [])
      dataLayer.push({
        event: 'content-view',
        'content-name': path,
        'content-view-name': screenName
      })
    }
  }

to something like:
trackView(screenName, path, options = {}) {
    if (inBrowser && pluginConfig.enabled) {
      logDebug('Dispatching TrackView', { screenName, path })
      let dataLayer = (window.dataLayer = window.dataLayer || [])
      dataLayer.push({
        event: 'content-view',
        'content-name': path,
        'content-view-name': screenName,
        ...options
      })
    }
  }

That way at least if we want to send trackView events on the router change we can use it like this:
this.$gtm.trackView('Home', '/home-page', { action: 'page-view', category: 'Home' .... })
And if we want to make that trackview Event automátic, we could change the way we are using the router meta params:
// Dispatch vue event using meta gtm value if defined otherwise fallback to route name
    const name = to.meta.gtmName || to.name
    const options = to.meta.gtm || {}
    const baseUrl = vueRouter.options.base || '';
    if (trackOnNextTick) {
      Vue.nextTick(() => {
        Vue.gtm.trackView(name, `${baseUrl}${to.fullPath}`, options)
      })
    } else {
      Vue.gtm.trackView(name, `${baseUrl}${to.fullPath}`, options)
    }

Then in your meta params you could set the gtm property like an object
meta: {
 gtmName: '',
 gtm: {
  action: '',
  category: '',
 ...
 }
}

If it's something you are willing to do I would submit a PR aswell so everyone can use it.
Thanks

Added in https://github.com/mib200/vue-gtm/commit/7d835b40984b5cacde07457b622314971453d28a


feat!: turn themes into userstyles

turn the themes into userstyles so that visitors can add it to their browser and it'll apply to any page using dev.css.
unfortunately, this is a breaking change since i would have to change the file names to include .user before the .css, so it'll have to be part of dev.css v4 since otherwise it'll break links. if you have any ideas to get around this, please let me know!

considering putting these in a separate folder so i can do specific customizations for the userstyles, and i wont need to bump major


[Enhancement] Do some code optimization.[ZookeeperMetaService]

Search before asking

[X] I had searched in the issues and found no similar issues.

Enhancement Request

located at:
eventmesh-registry-plugin/eventmesh-registry-zookeeper/src/main/java/org/apache/eventmesh/registry/zookeeper/service/ZookeeperRegistryService.java line 71,202-223,251-272.
Describe the solution you'd like
a. Change to private modifier.
b. Repeat code extraction as method.

Are you willing to submit PR?

[ ] Yes I am willing to submit a PR!

Hello, I am a beginner in eventmesh. Upon seeing the problem described in this issue, I wonder if eventmesh has already been refactored. I couldn't find the location of eventmesh-registry-zookeeper, but I found one located in eventmesh metaeventmesh-meta\eventmesh-meta-zookeeper\src\main\java\org\apache\eventmesh\meta\zookeeper\service\ZookeeperMetaService. Do I need to modify it here?
Meanwhile, regarding the document "Quick Start", I think the description of meta (Registry Meta Service) is too simple. I only understood it based on the code. Can I try to improve the Chinese description of Quick Start in the document?（https://eventmesh.apache.org/zh/docs/instruction/runtime）

Yes, the location may have changed due to updates to the code module, this looks unfinished, welcome to the eventmesh community.


talk: dm disappeared from sidebar (until refresh)

Had gone afk for just a minute, returned to my talk tab, and wanted to view the dm I had had just a little while ago with ~habsul-rignyr. But.. it wasn't in my sidebar anymore?
After a page refresh, it showed up just fine again.

Not sure what caused this. Maybe it just got sorted poorly, and was somewhere way down? A quick manual search didn't reveal it though.

this should be fixed as of a few releases ago


Should unhandled userOutboundEvents have their promises succeed or fail?

Currently BaseSocketChannel will succeed the promise for a userOutboundEvent that is not handled by the pipeline:
https://github.com/apple/swift-nio/blob/29d6bf029ae12e5bf7b289ce596cc50f66d041d1/Sources/NIO/BaseSocketChannel.swift#L812-L814
I wanted to ask whether that was actually a sensible behaviour. My gut says that we probably should fail events that make it that far, on the grounds that whatever outcome you were hoping to get you didn't successfully get it. Maybe with ChannelError.unsupportedOperation?

Yeah I think we should fail... Not sure if unsupportedOperation is a good error tho.

I also think we should fail em

add a new error to report this


Troubles with my first post

Hello, yesterday I started using jekyll and at the moment I had two difficulties:

I don't understand how "Red More" works, it seems to be added randomly. I do not want the "read more"
I could not set the post date

This is the code:
---
layout: post
title: !Bienvenidos!
date: 2019-8-8
---
Bievenidos a mi sitio personal.

Acá podrán encontrar información sobre mis proyectos personales, mis actividades de docencia e incluso algunos escritos sobre mis hobbies e intereses profesionales.

and the file name:
2019-8-8-Bienvenidos.md

After several days of trial and error he found the solution to my 2 problems:

"Read more" takes the text to the first "." Finding
It is not necessary to add the "date" tag


Solved chart issue.

Files Changed
_Layout.cshtml-Added the script for embedding Chart.js library
system.config.js-Added the path for chart.js
Checks

[x] Naming Conventions
[x] Server side code comments (proper English, grammar and no spelling mistakes)
[x] Client side code comments (proper English, grammar and no spelling mistakes)
[x] Unused variables, methods, blank spaces and name spaces.
[x] Optimal Code and code formatting
[x] Commit History is proper, no merge is done.
[x] Commit/pull request messages should be proper to justify your feature
[x] All test cases are executed provided by tester.

This change is

SonarQube analysis reported 1 issue
Note: The following issues were found on lines that were not modified in the pull request. Because these issues can't be reported as line comments, they are summarized here:

 systemjs.config.js#L5: Remove the unused function parameter "global".