ATA for tsserver on web

For #45314
This prototypes ATA for the web version of TypeScript. The logic is copied from the @typescript/ata project
The current implementation is not complete, mainly because I don't understand how to get the d.ts files into the TS project correctly
/cc @orta @DanielRosenwasser

To test this:

Build the TS changes using gulp local

In the VS Code codebase

Remove the line where we disable ATA on the web: https://github.com/microsoft/vscode/blob/f47ae9e324c8abdb15fe2effef94c5c4cb02c5aa/extensions/typescript-language-features/src/tsServer/spawner.ts#L209

Run yarn compile-web

Replace the built tsserver.web file with the one from the TS project. I do this with a symlink:
ln -s ~/projects/typescript/built/local/tsserver.js ~/projects/vscode/extensions/typescript-language-features/dist/browser/typescript/tsserver.web.js

Run yarn web to launch VS Code in the web

Close all TS files. Having a TS file in the implicit project caused ATA to become disabled (we need to investigate the UX here)

Open a JS file

Write import 'jquery'

You should not see suggestions for the global $

Note that at the moment the import doesn't actually get resolved properly. You don't get any intellisense if you are typing in the {} for import {} from 'jquery'. I believe this is because I'm not registering the d.ts file with TS properly

Oh cool, I missed this. Yeah, where the source of truth for the files lives is a bit of a tricky one. There's a few potential options:

Use the TSServer APIs to write the files in whatever is the 'source' for the other files. E.g. when the ATA comes back saying add<EMAIL_ADDRESS>then use whatever APIs we use in the emitter ( basically writeFile on a CompilerHost) to tell the other side to write that file to their disk/vfs

Have the TSServer host the VFS files, where it understands that extends internal calls to readFile / readDirs and when it's node_modules it also looks inside the ATA acquired files to see if it should include them

@orta Good point. My current approach would never be able to support features such as go to definition because VS Code would not have the acquired file content.
I wonder if we should have the typing installer on web delegate the actually installation logic back to VS Code. That's the first approach I considered with this PR, but it seemed overly complicated when I initially considered it. However that seems like it could cleaner than using the emit apis (which VS Code doesn't use at all currently)
To implement type installation on the VS Code side, I think we need:

A message / event where TypeScript can tell VS Code to install some typings
Some way for VS Code to tell TS that the Typings have been installed
On the VS Code side, a way to add a document to the workspace such that it is picked up by TypeScript but does not actually get committed

Is that similar to what you were thinking?

I wonder if we should have the web typing installer delegate the actually installation back to VS Code. That's the first approach I considered with this PR, but it seemed overly complicated when I thought about it. However that seems like it could cleaner than using the emit apis (which VS Code doesn't use at all currently)
To implement type installation on the VS Code side, I think we need:

A message / event where TypeScript can tell VS Code to install some typings
Some way for VS Code to tell TS that the Typings have been installed
On the VS Code side, a way to add a document to the workspace such that it is picked up by TypeScript but does not actually get committed

Is that similar to what you were thinking?

I've been thinking about this a lot (and tried knocking something together from your PR to explore it), and there is still the issue that with this ATA solution TS would be using the latest versions of every package, meaning a high likelihood of providing incorrect typings. However, it seems like what you've suggested above actually goes part way to a solution for full type acquisition. In essence, it seems like the above is needed in both directions, since:

Where possible, VS Code needs to tell TypeScript which versions of the packages to use (based on the nearest package.json)
For imports from the local project, VS Code needs to provide that imported file to TS, and it to install that file's typings (which of course means traversing and providing that file's dependencies too, probably meaning some back and forth as TS would need a way to request the missing files, or VS Code would need to provide them all upfront, and then there's the issue of keeping those files in sync since VS Code becomes the source of truth)

For a bit of context, we're specifically interested in this for utopia, where previously we were running a tsserver worker in the browser to build the user's project (providing all files upfront, storing them in memory via BrowserFS, updating and emitting the incremental build results after each file change), so that we then could provide the full set of types to Monaco (as we were using that as the file editor at the time) - maybe that's an avenue that would be of interest?

After https://github.com/microsoft/vscode/pull/184438 I think this one's no longer up to date or where we're going.


Feature Request: header title as link to site root

Use case:
As a Lagrange user, I would like to be able to browse back to the root of the gemsite by clicking on the Header Band Title (cf. screenshot)

I think this would help the "browsability" of gemsites.

Sounds useful, I'll make the banner clickable.

Also added keyboard shortcuts to navigate to root or the parent directory.


com ports

Is your feature request related to a problem? Please describe
No response
Describe the solution you'd like
please add support for com ports
Describe alternatives you've considered
No response
Please specify the version of Windows Subsystem for Android
2209.40000.26.0

Hi, thank you for this feature request. Currently this isn't on our immediate roadmap, but we're always listening to the community!  It would be great if you could provide details about what developer scenarios are blocked for you without com port access. This isn't a common feature on Android devices.


gotosocial: skip flaky test

Description of changes
Disable flaky test until it's fixed upstream: https://github.com/superseriousbusiness/gotosocial/issues/2651
See also: https://github.com/NixOS/nixpkgs/pull/286744#issuecomment-1930444694

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Result of nixpkgs-review pr 289553 run on x86_64-linux 1

1 package built:

gotosocial


Strange case on command usage

Issue Type: Bug
When I tried this in cmd.exe to create a new folder, and open it.
F:\Work>md 0301
F:\Work>code 0301

Visual Code opens a newly created (unsaved) file named 301, what I expected to be is open the newly created folder as current workspace

VS Code version: Code 1.31.1 (1b8e8302e405050205e69b59abb3559592bb9e60, 2019-02-12T02:21:36.727Z)
OS version: Windows_NT ia32 6.1.7601

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz (4 x 2394)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: unavailable_offsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Memory (System)
7.92GB (0.87GB free)

Process Argv
.

 If someone wants to look into it, feel free.

This has to do with the minimist argument parser detecting the unknown path argument as a number, and thus returning a number. As you noted, this case only really happens if the argument has a leading 0.
The only solution I could think of to avoid this behavior would be to check if any input arguments start with a 0, and then append a character to the end so that it isn't detected as a number, and then remove the character after it has been parsed. I feel like this could work since I think the only arguments that could start with zero would be folder and file names, so it wouldn't be breaking anything else. I may be missing something though, and I understand if this isn't the way you want to fix this. I'll open the pull request with my fix for you to look at.

This minimist line tells me we should define that _ should be a string. Something like the following, over here:
{ id: '_', type: 'string' }

@jmbockhorst Wanna try that?

@joaomoreno Yep, that worked. Thank you. I committed the new fix.


libosf.core cannot deal with gpslocation

It seems that the libosf.core cannot deal with channels of datatype gpslocation.
Running the "to_csv" example with python3 ./to_csv.py -i example.osf -c GPS.Location produces the following stack trace:
Traceback (most recent call last):
  File "[REDACTED]/python-osf/examples/./to_csv.py", line 58, in <module>
    main(sys.argv[1:])
  File "[REDACTED]/python-osf/examples/./to_csv.py", line 35, in main
    df = samples.make_column_based()
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[REDACTED]/python-osf/src/libosf/core.py", line 149, in make_column_based
    df = DataFrame(data=frame_data)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[REDACTED]/python-osf/venv/lib/python3.11/site-packages/pandas/core/frame.py", line 767, in __init__
    mgr = dict_to_mgr(data, index, columns, dtype=dtype, copy=copy, typ=manager)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[REDACTED]/python-osf/venv/lib/python3.11/site-packages/pandas/core/internals/construction.py", line 503, in dict_to_mgr
    return arrays_to_mgr(arrays, columns, index, dtype=dtype, typ=typ, consolidate=copy)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "[REDACTED]/python-osf/venv/lib/python3.11/site-packages/pandas/core/internals/construction.py", line 114, in arrays_to_mgr
    index = _extract_index(arrays)
            ^^^^^^^^^^^^^^^^^^^^^^
  File "[REDACTED]/python-osf/venv/lib/python3.11/site-packages/pandas/core/internals/construction.py", line 677, in _extract_index
    raise ValueError("All arrays must be of the same length")
ValueError: All arrays must be of the same length

I already narrowed it down to get_samples already producing a tuple of three arrays with different lengths (i.e., 362, 266, 362) while they should have the same length. The loop starting in L209 always extends result_timestamps by 1 element. While result_values and result_indexes are sometimes extended by more than 1 element, hence the lengths diverge.
https://github.com/optimeas/python-osf/blob/4a4d7edee679b8fcde13de8e1c9847a553b117f7/src/libosf/core.py#L185-L218

Yes, the "to_csv.py" script does not handle the gpslocation datatype correctly and it will crash. We will fix the script in the next 1-2 weeks - sorry we are really busy at the moment. In the "print_channel_data.py" script you see how the datatype is handled correctly. Also we will check the issue with the different signal lengths.


Improve performance to Zipkin exporter

Current behaviour
Zipkin exporter use JSON.stringify when exporting spans.
https://github.com/open-telemetry/opentelemetry-js/blob/b58965c97e5be0b556d83d0000eff0e3c7e25209/packages/opentelemetry-exporter-zipkin/src/zipkin.ts#L165
Desired behaviour

We could use https://github.com/fastify/fast-json-stringify (or something else)
It use Schema to speed up.
We should add tests in order to be sure that Schema is sync with ReadableSpan.

Could you make some benchmarks to see how much of a performance issue this actually would be in a production app? My understanding is that most spans would not be sampled anyway, and we only would export to Zipkin a smallish number of spans.
I see bringing in a new library as potentially exposing end users to security risks / bugs if the dependency encounters those at some point vs. the safe and built in (if non-optimal) JSON.stringify

I would be happy to make a benchmark. Do you have some exemples that could inspire me in order to provide to you something with added values or tools/packages that I could use.
I just want to avoid making a clunky benchmark.
Any feedback would be appreciate.

