Texturing Error Console Message

Thanks for the amazing plugin, I am getting this issue: Version: 3.4.1.
Python: Traceback (most recent call last):
File "C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\Apex-Legends-Auto-Shader-Blender-Addon-main\menu.py", line 24, in execute
methods[obj.type](obj, CURRENT_NODEADDER)
File "C:\Users\USER\AppData\Roaming\Blender Foundation\Blender\3.4\scripts\addons\Apex-Legends-Auto-Shader-Blender-Addon-main\utils.py", line 89, in shadeMesh
mesh_name = img_path.name[:img_path.name.rindex('_')]
ValueError: substring not found
bpy.context.space_data.shading.type = 'RENDERED'

I think it's most probably because your filename does not meet my requirement.
The addon require the texture name to be like this: <model_name>_<texture_name>.<file_type>
For example, this is the _image directory of the same model as yours (but probably exported way earlier).

Note that they always have some kind of model name at the front (e.g. bloodhound_mythic_v21_pilot_level02_body), followed by an underscore (_), and the texture name (e.g. albedoTexture).
If your exported filename looks like a string of random stuff, e.g. 0x4a85a742e8e5dceb.png, then update your legion version and try to export the texture again. Make sure that when you import rpak files, type "common.rpak" "root_lgnd_skins.rpak" manually, otherwise the files won't be properly named.

I have updated Legion+ and I did the manual typing of the .rpak, And I still get the "0x96dcd6a4ec60e661.png" file format.
Could you share your Legion+ settings for exporting?

If you really really can't make it export properly, you may try using archives on the web as a last resort...
ref. https://biast12.site/Apex_PC_Archive/Legends/Models/Bloodhound/bloodhound_v21_pilot_level02_w/_images/


task 13

Extract the data from the vajrang.org and print the results in the excel

@samkarne94
Task -13
Code verified.


chore: add gh action for dev container builds

Resolves #465
Description
Fix dev container build not working and add gh action to ensure the build always passes.

@tjjfvi still conflicted above having both "push" and "pull request" b/c it adds a lot of clutter

@ryanleecode Oh, I didn't realize that would make it run twice for PRs. Yeah, push: main makes sense in that case.


[Suggestion] Model Operation passed to WrapOperation with MethodHandle as well

An advantage of MethodHandle is that java compiler can generate any invocation method descriptor for invokeExact and invoke when they are surrounded by casts. This allows the call type (as from the NameAndType CP entry) to be preserved in the bytecode so it's easier for bytecode transfromation to substitute a call to MethodHandle (just call and then drop MH on stack), or the bytecode generator can pass actual MethodHandles loaded from constant pool, which is still more friendly to JIT compilation than Operation objects.
In contrast, the existing Operation takes a varargs array; though this looks simple in usage, it actually incurs extra costs in actual calls with varargs array allocations and type conversions, which is also complex and error-prone on the implementation side. https://github.com/LlamaLad7/MixinExtras/blob/b186f229cf76b69148d4e27902f9c4472cedb9af/src/main/java/com/llamalad7/mixinextras/utils/OperationUtils.java#L56

I have already confirmed that in hot code the JIT can see through many layers of wrappers and remove the boxing, arrays and lambdas entirely. As such, handles would offer no performance benefit and would be much less ergonomic to use.

Well, if you write if (1 == 2) or an empty loop, JIT profiling can see through it too as long as the bytecode paths aren't shared and your methods are below FreqInlineSize. (The operation object is constant from a callsite, which plays a role too) The actual benefits here is the simpler generation.

If handles are actually created, they can be created as easy as an ldc instruction.
If they serve as compiler hint shadows, the invokevirtual invoke/invokeExact calls in injectors are much easier to transform to actual method calls: the type is pretty close, everything on the stack can be passed to the call as-is; you just need to pop the handle from the stack after returning.
These operation calls' types can be checked at compile time instead of only at runtime, which is faster feedback for developers. (Note that the argument type are already specified in the wrap handler parameters, so passing them to the handle without casting would infer the correct parameter types for the java compiler)

Of course, since you still have to support the existing Operation interface, I would totally understand if you think the maintenance cost of the new feature outweighs the benefit.

The generation does not become simple because many wrapped things need their excess arguments bound to them, something LMF is specifically designed for that would need my own magic to perform with handles.
Moreover Operation is locked into the API and so any addition can only introduce more code.
I have no idea about the compile time checking you are referring to. MethodHandles are entirely untyped (including their return value which introduces another disadvantage compared to Operation).
MCDev already provides compile time checking of the types passed to the original.
The very minor JIT benefits are not really my job. If you're writing a performance mod then you can make your own judgement and take specific measures to keep the operation usages shallow by e.g. delegating to another method, thereby keeping the handler easy to inline.

All in all, I don't really see any benefits whatsoever, along with many drawbacks.


Add travis build

Would be nice to build and test this library on travis-ci.org

Agreed, I attempted this before, however the testing aspect created many issues due to the fact that I was working with Web Audio API and could not find any mocks and headless chrome (Pupeteer) wasn't out at that time.
If you want to take this on at all, I'd be happy to accept a PR. But as of now it's not a priority for me.

Currently only method is to run in browser.
Navigate to the test/test.html file and open it in your browser. The tests will be run on reload.

would http://mohayonao.github.io/web-audio-test-api/ be viable?

using a headless chrome on travis should work fine.

Agreed, headless chrome would be the best solution.


Remaining records should not be processed after catching ProducerFencedException in transactional non batch processing

Affects Version(s): 2.3.6.RELEASE (newest too)
🐞 Bug report
Context: non batch, transactional processing.
Scenario:

Listener one polls 10 records from topicparition topic-1 and process it one by one
For some reason listener two gets assigned partition topic 1 and fences listener one
Listener one wants to commit transaction on first processed record and gets ProducerFencedException, as we are still in the loop in KafkaMessageListenerContainer.invokeRecordListenerInTx we just log error and process another record which was polled - producer is created and fences back listener two - what is most important - if that succeed first record wont be reprocessed as we will commit new offset of second record
Listener two gets fenced and can do the same and fence back producer 1

I think we are missing break after logging ProducerFencedException in KafkaMessageListenerContainer.invokeRecordListenerInTx - probably should be done after finally is done.
Any ideas how can we avoid that other than setting max.poll.records to 1?

Ouch!
Thanks - 2.3.7 is due today so I will be sure to include a fix for this; I can't think of a work around.

@garyrussell One more thought:
This (skipping records) should work when polled records from one topic-partition but if I polled records from multiple topic partitions I should only omit records from topic partition I was fenced off but process other messages.
Example:

Listener fetched 3 records from topicpartition topic-1 and 2 records from topic-3
Producer is fenced when processing first records form topic-1 but we do not know if we are fenced from topic-3 (we do not have to be fenced)
We should omit all records from topicparition topic-1 but try to process those from topicpartition topic-3, if we just skip them and we are still assigned to topic-3 then it is possible we wont process those records again

@bartosz-stasikowski-projectdrgn I thought about that too but I don't believe it's an issue; when a rebalance occurs we will lose all assigned partitions, so it's correct to discard them all.
Of course, when we next poll, a new rebalance will be triggered but, as long as the other instances handle their current poll results in a timely fashion, there will be no more fencing.
Make sense?

@garyrussell
Yes, it makes sense. Rebalance will revoke all partitions, I forgot about it.
Good,  this makes it easier.


Which script is it that I need to fix the gun selection issue?

Hi, @karozaj You closed my other issue before I had a chance to ask you. Which script is it exactly and what line or lines do I need to fix the weapon selection bug? Also, would like to know when you get a chance what the copyright is for all models, textures, etc... EDIT: Also found another bug... if a cylinder lands on top of another cylinder then you shoot it with the rocket launcher, it keeps falling from the sky and hitting the ground as far as I am aware.
Much thanks, appreciation and PLEASE keep working on this!

Hello, sorry for not responding to your previous comment, I saw it but I just didn't have the time to respond.
To fix the weapon selection bug you need to ensure that is_being_pulled_out for the current weapon is set to true while the "pullout" animation is playing. This is the select_weapon function from the weapon_manager script.

Previously is_being_pulled_out was being set to true by the AnimationPlayer of the weapon at the beginning of the pullout animation, and that didn't always work, but when set from the select_weapon function it seems to be working correctly.
Also, make sure the weapons are set to be invisible by default.
By cylinder I guess you mean the enemy_test scene? I'm not really sure what the problem is but I guess it might have to do with the floor layers being set incorrectly. I haven't updated that scene in a while, since I didn't really use it anymore, but it seems to be working fine on my end, so please provide more information if possible.
I added a link to the list of third party assets currently used in the project to the readme file.
As for the assets made by me (currently  most of the models and textures), you can use them under the CC BY 4.0 license and you can use the code under the MIT license.

@karozaj it APPEARS ( I could be wrong ) but it APPEARS that when i go directly under a test enemy ( cylinder ) and blast it with the rocket launcher looking straight up, it goes flying up into the air, then back to the ground then here's the bug part. it keeps going back into the air and falling to the ground. If that helps I pray. Thank you for updating the copyright! Keep pushing this project! I absolutely adore this project!

I tried doing what you described but I couldn't replicate the issue, the cylinder falls to the ground like expected, so i don't know what's happening

I'll record a small video tomorrow for you demonstrating the bug.

@karozaj I'd like to solve this because I want to turn those into exploding barrels, some of which are wood, others are metal and where the pieces of the barrels fly off as pieces of the mesh that disappear. You know like in most FPS' ? HAPPY NEW YEAR TO YOU & YOURS BTW! <3

Thank you, happy new year to you too! If it helps, I did recently add a block that explodes when shot to the game (it basically just spawns a rocket projectile and explodes it instantly), but it sounds like you want it to be affected by physics? You could probably use the RigidBody3D node for that

@karozaj well if you can turn the rocket into a metal barrel then just made it break to pieces somehow, that would be PERFECT. we already have the barrel, we just have to texture it and break it when hit by a projectile that explodes!


To improve Contact section of index light

Is your feature request related to a problem? Please describe.
The contact us section of the file index light.html is needed to be improve by giving it proper css , I would like to work on this
Describe the solution you'd like

'Here's the problem of the section
Additional context
Please assign me this issue under hacktoberfest label I'm keen to solve the issue @akshitagupta15june

@ayan-joshi  hi ayan i would like to work on this issue ,please assign me this.

assign me the issue I'll surely improve the UI of the contact form.

please assign this issue to me

please assign this issue to me

It's already done and pr is merged as well , they will closed it in some days

I would like to work on this project. Please assign it to me!

please assign to me #gssoc24

@ayan-joshi hi ayan i would like to work on this issue ,please assign me this.

I would like to work ont his issue. I have previously worked on enhancing the UI experiences on many of my projects. So i think i would be a good candidate for this issue. #GSSOC24

@akshitagupta15june  I would like to work on this issue . I am SSoC contributor . Please assign me the same.

Hi @ayan-joshi, it looks like this issue has been solved with #1420. Please close this issue.


atlas migrate diff --env gorm - Error: sql/migrate: read migration directory state: sql/migrate: execute: executing statement

Error: sql/migrate: read migration directory state: sql/migrate: execute: executing statement "CREATE TABLE "customers" ("id" bigserial) from version "schema": pq: relation "customers" already exists
While I am running the command, getting the above error, I am unable to get the reason why it is raising.
atlas.hcl
variable "destructive" {
  type    = bool
  default = false
}

data "external_schema" "gorm" {

  program = [
    "go",
    "run",
    "main.go",
    "migrate",
    "-mod=mod",
    "./",
  ]
}

env "gorm" {
  src = data.external_schema.gorm.url
  url = "dburl"

  //to use versioned migration
  dev = "docker://postgres/15/sample"
  migration {
    dir = "file://migrations"
  }
  format {
    migrate {
      diff = "{{ sql . \"  \" }}"
    }
  }
  diff {
    skip {
      drop_schema = !var.destructive
      drop_table  = !var.destructive
    }
  }
}

