Feature Request: Add separate icons for function declaration and definitions in the OUTLINE for C sources

Add separate icons for function declaration and definitions in the OUTLINE for C sources

The func() on the outline has same symbol/icon for declaration and definition, this can be changed.
Also, a decoration can be added for static functions, like adding a S subscript/superscript to the icon, similar to PyCharm's private functions (starting with _).

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


Feature: get distribution from node

Now user can take a conditional distribution from node.
Tests are included.

Codecov Report

Merging #76 (a361562) into master (4f7fe72) will increase coverage by 1.09%.
The diff coverage is 80.48%.

@@            Coverage Diff             @@
##           master      #76      +/-   ##
==========================================
+ Coverage   64.35%   65.44%   +1.09%
==========================================
  Files          32       32
  Lines        2250     2298      +48
==========================================
+ Hits         1448     1504      +56
+ Misses        802      794       -8

Files Changed
Coverage Δ

bamt/nodes/base.py
69.76% <66.66%> (-0.24%)
:arrow_down:

bamt/nodes/mixture_gaussian_node.py
78.87% <70.00%> (+1.26%)
:arrow_up:

bamt/nodes/conditional_mixture_gaussian_node.py
87.03% <72.72%> (+2.57%)
:arrow_up:

bamt/networks/base.py
52.31% <80.00%> (+3.68%)
:arrow_up:

bamt/nodes/conditional_gaussian_node.py
86.23% <80.00%> (+0.66%)
:arrow_up:

bamt/nodes/logit_node.py
84.61% <83.33%> (-0.39%)
:arrow_down:

bamt/nodes/gaussian_node.py
85.07% <85.71%> (+0.69%)
:arrow_up:

bamt/nodes/discrete_node.py
98.41% <88.88%> (-1.59%)
:arrow_down:

bamt/nodes/conditional_logit_node.py
79.43% <90.00%> (+0.86%)
:arrow_up:


[PUI] fix infinite loop if classic frontend is disabled

Fixes #8575

@SchrodingersGat this seems to work; But could you verify before merge? This seems to easy


feat(autodiscovery/precommit): initial implementation

Fix #2431
Implement autodiscovery for precommit
Test
To test this pull request, you can run the following commands:
cd pkg/plugins/autodiscovery/precommit
go test

Additional Information
Tradeoff

Potential improvement

Neat!

I don't have any precommit configuration locally, but maybe @v1v does, as I think he is using that tool at Elastic

Indeed, I'll enable it in our repositories as soon as a new release is out :)


cmake: 3.27.8 -> 3.28.1

Description of changes

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
[x] 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
[x] 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.

Reopened version of #275075
Previous people that participated in previous PR: @AndersonTorres @2xsaiko
Sorry for the noise caused by the previous PR

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

I should have maybe stressed more that you should follow the steps in that link. Sorry! 😅

I thought I did, maybe I did something wrong by mistake 😭
It's okay, I'll be more careful next time, sorry again for the trouble

@gracicot please rebase

It should be good to go! Thank you for the review.
If it would happen that this particular CMake version create problems, there is 3.28.2 coming out in a few days. It has merged some regression fixes.

@AndersonTorres ofborg seem to fail since I rebase. I'm not sure if it's caused by this PR or not, as it was not causing errors before the rebase.

It was the same exact error on https://github.com/NixOS/nixpkgs/pull/285472 and https://github.com/NixOS/nixpkgs/pull/286473.
Three strikes? It looks like a bug on Staging!

Let me know if there's anything I can do to help getting this PR merged, other than keeping it rebased 😄

Let me know if there's anything I can do to help getting this PR merged, other than keeping it rebased 😄

Seeking mergers on Discourse, Discord, Matrix, Telegram, e-mail, telephone, snail mail or in person is a good idea.

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


Caching

Caching is a serious issue we face while developing, Hence before ensuring that your view is incorrect and is having styling bugs and wasting endless hours on the internet looking for the solution, make sure you all clear the cache and reload the page once to check.
Could also test the page in a different browser/ incognito mode.

@sdthapar @Shubham617 @zhuyifan @zkiihne

A follow up on this.

While committing ensure you enter a descriptive measure of your commit using the "-m" flag.
If making several changes separate them with a "+" sign
First letter of the commit must be a capital letter
Commit message must not be past tense, i.e. use "Add"/"Fix" etc. instead of "Added"/"Fixed"

All of these guidelines will be shifted to CONTRIBUTING.md later on in the root directory

Moved to wiki


build fixes for zig dev 0.14.0-dev.1820+ea527f7a8

Catching up with some latest Zig compiler & build system changes.
Not sure of the include dir change is correct but it's working at least when running zig build test and zig build run-example-interpreter
for #104

CI won't pass with this change since CI uses 0.13 and this fixes 0.14 dev.

Thank you for working on this! You are welcome to update the ci in the PR if you want.
I'm unsure of if I want to merge this into main, or if I want this in a dev branch of some kind. I'll give that some thought before merging

Yeah, better think it through where these devel versions should live.  One alternative would be to keep main as the "latest possible zig version" and then a branch per real zig versioned release.  IMO this model generally makes it a little easier to know where to work on new stuff as it'll always be main.

You are welcome to update the ci in the PR if you want.

Why didn't I think of that. 😄 I force-pushed an updated commit and it's passing now.

Yeah I agree keeping main as following Zig master is a good idea. I'll branch off the commit before this one to make a Zig 0.13.0 branch as needed


Site works locally but not on GitHub Pages

Most likely a noob question. I've scoured the internet and the issue list but I can't seem to find a solution to my problem. The theme works locally but when uploaded to github I'm hit with a 404 see image below:

My github page with the code can be found here. Any idea what could be the issue?
The url for my page is here

Other than you have no posts yet, your site looks fine to me.
You probably didn’t give GitHub enough time to finish building your site. That first build isn’t instant.
https://harpalsahota.github.io/

I think I'm getting somewhere but I don't know if what I'm doing is correct. I've moved content out of _site/home.md into index.md which is the root directory. The page no longer shows a 404 but the content is not loading. Again this works fine locally, but not on pages.
This is what it looks like locally for me:

Check your content. You have this page under _pages that is likely causing havoc with your index.md file
https://github.com/harpalsahota/harpalsahota.github.io/blob/master/_pages/_.md
They both have the same permalink and are overwriting each other.


Bump RMQ tag for multiple versions

Allows up to run the intermediary RabbitMQ version upgrades before a SLURP upgrade to Caracal.

Could you add a release note?


Update SweetHome3d to 6.4.2

/verify

Any clue as to why the check fails?
As an FYI: the previous manifest would not succeed; for some reason the download always stalls after a few (50?) MB; even downloading the 7z-file through Firefox didn't succeed. This is why I looked into the details. Downloading/installing v6.4.2 worked without problem.

@jovandeginste SweetHome3D is already at 6.6
If there are new updates to be made, please create a new PR

Okay


Deriving Reconcile on a struct with a MaybeMissing leads to compilation error

I'm trying to use autosurgeon with MaybeMissing instead of Option.  I would expect the following code to work:
 use autosurgeon::{hydrate::MaybeMissing, Hydrate, Reconcile};

#[derive(Hydrate, Reconcile)]
struct S {
    s: MaybeMissing<String>,
}

But it leads to this compilation error:
error[E0277]: the trait bound `MaybeMissing<std::string::String>: Reconcile` is not satisfied
   --> src/main.rs:3:19
    |
3   | #[derive(Hydrate, Reconcile)]
    |                   ^^^^^^^^^ the trait `Reconcile` is not implemented for `MaybeMissing<std::string::String>`, which is required by `&MaybeMissing<std::string::String>: Reconcile`