I don't have experience with benchmarking tool, but was thinking to use @clevernature/benchmark-regression to perform regression tests.
https://www.npmjs.com/package/@clevernature/benchmark-regression

Thanks Mayur, I will give a try

I actually think something you just do as a one-off would be fine - say a simple Node server that processes a hello-world type request, samples at 100% and exports to Zipkin. Run local server and local zipkin and then hammer it with traffic say with Apache bench or similar. See how it performs with the native JSON.stringify vs. fast-json-stringify and see the performance change in the overall server.
I'm not necessarily suggesting this is the best thing to do time right now, just that this would be my suggestion to validate that adding the dependency is worth it.
I also do think more general benchmark tests that run on every PR would be good, but I'd think that could be more for core parts of the library (though maybe Zipkin exporter would be worth doing it for as a whole).

Simpler indeed and good timing since I did https://github.com/open-telemetry/opentelemetry-js/pull/318

Using the http example in this repo (without the setTimeout on the server side):
First ab test is "as is", second is by removing the JSON.stringify and applying a RAW transformation (in order to avoid a dep) because span is not so complex (Jaeger does this too).
~/apps on 🐳 v19.03.2
➜ ab -n 5000 -c 100 http://localhost:8080/helloworld
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests

Server Software:
Server Hostname:        localhost
Server Port:            8080

Document Path:          /helloworld
Document Length:        12 bytes