Could you please let me know the reason

Hey! This looks like your migration directory does not contain correct files. An chance you can share it?

PFA for the migration directory
migrations.zip

The problem has been resolved, There is a problem while loading tables to Postgres db, We need to pass all the models as a parameter for the load() method.
Previously in the code, it accepted a single table struct as a parameter.

Thanks!


Update testing for new GHC-8.6.1 release

Decided to place in 0.2.0 release as it adds no new features and it was not yet on hackage.

Build error changed my mind, this can go in a minor patch later, once dependencies are fixed.


Add pin marks over image

It'd be great if one can insert a list of view over the image view (an experience similar to a map viewer).

@smarek if it's not difficult for you could you please give some sample code here to explain who exactly displayed matrix can use to render some pin view on top of PhotoView. If you you already implemented OnMatrixChangedListener please explain how exactly to use it for such task like pin marks over image.


failed at step 5 run node index.js

E:>node index.js
(node:22828) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use node --trace-warnings ... to show where the warning was created)
im having this problem while trying to set up. terminal gives me this error message when i run node index.js, can u help me how to solve this? thank you!

Which Node version are you using and have you installed Squad JS using yarn?

If the path above is what you are in are you in the correct folder as well?

Please don't delete the template - it's there to ensure all the relevant information needed to debug an issue is provided, which clearly hasn't happened here.


Tidy up OPLS SMARTS

Perhaps we should touch bases again soon. How are you guys indicating what atom the "atom type" refers to in your SMARTS patterns? Is it the one in square brackets? I'm just trying to wrap my mind around whether making a converter from this format to our format or vise versa would be trivial vs a pain in the neck.

Perhaps we should touch bases again soon.

Agreed. Sorry we fell out of contact!

How are you guys indicating what atom the "atom type" refers to in your SMARTS patterns? Is it the one in square brackets?

It's simply the first atom. Proper documentation is in the works!

I'm just trying to wrap my mind around whether making a converter from this format to our format or vise versa would be trivial vs a pain in the neck.

I've revisited this a few times in the past months and tinkered a bit with RDKit. One of the reasons we fell out of touch in the short term is that we have been unsuccessful in acquiring an OpenEye license (I believe we've applied 5 times now across 3 individuals). That being said, I am 100% certain that if we badgered a few more people that we could get the license but part of what we're trying to do is encourage people to properly disseminate forcefields in a more reproducible manner. To do this, we're trying to keep the barriers to entry as absolutely minimal as possible.
If you have any more thoughts on how to streamline the licensing issue, we'd love any more information and unless that can be significantly simplified, I'd like to talk more about our options with RDKit. If that is a feasible replacement, I do not think it should be too challenging to convert from a foyer force field to SMIRFF.

I just e-mailed; I think the OpenEye license issue can be greatly improved in all likelihood, and I sent some suggestions on how to do it.
We're also receptive to RDKit, but don't currently have developer time to move things over. If you had someone who could help us with that, we'd be willing to move that direction.


Fix SQL Expression parsing errors with GDAL 2.2+

Since GDAL 2.2 layer names loaded from geojson datasources using OGR are no longer always 'OGRGeoJSON'. Since they can contain characters that can mess with the SQL string to apply the where-clause they need to be quoted.

It would be fantastic if we had tests to cover this behaviour, would you be able to look into this?
Current tests are here: mapproxy/test/unit/test_ogr_reader.py. Currently the test loads a Shapefile, a new test could load a GeoJSON with a filename that causes the current implementation to fail?

It would be fantastic if we had tests to cover this behaviour, would you be able to look into this?
Current tests are here: mapproxy/test/unit/test_ogr_reader.py. Currently the test loads a Shapefile, a new test could load a GeoJSON with a filename that causes the current implementation to fail?

I added a geojson testfile and updated the unit test. I don't know much about unit tests in python though, so please let me know if this is done well enough.
Also this could be tested and reproduced a lot easier with just renaming the existing shapefile to contain a character that is not valid in SQL string like polygons-germany.shp. This would keep the tests and the test data smaller but would not test the OGRReader with geojson files. Let me know if this approach suits you better.

I added a geojson testfile and updated the unit test. I don't know much about unit tests in python though, so please let me know if this is done well enough.
Also this could be tested and reproduced a lot easier with just renaming the existing shapefile to contain a character that is not valid in SQL string like polygons-germany.shp. This would keep the tests and the test data smaller but would not test the OGRReader with geojson files. Let me know if this approach suits you better.

Anything still missing for this to get released?

@walkermatt Bump for visibility. We really need this merged. Is anything missing still?

@smomapz if you could update the GeoJSON test so that the filename causes the test to fail prior to your quoting change I think this is good to go.

@walkermatt The test is already failing prior to my changes. The filename is not relevant when the geojson file provides a layer name. Here with "polygons-germany" the hyphen is causing the issue in the old implementation.

@smomapz thanks, I was able to reproduce the issue and confirm the fix this afternoon. I've squashed your commits and merged :+1:


Create navigational popup

Hitting a menu button (Esc?) in most places should bring up a navigational popup with:

Settings visible
(from story mode) Side Button: Save + Quit (To Main Menu)
(from other menus) Side Button: Quit (To Main Menu)
(from main menu) Side Button: Quit (Exit game)
Side Button: Continue

Hitting a menu button when a puzzle is active should bring up an abridged navigational popup with:

Button: Continue
Button: Retry
Button: Quit (To game mode)

Hitting a menu from the puzzle screen when the puzzle is inactive should bring up the usual window, with settings/quit.
To accomplish this, we might want to have something like a bread crumb tree of places to quit to.

Main Menu

Practice Mode

Marathon Scenario

"Continue" means closing the navigational popup. "Quit" means going up one bread crumb level.

The breadcrumb navigation has been implemented in #263, but the popup does not exist.

I'm having second thoughts on this, as "Esc" is essentially the 'back' button. In simple menus, the back button should go back. In gameplay situations where this would be destructive, it should bring up a pause menu.
Esc results in popup:

Overworld
Puzzle mode
Main Menu
Splash Screen

Esc goes back:

Everywhere else (but, settings button still displays popup)

Popup:

Everywhere else (options to quit and exit)
Puzzle mode (options to end)
Main menu (option to exit game)
Splash Screen (option to exit game)


WIP: Emit ModRM Correctly When Register R12 Is Used

When register R12 is used in an instruction requiring a ModRM byte, the semantics and encoding of the instruction are unique. The emit_modrm_and_displacement function did not handle this uniqueness properly. This patch modifies the function to handle the use of R12 correctly.
Fixes #529

coverage: 80.298% (-0.005%) from 80.303%
when pulling e307c30bea2adb39399d54a3ebb8ed6fe67e8d9b on hawkinsw:r12_fix
into 19cd22c6fbe2878898717308d5792d49bff34d3e on iovisor:main.

Hmm, I still found my prog crashed. After a short dig:
	r7 = r1
	r8 = r1
	r4 = *(u64 *)(r8 + 0)
	r3 = *(u64 *)(r7 + 0)
	r0 = r3
	exit

the llvm-objdump:
bpf.o:	file format elf64-bpf

Disassembly of section .text:

0000000000000000 <func>:
       0:	bf 17 00 00 00 00 00 00	r7 = r1
       1:	bf 18 00 00 00 00 00 00	r8 = r1
       2:	79 84 00 00 00 00 00 00	r4 = *(u64 *)(r8 + 0)
       3:	79 73 00 00 00 00 00 00	r3 = *(u64 *)(r7 + 0)
       4:	bf 30 00 00 00 00 00 00	r0 = r3
       5:	95 00 00 00 00 00 00 00	exit

and jited code:
   0x7f388a345000:      push   %rbp
   0x7f388a345001:      push   %rbx
   0x7f388a345002:      push   %r12
   0x7f388a345004:      push   %r13
   0x7f388a345006:      push   %r14
   0x7f388a345008:      push   %r15
   0x7f388a34500a:      mov    %rdi,%r11
   0x7f388a34500d:      sub    $0x8,%rsp
   0x7f388a345014:      mov    %rsp,%rbp
   0x7f388a345017:      mov    %rsp,%r15
   0x7f388a34501a:      sub    $0x200,%rsp
   0x7f388a345021:      callq  0x7f388a34502b
   0x7f388a345026:      jmpq   0x7f388a345053
   0x7f388a34502b:      sub    $0x8,%rsp
   0x7f388a345032:      movq   $0x20,(%rsp)
   0x7f388a34503a:      mov    %rdi,%r12
   0x7f388a34503d:      mov    %rdi,%r13
=> 0x7f388a345040:      mov    0x24548b49(%rip),%r10        # 0x7f38ae88db90
   0x7f388a345047:      add    %cl,-0x77(%rax)
   0x7f388a34504a:      rorb   -0x7f(%rax)
   0x7f388a34504d:      (bad)
   0x7f388a34504e:      or     %al,(%rax)
   0x7f388a345050:      add    %al,(%rax)
   0x7f388a345052:      retq
   0x7f388a345053:      mov    %rbp,%rsp
   0x7f388a345056:      add    $0x8,%rsp
   0x7f388a34505d:      pop    %r15
   0x7f388a34505f:      pop    %r14
   0x7f388a345061:      pop    %r13
   0x7f388a345063:      pop    %r12
   0x7f388a345065:      pop    %rbx
   0x7f388a345066:      pop    %rbp
   0x7f388a345067:      retq
   0x7f388a345068:      callq  0x7f388a345074
   0x7f388a34506d:      pause
   0x7f388a34506f:      jmpq   0x7f388a345000
   0x7f388a345074:      mov    %rax,(%rsp)
   0x7f388a345078:      retq

I reverted this commit and r8 is ok. It seems r8 is the regression of this commit.

Hmm, I still found my prog crashed. After a short dig:
	r8 = r1
	r0 = *(u64 *)(r8 + 0)
	exit

the llvm-objdump:
bpf.o:	file format elf64-bpf

Disassembly of section .text:

0000000000000000 <func>:
       0:	bf 18 00 00 00 00 00 00	r8 = r1
       1:	79 80 00 00 00 00 00 00	r0 = *(u64 *)(r8 + 0)
       2:	95 00 00 00 00 00 00 00	exit

and jited code:
   0x7fdcde481000:      push   %rbp
   0x7fdcde481001:      push   %rbx
   0x7fdcde481002:      push   %r12
   0x7fdcde481004:      push   %r13
   0x7fdcde481006:      push   %r14
   0x7fdcde481008:      push   %r15
   0x7fdcde48100a:      mov    %rdi,%r11
   0x7fdcde48100d:      sub    $0x8,%rsp
   0x7fdcde481014:      mov    %rsp,%rbp
   0x7fdcde481017:      mov    %rsp,%r15
   0x7fdcde48101a:      sub    $0x200,%rsp
   0x7fdcde481021:      callq  0x7fdcde48102b
   0x7fdcde481026:      jmpq   0x7fdcde481048
   0x7fdcde48102b:      sub    $0x8,%rsp
   0x7fdcde481032:      movq   $0x20,(%rsp)
   0x7fdcde48103a:      mov    %rdi,%r13
=> 0x7fdcde48103d:      mov    0x8c48148(%rip),%rax        # 0x7fdce70c918c
   0x7fdcde481044:      add    %al,(%rax)
   0x7fdcde481046:      add    %al,%bl
   0x7fdcde481048:      mov    %rbp,%rsp
   0x7fdcde48104b:      add    $0x8,%rsp
   0x7fdcde481052:      pop    %r15
   0x7fdcde481054:      pop    %r14
   0x7fdcde481056:      pop    %r13
   0x7fdcde481058:      pop    %r12
   0x7fdcde48105a:      pop    %rbx
   0x7fdcde48105b:      pop    %rbp
   0x7fdcde48105c:      retq
   0x7fdcde48105d:      callq  0x7fdcde481069
   0x7fdcde481062:      pause
   0x7fdcde481064:      jmpq   0x7fdcde481000
   0x7fdcde481069:      mov    %rax,(%rsp)
   0x7fdcde48106d:      retq

