added ql version in metadata

Proposed changes
Stored ql_version in metadata
Types of changes
What types of changes does your code introduce to the project: Put
an x in the boxes that apply

[ x ] Bugfix (non-breaking change which fixes an issue)
[ x ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing
functionality to not work as expected)

Checklist
Put an x in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to
ask. We're here to help! This is simply a reminder of what we are going
to look for before merging your code.

[ x ] I have read the CONTRIBUTING doc
[ x ] I have signed the CLA
[ ] I have added tests that prove my fix is effective or that my
feature works
[ x ] I have updated the [RELEASE_NOTES][RELEASE_NOTES.md]
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in
downstream modules

Further comments
Fix for Issue

Hi @chicco785 @c0c0n3 , I have done some changes in code test case are passing but still autopep8 is failing not able to get exact cause why it is failing.

hi @daminichopra :-)
I'm not sure why autopep is failing, I looked at the logs but couldn't find any useful clues. We'll look into this. In the meantime, if you could please review my suggestion below and implement it if you agree with the proposed changes.
We've got to store the version number in a single place to avoid grief down the line. So I suggest we add a src/_version.py file with the following content
# Most recent official release
__version_info__ = ('0', '8', '3')
__version__ = '.'.join(__version_info__)

# Current dev version for the next release
__dev_version__ = '0.9.0-dev'

See also this SO question about app versions

https://stackoverflow.com/questions/458550

Once this module is in place, replace all hard-coded version numbers scattered around the code with the constants defined above. For example, here's what the reporter.version module should look like
from _version import __dev_version__

def version():
    return {
        'version': __dev_version__
    }

Same applies to the module's test. On the other hand, you should use the __version__ constant in the new code you've implemented for this PR.
Thank you so much!

hi @daminichopra :-)
I'm not sure why autopep is failing, I looked at the logs but couldn't find any useful clues. We'll look into this. In the meantime, if you could please review my suggestion below and implement it if you agree with the proposed changes.
We've got to store the version number in a single place to avoid grief down the line. So I suggest we add a src/_version.py file with the following content
# Most recent official release
__version_info__ = ('0', '8', '3')
__version__ = '.'.join(__version_info__)

# Current dev version for the next release
__dev_version__ = '0.9.0-dev'

See also this SO question about app versions

https://stackoverflow.com/questions/458550

Once this module is in place, replace all hard-coded version numbers scattered around the code with the constants defined above. For example, here's what the reporter.version module should look like
from _version import __dev_version__

def version():
    return {
        'version': __dev_version__
    }

Same applies to the module's test. On the other hand, you should use the __version__ constant in the new code you've implemented for this PR.
Thank you so much!

@c0c0n3 , Incorporated comments given and updated PR.

@daminichopra thank you sooo much that's great. We're going to need some tests though :-) But before you do that, let's wait for @chicco785 to comment on this PR since I remember him mentioning he had something different in mind when he wrote #591?

@daminichopra thank you sooo much that's great. We're going to need some tests though :-) But before you do that, let's wait for @chicco785 to comment on this PR since I remember him mentioning he had something different in mind when he wrote #591?

@c0c0n3  , Sure

@daminichopra thanks for this contrib, we just need you to add some tests to check that the QL version gets written to the meta table...Any chance you could you do that? Thanks alot!!!

@c0c0n3 @chicco785 I have updated this PR. Please let me know in case any other change is required to merge this PR.

@c0c0n3 @chicco785 I have updated the PR. If you can spare sometime for review and let me know in case any further change is required.

@daminichopra @pooja1pathak thank you for the reminder. We've been busy w/ other projects and this PR fell through the cracks. Soooo sorry about that. Anyhoo, we've just checked out your branch and had a look at the code which is mostly fine, but we'd like to change where the version gets stored in the DB.
At the moment it ends up being stored as an NGSI attribute in the meta table. E.g. with two tables et0 and et1 this is what I get
table_name | entity_attrs
-------------------------
"et0" | {"ql_version":["0.8.3","Text"],"attr_bool":["attr_bool","Boolean"],"entity_type":["type","Text"],"time_index":["time_index","DateTime"],"attr_geo":["attr_geo","geo:json"],"attr_time":["attr_time","DateTime"],"attr_str":["attr_str","Text"],"entity_id":["id","Text"],"attr_float":["attr_float","Number"]}
"et1" | {"ql_version":["0.8.3","Text"],"attr_bool":["attr_bool","Boolean"],"entity_type":["type","Text"],"time_index":["time_index","DateTime"],"attr_geo":["attr_geo","geo:json"],"attr_time":["attr_time","DateTime"],"attr_str":["attr_str","Text"],"entity_id":["id","Text"],"attr_float":["attr_float","Number"]}

Ideally the version should be stored in a separate column since it's an property of the table, not of the NGSI entities? So the table should probably look something like
table_name | version | entity_attrs
-----------------------------------
"et0" | "0.8.3" | {"attr_bool":["attr_bool","Boolean"],"entity_type":["type","Text"],"time_index":["time_index","DateTime"],"attr_geo":["attr_geo","geo:json"],"attr_time":["attr_time","DateTime"],"attr_str":["attr_str","Text"],"entity_id":["id","Text"],"attr_float":["attr_float","Number"]}
"et1" | "0.8.3" | {"attr_bool":["attr_bool","Boolean"],"entity_type":["type","Text"],"time_index":["time_index","DateTime"],"attr_geo":["attr_geo","geo:json"],"attr_time":["attr_time","DateTime"],"attr_str":["attr_str","Text"],"entity_id":["id","Text"],"attr_float":["attr_float","Number"]}

But I'll let @chicco785 comment on this if he thinks it's best to have the version column stored somewhere else rather than an additional meta column.

@daminichopra @pooja1pathak thank you for the reminder. We've been busy w/ other projects and this PR fell through the cracks. Soooo sorry about that. Anyhoo, we've just checked out your branch and had a look at the code which is mostly fine, but we'd like to change where the version gets stored in the DB.
At the moment it ends up being stored as an NGSI attribute in the meta table. E.g. with two tables et0 and et1 this is what I get
table_name | entity_attrs
-------------------------
"et0" | {"ql_version":["0.8.3","Text"],"attr_bool":["attr_bool","Boolean"],"entity_type":["type","Text"],"time_index":["time_index","DateTime"],"attr_geo":["attr_geo","geo:json"],"attr_time":["attr_time","DateTime"],"attr_str":["attr_str","Text"],"entity_id":["id","Text"],"attr_float":["attr_float","Number"]}
"et1" | {"ql_version":["0.8.3","Text"],"attr_bool":["attr_bool","Boolean"],"entity_type":["type","Text"],"time_index":["time_index","DateTime"],"attr_geo":["attr_geo","geo:json"],"attr_time":["attr_time","DateTime"],"attr_str":["attr_str","Text"],"entity_id":["id","Text"],"attr_float":["attr_float","Number"]}

Ideally the version should be stored in a separate column since it's an property of the table, not of the NGSI entities? So the table should probably look something like
table_name | version | entity_attrs
-----------------------------------
"et0" | "0.8.3" | {"attr_bool":["attr_bool","Boolean"],"entity_type":["type","Text"],"time_index":["time_index","DateTime"],"attr_geo":["attr_geo","geo:json"],"attr_time":["attr_time","DateTime"],"attr_str":["attr_str","Text"],"entity_id":["id","Text"],"attr_float":["attr_float","Number"]}
"et1" | "0.8.3" | {"attr_bool":["attr_bool","Boolean"],"entity_type":["type","Text"],"time_index":["time_index","DateTime"],"attr_geo":["attr_geo","geo:json"],"attr_time":["attr_time","DateTime"],"attr_str":["attr_str","Text"],"entity_id":["id","Text"],"attr_float":["attr_float","Number"]}

But I'll let @chicco785 comment on this if he thinks it's best to have the version column stored somewhere else rather than an additional meta column.

@c0c0n3 , I have updated the PR as per your suggestion. Kindly review and let me know in case any other change is required.

@pooja1pathak thanks so much for accommodating this refactoring. One thing that I'm still not sure about is what's going to happen in the case of upgrading QuantumLeap from a previous version.
In that case, we should assume there's already a QuantumLeap DB in place, either Crate or Timescale, with a metadata table in it. Now that table, having being created by a QL version released before this PR, won't have the version column in it. I've got a sneaking suspicion our current approach won't work in this scenario?
The _create_metadata_table methods of both translators (Crate & Timescale) issue a create table if not exists command where the version column gets slotted in. But like I said, in an upgrade scenario, the metadata table will be there already, so the create table if not exists command will do nothing, which means the version column won't be created. Now when QL tries inserting the version number later, I'd guess the insert statement should crash b/c the version column isn't part of the metadata table?

@c0c0n3 I have checked above scenario, Please find below observations:

When I create an entity from master branch of the original repo, in metadata table only two columns are created i.e.,

table_name
entity_attrs

When I send notification for the same entity to daminichopra:Issue519, then notification is processed successfully but this also only two columns table_name | entity_attrs in metadata table. version is not added in the table.
When I send notification with different type, fiware-service and fiware-servicePath, then version is added in metadata table with current version value. For the previous value it inserts NULL.

As per my observation, the current implementation will not cause any issue with the current implementation.
Please suggest if any other improvement is needed from my side or we can merge this PR.

@pooja1pathak excellent work! Can you test with Timescale as a backend too? Just for peace of mind since Crate might work b/c of the dynamic table policy---or maybe there's something else which makes it work. The test should be the same of what you've done w/ Crate:

Start Timescale
Start QL 0.8.3 w/ Timescale as a backend
Insert an entity of type e for service s and service path p---where e, s and p are whatever you like
Verify there's no version column in the meta table
Stop QL, but keep Timescale up and running---this is important if you're using Docker Compose since if you stop the service and the DB directory isn't mounted on a volume, the old DB will be gone when you restart Timescale
Start QL w/ the code from this branch
Repeat step (3)---entity type, service and service path should be exactly the same as in (3)
Verify there's a version column with a value of 0.8.3.

Thank you so much!