4   | struct S {
5   |     s: MaybeMissing<String>,
    |     - required by a bound introduced by this call
    |
    = help: the following other types implement trait `Reconcile`:
              bool
              i8
              i16
              i32
              i64
              u8
              u16
              u32
            and 17 others
    = note: required for `&MaybeMissing<std::string::String>` to implement `Reconcile`
note: required by a bound in `autosurgeon::reconcile::MapReconciler::put`
   --> /home/matt/.cargo/registry/src/index.crates.io-6f17d22bba15001f/autosurgeon-0.8.3/src/reconcile.rs:114:15
    |
114 |     fn put<R: Reconcile, P: AsRef<str>>(&mut self, prop: P, value: R) -> Result<(), Self::Error>;
    |               ^^^^^^^^^ required by this bound in `MapReconciler::put`

I'm curious to learn whether this is expected to work or not.
P.S. if there is any available way to induce the compiler to tell me what the other types in the "and 17 others" error is, that'd be awesome to learn about too!

Fix is out in 0.8.4


Parameter Help auto generation in PowerShell Functions

Prerequisites

[X] I have written a descriptive issue title.
[X] I have searched all issues to ensure it has not already been reported.

Summary
If you go above the parameter block of a function and write "##" the parameter help template is pre-generated automatically by the PowerShell Extension. However currently this generates:
<#
    .SYNOPSIS
    Short description

    .DESCRIPTION
    Long description

    .PARAMETER exampleParam
    Parameter description

    .EXAMPLE
    An example

    .NOTES
    General notes
    #>

However, it is best practice to also specify the return value of your function by using ".OUTPUTS", therefore it would be nice if this could be added to the default template / if the default template could be configured in the settings.json.
Proposed Design
This could be accomplished by either:
Static Design
Add ".OUTPUTS" to the current template
Dynamic Design
Add the possibility to specify the fields in the template in a list like:
 "powershell.extentention" : {
      "parameterHelp" : {
           "generatorTemplateFields" : [
               ".SYNOPSIS", ".DESCRIPTION", ".PARAMETER", ".EXAMPLE", ".NOTES", ".OUTPUTS"
            ]
      }
 }

@fasteiner is there a reason why we shouldn't add the complete template rather than just output? thanks for your help!

@SydneyhSmith I meant that the current template should be extended to also include ".OUTPUT". So it is also possible to always add the whole template (because this should also contain .OUTPUT)


make Timeline::get's disk IO async through spawn_blocking

THIS IS THE NEWER VERSION OF https://github.com/neondatabase/neon/pull/4215 - it uses tokio::sync instead of parking_lot
Summary
Before this PR, we'd execute the synchronous IOs inside Layer::get_value_reconstruct_data on the tokio main executor threads.
This has a bunch of problems:

We limit IO parallelism among all the timelines to the number of tokio main executor threads (default: ncpus (?))
While we do IO, no other async code can run on that executor thread.
So, we starve other async tasks that are runnable.

I found this while analyzing https://github.com/neondatabase/neon/issues/4154 .
I have no concrete hypothesis for why 4154 would be caused by above problems.
But, I know that 4154 happens only on the CI runners.
The CI runners are notorious for high CPU usage, which, with regards to task starvation,
has the same effect as blocking the executor threads through blocking IO.
So, even if this change makes 4154 go away, this is not a fix for it.
But anyways, the problems above are severe enough to be worth a fix, regardless of 4154.
Implementation
At a high level, this PR makes the following changes Layer::get_value_reconstruct_data to become an async trait method that executes the synchronous IO code inside spawn_blocking.[^1]
[^1]: Should we be using block_in_place instead?
Rust doesn't have async trait methods yet, so, the method is still sync,
but we make it return a boxed future.
The boxed future can outlive the get_value_reconstruct_data invocation.
So, we have to move all the arguments into the boxed future.
This primarily affects how the ValueReconstructState is handled.
Before this PR, it was passed in as a &mut.
With this PR, we pass it in by value and the future returns it back.
So, it will be moved through a bunch of get_value_reconstruct_data futures over the course of a Timeline::get call.
Inside the boxed future, we use spawn_blocking to execute the same synchronous code that we had before this patch.
We could switch to tokio::fs in the future, but, that would require getting rid of the std::sync primitives used inside the various Layer types.
Precursors to enable that simple change are the following (listed in order in which I discovered the need for them):

Convert Timeline::layers from std::sync::RwLock to tokio::sync::Rwlock.

Required so that we can await the future retunred by Layer::get_value_reconstruct_data.

Make TimelineWriter Send by using a tokio::sync::Mutex for Timeline::write_lock.

It needs to be Send because a a bunch of places need to hold it across await points.

basebackup import: pre-lock the layer map for the DatadirModification::flush() calls

Required because DatadirModifcation::flush uses retain(|| {  }). We can't await in that closure, but we need to, because down in its callgraph we need access to the InMemoryLayer.

I think this is fine because the checkpointer thread isn't launched yet, so, keeping layer map lock held is no problem.
But, I wonder why the checkpointer isn't launched yet / won't we queue up all the basebackup contents in RAM?

[ ] TODO: check above, maybe there's a way to replace retain ?

Keep holding layer map lock inside compact_level0_phase1

Before this PR, we drop it temporarily.
But, we need to keep holding it because when we re-aquire it, it becomes an await point.
That makes the future not-Send, but, we require it to be Send because it runs inside task_mgr::spawn, which requires the Fut's to be Send.

[ ] TODO check if this is still true

Convert Tenant::timelines from std::sync::Mutex to tokio::sync::Mutex.

Required because we sometimes hold Tenant::timelines while awaiting lock of Timeline::layers.

A dirty hack to allow using async inside the closures that we pass to Tenant::state.send_modify()

Required because Tenant::activate needs to lock Tenant::timelines

[ ] TODO: investigate whether we can move the locking out of send_modify. I think we can't?

Performance
Anticipiated performance impact:

Our core data path now depends on tokio::sync primitives being high-performan
Due to the increase in await points on the core data path, we're now more exposed to tokio scheduler performance.
Each get_value_reconstruct_data call now allocates the returned boxed future.
These are short-lived allocations, and, for a given Timeline::get call, there's only
one of them at a time.
Maybe we could pre-allocate these at the beginning of Timeline::get,
or have a slab cache of sorts.
But I think given that we will do system call, the direct overhead of the allocation is miniscule.
Fragmentation may become an issue, which could be solved through a slab cache.
The spawn_blocking has overhead, because, it's basically a thread pool underneath.
In total, I'd still expect that no longer blocking the executors has a positive impact on
currently un-monitored metrics like the p9X of the time an async task waits to be polled.

Maintainability
The use of the Send-able lock guards is my biggest concern.
For example, with them, it's no longer a compile-time error to download_remote_layer while holding the layer map lock.
If we believe that we can't catch such issues in code review, perhaps it's better to reduce hold times of Tenant::timelines and Timelines::layers first.
Then, we can await the get_value_reconstruct_data without holding locks.
The above would be preferable but I believe asyncifying the IO path is more important right now.
Closing Notes
obsoletes https://github.com/neondatabase/neon/pull/4215
refs https://github.com/neondatabase/neon/issues/4154

For example, with them, it's no longer a compile-time error to download_remote_layer while holding the layer map lock.

Parking-lot locks can be non-Send. Also there is a clippy lint await_holding_lock for using std::Mutex in async environment in some nightly version of Rust compiler (with some false positives), so we should be fine.

This PR got merged piecemeal, last PR in the stack is https://github.com/neondatabase/neon/pull/4498 and its description references all the preliminary PRs.


API should allow successful response of a blocking invoke to be just the result object

The current action activation API states that a successful blocking invoke responds with an activation record, which contains among various properties, the result of the activation. This is not convenient if the result of the activation needs to be consumed by a third party service. Hence, the API should provide an option to project the result from the activation on the server.
Note: The CLI provides a --result option which projects the result response from the activation result on the client side.

A projection on the activation result makes sense if we stop there. We should be careful about feature creep with requirements on settings response headers, mime types, etc. Such capabilities should belong in a separate service.

Current activation result is on the following:
GET .../activations/123
{
  "name": "echo",
  "subject": "guest",
  "activationId": "123",
  "publish": false,
  "annotations": [],
  "version": "0.0.1",
  "response": {
    "result": {
      "message": "Hello"
    },
    "success": true,
    "status": "success"
  },
  "end":<PHONE_NUMBER>085,
  "logs": [],
  "start":<PHONE_NUMBER>077,
  "namespace": "guest"
}

@rabbah , do you envision something like that?
GET  .../activations/123?excludeMetadata=true
"response": {
    "result": {
      "message": "Hello"
    },
    "success": true,
    "status": "success"
  },

On the CLI:
wsk -v activation get 123 --excludeMetadata

This is related to the actions API not the activations API endpoints. A request to invoke an action via POST /actions/name?blocking=true currently returns an activation record W as the one you showed above. Instead I am suggesting POST /actions/name?blocking=true&result=true to return W.response.result instead for a successful activation (status code 200).

Fixed by #432.


Update ofc-bootstrap OFC components to 0.12.2

Signed-off-by: Alistair Hey<EMAIL_ADDRESS>Description
Bump various references to updated components to match 0.12.2 version
How Has This Been Tested?

Checklist:
I have:

[x] checked my changes follow the style of the existing code / OpenFaaS repos
[ ] updated the documentation and/or roadmap in README.md
[x] read the CONTRIBUTION guide
[x] signed-off my commits with git commit -s
[ ] added unit tests

/close
you already did it :p


Currency field misaligned and input indented on IE7

Browser
IE7
Operating System
Windows 7
Screenshot

Our browser support for IE7 is "functional", I wouldn't fix this.

CC @armstrongb I'm closing this but it might be something you still want to track for the pattern library.


Allow SMTP notification without user/password

I'm running Mailrise (https://github.com/YoRyan/mailrise) for my SMTP relay to then use any Apprise notifier.  It works fine when I test it, but I can't save my settings as I don't have a username/password set.  Any chance to remove that restriction?

1.0.2 updated for this

It appears this still might be an issue; though the requirement for a UID/PW was removed when setting up the alert, it'll fail with Missing credentials for "PLAIN" when attempting to send SMTP without credentials.
It looks like this project had the same issue: https://github.com/directus/directus/issues/5652
I was able to get it working by manually setting the following line to auth: false,: https://github.com/louislam/uptime-kuma/blob/2461f5084e2ef58f3ecfd6f1ece8ade7faa4cb8e/server/notification.js#L376-L379
So I assume a check just has to be made first to check if a UID/PW is set, and if not, set auth to false?

It appears this still might be an issue; though the requirement for a UID/PW was removed when setting up the alert, it'll fail with Missing credentials for "PLAIN" when attempting to send SMTP without credentials.
It looks like this project had the same issue: directus/directus#5652
I was able to get it working by manually setting the following line to auth: false,:
https://github.com/louislam/uptime-kuma/blob/2461f5084e2ef58f3ecfd6f1ece8ade7faa4cb8e/server/notification.js#L376-L379
So I assume a check just has to be made first to check if a UID/PW is set, and if not, set auth to false?

Should be fixed in 1.3.0


[qqmusic] Fix song extraction when certain formats are unavailable

Some songs do not have hq (320k) versions available. This fixes it by checking if the url is valid before adding to formats.
Also includes a small change to get the thumbnail url for a song based on the album mid.

@jaimeMF Thanks, switched to using _check_formats instead.

Thanks. Merged.


Adapter config for default_transaction_mode: IMMEDIATE

I am trying to use sqlite in a project and have noticed that there is no option to set a IMMEDIATE transaction mode globally.
This has been brought up before here: https://github.com/elixir-sqlite/ecto_sqlite3/issues/151 and the conclusion was to have the responsibility on the caller.
I want to raise the question again to have a configuration on the adapter level and maybe even make it default.
Here are 2 convincing sources:

https://fractaledmind.github.io/2024/04/15/sqlite-on-rails-the-how-and-why-of-optimal-performance/
The author did extensive testing with Rails and concluded that it is not viable to have DEFERRED in a typical Rails application. And to me a typical Rails application has the same usage pattern as a Phoenix application.

In a context where you only have one connection or you have a large amount of transactions that only do read operations, this is great for performance, because it means that SQLite doesn’t have to acquire a lock on the database for every transaction, only for transactions that actually write to the database. The problem is that this is not the context Rails apps are in. In a production Rails application, not only will you have multiple connections to the database from multiple threads, Rails will only wrap database queries that write to the database in a transaction. And, when we write our own explicit transactions, it is essentially a guarantee that we will include a write operation. So, in a production Rails application, SQLite will be working with multiple connections and every transaction will include a write operation. This is the opposite of the context that SQLite’s default deferred transaction mode is optimized for.

https://highperformancesqlite.com/watch/transaction-modes
Aaron Francis is a well known database expert and his sqlite course is amazing. Here are some quotes:

So on the application side, whenever you connect to the database, you're going to want to set your transaction mode to immediate.

You'll need to look up for your specific framework how to connect to the database and how to make sure that all of the rights are wrapped in a begin immediate transaction. Most web frameworks wrap the rights in a transaction regardless, and so you're looking for the thing where you can set, alright, we want that to be an immediate transaction. I think the rails adapter for SQLite, I think that does that by default. I know in PHP, you can set a p d o attribute to set it to immediate. So you'll have to do a little bit of digging.

To summarise: IMMEDIATE transaction mode makes the most sense for a web application. Passing manually mode: :immediate is not a good experience.
Main question: Are the maintainers open to a config on adapter level? In Rails the config is called default_transaction_mode: IMMEDIATE, we could do the same.
I am happy to do the work, with some pointers where to start best.

It doesn't bother me if someone adds it. Right now I've settled on using:
defmodule MyApp.Repo do
  use Ecto.Repo, adapter: Ecto.Adapters.SQLite3, otp_app: :my_app

  def immediate_transaction(fun_or_multi) do
    transaction(fun_or_multi, mode: :immediate)
  end
end

I have a few cases in my personal project where I want deferred and opt into immediate mode for transactions. This has to do with multiple processes reading from the database at the same time. In my use case, I wanted as low as possible blocks to reads as I can because this is a heavy read application with low writes.
If you want to add the option, you are more than welcome to try it out. Although you will need to do that change in exqlite because that is where the DBConnection interface is defined.
https://github.com/elixir-sqlite/exqlite/blob/81cf923b979eaee1ae748a516b39452046e64592/lib/exqlite/connection.ex#L252-L281
Keep in mind, we are going through some reworking of the underlying adapter sqlite implementation and the ecto adapter to better consolidate responsibilities.
You'll need to add to the %Connection{} struct a new field :default_transaction_mode and default it to :deferred since that was the original implementation.
def handle_begin(options, %{transaction_status: transaction_status, state.default_transaction_mode: state.default_transaction_mode} = state) do
  mode = Keyword.get(options, :mode) || default_transaction_mode || :deferred
  # ...
end

Then you'll probably need to shim that default mode into do_connect/2
  defp do_connect(database, options) do
    # ... with block ....
    state = %__MODULE__{
      default_transaction_mode: Keyword.get(options, :default_transaction_mode, :deferred)
    }
    # ...
  end

You'll then need to update the connection_opt() type definition to include the new transaction mode option and finally add it to the doc block.

Thanks for the tips. I'll pick it up in a week.

Personally though, I still think having the helper function defined on the Repo is far more telling to the reader that this transaction is deferred vs immediate.
I have this in my application's Repo definition
  def immediate_transaction(fun_or_multi) do
    transaction(fun_or_multi, mode: :immediate)
  end

  def deferred_transaction(fun_or_multi) do
    transaction(fun_or_multi, mode: :deferred)
  end

And use it like multi |> Repo.deferred_transaction() or multi |> Repo.immediate_transaction()
BUT, with the changes I suggested above for the default transaction mode it won't break my application and is a reasonable ask.

@warmwaffles I create a PR for exqlite. When it's merged, I'll add one for the current repo with some more documentation.

@warmwaffles And the follow-up PR with docs: https://github.com/elixir-sqlite/ecto_sqlite3/pull/155


Missing output from wp

On a Mac M1 I built the CBAT Docker image and ran the container. All files appear to be present and I am able to run the various wp analyses from the CBAT tutorial. However, they do not produce output, e.g., bap wp --func=main --trip-asserts 01/binary/main should show "SAT! ..." but instead displays nothing. On the other hand,  CBAT places an input in RDI that will trip the assert when I put the output in a .yml file and use it to initialize bildb:
bap wp --func=main --trip-asserts --bildb-output=init.yml 01/binary/main
followed by
bap 01/binary/main --pass=run --run-entry-point=main --bildb-debug --bildb-init=init.yml. This helps, but in some situations I need the standard wp output.
(I don't know if the following is related, but the only atypical thing about my installation is that the Dockerfile resulted in an error at the stage cd cbat_tools/bildb; \ opam config exec -- make. I could proceed by commenting out opam config exec -- make and then modifying the Makefile in the /home/opam/cbat_tools/bildb directory to comment out every mention of plugin.uninstall. AFAICT, bildb is working normally.)

Hi, I also meet with this problem. Have you solved it already? I think it actually has something to do with its internal log/print suppressed, but I haven't found a way to enable it.


HTML printer gets tripped over by some special characters

.env
# Generic
TEXT_EMBEDDINGS_MODEL=sentence-transformers/all-MiniLM-L6-v2
TEXT_EMBEDDINGS_MODEL_TYPE=HF  # LlamaCpp or HF
USE_MLOCK=false

# Ingestion
PERSIST_DIRECTORY=db
DOCUMENTS_DIRECTORY=source_documents
INGEST_CHUNK_SIZE=500
INGEST_CHUNK_OVERLAP=50
INGEST_N_THREADS=4

# Generation
MODEL_TYPE=LlamaCpp # GPT4All or LlamaCpp
MODEL_PATH=eachadea/ggml-vicuna-7b-1.1/ggml-vic7b-q5_1.bin
MODEL_TEMP=0.8
MODEL_N_CTX=1024  # Max total size of prompt+answer
MODEL_MAX_TOKENS=512  # Max size of answer
MODEL_STOP=[STOP]
CHAIN_TYPE=betterstuff
N_RETRIEVE_DOCUMENTS=2000 # How many documents to retrieve from the db
N_FORWARD_DOCUMENTS=500 # How many documents to forward to the LLM, chosen among those retrieved
N_GPU_LAYERS=2

Python version
Python 3.11.3
System
Manjaro
CASALIOY version
05cbfc0d3f2a2c2632405fcc85fd940ee4468164
Information

[X] The official example scripts
[X] My own modified scripts

Related Components

[ ] Document ingestion
[ ] GUI
[X] Prompt answering

Reproduction
Reproduction steps:

Perform ingestion step
Run python casalioy/startLLM.py
Enter } as a query and wait for answer to complete
Program will crash with a stack trace

Example:
(casalioy-py3.11) [v@v-home CASALIOY]$ python casalioy/startLLM.py
found local model dir at models/sentence-transformers/all-MiniLM-L6-v2
found local model file at models/eachadea/ggml-vicuna-7b-1.1/ggml-vic7b-q5_1.bin
ggml_init_cublas: found 1 CUDA devices:
  Device 0: NVIDIA GeForce GTX 1650 SUPER, compute capability 7.5
llama.cpp: loading model from models/eachadea/ggml-vicuna-7b-1.1/ggml-vic7b-q5_1.bin
llama_model_load_internal: format     = ggjt v2 (pre #1508)
llama_model_load_internal: n_vocab    = 32000
llama_model_load_internal: n_ctx      = 1024
llama_model_load_internal: n_embd     = 4096
llama_model_load_internal: n_mult     = 256
llama_model_load_internal: n_head     = 32
llama_model_load_internal: n_head_kv  = 32
llama_model_load_internal: n_layer    = 32
llama_model_load_internal: n_rot      = 128
llama_model_load_internal: n_gqa      = 1
llama_model_load_internal: rnorm_eps  = 1.0e-06
llama_model_load_internal: n_ff       = 11008
llama_model_load_internal: freq_base  = 10000.0
llama_model_load_internal: freq_scale = 1
llama_model_load_internal: ftype      = 9 (mostly Q5_1)
llama_model_load_internal: model size = 7B
llama_model_load_internal: ggml ctx size =    0.08 MB
llama_model_load_internal: using CUDA for GPU acceleration
llama_model_load_internal: mem required  = 4865.04 MB (+  512.00 MB per state)
llama_model_load_internal: allocating batch_size x (512 kB + n_ctx x 128 B) = 320 MB VRAM for the scratch buffer
llama_model_load_internal: offloading 2 repeating layers to GPU
llama_model_load_internal: offloaded 2/35 layers to GPU
llama_model_load_internal: total VRAM used: 610 MB
llama_new_context_with_model: kv self size  =  512.00 MB
AVX = 1 | AVX2 = 1 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | FMA = 1 | NEON = 0 | ARM_FMA = 0 | F16C = 1 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 1 | VSX = 0 |

Enter a query: }
Stuffed 1 documents in the context
HUMAN:
Unfortunately, I cannot answer this question without a clear question statement. Please provide me with the question again and make sure it is relevant to the given extracts
llama_print_timings:        load time =  2381.26 ms
llama_print_timings:      sample time =    14.64 ms /    39 runs   (    0.38 ms per token,  2664.12 tokens per second)
llama_print_timings: prompt eval time =  2381.22 ms /   121 tokens (   19.68 ms per token,    50.81 tokens per second)
llama_print_timings:        eval time =  6776.55 ms /    38 runs   (  178.33 ms per token,     5.61 tokens per second)
llama_print_timings:       total time =  9231.88 ms
.Traceback (most recent call last):
  File "/home/v/compile/CASALIOY/casalioy/startLLM.py", line 135, in <module>
    main()
  File "/home/v/compile/CASALIOY/casalioy/startLLM.py", line 131, in main
    qa_system.prompt_once(query)
  File "/home/v/compile/CASALIOY/casalioy/startLLM.py", line 110, in prompt_once
    print_HTML(
  File "/home/v/compile/CASALIOY/casalioy/utils.py", line 39, in print_HTML
    print_formatted_text(HTML(text).format(**kwargs), style=style)
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/v/compile/CASALIOY/.venv/lib/python3.11/site-packages/prompt_toolkit/formatted_text/html.py", line 113, in format
    return HTML(FORMATTER.vformat(self.value, args, kwargs))
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/string.py", line 194, in vformat
    result, _ = self._vformat(format_string, args, kwargs, used_args, 2)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/string.py", line 203, in _vformat
    for literal_text, field_name, format_spec, conversion in \
ValueError: Single '}' encountered in format string

Expected behavior
Program does not crash but prints prompt and answer correctly.
There's also a different minor issue here with the final token (dot in the given example) being printed after llama timings dump, not sure it's worth reporting separately.

Thanks, i'll look at it later in time since it's not critical. On it rn here
Besides escaped { } the dot character should not cause any issues.

I had similar situation and I stopped the process since I thought that something went wrong and now every time I start my vscode.. it keeps killing my bash session..
Do I have to restart ingesting everything again? it will be great if there is a way to know if the machine is still working or stuck.. any suggestion/idea? Thanks in advance!

Ingesting itself should be a very fast process unless you are talking about terrabytes of data. So just run the /casalioy/ingest.py with a y flag to create a new vector store. I'll add this onto my watchlist anyways.


How can I compute module completion ratios with the KO list from GhostKOALA?

Hi there,
I would like to compute module completion ratios with the KO list from GhostKOALA. It seems I can use the script ko_mapper.py to do this. But I am not sure how to run this script. How is the input file look like? Do you have any example to run this script?
I only installed the MicrobeAnnotator, and have not set up the database as it's too hard to install on our server.
Looking forward to your reply.
Thanks.
Yan

Hi, I too think that a little more documentation for ko_mapper.py would help a lot! Thanks a lot for an awesome tool

Hi, unfortunately, neither of us have time to do this right now.
Another tool I have helped with a few years ago may give you what you want. It was written for GhostKOALA output.
https://github.com/bjtully/BioData/tree/master/KEGGDecoder


Fix voting to handle Constitution Actions

Following fixes are applied:
Added placeholder reaction on voting message just to be cool
fix policy breaking when checking for a maybe value
Policy breaks when checking for community_origin a field that's optional
used hasattr instead
update discord democracy starterkit to work
Accept votes on constitution policies in discord

This all looks good to me, thanks. I love the idea of reaction placeholders!


Indenting is different on OSX and Windows

Godot version
3.3.2 Stable
System information
Big Sur 11.2.3 MacBook Air (M1, 2020)
Issue description
I would like to preface this by saying that this is not a huge bug and does not need to be treated as a priority, this is just something that I personally find annoying and frustrating.
When I write my code, I like to comment by indenting at the end of the line and explaining what the line does.
On my Windows desktop, the indented lines line up just fine. When I open the GD file in another text editor on windows or OSX, the indented lines are still lined up. When I open the gd file on my Macbook Air, the indented lines are no longer lined up.
When I correct the intending on OSX it then becomes broken on windows.
Here is a screenshot of the script file in the Godot Editor on my Mac

Here is the same script file opened in Sublime Text on my Mac

Here is the script file opened in the Godot Editor on Windows

In my Editor on both Windows and OSX I have left the tab options at the default (see attached screenshot)

I have not tested how the indenting is formatted on Linux. If there is documentation on how to fix this that I have missed I am sorry. I have googled around for 2 days and have not found anything that seems to resolve this issue.
Thank You
Steps to reproduce
This isn't an issue with game performance or the engine (to my knowledge), this seems to just be an issue in the editor.
Steps to reproduce would be to comment at the end of a line, and open the project on another platform.
Minimal reproduction project
I have created a project with the script file in question.
TestProject.zip

It's probably caused by the difference in default font hinting mode on macOS and Windows. Try setting Editor Settings→Interface→Editor→Font Hinting to the same value on both OS.

Wow, that totally fixed it. My Laptop was on none and my windows pc was on light

@bruvzg Is there a way to solve this font metric discrepancy in 3.x when hinting is disabled?


Bug | Bogue

Summary | Résumé
Reduce minimumExposureDurationMinutes

One paragraph explanation of the bug, including why it is a problem (i.e. what does it prevent a user from doing or accomplishing). Screenshots are greatly helpful here too.

New variants of concern are known to propagate through briefer generations (as little as 24 hours) and on shorter contacts. Please consider reducing minimumExposureDurationMinutes from the existing arbitrary value of 15.

Hey @LeadSongDog , apologies for the shuffling. In keeping with our newly really release #31 practices, I've moved this up into the covid-alert-documentation repo as our central point for taking input from folks outside the team, and am converting the issue into a Discussion.


Please add namespace

I would recommend to add the @valantic/ namespace to the NPM package => @valantic/webpack-dependency-hint.

Adjust the namespace and published the package => https://www.npmjs.com/package/@valantic/webpack-dependency-hint


Setup Botwinder for discord

Set up the botwinder discord bot for our public discord.
At a minimum it should:

Give people a friendly welcome message when they join the server
Auto-assign them to the HEROES role

Future features:

Contribution help info
github integration:  brodcast commits, pull requests and merges

Done!  Thanks @RheaAyase ! :clap:


Add support for F#-style Pipeline Operator

PR adding pipeline operator support to TypeScript. The proposal is currently a stage 1 proposal for EcmaScript. It "introduces a new operator |> similar to F#, OCaml, Elixir, Elm, Julia, Hack, and LiveScript, as well as UNIX pipes and Haskell's &. It's a backwards-compatible way of streamlining chained function calls in a readable, functional manner, and provides a practical alternative to extending built-in prototypes."
const square = (n: number) => Math.pow(n, 2);
4 |> square |> console.log; // 16

Currently this is a minimal implementation of pipeline operator, but I'm planning on making a F# variant support and after that a Topic/Smart pipeline variant PRs.
Partial application is a good pair for minimal/F# pipeline operator and has it's own PR at #37973. I'm planning on making a separate draft PR that has both features in them.
There is also a PR for Hack-style pipelines with # as a placeholder token.
Code status
This works minimally. The TS transformer generates valid JS and there's working type inference.  There are many bugs, inconsistencies with specs, insufficient error messages currently. Most of failing tests are not included in this PR since Playground won't get generated with any failures and having faulty baselines is shady. I'm eagerly awaiting feedback, testing and even help with this PR. Even using and talking of these features will help advance them through TC39 proposal process!
await is currently not supported.
I used @rbuckton 's work on pipelineStage1 branch as a guide.
Testing
Playground link
To test it in your project, add following to your package.json:
{
    "devDependencies": {
        "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/100059/artifacts?artifactName=tgz&fileId=D3836CF7DD5F6438481C5BCDBEE7A63AB21880164FEFD2BD75085B15EB974FCE02&fileName=/typescript-4.3.0-insiders.20210404.tgz"
    }
}

and then run npm install.
PR state

[ ] There is an associated issue in the Backlog milestone (required)
[X] Code is up-to-date with the master branch
[X] You've successfully run gulp runtests locally
[X] There are new or updated unit tests validating the change

Why a draft PR for stage 1 proposal?
The TypeScript officially follows EcmaScript / stage 3 proposals. However, I'm opening this draft pull request despite it being only stage 1. The partial application and pipeline proposals now are in a stage where they want people to test the features - write it in their code, find problems, test existing codebases. The usual way these would be done is through a Babel plugin, but since a few years ago, just a plain text editor with syntax highlighting is no longer the default JS development environment.
TypeScript is no longer just a build step. It's used by a significant portion of JS developers for all their development, even when prototyping new code. If the tool chain of these developers requires TypeScript, then a simple Babel plugin won't help. This means that writing TypeScript with those features is impossible without first-class support for them in TypeScript.
But then could we ask them to write just plain JS instead? It turns out that TypeScript is more and more part of normal JavaScript development process with Language Server Protocol pointing out errors in code and providing typing information. Having people encounter red squigglies and disappearing type information as soon as they use the new language feature will not count favourably to the user experience. I believe having TypeScript support for new syntax proposals as important or even more important than having a Babel plugin.
I was considering creating and upkeeping a separate fork, but that would just mean duplication of work. There's already a great infrastructure for TypeScript with playgrounds, CI, etc. With a draft PR, new features can more easily get more eyes, testers and feedback. There will eventually be issues and questions on new features for TypeScript and github.com/microsoft/TypeScript is where anyone would first look up info on partial application.
Of course, I'm not expecting merging until the proposal reaches stage 3.

@typescript-bot pack this.

Nice! I have wondered myself how pipeline operators would play with typescript, especially how the types would flow. You could have went the way of only parsing and type checking, and letting e.g. babel do translation, but since you have also done translation this is really easy to try out.
I did test it out and ran in to a type inference limitation which I hope can be fixed or it will be hard to use with complex types:
const ns = [1, 2, 3, 4, 5];

function map<T, R>(f: (t: T) => R) {
    return (ts: T[]): R[] => ts.map(f);
}

const result = ns |> map(x => x * x);

index.ts:8:16 - error TS2571: Object is of type 'unknown'.

8 ns |> map(x => x * x);

Here T must be inferred from the type of ns.

@Pokute: If it helps at all I have two old branches where I started to look into implementing pipeline as well:

https://github.com/microsoft/TypeScript/tree/pipelineStage1 - Limited to only the pipeline operator
https://github.com/microsoft/TypeScript/tree/rbuckton/pipeline - Pipeline, partial application, and a few other concepts. Older than pipelineStage1 and much more experimental

Nice! I have wondered myself how pipeline operators would play with typescript, especially how the types would flow. You could have went the way of only parsing and type checking, and letting e.g. babel do translation, but since you have also done translation this is really easy to try out.

Writing the transformer was actually pretty simple as soon as I had the parsing and type checking in place.

I did test it out and ran in to a type inference limitation which I hope can be fixed or it will be hard to use with complex types:
Here T must be inferred from the type of ns.

I think that the form that TypeScript seems to internally handle it is map(x => x * x)(ns).
This is an interesting case where the type of a function would be resolved from it's usage and it's not directly either. I'm interested whether there are existing cases of this happening within TypeScript.
In the simplest cases, it feels like it should be possible to resolve the type. Beyond that is out of my expertise. :-)
Either way, thank you for an interesting test case!

Is there a way to try pipeline operator and partial application together?

When I found this PR I nearly cried. Thank you.

Hey folks, I stumbled upon this PR from https://github.com/tc39/proposal-pipeline-operator#build-tools. I'm not able to access the tarball mentioned here https://github.com/microsoft/TypeScript/pull/38305#issuecomment-623049381 and I'm just wondering if it's been removed intentionally.

Hey folks, I stumbled upon this PR from https://github.com/tc39/proposal-pipeline-operator#build-tools. I'm not able to access the tarball mentioned here #38305 (comment) and I'm just wondering if it's been removed intentionally.

At least I haven't removed the tarball. I wonder if those have limited lifetimes. Any ideas @orta?

Yep, looks like they timeout - we're having a chat about what to do in the long term, but for now I'll give it another 10-12 days.
@typescript-bot pack this

Nice! I have wondered myself how pipeline operators would play with typescript, especially how the types would flow. You could have went the way of only parsing and type checking, and letting e.g. babel do translation, but since you have also done translation this is really easy to try out.
I did test it out and ran in to a type inference limitation which I hope can be fixed or it will be hard to use with complex types:
const ns = [1, 2, 3, 4, 5];

function map<T, R>(f: (t: T) => R) {
    return (ts: T[]): R[] => ts.map(f);
}

const result = ns |> map(x => x * x);

index.ts:8:16 - error TS2571: Object is of type 'unknown'.

8 ns |> map(x => x * x);

Here T must be inferred from the type of ns.

Running in the same issue, without this sort of inference the usage of the operator is very limited, not sure if this can help but currently the only place I sow proper inference with a pipe implementation is this (not the operator a simple pipe function):
https://github.com/gcanti/fp-ts/blob/master/src/pipeable.ts#L97

This is great, I might take a stab at adding the Hack-style proposal (see https://github.com/tc39/proposal-pipeline-operator/issues/167#issuecomment-631878219 - it's the Smart proposal without the minimal proposal) to Flow.

One of the greatest updates.
Just in case, here's the working:
 "devDependencies": {
    "@types/node": "*",
    "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/74014/artifacts?artifactName=tgz&fileId=53B4D99407A93B4AF6FAEF8437B02126A8C7FEC62F1C3307DAA098F75D2CE5D602&fileName=/typescript-4.0.0-insiders.20200515.tgz"
  }

 const log = msg => (console.log(
    typeof msg === "function"
      ? msg
      : JSON.stringify(msg))
    , msg);

YESSSS

Funny that this is coming back full circle. I've made a comment a while ago regarding the type inference/tooling problem with the pipe, and how to solve it: https://github.com/tc39/proposal-pipeline-operator/issues/143#issuecomment-492019845

About that backward type inference problem:
In RxJS, TypeScript works just fine for a situation like this:
const int$ = of('hello').pipe(map(x => x.length));
// type of int$ is inferred to be Observable<number>

This would be equivalent to:
const int$ = of('hello') |> map(x => x.length);

Why would it be impossible to infer int$ in the latter case while it is inferrable in the former? In both cases map is something of type:
type Map = <T, U>(f: T => U) => Observable<T> => Observable<U>

And hence the receiver is the last curried argument. So it feels like it should be inferrable in both cases..?

FYI: It appears the type inference isn't working that great for more advanced cases like RxJS see this playground example
Copied here for convenience:
interface Subscription {
  unsubscribe(): void;
}

interface Observer<T> {
  next(value: T): void;
  error(err: any): void;
  complete(): void;
}

interface Observable<T> {
  subscribe(observer: Partial<Observer<T>>): Subscription;
}

type Op<T, R> = (source: Observable<T>) => Observable<R>;

declare function map<T, R>(fn: (value: T, index: number) => R): Op<T, R>;

declare function filter<T>(fn: (value: T, index: number) => boolean): Op<T, T>;

declare const source: Observable<number>;

const result = source
  |> map(x => x + x) // <-- x is `unknown`
  |> map(x => x + '!!!') // <-- x is `unknown`
  |> filter(x => x.length < 20); // <-- x is `unknown`

This is a real shame, because it would be a killer language feature for libraries like RxJS.

@benlesh @markusjohnsson Seems to be a pattern of type inference needing to be added for its use w/ generics; generic use cases don't seem to be covered yet in cases/conformance nor baselines/reference yet by @Pokute.

@typescript-bot pack this

@typescript-bot pack this

Testing this out in a project and having to manually update the packed bundle because it expires in about 10 days is very annoying - could we get a feature to tell typescript bot to pack this indefinitely? Thanks!
/cc @orta

Actually, this PR convinces me that the pipeline operator in its current form is not a good match for typescript.
The pipeline operator feels the most natural if we live in a js world with curried, data last, functions.
Of course, Haskell and other FP languages have moved to this pattern for similar reasons. It makes function much easier composable.
However:

This is not the current js world where we live in. I think any javascript programmer with no FP background, will use the data as the first argument. This is the standard for most JS programmers, codebases and I also think still the standard in most open source APIs. Do we really want to change this whole paradigm?
Curried functions are quite a bit uglier in js, especially if you want to use function, function* or async function.
If you are only going to use the curried function by itself, it looks more confusing. For example, what is the output of this function: concat([1])([2, 3])? [1,2,3] or [2,3,1]
TS can not really infer curried, data last, functions well. This has nothing to do with this PR, but more in general that TS infers from left to right, (data first), and not right to left (data last).

For example, this also get not inferred well:
interface Observable<T> {}
type Op<T, R> = (source: Observable<T>) => Observable<R>;
declare function map<T, R>(fn: (value: T, index: number) => R): Op<T, R>;
declare function filter<T>(fn: (value: T, index: number) => boolean): Op<T, T>;
declare const source: Observable<number>;
const result = filter(x => x.length < 20)(map(x => x + '!!!')(map(x => x + x)(source)));

Libraries like RxJS partially has solved this problem, by having a sick pipe method, that basically allows curried functions to be inferred left to right again. For example, it could be typed like this:
export function pipe<X1, X2, X3, R>(
  value: X1,
  f1: (x: X1) => X2,
  f2: (x: X2) => X3,
  f3: (x: X3) => R,
): R;

const result = pipe(
  source,
  map(x => x + x),
  map(x => x + '!!!'),
  filter(x => x.length < 20),
);

But if typescript can not infer curried functions well using the pipeline "natively", TS users will still prefer a custom pipe method above the js operator.
It sounds like me, that we may need to reach the same conclusion as rescript did (used to be called reasonml), and move to a pipeline operator that is optimized to work with data first functions:
https://www.javierchavarri.com/data-first-and-data-last-a-comparison/

@kasperpeulen Your mention of RxJS in your last comment is kind of confusing. The main contributors of RxJS have also campaigned for this version pipeline operator for some time; the version of pipeline operator they've supported that this PR is related to is in fact a drop-in replacement for their implementation.
A good example of that can be found here: https://reactive.how/rxjs/explorer
Accordingly it can be inferred just fine by TypeScript; it been pointed out by people like @benlesh that this current attempt of realizing that version is not acting as expected well within the capabilities of TypeScript today.
Similarly, pipeline operator is also a drop-in replacement for the equivalent in lodash, ramda, & other popular functional programming libraries that also have significant traction in the JS community overall. The way this variant of the pipeline operator works also aligns with how POSIX-compliant unix shells work & so on. Overall, how this pipeline operator behaves is not an uncommon way data pipelining works.
Accordingly, I respectfully disagree we need to prioritize an alternate pipeline operator that "works on data first functions" that isn't as idiomatic or have been historically leveraged by functional programmers  ; not opposed to that being pursued as a separate initiative/standard proposed nonetheless.

@lozandier My point is that the curried function of Rx.js only infer in combination with the pipe method. They don't infer if you would use the curried function directly:
const result = filter(x => x.length < 20)(map(x => x + '!!!')(map(x => x + x)(observable)));
That is I think the reason why the pipeline operator implemented in this PR, can not infer them.
It could be, that we can change the pipeline operator implementation in TS so that this will get inferred as good as the .pipe method of RxJS.
However, isn't a bit silly that we are about to change the whole paradigm of how to write a function in javascript, while we can only leverage those functions using a pipeline operator, and not be able to write those functions directly?

@kasperpeulen I’m not sure what you mean by “change the paradigm of how functions are written in JS” when partial application capabilities & the pipeline operator enable the use of existing functions that JS developers have written just fine.
This is particularly true of referential transparent functions that have been augmented by the equivalent of both a variety of FP libraries provide FP devs today while they wait for these two proposals to be supported by the language properly usually  through ramda, lodash, or from scratch via call/apply.
These functions are extremely common, particularly when writing optimally testable JS anyway; I’m not sure what functions would have to be majorly re-written for use w/ the pipeline operator when combined w/ the partial application proposal.
The pipeline operator on its own elegantly supports single arg (unary) referential transparent functions while combined w/ the partial application proposal enables it to handle all typical functions JS write today just fine.
Without the latter being available to the language for a long time is where I can see your concern having merit forcing point-free programming all the time when using the pipeline operator; that said, all steps point to the pipeline operator & partial application capabilities being combined or ratified simultaneously to alleviate your concern.
Currently the F#-style, split mix, & smart mix are proposals that explicitly do so.
The latter 2 are explicitly a florian's compromise of accepting some of the ideas of a recently proposed new style (Hack-style) from a perspective similar to yours being cautious of forcing point-free programming w/ the use of pipeline-operator.
Split mix & F#-style I find promising on that matter.

With the partial application proposal also in, you indeed dont have to rewrite existing javascript, but it is still more elegant to use the curried variant of the same function (to avoid the ?).
I guess the js ecosystem will move more to curried, data last functions even with the partial application syntax.
The question is, do we want that?
When data last, curried functions, when called directly as shown above, infer very poorly the generic parameters, which seems to be a core design limitation of typescript.
Or are there better solution for function composition in typescript?

@kasperpeulen While I prefer point-free programming, it's purely subjective that a curried variant of the same function is "still more elegant".
As far as the two capabilities "moving the JS ecosystem" in a particular direction, that's up for the JS community to decide; not exactly sure who is "we" in your original comment & why their wants should outweigh the JS community.
The existence of these proposals won't force the JS community in a particular direction; these capabilities being prevalent in codebases after being ratified would merely signal & verify people wanted to go this direction and them being available natively finally more easily enabled that. The existence of the pipeline operator & partial application proposal natively unblocks barrier of entry selling & communicating longly-leveraged patterns of writing declarative, functional code involving left-to-right composition, clearer mix-in patterns, & so on in environments where every byte counts compared to importing & writing ad hoc code to approximate their behavior with limitations a native solution doesn't.
With these capabilities in the language soon, it will be marketed that there are "new" ways to create declarative, functional code in JS.
As far as limitations w/ TypeScript's type system: TypeScript core maintainers are a brilliant bunch; at the end of the day JS doesn't revolve around TypeScript; as a superset of JS they'll refactor TypeScript as needed to continue to be that in good faith.
It can be argued w/ the pipeline operator types flow much easier, not the other way around.

With these capabilities in the language soon, it will be marketed that there are "new" ways to write declarative, functional code in JS as a result. That's fine.

That is fine, if you believe this is the best way to write declarative functional code in JS using curried data last functions. That is what I doubt.
Your argument are not really argumenting why data last curried functions with say a F# pipeline are a better fit for javascript, than say a data first “normal” function with an elixir like pipeline.
This article goes in detail about the pros and cons about those approaches:
https://www.javierchavarri.com/data-first-and-data-last-a-comparison/
Probably better to move this discussion to the pipeline repo though.
If we indeed can fix the all typescript inference issues for this PR and curried functions in general, than it wouldnt matter that much to me which variant of the pipeline proposal is chosen.
But if those issues are too hard to fix, it may be another argument to take the elixer pipeline proposal more serious.

Heya @orta, I've started to run the tarball bundle task on this PR at 19fd8b1. You can monitor the build here.

@orta The pack build seems failed?

@orta @Pokute @kiprasmel
I have the packed typescript-4.0.0-insiders.20200515.tgz, and now the latest version is  TypeScript v4.1.2 (Stable).
https://github.com/microsoft/TypeScript/releases
How can we obtain the repacked latest version with Pipeline Operator?
Thanks.

You're welcome to rebase this PR to get it running on 4.1 and we can re-issue a new build - I've also added a feature to the pack command so that a permanent npm deploy will be created the next time this is built https://github.com/microsoft/TypeScript-Make-Monaco-Builds/commit/92b5625f22bd29e43a9056714e84732f973eb08a

@orta I really appreciate your contribution!
I've investigated
https://github.com/microsoft/TypeScript-Make-Monaco-Builds/commit/92b5625f22bd29e43a9056714e84732f973eb08a
However, the things are not clear to me, so please explain more.
I would like to confirm which URL a permanent npm deploy will be uploaded.
According to
https://github.com/microsoft/TypeScript-Make-Monaco-Builds#cdnd
I found:
Releases: https://typescript.azureedge.net/indexes/releases.json
Pre-Releases: https://typescript.azureedge.net/indexes/pre-releases.json
Next: (provides a redirect to the latest nightly version)
https://typescript.azureedge.net/indexes/next.json
For instance my current package.json for my own project is
 "devDependencies": {
    "typescript": "https://typescript.visualstudio.com/cf7ac146-d525-443c-b23c-0d58337efebc/_apis/build/builds/74014/artifacts?artifactName=tgz&fileId=53B4D99407A93B4AF6FAEF8437B02126A8C7FEC62F1C3307DAA098F75D2CE5D602&fileName=/typescript-4.0.0-insiders.20200515.tgz"
  }

How can we adapt to a permanent npm deploy with repacked Pipeline Operator??
Thanks again.

The bot would give instructions after the new version has been built, https://github.com/microsoft/TypeScript-Make-Monaco-Builds/commit/225742ada04fed90b98112997566169be9f61ac0 - until this has been rebased, and re-packed, it won't show up here.

The bot would give instructions after the new version has been built, microsoft/TypeScript-Make-Monaco-Builds@225742a - until this has been rebased, and re-packed, it won't show up here.

@orta Is new version with pipeline-operator released?
I don't see any bot activity here or links...  Thanks.

The bot would give instructions after the new version has been built, microsoft/TypeScript-Make-Monaco-Builds@225742a - until this has been rebased, and re-packed, it won't show up here.

@orta Is new version with pipeline-operator released?
I don't see any bot activity here or links...  Thanks.

This PR would need rebasing, and to be re-requested to be packaged again to get the new infra I added for permanent deploys

This PR would need rebasing, and to be re-requested to be packaged again to get the new infra I added for permanent deploys

@Pokute Can you please rebase it?

I rebased the code now.
Additionally I fixed a bunch of bugs - all typescript code inside pipelines after |> was not converted into JS. The tests now fail due to additional testing constrains added since last year, specifically it seems to complain about unused member field, typeArguments, in PipelineExpression. I think typeArguments will be used later so I left them in the code.
On the topic of type arguments, I actually tried to fix that one but it was more complex than I initially expected. If I went for [] |> Array.from<number>; syntax then I have to make a separate, temporary expression that's similar to a CallExpression, but the error reporting would become complex. A simpler way would be to use the funny-looking [] |><number> Array.from; which seems easier to implement. I will probably try the latter first since it would allow me to test the feature.
I'm not sure if this can be packed with existing errors, so I'll try to do some kind of fixes soon.

@typescript-bot pack this

I rebased the code now.
Additionally I fixed a bunch of bugs - all typescript code inside pipelines after |> was not converted into JS. The tests now fail due to additional testing constrains added since last year, specifically it seems to complain about unused member field, typeArguments, in PipelineExpression. I think typeArguments will be used later so I left them in the code.
On the topic of type arguments, I actually tried to fix that one but it was more complex than I initially expected. If I went for [] |> Array.from<number>; syntax then I have to make a separate, temporary expression that's similar to a CallExpression, but the error reporting would become complex. A simpler way would be to use the funny-looking [] |><number> Array.from; which seems easier to implement. I will probably try the latter first since it would allow me to test the feature.
I'm not sure if this can be packed with existing errors, so I'll try to do some kind of fixes soon.

Thanks a lot for your contribution!
Waiting for an update!

@typescript-bot pack this

This is cool! Here's a contrived example of an interesting use-case for using pipelines to create builders composed from separate functions.
const url = new URLBuilder()
  |> host('localhost')
  |> port(4200)
  |> query('search', 'typescript')
  |> query('sort', 'recent')
  |> build

https://www.staging-typescript.org/play?ts=4.3.0-pr-38305-46#code/MYGwhgzhAECqBKAZAQgVwJYgCYFMBO0A3gFDTQAOqARiOsNAI6r4CeAXNAIJ55gsA8AbQgAXPOgB2AcwA00UeOkBdAHzQAvNEFKA3KQrVa9ABYB7UQH4OCyVL1lKNOhVN4RV6BNQBbKvj0AvsTEwKYSotBmEZoAFFEi1mK2AJQaKjGoeCBomLh4HAgoGNj4qepqJGSZ2cV5AHTxGpHmIvp4OCKZEtDVOSV4xEEhYRFMrE0xY3gsANI47PJJ0nJTLABqYCDMiYpSZWoZWX15BUjHpWlE+r21+HWrdZQQxjGCq3MsK8zTG1s4Ssk2h0uj0jrcBkNQuERC43BNyK4Ep4fH48PtoIcarl8Kciti0ZdKqCsf1Hoimgi3EDOnhujd8YNglCIlRahN6f1cecCeVoAADAAkhA59XiATYQpFd0pIgCFklYPx92+LDq3jA5EmlwYggADEpoABqaAAcnUJqNjEEAEYAXUAFamSQxE0AMhNyQCfKZIxh1SaEhwAHc4GdwTFAWQAD5qeIukCmYCbeIe-Qx2EiGIAFgATLrdZHoOnVi6IDgwHhgMYTXITSIWOQcBBgOJyCJU9G1CWTRBETXTe1gDgJO3C+nWbkfeFTCAcHUE1JMckgA
I can see this being very useful for working with external apis etc as you could easily add your own builder method without having to extend the external builder class. composition ftw!
Unfortunately from the TC39 meeting notes it seems like the pipeline proposal is starting to veer into the Hack style preference. Hopefully they can find a champion to make the case for the IMO simpler implementation demonstrated here. My three biggest use cases for pipeline (rxjs, array manipulation and builders) all would be less readable with Hack style :(

Unfortunately from the TC39 meeting notes it seems like the pipeline proposal is starting to veer into the Hack style preference.

I'm sure that after we get any version of pipeline operator in place, it should be very straightforward to augment that functionality with another operator. For hack-style pipeline, this could be #|> or |>> or whatever to call unary functions.
Thus this all discussion now feels to be about preference and priorities and few are actually opposed to a more full set of features. The issue on priorities and preferences has already stalled this for multiple years and I recall It's only a very small minority that would rather see no pipelines rather than something other than their version of pipelines. That's why I'm now supporting any pipeline variant - this one just happened to be the one I worked on first.
I'll probably try to implement a hack-style PR next instead of going for typeArguments -support.

Hopefully they can find a champion

according to the notes @DanielRosenwasser and his team have "some light interest in potentially championing this proposal"
this needs to happen yesterday 🤞

This is cool! Here's a contrived example of an interesting use-case for using pipelines to create builders composed from separate functions.
const url = new URLBuilder()
  |> host('localhost')
  |> port(4200)
  |> query('search', 'typescript')
  |> query('sort', 'recent')
  |> build

https://www.staging-typescript.org/play?ts=4.3.0-pr-38305-46#code/MYGwhgzhAECqBKAZAQgVwJYgCYFMBO0A3gFDTQAOqARiOsNAI6r4CeAXNAIJ55gsA8AbQgAXPOgB2AcwA00UeOkBdAHzQAvNEFKA3KQrVa9ABYB7UQH4OCyVL1lKNOhVN4RV6BNQBbKvj0AvsTEwKYSotBmEZoAFFEi1mK2AJQaKjGoeCBomLh4HAgoGNj4qepqJGSZ2cV5AHTxGpHmIvp4OCKZEtDVOSV4xEEhYRFMrE0xY3gsANI47PJJ0nJTLABqYCDMiYpSZWoZWX15BUjHpWlE+r21+HWrdZQQxjGCq3MsK8zTG1s4Ssk2h0uj0jrcBkNQuERC43BNyK4Ep4fH48PtoIcarl8Kciti0ZdKqCsf1Hoimgi3EDOnhujd8YNglCIlRahN6f1cecCeVoAADAAkhA59XiATYQpFd0pIgCFklYPx92+LDq3jA5EmlwYggADEpoABqaAAcnUJqNjEEAEYAXUAFamSQxE0AMhNyQCfKZIxh1SaEhwAHc4GdwTFAWQAD5qeIukCmYCbeIe-Qx2EiGIAFgATLrdZHoOnVi6IDgwHhgMYTXITSIWOQcBBgOJyCJU9G1CWTRBETXTe1gDgJO3C+nWbkfeFTCAcHUE1JMckgA
I can see this being very useful for working with external apis etc as you could easily add your own builder method without having to extend the external builder class. composition ftw!
Unfortunately from the TC39 meeting notes it seems like the pipeline proposal is starting to veer into the Hack style preference. Hopefully they can find a champion to make the case for the IMO simpler implementation demonstrated here. My three biggest use cases for pipeline (rxjs, array manipulation and builders) all would be less readable with Hack style :(

It's been abundantly clear in an overwhelming amount of threads with JS community participation that hack-style hasn't had much traction over the other styles. Accordingly, it would be hasty to prioritize it over the other styles.
Simple proposal is a base that is supported without contention; accordingly I'm of the opinion that should be the implemented first & foremost.

Unfortunately from the TC39 meeting notes it seems like the pipeline proposal is starting to veer into the Hack style preference.

I'm sure that after we get any version of pipeline operator in place, it should be very straightforward to augment that functionality with another operator. For hack-style pipeline, this could be #|> or |>> or whatever to call unary functions.
Thus this all discussion now feels to be about preference and priorities and few are actually opposed to a more full set of features. The issue on priorities and preferences has seemingly already stalled this proposal for multiple years and I recall It's only a very small minority that would rather see no pipelines rather than something other than their version of pipelines. That's why I'm now supporting any pipeline variant - this one just happened to be the one I worked on first.
I'll probably try to implement a hack-style PR next instead of going for typeArguments -support.

Wouldn't it be simpler to get the base characters working first prior to hack-style? Hack-style has been proposed as a florian's compromise with heavy pushback from the JS community, especially the functional programming community.

Hope this helps @zakhenry & @Pokute

Alright folks, let's not use the TypeScript issues to debate the merits of the F# vs Hack proposal - you can use the proposal's repo or twitter etc. Even better, if you work at a place which is a TC39 member, attend the next meeting and give feedback.

Update: I've been refactoring the TS PRs for pipelines (both F# #38305  and hack #43617 ) during this week and the commits are a lot cleaner now. The current commit history for hack-style pipelines is just a mess since it builds upon the F# implementation. The newer one will use a common commit.
One big idea I came upon is to have different PipelineExpression types for both a method that itself calls a unary function (F#) and another (hack) that just replaces tokens with the "argument". After all, the way those two pipelines work is different despite the similarities. This will allow for easier support of both F#, hack and even smart pipeline styles at the same time.
I believe that whichever style of F# or hack pipelines will be the default, the next shop would be to add another pipelineish operator for the other one. This is relatively straightforward to implement in TypeScript, so I'm considering adding Tacit Unary Function Application syntax for this Hack-style PR to enable Math.random() |> 1 / # |>> Math.round;. For F# style pipelines, partial function application might be a better pair, so I won't be adding additional hack/topic-support to this PR unless there's a lot of requests for it.
I've been rebasing my own repos against master, but I still haven't had time to fix the (Missing) errors in Hack-style pipelines. Hopefully I get new versions out before the end of the week.

@typescript-bot pack this

Will it be possible to use pipeline with iterators, sync and async?

@Lonli-Lokli Yes, see the following examples from the proposal's github repo
The simple pipeline handles the former 2 trivially by design; F#, Smart, & Hack-style proposals build on top of the simple proposal to accommodate async functions / promises / iterables a variety of ways w/ pros & cons.

Is anyone aware of a working version of this PR? I tried the playground link posted by the bot, but the playground doesn't appear to be working with this branch?
https://www.staging-typescript.org/play?ts=4.3.0-pr-38305-57

Is anyone aware of a working version of this PR? I tried the playground link posted by the bot, but the playground doesn't appear to be working with this branch?

There might be a problem with operator precedence. You need to wrap the inline arrow function within parenthesis:  |> ((x: string) => x.toUpperCase()) |>
Thank you for testing this out.

@Pokute ah, thanks, I didn't realize you had to wrap the lamda in parens. That seems to work, mostly. The compiler accepts the expression, but still has an error.

It doesn't seem to properly infer that x is a string and I would have to tell the compiler that it's a string explicitly.

Is that expected for this build? Is the plan to have that inference work?

@Pokute ah, thanks, I didn't realize you had to wrap the lamda in parens. That seems to work, mostly. The compiler accepts the expression, but still has an error.

It doesn't seem to properly infer that x is a string and I would have to tell the compiler that it's a string explicitly.

Is that expected for this build? Is the plan to have that inference work?

I think it's natural that the pipeline operator has a high precedence.
and the error is common in typescript, nothing to do with with to the pipeline operator.

The compiler [...] still has an error.
It doesn't seem to properly infer that x is a string and I would have to tell the compiler that it's a string explicitly.

Is that expected for this build? Is the plan to have that inference work?

and the error is common in typescript, nothing to do with with to the pipeline operator.

This should be inferable as shown in a above screenshot. It does require more work though, but I'm not sure when I can work on it.
I'm not sure about the precedence either. I'll need to check it out.

TC39 is moving forward with the hack-proposal version, they just moved it to stage 2. Therefore, this PR should be closed in favor of https://github.com/microsoft/TypeScript/pull/43617

TC39 is moving forward with the Hack-proposal version (stage 1 -> 2).
Therefore, this PR should be closed in favor of the Hack-style approach #43617

I firstly thought it's good news, but investigating "hack-style" that for some reason I didn't notice (I only knew miminal/F#/Smart).
I think if a programmer knows mathematics or functional programming, the one will notice it's just a mess and night-mare.
I wrote this:
https://gist.github.com/tabatkins/1261b108b9e6cdab5ad5df4b8021bcb5#gistcomment-3892109

I've just posted
https://github.com/tc39/proposal-pipeline-operator/issues/202#issuecomment-921433351
Hack-style contains serious problems.
I wish TypeScript users join and I would like to read your insight. Thanks.

This is a new issue to discuss
Impact of Hack pipes on functional programming
https://github.com/tc39/proposal-pipeline-operator/issues/217

This is a new issue to discuss
Impact of Hack pipes on functional programming
tc39/proposal-pipeline-operator#217

I had to move the place, thanks.
https://github.com/tc39/proposal-pipeline-operator/issues/223

Pipelines with operator overloading
https://github.com/tc39/proposal-pipeline-operator/issues/228
We don't want pipe any more. It's redundant over the operator overloading. We no longer support this pipeline-operator proposal as a whole.
RxJS author has just announced he no longer supports the Hack and will ignore.
https://github.com/tc39/proposal-pipeline-operator/issues/228#issuecomment-925465598

This experiment is pretty old, so I'm going to close it to reduce the number of open PRs.


Too many spurious guest accounts being created

Describe the bug
A lot of empty guest accounts are created with our current account allocation design.  This is causing a lot of clutter in the database.
To Reproduce
Steps to reproduce the behavior:

Go to the landing page.  Note that a default guest account has been created (see the account id in the url)
Log in and log out again.
Note that a different guest account is created.

Expected behavior
Guest accounts should not be created by default when a user arrives on the landing page.  A guest account should only be created when the user opts out of the login flow.
Additional context
This may be a fairly large refactoring of the landing page given that it isn't set up to be able to show anything (including the list of available programs) without a user tied to it right now.

This is WAI

We used to have a landing page that gave applicants the option to log in or continue as guests, research showed less engagement from applicants with that page so we removed it in favor of immediately showing the list of programs. The code that loads and displays the programs assumes an account of some type exists (including guest accounts), and refactoring it would be a fairly big effort so we went with creating an account on initial pageload if necessary. We checked with Seattle to get a sense of traffic and how much of an issue it would be for the database size and determined it wouldn't be an issue. There's an issue for writing a recurring job for deleting the old accounts but there's not much motivating action on it at the moment: https://github.com/civiform/civiform/issues/4719

Another idea that Bion and I have discussed in the past is creating a batch job to delete applicants that don't have any data tied to them that haven't logged in in the past couple of days or something.


Create *Hardware-structures

[x] ComponentHardware
[x] SensorHardware
[x] ActuatorHardware
[x] RobotHardware

PR: ros-controls/ros2_control#80

not relevant any more. see ros-controls/ros2_control#80  ros-controls/ros2_control#101 for more details and further development


A few error messages in my ts file

VSCode Version: 1.6.1
OS Version: 10.11.6

Steps to Reproduce:

git clone https://github.com/bsliran/angular2-meteor-base.git demo
Open app.component.ts

The first error is:  [ts] Cannot find module './app.component.html'.
The second error is: [ts] Experimental support for decorators is a feature that is subject to change in a future release. Set the 'experimentalDecorators' option to remove this warning.
After I insert to .vscode/settings.json:
{
  "typescript.tsdk": "/usr/local/lib/node_modules/typescript/lib"
}

The problem exists.
My tsconfig.json:
{
  "compilerOptions": {
    "target": "es5",
    "lib": [
      "es6",
      "dom"
    ],
    "module": "commonjs",
    "moduleResolution": "node",
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true,
    "sourceMap": true
  },
  "exclude": [
    "node_modules"
  ],
  "files": [
    "typings.d.ts"
  ],
  "compileOnSave": false,
  "angularCompilerOptions": {
    "genDir": "aot",
    "skipMetadataEmit": true
  }
}

I think the code itself has no problem because I can run the app without problem. But it shows the error message.
What should I do? Thanks.

The tsconfig file isn't being applied to that file, because of the files entry. That's a list of the files you want to include, and it doesn't include any others, so app.component.ts is excluded. It works if I remove that.

@roblourens Yes, removing files in tsconfig.json will remove the error messages. But it causes the following error message when I run the application:

While processing files with barbatus:typescript (for target web.browser):
packages/barbatus:typescript-compiler/typescript-compiler.js:254:13: Format
of the tsconfig is invalid: SyntaxError: Unexpected token /
at TypeScriptCompiler.parseConfig
(packages/barbatus:typescript-compiler/typescript-compiler.js:254:13)
at TypeScriptCompiler.processConfig
(packages/barbatus:typescript-compiler/typescript-compiler.js:228:32)
at TypeScriptCompiler.processFilesForTarget
(packages/barbatus:typescript-compiler/typescript-compiler.js:41:10)
While processing files with barbatus:typescript (for target os.osx.x86_64):
packages/barbatus:typescript-compiler/typescript-compiler.js:254:13: Format
of the tsconfig is invalid: SyntaxError: Unexpected token /
at TypeScriptCompiler.parseConfig
(packages/barbatus:typescript-compiler/typescript-compiler.js:254:13)
at TypeScriptCompiler.processConfig
(packages/barbatus:typescript-compiler/typescript-compiler.js:228:32)
at TypeScriptCompiler.processFilesForTarget
(packages/barbatus:typescript-compiler/typescript-compiler.js:41:10)

Did you comment out the line? Comments usually aren't allowed in JSON, and whatever tool you're using can't parse it.

@roblourens Yeah. That's right. It solves my issues. Thanks.


Add PPP with basic layout

Codecov Report

Merging #202 (122a1e4) into master (b96471d) will increase coverage by 0.57%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #202      +/-   ##
============================================
+ Coverage     51.56%   52.14%   +0.57%
- Complexity      604      623      +19
============================================
  Files           125      125
  Lines          2612     2635      +23
  Branches        336      346      +10
============================================
+ Hits           1347     1374      +27
+ Misses         1182     1173       -9
- Partials         83       88       +5

Impacted Files
Coverage Δ

.../main/java/seedu/edrecord/model/module/Module.java
80.76% <0.00%> (-0.90%)
:arrow_down:

.../seedu/edrecord/logic/parser/AddCommandParser.java
88.46% <0.00%> (-0.43%)
:arrow_down:

...c/main/java/seedu/edrecord/model/ModelManager.java
56.41% <0.00%> (ø)

...java/seedu/edrecord/logic/commands/AddCommand.java
80.00% <0.00%> (ø)

...ava/seedu/edrecord/logic/commands/MoveCommand.java
0.00% <0.00%> (ø)

...a/seedu/edrecord/logic/commands/RemoveCommand.java
0.00% <0.00%> (ø)

.../edrecord/logic/commands/AddAssignmentCommand.java

...ecord/logic/parser/AddAssignmentCommandParser.java

...va/seedu/edrecord/model/module/ModuleGroupMap.java

...edrecord/logic/commands/MakeAssignmentCommand.java
100.00% <0.00%> (ø)

... and 5 more

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 b96471d...122a1e4. Read the comment docs.


[ELE-127] Baseline schema changes duration is very long

Thread link

From SyncLinear.com | ELE-127

Ran into the same issue when implementing the schema change tests, non baseline version. Using Redshift as our DWH. A new source was added outside of our teams chage management workflows so figured the schema anomalies would be nice.
Approximately 40 tables were added with schema changes, and each table introduced 1-1.5minutes of runtime. Our total job runtime jumped by 15 minutes. I don't know what ability Elementary has to pull 'table' tests out to a larger scope but perhaps the schema change anomalies running as a posthook, where information schema only needs to be queried once might be helpful. For now we're going to remove the tests.

https://elementary-community.slack.com/archives/C02CTC89LAX/p1681873133128709


Get-CimInstance requires elevated privileges

I am using Powershell SDK 7.0 from C#
Steps to reproduce
My C# app is running as a normal user (not elevated)
(Get-CimInstance Win32_ComputerSystem).NumberOfLogicalProcessors

Expected behavior
Get the number of logical processors (4 in my test environment, validated through Windows Powershell 5.1 running as normal user.)
Actual behavior
I get the following error from API
{The 'Get-CimInstance' command was found in the module 'CimCmdlets', but the module could not be loaded. For more information, run 'Import-Module CimCmdlets'.}
I tried adding import-module CimCmdlets in front of the command but received "Scripting not enabled" which leads to running executionpolicy command as elevated inside script.
Environment data
PSVersion=7.0.0
PSEdition=Core
WSManStackVersion=3.0
PSRemotingProtocolVersion=2.3

Your command does not require elevation, and neither does changing the execution policy, as long as you use either -Scope  CurrentUser or -Scope Process.
Also, you don't need an .AddScript() call to invoke Import-Module; you can use .AddCommand("Import-Module").AddArgument("CimCmdlets"). Once you've done that, you can access the .Error collection on the PowerShell instance to see what went wrong.

OK, this worked


Provide a sample Kotlin project built with Gradle and Kotlin DSL

Currently all sample projects are Maven based.

We should be able to do that thanks to #165, the kotlin-webmvc sample is a good candidate to be migrated to a Gradle Kotlin DSL build.


⚠ Bofrost.at has degraded performance

In 778b4d0, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1811 ms

Resolved: Bofrost.at performance has improved in b018ad2 after 7 minutes.


Chore/improve dictionary

Improves dictionary with non-english chars.
Fixes #13

Codecov Report

Merging #15 (8d1c50b) into master (b247613) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master       #15   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            3         3
  Lines           16        18    +2
=========================================
+ Hits            16        18    +2

Impacted Files
Coverage Δ

src/dictionary.js
100.00% <100.00%> (ø)

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 b247613...8d1c50b. Read the comment docs.


Boot of K3OS failed: Failed to determine boot mode

Version (k3OS / kernel)

k3os-20440 [~]$ uname --kernel-release --kernel-version
5.0.0-43-generic #47~18.04.1 SMP Wed Apr 1 16:27:01 UTC 2020

k3os-20440 [~]$ k3os --version
k3os version v0.10.0

Architecture

k3os-20440 [~]$ uname --machine
x86_64

Describe the bug

k3sos does not boot if installed on a regular USB-stick. Instead it fails with Failed to determine boot mode and drops into a bash.

To Reproduce

Setup of disks

2 SATA disks connected via SATA (sda, sdb)
1 USB-stick connected via USB 2.0 (sdc)

sda      8:0    0   1.8T  0 disk
└─sda1   8:1    0   1.8T  0 part
sdb      8:16   0   1.8T  0 disk
└─sdb1   8:17   0   1.8T  0 part
sdc      8:32   1  14.9G  0 disk
├─sdc1   8:33   1    47M  0 part
└─sdc2   8:34   1  14.9G  0 part /k3os/system

Mainboard: unknown (BareBone IPC, ~ 2014)

Install K3OS from USB-CDROM in UEFI-mode onto USB-stick

Reboot K3OS

Expected behavior

k3os boots without any error.

Actual behavior

Additional context

BIOS is kind a old - this is just some of my test equipment

I can configure some kind of USB emulation in the BIOS

If I force the BIOS to emulate a harddisk K3OS boots as expected most times, but sometimes it still fails to boot

If I set the emulation into auto  K3OS does not boot

https://github.com/rancher/k3os/issues/458 looks similar

Also looks like #376

@stuartpb Thanks for having looked at this.


Listen function is timing out after 45 sec.

I'm trying to listen to K8s nodes / pods continuously but the listen function times out after 45 seconds. Is this the expected behaviour? Is there a way to listen indefinitely and print the any new nodes are added to the cluster?
Timeout Exception:
java.util.concurrent.TimeoutException: 45 seconds
        at timeout @ org.http4s.ember.core.Util$.timeoutMaybe(Util.scala:104)
        at main$ @ poc.k8s.ControllerTest$.main(ControllerTest.scala:24)
        at timeout @ org.http4s.ember.core.Util$.timeoutMaybe(Util.scala:104)
        at timeout @ org.http4s.ember.core.Util$.timeoutMaybe(Util.scala:104)

Code:
object ControllerTest extends IOApp:

  val clientResource = EmberKubernetesClient.defaultConfig[IO, Json]

  def run(args: List[String]): IO[ExitCode] =
    for {
      _ <- IO.println("Watch K8s nodes")

      watchNodes <- fs2.Stream.resource(clientResource)
        .flatMap(APIs.nodes.list().listen)
        // Debugging
        .flatMap(ev =>
          exec(
            IO.println("event => " + ev.event) >>
            IO.println("name => " + ev.payload.metadata.flatMap(_.name))
          )
        )
        .compile
        .drain

    } yield ExitCode.Succes

@hnaderi Could you help with this please? Thanks

Hi :wave:
That's the default timeout for http4s ember client which is not exposed in the kubernetes client builder currently (v0.11.x),
However is exposed in the current development version (v0.12.0) which is not yet released.
As a workaround you can use the .fromClient method and pass any http4s client directly, however you'll need to setup TLS context manually.
I can release a snapshot version of the development version, let me know if it helps you.

Also another workaround would be to long poll using the current version, i.e. listen and continue next listen from last offset.
However, the new version will have been released at most by this weekend.

@hnaderi Let me check the options you suggested and get back to you. Thanks

Also another workaround would be to long poll using the current version, i.e. listen and continue next listen from last offset.

Do you have any example to do this some where? I can't figure out how to trigger next listen from the last offset. Thanks

Also another workaround would be to long poll using the current version, i.e. listen and continue next listen from last offset.

Do you have any example to do this some where? I can't figure out how to trigger next listen from the last offset. Thanks

You can see here to figure out watch semantics. Basically you need to pass required arguments to the list method, i.e. .list(continue = Some("last token")).
Also, I'll publish a snapshot version with all the client configs exposed to the user tonight, after my work day finishes.

@pradeepcheers  This will publish a snapshot, you can use it by:
ThisBuild / resolvers ++= Resolver.sonatypeOssRepos("snapshots")
libraryDependencies ++= Seq(
  "dev.hnaderi" %% "scala-k8s-http4s-ember" % "0.12-706250c-SNAPSHOT"
)

And you can change timeout like this:
EmberKubernetesClient(
  EmberClientBuilder.default[IO].withTimeout(Duration.Inf)
).defaultConfig[Json]

@pradeepcheers You can try this version 0.12-f3fc096-SNAPSHOT

@hnaderi Thanks. However getting similar timeout exception in a different place this time!
[error] java.util.concurrent.TimeoutException: 45 seconds
[error] 	at timeout$extension @ org.http4s.ember.client.internal.ClientHelpers$.writeRead$1(ClientHelpers.scala:171
[error] 	at main$ @ poc.k8s.ControllerTest$.main(ControllerTest.scala:28)
[error] 	at timeout$extension @ org.http4s.ember.client.internal.ClientHelpers$.writeRead$1(ClientHelpers.scala:171
[error] 	at timeout$extension @ org.http4s.ember.client.internal.ClientHelpers$.writeRead$1(ClientHelpers.scala:171
[error] stack trace is suppressed; run last controller / Compile / run for the full output
[error] (controller / Compile / run) java.util.concurrent.TimeoutException: 45 seconds
[error] Total time: 51 s, completed 18 May 2023, 10:33:20

EmberKubernetesClient(
  EmberClientBuilder.default[IO].withTimeout(Duration.Inf)
).defaultConfig[Json]

Have you changed the client to this?
If that's the case it might be some problem on the ember side, as scala-k8s doesn't impose any timeout or stuff like that

@pradeepcheers I filed an issue on the http4s for this behavior here
In the meanwhile, you can use other http4s clients, like jdk-client, netty or blaze.

@pradeepcheers Apparently the example I gave you was not complete, you need to also add
 .withIdleConnectionTime(Duration.Inf)
EmberKubernetesClient(
  EmberClientBuilder.default[IO]
    .withTimeout(Duration.Inf)
    .withIdleConnectionTime(Duration.Inf)
).defaultConfig[Json]

@hnaderi sorry was a bit busy earlier. Let me try what you suggested above, I will keep you posted.  I really appreciate your help. Thanks

@pradeepcheers Apparently the example I gave you was not complete, you need to also add  .withIdleConnectionTime(Duration.Inf)
EmberKubernetesClient(
  EmberClientBuilder.default[IO]
    .withTimeout(Duration.Inf)
    .withIdleConnectionTime(Duration.Inf)
).defaultConfig[Json]

@hnaderi the listen method works as expected with the above change. Thanks a lot

This changes are released in https://github.com/hnaderi/scala-k8s/releases/tag/v0.12.0