Concurrency Level:      100
Time taken for tests:   9.950 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      435000 bytes
HTML transferred:       60000 bytes
Requests per second:    502.49 [#/sec] (mean)
Time per request:       199.010 [ms] (mean)
Time per request:       1.990 [ms] (mean, across all concurrent requests)
Transfer rate:          42.69 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    3   1.6      3      41
Processing:    32  194  56.1    190     445
Waiting:       14  165  50.9    161     441
Total:         32  197  56.2    192     447

Percentage of the requests served within a certain time (ms)
  50%    192
  66%    208
  75%    225
  80%    229
  90%    261
  95%    286
  98%    380
  99%    445
 100%    447 (longest request)

——————————————————————————————————————

➜ ab -n 5000 -c 100 http://localhost:8080/helloworld
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 500 requests
Completed 1000 requests
Completed 1500 requests
Completed 2000 requests
Completed 2500 requests
Completed 3000 requests
Completed 3500 requests
Completed 4000 requests
Completed 4500 requests
Completed 5000 requests
Finished 5000 requests

Server Software:
Server Hostname:        localhost
Server Port:            8080

Document Path:          /helloworld
Document Length:        12 bytes

Concurrency Level:      100
Time taken for tests:   9.413 seconds
Complete requests:      5000
Failed requests:        0
Total transferred:      435000 bytes
HTML transferred:       60000 bytes
Requests per second:    531.19 [#/sec] (mean)
Time per request:       188.258 [ms] (mean)
Time per request:       1.883 [ms] (mean, across all concurrent requests)
Transfer rate:          45.13 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2   1.8      2      17
Processing:     7  185  47.1    179     347
Waiting:        2  151  42.1    149     278
Total:          7  187  46.9    181     347

Percentage of the requests served within a certain time (ms)
  50%    181
  66%    201
  75%    217
  80%    229
  90%    254
  95%    280
  98%    298
  99%    305
 100%    347 (longest request)

Should we let the JSON.stringify ?

This is great 💯. Could you please use fast-json-stringify and run the same test?

Looks like you are saving ~10ms at the 50p latency, and ~140ms at the 99p latency.
I'm interested in what you said about "applied a RAW transformation (in order to avoid a dep)" - might that be a way to have better performance without introducing a dependency?
Do you know if fast-json-stringify supports a mode where you only include it as a dev dependency and not an install dependency? If you could have fast-json-stringify generate the function for you and then check in that function, I wonder if that could also be a way to avoid the extra install dependency but still get the performance benefit.

fast-json-stringify generate the function for you and then check in that function

fast-json-stringify is pretty small. The gain would be minimal.
On the list of things to do, this is at best very far down, and at worst more trouble than it could ever be worth.

My thinking with inlining the resulting function from fast-json-stringify rather than depending on the library is based on a security consideration - each new dependency you add, no matter how small, provides an opportunity for the author of that package to be compromised and push a vulnerable version of the package. In principle, cou would audit every single package dependency all the way down the tree when you do upgrades ..... but that's not super realistic.
So in general, I think we should have a fairly high bar to taking on a new install dependency. Dev dependencies concern me less because a vulnerability there would only affect developers of the library, not end customers and their production apps.

Seems like consensus was reached to keep using JSON.stringify? So this can be closed @dyladan


DatabaseCleaner is removing items for subsequent it blocks when using before(:all)

The issue
I am facing a very anonying issue with the DatabaseCleaner gem when dealing with the before(:all) blocks.
When using the before(:all) block, the database items will be available on the next it block, but they will not be available on all subsequent it blocks.
Please take a look at the simple code snippet below...
require 'rails_helper'

RSpec.describe Record, type: :model do
  describe 'when creating a Project' do
    before(:all) do
      @project = Project.create(name: 'Test')
    end

    it 'should have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should still have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should also still have the Project created' do
      expect(Project.count).to be_eql(1)
    end
  end
end

☝
Before configuring the DatabaseCleaner on the system, this test will pass with success. However, after configuring the DatabaseCleaner, it will pass just on the first it block and fail on all the subsequent ones, on this case, it will fail on these ones...

should still have the Project created
should also still have the Project created

Before I applied the DatabaseCleaner gem, I was doing the job to clean the database by myself. I was trully believing the DatabaseCleaner would do something similar, but it is cleaning too much.
I had this line on the version before applying the DatabaseCleaner gem... And this test was working correctly.
require 'rails_helper'

RSpec.describe Record, type: :model do
  describe 'when creating a Project' do
    before(:all) do
      Project.delete_all # Here is the change!
      @project = Project.create(name: 'Test')
    end

    it 'should have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should still have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should also still have the Project created' do
      expect(Project.count).to be_eql(1)
    end
  end
end

The configuration
I configured my spec_helper.rb file with this:
RSpec.configure do |config|
  # Configure DatabaseCleaner to automatically reset the database between tests
  config.before(:suite) do
    DatabaseCleaner[:mongoid].strategy = :truncation
  end

  config.around(:each) do |example|
    DatabaseCleaner.cleaning do
      example.run
    end
  end
end

How can I solve this?
If I change the before(:all) to simple before blocks, the problem is solved. However, the test suite become 1000x times slower, I would like to maintain the before(:all) blocks in tests that makes sense to use them.

You are telling DatabaseCleaner to cleanup around every example and this is the expected outcome of that.
If you swap to this:
RSpec.configure do |config|
  # Use truncation and clean the database to start with.
  config.before(:suite) do
    DatabaseCleaner[:mongoid].strategy = :truncation
    DatabaseCleaner.clean
  end

  # Technically this is unneeded for truncation but is the equivalent of what you are doing
  config.before(:context) do |example|
    DatabaseCleaner.start
  end

  # Truncate the DB after each context.
  config.after(:context) do |example|
    DatabaseCleaner.clean
  end
end

You should find that DatabaseCleaner cleans after every describe or context block which might help you here, but it still won't survive between contexts.

Hi @JonRowe
Thanks for the response!
I tried the first approach and this specific test with the before(:all) passed, but most part of my tests failed.
The issue is that when using before(:all), I want to remain with the database data for the its inside the context/describe block. (The example I just posted here).
However, when using the before(:each) or just before, I want to clean the database data before each it inside the context/describe block.

In other words..
This test should work (before(:all))
require 'rails_helper'

RSpec.describe Record, type: :model do
  describe 'when creating a Project' do
    before(:all) do
      @project = Project.create(name: 'Test')
    end

    it 'should have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should still have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should also still have the Project created' do
      expect(Project.count).to be_eql(1)
    end
  end
end

But this one also should work (before)
require 'rails_helper'

RSpec.describe Record, type: :model do
  describe 'when creating a Project' do
    before do
      @project = Project.create(name: 'Test')
    end

    it 'should have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should still have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should also still have the Project created' do
      expect(Project.count).to be_eql(1)
    end
  end
end

You will have to set this up manually so that cleaning occurs unless you mark that it shouldn't.
This is mostly a limitation of the truncation strategy, you simply can't have before every test database cleaning and have shared database setup.

@JonRowe 😢  Yep, looks like a limitation of the truncation strategy, because on the Active Record, I used the transaction strategy and everything worked perfectly fine.

You basically want this:
RSpec.configure do |config|
  config.before(:suite) do
    DatabaseCleaner[:mongoid].strategy = :truncation
    DatabaseCleaner.clean
  end

  config.before(:example) do |example|
    unless example.metadata[:per_context_database_cleaning]
      DatabaseCleaner.clean
    end
  end

  config.before(:context, per_context_database_cleaning: true) do
    DatabaseCleaner.clean
  end
end

RSpec.describe do
  context "", per_context_database_cleaning: true do
    before(:context) { dirty_the_db }
    it {}
    it {}
  end
  context do
    it {}
  end
end

Closing because this is a configuration issue really.

@JonRowe
Thank you very much for the response!
I really didn't understand why you closed this issue, since this still didn't work fully as expected here. 😢
I configured the spec_helper.rb with this
RSpec.configure do |config|
  config.before(:suite) do
    DatabaseCleaner[:mongoid].strategy = :truncation
    DatabaseCleaner.clean
  end

  config.before(:example) do |example|
    next if example.metadata[:context_cleaning]
    DatabaseCleaner.clean
  end

  config.before(:context, context_cleaning: true) do
    DatabaseCleaner.clean
  end
end

And these tests worked as expected:

With before

require 'rails_helper'

RSpec.describe Record, type: :model do
  describe 'when creating a Project' do
    before do
      @project = Project.create(name: 'Test')
    end

    it 'should have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should still have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should also still have the Project created' do
      expect(Project.count).to be_eql(1)
    end
  end
end

With before(:all)

require 'rails_helper'

RSpec.describe Record, type: :model do
  describe 'when creating a Project', context_cleaning: true do
    before(:all) do
      @project = Project.create(name: 'Test')
    end

    it 'should have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should still have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should also still have the Project created' do
      expect(Project.count).to be_eql(1)
    end
  end
end

However, many tests broke, because they can have nested describe/context blocks.
For example, this test is not working...

Failling test

require 'rails_helper'

RSpec.describe Record, type: :model do
  describe 'when creating a Project', context_cleaning: true do
    before(:all) do
      Project.create(name: 'Test')
    end

    it 'should have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    it 'should still have the Project created' do
      expect(Project.count).to be_eql(1)
    end

    describe 'the edge case' do
      before do
        Project.create(name: 'Test')
      end

      it 'should be equal 2' do
        expect(Project.count).to be_eql(2)
      end

      it 'should still be equal 2' do
        expect(Project.count).to be_eql(2) # Should be equal 3
      end
    end
  end
end

On the Active Record DatabaseCleaner, using the transaction strategy would avoid all of these contour solutions and would work fully as expected.
On this case, I should clean the database by myself?
If the mongoid enables the transaction strategy somehow, can be a really nice solution

I closed because this is not something database cleaner can fix.

@JonRowe So why the transaction strategy on the Active Record worked? 🤔

Because transactions wrap examples and roll back the data afterwards, so there is a start and an end. Truncation just deletes everything.

@JonRowe Exactly!! As you said

this is mostly a limitation of the truncation strategy

Would be really nice if the mongoid database cleaner allows the transaction strategy. The new versions of mongoid allows transactions 🥇
Even after configuring all of these things, we still need to manually clean the database on the test suite. That's why I believe it is not entiretly a configuration error, instead it is a limitation with the truncation strategy.


Improve watched lists performance

Performance is pretty bad when you have around 300 items on your list, a virtual list may improve this so we only add items to dom when they will be visible.
Probably a nice library we can use for this.

I tried it again, it actually doesn't seem that bad with 300 items on the list. Probably will wait for other feedback on this, may not be a problem.


adding version parameter to the GitArchiver. pep8 fixes

These are changes I needed for another project to use this script.
The version parameter for the git reference ( hash/ branch ) migth be confusing since we have hte command line "version". maybe we want a different name ?

I'd recommend you make style or PEP8 changes in a separate commit so that it is easier to review what substantive changes have been made.

@asmodehn Could you provide some summary about the changes? What issue they address?

@Kentzo
git archive expect a <tree-ish> argument :
SYNOPSIS
       git archive [--format=<fmt>] [--list] [--prefix=<prefix>/] [<extra>]
                     [-o <file> | --output=<file>] [--worktree-attributes]
                     [--remote=<repo> [--exec=<git-upload-archive>]] <tree-ish>
                     [<path>...]

       <tree-ish>
           The tree or commit to produce an archive for.

This change : https://github.com/Kentzo/git-archive-all/pull/26/files#diff-187e2427f0e961edb831c9683c10f641R108 allows the GitArchiver class to behave in a similar way by checking out the commit we want to archive.
The other changes are mostly pep8 related.

I think it would make sense to change version to treeish (or tree or whatever git's most common noun for that) at least :)

And I think it should restore previous state.
The reason why I did not implement it initially, is that I didn't come up with a reliable algorithm to checkout arbitrary version safely. So I left that work to the caller of that code.

Ah I see... so if understand correctly, the proper way to restore the working tree to that "tree-ish" revision would be : git checkout <tree-ish> -- .
From the doc :
git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>…

    When <paths> or --patch are given, git checkout does not switch branches. It updates the named paths in the working tree from the index file or from a named <tree-ish> (most often a commit)

This doesn't switch branch, and it will error if the branch does not previously exist. However it restore all files to their status at that "tree-ish" revision.
and then we probably want to force submodule update in that case...

In this latest commit, I am using a combination of :

git checkout
git reset --hard
git ls-files --others | xargs -r rm -r
to garantee that submodule checkouts are clean.

However we might want to do the submodule init + update in one place only instead of two right now (git_walk_files + end of create()).
Thanks for letting me know your feedback on this.

I'm not sure that unconditional git reset --hard is desired behavior.
I'd prefer something like that:
git stash
git checkout
archive
git checkout
git stash pop

So I kept investigating and I found out that :
git submodule deinit .
git checkout <treeish>
archive
git checkout <previous>
git submodule update --init

will clean the submodule folder properly when switching branch. So no need to remove it anymore.
Also, if there is a modification in the submodule, git will error and display an error message.
However if we want to stash user changes before switching and restoring them after, in order to not have these local changes in the archive ( on top of a different commit ), things get more complicated... I haven't found a proper way to do that reliably yet.
How about returning an error if the directory is not clean instead ? I m not sure about the exact behavior of git-archive-all currently, and if this would be troublesome or not...

FYI git submodule deinit requires git > 1.8.3.
I am not sure what are the prerequisites for git-archive-all and if this is acceptable or not.

Also I recently solved my problem of archiving a specific version by doing this submodule deinit / reinit in the calling code, as you mentioned previously.
I am happy to implement the same here, if you think this is suitable.
However I do not require this change any longer, so I am also happy to drop this pull request, if you think it s not useful / too troublesome to implement , and I can make a new one only for cosmetics ( pep8 ) changes.
Let me know, thank you !

It's very welcome, but the command must be safe to execute in a tree of any state. So it should preserve any changes and then restore them or at very last print how to restore them.

Another option, instead of changing the current tree, is to clone that
local repo into another (/tmp) location and work with it. This way the
original working tree will not be affected.
On Oct 23, 2015 6:18 AM, "Ilya Kulakov"<EMAIL_ADDRESS>wrote:

It's very welcome, but the command must be safe to execute in a tree of
any state. So it should preserve any changes and then restore them or at
very last print how to restore them.
—
Reply to this email directly or view it on GitHub
https://github.com/Kentzo/git-archive-all/pull/26#issuecomment-150359096
.

That's indeed an interesting approach. Especially if cloned with --depth 1. I cannot recall if you can clone by pointing to an arbitrary sha.
Best Regards
Ilya Kulakov

On 22 окт. 2015 г., at 20:21, AlexV<EMAIL_ADDRESS>wrote:
Another option, instead of changing the current tree, is to clone that
local repo into another (/tmp) location and work with it. This way the
original working tree will not be affected.
On Oct 23, 2015 6:18 AM, "Ilya Kulakov"<EMAIL_ADDRESS>wrote:

It's very welcome, but the command must be safe to execute in a tree of
any state. So it should preserve any changes and then restore them or at
very last print how to restore them.
—
Reply to this email directly or view it on GitHub
https://github.com/Kentzo/git-archive-all/pull/26#issuecomment-150359096
.

—
Reply to this email directly or view it on GitHub.

I made this https://github.com/Kentzo/git-archive-all/pull/27 for pep8 changes, in order to not mix two things here.
I was thinking that adding the version feature might require a bunch of tests to be sure we don't break anything...

I close this PR for now as it may modify state of the repo. Let the user manually control what needs to be archived.
If someone would like to work on that, leave a comment.


[QUESTION] The official website cannot be accessed...

https://dolphinscheduler.apache.org/zh-cn/
Not Found
The requested URL was not found on this server.
date: Fri Feb 28 15:03:37

Currently fixed, merge code causes

I noticed this problem，I will keep an eye on , thank you


luftdaten integrations always stops working after a few days

Home Assistant release with the issue:
0.92.2
Last working Home Assistant release (if known):
Was always this way (since maybe 0.85 when I started).
Operating environment (Hass.io/Docker/Windows/etc.):
hass.io on docker on odroidc2 (aarch64)
Component/platform:
https://www.home-assistant.io/components/luftdaten/
Description of problem:
After a couple of hours or days, the values of my particulate matter sensor won't update in home assistant, whereas the data show up on https://deutschland.maps.luftdaten.info
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
Not in configuration.yaml, since I use the integration frontend.
Traceback (if applicable):
Additional information:
My sensor id is 645.

More observations after doing another cycle of removing/adding my sensor:
After a while (maybe after a restart of HA), the entities are no longer found in the "states" pane but they are still in the integrations. But there are new entities named like "sensor.unnamed_device" in the states pane.

Exactly the same behavior I noticed. I was wondering if there was my hardware that was bad. But when i log in to the ESP gui it shows values on the sensors..

same problem here, has been happening for a couple of months now.
2019-05-20 13:43:19 ERROR (MainThread) [luftdaten] Can not load data from luftdaten.info 2019-05-20 13:43:19 ERROR (MainThread) [homeassistant.components.luftdaten] Unable to retrieve data from luftdaten.info

same problem here. Have to delete an add the integration every time i want to look at the values.

I can confirm this problem, too.

The Luftdaten integration is useless at the moment for me, as it keeps throwing errors.
@balloob If there is no will by the codeowner to fix it, then it should be removed from Home Assistant.

A kind of stupid workaround for me:
After the devices reappear as "sensor.unnamed_device" in the entity list (I have two of these), I just use them under this name.

@fabaff Not sure if you created the initial release, but found your name at the first commit.
Would you be able to fix the current problem we are facing with this component?
I'm happy to supply you with additional log files if needed or other.


hydra: 2017-06-22 -> 2017-07-24 (NixOS-17.03)

hydra-2017-06-22 fails to build because of the nixUnstable upgrade.
hydra-2017-07-24 builds successfully.
Cherry-pick of https://github.com/NixOS/nixpkgs/pull/27625.

https://github.com/NixOS/nixpkgs/commit/7dc735ea2917e072b42acd89bac717ee1fa8b9c4
Thanks! I forgot about my services.hydra.package = /nix/store/... workaround.


hoverable added shadow intentionally?

The hoverable class used to shade children of the class, but I just upgraded to<EMAIL_ADDRESS>and was surprised to see that my hoverable tables now also have a shadow around the entire table.  I was able to disable the shadow using:
.hoverable:hover {
  transition: none;
  box-shadow: none;
}

but am wondering if you added this shadow intentionally or if it might have slipped in by mistake?
My vote is to keep hoverable the way it was since one of the great things about Materialize is its minimal elegance.  The new default shadow seems a bit much.  Also, if we need a shadow, you already provide a nice selection of z-index shadow classes.

fixed on master. Look for duplicate closed issues


[Bug] Mathpix OCR API now costs?

Not really a bug on any of this software, but just came back to this repo to reinstall on a new Mac (I last used this project a year ago), and tried to log back into my Mathpix OCR API account. I noticed that they had made some changes to the sign in and it now looks like the OCR costs money, even within the previous 1000 free queries? Is this correct or have I misunderstood something?

If my understanding is correct, mathpix will start to charge after the first 1000 requests as it stated $0.004/request (1-100K requests). For further confirmation, maybe you need to contact mathpix customer support.

It turns out that there was an account mismatch for me that Mathpix support resolved. Looks like the first 1000 requests are still free - sorry for any confusion and thanks for the great OS project! :))


Components/events page

Description
event page for student to see what events come up.
Fixes #78
How to test?
storybook. EventPageComplete is the one to see the whole page
Checklist

[ x] I have performed a self-review of my own code
[ x] I have commented my code, particularly in hard-to-understand areas
[ x] I have made corresponding changes to the documentation
[ ] This PR is ready to be merged and not breaking any other functionality

yuka , the path of your issue is src/client/containers/EventsPage/EventsPage.component.js but you but it instead  in  src/client/components/

hi yuka , i think u still have two not successful checks


Collaborative Launch<PHONE_NUMBER> (2024-01-25 14:00 GMT, Kartograf v0.4.2)

Next collaborative launch is planned for<PHONE_NUMBER>. Please make sure to upgrade to Kartograf v0.4.2 which was released today (https://github.com/fjahr/kartograf/releases/tag/0.4.2).
./run map -w=1706191200 -irr -rv

https://github.com/fjahr/asmap-data/issues/4 has been a success but a lot of issues were fixed along the way making it hard to parse and grasp the actual process. I hope this one can the first clean run that concisely shows what the process could look like when being run routinely.
Thanks for your participation in advance! Upon completion please post your hash in the comments. When we have majority for one hash, we will open a PR, similar to https://github.com/fjahr/asmap-data/pull/6.

Engines ready! T - 4 hours...

I will join! Ready here!

Sadly, my run failed. Same error as @virtu reported in #8.

Not a match with @Sjors unfortunately:
The SHA-256 hash of the result file is: 3910796c4a706de88043646bed3de62e5a87482ee7c58b8e312ae29fc09e5638
Total runtime: 3:11:21.409145

The SHA-256 hash of the result file is: 6c850c482428d19e6c5b78f8882699b824ab1ad14432816f71e1f1a9f3d50490
Total runtime: 2:30:40.648287

The SHA-256 hash of the result file is: 30048a44cf31116a841dffee4a6760b624fcde5b20ba6679f1ef6ce6c31d9d3b
Total runtime: 15:38:24.217769

Got a match with @Sjors

I'm assuming, but I don't know, that the different hashes stem from different input data. E.g. the data was updated on the server between participants downloaded it. A few thoughts came to mind:

The data might be updated with a cronjob (or similar). Humans like round numbers, so these cron jobs might run hourly (or every 30 min, or every 10 min, or every 5 min - I'm not sure what update frequency makes sense for them). Starting a collaborative launch at exactly the full hour gives us a high chance of some participants downloading data before and some after the cronjob has finished.
The downloads run in sequence. Participants with a slower connection might ask for the last to-be-downloaded file later than a faster connection. I think, it might make sense to experiment with starting the downloads in fetch_irr() and in download_rir_tals() in parallel. This assumes the download would still continue even if the file is changed on the server. I don't know if that's the case.
To figure out if the issue stems from different input data, it might be good to implement https://github.com/fjahr/kartograf/issues/2.

These are the timestamps that the FTP servers provide for the IRR files (code):
2024-01-27   00:05                      afrinic.db.gz
2024-01-26   15:01:07	                apnic.db.route6.gz
2024-01-26   15:01:15			apnic.db.route.gz
2024-01-26   14:00:07			arin.db.gz
2024-01-26   23:08:37			ripe.db.route6.gz
2024-01-26   23:08:37			ripe.db.route.gz
2024-01-27   07:35                      lacnic.db.gz

It doesn't seem like they are updated too often. There might have been updates around the time of this collaborative launch (not sure what timezone these timestamps are).

@0xB10C Yes, the different hashes should come from different inputs unless we have found another bug :) The data that is fluctuating the most by far is RPKI, because there we download the data directly from many different decentralized repositories that can change their data every second. This is the reason why I was not expecting collaborative launch to work as well as it did the last couple of times and why a result like today should be expected sometimes.
The RPKI updates are usually manually triggered in very small increments so I don't think the start time matters there. I think it's possible that the IRR DB FTP download is updated with a cron job regularly but there is no public information on this and from my experience with the space they probably don't have a very strict or transparent policy on this. I will see if I know someone who has an idea. But if they are triggered every full hour for example, that should work perfectly well with the current implementation because RPKI is downloaded first, taking a few minutes on a fast connection. Then the IRR file is downloaded which should be updated at that point.
Running the downloads in sequence is by design currently because the RPKI data is the most volatile by far from my experience. So far every time I have analyzed the results of failed collaborative launch matches, the source was RPKI (aside from bugs). So I prioritize that everyone is getting the RPKI data as fast as possible to minimize the risk there. I believe starting the IRR downloads in parallel would lead to slightly worse results due to higher likelihood of differing RPKI data.
From what I have seen on these IRR download failures I would really put my money on some quirky issue between the ftp server and the libs that are used in the nix env because:

I have downloaded these IRR files over ftp probably about 300 times in the last couple of months. I have never seen this issue and no other tester has reported such an issue until this week. Now two nix users see it happening very frequently while the non-nix users don't see it. The only thing irritating about that is that you also haven't seen such an error in earlier runs, right?
I am not an expert on this but I did some research and usually the download shouldn't break even if the file is updated because during the download the download file is cached in memory on the server side. Some FTP implementations may not do this but I would be surprised if the RIRs would not use the most robust solution possible.

But yes, I will implement printing the hashes now, it just saved us a lot of guess-work/manual hashing when we fail :)

Hm, ok, your lacnic finding that i didn't see before writing seem to indicate that it might be interesting to look into parallel download. I am still very surprised then that I didn't see lacnic fail every. I will try to reproduce this. Maybe the nix env uses a lib where the download breaks while others don't have the same behavior.

2. I am not an expert on this but I did some research and usually the download shouldn't break even if the file is updated because during the download the download file is cached in memory on the server side. Some FTP implementations may not do this but I would be surprised if the RIRs would not use the most robust solution possible.

At an Unix like (Linux) OS, if the file is replaced the old file will stay in place for the process that opened it and gets for real erased after the file handle if closed. So the ftp server should not be interrupted by it.

Alright, unfortunately, I need to declare this one a failure. But it's not too bad, I still expected the collaborative launches not to work every time and Kartograf 0.4.4 should now be more robust against these FTP download issues and it also prints downloaded file hashes right away to make initial debugging of mismatches much easier.
So, I would be happy if as many of you as possible could join me again for the next one tomorrow, same time of day: https://github.com/fjahr/asmap-data/issues/9
@Emzy @Sjors @brunoerg @0xB10C


Should reverse verification throw an exception?

We are currently checking the rule sgn(a.compareTo(b)) == -sgn(b.compareTo(a)) but not handling any exceptions coming out of the a.compareTo(b) and b.compareTo(a) in any way. The question is should we handle this in any way?
Quoting the Comparable documentation:

The implementor must ensure sgn(x.compareTo(y)) == -sgn(y.compareTo(x)) for all x and y. (This implies that x.compareTo(y) must throw an exception iff y.compareTo(x) throws an exception.)

I guess this means that would need to rewrite the verifyReverse method to handle such case. This also brings a question should this check be eligible for suppression? I am more inclined to

if both sides  x.compareTo(y) and y.compareTo(x) throw an exception than it is ok
warn about compareTo throwing an exception even if it is symmetric
if only one side throws an exception then throw an AssertionError to communicate this

If we would introduce the concept of a warning to the library then we could have treatWarningsAsErrors option, but this needs further discussion if we have enough "warnings" to justify such option. Also we should not work on it before we have both verifiers ready.
What do you think about it? @AlexZhukovich

I think it's a great idea to support handling Exceptions because it's part of the language and we should handle them


Accessory is out of compliance

Hey there! Thanks for the example code. I was trying to get this exact code running.
It builds, and uploads to the board just fine. I configure wifi, and a pairing code. The iPhone thinks for a moment, and then this error appears:

Unable to add Accessory
Accessory is out of compliance

Given you've run this code yourself just fine, I'm wondering if Apple made some kind of update that breaks the code? Also worth noting I'm running the current latest HomeSpan (1.7.1 as of writing this).
Thanks for the great library!

I haven't run this in a while - very possible Apple made an update in recent versions of HomeKit that broke something in the sketch.  I'll revisit and see what I can find.

Thanks so much! While I have your attention,  I'm still trying to wrap my head around the underlying HomeKit architecture works.
I'm wondering if it's possible to have something beyond the hue selector. I saw in here you did something special for the eve controller. But is there no way to surface an additional tile for an additional characteristic that would allow you to control animations in the apple home app itself?
I was looking here, and it kind of looks like that's all you can do: https://developer.apple.com/documentation/homekit/hmcharacteristic/characteristic_types#3080266

I just tried the code, compiled with 1.7.1, and it pairs and works fine - did not get any errors about the device being out of compliance.  Are you running a beta version of iOS, or just production?  Do you get the same error if you run one of the Tutorial Example sketches?

Regarding your question about surfacing an additional tile to control animations, unfortunately Apple does not have anything like that for the Lightbulb Service.  However, others have created some clever combinations of other tiles: instead of using the Lightbulb Service, they model the light as a Television Service and use the Input Source Service as a way of selecting different effects (instead of different TV Inputs).  It's a little clunky but seems to work.

I’m just running the latest production release of iOS 16.3.1. Nothing special. I can run other HomeSpan sketches without a problem. When I comment out all of the animation related code it pairs without issue. It’s not a huge deal, so don’t waste your time on it. I just thought it might be some upgrade related thing that might be obvious to you. I’ve moved along with my project for the time being, and the example was helpful all the same :) Thanks a bunch for the support!Sent from my iPhoneOn Mar 24, 2023, at 8:04 PM, HomeSpan @.***> wrote:
I just tried the code, compiled with 1.7.1, and it pairs and works fine - did not get any errors about the device being out of compliance.  Are you running a beta version of iOS, or just production?  Do you get the same error if you run one of the Tutorial Example sketches?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