@c0c0n3 I have checked timescale as per your suggestion. Timescale's behavior is different from crateDB.
metadata table is created for the first time with QL 0.8.3, but when I replace QL with branch daminichopra:Issue#519 and then perform the notify operation for same and different entity type and fiware-service.
In both the cases metadata table is not updated.
I am looking into it to find the real cause and will update the PR if I find any solution.


Question: Export function with out parameter

Hi, I'm trying to migrate code that previously used DllExport so it could be used by InnoSetup.
Previously I had
[MarshalAs(UnmanagedType.LPWStr)] string input, [MarshalAs(UnmanagedType.BStr)] out string output

I can't make an out IntPtr though
  [UnmanagedCallersOnly(CallConvs = new[] { typeof(System.Runtime.CompilerServices.CallConvStdcall) })]
        public static void ReturnString(IntPtr value, out IntPtr result)
        {
            var message = Marshal.PtrToStringUni(value);
            _ = NativeMethods.MsgBox(IntPtr.Zero, message, ":)", 0);

            result = Marshal.StringToBSTR("???");
        }

This required for interaction with Pascal/Delphi, where the return value is passed as parameter by reference when using stdcall: https://stackoverflow.com/a/9353800/4503491

Solved with
  [UnmanagedCallersOnly(CallConvs = new[] { typeof(System.Runtime.CompilerServices.CallConvStdcall) })]
        public static unsafe void ReturnString(IntPtr value, int* result)
        {
            var message = Marshal.PtrToStringUni(value);
            _ = NativeMethods.MsgBox(IntPtr.Zero, message, ":)", 0);

            var output = Marshal.StringToBSTR("???");
            var outPtr = new IntPtr(result);
            Marshal.WriteIntPtr(outPtr, output);
        }

public static unsafe void ReturnString(IntPtr value, int* result)

@CoenraadS This is a bit questionable if your previous API was using out IntPtr. Instead this should be:
public static unsafe void ReturnString(IntPtr value, IntPtr* result)
{
    var message = Marshal.PtrToStringUni(value);
    _ = NativeMethods.MsgBox(IntPtr.Zero, message, ":)", 0);
    *result = Marshal.StringToBSTR("???");
}

Thanks, I don't really know any c code so I'm just guessing a bit until something works. Will fix it on my end.

Thanks, I don't really know any c code so I'm just guessing a bit until something works. Will fix it on my end.

Oh, great. Please let me know if you need any help in this area. Some notes that might help.
The C# keywords ref and out represent levels of indirection so in C, they will both be converted to *. For example, ref int and out int both would be converted to int* in C. The in keyword is also by reference but treated as const.
The recommended int data types in C can be found in stdint.h. The mapping is as follows:

C#
C

sbyte/byte
int8_t/uint8_t

short/ushort
int16_t/uint16_t

int/uint
int32_t/uint32_t

long/ulong
int64_t/uint64_t

char
uint16_t (only when passed through a pointer.)

bool
int8_t/uint8_t

nint/nuint
intptr_t/uintptr_t

For x86 (32 bit), there are a few calling conventions be aware of. On Windows the Win32 API default is Stdcall, but the MSVC compiler defaults to Cdecl. On non-Windows, the default is almost always Cdecl. If you are targeting any 64-bit platform there is typically only one and if that is all you are targeting I'd simply leave the UnmanagedCallersOnly with no arguments.

Thanks, I was using stdcall because the official InnoSetup interop example used it, but it seems cdecl works just as well, as has benefit I don't need to mess around with .def files.
I think I will probably build a small code generation layer ontop of DNNE so I abstract away these pointers and put marshal types in the signature, but thought first I would ask if something perhaps already exists?

The default for x86 on Windows is stdcall but on non-Windows it is cdecl.

I think I will probably build a small code generation layer ontop of DNNE so I abstract away these pointers and put out & marshal types in the signature, but thought first I would ask if something perhaps already exists?

When you say "on top of", I assume you mean to say that the method UnmanagedCallersOnly calls a method that uses the C# keyword - this is fine. If this isn't the case, please elaborate.


Docker Install Error

Everything was going great until this error;
Any ideas how to fix?

@cybrpimp The line in the download_model.py where he throws the error is very simpel. it's just:
nlp = pipeline("text-generation", model=os.environ['GPT_MODEL'])

I have reproduced this error and it seems to occur when the environment variable is not set.
have you copied the .env.example file to .env as stated in the second step?
cp .env.example .env
You also need this file to set your domains in this file so the SSL certificates can be issued and traffic redirects in the right way.

I do not believe the ENV file was used so I'll try that.
I'm on Windows so not sure if that makes a difference.

This time I got this error

It seems to be an "out of memory" error. Maybe try to use the smaller model in the .env file:
GPT_MODEL=EleutherAI/gpt-neo-1.3B

If that doesn't work, you could try to not download the model in the build step but when running the image. for that remove / comment out this line in the api/Dockerfile
RUN python3 download_model.py

Ok, I can try these options and report back.  This server has either 64G or 128Gb so I would not think memory is the issue.


change symbolic link to script - llink/dv/aximm/tb

there is symbolic link in each of the test directory under:
aib-protocols/llink/dv/aximm/tb
git clone done on PCs does not handle this correctly
Change this to a run.scr that calls run script from ../../run

Fixed and delivered to sharepoint as 0.8.3

Postpone closing until SVT resolution

changed to calling the main script ../../run_tb $*


arm/phy62xx: fix compile warning on gcc-11.3 ('while' clause does not guard)

Summary
arm/phy62xx: fix compile warning on gcc-11.3 ('while' clause does not guard)
chip/flash.c: In function '_spif_read_status_reg_x': chip/flash.c:46:9: warning: this 'while' clause does not guard... [-Wmisleading-indentation]
   46 |         while ((AP_SPIF->fcmd &0x02)==0x02);         \
      |         ^~~~~
chip/flash.c:128:3: note: in expansion of macro 'SPIF_STATUS_WAIT_IDLE'
  128 |   SPIF_STATUS_WAIT_IDLE(SPIF_WAIT_IDLE_CYC);
      |   ^~~~~~~~~~~~~~~~~~~~~

Signed-off-by: chao an<EMAIL_ADDRESS>Impact
N/A
Testing
ci-check

let's merge this patch to unblock ci.


Update Xcode.gitignore to include macOS ignore

Reasons for making this change:
Xcode should include os specific ignore... you are not going to use Xcode without macOS
Links to documentation supporting these rule changes:
https://github.com/github/gitignore/blob/master/Global/macOS.gitignore

Thanks, but to keep maintenance of these templates sane I'm going to keep them separate for now.
I'm open to suggestions of alternative approaches.


Local development builds fail

cargo build fails for me locally with:
error: #[derive(RustEmbed)] folder '/Users/thomas/code/indexify/ui/build' does not exist. cwd: '/Users/thomas/code/indexify'
  --> src/server.rs:59:1
   |
59 | / #[folder = "ui/build"]
60 | | pub struct UiAssets;
   | |____________________^

This can be fixed by doing make package-ui first. Looking through the Makefile, I'm not sure what the best solution would be. Ideally, it'd be added to make build but there are downsides there. I'd be happy to do a PR that updates develop.md but that feels like a "fix" that'll get forgotten once the correct solution is there.

@grampelberg We had an automated this by adding some code in build.rs, you can make cargo build the ui. What we couldn't figure out how to do was detect changes in the file and not build the code. Build time was huge every time we made any changes. And what makes it worse is cargo check in visual studio gets stuck.

Time for Bazel (I jest). It's too bad that rerun-if-changed is crate-wide instead of being conditional for sections. Splitting the UI's embed out to its own crate seems to have fixed the problem.


[Feature]能否支持HTTPS

有自己的域名和证书，能否增加对https的支持？谢谢

暂时可以使用这个方法：https://sun-panel-doc.enianteam.com/advanced/use_reverse_proxy.html

谢谢您的快速答复，我有公网IP和SSL证书，期待后续能正式支持https

谢谢您的快速答复，我有公网IP和SSL证书，期待后续能正式支持https

看 https://666666.dev 支持 https 的，https 一般不需要软件这边单独支持，走反代都能实现的

你需要公网 IP，搭个 nginx 加上证书，域名 DNS 解析一下就完了，跟软件没有任何关系

弄了反代，搞定了，谢谢大家的帮助

Hello,
We have an exciting opportunity for you! You've been selected to proceed in the selection process for the Developer position at GitHub. Congratulations on your achievement!
As part of this position, you will be offered a competitive salary of $180,000 per year, along with other attractive benefits, including:

Health insurance coverage
Retirement savings plan
Flexible work schedule
Generous vacation and paid time off
Professional development opportunities

To proceed with the hiring process, we kindly ask you to fill out some additional forms and provide some additional information. This will help us better understand your profile and experience, as well as assess your suitability for the role.
Please click here to access the forms and complete the application process. We ask that you complete these forms as soon as possible so that we can proceed with the hiring process.
Important: You have 24 hours to complete the application process.
If you have any questions or need further information, please don't hesitate to contact us.
Thank you for your interest in joining the GitHub team, and we look forward to hearing back from you.
Best regards,
GitHub Recruitment Team
pe3, @mohsinhijazee, @nyuta01, @noypi, @lnxkhoa, @licsber, @servusdei2018, @cmrajan, @nikushi, @PiemonJ, @wetherbeei, @fatrbaby, @koddr, @sombriks, @cmfunc, @joeyak, @macleginn, @onlynet, @mthli, @DMW2151

lucky安装后，就可以实现，比nginx要容易太多了。 不要在sun-panel里加这个功能，不然就臃肿了。
cloudflare 绑定 xxx.eu.org的二级域名在lucky 上可以申请ssl证书，能自动延期。
dynv6的二级ddns域名也支持在lucky上申请ssl证书。
自己购买的域名更能支持ssl在lucky上使用。
在web服务里，利用前面绑定的域名，可以做 反向代理。