It seems this is time to r8....

@dtcccc Thank you! I think that the issue here is slightly different. We have a special case for a 0 offset and I bet that is emitting incorrect code. I am checking now and then I will send out another PR.
Thank you for the feedback!
Will

@dtcccc I think that the latest version should resolve your issue! Give it a test, if you can!!

@dtcccc I think that the latest version should resolve your issue! Give it a test, if you can!!

It works for me now. Thanks for your work!

@dtcccc I think that the latest version should resolve your issue! Give it a test, if you can!!

It works for me now. Thanks for your work!

Great news! I was waiting all day to hear a confirmation! Thank you!

Great news! I was waiting all day to hear a confirmation! Thank you!

I'm sleeping at that time :-)

Great news! I was waiting all day to hear a confirmation! Thank you!

I was sleeping at that time :-)

There's absolutely no excuse for you sleeping while I was waiting :-) Thank you, again, for reporting the issue and being a great user.


What is the maximum columns and rows?

I have around 50 columns and 10 thousands rows for one sheet, and i export anohter sheet next to it, but the another sheet is showing incorrectly, like some data are missing or there is no data etc...
here is my code,
`
$calllogsdata = Calllog::get()->toArray();
    $jobseekersdata = Jobseeker::get()->toArray();

    return Excel::create('jobseekers_excel', function($excel) use ($calllogsdata,$jobseekersdata) {

        $excel->sheet('calllogs',function($sheet) use ($calllogsdata){
            $sheet->fromArray($calllogsdata);
        });
        $excel->sheet('js_data',function($sheet) use ($jobseekersdata){
            $sheet->fromArray($jobseekersdata);
        });
    })->download($type);`

Excel specifications and limits states that the limit is 1,048,576 rows by 16,384 columns
so maybe the issue comes from a memory limit set too low
please run phpinfo() and check memory_limit in the core section, and adjust it like so:
ini_set('memory_limit', '512M');


Test: Migrate board_keys in pull_jobs tests to dev-demo

The tests passed for all connectors and actions.
There was a bug in Breezyhr job["metadatas"] that caused an indexing error , it was corrected

@CorentinDuchene  you can also close this PR without merging it, the changes made are already merged and enhanced on architecture/schemas_pipeline branch


snap: Electron not starting up on Linux

My Setup

Operating System: Debian testing / Ubuntu 19.10

App Version: 3.0.0-develop 2020-03-13

Installation type: snap

[x] I have tested with the latest version

[x] I can simulate the issue easily

Description
After switching in snap from the stable to the beta channel, the application is no longer starting.
You can see the Electron processes in the process viewer, but no UI appears at all.
I haven't tested with the normal packages yet. Let me know if I can test / do anything. I'm not sure how to debug Electron...

Please test if the latest release did solve this. If not please reopen the issue or create a new one and tell us. I will be closing this one for now.
Thank you!


Use DI/factories for WF identity, extensions and WF input arguments

Remove CreateExtensions(), use factory as parameter in ctor.
Though there can be situations, where grain should add an extension for some custom activity, in this case it must use it's extension factory wrapper.

Not only extensions, but WF identity and input arguments should be optionally dependent on grain state also.

Only WF definition identity and WF definition factories remained ctor injected, Extensions, OnStart (input args) and OnCompleted (output args) got property injection. These were virtual methods, but with property injection additional extensions can be added at run time, and OnStart and OnCompleted "event" handlers can be set with composition and not inheritance (this will be useful for "Invoke" like support to run computational workflows).


FIX Web Crawler doesn't include search params in URLs

There is an issue with Puppeter, Playwright and Cherioo Web Scrappers, they doesn't include search params from URLs.
E. g. I'd like to scrap URL https://wiki.minthcm.org/index.php?title=Process:Running_on_Docker and in te result this URL which is scrapped is truncated to https://wiki.minthcm.org/index.php. Current implemetation truncates all the parameters after "?".
Provided fix will cover this issue.
Here is the flow I was using

awesome thanks @ahmosman !
for future reference:
const urlObj = new URL('https://example.org/abc?123')
urlObj.hostname = example.org
urlObj.pathname= /abc
urlObj.search= ?123


Clover Bridge

Grant Application Checklist

[x] The application-template.md has been copied, renamed ( "project_name.md") and updated.
[x] A BTC or Ethereum (DAI) address for the payment of the milestones is provided inside the application.
[x] The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
[x] The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants.
[x] The initial PR contains only one commit (squash if needed before submitting your PR).
[x] The grant will only be announced once we've successfully delivered the first milestone.

Hi @brqgoo, thank you for your submission and apologies for the late reply.
I am happy to share this application with the rest of the team, except that we recently changed the policy to grant applications having to be denominated in USD (due to the volatility of other currencies). It can still be paid out in DAI or BTC. Could you change the prices to USD?

Hi @brqgoo, thank you for your submission and apologies for the late reply.
I am happy to share this application with the rest of the team, except that we recently changed the policy to grant applications having to be denominated in USD (due to the volatility of other currencies). It can still be paid out in DAI or BTC. Could you change the prices to USD?

Hi @semuelle made the respective changes. Looking forward to your feedback.

Thanks for the follow-up. Two more notes:

The grants program doesn't fund Solidity smart contract development.
Can you be more specific about the deliverables? Start documenting, for example, is too vague.

Thanks for the follow-up. Two more notes:

The grants program doesn't fund Solidity smart contract development.
Can you be more specific about the deliverables? Start documenting, for example, is too vague.

Hi @semuelle contracts were needed for peg-in and peg-out flows, however are a small part of overall development. Updated the application, thanks.

Thanks for the update. I’m happy to go ahead with the application as it is now and will share it with the rest of the team.

Thanks for the application. However, given that we already have two big ethereum bridges in the ecosystem under development (ChainBridge,  polkadot-ethereum) the grants committee previously was rather reluctant to fund another bridge. Could you point out what’s the advantage of your solution compared to the existing solutions? Additionally all your deliveries are currently in go. Don’t you need to store anything on-chain?

Hi @Noc2  thanks for the reply.
Today’s bridges operate under a trusted federation model. ChainBridge is for example, governed by a trusted set of off-chain relayers who await finality, submit events to the other chain and vote on submissions to reach acceptance triggering the appropriate handler.
Snowfork is on the other hand, allows Ethereum to read state from Polkadot which is a bit more complex, as there are enormous compute/gas cost challenges in doing this.
The more signatories a bridge accommodates the more decentralized the bridge becomes, however this is also proportional to gas consumption since ecrecover consumes 3000 gas per signatory. Bitcoin script is on the other hand is limited to 15 signatories in a multisig operation and is also expensive in witness units.
Clover Bridge proposes a solution to the pain point of decentralization cost of how a proper cross-chain communication should be operating under scarce resources. We’re proposing a Schnorr-compatible threshold signatory solution which can provide a high level of decentralization by accommodating up to hypothetically unlimited number of signatories while massively reducing the verification cost. With Clover Bridge, the entire bridge operation is compressed into one aggregated public key which can be verified with one custom signature check operation that only consumes 85000 gas in Ethereum VM and 291 weight units in Bitcoin script (with the upcoming BIP-340 upgrade).
We have contract implementations for peg-in/peg-out flows that are separated from the application as W3F Grants Program does cover Solidity contract development.

Thanks for the detailed reply and all the effort you put into the application. However, I’m closing the application for now, since you are currently actively raising money for exactly this implementation, see https://coinlist.co/clover. See our guidelines: “We do not award grants for projects that have been the object of a successful token sale.”
Please integrate this the next time under additional information section In case the toke sale fails, feel free to reapply/reopen the application or  in the meantime feel free to send us an application for another project.

Btw. you probably should remove Polkadot from Strategic Partners. Not sure how you can partner with a decentralized network ;-)

@brqgoo  I also like to point out, that you are still use acala’s code without proper attribution, even after we notified you about it, see

https://github.com/clover-network/clover/blob/bcd6a74a8fe422c3a056d29e348183103448301e/modules/evm-accounts/src/lib.rs
https://github.com/AcalaNetwork/Acala/blob/4b74d6c622610a4a0a873941b3f1e2d4963f79eb/modules/evm-accounts/src/lib.rs

Based on this, I’m personally highly likely not going to support any future grant applications of your team.

that's weird

So far, no founder of this project has come out to speak, or even violated the contract of community members. From a personal point of view, I think clover is more like a scammer and a thief.


Enabling KEM and QSIGNATURE of choice in PQCrypto-VPN

The "PQCrypto-VPN/openvpn/config" folder contains examples on how to enable any available QCipherSuite:
How can I specify what KEM or QSIGNATURE PQCrypto-VPN should use? Thanks.
EDIT 1: I just realized that KEMs are part of the Cipher Suite, but they are coded as KEX, or more precisely as "OQSKEX" which is slightly confusing. "OQSKEM" would be better. Any notes on how to use the QSIGNATURE in the vpn would still be valuable though.
Here for reference, the available traditional and quantum cipher suites.:
 * SSL/TLS Cipher suite name translation table
 */