@HomeSpan I am also having the compliance error when compiling and adding with 1.8. Other sketches and tutorials have worked and paired just fine. Perhaps it's related to the Custom Characteristic. I might try with the TV selector, but would love to set the color as well as pick an effect.

Which sketch is causing the compliance error?


[SR-710][Frontend] Add -dump-xctest-methods

What's in this pull request?

SR-710 tracks a major goal for Swift 3: having SwiftPM/corelibs-xctest automatically generate a list of test methods to execute. Several approaches to this problem were discussed on the mailing list:

Port SourceKit to Linux, using a different form of IPC since XPC is not available.
Add a C header to libIDE (like libclang or sourcekitd). A tool to generate an XCTest "manifest" would link against libIDE and use the C header.
Add a swiftc option that would output a list of test methods. A tool to generate an XCTest "manifest" would use swiftc.

The discussion appeared to have settled on option 3. This commit implements the swiftc option: swiftc -frontend -dump-xctest-methods.
To encode all the information a manifest generation tool would need, -dump-xctest-methods outputs USRs, such as the following:
s:FC4main7MyClass55test_startsWithTest_takesNoParams_returnsVoid_andThrowsFzT_T_

These can be transformed and demangled:

Remove the "s:" prefix.
Prepend a "_T".
Run swift-demangle on the string.