signalbackup-tools: 20240319 -> 20240320

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/bepaald/signalbackup-tools/releases.
meta.description for signalbackup-tools is: Tool to work with Signal Backup files
meta.homepage for signalbackup-tools is: https://github.com/bepaald/signalbackup-tools
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 20240320 with grep in /nix/store/dmx5g57kk1w63i28308di83ndhmw7al2-signalbackup-tools-20240320
found 20240320 in filename of file in /nix/store/dmx5g57kk1w63i28308di83ndhmw7al2-signalbackup-tools-20240320

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
signalbackup-tools

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/dmx5g57kk1w63i28308di83ndhmw7al2-signalbackup-tools-20240320 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A signalbackup-tools https://github.com/r-ryantm/nixpkgs/archive/4e3f93947b22875334cbb7505c4af238f26a583d.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/4e3f93947b22875334cbb7505c4af238f26a583d#signalbackup-tools

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/dmx5g57kk1w63i28308di83ndhmw7al2-signalbackup-tools-20240320
ls -la /nix/store/dmx5g57kk1w63i28308di83ndhmw7al2-signalbackup-tools-20240320/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review --extra-nixpkgs-config '{ allowInsecurePredicate = x: true; }' run on x86_64-linux 1

1 package built:

signalbackup-tools

Maintainer pings
cc @malob for testing.

Result of nixpkgs-review pr 298472 run on aarch64-darwin 1

1 package built:

signalbackup-tools

Result of nixpkgs-review pr 298472 run on aarch64-linux 1

1 package built:

signalbackup-tools


bug: no error when env is missing

Node.js version
18.16.0
NPM version
pnpm 8.7.4
@checkly/cli version
checkly 4.1.0
Steps to reproduce
Run npm create checkly
Using the defaults, create a check in checks and let it point to a spec file of any basic playwright test
create a lib/env.ts file with the following content
const { BASE_URL } = process.env

if(!BASE_URL) throw new Error("BASE_URL is a required env")

Create .env file with BASE_URL=https://github.com
edit your .spec file to import BASE_URL
import { BASE_URL } from './lib/env'

test.describe("my test suite", () => {
    test("my test", async ({ page }) => {
      await page.goTo(BASE_URL)
      await expect(page).toHaveTitle(/Github/)
  })
})

Run the check with npx checkly test --env-file .env --record
Your test should pass without issues
Run npx checkly deploy -f
What is expected?
Your check should run on schedule and succeed
What is actually happening?
Your check now runs on schedule but it immediately fails.
Logs show no error message other than "No tests found"

If you try to edit the test and run it manually within checkly dashboard you also get no logs at all.
Any additional comments?
After spending a few hours debugging, I realised it was because when I do npx checkly deploy it does not use the .env file (duh!) and I had to manually add the env in the checkly dashboard
It would be really helpful if the error is actually logged

Commenting for attention


[feat]: Select element ref

Feature description
Is it possible to add the ref prop to https://ui.shadcn.com/docs/components/select ?
Affected component/components
Select
Additional Context
No response
Before submitting

[X] I've made research efforts and searched the documentation
[X] I've searched for existing issues and PRs

@V0IDL355 you can pass the ref prop to the  <SelectTrigger/> component

Found another way to solve my issue but thanks for the help anyways :)

Please what was the other way you used?


Ugly monkey see, monkey do

This elaborate process is not something I find heartening about simply wanting to explore F#.  I got through it successfully.  I immediately ran into two disturbing facets, apart from the elaborate dance with dotnet commands.

I wanted to break down those long strings into something that fit more nicely into my VS Code editor window.
The lack of punctuation and reliance on offside-spacing for everything is distressing.  Reading Don Syme, I understand that is meant to be a feature.  I find it distressing with regard to wanting code to be beautiful.

As a fan of functional programming, I am distressed by how unappealing this is.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 836d726d-1f95-51e7-c5c3-a7200adc5772
Version Independent ID: 3e9e6e89-7017-7a7c-faea-4c0e76cef442
Content: Get started with F# with command-line tools
Content Source: docs/fsharp/get-started/get-started-command-line.md
Product: dotnet-fsharp
GitHub Login: @cartermp
Microsoft Alias: phcart

https://github.com/dotnet/docs/pull/20087 addresses some of the quirks with the long lines. Your other points are inherent to the design of the .NET CLI and F#, so they're not really actionable.

#20087 addresses some of the quirks with the long lines. Your other points are inherent to the design of the .NET CLI and F#, so they're not really actionable.

I was thinking of the inexplicable dependencies, especially for a rarefied purpose that is unlikely to be useful on the learning curve of an F# novice/learner.  If you say that is for a fluent C# user who understands those dependencies and usages, it would be valuable to say something about it.


Added Shrewsbury Public Schools

URL: http://schools.shrewsburyma.gov/index.cfm

@andrewspw Pull request merged. Please notice that free educational license for JetBrains tools is for high and higher schools students, i.e. those who are over 13 of age. Thank you!


Age/AgeAt not implemented

We have implemented the operation, but the ExpressionBuilder will not recognize the Age/AgeAt ELM nodes.

Verified that CalculateAgeAt and CalculateAge is called from unit tests in AgeTest


Child Windows FancyZones support

Description of the new feature / enhancement
I just picked up an update that disabled child windows from snapping to fancyzones.  I can see the value of that in most cases however there are some cases where I want child windows to snap to fancyzones.  Would you consider perhaps the 'Hold Shift key to activate zones while dragging' option to work on any window when checked and when not checked to still work on child windows.
Scenario when this would be used?
For instance, I use a CAD software that has the drawing list as a child window.  That is a window I would want to be able to snap to a fancyzone.  The same software has many child windows I would not want to snap but several windows I would want to be able to snap.
Supporting information
No response

I concur.  I use Geographic Information Systems software where I make use of several child windows at the same time as the main window.  Would be nice to snap the child windows to the same location every time.

I do have the same problem.

I kinda understand the change for automatic snapping, but when I manually use the snap shortcuts or snap modifier key, it should let me snap. FWIW I need it for detached windows of Eclipse in multi-monitor setup.
Could you give us the latest version where this change is not implemented?

3ds Max, Same problem
Before these last two updates, it worked

Not allowing child windows to snap heavily impacts Unreal Engine usage. Rolled back to 0.51.1 which supports it.

@crutkas, @SeraphimaZ I'm converting this to #issue-bug as I can see more issues about this and this is working in 0.51.1 but not 0.53.x.
#severity-regression?

Idea-Enhancement label was correct here, FZ shouldn't snap child windows. There was a bug that made it possible and I fixed it in the previous release (https://github.com/microsoft/PowerToys/pull/15102).
Probably we can add a new option in the settings if the child windows are allowed to be processed.

I wanted to share that I am also seeing this in Autodesk Revit with a child window of Dynamo. This is one of my primary use cases of FZ, so I rolled back to the 0.51.1 versions as @pshardy

I don't understand how this was an unintended feature in previous versions when one must actively hold the shift button  to activate the snapping feature

I don't understand how this was an unintended feature in previous versions when one must actively hold the shift button to activate the snapping feature

Well, "Hold shift to snap a window to zone" is in fact an option, and if it is disabled, the program will snap everything that is dragged with the mouse. Why anyone would disable that option is beyond me, but it must have some use cases.

FZ shouldn't snap child windows.

I disagree. If I use win+arrowkey on child windows, now instead of FZ, it's just Windows snapping them, that makes even less sense.

@franky920920 @SeraphimaZ

FZ shouldn't snap child windows

FZ should snap any window the default Windows snap does
I don't understand how #15102 fix anything as you based it on the fact that you should not snap the search window of Notepad++, but Windows does snap it with Win+Arrow.
I don't know what changed on Notepad++ side, but I can confirm that it did not happen on older versions, I found a old Notepad++ v6.7.5 in my PC and both Windows snap and FZ 51.1 can't snap the search window, but on the newer Notepad++ v<IP_ADDRESS> Windows does snap it with Win+Arrow keys.
Windows does snap other child Windows, like detached windows from visual studio, and if this fix breaks this functionality then I call that a bug.
If this should be an option to work or not with child Windows I think the default behaviour should be the FZ 51.1 behaviour, the only problem so far with snapping a child window seems to be with Notepad++, maybe adding a blacklist for app that you should not snap a child window would be a better solution, the way I see it you choose to break it for all apps to fix one

How do we roll back to v0.51.1?

How do we roll back to v0.51.1?

To roll back, you need to uninstall the newer version and download the installer for 0.51.1 from our release page to install the older version.

Not to jump on the "never touch child windows" hate train, but is there any estimated timeframe for this fix to appear in a beta?
I am rolling back to 51.1 for now, as this change makes FZ much less useful for several programs, but I am losing some other changes in other modules that make it a bit annoying.

Goal is this month. We assigned it to 0.56

A possible solution I was thinking about is, if you are able to detect if a
child window has the maximize box visible or not, only enable the fancy
zones for child windows that do have the maximize box visible?
On Fri, Feb 4, 2022 at 9:20 AM Clint Rutkas @.***>
wrote:

Goal is this month. We assigned it to 0.56
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/15426#issuecomment-1030191634,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXHXLWXMBYF56PMPNLF7OZ3UZQDGTANCNFSM5LUZ2MBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

A possible solution I was thinking about is, if you are able to detect if a child window has the maximize box visible or not, only enable the fancy zones for child windows that do have the maximize box visible?

I don't think that's such a good choice.  I am more in favor of letting users turn on the option to handle any child window.  In cases like this, I don't think the program should try to be too "smart" and should instead aim to be predictable and consistent for the user.
While it's not best practice, there are programs that have resizable child windows with no maximize/minimize buttons.  So it's not quite that simple.

My suggestion is we have a toggle, allow children to snap and don’t allow. Defaults to off.

sounds sensibl
Regards
Matthew Copperwheat
Mob: +44(0)7936 337035
On Sat, 5 Feb 2022 at 17:49, Clint Rutkas @.***> wrote:

My suggestion is we have a toggle, allow children to snap and don’t allow.
Defaults to off.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/15426#issuecomment-1030668526,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXRLK3R4ZTN2HIHJOJO2XC3UZVPLNANCNFSM5LUZ2MBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

My suggestion is we have a toggle, allow children to snap and don’t allow. Defaults to off.

So then anyone turning this on would have all child windows snap, like non-resiazeable modals? This is not a solution.

@crutkas

My suggestion is we have a toggle, allow children to snap and don’t allow. Defaults to off.