static const tls_cipher_name_pair tls_cipher_name_translation_table[] = {
    {"ADH-SEED-SHA", "TLS-DH-anon-WITH-SEED-CBC-SHA"},
    {"AES128-GCM-SHA256", "TLS-RSA-WITH-AES-128-GCM-SHA256"},
    {"AES128-SHA256", "TLS-RSA-WITH-AES-128-CBC-SHA256"},
    {"AES128-SHA", "TLS-RSA-WITH-AES-128-CBC-SHA"},
    {"AES256-GCM-SHA384", "TLS-RSA-WITH-AES-256-GCM-SHA384"},
    {"AES256-SHA256", "TLS-RSA-WITH-AES-256-CBC-SHA256"},
    {"AES256-SHA", "TLS-RSA-WITH-AES-256-CBC-SHA"},
    {"CAMELLIA128-SHA256", "TLS-RSA-WITH-CAMELLIA-128-CBC-SHA256"},
    {"CAMELLIA128-SHA", "TLS-RSA-WITH-CAMELLIA-128-CBC-SHA"},
    {"CAMELLIA256-SHA256", "TLS-RSA-WITH-CAMELLIA-256-CBC-SHA256"},
    {"CAMELLIA256-SHA", "TLS-RSA-WITH-CAMELLIA-256-CBC-SHA"},
    {"DES-CBC3-SHA", "TLS-RSA-WITH-3DES-EDE-CBC-SHA"},
    {"DES-CBC-SHA", "TLS-RSA-WITH-DES-CBC-SHA"},
    {"DH-DSS-SEED-SHA", "TLS-DH-DSS-WITH-SEED-CBC-SHA"},
    {"DHE-DSS-AES128-GCM-SHA256", "TLS-DHE-DSS-WITH-AES-128-GCM-SHA256"},
    {"DHE-DSS-AES128-SHA256", "TLS-DHE-DSS-WITH-AES-128-CBC-SHA256"},
    {"DHE-DSS-AES128-SHA", "TLS-DHE-DSS-WITH-AES-128-CBC-SHA"},
    {"DHE-DSS-AES256-GCM-SHA384", "TLS-DHE-DSS-WITH-AES-256-GCM-SHA384"},
    {"DHE-DSS-AES256-SHA256", "TLS-DHE-DSS-WITH-AES-256-CBC-SHA256"},
    {"DHE-DSS-AES256-SHA", "TLS-DHE-DSS-WITH-AES-256-CBC-SHA"},
    {"DHE-DSS-CAMELLIA128-SHA256", "TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA256"},
    {"DHE-DSS-CAMELLIA128-SHA", "TLS-DHE-DSS-WITH-CAMELLIA-128-CBC-SHA"},
    {"DHE-DSS-CAMELLIA256-SHA256", "TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA256"},
    {"DHE-DSS-CAMELLIA256-SHA", "TLS-DHE-DSS-WITH-CAMELLIA-256-CBC-SHA"},
    {"DHE-DSS-SEED-SHA", "TLS-DHE-DSS-WITH-SEED-CBC-SHA"},
    {"DHE-RSA-AES128-GCM-SHA256", "TLS-DHE-RSA-WITH-AES-128-GCM-SHA256"},
    {"DHE-RSA-AES128-SHA256", "TLS-DHE-RSA-WITH-AES-128-CBC-SHA256"},
    {"DHE-RSA-AES128-SHA", "TLS-DHE-RSA-WITH-AES-128-CBC-SHA"},
    {"DHE-RSA-AES256-GCM-SHA384", "TLS-DHE-RSA-WITH-AES-256-GCM-SHA384"},
    {"DHE-RSA-AES256-SHA256", "TLS-DHE-RSA-WITH-AES-256-CBC-SHA256"},
    {"DHE-RSA-AES256-SHA", "TLS-DHE-RSA-WITH-AES-256-CBC-SHA"},
    {"DHE-RSA-CAMELLIA128-SHA256", "TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA256"},
    {"DHE-RSA-CAMELLIA128-SHA", "TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA"},
    {"DHE-RSA-CAMELLIA256-SHA256", "TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA256"},
    {"DHE-RSA-CAMELLIA256-SHA", "TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA"},
    {"DHE-RSA-CHACHA20-POLY1305", "TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256"},
    {"DHE-RSA-SEED-SHA", "TLS-DHE-RSA-WITH-SEED-CBC-SHA"},
    {"DH-RSA-SEED-SHA", "TLS-DH-RSA-WITH-SEED-CBC-SHA"},
    {"ECDH-ECDSA-AES128-GCM-SHA256", "TLS-ECDH-ECDSA-WITH-AES-128-GCM-SHA256"},
    {"ECDH-ECDSA-AES128-SHA256", "TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA256"},
    {"ECDH-ECDSA-AES128-SHA", "TLS-ECDH-ECDSA-WITH-AES-128-CBC-SHA"},
    {"ECDH-ECDSA-AES256-GCM-SHA384", "TLS-ECDH-ECDSA-WITH-AES-256-GCM-SHA384"},
    {"ECDH-ECDSA-AES256-SHA256", "TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA256"},
    {"ECDH-ECDSA-AES256-SHA384", "TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA384"},
    {"ECDH-ECDSA-AES256-SHA", "TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA"},
    {"ECDH-ECDSA-CAMELLIA128-SHA256", "TLS-ECDH-ECDSA-WITH-CAMELLIA-128-CBC-SHA256"},
    {"ECDH-ECDSA-CAMELLIA128-SHA", "TLS-ECDH-ECDSA-WITH-CAMELLIA-128-CBC-SHA"},
    {"ECDH-ECDSA-CAMELLIA256-SHA256", "TLS-ECDH-ECDSA-WITH-CAMELLIA-256-CBC-SHA256"},
    {"ECDH-ECDSA-CAMELLIA256-SHA", "TLS-ECDH-ECDSA-WITH-CAMELLIA-256-CBC-SHA"},
    {"ECDH-ECDSA-DES-CBC3-SHA", "TLS-ECDH-ECDSA-WITH-3DES-EDE-CBC-SHA"},
    {"ECDH-ECDSA-DES-CBC-SHA", "TLS-ECDH-ECDSA-WITH-DES-CBC-SHA"},
    {"ECDH-ECDSA-RC4-SHA", "TLS-ECDH-ECDSA-WITH-RC4-128-SHA"},
    {"ECDHE-ECDSA-AES128-GCM-SHA256", "TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256"},
    {"ECDHE-ECDSA-AES128-SHA256", "TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA256"},
    {"ECDHE-ECDSA-AES128-SHA384", "TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA384"},
    {"ECDHE-ECDSA-AES128-SHA", "TLS-ECDHE-ECDSA-WITH-AES-128-CBC-SHA"},
    {"ECDHE-ECDSA-AES256-GCM-SHA384", "TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384"},
    {"ECDHE-ECDSA-AES256-SHA256", "TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA256"},
    {"ECDHE-ECDSA-AES256-SHA384", "TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384"},
    {"ECDHE-ECDSA-AES256-SHA", "TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA"},
    {"ECDHE-ECDSA-CAMELLIA128-SHA256", "TLS-ECDHE-ECDSA-WITH-CAMELLIA-128-CBC-SHA256"},
    {"ECDHE-ECDSA-CAMELLIA128-SHA", "TLS-ECDHE-ECDSA-WITH-CAMELLIA-128-CBC-SHA"},
    {"ECDHE-ECDSA-CAMELLIA256-SHA256", "TLS-ECDHE-ECDSA-WITH-CAMELLIA-256-CBC-SHA256"},
    {"ECDHE-ECDSA-CAMELLIA256-SHA", "TLS-ECDHE-ECDSA-WITH-CAMELLIA-256-CBC-SHA"},
    {"ECDHE-ECDSA-CHACHA20-POLY1305", "TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256"},
    {"ECDHE-ECDSA-DES-CBC3-SHA", "TLS-ECDHE-ECDSA-WITH-3DES-EDE-CBC-SHA"},
    {"ECDHE-ECDSA-DES-CBC-SHA", "TLS-ECDHE-ECDSA-WITH-DES-CBC-SHA"},
    {"ECDHE-ECDSA-RC4-SHA", "TLS-ECDHE-ECDSA-WITH-RC4-128-SHA"},
    {"ECDHE-RSA-AES128-GCM-SHA256", "TLS-ECDHE-RSA-WITH-AES-128-GCM-SHA256"},
    {"ECDHE-RSA-AES128-SHA256", "TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA256"},
    {"ECDHE-RSA-AES128-SHA384", "TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA384"},
    {"ECDHE-RSA-AES128-SHA", "TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA"},
    {"ECDHE-RSA-AES256-GCM-SHA384", "TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384"},
    {"ECDHE-RSA-AES256-SHA256", "TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA256"},
    {"ECDHE-RSA-AES256-SHA384", "TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384"},
    {"ECDHE-RSA-AES256-SHA", "TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA"},
    {"ECDHE-RSA-CAMELLIA128-SHA256", "TLS-ECDHE-RSA-WITH-CAMELLIA-128-CBC-SHA256"},
    {"ECDHE-RSA-CAMELLIA128-SHA", "TLS-ECDHE-RSA-WITH-CAMELLIA-128-CBC-SHA"},
    {"ECDHE-RSA-CAMELLIA256-SHA256", "TLS-ECDHE-RSA-WITH-CAMELLIA-256-CBC-SHA256"},
    {"ECDHE-RSA-CAMELLIA256-SHA", "TLS-ECDHE-RSA-WITH-CAMELLIA-256-CBC-SHA"},
    {"ECDHE-RSA-CHACHA20-POLY1305", "TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256"},
    {"ECDHE-RSA-DES-CBC3-SHA", "TLS-ECDHE-RSA-WITH-3DES-EDE-CBC-SHA"},
    {"ECDHE-RSA-DES-CBC-SHA", "TLS-ECDHE-RSA-WITH-DES-CBC-SHA"},
    {"ECDHE-RSA-RC4-SHA", "TLS-ECDHE-RSA-WITH-RC4-128-SHA"},
    {"ECDH-RSA-AES128-GCM-SHA256", "TLS-ECDH-RSA-WITH-AES-128-GCM-SHA256"},
    {"ECDH-RSA-AES128-SHA256", "TLS-ECDH-RSA-WITH-AES-128-CBC-SHA256"},
    {"ECDH-RSA-AES128-SHA384", "TLS-ECDH-RSA-WITH-AES-128-CBC-SHA384"},
    {"ECDH-RSA-AES128-SHA", "TLS-ECDH-RSA-WITH-AES-128-CBC-SHA"},
    {"ECDH-RSA-AES256-GCM-SHA384", "TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384"},
    {"ECDH-RSA-AES256-SHA256", "TLS-ECDH-RSA-WITH-AES-256-CBC-SHA256"},
    {"ECDH-RSA-AES256-SHA384", "TLS-ECDH-RSA-WITH-AES-256-CBC-SHA384"},
    {"ECDH-RSA-AES256-SHA", "TLS-ECDH-RSA-WITH-AES-256-CBC-SHA"},
    {"ECDH-RSA-CAMELLIA128-SHA256", "TLS-ECDH-RSA-WITH-CAMELLIA-128-CBC-SHA256"},
    {"ECDH-RSA-CAMELLIA128-SHA", "TLS-ECDH-RSA-WITH-CAMELLIA-128-CBC-SHA"},
    {"ECDH-RSA-CAMELLIA256-SHA256", "TLS-ECDH-RSA-WITH-CAMELLIA-256-CBC-SHA256"},
    {"ECDH-RSA-CAMELLIA256-SHA", "TLS-ECDH-RSA-WITH-CAMELLIA-256-CBC-SHA"},
    {"ECDH-RSA-DES-CBC3-SHA", "TLS-ECDH-RSA-WITH-3DES-EDE-CBC-SHA"},
    {"ECDH-RSA-DES-CBC-SHA", "TLS-ECDH-RSA-WITH-DES-CBC-SHA"},
    {"ECDH-RSA-RC4-SHA", "TLS-ECDH-RSA-WITH-RC4-128-SHA"},
    {"EDH-DSS-DES-CBC3-SHA", "TLS-DHE-DSS-WITH-3DES-EDE-CBC-SHA"},
    {"EDH-DSS-DES-CBC-SHA", "TLS-DHE-DSS-WITH-DES-CBC-SHA"},
    {"EDH-RSA-DES-CBC3-SHA", "TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA"},
    {"EDH-RSA-DES-CBC-SHA", "TLS-DHE-RSA-WITH-DES-CBC-SHA"},
    {"EXP-DES-CBC-SHA", "TLS-RSA-EXPORT-WITH-DES40-CBC-SHA"},
    {"EXP-EDH-DSS-DES-CBC-SHA", "TLS-DH-DSS-EXPORT-WITH-DES40-CBC-SHA"},
    {"EXP-EDH-RSA-DES-CBC-SHA", "TLS-DH-RSA-EXPORT-WITH-DES40-CBC-SHA"},
    {"EXP-RC2-CBC-MD5", "TLS-RSA-EXPORT-WITH-RC2-CBC-40-MD5"},
    {"EXP-RC4-MD5", "TLS-RSA-EXPORT-WITH-RC4-40-MD5"},
    {"NULL-MD5", "TLS-RSA-WITH-NULL-MD5"},
    {"NULL-SHA256", "TLS-RSA-WITH-NULL-SHA256"},
    {"NULL-SHA", "TLS-RSA-WITH-NULL-SHA"},
    {"PSK-3DES-EDE-CBC-SHA", "TLS-PSK-WITH-3DES-EDE-CBC-SHA"},
    {"PSK-AES128-CBC-SHA", "TLS-PSK-WITH-AES-128-CBC-SHA"},
    {"PSK-AES256-CBC-SHA", "TLS-PSK-WITH-AES-256-CBC-SHA"},
    {"PSK-RC4-SHA", "TLS-PSK-WITH-RC4-128-SHA"},
    {"RC4-MD5", "TLS-RSA-WITH-RC4-128-MD5"},
    {"RC4-SHA", "TLS-RSA-WITH-RC4-128-SHA"},
    {"SEED-SHA", "TLS-RSA-WITH-SEED-CBC-SHA"},
    {"SRP-DSS-3DES-EDE-CBC-SHA", "TLS-SRP-SHA-DSS-WITH-3DES-EDE-CBC-SHA"},
    {"SRP-DSS-AES-128-CBC-SHA", "TLS-SRP-SHA-DSS-WITH-AES-128-CBC-SHA"},
    {"SRP-DSS-AES-256-CBC-SHA", "TLS-SRP-SHA-DSS-WITH-AES-256-CBC-SHA"},
    {"SRP-RSA-3DES-EDE-CBC-SHA", "TLS-SRP-SHA-RSA-WITH-3DES-EDE-CBC-SHA"},
    {"SRP-RSA-AES-128-CBC-SHA", "TLS-SRP-SHA-RSA-WITH-AES-128-CBC-SHA"},
    {"SRP-RSA-AES-256-CBC-SHA", "TLS-SRP-SHA-RSA-WITH-AES-256-CBC-SHA"},
    /*
     * Non-standard, post-quantum cipher suites, provided by the OQS fork of OpenSSL.
     * https://github.com/open-quantum-safe/openssl
     */
    {"OQSKEX-SIDH-MSR-ECDHE-RSA-AES256-GCM-SHA384", "OQSKEX-SIDH-MSR-ECDHE-RSA-AES256-GCM-SHA384"},
    {"OQSKEX-LWE-FRODO-RECOMMENDED-ECDHE-RSA-AES256-GCM-SHA384", "OQSKEX-LWE-FRODO-RECOMMENDED-ECDHE-RSA-AES256-GCM-SHA384"},
    {"OQSKEX-RLWE-BCNS15-ECDHE-RSA-AES256-GCM-SHA384", "OQSKEX-RLWE-BCNS15-ECDHE-RSA-AES256-GCM-SHA384"},
    {"OQSKEX-RLWE-NEWHOPE-ECDHE-RSA-AES256-GCM-SHA384", "OQSKEX-RLWE-NEWHOPE-ECDHE-RSA-AES256-GCM-SHA384"},
    {"OQSKEX-RLWE-MSRLN16-ECDHE-RSA-AES256-GCM-SHA384", "OQSKEX-RLWE-MSRLN16-ECDHE-RSA-AES256-GCM-SHA384"},
    {"OQSKEX-SIDH-IQC-REF-ECDHE-RSA-WITH-AES-256-GCM-SHA384", "OQSKEX-SIDH-IQC-REF-ECDHE-RSA-WITH-AES-256-GCM-SHA384"},
    {"OQSKEX-CODE-MCBITS-ECDHE-RSA-WITH-AES-256-GCM-SHA384", "OQSKEX-CODE-MCBITS-ECDHE-RSA-WITH-AES-256-GCM-SHA384"},
    {"OQSKEX-NTRU-ECDHE-RSA-WITH-AES-256-GCM-SHA384", "OQSKEX-NTRU-ECDHE-RSA-WITH-AES-256-GCM-SHA384"},
    {"OQSKEX-MLWE-KYBER-ECDHE-RSA-WITH-AES-256-GCM-SHA384", "OQSKEX-MLWE-KYBER-ECDHE-RSA-WITH-AES-256-GCM-SHA384"},
    /* same list as above, but with ECDSA instead of RSA */
    {"OQSKEX-SIDH-MSR-ECDHE-ECDSA-AES256-GCM-SHA384", "OQSKEX-SIDH-MSR-ECDHE-ECDSA-AES256-GCM-SHA384"},
    {"OQSKEX-LWE-FRODO-RECOMMENDED-ECDHE-ECDSA-AES256-GCM-SHA384", "OQSKEX-LWE-FRODO-RECOMMENDED-ECDHE-ECDSA-AES256-GCM-SHA384"},
    {"OQSKEX-RLWE-BCNS15-ECDHE-ECDSA-AES256-GCM-SHA384", "OQSKEX-RLWE-BCNS15-ECDHE-ECDSA-AES256-GCM-SHA384"},
    {"OQSKEX-RLWE-NEWHOPE-ECDHE-ECDSA-AES256-GCM-SHA384", "OQSKEX-RLWE-NEWHOPE-ECDHE-ECDSA-AES256-GCM-SHA384"},
    {"OQSKEX-RLWE-MSRLN16-ECDHE-ECDSA-AES256-GCM-SHA384", "OQSKEX-RLWE-MSRLN16-ECDHE-ECDSA-AES256-GCM-SHA384"},
    {"OQSKEX-SIDH-IQC-REF-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384", "OQSKEX-SIDH-IQC-REF-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384"},
    {"OQSKEX-CODE-MCBITS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384", "OQSKEX-CODE-MCBITS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384"},
    {"OQSKEX-NTRU-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384", "OQSKEX-NTRU-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384"},
    {"OQSKEX-MLWE-KYBER-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384", "OQSKEX-MLWE-KYBER-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384"},
    /* Picnic-capable ciphersuites */
    {"OQSKEX-LWE-FRODO-RECOMMENDED-PICNIC-AES256-GCM-SHA384", "OQSKEX-LWE-FRODO-RECOMMENDED-PICNIC-AES256-GCM-SHA384"},
    {"OQSKEX-RLWE-MSRLN16-PICNIC-AES256-GCM-SHA384", "OQSKEX-RLWE-MSRLN16-PICNIC-AES256-GCM-SHA384"},
    {"OQSKEX-SIDH-MSR-PICNIC-AES256-GCM-SHA384", "OQSKEX-SIDH-MSR-PICNIC-AES256-GCM-SHA384"},
    {"OQSKEX-LWE-FRODO-RECOMMENDED-ECDHE-PICNIC-AES256-GCM-SHA384", "OQSKEX-LWE-FRODO-RECOMMENDED-ECDHE-PICNIC-AES256-GCM-SHA384"},
    {"OQSKEX-RLWE-MSRLN16-ECDHE-PICNIC-AES256-GCM-SHA384", "OQSKEX-RLWE-MSRLN16-ECDHE-PICNIC-AES256-GCM-SHA384"},
    {"OQSKEX-SIDH-MSR-ECDHE-PICNIC-AES256-GCM-SHA384", "OQSKEX-SIDH-MSR-ECDHE-PICNIC-AES256-GCM-SHA384"},
#ifdef ENABLE_CRYPTO_OPENSSL
    /* OpenSSL-specific group names */
    {"DEFAULT", "DEFAULT"},
    {"ALL", "ALL"},
    {"HIGH", "HIGH"}, {"!HIGH", "!HIGH"},
    {"MEDIUM", "MEDIUM"}, {"!MEDIUM", "!MEDIUM"},
    {"LOW", "LOW"}, {"!LOW", "!LOW"},
    {"ECDH", "ECDH"}, {"!ECDH", "!ECDH"},
    {"ECDSA", "ECDSA"}, {"!ECDSA", "!ECDSA"},
    {"EDH", "EDH"}, {"!EDH", "!EDH"},
    {"EXP", "EXP"}, {"!EXP", "!EXP"},
    {"RSA", "RSA"}, {"!RSA", "!RSA"},
    {"kRSA", "kRSA"}, {"!kRSA", "!kRSA"},
    {"SRP", "SRP"}, {"!SRP", "!SRP"},
#endif
    {NULL, NULL}
};