A test manifest generation tool can use this new option and the steps above to generate the following for each XCTestCase subclass that defines test candidate methods:
extension MyTestCase {
  static var allTests: [(String, MyTestCase -> () throws -> Void)] {
    return [
      ("testFoo", testFoo),
      ("testBar", testBar),
    ]
  }
}

/cc @gribozavr @ddunbar
Resolved Related bug number: (SR-710)

Before merging this pull request to apple/swift repository:

[ ] Test pull request on Swift continuous integration.

Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please smoke test
    OS X platform               | @swift-ci Please smoke test OS X platform
    Linux platform              | @swift-ci Please smoke test Linux platform

Validation Testing
    Platform     | Comment
    ------------ | -------------
    All supported platforms     | @swift-ci Please test
    OS X platform               | @swift-ci Please test OS X platform
    Linux platform              | @swift-ci Please test Linux platform

Note: Only members of the Apple organization can trigger swift-ci.

Awesome!

@modocache Do you think you can add a flag which would write the output to the specified file? I think that'll make it easier to integrate this in swiftpm and will avoid using the "shell" tool.

How does the fact that a proper XCTest test method also has to be declared in a class subclassing XCTestCase fit into this? Is that going to be detected elsewhere?

looks like it is only dumping symbols for the first file in the inputs, for eg :
$ .build/debug/swiftc -frontend -dump-xctest-methods -module-name BuildTestSuite -parse-as-library -I /home/aciid/swift.org/swift-package-manager/.build/debug -I/home/aciid/swift.org/build/Ninja-ReleaseAssert/xctest-linux-x86_64 -I/home/aciid/swift.org/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation -I/home/aciid/swift.org/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation/usr/lib/swift /home/aciid/swift.org/swift-package-manager/Tests/Build/DescribeTests.swift /home/aciid/swift.org/swift-package-manager/Tests/Build/PkgConfigParserTests.swift /home/aciid/swift.org/swift-package-manager/Tests/Build/PackageVersionDataTests.swift /home/aciid/swift.org/swift-package-manager/Tests/Build/Utilities.swift
s:FC14BuildTestSuite13DescribeTests29testDescribingNoModulesThrowsFT_T_

and if I change the order of inputs :
$ .build/debug/swiftc -frontend -dump-xctest-methods -module-name BuildTestSuite -parse-as-library -I /home/aciid/swift.org/swift-package-manager/.build/debug -I/home/aciid/swift.org/build/Ninja-ReleaseAssert/xctest-linux-x86_64 -I/home/aciid/swift.org/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation -I/home/aciid/swift.org/build/Ninja-ReleaseAssert/foundation-linux-x86_64/Foundation/usr/lib/swift /home/aciid/swift.org/swift-package-manager/Tests/Build/PkgConfigParserTests.swift /home/aciid/swift.org/swift-package-manager/Tests/Build/DescribeTests.swift /home/aciid/swift.org/swift-package-manager/Tests/Build/PackageVersionDataTests.swift /home/aciid/swift.org/swift-package-manager/Tests/Build/Utilities.swift
s:FC14BuildTestSuite20PkgConfigParserTests14testGTK3PCFileFT_T_
s:FC14BuildTestSuite20PkgConfigParserTests15testEmptyCFlagsFT_T_
s:FC14BuildTestSuite20PkgConfigParserTests24testVariableinDependencyFT_T_
s:FC14BuildTestSuite20PkgConfigParserTests22testUnresolvablePCFileFT_T_

Is access control something we need to pay attention to here? I remember it being noted in a previous  discussion that a test method or class marked private would lead to a non-obvious build failure if included in a test manifest.

Is access control something we need to pay attention to here?

Yes, good point! Although it should be noted that Apple XCTest uses the Objective-C runtime to find methods, and it doesn't matter whether they're public, internal, or private. I'll update ValueDecl::isTestCandidate to, on platforms where Objective-C interop is unavailable, only return internal or public methods.

How does the fact that a proper XCTest test method also has to be declared in a class subclassing XCTestCase fit into this?

I think it might be possible to determine whether an ancestor of the class is named "XCTestCase". The isTestCandidate function I moved from libIndex didn't have that logic though--I wonder why?

Do you think you can add a flag which would write the output to the specified file?

looks like it is only dumping symbols for the first file in the inputs

I copied the implementation of -dump-parse. I assume this supports all the same things that option does, meaning perhaps -dump-parse also only dumps one file, and that this takes the same output options (does -dump-parse -o work?). I'll double check as soon as I get in front of a computer.

I don't think -o works for -dump methods, anyway its not a big issue.
Not sure about -dump-parse but I've used -dump-ast which dumps the entire module, I think it would be incorrect to "feed" all files and get result for only the first file in input.

Makes sense. I'll try to get it to either take only a single file (and error when given multiple), or take multiple files. I'll take a look at how -dump-ast does it.

I think it should take multiple files input because otherwise the module might not compile?

This is a good point, although -dump-parse does not require the code to be totally valid. I believe this option does not require valid code either--although I didn't add a test case for that.

Anyway, at this point I'm more interested in whether an option such as -dump-xctest-methods is the correct approach in the first place. I know @gribozavr preferred that option based on the mailing list discussion, but @ddunbar expressed some doubts.
I'd be more confident perfecting the behavior of this option once I was sure this is the approach we'll be taking to resolve SR-710.

We had a long discussion on this topic on Friday, but I haven't had time to write up a summary yet... I will try to get one out today.

I'd be more confident perfecting the behavior of this option once I was sure this is the approach we'll be taking to resolve SR-710.

Oh! Been working on implementing this on swiftpm 😂 ... :wq

@swift-ci please test

@swift-ci please test

@swift-ci test

@swift-ci test

@swift-ci please test

@ddunbar So what's the gist of what you all discussed last Friday? Using SourceKit? Porting it to Linux? Should SourceKit expose a xctestmethods request type? Or does the generation tool index the files and filters by methods that look like XCTest methods?

Based on a discussion amongst the core team last Friday, it looks like the preferred approach will be porting SourceKit to Linux, then using its functionality to discover tests.
Some of the feedback on this pull request can be applied to the current implementation of isTestCandidate(). I plan on sending some pull requests shortly, at which point I'll close this pull request.

@modocache  This PR is good to be closed now, right?

Yeah, I kept this one open for fun. Also, to remember the comment on AST/Module.cpp:

Yeah, the method above should be changed. I missed it when it went in this way.

But I'll probably never end up doing that anyway. Maybe it's worth creating a StarterBug task for it...?


Refacto + njre + all javas compliance

Big refactoring to simplify and enhance performances of code checking/installing java version
Replace use of deprecated package node-jre by njre
Compliance with JDK & JRE from 8 to 14 (AdoptOpenJdk releases)

Codecov Report

Merging #5 into master will decrease coverage by 0.25%.
The diff coverage is 90.96%.

@@            Coverage Diff             @@
##           master       #5      +/-   ##
==========================================
- Coverage   91.27%   91.01%   -0.26%
==========================================
  Files           1        2       +1
  Lines         149      167      +18
==========================================
+ Hits          136      152      +16
- Misses         13       15       +2

Impacted Files
Coverage Δ

lib/java-caller.js
90.90% <90.90%> (ø)

lib/index.js
100.00% <100.00%> (+8.72%)
:arrow_up:

Continue to review full report at Codecov.

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


add --max-persisted-states to configure max_on_disk_limit

Motivation
fix #8399

Solution

@mattsse added some simple test, any specific test cases need to add?


Fix Adapter TimeoutException

This include fix of timeout exception after adLoaded successfully.

Coverage decreased (-0.03%) to 22.736% when pulling 865a80e63702cd01b148c168f5147c77f155ef35 on fix-timeout-interstitial into<PHONE_NUMBER>0684e951253e28ec8b6b7c0c0ebd92 on development.

good, let's merge


missing libsql-server-v0.24.19/source.tar.gz

👋 looks like libsql-server-v0.24.19 tag got created, but the artifacts did not get uploaded for them? Thanks!

Hi @chenrui333!
We are aware of the issue. Will publish new release soon.

@chenrui333, we fixed our CI and published new release: https://github.com/tursodatabase/libsql/releases/tag/libsql-server-v0.24.20

thank you!

https://github.com/Homebrew/homebrew-core/pull/181820

^^ cc @sivukhin


Time Sync delay between Zillean and EC-lab data?

Hi, I am a relatively new user of ixdat and have come across this issue multiple times and haven't found a solution yet in the documentation. There seems to be time delay/lag when the ec and ms are combined as shown in the image attached.
These are just regular step cycles going beyond water stability to produce O2 and H2 being recorded by the ECMS. When plotting the data it seems that M32 signal increases even before the EC measurement starts and everything is offset by ~10s. Making H2 in oxidative regime is thermodynamically impossible which makes me convinced that it is some sort of time lag that is not accounted for when ec and ms are combined in ixdat.
Any help is appreciated! Thank you!

Hi @abhadou , thanks for the issue! This looks like a problem in the data, rather than with ixdat. I have some thoughts:

Are Zilien and EC-Lab running on the same computer? Both get the timestamp from the computer's clock, and two different computers might not have their time aligned to the second. The best is to run both softwares on the same computer! If they are two separate computers, do they update their clock from the internet (I think all modern Windows computers automatically do this by default.)? In your data it looks like a 5 second difference, which is a lot even for separate computers if both are connected to the internet and allowed to automatically adjust their clocks.
In my experience, when I have seen this before, it has been because the biologic potentiostat seems to get a few seconds ahead or behind in very long experiments. EC-Lab gets the timestamp from the computer's clock at the start of the measurement and then relies on the potentiostat's clock, whereas zilien uses the computer's clock throughought the measurement. The Biologic potentiostat's clock is very good at recording data with microsecond resolution when you need it, but quite lousy at keeping accurate time over many hours. This is easy to check: is the data aligned earlier in the measurement?

Either way, a "patch" solution could be to use the following code:
from ixdat.data_series import TimeSeries, ValueSeries

time_offset = 5   # how much to shift EC data to the left, in [s]

for vseries in ec.value_series:
    tseries = vseries.tseries
    new_tseries = TimeSeries(
        name = tseries.name,
        unit_name = tseries.unit_name,
        data = tseries.data,
        tstamp = tseries.tstamp + time_offset
    )
    new_vseries = ValueSeries(
        name = vseries.name,
        unit_name = vseries.unit_name,
        data = vseries.data,
        tseries = new_tseries
    )
    ec.replace_series(vseries.name, new_vseries)
    ec.replace_series(tseries.name, new_tseries)
ec.clear_cache()

ec_ms = ec + ms

That code is a bit complex because usually ixdat does everything it can to avoid absolute times changing while you adjust relative times to get the best selection of your data for analyzing, plotting, or exporting. Consider it a patch, and not a real solution. A real solution will almost have to involve hardware, to get the correct alignment in the raw data.
So let me know if either of the above possible causes of misaligned data might apply in your case.

@abhadou , did you identify the cause of the time offset?

Hi @ScottSoren, thank you for your quick response and apologies for my delay in getting back to you; I am preparing for my qual exams so got super preoccupied as the semester started.
I did have a look into the issue further and this is what I have so far:

I was already using ec+ms to combine the two files to make an ECMS measurement file. The EC and MS data were read separately using Measurement.read_set for importing both the EC and MS data with the corresponding reader and technique [EC: reader = 'biologic', technique = 'EC', MS: reader = 'zilien', technique = 'MS']. The problem does exist despite using this each time I make an ecms plot.
EC lab and ziliean are actually running on the same laptop for us (just using an additional monitor to have both the screens open simultaneously) so hopefully the problem should not stem from that- if the time is different it should be equally different for them both.
Thank you for your piece of code and yes, I was using a similar offset (just in the final raw data from the ms.grab function) in order to align the HER/OER peaks with the step cycles and shift the entire spectrum accordingly. I did play around with the absolute time extraction code you sent and consistently across a variety of experiments (on different days over many months) there is a tstamp difference between the ms and ec as shown below.

Sample experiment 1:

Experiment 2:

I am guessing the difference between the two tstamp values would be the time sync delay (in ms?) but still not sure of the source of it. I think your last explanation makes the most sense in my case since we do experiments over long periods of time especially over an entire 6-8hr period. I am not sure if there is an internal fix for that but for now just adding the offset time seems to be a short-term solution.
I think using a trigger measurement might also do the trick but not sure about what would be an accurate run of it (apart from aligning the OER/HER in step cycles). I will run some tests to see if the delay starts off at the start of the experiment or begins to occur towards the longer times (i.e. if it is a consistent delay across the entire time or if it varies). I am hoping it is a consistent constant delay (or else using ecms for longer experiments might become very tricky)
Thank you again for looking into the matter and I appreciate your time and input!
P.S. I read your papers and thesis - a big fan of your work :))

Hi @abhadou ,
Thanks for the looking into it and getting back here!
Good test to check that the MS tstamps and EC tstamps are offet. However, this would be expected if the two instruments started their measurements at different times. Is this the case? It looks in both cases like the EC measurement starts on the order of 10000 seconds later (which would make sense if you start your MS measurement in the morning, do some preparation, and then start the EC measurement when you actually do your experiment), so I don't think it's related with the approx 5 second offset that arises when you combine them.
If it is the Biologic potentiostat's clock which is the problem, I'm afraid I only can think of complex solutions - if you find a simple one I'd love to know so please post it here!
A known complex solution, which I once used during my PhD at Technical University of Denmark (pre-Spectro Inlets and pre-ixdat).

The hardware implementation was to use BioLogic's Trigger Out method inbetween the measurement steps (or right before the LOOP step) and use a DAC (digital-to-anolog converter) to give an auxiliary input to a USB port in the PC connected to the mass spectrometer. I think we used this DAC: https://www.analog.com/en/products/ad5667.html#product-overview with this python driver: https://github.com/CINF/PyExpLabSys/blob/master/PyExpLabSys/drivers/analogdevices_ad5667.py. The voltage in V from the DAC (approx. 0 normally and approx 5 V when the trigger was applied) was stored as a column in the MS data file. I got help from Kenneth Nielsen (now at Spectro Inlets) and Robert Jensen (now back at DTU) - they are better than me for this kind of thing.
The data treatment was then to identify where the triggers were, find the change in loop number or file number closest to each one, and then linearly adjust all the time in the EC data to line them up. The implementation is here:
https://github.com/ScottSoren/EC_MS/blob/f7c12f9f2180950ca929d6da9ca2767479a2e106/src/EC_MS/Combining.py#L1324. Forgive the poor code readability. ixdat should have a better version of that function, which we can write when/if someone starts using triggers in this way.

Come to think of it, I have never spoken with Biologic about this issue. If the experiment time vs computer clock time could be stored in the header of a .mpt file, for example, it would eliminate the need for a trigger between data acquisition hardwares in this case. I'll ask around.
P.S. Thanks :) That makes it feel like the work was worth it. Hope you come to hear the same from readers of your thesis!

@ScottSoren @abhadou With regard to the poor timer in the Biologic potentiostats. I have had a fix for this in mind, but I have never been prompted by customer requests to do anything about it before possibly with this issue. So, I would like to know if you can trace the issue back to that core problem. The way to fix on the ECMS Zilien side, I think, is to measure the biologic timer offset multiple times during the EC measurement and make a linear correction to the potentiostat times instead of just measuring it once and make a constant correction. BTW. Having the problem fixed in that manner would involve letting Zilien merge the data files which newer version of Zilien do. So no matter what I suggest you upgrade to the latest version.
@matenestor this issue should be on your radar as well.


CLOUDSC low-level GPU (transpilation) via Loki (CUF/CUDA)

Still work in progress ...
Corresponding CLOUDSC branch nams-cloudsc-low-level-GPU
Build via cloudsc-bundle build --clean --arch=arch/ecmwf/hpc2020/nvhpc/22.11 --with-loki --with-gpu --with-cuda
New modes/binaries:

./bin/dwarf-cloudsc-loki-idem-lower CPU variant with lowered block index
./bin/dwarf-cloudsc-loki-idem-lower-loop CPU variant with lowered block index and loop
./bin/dwarf-cloudsc-loki-scc-parametrise-cuda SCC-PARAMETRISE CUDA C
./bin/dwarf-cloudsc-loki-scc-hoist-cuda SCC-HOIST CUDA C

Furthermore, usage of pipelines:
SCCLowLevelCufParametrise = partial(
    Pipeline, classes=(
        SCCBaseTransformation,
        SCCDevectorTransformation,
        SCCDemoteTransformation,
        SCCRevectorTransformation,
        LowerBlockIndexTransformation,
        InjectBlockIndexTransformation,
        LowerBlockLoopTransformation,
        SccLowLevelLaunchConfiguration,
        SccLowLevelDataOffload,
        ParametriseTransformation
    )
)