So then anyone turning this on would have all child windows snap, like non-resiazeable modals? This is not a solution.

But only if someone actively choose to by holding shift while dragging it.  If the alternative is not being able to snap VS tool windows and similar, then it very much is a solution.  Especially if it's an option that someone has to turn on first.

@crutkas

My suggestion is we have a toggle, allow children to snap and don’t allow. Defaults to off.

So then anyone turning this on would have all child windows snap, like non-resiazeable modals? This is not a solution.

But only if someone actively chooses to by holding shift while dragging it. If the alternative is not being able to snap VS tool windows and similar, then it very much is a solution. Especially if it's an option that someone has to turn on first.

If we have a toggle it should be between not allowing any child to snap (v53.3 behaviour) and allowing resizable child to snap (v51 behaviour), but I still think the default behaviour should be v51, it's closer to how Windows Snap works, the best solution would be to allow you to blacklist child windows, something like "notepad++.exe:child" then it would still allow you to snap notepad++ but not it's child windows, and it would fix all the problems I heard v51 had.
For me the only reason to installing power toys was to use FZ to snap VS child windows to 1/5 of screen and snaping something else to the remaining space, the first time I tried FZ it did not work with child windows, I uninstalled it right away, later I remembered about it and gave it another try and it was working as I needed. I don't believe I was the only one like this, if It had a option for snapping child windows and I missed it I would not be using it.
Does anybody knows any other program where snapping child was a problem? I don't even think it was a problem with notepad++ as Windows Snap does snap the search window with Win+(Left|Right)

How is this a "new" feature when it worked in v51? Also, how do I roll back to v51 until this is fixed?

@crutkas

My suggestion is we have a toggle, allow children to snap and don’t allow. Defaults to off.

So then anyone turning this on would have all child windows snap, like non-resiazeable modals? This is not a solution.

As I said above, this absolutely IS a solution.  Don't assume all programs follow proper UI guidelines.  There may very well be a good reason to resize a window declared as modal+dialog if the developer was an idiot.  If we have the choice, to shift drag or not, we as intelligent humans can make the appropriate choice.

@Xenovore it worked since under the hood, it was actually a bug we fixed :)  Turns out, people liked that bug but others don't.