Your edit is correct in that you want to chose a particular KEX, and OQS used OQSKEX as a standard prefix to distinguish their ciphersuites from the ones in mainline OpenSSL. In this case they are key exchange (KEX) algorithms, not key encapsulation methods (KEMs), so the nomenclature is correct in this case. But more importantly, those strings are coming from OQS-OpenSSL and are beyond our ability to control.
Be advised that we discovered, after our release, that most Picnic certificates don't actually work because they're too large. They worked early in our testing when they were trivial, but when we started adding more fields to the certificate we found they ended up exceeded a hardcoded limit somewhere inside OpenSSL. Since protecting the data in transit from future quantum attackers is the more interesting scenario right now instead of protecting the authentication against a quantum-enabled adversary, we're leaving this for now and focusing on getting the next release ready, and recommending people still use RSA or ECDSA certificates for authentication until then. See #6 for more information.

Closing due to no further activity in a week; feel free to reopen if you have more questions on this.


percentile() function returns incorrect results

Using Grafana 6.5.2 and Grafana-Zabbix 3.10.5.
The percentile functionality is not computing the expected percentile. Let me explain by example. Consider the following dataset:

Now let's ask Grafana-Zabbix to compute the P95 and P25 over these data:
P95

P25

Looking at these we make the following observations:

The P95 value are too low. The raw data have a number of KVMs with CPU usage well over 50%, so the P95 should be higher than (rouighly) 25%.
The P95 and P25 graphs are basically the same; that makes no sense at all.

Cutting to the chase, this is akin to issues #498 and #690; in particular the percentile() function is not sorting the dataset before calling groupBy_perf().


Core Roadmap

1. Dataset
Yoga Posture Dataset
2. Feature Engineering
Different treatments according to different algorithms
3. Image Classification Algorithm candidates

KNN
Decision Tree
SVM
CNN
Transformer

4. Performance Evaluation & Comparison

Accuracy
Confusion Matrix
Recall

Reference Projects:
https://www.kaggle.com/datasets/tr1gg3rtrash/yoga-posture-dataset/code

@hatamoto429  @hatamoto429 @Alex-exy @stickrundude
I showed this to Max after class, he approved this idea.
Other questions I asked:
Q: Do we need to run the training process during the presentation?
A: No, just show the code, a good idea is to save a trained model, and test it with real data
Q: Does using a simple algorithm necessarily result in a low grade?
A: No, but the person picking KNN might be asked questions about CNN, the grade depends both on the project and the answers
Q: In addition to indicators such as accuracy score, what else can we compare?
A:

Training time
Differences in data processing

Q: Other suggestions?
A: Show how your model is improved.

Same Dataset

Two approaches

CNN (Alex, Lukas)
Transformer (KshitiJ, Kun)

Deadline: 2024-07-11 2pm


This should have a url of a badger pic

?

🤷♂

I mean . I can got a pic of real stargazers from a url

Sorry I'm really not sure I understand, could you rephrase your request?

This project is to get how many real people started at a project right？

Then a url link to show these data is very useful

Yeah I see a astro rating badge

Currently there are GitHub badges you can get that give you the overall score of a repository, and in the 1.2 version there will be a webapp showing the detailed reports for each repo.

Thats what I said


try adding amsmath too

I've turned MyST Markdown parsing back on, and now the mathjax typesetting goes through. I don't understand why using Commonmark would, and suspect its a bug. MyST seems to do a lot of manipulation of the notebook. I generally don't use MyST in notebooks because it's unlikely a user will have the MyST extension for their own JupyterLab, or maybe they don't even use JupyterLab. But, turning it on doesn't appear to cause any problems for our notebooks.


Update CellectController responses to be more usable

Instead of just returning ids, it returns the necessary fields for cellect.

There's something odd going on in the specs with set_member_subjects vs subjects.  Any thoughts?

This is great - thanks @parrish. Yeah re the specs, it'll be the sms.id attribute select vs the sms.subject_id.


User is always redirected back to Google login

With the latest version of the Google API Client (2.2.2), the user is always redirected back to Google login even after a successful login.

Thank you, just merged #8


Idea: auto-generated bindings for webgpu-native

We could consider "splitting" the webgpu-native backend in 2 parts, one being autogenerated direct python bindings, and one being the translation layer to the IDL-standardized webgpu API, I documented this idea here. Idea originates from #480
We can combine the following tools to automatically generate bindings for webgpu-native:

pyo3 and maturin to build python bindings
a python script generate pyo3 bindings, using cffi to parse wgpu.h

These bindings will be more performant since they don't rely on cffi at runtime.
This would need to be done in a separate lib, that we can then depend on in wgpu-py to layer the IDL based API on top of the bindings.
We would not be able to use the binary releases of webgpu-native though; we'd have to build the bindings ourselves directly from rust source. So that's a bit of a bummer but not impossible. Because of that, we have a few choices:

fork the webgpu-native repo
depend on webgpu-native with cargo (not sure if this is realistic)