SCCLowLevelCufHoist = partial(
    Pipeline, classes=(
        SCCBaseTransformation,
        SCCDevectorTransformation,
        SCCDemoteTransformation,
        SCCRevectorTransformation,
        LowerBlockIndexTransformation,
        InjectBlockIndexTransformation,
        LowerBlockLoopTransformation,
        SccLowLevelLaunchConfiguration,
        SccLowLevelDataOffload,
        HoistTemporaryArraysAnalysis,
        HoistTemporaryArraysDeviceAllocatableTransformation
    )
)

SCCLowLevelParametrise = partial(
    Pipeline, classes=(
        InlineTransformation,
        GlobalVariableAnalysis,
        GlobalVarHoistTransformation,
        DerivedTypeArgumentsTransformation,
        SCCBaseTransformation,
        SCCDevectorTransformation,
        SCCDemoteTransformation,
        SCCRevectorTransformation,
        LowerBlockIndexTransformation,
        InjectBlockIndexTransformation,
        LowerBlockLoopTransformation,
        SccLowLevelLaunchConfiguration,
        SccLowLevelDataOffload,
        ParametriseTransformation
    )
)

SCCLowLevelHoist = partial(
    Pipeline, classes=(
        InlineTransformation,
        GlobalVariableAnalysis,
        GlobalVarHoistTransformation,
        DerivedTypeArgumentsTransformation,
        SCCBaseTransformation,
        SCCDevectorTransformation,
        SCCDemoteTransformation,
        SCCRevectorTransformation,
        LowerBlockIndexTransformation,
        InjectBlockIndexTransformation,
        LowerBlockLoopTransformation,
        SccLowLevelLaunchConfiguration,
        SccLowLevelDataOffload,
        HoistTemporaryArraysAnalysis,
        HoistTemporaryArraysPragmaOffloadTransformation
    )
)

Thank you for the review @reuterbal!
I have no objections to your comments and want to apologise for the large PR...
However, it seems that you have no general objections regarding the implementation/splitting of transformation/etc.
I'll tackle your comments and see whether I can split up the PR into multiple smaller PRs.

As discussed offline: I have removed the commit that points to the custom CLOUDSC branch. After merging this PR, we can create a new Loki release.
Subsequently, please file a corresponding CLOUDSC PR against develop that adds the transpilation targets in the CMake there and points to the new Loki version.
Once that's in CLOUDSC develop, we can also enable (at least the idem variants) in the test_cloudsc.py of the regression tests.
As soon as CI tests are green I will merge. Thanks again!


DNS flag day - EDNS buffer size recommendation. Issue #10293

[ ] Redmine Issue: https://redmine.pfsense.org/issues/10293
[ ] Ready for review

https://dnsflagday.net/2020/:

Message Size Considerations
The optimum DNS message size to avoid IP fragmentation while minimizaing the use of TCP will depend on the Maximum Transmission Unit (MTU) of the physical network links connecting two network endpoints. Unfortunately, there is not yet a standard mechanism for DNS server implementors to access this information. Until such a standard exists, we recommend that the EDNS buffer size should, by default, be set to a value small enough to avoid fragmentation on the majority of network links in use today.
An EDNS buffer size of 1232 bytes will avoid fragmentation on nearly all current networks. This is based on an MTU of 1280, which is required by the IPv6 specification, minus 48 bytes for the IPv6 and UDP headers.
Note that this recomendation is for a default value, to be used when better information is not available. Operators may still configure larger values if their networks support larger data frames and they are certain there is no risk of IP fragmentation. DNS server vendors may use higher (or lower) packet sizes if better information about the MTU is available from the kernel.

now it can calculate EDNS buffer size limit by taking the smallest MTU - max IPv4 header (60 bytes IP + 8 bytes UDP = 68).
does not allow too small sizes:
minimum for IPv4-only setup = 512
minimum for +IPv6 setup = 1232
extra sizes on services_unbound_advanced.php page:
1232 (IPv6 minimum)
1432 (1500 - 68)
1480 - seems incorrect, although recommended by unbound and CoreDNS, left for backward compatibility.
see interesting discussion:
https://github.com/dns-violations/dnsflagday/issues/125
and https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-01


OCP  formulation

The main issue is that in this code
https://github.com/Thuong-ironman/OCR_2023/blob/b5b40a7aff4eea136e968212b5d882780eae84d2/OCP_SinglePendulum.py#L24-L36
You have a 0 that multiplies the position error.
Still this shouldn't resolve all the issues.
I will get a closer look

I actually don't know where issues could be
I suggest you creating a new script just to test the OCP formulation.
In that file copy the problem parameters, and solve a single OCP problem starting from 1 condition.
Create all the different plots and make sure that they make somehow sense.
If not, you have to add some debug traces and see if the cost function is evaluating to something meaningful

One more idea: do not initialize the guess of the state to zeros, but to random numbers (uniform distribution in -1,1 should be fine). Such initial guess might be already optimal, even though constraints are not satisfied.
But I don't know how the solver works, thus it might be an issue.


Decay functions and Generalized Costs

This adds documentation for two new features slated for public release: distance decay functions and generalized cost from specialized OSM tags.
It also fixes a Google Analytics problem with non-production deployments of the docs.
This is marked draft because it needs another round of cleanup and writing.

I did some more fact-checking and cleanup to match recent backend changes. This should be ready for review and potentially Kodiak automerge @ansoncfit


How to compute the F1 score over a dataset?

Orion version: 0.1.7
Python version:3.6
Operating System:Ubuntu 18.04.5 LTS

Description
In NAB dataset for Art, it has 6 signals. how to compute the F1 score for Art?
I cannot find the concrete descriptions for the computation of F1 in Orion.
I use the mean F1 socre.
What I Did
I have used the Tadgan pipeline to detect the NAB(art) and got the 6 signals' F1 scores for NAB(art), how to compute the Art F1 score overall?
#score_art_daily_flatmiddle.csv
F1 = 1
#score_art_daily_jumpsdown.csv
F1 = 1
#score_art_daily_jumpsup.csv
F1 = 1
#score_art_daily_nojump.csv
F1 = 1
#score_art_increase_spike_density.csv
F1 = 0.666667
#art_load_balancer_spikes.csv
F1 = 0.5

The mean F1 score for Art
I use the mean of the SIX  F1 scores.
0.86

Hi @kanesp, this is a good question. Here is how we compute the F1 score over a dataset (e.g., Art):
We don't use the mean of the F1 score for each signal; instead, we maintain four variables sum_tp, sum_tn, sum_fp, and sum_fn to record the total number of tp, tn, fp, and fn for all the signals – in your case should be the SIX signals in Art dataset.
Calculate precision/recall/f1 score individually and then use mean of them may suffer from the following problem:

the number of anomalies in different signals can be very different; some may contain many while some may contain only few and even zero. So they are very unbalanced and simply using mean can lose such information;
tp, fp, and fn for the individual signal can be often zero, leading to None value for precision/recall/f1. In this case, it's hard to decide whether we should count it in the computation of mean.

thank u! i find the tp, tn, fp, and fn are computed in orion/evaluation/contextual.pywith the function contextual_confusion_matrix.   Is it used to compute the  tp, tn, fp, and fn?  At the same time , in  the function contextual_confusion_matrix,  expectedis the ground truth, observed  is the detected anomalies, but what is  the data?  is the whole dataset (like nyc_taxi.csv)?

@kanesp the data is the timeseries, it is an optional argument used to extract the start and end of the timeseries. If you do not provide it, we extract it from observed and expected.


feat: add log pipe to explorer

What type of PR is this?

[ ] bug
[ ] feature
[ ] enhancement

What problem(s) does this PR solve?
Issue(s) number:
Description:
How do you solve it?
Special notes for your reviewer, ex. impact of this fix, design document, etc:

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: mizy:x: bruce.lubruce.lu seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Kansa Analysis: Timeline analysis module

2 things come to mind as a potential analysis module:
Something similiar to 'log2timeline' tool.
OR
Timeline of the data collected from the modules that were run.

How about an analysis script that converts collected data to fls bodyfile format so log2timeline can ingest it? Or even modifying Kansa.ps1 to support an fls bodyfile output format?

Thats a great idea, thanks


Possible weird behaviour in LookUpScripts.PrepareQuery