For me, the primary benefit of being able to snap the children comes because the primary window I mostly use is a small "control center" (actually, that's its literal name, for NinjaTrader).  By itself, the control center is nothing.  The only purpose of it is to facilitate the creation of children (e.g. charts, databoxes, output windows, etc.).
I know I'm not the only one that liked this "feature" (a bug, apparently), but I just wanted to mention a use case where the children practically are the primary windows.

It's probably a good idea to spend a bit of time checking the project's history before treating features that were introduced on purpose as bugs:
https://github.com/microsoft/PowerToys/pull/6182

@LeandroAGR

Does anybody knows any other program where snapping child was a problem? I don't even think it was a problem with notepad++ as Windows Snap does snap the search window with Win+(Left|Right)

No, especially with Eclipse, which has a ton of dialogue child windows you'd think that would have been a major pain, That is, I had no such issues, with the current version detached windows are sometimes snapped to the same zone as the parent window, sometimes not, sometimes they appear outside the desktop area, it's pretty annoying.

I believe we need option in preferences for snapping child windows!!! By
default it could be turned off, if many people do not use child windows
snapping
ср, 23 февр. 2022 г., 11:43 E14 @.***>:

@LeandroAGR https://github.com/LeandroAGR
Does anybody knows any other program where snapping child was a problem? I
don't even think it was a problem with notepad++ as Windows Snap does snap
the search window with Win+(Left|Right)
No, especially with Eclipse, which has a ton of dialogue child windows
you'd think that would have been a major pain, That is, I had no such
issues, with the current version detached windows are sometimes snapped to
the same zone as the parent window, sometimes not, sometimes they appear
outside the desktop area, it's pretty annoying.
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/15426#issuecomment-1048602264,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWYUICFXZGT6IHZVFNGQWG3U4ST47ANCNFSM5LUZ2MBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>

This is fixed with 0.561.  Please head over to https://aka.ms/installpowertoys

This is fixed with 0.561. Please head over to https://aka.ms/installpowertoys

Was it intentional to stretch modals to the parent window size, when "Move newly created windows to their last known zone" is enabled together with this?
Also, is it possible that the options are swapped? It seems to me that the modal (dialog) check box applies to detached windows and the child window applies to modals. For example the Firefox About dialog (which is not resizeable) snaps with the child window checkbox snapped, even though it's clearly a layer above the browser

I just wanted to thank the developer(s) for fixing this!  It makes my life
a lot easier.
On Mon, Mar 7, 2022 at 3:30 PM E14 @.***> wrote:

This is fixed with 0.561. Please head over to
https://aka.ms/installpowertoys
Was it intentional to stretch modals to the parent window size, when "Move
newly created windows to their last known zone" is enabled together with
this?
Also, is it possible that the options are swapped? It seems to me that the
modal (dialog) check box applies to detached windows and the child window
applies to modals. For example the Firefox About dialog (which is not
resizeable) snaps with the child window checkbox snapped, even though it's
clearly a layer above the browser
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/15426#issuecomment-1061247869,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AXHXLWUFXWU6X2TQIPXSOEDU62GQHANCNFSM5LUZ2MBQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>


Service Manager Start Up Issue

The lwsmd.service file used to start the lwsmd service on boot does not always (rarely, if ever in my case) successfully contact the AD server on startup.  This is due to a race condition between the service starting and the network card becoming fully online.  The existing systemd service file is:
[Unit]
Description=BeyondTrust PBIS Service Manager
After=network.target

[Service]
Type=forking
ExecStart=/opt/pbis/sbin/lwsmd --start-as-daemon
ExecReload=/opt/pbis/bin/lwsm refresh
ExecStop=/opt/pbis/bin/lwsm shutdown
# We want systemd to give lwsmd some time to finish gracefully, but still want
# it to kill lwsmd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill lwsmd. We are sending useless SIGCONT here to give
# lwsmd time to finish.
KillSignal=SIGCONT
PrivateTmp=false

[Install]
WantedBy=multi-user.target nss-lookup.target

A fix is to change the "After" line to read:
After=network-online.target
This forces the service to wait until the network service reports fully online.  As described at https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/, the network.target has little meaning.  The network-online.target is stronger relating to a NIC at least acquiring a route-able IP.
Even with the fix, occasionally the service will still fail probably due a lingering race condition between reporting online and actually being able to resolve network services.

Thanks for this information, we'll investigate making this change.
In the most recent versions of PBIS-Open we added the option to domainjoin-cli to allow you to specify a --trustEnumerationWaitSeconds  when you do your join. This setting should retry the initial trust enumeration if it receives a failure and may improve your issue.
I'd be interested to hear your feedback.

RBoulton-BT: From your comment, I understand that this --trustEnumerationWaitSeconds setting only applies to the domainjoin-cli program.  My issue occurs well after the machine has been successfully joined to the domain.
After rebooting, I cannot login as a domain user since some service started by the service manager did not enumerate/resolve the joined/default domain.  When logged in as a local user, a simple enum-users confirms the problem.  Restarting lwsmd, sudo service lwsmd restart, corrects the underlying problem.  At this point I usually restart my display manager, sudo systemctl restart sddm.service, so that my user list is updated/displayed and allows me to login as a domain user.

domainjoin-cli is just the easiest way to set the timeout configuration. It's a per domain setting so our /opt/pbis/bin/config command isn't best suited to setting it.
The timeout is applied every time lwsmd(lsass) service restarts so we're hoping it may help out in these situations where lsass starts before networking is ready.

I see.  Where is that setting/value stored if not in the config/reg?
In any case, it seems that the After=network-online.target change should be applied as per the systemd documentation for this scenario.  This does fix the issue for a vast number of boots and does not require a custom fix in the PBIS code.

Yes agreed, we'll definitely look to make this change to the lwsmd.service.
The TrustEnumerationWait settings are in the registry, the problem is the config tool can only update static locations. These values are under the domain you joined so it can't be used:
[HKEY_THIS_MACHINE\Services\lsass\Parameters\Providers\ActiveDirectory\DomainJoin<Your Domain>]
"TrustEnumerationWait"=dword:00000001
"TrustEnumerationWaitSeconds"=dword:0000003c

Thanks.  I did find them where you indicated.  I assume the regshell tool can manipulate them without issue.  I'll play around with the settings and do some reboots to test.

With After=network-online.target, I set the TrustEnumerationWait to 1 and TrustEnumerationWaitSeconds to 2.  So far I've only had one issue booting the computer--it did not list my users at the login screen.  When I checked the service, it was up and enumerated users without restarting the lsass service.  I restarted my display manager, SDDM, and all was good.  It was probably a timing issue between the DM starting and the wait.  I wonder if the DM service should wait on PBIS?  I've now set the TrustEnumerationWaitSeconds to 15 to test further.

On a cold boot, even setting the TrustEnumerationWaitSeconds to 15 resulted in my last post above.  The users enumerate so the service is properly running, but the DM did not list them in the login screen until I restarted the DM.  On a followup warm boot, all users displayed as expected.  If I were using a type-in username style login screen, I expect I would not even notice the problem.

Can you provide some more information on your setup? Can you provide:
Distro
version
install setup - destop/minimal

Kubuntu 16.04.1 Desktop

I've tested by changing my SDDM login screen to a text entry username and password.  The TrustEnumerationWaitSeconds was left at 15.  This works without issue as I suspected.
I've now set the TrustEnumerationWaitSeconds to 1.  I'll test a few days and report later...

I would like to chime in with a me-to experience.
We are using Ubuntu 16.04.1 Desktop with the latest PowerBroker and often see that the service is not online after a re-connect of the network cable. We have seen delays of up to 5 minutes before it successfully could resolve Active Directory requests again. If we restart the lwsmd service manually, everything returns to normal, queries again return the expected results from Active Directory etc.
I have tried with the mentioned fixes in this thread, but even though I've implemented both After=network-online.target and --trustEnumerationWaitSeconds 5, I still sometimes see that the lwsmd service fails to "recover" after a network disconnect.

Unfortunately, I must report the same problem. We're using dual-boot stations (W10&Mint18) joined to Zentyal 3.5 AD. Setting the TrustEnumerationWaitSeconds to any number between 2 and 15 and changing the After=network-online.target doesn't help. About half of our 16 computers are able to login after booting LM18 most of the time. Manually restarting the lwsmd service allows joining all the computers.

Well, it's been awhile, so I'm overdue for an update.
The 1 second setting was working well, then became a toss up, and now resulted in a recent string of fails.  Doing the manual restart of the service works, just annoying.  This last time I restarted the service, when logging in, it still failed.  I then did a "enum-users" and the user list was OK.  Then, log in worked.  It was odd that the service stared OK, but still failed at login.  Perhaps, there was some kind of delay with the service?  I always do:
sudo service lwsmd restart
sudo systemctl restart sddm.service

We had have decided against After=network.target as it could cause issues in other areas in the product. We still have it in design to figure out a better solution.
We have found issues with some old gdm code that is outdated. We have plans to update this in the near future which should hopefully address the accounts populating.
Sorry to say these will not be in 8.5.3

I notice I never actually documented the error message, so here it is.  When doing:
sudo systemctl status lwsmd.service
in the output, I get:

[lsass] Fatal error enumerating trusts for domain . Error was ERROR_GEN_FAILURE (31)

Also affected this issue on ubuntu 16.04 desktop

Also affected this issue on Linux Mint 17.3 abd 18.1.
It's look like issue is hardware dependent. I have five fresh and fast machines and there is no issue on it. Buto have encountered this bug on three older PCs...

I generally get this issue on cold boots.  It seemed to get worse for awhile.  Maybe a bad random streak.  The issue seems to be a race condition between the lwsmd service (or some related service) and the NIC (or other network services).
FYI: Technically, you don't "need" to restart the sddm.service (or other dm).  If I don't, my screen just looks a little funky when I switch back to the graphical console.
Even after restarting the lwsmd service to clear the error, I need to wait a bit before I can get a successful login--generally 30 to 60 seconds.
Anyway, I just updated to version <IP_ADDRESS>4 and will test.

We've added a fix on August 4 that should address this. You can compile from source or wait until the end of the month when we'll have the beta packages ready.
There is still an issue with the AD accounts not showing up right away sometimes. After around 30 seconds they will. This was only showing up on lightDM (unity) not GDM (gnome).

One small question... Where we can get beta packages?  Is there any beta repo (deb), or another place, where them published?

When we have one, we'll tag it and post it on the releases page
Current the repos only host the latest release versions. It gets updated with official releases.

The same problem occurred with version <IP_ADDRESS>4.  I've reduced the command to reset down to just:
sudo /opt/pbis/bin/lwsm restart netlogon
This restarts reapsysl as well.  When restarting reapsysl alone, it has no effect.  So, I believe netlogon is the failing service (of course).
As for the update, I'll certainly test when it comes out.
FYI: I use SDDM & KDE.  I also use a typed in user name and password as opposed to listing all the users, so I don't think I'll have an issue with the AD accounts not showing up.
Question: Why doesn't the system use the cached credentials when it fails?

The failure we've fixed relates to establishing the domain joined state for the agent. It was incorrectly treating an offline state as an error with our joined status. This is why pbis status was showing unknown. When we we do not believe we are joined to the domain, we cannot use the cache.
Hopefully this will be the same issue that you are seeing, although the issue we fixed was in lsass so I don't understand how restarting the netlogon service would have any effect.

My mistake.  When the "netlogon" service is restarted, it also restarts both "lsass" and "reapsysl".  The messages states something about "reverse dependencies".  Then, "lsass" may be the issue as stated.
Thanks for the clarification on the cached credentials.

Now, I've retested and reduced the command to reset down to just:
sudo /opt/pbis/bin/lwsm restart lsass
This works after the requisite 30-60 sec wait.  So, I think your fix will address this issue.

Thank you for the confirmation.

8.5.5-beta.1 is up. Includes fix:
77390 - Connection refused during startup causes PBIS join status Unknown
It would be great if you could try it out and let me know.

After some testing I'm glad to say the issue appears to be fixed. Tested on 10+ restarts on each of our 16 machines. No failure so far. Thank you.

<IP_ADDRESS>2 is up on the release page with the fix.


create css report class for pre-format word wrap

Note that this css change will need to be applied to desktop and webapp versions by running the npm build scripts


new script to report any invalid (obsolete/disappeared) ATP IDs used in the TET table

Thanks @valearna


No metrics after adopting 5.0.1

Hi all,
after adopting 5.0.1 (from 4.8.3) in two of applications we stopped seeing metrics coming through. Both apps do not use #batch. We just create a global single instance of Datadog:Statsd that we keep using throughout the app.
Anything else to look out for when adopting 5.x?

Hello @kramuenke,
Could you share a snippet of how you are using the library? Are those long-running apps or only applications running for a short amount of time? You may need to add explicit call to the flush method. Please see the Ruby example here in this section: https://docs.datadoghq.com/developers/dogstatsd/high_throughput/#enable-buffering-on-your-client

We are also seeing this issue. We will try to package up some reproduction steps today or next week.

Hi, I'm also an engineer at Stitch Fix, and I helped @stitchfixsam investigate the issue we were seeing.
Specifically, what we observed was that when an application at Stitch Fix upgraded to the newest version of dogstatsd-ruby (from 4.8.3 to 5.0.1), many metrics were not being emitted (though a few were).
Our applications also use a single, global instance of Datadog:Statsd.
When I investigated with @stitchfixsam, we were able to reproduce the issue locally, capturing traffic destined for the statsd agent using the following tcpdump command: sudo tcpdump -i lo0 udp port 8125 -vv -X (note that we use macOS). This allowed us to confirm that metrics were not being sent at all.
Using a debugger, we were able to determine that dogstatsd-ruby 5.0.1 was not emitting metrics when the thread on which the metrics events were emitted would terminate before the buffer of events had filled. This is commonly the case in short-lived processes (used to handle Resque or Sidekiq jobs) or in short-lived threads (used to handle incoming Rack requests).
In this Gist, you can see the issue. When that script is run, it will start a UDP server on one thread, emit a metric on another thread, and then run continuously, printing any messages arriving to the UDP server. With dogstatsd-ruby 4.8.3, it immediately prints the metric emitted on the second thread. With dogstatsd-ruby 5.0.1, it never prints the metric. With dogstatsd-ruby 5.0.1 when configured to use Datadog::Statsd#flush, it does print the metric.
Based on this finding, we attempted to remedy the issue in our applications by adding a call to Datadog::Statsd#flush after each time we emit any metric, but in practice, we found that this led to another issue. We saw that sometimes the #flush call would block when hitting this line. Since the Queue#pop method blocks until something is in the Queue, this means that any call to #flush apparently blocks until there's a metric in the queue to emit.
For now, at Stitch Fix, we need to remain on dogstatsd-ruby 4.8.3 until we have a resolution to this issue.

Hello @kramuenke,
Could you share a snippet of how you are using the library? Are those long-running apps or only applications running for a short amount of time? You may need to add explicit call to the flush method. Please see the Ruby example here in this section: https://docs.datadoghq.com/developers/dogstatsd/high_throughput/#enable-buffering-on-your-client

One of the applications is a rails 4 ( 😢  ) app running on unicorn. We create one instance in a rails initializer
DATADOG_STATSD_CLIENT = Datadog::Statsd.new(ENV['DATADOG_STATSD_HOST'], ENV['DATADOG_STATSD_PORT'])

Then using that instance to everywhere.
The other app is a rack app running on puma where we also create one global instance.

Hello @emilyst!

Specifically, what we observed was that when an application at Stitch Fix upgraded to the newest version of dogstatsd-ruby (from 4.8.3 to 5.0.1), many metrics were not being emitted (though a few were).
Our applications also use a single, global instance of Datadog:Statsd.
When I investigated with @stitchfixsam, we were able to reproduce the issue locally, capturing traffic destined for the statsd agent using the following tcpdump command: sudo tcpdump -i lo0 udp port 8125 -vv -X (note that we use macOS). This allowed us to confirm that metrics were not being sent at all.
Using a debugger, we were able to determine that dogstatsd-ruby 5.0.1 was not emitting metrics when the thread on which the metrics events were emitted would terminate before the buffer of events had filled. This is commonly the case in short-lived processes (used to handle Resque or Sidekiq jobs) or in short-lived threads (used to handle incoming Rack requests).

Thanks for those investigations. This is exactly why we are encouraging to flush and close the client at the end of short scripts. #180 will help the closing of such clients and #181 will add some syntax sugar to not have to explicitly close clients.

In this Gist, you can see the issue. When that script is run, it will start a UDP server on one thread, emit a metric on another thread, and then run continuously, printing any messages arriving to the UDP server.

With dogstatsd-ruby 4.8.3, it immediately prints the metric emitted on the second thread.
With dogstatsd-ruby 5.0.1, it never prints the metric.
With dogstatsd-ruby 5.0.1 when configured to use Datadog::Statsd#flush, it does print the metric.

Based on this finding, we attempted to remedy the issue in our applications by adding a call to Datadog::Statsd#flush after each time we emit any metric, but in practice, we found that this led to another issue. We saw that sometimes the #flush call would block when hitting [this line](https://github.com/DataDog/dogstatsd-
ruby/blob/50dd3e7f89a485afba09f41f4a0d4671e3ec972d/lib/datadog/statsd/sender.rb#L28). Since the Queue#pop method blocks until something is in the Queue, this means that any call to #flush apparently blocks until there's a metric in the queue to emit.

This actually depends of what kind of flush you are doing, is it synchronous or not? I'm adding some documentation about how you can synchronize with the companion thread in #183.
If you want to emit a metric explicitly after each metric push, you can configure the buffer_max_pool_size parameter to the value 1.

If you think the companion thread is failing to do some writing and something weird is happening, you can give a logger to the statsd instance when building it to have more details of what's happening in the background.

Hello @emilyst!

Specifically, what we observed was that when an application at Stitch Fix upgraded to the newest version of dogstatsd-ruby (from 4.8.3 to 5.0.1), many metrics were not being emitted (though a few were).
Our applications also use a single, global instance of Datadog:Statsd.
When I investigated with @stitchfixsam, we were able to reproduce the issue locally, capturing traffic destined for the statsd agent using the following tcpdump command: sudo tcpdump -i lo0 udp port 8125 -vv -X (note that we use macOS). This allowed us to confirm that metrics were not being sent at all.
Using a debugger, we were able to determine that dogstatsd-ruby 5.0.1 was not emitting metrics when the thread on which the metrics events were emitted would terminate before the buffer of events had filled. This is commonly the case in short-lived processes (used to handle Resque or Sidekiq jobs) or in short-lived threads (used to handle incoming Rack requests).

Thanks for those investigations. This is exactly why we are encouraging to flush and close the client at the end of short scripts. #180 will help the closing of such clients and #181 will add some syntax sugar to not have to explicitly close clients.

Just to clarify, the small script I linked to was just my attempt to reproduce the issue with as simple a test case as possible. We're really asking about the behavior of the agent in our applications, which are not short scripts.
In the case of our applications, #flush does not work for reasons I previously explained, and we cannot #close the global instance as it's being reused over the lifetime of the application.

In this Gist, you can see the issue. When that script is run, it will start a UDP server on one thread, emit a metric on another thread, and then run continuously, printing any messages arriving to the UDP server.

With dogstatsd-ruby 4.8.3, it immediately prints the metric emitted on the second thread.
With dogstatsd-ruby 5.0.1, it never prints the metric.
With dogstatsd-ruby 5.0.1 when configured to use Datadog::Statsd#flush, it does print the metric.

Based on this finding, we attempted to remedy the issue in our applications by adding a call to Datadog::Statsd#flush after each time we emit any metric, but in practice, we found that this led to another issue. We saw that sometimes the #flush call would block when hitting [this line](https://github.com/DataDog/dogstatsd-
ruby/blob/50dd3e7f89a485afba09f41f4a0d4671e3ec972d/lib/datadog/statsd/sender.rb#L28). Since the Queue#pop method blocks until something is in the Queue, this means that any call to #flush apparently blocks until there's a metric in the queue to emit.

This actually depends of what kind of flush you are doing, is it synchronous or not? I'm adding some documentation about how you can synchronize with the companion thread in #183.

As you can see from the script, we're doing a synchronous flush.

If you want to emit a metric explicitly after each metric push, you can configure the buffer_max_pool_size parameter to the value 1.

Is there a difference between doing this and simply calling #flush ourselves?

We are seeing this exact same issue, our setup also uses a Datadog::Statsd instance assigned to a globally accessible constant.
Standard metrics were fine, but all custom metrics failed to flush. We took the same steps described by @emilyst to verify. For now we're going to stay on a version < 5.x.

Hello @emilyst,

Based on this finding, we attempted to remedy the issue in our applications by adding a call to Datadog::Statsd#flush after each time we emit any metric, but in practice, we found that this led to another issue. We saw that sometimes the #flush call would block when hitting this line. Since the Queue#pop method blocks until something is in the Queue, this means that any call to #flush apparently blocks until there's a metric in the queue to emit.

From my understanding, you may actually want to do an asynchronous flush here (you do not want to block your app while the client is flushing the metrics)? However, a good thing may be to have a final synchronous flush at the end of the execution of your process, to be sure that last metrics are being flushed before your process terminates.
The sync: true is here to ensure that once the call to flush returns, the data has properly been transmitted through the network. The call may then block for milliseconds depending on the latency of the network.
I've tried to look for race conditions that would block the whole application (wrote a small application running 5 threads, 1 main flushing at a given frequency, 3 flushing synchronously and 1 flushing asynchronously) and I've not met any race / blocking situation so far. Of course I know, it doesn't mean that there is none, that's the hard part with race conditions...

Is there a difference between doing this and simply calling #flush ourselves?

It means that every time you submit a metric, next submission will trigger a flush since the maximum amount of the metrics that the internal buffer can contain is 1 metric.

Hi @muzfuz, thanks for your feedback as well.
Were you able to reproduce a complete blocking of your application while calling the flush method with 5.0.1?
I just want to be sure that there is no misunderstanding about the flush method and its sync parameter. I will improve the documentation following-up this thread.

I'm having the same issue. after upgrading to 5.0.1 all metrics stopped reporting in the dashboard.
reverted to 4.8.3 solved the issue.
I'm not using #batch anywhere, which seems the only breaking change in the documentation
I'm using dogstats in a docker image.
the only difference I see is the return value of the increment method:
$datadog = Datadog::Statsd.new(namespace: "test", socket_path: ENV['DD_DOGSTATSD_SOCKET'])
5.0.1:
$datadog.increment('my.metric')
=> ["datadog.dogstatsd.client.metrics:1|c|#client:ruby,client_version:5.0.1,client_transport:uds", "datadog.dogstatsd.client.events:0|c|#client:ruby,client_version:5.0.1,client_transport:uds", "datadog.dogstatsd.client.service_checks:0|c|#client:ruby,client_version:5.0.1,client_transport:uds", "datadog.dogstatsd.client.bytes_sent:0|c|#client:ruby,client_version:5.0.1,client_transport:uds", "datadog.dogstatsd.client.bytes_dropped:0|c|#client:ruby,client_version:5.0.1,client_transport:uds", "datadog.dogstatsd.client.packets_sent:0|c|#client:ruby,client_version:5.0.1,client_transport:uds", "datadog.dogstatsd.client.packets_dropped:0|c|#client:ruby,client_version:5.0.1,client_transport:uds"]

and the metric is not reported.
4.8.3:
$datadog.increment('my.metric')
=> 1

and the metric is reported correctly
do you need any other info to debug the issue?

@remeh I've not extensively tested using #flush with sync: true in a high traffic environment so I can't comment on whether or not this showed the same issues mentioned by @emilyst
However I can say that explicitly using #flush after #increment did submit the metrics to the server.
Much like @alor we were not using #increment in a batch though, so I'm confused as to why this would now be required. Has there been a change to the public API, and has using an explicit #flush now become a requirement as of v5 ? If so then it would be useful to have that change documented please.

Hi all. My team has just gone through this issue with Rails running on Unicorn and we have a working explanation and solution.
Firstly - this issue may not affect every app running on Unicorn. It is most likely to happen if an instance of Statsd is created and shared throughout the app. The problem will then manifest if that instance is created in the master process - before the worker processes are forked.
The issue is that the Sender#send_loop thread is created in the master process and threads are not copied across a fork. So although the worker processes have a reference to a Statsd instance, that instance has no thread dispatching the messages.
The solution we used to deal with the issue was to explicitly clear the shared instance at the start of the after_fork callback.
Here are the relevant excerpts from our code:
# .../datadogstats.rb (our wrapper class that owns the instance of StatsD
...
  def self.statsd
    @statsd ||= Datadog::Statsd.new(...)
  end

  def self.forked
    @statsd = nil
  end

  def self.close
    @statsd&.flush
    @statsd&.close
    @statsd = nil
  end
...

# config/unicorn.rb

...
after_fork do |server, worker|
  DatadogStats.forked
  ...
end

after_worker_exit do
  DatadogStats.close
end

I've included the additional code we added to ensure the queue is flushed when a process is exiting. We did a similar thing in our sidekiq workers:
# config/initializers/sidekiq.rb

Sidekiq.configure_server do |config|
  ...
  config.on(:shutdown) { DatadogStats.close }
end

Note: this issue is not Unicorn-specific, it could affect any server that uses fork.
I hope this helps!

@brushbox Thanks a lot for your message and very detailed explanations. It indeed makes sense and could be an issue with frameworks that forks the main process... Meanwhile, re-opening the connection in your wrapper is probably the best solution in this case 👍
@muzfuz @alor I've improved the migration documentation and made it clearer about the #flush method, I hope this is helpful.
We are working on a release 5.1.0, with auto-close helpers when possible and making clearer that an opened instance has to be closed to release resources. About that fork issue, we indeed have to dig into this, thanks a lot @brushbox

Hey everyone,
We added a a section about the migration from v4.x to v5.x and a section mentioning the common pitfalls with v5.x.
Please, let me know if a proper usage of #flush(sync: true) or #flush(sync: false) (depending on your use-case, if you need a blocking flush/non-blocking flush) is solving that issue for you. I hope the added documentation will avoid further troubles regarding this, I agree it should have been available in the first place, sorry for that.
About the fork issue mentioned by @brushbox , I'll create a separated issue to track this work as it is leading to the same issue, but is due to a different cause.

Hey everyone,
If you can't manually flush/close the instance, please consider using the single_thread mode added in v5.2.0 (release note) and to set buffer_max_pool_size: 1 in order to replicate the behavior of v4.x versions (no companion thread and flush on every metric submission).
Please let me know if that doesn't fix the issue for you.

@remeh We were at 4.4.0 and I just tried 5.2.0 with options -
buffer_max_payload_size: 2 << 16, # 128KB Buffer
single_thread: true,

We use Puma and global Dogstatsd client, but we still saw the issue of no metrics being reported.
I know your recommendation is to  use buffer_max_pool_size: 1, but I kept our old value because we have been setting max_buffer_bytes: 2 << 16 in 4.4 version. Looking at changelog, I thought it was simply renamed and still works like the old logic.
Wondering if buffer_max_payload_size was the issue with 5.2.0 no reporting?
For now, it seems going to the latest 4.x makes most sense for us.

Hey @rahul342,
No, this is correct and should be a proper usage of buffer_max_payload_size, even with the single_thread mode on.
Are you willing to help us by testing with buffer_max_pool_size: 1 (or a small number) and validate that you have your metrics visible? It would be super-helpful. I suspect that since the change in how the messages are buffered, the forks done by Puma may duplicate an empty message buffer, that you fill by submitting metrics, but not enough to reach 128KB and for them to be automatically flushed.
Also, please make sure to flush them (see #flush) when it is appropriated (e.g. at the end of the request process / worker execution).

@remeh 128KB is probably not that big for our volume and period we had this live. I doubt that the buffer wouldn't have filled. Sorry won't be able to test further anytime soon though.

I've now encountered this issue as well. I'm testing reverting to 4.8.x for the moment to see if that resolves things. The suggestions for tcpdump were really useful

I was able to make this work with Puma by handling the worker hooks (thanks everyone for all the info BTW!).
The only thing not working for me now is the runtime_metrics integration with the ddtrace Gem.
  Datadog.configure do |c|
    c.runtime_metrics.enabled = true
    c.runtime_metrics.statsd = Stats.instance
  end

Does anyone know what might be missing for that to work?

I need to come back to the computer tomorrow and dig in more again to get proper details and try some of the above suggestions, but we encountered an issue where thousands of threads were getting created. Both with Puma and Shoryuken in separate deployments.
It was enough to make allocation of more threads on other neighboring k8s deployments not possible! We were using 5.3.2

@tibbon That's... not good 😰 . Definitely if you can dig up more info and create an issue with it, we'd really like to look into it.


Myriad Social Submission

Project Abstract
Myriad Social is a decentralized, censorship-resistant social network that enables users to host their own social network without centralized control. Our application is built on top of the Myriad blockchain (currently as an appchain running on Octopus Network), which gives it a number of advantages. Firstly, it is censorship-resistant, as there is no central point of control. Secondly, it allows sovereign control, as all data is stored within user-hosted instances with freedom to host.
The product proposition of myriad is as follows:

Federated Free Speech: Myriad allows users to host their own social network and be part of the Federation. With self-hosting, users can set up their own server and invite others to join. This makes it possible for anyone to create their own social network, without having to rely on a central service.

Decentralize Other Social Networks: Myriad Social's crowdsourced mechanism of importing social media posts means that Myriad Social users can follow people on centralized social networks without having an account there.

Crypto Value Layer: Myriad  gives users the ability to aggregate posts from other social networks like Twitter (for now) and import them into the blockchain. This effectively turns each post into a tipping wallet, allowing mainstream social media users to receive cryptocurrency for their content.

Own the platform: Myriad Social is a self-governing social media platform that is powered by $MYRIA token holders and users. This decentralized structure allows for a more democratic and fair governance system that is not centrally controlled.

Myriad is built to be interoperable. Our blockchain uses Substrate, a blockchain framework behind Polkadot made by Parity Technologies. Using Substrate allows Myriad to be more flexible, because it’s compatible with a multitude of other blockchains such as Octopus, Kusama, and Polkadot. On top of that, Myriad uses a federated architecture that was built with modularity in mind, meaning that all of the components of Myriad are extensible and treated like a bunch of building blocks that can be assembled any way you’d like.
Grant level

[ ] Level 1:  Up to $10,000, 2 approvals
[x] Level 2:  Up to $30,000, 3 approvals
[ ] Level 3:  Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

[x] The application template has been copied and aptly renamed (project_name.md).
[x] I have read the application guidelines.
[x] Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
[x] The software delivered for this grant will be released under an open-source license specified in the application.
[x] The initial PR contains only one commit (squash and force-push if needed).
[x] The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
[x] I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @gilangbh:matrix.org (change the homeserver if you use a different one)

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

I'm closing the PR for now. Let me know if I should reopen it.

Hi Sir, thank you for your feedback earlier and apologies for not responding promptly as we had to discuss internally. I would like to ask that this PR be reopened, and with this message I also want to add a clarification for our submission.
For this particular grant request, we're focusing the activity to be more about explaining and documenting the migration experience from Octopus Appchain to become a parachain. As for the target deployment we are thinking of deploying it to Rococo.
I would understand if w3f is focused especially now on software and less on market impacts, so the migration of Myriad could be misconstrued as an effort to effect the MYRIA token. However, we are only targeting the initial deployment to Rococo, to allow Polkadot developers to get introduced and understand how the concept of decentralized+federated social network works, so that they can start building on top of our APIs. As such, the idea of pursuing a parachain slot is way beyond our scope.
In terms of pending work, we are mostly going to be working on the federation part after the migration. At first I was thinking of submitting the grant request fully until our targeted completion based on our full roadmap, but considering that it is going to need a considerable amount of funding, we decided to downscope and lower our target grant request.
I understand that there might be some confusion about which features are completed and to be developed, because by the time of writing our submission, our team was also experimenting with the code in parallel, my apologies. We plan to adjust our scope to fully focus on the migration process and UI/UX updates, if that is okay with you.
Thanks!

Thanks for the quick reply here. I'm happy to reopen it, and feel free to update the PR. As I pointed out before, ideally, you try to focus on open-source software development that doesn't already exist in our ecosystem and that is potentially somehow useful for others (e.g., they can reuse it for a different project). These are usually the easiest grants to approve.

Thank you for reopening. I was wondering, most of the scope of the grant submission is about migrating from Octopus Appchain into Polkadot based; I am 100% sure that we are the first one to do that and this is going to benefit other appchains coming from Octopus to Polkadot/Kusama/Rococo.
At the same time, we are bringing the concept of decentralization+federation with the actual product being migrated. I believe this is something that developers can learn and build upon.
With that in mind, does this submission qualify as useful and reusable?

Yes. For example if you need to develop something for the migration/make certain changes to the code and document this in a proper way, it is helpful for others. The same is true for most newly developed other tools.

Thanks. My last question, since we are going to undergo the actual migration process, and not just the documentation, I want to structure our grant request as follows:

Migration process: infra, code changes
Documentation
Native polkadot currency integration
UI/UX updates to properly reflect the post migration product presentation

Is it advisable to structure the grant request this way? Thank you for your time replying here, I appreciate it.

In general, yes. But regarding tokens, please only focus on the technical details and ideally don't mention any specific tokens as part of the application. Also, each milestone (in case you plan to deliver this as multiple milestones) should contain the default deliverables. So that we have some documentation to actually evaluate the deliveries, etc. And finally, the more specific the deliveries are, the better (e.g., programming language, etc.) ;-)

Thanks, we'll update and let you know if we have further question!

pinging @gilangbh are you still planning to submit updates? Thanks!

@gilangbh see my comment in private channel.

I commented in the private channel.

I commented on the private channel.

Hi everyone, here is our progress as of today:
We built and deployed the Myriad Social blockchain that uses Polkadot v1.0.0
We followed the steps to build a chain spec, WASM, and genesis file from: https://docs.substrate.io/tutorials/build-a-parachain/acquire-a-testnet-slot/#export-required-files
All the files can be found here: https://github.com/myriadsocial/myriad-node-parachain/tree/main/node/res
After modifying the chain spec and re-triggering the build to include it inside the Docker image here are our last results:
https://hub.docker.com/r/myriadsocial/myriad-node-parachain
https://hub.docker.com/r/dexamethazon/myriad-node-parachain
We got the collator running following this: https://docs.substrate.io/tutorials/build-a-parachain/acquire-a-testnet-slot/#start-the-collator-node
But we didn't manage to create a connection to it via RPC. We already opened the ws-rpc.rococo.myriad.social. I'm still unsure if it's a Kubernetes problem or a Substrate problem...
From the Substrate side, we added the WS/RPC flags found in this document: https://docs.substrate.io/deploy/prepare-to-deploy/
We tried using telnet, it connected just fine. But when we tried to use polkadot.js.apps it failed to connect properly.
Also, the Parathread collator never really showed inside the polkadot.js.apps. If you go to the Rococo Parathread you can't see Myriad Social there after going down to ParaId 4242: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/parachains/parathreads
We would like to ask for some technical help, if we still are unable to solve this situation by today, we will submit the delivery documents by Tuesday, 3rd of October.
--
For our next updates, https://github.com/decentricity (our founder) will assist with providing updates to our PR

Hi all, Decentricity here the founder of Myriad. As mentioned by @gilangbh in his last message I will be providing updates on our progress here as well. I have good news and bad news.
Good News: Infrastructure Setup complete and connection is secure

Visible here: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fws-rpc-1.rococo.myriad.social%2Fwebsocket%2F#/explorer
Bad News: Block Production Has Not Started (>12 hours)
Command used to sync:
 /home/ubuntu/myriad-node-parachain/target/release/myriad --collator --chain /home/ubuntu/myriad-node-parachain/raw-parachain-chainspec.json --base-path /var/lib/myriad/ --port 50333 --rpc-port 9944 --unsafe-rpc-external   --rpc-cors all -- --execution wasm --chain rococo --port 50343 --rpc-port 9988

Results:

Based on our StackExchange searching, we found that this might be a common problem:
https://substrate.stackexchange.com/questions/4301/collator-nodes-are-not-working/4302#comment9580_4302

Help Needed

We would like to reconfirm if this is a normal / common problem, or if we missed anything in our deployment. Our WASM build and chainspec can be found here: https://github.com/myriadsocial/myriad-node-parachain/tree/main/node/res
We would like to note that the production of blocks is our only dependency in finishing Milestone 1 (we can't do the data migration without this last step) and we would only be able to submit our final delivery document when that is completed. (refer to #https://github.com/w3f/Grant-Milestone-Delivery/pull/1019 )

Updating the prior comment  #(https://github.com/w3f/Grants-Program/pull/1795#issuecomment-1744142204)
--> we have finished the Sync (after 5 days of syncing!) but the blocks are not being produced still.
We did go through the documents including https://substrate.stackexchange.com/questions/1394/our-parachain-doesnt-produce-blocks-checklist -- this has alerted us that the problem might be due to our current deployment only having one collator node.
so we updated the chainspec and we are currently deploying two collator nodes: https://github.com/myriadsocial/myriad-node-parachain/tree/main/node/res
As per informed by Santi Balaguer (onboarding team), we are just setting up a new head and wasm (without re-onboarding) as the Parachain is already unlocked, and then deploying the two collator nodes above.

Thanks for the update, @gilangbh. I hope everything works out this time!

Hi everyone,
just wanted to give you an update on the progress on grant delivery. I'm glad to say that we have actually finished all items under Milestone 1 and Milestone 2, except for items related to the block production issue. Here's our internal Trello as an overview of finished tasks, with red and blue tasks being M1 & M2, and pink tasks being Milestone 3:

In the last few weeks we've been in contact with Santi Balaguer from the SquareOne team trying to get our chain to start producing blocks. Here's a chronology of events:

Week 2 Oct: after the last update here -- https://github.com/w3f/Grants-Program/pull/1795#issuecomment-1752580885 -- we discovered that the blocks are still not being produced, with both peers online and syncing.

Week 3 Oct: Santi highlighted to us that we do need to be a parachain to produce blocks, not a parathread. Additionally there was an issue with Rococo that required a fix -- which meant we needed to update from our v1.0.0 to v1.2.0. (This fix existed but needed to be deployed so before then v1.0.0 is nonworking: https://github.com/paritytech/polkadot-sdk/pull/1920 )

Week 4 Oct: We have redeployed the chain in v1.2.0 and submitted PR to request for short-term parachain slot, and finally onboarded: https://github.com/paritytech/subport/issues/604#issuecomment-1779453938 ~ we then bought coretime based on onDemandBaseFee: 10,000,000 which equates to 0.0001 ROC. Unfortunately our chain is still failing to produce blocks. Here are the logs from back then:

Week 1 Nov: We retried with 1_000_000_000 instead of 10_000_000. Santi confirmed that we have onboarded but still not producing blocks. Santi requested us to try running the collators locally and we complied. (We have previously tested locally but not with the newest version.)

Present: Local chain is producing blocks in the local relaychain:

Collator RPC: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fws-rpc-1.parachain.myriad.social%2Fwebsocket%2F#/explorer
Relay Chain RPC: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fws-rpc-2.rococo.myriad.social%2Fwebsocket%2F#/explorer
Transactions also work:

We are attaching the logs here for your convenience:
myriad-local-parachain.logs (2).txt
myriad-local-validator-alice.logs (2).txt
myriad-local-validator-bob.logs (2).txt
We would love to hear your thoughts on how to fix this issue so our Myriad.Social project can immediately deliver Milestone 1 and Milestone 2 to W3F and add value to the ecosystem.

This is impressive 👏

Collator RPC: polkadot.js.org/apps/?rpc=wss%3A%2F%2Fws-rpc-1.parachain.myriad.social%2Fwebsocket%2F#/explorer
Relay Chain RPC: polkadot.js.org/apps/?rpc=wss%3A%2F%2Fws-rpc-2.rococo.myriad.social%2Fwebsocket%2F#/explorer

It seems these are currently down, @Decentricity?

Hi @gilangbh how is milestone 3 coming along?

Hi @agustinustheo, have you checked the "Technical" links in the wiki? There are some chatrooms for Substrate/Polkadot SDK, though the best place to ask questions mights still be the StackExchange.
I will reach out to some people to see if there is someone who could look into the Rococo issue.

Hi @agustinustheo, have you checked the "Technical" links in the wiki? There are some chatrooms for Substrate/Polkadot SDK, though the best place to ask questions mights still be the StackExchange.
I will reach out to some people to see if there is someone who could look into the Rococo issue.

Hi @keeganquigley @semuelle,
Just an update, we just finished moving our servers off Google Cloud and into our own self-hosted onpremise servers.
I have made an ParaId within the new Paseo Testnet and I'm looking into the docs to try to manage deploying a runtime there.
@gilangbh has also invited me into the group chat in Element.

Thanks for the update, @agustinustheo. I also spoke with @SBalaguer yesterday, who promised to reach out again in case you still need help.

Hi @agustinustheo just checking in since its been a month or so now :)

Hi @agustinustheo just checking in since its been a month or so now :)

Thanks for checking in we are trying still with Paseo, we already have PAS tokens but because they don't have a guide it is taking longer than expected.

Hi @agustinustheo any updates?

Hi @agustinustheo any updates?

Theo is still struggling with Paseo deployment, can we ask for some technical guidance, maybe on Element chat?

FYI, @gilangbh @keeganquigley
I got in contact with Hector from Paseo.
He gave me a link to the following support docs: https://github.com/paseo-network/support/blob/main/docs/rococo_migration.md
They just released this a month ago, on the 4th of June.
I will talk with him and try to finish this ASAP!

Hi @keeganquigley, we finally figured out how to deploy on Paseo, and Myriad Social is now a Paseo Network Parachain!
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fws-rpc.paseo.myriad.social#/explorer
We're ParaID 4005.

Awesome, congrats @gilangbh glad to hear it! As a reminder, when the delivery is ready it can be submitted here: https://github.com/w3f/Grant-Milestone-Delivery/pulls

Hi @gilangbh just a reminder that if you want to get paid out for the delivery you will need to submit the delivery at the above repo. Thanks!

pinging @gilangbh, @Decentricity & @agustinustheo

Hi @semuelle and @keeganquigley
Apologies for not responding, the team has been busy with projects other than Myriad Social at the moment.
We currently have finished most of the deliverables for Milestone 3 and we're going to submit an update to you guys soon.
Right now we're having an issue because our Paseo Parachain stopped running on our servers. We resolved it on our end and now we're going to work with the Paseo Network team in order to finish the grant program!
https://github.com/paseo-network/support/issues/74#issuecomment-2365843087

Thanks for the update, @agustinustheo. Looking forward to it.

Thanks for the update, @agustinustheo. Looking forward to it.

Our Paseo Parachain is running.
I'm working on the documentation now, @gilangbh should be able to submit the recent Milestone either tomorrow or Friday.

Thanks for the updates @agustinustheo still planning to submit this soon? :)

pinging @gilangbh

Hi @gilangbh reaching out again. Please note if we don't receive a delivery in the next few weeks we will terminate the grant due to inactivity. Thanks!

Hi Keegan. Thank you for the notice. We're wrapping up the documentations and will finish as soon as possible!
https://aka.ms/AAb9ysg

From: Keegan | W3F @.>
Sent: Saturday, November 2, 2024 2:02:49 AM
To: w3f/Grants-Program @.>
Cc: Gilang Bhagasakara @.>; Mention @.>
Subject: Re: [w3f/Grants-Program] Myriad Social Submission (PR #1795)
Hi @gilangbhhttps://github.com/gilangbh reaching out again. Please note if we don't receive a delivery in the next few weeks we will terminate the grant due to inactivity. Thanks!
—
Reply to this email directly, view it on GitHubhttps://github.com/w3f/Grants-Program/pull/1795#issuecomment-2452431579, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AFAYCICC4PJ5WLGLWJZF6I3Z6PF5TAVCNFSM6AAAAAAZATQCJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJSGQZTCNJXHE.
You are receiving this because you were mentioned.Message ID: @.***>

Hi @gilangbh @keeganquigley
We have finished Milestone 3 and have the documentation ready. @gilangbh will submit the deliverables officially soon but the documents can be seen here:

Documentation Milestone 3: https://github.com/myriadsocial/myriad-web/blob/main/docs/milestone-3-documentation.md
Testing Guide Milestone 3: https://github.com/myriadsocial/myriad-web/blob/main/docs/milestone-3-testing-guide.md
Dockerfile Milestone 3: https://github.com/myriadsocial/myriad-infrastructure/blob/main/linux/Dockerfile

Have a good weekend!


j.tools.tfgrid_simulator object raise error

j.tools.tfgrid_simulator
Traceback (most recent call last):
  File "/sandbox/lib/jumpscale/Jumpscale/core/BASECLASSES/TestTools.py", line 130, in _discover_group
    attr = getattr(group, factory)
  File "/sandbox/lib/jumpscale/jumpscale_generated.py", line 1074, in tfgrid_simulator
    from JumpscaleLibsExtra.tools.threefold_simulation.TFGridSimulatorFactory import TFGridSimulatorFactory
  File "/sandbox/lib/jumpscale/JumpscaleLibsExtra/tools/threefold_simulation/TFGridSimulatorFactory.py", line 3, in <module>
    from .TFGridSimulator import TFGridSimulator
  File "/sandbox/lib/jumpscale/JumpscaleLibsExtra/tools/threefold_simulation/TFGridSimulator.py", line 6, in <module>
    from .TokenCreator import TokenCreator
ImportError: cannot import name 'TokenCreator'

can't reproduce anymore on current image
on fresh installation:


feat(icons): added key-refresh icon

closes #2542
What is the purpose of this pull request?

[x] New Icon

Description
Added new key-refresh icon.
Icon use case

password or key refresh/reset
Alternative icon designs

Icon Design Checklist
Concept

[x] I have provided valid use cases for each icon.
[x] I have not added any a brand or logo icon.
[x] I have not used any hate symbols.
[x] I have not included any religious or political imagery.

Author, credits & license

[ ] The icons are solely my own creation.
[x] The icons were originally created in #2542 by @karsa-mistmere
[ ] I've based them on the following Lucide icons: ``
[ ] I've based them on the following design:

Naming

[x] I've read and followed the naming conventions
[x] I've named icons by what they are rather than their use case.
[x] I've provided meta JSON files in icons/[iconName].json.

Design

[ ] I've read and followed the icon design guidelines
[ ] I've made sure that the icons look sharp on low DPI displays.
[ ] I've made sure that the icons look consistent with the icon set in size, optical volume and density.
[ ] I've made sure that the icons are visually centered.
[ ] I've correctly optimized all icons to three points of precision.

Before Submitting

[x] I've read the Contribution Guidelines.
[x ] I've checked if there was an existing PR that solves the same issue.

Should be refresh-key and there is another guideline violation at the tip of the key, the gap is 1px but needs to be at least 2px.


Server Crash

When making a server for my pack this mod errors, causing the server to shutdown.
Here is the crash report:
http://pastebin.com/sS4XU3JJ
Although might be something im doing wrong.

Very strange bug - I'm not having issues, but I found what's crashing you. I'll get an update out as soon as possible to fix it :)

thank you :)

Fixed in 1.6c


False positive in field merging validation

Spotted while running comparative testing with graphql-js validation in the Apollo Router. apollo-rs produces a validation error claiming two different types are selected to the same field name, but graphql-js does not.
I think this may be a regression in the validation port to 1.0 as we started getting rare false positives since then.
Minimal repro TBD

I guess PR titles don't close issues 🤪


Sliding Tab Below Navigation Title

How can we put the tab below the Top navigation bar if using storyboards

SGTabbedPager is just a UIViewController. Putting it inside of a UINavigationViewController would put it below the NavigationBar.