There is one other project we can look at for inspiration that already autogenerates bindings for C++ here: https://github.com/eliemichel/WebGPU-Cpp/

What if we go for C-API bindings instead? Then we can use the binary wgpu-native releases, and use simpler tooling (e.g. cython).

What if we go for C-API bindings instead? Then we can use the binary wgpu-native releases, and use simpler tooling (e.g. cython).

So we take the binary, the header file, and then wrap with cython? I'm not sure I know how to compile something like that. Would we dynamically link to the binary then?

The answer to all questions is "I think so". I'm pretty sure ppl use Cython for this sort of thing. But perhaps there are other tools too.


feat(#247): Refactor SelectiveDecompilerTest and Add InMemoryStorage

In this PR I significantly refactored and simplified the SelectiveDecompilerTest.
I removed literal duplication and redundant field.
Also I added InMemoryStorage that speeds up testing since we don't need to interact with filesystem anymore.
However, we might encounter some problems with InMemoryStorage since it removes all the elements when recepient gets this elements.
So, InMemorySorage implicitly works like a queue.
Closes: #247
History:

feat(#247): add in memory storage for tests
feat(#247): refactor decompilesOnlySomeFiles test
feat(#247): remove 'supported' fied
feat(#247): refactor #copiesDecompiledFiles test'
feat(#247): remove redundant test
feat(#247): remove the puzzle description for #247 issue

PR-Codex overview
This PR adds constructors and methods, implements InMemoryStorage, and refactors SelectiveDecompilerTest.
Detailed summary

Added constructors and methods in SelectiveDecompiler, XmirEntry, and InMemoryStorage
Implemented InMemoryStorage for unit tests
Refactored SelectiveDecompilerTest to remove duplicated string literals and unused fields

The following files were skipped due to too many changes: src/test/java/org/eolang/opeo/decompilation/SelectiveDecompilerTest.java

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@rultor merge

@rultor merge

@volodya-lombrozo OK, I'll try to merge now. You can check the progress of the merge here

@rultor merge

@volodya-lombrozo Done! FYI, the full log is here (took me 5min)


[BUG] Am keeping on getting unauthorized app message even when am using the test certificate.pfx

:information_source: Info

Version: e.g. v2.8.15
:speech_balloon: Description

Enter a description of your problem here.
Any logs, error and assets you have that can help to find this bug.
To run the tool with extended logs use the -v argument, for example: flutter pub run msix:create -v
:scroll: Pubspec.yaml

We ask that you include your pubspec.yaml file as a common problem we have seen has been the pubspec.yaml file being incorrect

Hey, Sorry for the late response.
Please try the latest version.


JFXCheckBox clickable area is too wide

The JFXCheckBox appears to have a clickable area that is equal to the radius of the Rippler and not the CheckBox's layout itself. Is there a way to fix? Currently, if I have two checkboxes that are somewhat close together, you can accidentally click on the wrong one if you click low on the top checkbox, since the clickable area of the second is overlapping.

For now I've worked around this by disabling the rippler in CSS (so it doesn't show up at all for checkboxes) like
.jfx-check-box .jfx-rippler {     -jfx-rippler-disabled: true; }
And then in the click handler for the checkbox, reverting the selection if it was clicked on the box-container and not the checkbox itself:
checkBox.setOnMouseClicked( e -> { 			if (e.getTarget() instanceof StackPane) { 				StackPane pane = (StackPane)e.getTarget(); 				if (pane.getStyleClass().contains("box-container")) { 					this.checkBox.setSelected(!this.checkBox.isSelected()); 				} 			} 		});
Would be nice if there is a cleaner solution.


Add BatchedArray tests

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (21ce6d0) 100.00% compared to head (6b11940) 100.00%.

Additional details and impacted files
@@            Coverage Diff            @@
##              main      #576   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           25        25
  Lines         2149      2149
  Branches       278       278
=========================================
  Hits          2149      2149

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Remove speaker button

Remove speaker button
#2

To make this removal cleaner, I think the associated files e.g., lib/textToSpeech.ts can be removed too


Delegate check for preemptive authentication from AuthenticatorBase to affected Authenticators

The main purpose of the proposed refactoring is to give an individual Authenticator the possibility to decide if preemptive authentication is possible (e.g. if a completely different header is used for authentication).
In addition it yields cleaner code as the certificate handling code and the header name for basic, digest and spnego auth can now be moved to the relevant Authenticators and does not pollute the AuthenicatorBase. FormAuthenticator and NonLoginAuthenticator don't need to override isPreemptiveAuthRequest() as preemptive is not supported/needed.

Mixed up my branches. Will reopen without the Bugfix.


Usage with nvim-lsp-installer

Hello everyone,
I'm currently trying to integrate this plugin together with https://github.com/williamboman/nvim-lsp-installer.
I want to use nvim-lsp-installer to manage the installation of rust-analyzer
and use this plugin for extended capabilities. But both api's are pretty incompatible.
nvim-lsp-installer wants me to call its setup function in a callback provided by it and rust-tools.nvim also
wants me to run their setup function to set everything up.
It seems like that it would be much more natural if rust-tools.nvim would provide a public function to inject
(extend) the lsp server settings configuration instead of internalizing everything. (At least it should provide
the option for extended use cases.)
What do you think? Is this a good idea? Do you have other ideas on how to integrate these two plugins?

local lsp_installer = require("nvim-lsp-installer")

lsp_installer.on_server_ready(function(server)
	local opts = {}

	-- (optional) Customize the options passed to the server
	-- if server.name == "tsserver" then
	--     opts.root_dir = function() ... end
	-- end

	if server.name == "rust_analyzer" then
		require("rust-tools").setup({
			dap = {
				adapter = require("rust-tools.dap").get_codelldb_adapter(
					"/home/simrat39/.vscode/extensions/vadimcn.vscode-lldb-1.6.7/adapter/codelldb",
					"/home/simrat39/.vscode/extensions/vadimcn.vscode-lldb-1.6.7/lldb/lib/liblldb.so"
				),
			},
			server = { cmd = server._default_options.cmd },
		})
		return
	end
	-- This setup() function is exactly the same as lspconfig's setup function.
	-- Refer to https://github.com/neovim/nvim-lspconfig/blob/master/ADVANCED_README.md
	server:setup(opts)
end)

This works, please ignore the dap stuff

Hello,
Same problem here and fortunately I was able to have rust-tools running thanks to the setup above with the exception of the better debugging features. I have properly setup the path and everything but variables like string wouldn't show the values at all.

Here are my configuration for the rust_analyzer server
    elseif server.name == "rust_analyzer" then
        local extension_path = os.getenv("HOME") .. '/.vscode-oss/extensions/vadimcn.vscode-lldb-1.6.9/'
        local codelldb_path = extension_path .. 'adapter/codelldb'
        local liblldb_path = extension_path .. 'lldb/lib/liblldb.so'
        require("rust-tools").setup({
            server = {
                dap = {
                    adapter = require('rust-tools.dap').get_codelldb_adapter(
                        codelldb_path, liblldb_path)
                },
                server = {cmd = server._default_options.cmd}
            }
        })
        return
    end

Ah my mistake, thank you for that!

local lsp_installer = require("nvim-lsp-installer")

lsp_installer.on_server_ready(function(server)
	local opts = {}

	-- (optional) Customize the options passed to the server
	-- if server.name == "tsserver" then
	--     opts.root_dir = function() ... end
	-- end

	if server.name == "rust_analyzer" then
		require("rust-tools").setup({
			dap = {
				adapter = require("rust-tools.dap").get_codelldb_adapter(
					"/home/simrat39/.vscode/extensions/vadimcn.vscode-lldb-1.6.7/adapter/codelldb",
					"/home/simrat39/.vscode/extensions/vadimcn.vscode-lldb-1.6.7/lldb/lib/liblldb.so"
				),
			},
			server = { cmd = server._default_options.cmd },
		})
		return
	end
	-- This setup() function is exactly the same as lspconfig's setup function.
	-- Refer to https://github.com/neovim/nvim-lspconfig/blob/master/ADVANCED_README.md
	server:setup(opts)
end)

This works, please ignore the dap stuff Make sure the return is present else it'll mess things up

Hey @simrat39,
thanks for your reply. I could verify that this is working.
The only thing that I dislike about it, is that nvim-lsp-installer
can do a few additional things inside its setup function (like executing
the pre/post hook, see here: https://github.com/williamboman/nvim-lsp-installer/blob/main/lua/nvim-lsp-installer/server.lua#L53).
I don't think that it is a problem in this case, but it is also not that perfect.
But at least I have a working version for now.

@nagua can't you just...call them before and after calling rust-tools' setup lol

I'm having a problem using this with nvim-lsp-installer where I get an error when opening a .rs file outside the context of a project. I get a Error detected while processing VimEnter Autocommands for "*.rs": E5108: Error executing lua ...im/plugged/rust-tools.nvim/lua/rust-tools/s tandalone.lua:8: attempt to index field 'server' (a nil value) error on startup.
I'm doing the similar as recommended by lsp_installer upstream:
local lsp_installer = require("nvim-lsp-installer")

lsp_installer.on_server_ready(function(server)
  if server.name == "rust_analyzer" then
    local opts = {
      server = vim.tbl_deep_extend("force", server:get_default_options(), {
        on_attach = on_attach,
        flags = {
          debounce_text_changes = 150,
        },
      }),
    }
    require("rust-tools").setup(coq.lsp_ensure_capabilities(opts))
    server:attach_buffers()
  else
    local opts = {
      on_attach = on_attach,
      flags = {
        debounce_text_changes = 150,
      },
    }
    server:setup(coq.lsp_ensure_capabilities(opts))
  end
  -- vim.cmd [[ do User LspAttachBuffers ]]
end)

@GBeauregard could you try without the Coq ensure capabilities stuff? And you shouldnt need to call server:attach_buffers as well

@GBeauregard could you try without the Coq ensure capabilities stuff?

Ah yeah that was it since I had it in the wrong spot...oops :facepalm: ; now without it, it just throws an error that it can't find the workplace (correctly). I don't mind the error but it'd be nice to silence it if possible i guess. I think this is on the LSP side and not your side though.

And you shouldnt need to call server:attach_buffers as well

This is required and removing it breaks the server starting. This is only required with the nvim-lsp-installer since 2 days ago because of new changes that were made; the lsp-installer maintainer directed me to add it to get things working again.

@GBeauregard could you try without the Coq ensure capabilities stuff? And you shouldnt need to call server:attach_buffers as well

I have no idea how I had it working earlier, but now I'm getting the error again (with or w/o the coq line)

So looks like this happens because the setup finishes after the autocommand is triggered:

local lsp_installer = require("nvim-lsp-installer")
local lsp_installer_servers = require("nvim-lsp-installer/servers")

local server_available, requested_server = lsp_installer_servers.get_server("rust_analyzer")

if server_available then
    require("rust-tools").setup({
        dap = {
            adapter = require("rust-tools.dap").get_codelldb_adapter(
                "/home/simrat39/.vscode/extensions/vadimcn.vscode-lldb-1.6.7/adapter/codelldb",
                "/home/simrat39/.vscode/extensions/vadimcn.vscode-lldb-1.6.7/lldb/lib/liblldb.so"
            ),
        },
        server = { cmd = requested_server._default_options.cmd },
    })
end

lsp_installer.on_server_ready(function(server)
    local opts = {}

    if server.name == "rust_analyzer" then
        return
    end

    server:setup(opts)
end)

@GBeauregard it works with this setup. @nagua @mkadit consider updating to this

I'd recommend the following change, to avoid reaching into private fields (also to make sure any other server options other than just cmd are included should they be introduced in the future):
diff --git a/a b/b
index ce46eb9..35a5872 100644
--- a/a
+++ b/b
@@ -11,7 +11,7 @@ if server_available then
                 "/home/simrat39/.vscode/extensions/vadimcn.vscode-lldb-1.6.7/lldb/lib/liblldb.so"
             ),
         },
-        server = { cmd = requested_server._default_options.cmd },
+        server = server:get_default_options()
     })
 end

I would also put this inside the lsp_installer.on_server_ready() callback, in the if server.name == "rust_analyzer" block. Would provide a nicer interop with nvim-lsp-installer imo

@williamboman Can you please post a full config of how you suggest initializing both plugins? I'm trying to follow your suggestion of moving the opts into the on_server_ready block, but depending on what I pass as the top level key, I either get nothing (lsp doesn't seem to be active), or I get an error from LspInstall about rust-analyzer not being on the path BUT it still works.

Have you tried something like the following? Just from reading the docs, I believe this should work
lsp_installer.on_server_ready(function(server)
    local opts = {}

    if server.name == "rust_analyzer" then
        require("rust-tools").setup({
            server = server:get_default_options(),
        })
    else
        server:setup(opts)
    end
end)

Also a heads up to those who currently read the cmd property from nvim-lsp-installer: this cmd property will soon be removed from virtually all servers in nvim-lsp-installer. Instead, we'll extend the user's PATH before starting the server - allowing the neovim LSP client to locate the server executables by itself instead (https://github.com/williamboman/nvim-lsp-installer/pull/283). This means servers will start using the default cmd provided by nvim-lspconfig, so if you'd like to access it for some reason you'll need to do so via lspconfig (e.g., require("lspconfig.server_configurations.rust_analyzer").default_config.cmd)

I can't seem to get it working. This code snippet works:
local lsp_installer = require("nvim-lsp-installer")
local lsp_installer_servers = require("nvim-lsp-installer/servers")

local server_available, requested_server = lsp_installer_servers.get_server("rust_analyzer")

if server_available then
    local opts = {
        tools = {
            autoSetHints = true,
            hover_with_actions = false,
            inlay_hints = {
                show_parameter_hints = true,
                parameter_hints_prefix = "",
                other_hints_prefix = "",
            },
        },
        server = {
            cmd = requested_server._default_options.cmd,
            settings = {
                ["rust-analyzer"] = {
                    completion = {
                        postfix = {
                            enable = false
                        }
                    },
                    checkOnSave = {
                        command = "clippy"
                    },
                }
            }
        },
    }
    require("rust-tools").setup(opts)
end

lsp_installer.on_server_ready(function(server)
    local opts = {}

    if server.name == "rust_analyzer" then
        return
    end

    server:setup(opts)
end)

While this one doesn't, no error messages shown:
lsp_installer.on_server_ready(function(server)
    local opts = {}

    if server.name == "rust_analyzer" then
        local rustopts = {
            tools = {
                autoSetHints = true,
                hover_with_actions = false,
                inlay_hints = {
                    show_parameter_hints = true,
                    parameter_hints_prefix = "",
                    other_hints_prefix = "",
                },
            },
            server = vim.tbl_deep_extend("force", server:get_default_options(), opts, {
                settings = {
                    ["rust-analyzer"] = {
                        completion = {
                            postfix = {
                                enable = false
                            }
                        },
                        checkOnSave = {
                            command = "clippy"
                        },
                    }
                }
            }),
        }
        require("rust-tools").setup(rustops)
    else
        server:setup(opts)
    end
end)

Minor and unrelated but convention re: / vs . is to use . (I believe it has an impact on Lua module cache, and . is more OS-agnostic).
- local lsp_installer_servers = require("nvim-lsp-installer/servers")
+ local lsp_installer_servers = require("nvim-lsp-installer.servers")

Hmm, the snippet I suggested assumes you manage the installation of rust-analyzer via nvim-lsp-installer. Is it currently listed as installed (:LspInstallInfo)?

Yes it is listed as installed (I actually have removed it from my system altogether), the first snippet I posted actually uses that through requested_server._default_options.cmd.

Hmm weird, will have to tinker with it locally to understand more.

So this seems to work just fine for me. The only problem is that it doesn't attach the very first buffer(s) that happen to be open when rust-tools is initialized. The reason for this is that nvim-lsp-installer schedules the "server ready" dispatches, so if you open a buffer like nvim src/main.rs or :e src/main.rs the FileType event will already have fired (lspconfig uses this to check whether it should start and attach any LSP servers).
There's a convenience server:attach_buffers() method provided by nvim-lsp-installer to remedy this.
lsp_installer.on_server_ready(function(server)
    local opts = {}

    if server.name == "rust_analyzer" then
        -- Initialize the LSP via rust-tools instead
        require("rust-tools").setup({
            -- The "server" property provided in rust-tools setup function are the settings rust-tools will provide to
            -- lspconfig during init.
            -- We merge the necessary settings from nvim-lsp-installer (server:get_default_options()) with
            -- the user's own settings (opts).
            server = vim.tbl_deep_extend("force", server:get_default_options(), opts),
        })
+       server:attach_buffers()
    else
        server:setup(opts)
    end
end)

https://asciinema.org/a/30RQSRdiLXdP6SISvJeBslC6h

https://asciinema.org/a/30RQSRdiLXdP6SISvJeBslC6h

This doesn't appear to be working correctly; we should be getting inlayed type hints by default. You do appear to have coincidentally made a testfile that wouldn't have them despite them being fairly ubiquitous. Try the config here to see them: https://github.com/simrat39/rust-tools.nvim/issues/89#issuecomment-960405755

That's probably because I've not set up either the Rust project or rust-tools properly. It does end up using nvim-lsp-installer's installation of rust_analyzer - anything further than that I feel like have nothing to do with rust-tools <-> nvim-lsp-installer interop, or am I missing something?
If I run :RustSetInlayHints manually it pops up:

@williamboman It seems the attach_buffers call does the trick, it works now, thank you very much for your help.
For everyone else looking for an example on how to specify some other options to pass along to rust analyzer, this is what I'm using:
local lsp_installer = require("nvim-lsp-installer")

lsp_installer.on_server_ready(function(server)
    local opts = {}

    if server.name == "rust_analyzer" then
        local rustopts = {
            tools = {
                autoSetHints = true,
                hover_with_actions = false,
                inlay_hints = {
                    show_parameter_hints = true,
                    parameter_hints_prefix = "",
                    other_hints_prefix = "",
                },
            },
            server = vim.tbl_deep_extend("force", server:get_default_options(), opts, {
                settings = {
                    ["rust-analyzer"] = {
                        completion = {
                            postfix = {
                                enable = false
                            }
                        },
                        checkOnSave = {
                            command = "clippy"
                        },
                    }
                }
            }),
        }
        require("rust-tools").setup(rustopts)
        server:attach_buffers()
    else
        server:setup(opts)
    end
end)

In the above example, I'm disabling postfix completions, and enabling clippy.

:+1: I added this to nvim-lsp-installer's Wiki here yesterday, feel free to update it if you discover any problems/improvements


l0_threshold

I find this work extremely useful and interesting. Thanks for that!
Could you please explain why l0_threshold is .05 in utils.py? I cannot see why according to the paper.
Thanks in advance!

This implementation contains some different (hopefully better) hyperparameter choices compared to the code used in the paper. The value 0.05 simply came out of our better hyperparameter optimization pipeline. Does this answer your question?

Reading this now, I think the threshold should be much lower, to allow also for small weights to be used. 0.01 or 0.001 would be better, but also require the L1 phase longer to converge.

Reading this now, I think the threshold should be much lower, to allow also for small weights to be used. 0.01 or 0.001 would be better, but also require the L1 phase longer to converge.


fix the issue failed to delete sslkeys by TrafficOps API

@dneuman64
I open a issue : https://issues.apache.org/jira/browse/TC-98

I tried to delete SSL keys by API for Delivery Services: https001 as follows:
/api/1.1/deliveryservices/xmlId/https001/sslkeys/delete.json
2.The result was failure, the sslkey for https001 stilled in Traffic Vault.

The root cause is the delete function in traffic_ops/app/lib/Connection/RiakAdapter.pm

Hey @pengyuewu, it looks like this PR is against 1.7.x which was released before apache.  We don't have any plans on releasing another version of 1.7.  Can you re-test this defect against master and, if it still exists, create a PR against master?

OK,it still exists in master,I'll create a PR against master?


Implement retriable connection

Add a test for an issue that was reported where the process exits if the connection to the Redis server is lost while being subscribed to a topic.
To run this test, you will need to specifically allow to run (execute) commands and enable the unstable API -- deno test --allow-net --allow-run --unstable
Reference: https://github.com/keroxp/deno-redis/issues/83

At the moment, a client will die if the server is killed or the connection is lost. This is a problem especially with clients subscribed to a channel.
Since the Writer/Reader buffers are passed around to I/O functions, it is impossible to reconnect a Redis client.
Having a connection object allows to easily replace the buffers.
Resolves: https://github.com/denolib/deno-redis/issues/83
ToDo
[ ] Fix 3 failing tests
[ ] Update documentation on retriable connections
The following tests are failing inconsistently, and I would need some help to figure out why:

testSubscribe
connect with wrong password
connect with empty password

For example, before running testSubscribe (only when running all the tests; never if running only the tests under ./pubsub_test.ts); the Redis client loops on DB index from 0 to 15 and then flush wherever it ends... In my case, it selects up to 11 and doesn't flush... Something seems to go wrong and makes the before-mentioned failing tests...
1592932362.977302 [0 <IP_ADDRESS>:60779] "SELECT" "1"
1592932362.977361 [0 <IP_ADDRESS>:60780] "SELECT" "2"
1592932362.977377 [0 <IP_ADDRESS>:60781] "SELECT" "3"
1592932362.977384 [3 <IP_ADDRESS>:60781] "SELECT" "3"
1592932362.977388 [3 <IP_ADDRESS>:60781] "FLUSHDB"
1592932362.977402 [0 <IP_ADDRESS>:60782] "SELECT" "4"
1592932362.977414 [0 <IP_ADDRESS>:60783] "SELECT" "5"
1592932362.977552 [0 <IP_ADDRESS>:60784] "SELECT" "6"
1592932362.977574 [0 <IP_ADDRESS>:60785] "SELECT" "7"
1592932362.977585 [0 <IP_ADDRESS>:60786] "SELECT" "8"
1592932362.977595 [0 <IP_ADDRESS>:60787] "SELECT" "9"
1592932362.977604 [0 <IP_ADDRESS>:60788] "SELECT" "10"
1592932362.977614 [0 <IP_ADDRESS>:60789] "SELECT" "11"

I would like some help to finish this PR.

Thanks for working this, @sebastienfilion!

Hmm, it looks like the testSubscribe case is causing a resource leak. :thinking:
I'll also look into the cause of this.
$ deno test -A --unstable --filter testSubscribe
running 4 tests
test testSubscribe ... FAILED (9ms)
test testSubscribe2 ... ok (6ms)
test testSubscribe3 ... ok (5ms)
test testSubscribe4 (#83) ... ignored (0ms)

failures:

testSubscribe
AssertionError: Test case is leaking async ops.
Before:
  - dispatched: 23
  - completed: 12
After:
  - dispatched: 44
  - completed: 44

Make sure to await all promises returned from Deno APIs before
finishing test case.
    at Object.assert ($deno$/util.ts:35:11)
    at asyncOpSanitizer ($deno$/testing.ts:43:5)
    at async Object.resourceSanitizer [as fn] ($deno$/testing.ts:67:5)
    at async TestRunner.[Symbol.asyncIterator] ($deno$/testing.ts:275:11)
    at async Object.runTests ($deno$/testing.ts:358:20)

failures:

	testSubscribe

test result: FAILED. 2 passed; 1 failed; 1 ignored; 0 measured; 177 filtered out

Umm, it looks like the testSubscribe case is causing a resource leak 🤔
I'll also look into the cause of this.

Part of the problem is ./tests/test_util.ts that creates multiple clients (about 12) at runtime and never seems to close them.
If I run deno test [...] pubsub_test.ts the tests complete without any leak.
But if I run deno test [..] . the tests fails because of the left over TCP streams...
I guess that it's because before, the TCP connection was garbage collected with the writers?

Thanks for submitting the changes @sebastienfilion!

Fix 3 failing tests

We can merge this PR when the above issue is resolved.
Please wait a little longer.

We can merge this PR when the above issue is resolved.

Will you help resolve the issue or you want me to do it?

Yeah, I'll also investigate the cause.

Requested changes address the problem of the testSubscribe case.
(However, the other cases still fail...)

Good catch!

@uki00a I made the changes that you suggested and all but one test passes! 🎈
This one is not working connect with empty password because either the TypeScript compiler will complain that password can't be any or else at runtime TypeScript will catch that the password is empty and will not throw ErrorReplyError as the test expect.
So either I force the compiler to allow a password to be any or a change the error from ErrorReplyError to TypeError (?)

Awesome work!
Thanks @sebastienfilion!

This PR closes #83.

Released in v0.11.0!


nixos/smokeping: port test to python

Motivation for this change
#72828
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers
cc @tfc @worldofpeace

@GrahamcOfBorg test smokeping

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/65


Support Headers and Footers using page.set('paperSize',paperSize) & phantom.callback

This is a fix for the existing issue - https://github.com/baudehlo/node-phantom-simple/issues/78
This fix allows us to support the following code snippet
var driver = require('node-phantom-simple');

var phantom = null;

var path = 'out.pdf';

driver.create(function(err, browser) {

    phantom = browser;
    return browser.createPage(function(err, page) {
        return page.open("http://www.google.com/search?q=rohit%20ghatol", function(err, status) {

            var paperSize = {
                format: 'A4',
                margin: "1cm",
                header: {
                    height: "2cm",
                    contents: phantom.callback(function(pageNum, numPages) {
                        return "
Header " + pageNum + " / " + numPages + "
";
                    })
                },
                footer: {
                    height: "2cm",
                    contents: phantom.callback(function(pageNum, numPages) {
                        return "
Footer " + pageNum + " / " + numPages + "
";
                    })
                }
            };
            page.set('paperSize', paperSize, function() {
                page.render(path, {
                    format: 'pdf',
                    quality: '100'
                }, function() {
                  browser.exit();
                    console.log('done');
                });
            });
        });
    });
});

The basic issue here is, node-phantom-simple is extremely good at passing json objects to the actual phantomjs (via bridge). However when we need a functionality like the phantom.callback() function to add headers and footers, there is no way the existing bridge can support it, as it is restricted to json object, functions are ofcourse stripped out.
The solution to this was we added phantom.callback() function in the node-phantom-simple.js, which actually converts the function into string and passes that to the bridge.js
In the bridge.js, I have created a hooks[] array which holds any set or get hooks for any property we set using page.set('pageSize',object). There is a hook particularly for 'pageSize' which looks for pageSize.header.contents and pageSize.footer.contents and converts the string passed to an actual function.
This way we are able to use phantom.callback() abstracting how we pass the callback function to the server.  Only catch here is the function will not support any closure variables. We will need to document the fact, since the function runs remotely in the content of phantom.
I have updated the test case test/test_page_render.js, adhered with the lint conventions and was able to run tests (till mine).
Ripple effects of this fix should be minimal.

Please, don't create multiple PRs. Run tests locally first, squash and push with --force to existing PR-ed branch.

Hi Vitaly
My bad, next time onwards I will take care of it.
Thanks for the tip about --force to existing PR-ed branch, I will use that.
Cheers,
Rohit
On Sat, Oct 10, 2015 at 6:54 AM, Vitaly Puzrin<EMAIL_ADDRESS>wrote:

Please, don't create multiple PRs. Run tests locally first, squash and
push with --force to existing PR-ed branch.
—
Reply to this email directly or view it on GitHub
https://github.com/baudehlo/node-phantom-simple/pull/85#issuecomment-147020394
.

--
Director of Engineering Synerzip Softech
Mobile -<PHONE_NUMBER>
http://www.linkedin.com/in/rohitghatol


feat: Add support for tracing crate

It is no longer necessary to have to depend on both log and tracing-log
to use clap-verbosity-flag with the tracing crate. This commit adds
support for the tracing crate directly.

Add tracing-core as a dependency
Add tracing as a feature
Add tracing module
Remove tracing-log as a dependency for the tracing example

Pull Request Test Coverage Report for Build<PHONE_NUMBER>0
Details

39 of 78 (50.0%)  changed or added relevant lines in 3 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-11.9%) to 47.312%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/tracing.rs
0
4
0.0%

src/log.rs
20
36
55.56%

src/lib.rs
19
38
50.0%

Files with Coverage Reduction
New Missed Lines
%

src/lib.rs
3
45.28%

Totals

Change from base Build<PHONE_NUMBER>9:
-11.9%

Covered Lines:
44

Relevant Lines:
93

💛  - Coveralls


Intersection cannot be accessed

https://routeplanner.bike.brussels/#15.76/50.8181/4.3772?sb=true&o=4.3751175,50.8198880&d=4.3743753,50.8203894&p=profile1

https://www.openstreetmap.org/way/40151775 has a 'cyclway:right=no', which is currently still interpreted wrongly.
https://github.com/anyways-open/routing-profiles/pull/35 should fix this

Already better, still an issue there:

The routing follows the expected behaviour, it's just that the colours aren't added.
I've fixed that here: https://www.openstreetmap.org/changeset/87077971


Plugin won’t install after pressing install…

Can anyone please help with the above?
After searching for and clicking install on the WebOS Tv plug-in, nothing actually installs...
I select to create a new bridge then just takes me back to the install page with no option to configure.
Same thing happens again if I click install...
Am I missing something?

I do not think that the issue is related to this plugin... I guess it has something to do with your homebridge installation


WIP - Create a new install guide

This PR creates a new install guide and a helm chart that uses etcd-operator to create a new etcd cluster with backup capabilities.

@jeremyrickard do you want this in v0.12.0?

We can do this after the v0.12.0 release, but ideally shortly there after. I’d like to go through this and update for RBAC since AKS is GA now. Shouldn’t be any major changes and will not have any code changes.


[bug]add escape character option to global dictionary

while using spark-csv to load the data,by default,the escape char is "".
so when the data in quote with "",then spark-csv will skip ,like "ab\c"->"abc".
and in csv reader ,it will no skip.
so there is inconsistency in read in phase 1 - dictionary generation and phase 2- data loading.
then we provide an option to user to specify escape character.
@Vimal-Das please review.thanks.

LGTM

retest this please

OK,  merge to master.


Volar lsp client crashed

Description
Volar lsp server attached to the buffer and then detach.
@volar/server version: 0.27.21
Neovim version
NVIM v0.6.0-dev+296-g1f49268c4
Build type: Release
LuaJIT 2.1.0-beta3
Nvim-lspconfig version
No response
Operating system and version
macOS 10.13.6
Affected language servers
volar
Steps to reproduce

open *.vue file
wait a few seconds
volar client detached

Actual behavior
volar client detached

Expected behavior
No response
Minimal config
local nvim_lsp = require('lspconfig')
local servers = {"html", "cssls", "volar", "tsserver"}

for _, lsp in ipairs(servers) do
   nvim_lsp[lsp].setup {}
end

Health check
health#lspconfig#check
Checking language server protocol configuration

INFO: cssls: configuration checked.
INFO: volar: configuration checked.
INFO: tsserver: configuration checked.
INFO: null-ls: configuration checked.
INFO: html: configuration checked.

LSP log
https://gist.github.com/lukerHhy/3ebaad6216b1ce3226975079d4ed5ffb

If the server crashes, you should file an issue with the upstream issue tracker.


Remove MAXIMUM_SPONSOR_WALLET_REQUESTS to avoid throttling request fulfillments

This PR closes #1644 by removing the MAXIMUM_SPONSOR_WALLET_REQUESTS constant. The initial intention of this constant was to prevent a single user from monopolizing the Airnode response bandwidth. However, as discussed in this thread, this measure is not effective, and it may obstruct legitimate usage.

I kept the blocking.ts and blocking.test.ts just in case if we revisit this feature for potential future use. But these files can be removed completely since they are not used anymore, looking forward for any input on this.


Don't inherit datetime format from language settings

I like to work with DBeaver's UI in English language. But I don't like US format of date and time like this:
7/14/24, 10:26 PM
I want something like this:
14.07.2024 22:26
Here are some places in the application where time and date are shown (to reach this form - double click on a node "Databases" in any connection):

Window -> Show View -> Error log

I can see now, that format of date and time is inherited from a language from Preferences here.
I suggest to do not inherit it or add a separate option to set it somehow in Preferences so that UI would be in English and date/time format would be based on another location.

Here is an example of changing time format from another application:
https://github.com/user-attachments/assets/053256c9-d58c-4b82-89d6-73fb60e3ad5b

Thank you for the idea!
We could add special settings for the datetime format, independent of the locale. However, this is a complex problem that requires a lot of effort.
You can vote for the issue with the emoji under the issue description to promote it to a higher priority.
Related bug report: https://github.com/dbeaver/dbeaver/issues/34821

Thanks for explanation.


Begin the presentation template

https://docs.google.com/presentation/d/1B7hu9vGx0EAl0u-qQ7hgCLQK24yVcxIo5I-OV0zQQ94/edit?usp=sharing
I've started a template.
This should be available to view by anyone with a link.


Address component governance alerts in dotnet-source-build-utilities

The ask is to address all critical and high alerts by 2022-01-28.
https://dnceng.visualstudio.com/internal/_componentGovernance/dotnet-source-build-utilities?_a=alerts&typeId=1981362&alerts-view-option=active (internal link)

All issues have been addressed.


Search for dot_formatter_opts

Pull Request Test Coverage Report for Build 8386a7de05a32b8a5c8b0aaf8fb97bef451791f4-PR-17

4 of 5 (80.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.3%) to 98.013%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/rewrite/source.ex
4
5
80.0%

Totals

Change from base Build d96aa39de11ce2ee06ee57129ab8375836caaac9:
-0.3%

Covered Lines:
296

Relevant Lines:
302

💛  - Coveralls


Replace select with pselect

pselect syscall enables correct handling of signal events
it is included in the POSIX-2001 standard and therefore can be used for the neutral backend

fixed in e75119b


Building twig.js for browser use

I would like to use twig.js in the browser - without npm.
Where can I get the latest twig.js for browser use. I read "Run make (or make -B to force building) build them", however, I still don't know what to do :-)
Can anybody point me in the right direction?
Thanks!

The latest release version is available via bower here: https://github.com/philsbury/twigjs-bower
You can alway just download the repo if you don't use bower

Many Thanks, philsbury, that did the trick: use "Twig.twig" instead of just "twig".


Deploy devon4quarkus application on EKS/AKS rancher

Deploy devon4quarkus application on EKS/AKS rancher.
Acceptance criteria:

Deploy devon4quarkus application using generic pipeline script in EKS rancher.
Both rancher and devon4quarkus application should be up and running and accessible.

Facing issue while accessing two application using ingress controller DNS, ingress controller IP address is mapping only for single ingress, it is not supporting for multiple ingress.
I need to research more about ingress controller to access multiple application with same DNS.

Additional points(from albert):

Create second nginx ingress service domain.
Deploy devon4quarkus application using nginx service domain in EKS rancher.
Both rancher and devon4quarkus application should be up and running and accessible with different domains.

Created new nginx ingress service  and deployed quarkus application and created ingress by using domain. facing issue while accessing application using ingress controller domain. Error: 503 service temporarily unavailable, troubleshooting it.


Add more information into cards

Create a text that shows how have the values changed in BitCoin Cards (TAB2BTCChart), with green color if it is positive or red color in other case.

Completed in commit https://github.com/Javinator9889/BitCoinPools/commit/cadc98287703cd221dbf83c31777f80f3734776d