This code (from a custom lookupscript)
protected override void PrepareQuery(SqlQuery query)
        {
               query
                .From("Patient")
                .Select("ID")
                .Select("PatientID")
                .Select("FirstName")
                .Select("LastName")
                .Select("PhoneNumer")
                .Select("FirstName + ' ' + LastName, "PatientName")
                .OrderBy("LastName");
        }

--Results in this invalid query (SQL server profiler). The problem is the from statement (it constructs a crossjoin). Is the From method called later after PrepareQuery ?
SELECT
ID,
PatientID,
FirstName,
LastName,
PhoneNumer,
FirstName + ' ' + LastName AS [PatientName]
FROM [dbo].[Patient] T0, [Patient]
ORDER BY LastName

OK, I found out that if I exclude the call to query.From it will work.
This Works
query
                .Select("ID")
                .Select("PatientID")
                .Select("FirstName")
                .Select("LastName")
                .Select("PhoneNumer")
                .Select("FirstName + ' ' + LastName, "PatientName")
                .OrderBy("LastName");

Yes thats it


Update CI tests

Run CI tests on Julia LTS, stable, and master.

This library probably needs quite a bit of updates. I've been waiting on getting it updated before adding it to the main docs, and adding regression tests to it.

We should disable the tests on travis-ci.org, it seems currently they run both on travis-ci.com and travis-ci.org.

Hmm seems tests on Travis run with DiffEqBase 6.20 whereas locally tests passed with DiffEqBase 6.29. Maybe we should just lower bounding DiffEqBase?

Yes, that should help. Note that I think callbacks will be broken for sure, and they aren't tested.

Ah I just noticed, the problem is StochasticDiffEq. Tests fail with version 6.17 but it is the latest version that is compatible with Julia < 1.2. Should we just drop support for Julia < 1.2 in StochasticDelayDiffEq?

Yes, just up it to at least v1.3.

OK, I guess this is good to go, tests pass now on Julia 1.4 and master. I'd suggest creating separate PRs for adding more tests and fixing bugs. Can you disable the tests on travis-ci.org? I don't have any permissions for StochasticDelayDiffEq it seems.


[1] Add bootstrap

https://github.com/byhbt/kwtool/issues/1
What happened 👀
As a User, I can see the homepage of the website.

[x] Remove default style and CSS from Phoenix framework.
[x] Integrate Bootstrap SCSS via webpack.
[x] Bootstrap styles loaded to the page.
[x] Add the core-js dependency

Insight 📝

[x] The website homepage display properly on the browser.
[x] No error in the browser console.

Proof Of Work 📹

This PR also needs request tests. learn more in the ExUnit conventions on Compass.

I added the request test.


Text to big and overflowing

Hi,
Im using this library, but on some devices when the text is bigger, the writing doesnt all show up, and the widget doesnt expand to fill all the text.
Attached is a screen shot.

The full text is "This apointment is urgent", and the second option is "This apointment can wait a day or two". But as you see, its not showing the full text.
Here is my full code of the widget.
  DropdownButtonFormField2(
                decoration: InputDecoration(
                  isDense: true,
                  contentPadding: EdgeInsets.zero,
                  border: OutlineInputBorder(
                    borderSide: BorderSide(color: Colors.blue, width: 0.0),
                    borderRadius: BorderRadius.circular(15),
                  ),
                  // label: Text('Gender'),
                  //Add more decoration as you want here
                  //Add label If you want but add hint outside the decoration to be aligned in the button perfectly.
                ),
                isExpanded: true,
                hint: Text(
                  'Priority',
                  style: TextStyle(fontSize: 20),
                ),
                items: priorityDropDownList
                    .map((item) => DropdownMenuItem<String>(
                  value: item,
                  child: Text(
                    item,
                    style: TextStyle(
                      fontSize: 20,
                    ),
                  ),
                ))
                    .toList(),
                validator: (value) {
                  if (value == null) {
                    return 'Priority';
                  }
                  return null;
                },
                // value: selectedValue == 'NONE' ? null : selectedValue,
                onChanged: (value) {
                  //Do something when changing the item if you want.
                  // ref.read(intValueProvider.notifier).state = getIntFromStringValue(value!);
                  selectedPriority = value!;
                },
                onSaved: (value) {
                  // selectedValue = value.toString();
                },
                buttonStyleData: const ButtonStyleData(
                  height: 60,
                  padding: EdgeInsets.only(left: 0, right: 10),
                ),
                iconStyleData: const IconStyleData(
                  icon: Icon(
                    Icons.arrow_drop_down,
                    color: Colors.black45,
                  ),
                  iconSize: 30,
                ),
                dropdownStyleData: DropdownStyleData(
                  decoration: BoxDecoration(
                    borderRadius: BorderRadius.circular(15),
                  ),
                ),
              ),

Duplicate of https://github.com/AhmedLSayed9/dropdown_button2/issues/163

Wait, are you referring to the height not the width?

Height

Set isDense to false and you can increase itemHeight using menuItemStyleData.height.

So there is no way that the height will automatically adjust based on how many lines is needed for the text?

So there is no way that the height will automatically adjust based on how many lines is needed for the text?

Currently, no. That's because the menu height is being calculated based on items heights.
The only way to make this work is to make sure menu height is predefined instead. but that means menu height could have an empty space at the end too.
Anyway, this is relevant to the open which demand a predefined menu height too.


Off-artboard artwork for many SVGs

I am working on a SVG-in-OT version of NotoEmoji, and I notice that many SVGs contain leftover artwork beyond the art board (or viewBox). For example, all the glyphs containing 1F485:

Using the SVG font, the result ends up looking like this:

I realize that cleaning up the SVGs might not be a high priority, but I would appreciate such work (rather than doing the same downstream on my end).
There must be a programmatic way to find outlines outside the view box, but unfortunately I have not found anything yet – pointers are welcome!
Thanks!

How do you run nanoemoji? The --clip_to_viewbox option should already be enabled by default, unless you set --noclip_to_viewbox CLI flag, or equivalent clip_to_viebox = false in the config.toml that your may feed nanoemoji.

Also maybe upload the source .SVG file and the exact command to reproduce, thank you!

I do use the raw .svg provided in this repo and wrap them into a SVG-in-OT font (repo and workflow here: https://github.com/adobe-fonts/noto-emoji-svg)
At this moment I don’t use nanoemoji, but perhaps I could extract a method to understand how the clipping works.

Ah so you are not using nanoemoji! I misunderstood then. The clipping happens in picosvg actually, nanoemoji simply calls picosvg with that option.

Sorry I was confused when I read the repository title "noto-emoji" I misread and thought you had posted this on the nanoemoji GitHub repo.. 😅

Thanks again for the pointers here!
For anyone reading this, the necessary command is picosvg --clip_to_viewbox file.svg
👍

Rather late +1 to use picosvg. My understanding is these surprising off-board assets are very helpful to the designers so we wouldn't want to alter the source.


MissingMethodException crash running tests with Presto

Installed Presto and it crashes with the following exception:
[8/30/2019 9:00:57.059 AM Error] System.MissingMethodException: Method not found: 'Boolean Microsoft.VisualStudio.TestWindow.Controller.TestRunConfiguration.get_Debug()'.
   at PrestoCoverage.PrestoCoverageCore.OnTestExecutionStarting(Object sender, OperationStateChangedEventArgs stateArgs)
   at PrestoCoverage.PrestoCoverageContainerDiscoverer.OperationState_StateChanged(Object sender, OperationStateChangedEventArgs e) in C:\Projects\PrestoCoverage\PrestoCoverage\PrestoCoverage\PrestoCoverageContainerDiscoverer.cs:line 73
   at System.EventHandler`1.Invoke(Object sender, TEventArgs e)
   at Microsoft.VisualStudio.TestWindow.Controller.OperationData.<>c__DisplayClass43_0.<OnStateChanged>b__0()
   at Microsoft.VisualStudio.TestWindow.Extensibility.ILoggerExtensions.CallInternalWithLogging(ILogger2 log, Action action, Boolean shouldThrow)
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.VisualStudio.Telemetry.WindowsErrorReporting.WatsonReport.GetClrWatsonExceptionInfo(Exception exceptionObject)

Using VS2019, net472

Please track https://github.com/ppumkin/PrestoCoverage/issues/17 for fixes


Build errors in terraform tenant pipeline

I can't see this error in our XKS pipelines but for one tenant I can see it.
When I run make locally on my computer it works without any issues.
Digest: sha256:5ee2e1d098e1228e7c49387b9cf570f567b662237ba289a11b7d926fcc1d1849
Status: Downloaded newer image for ghcr.io/xenitab/github-actions/tools:2022.10.1
[Errno 13] Permission denied: '/work/.azure/versionCheck.json'
Traceback (most recent call last):
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/cloud.py", line 474, in get_active_cloud_name
    return cli_ctx.config.get('cloud', 'name')
  File "/opt/az/lib/python3.10/site-packages/knack/config.py", line 99, in get
    raise last_ex  # pylint:disable=raising-bad-type
  File "/opt/az/lib/python3.10/site-packages/knack/config.py", line 94, in get
    return config.get(section, option)
  File "/opt/az/lib/python3.10/site-packages/knack/config.py", line 208, in get
    return self.config_parser.get(section, option)
  File "/opt/az/lib/python3.10/configparser.py", line 782, in get
    d = self._unify_values(section, vars)
  File "/opt/az/lib/python3.10/configparser.py", line 1153, in _unify_values
    raise NoSectionError(section) from None
configparser.NoSectionError: No section: 'cloud'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/az/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/az/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/__main__.py", line 38, in <module>
    az_cli = get_default_cli()
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/__init__.py", line 910, in get_default_cli
    return AzCli(cli_name='az',
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/__init__.py", line 86, in __init__
    self.cloud = get_active_cloud(self)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/cloud.py", line 555, in get_active_cloud
    return get_cloud(cli_ctx, get_active_cloud_name(cli_ctx))
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/cloud.py", line 477, in get_active_cloud_name
    _set_active_cloud(cli_ctx, default_cloud_name)
  File "/opt/az/lib/python3.10/site-packages/azure/cli/core/cloud.py", line 468, in _set_active_cloud
    cli_ctx.config.set_value('cloud', 'name', cloud_name)
  File "/opt/az/lib/python3.10/site-packages/knack/config.py", line 161, in set_value

Could the following be something to look in to?
https://learn.microsoft.com/en-us/cli/azure/azure-cli-configuration?view=azure-cli-latest#cli-configuration-file
environment {
    AZURE_CONFIG_DIR = "${env.WORKSPACE}/.azure"
}

This is not a problem, i was using a old template version and was why i got the issue.


Address synthetic flaky tests

Context
It has been detected several flaky tests and the goal of this issue is to make them more stable.
The tests encountered so far are:

network › timings for aborted requests. Pipeline
CLI › TLS site with self-signed cert › succeeds succeeds with --ignore-https-errors. Pipeline
CLI › screenshots with device emulation. Pipeline

Findings
@emilioalvap have done some findings:
"some of the unit tests for synthetics are relying on the cli pipe to emit message individually but under certains circumstances two or more can be passed in the same event, making the out not-Json-parseable"

To provide more details on some of the flakiness that I found, locally it all came down to CLIMock class and the interaction with the spawned node process that executes cli.js:
this.process.stdout.on('data', dataListener);

Some tests are relying on data recevied through the handler to be a JSON object, which would be the case if the output were to be 1:1 between processes:
expect(JSON.parse(cli.output()).journey).toEqual(

Local tests have shown that this condition is not always met, where the chunk received from the node process corresponds to a) multiple JSON objects, or b) a chunk of a large JSON object (mainly blobs).
This section of node docs might be relevant in this situation.

Moving to the 8.2 board