Breaking changes in moment.d.ts type definition

Updating the typings from 1.8 to 2.0 syntax ended up breaking my TypeScript 1.8 project.
I've reverted to 2.16.0 for now, but 2.17.0 will break any TypeScript < 2 projects.

Cna you provide more info please.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(251,28): error TS1110: Type expected.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(256,24): error TS1110: Type expected.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(392,98): error TS1110: Type expected.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(393,88): error TS1110: Type expected.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(635,80): error TS1110: Type expected.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(687,84): error TS1110: Type expected.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(688,84): error TS1110: Type expected.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(251,28): error TS2300: Duplicate identifier 'null'.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(256,24): error TS2300: Duplicate identifier 'null'.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(71,36): error TS2304: Cannot find name 'undefined'.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(251,28): error TS7008: Member 'null' implicitly has an 'any' type.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(256,24): error TS7008: Member 'null' implicitly has an 'any' type.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(392,98): error TS2362: The left-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(392,105): error TS2363: The right-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(393,88): error TS2362: The left-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(393,95): error TS2363: The right-hand side of an arithmetic operation must be of type 'any', 'number' or an enum type.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(635,45): error TS2371: A parameter initializer is only allowed in a function or constructor implementation.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(687,50): error TS2371: A parameter initializer is only allowed in a function or constructor implementation.

ERROR in /builds/*****/node_modules/moment/moment.d.ts
(688,50): error TS2371: A parameter initializer is only allowed in a function or constructor implementation.

Same here

@blakeembrey so they need to update?

@ichernev I had noted in https://github.com/moment/moment/pull/3591#issuecomment-260131758 that using undefined was a breaking change for consumers, but perhaps it wasn't clear enough. It's a bit of a bummer because of the incompatibilities between versions makes it hard to update without affecting people.
@nebez @moreginger @diegocasmo What is preventing you from updating to 2.0?

This one bit me because moment is a dependency of angular2-moment and was automatically updated for all our builds. This issue have been prevented if it was released as a 3.0 version instead of 2.17?
When this issue first came to light yesterday I considered upgrading to typescript  2.0 but there were too many errors for us to resolve with our time constraints. I had to force our project to use 2.16.

@blakeembrey well, why did we change it in the first place? Why not just keep the pre 2.0 stuff and keep going a few more months before moment 3.0?

@blakeembrey yes, we will upgrade to typescript 2, but it's going to take a bit of effort.
For now we've pinned<EMAIL_ADDRESS>

@ichernev It was changed in the PR I linked to. You're welcome to revert it, but it wasn't usable by people on 2.0 with strictNullChecks enabled. It's definitely nice to have strictNullChecks support, but for 1.8 compatibility you could revert all the undefined and null types. In the index signature position, you can use Type | void (using void instead of undefined) to achieve compatibility with both (it's a little hacky, but should work until you do 2.0 support).
FWIW, do you have a list of the errors when upgrading? It should be pretty straightforward, as far as I can recall it's only type system improvements in 2.0 and no major breaking changes. You don't have to share here as it'd clutter up the issue, but I'm happy to help if you need it.

@blakeembrey so replace all the null/undefined in the current code with void, to make everyone happy? I actually added it to a few other necessary places. Then in moment 3.0 put back null/undefined.
By errors when upgrading -- I think only the funky one with the []. But to be proper 2.0 strict as we discussed it needs a few more null/undefined added (which I did here: https://github.com/moment/moment/commit/2cfb22b779ed5c35dc590994715d73b6f650b74d)

Yep, sounds good. void acts roughly like undefined where we'd need it for 1.8 and 2.0 compatibility. The index signature (I think the one you point to as []) introduced in https://github.com/moment/moment/commit/d7390272ed18b62fec358ca98d3d9fa0ce8c5c05 can also go to void, the tests should catch if it's an issue in 2.0  but it should work fine.

But it doesn't like the nulls
Running "exec:typescript-test" (exec) task
typing-tests/moment-tests.ts(25,8): error TS2345: Argument of type 'null' is not assignable to parameter of type 'MomentInput'.
typing-tests/moment-tests.ts(228,17): error TS2345: Argument of type 'null' is not assignable to parameter of type 'DurationInputArg1'.
typing-tests/moment-tests.ts(262,27): error TS2345: Argument of type 'null' is not assignable to parameter of type 'void | LocaleSpecification'.
typing-tests/moment-tests.ts(263,27): error TS2345: Argument of type 'null' is not assignable to parameter of type 'void | LocaleSpecification'.
typing-tests/moment-tests.ts(264,21): error TS2345: Argument of type 'null' is not assignable to parameter of type 'void | LocaleSpecification'.

I guess I can turn off strictNullChecks but that defeats the purpose ... maybe.

@ichernev Correct, you'd have to ignore testing null for now. People using strictNullChecks won't be able to pass null, but it's probably not a huge drawback for them. If undefined is accepted, you can use void as a placeholder for now.

@blakeembrey ok, here's a crazy idea -- why don't you release a patch 1.x version that supports both null and undefined, to be just allowed keywords but not really have any meaning. In 1.x you can't have strict null checks anyway so the data is worthless, but it will make the 1.x and 2.x formats compatible with each other. Then we can tell all complaining 1.x people to update to latest 1.x (which I hope is safe and easy, not like updating to 2.x).

@ichernev I would love that, but unfortunately I am not a collaborator on TypeScript, just a contributor trying to help out like here. I would love the same thing, but note there are more types than just null and undefined. There are number and boolean literals as well. However, there was an issue to support something like this but I can't find it now. /cc @mhegazy @DanielRosenwasser.

How could we move forward with this?

@marwahaha Release the TypeScript 2.x definitions with moment 3.0, or adopt a versioning scheme that is compatible with TypeScript users and give those users notice (e.g. mention that minors may introduce breaking TypeScript changes in the README). I believe the authors just need to decide whether the module will be 100% true to semver, or make some allowances to ensure that in the future the definition can be improved more freely.

The null issue is causing a problem for my project (using TS 2.4.*).  https://github.com/moment/moment/issues/4073

@nebez Installing moment 2.16.0 not working
bower install moment#2.16.0 --save

### Fast Compile >>client/typings/tsd.d.ts
Using tsc v1.7.5
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(5,26): error TS1110: Type expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(6,22): error TS1110: Type expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(7,28): error TS1110: Type expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(282,7): error TS1110: Type expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(290,5): error TS1128: Declaration or statement expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(292,21): error TS1110: Type expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(293,21): error TS1110: Type expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(294,18): error TS1110: Type expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(306,7): error TS1110: Type expected.
/home/vagrant/Fundebug/funweb/client/bower_components/moment/moment.d.ts(562,100): error TS1005: '=' expected.

>> 10 syntax errors
>> Error: tsc return code: 2
Warning: Task "ts:client" failed. Use --force to continue.

Aborted due to warnings.


Consider using NuGet's new buildTransitive folder

See Allow package authors to define build assets transitive behavior.
This could help the situation where you have ProjectA -> ProjectB -> SQLitePCL.raw and e_sqlite3.dll isn't copied to the output directory of ProjectA.

Wahoo! I'm removing PrivateAssets="none" from Microsoft.Data.Sqlite in https://github.com/dotnet/efcore/pull/27191 which was in place to help mitigate this. (It propagated SQLitePCLRaw's build assets one more level into the user's project.)


Toyota: always log cruise standstill

AFAIK cruiseState.standstill isn't used anywhere in Toyota-specific code, so this makes no sense to not log under certain conditions -- these "NO_STOP_TIMER" cars definitely can be put into standstill if engaged at a stop
Only thing that changes is the long controller doesn't try to apply accel when at a stop in standstill to no effect (undefined situation from the car's perspective, but it happens to handle this)

does this make sense for tssp interceptor cars?
I seem to have stopped resuming from red lights yesterday, and haven't had time to see if my pedal has broken.
a152dad3c3368320|2022-11-23--22-44-01--4 stopped after going ~30mph, and before going ~45mph. (~250 sec into route?)
pressed gas because car didn't want to seem to go.
I'll look into it more later but couldn't see how my car would exit standstill, when reading through longcontrol.py

https://github.com/commaai/openpilot/pull/26597


fix: Add missing APIs

This PR adds missing API's in 5-app-infra and 5-vpc-sc  steps.

Some observations:
I noticed there is redudant information on 5-app-infra/5-vpc-sc/README.md and 5-app-infra/README.md. I think it's better if we choose one of them to be the source of truth and remove the other one.
Objective is to make the step-by-step less confusing. If you want, you can include this on the scope of this PR.
LGTM


add_member after install with ALLOW_REGISTRATION=TRUE

After a new Ubuntu server install:
While ALLOW_REGISTRATION = True
When trying to add a member to a project...
Apparently SMTP is not configured correctly - need to document where and how to set it correctly.

Request Method:
POST

http://editor4.vmath.club/project/2/settings/add_member

2.2.10

ConnectionRefusedError

[Errno 111] Connection refused

/usr/lib/python3.6/socket.py in create_connection, line 713

/opt/python/numbas-editor/bin/python

3.6.9

['/usr/lib/python36.zip',  '/usr/lib/python3.6',  '/usr/lib/python3.6/lib-dynload',  '/opt/python/numbas-editor/lib/python3.6/site-packages',  '/srv/www/numbas_editor',  '/srv/numbas/compiler/bin']

Sun, 26 Apr 2020 07:44:43 +0100

I was able to resolve this by adding to settings an SMTP server settings user, pass, tls host etc.


Two problems in Array.prototype.sort

JerryScript revision
2.4.0
Build platform
ubuntu20.04
Description
I executed the following test cases and found the resuts of jerry were different from other js engines.
The first test case should return an array sorted from smallest to largest, but jerry didn't sort the array.
The second test case takes an empty function as the parameter of sort(), and it should return the original array, while jerry returns a reversed array.
Looking foward to your reply.
Test case1
function foo1() {
  foo2.prototype = arguments;
  new foo2();
}

function foo2() {
  var x = Array.prototype.sort.call(this);
  for (var i = 0; i < x.length; i++) {
    print(x[i]);
  }
}
foo1(3,2,4,1);

Output
3
2
4
1
Expected behavior
1
2
3
4
Test case2
var a = [3, 2, 4, 1].sort(() => {});
for (var i = 0; i < a.length; i++) {
  print(a[i]);
}

Output
1
4
2
3
Expected bahavior
3
2
4
1

Related to #5025


Get rid of assets/config.properties file

We were using config.properties file with ant tool earlier.
Now we don't need it. We can pick versionName from AndroidManifest and ENVIRONMENT_DISPLAY_NAME from the configuration to show in the app navigation drawer.
cc @aleffert @nasthagiri @shahidtamboli

:+1:


test: add pause api tests

Signed-off-by: letty<EMAIL_ADDRESS>
1.Describe what this PR did
2.Does this pull request fix one issue?

3.Describe how you did it
4.Describe how to verify it
5.Special notes for reviews

LGTM


As Christa, I'd like to see the % of plans that had 2 or more reviews for the same trade so that we can investigate inefficiencies

@mathias-gibson - if we were to go forward with this,

[ ] What dataset would we use? Plans review? Permits?
[ ] What specifically would we need to check for to verify there are two or more reviews for the same trade?

If we don't have a clear way on how to solve this, this is something we must push back unfortunately.

id like to track this on the metrics dashboard doc, gonna talk to donna about this one on monday, but might not be something we can access


Measure tool

Summary of the Pull Request
Bounds tool and measure tool is implemented. Fixes still needed:

[x] Change the horizontal+vertical icon to be more in line with the other icons. Example:

[x] Make having feet in the ticker an option. (Not working on continuous mode, though).
[x] Multimonitor is not working.
[x] Interaction seems to reversed for select vs scan mode. (left-click vs right-click to copy)
[x] Changing tolerance in Settings seems to do nothing.
[x] Add an ability to quickly change sensitivity while scanning with a mouse wheel
[x] Verify on VM: initializing overlay UI shouldn't fail in GetClientRect with "Invalid window handle".
[x] After finishing using a scan option, the toggle shouldn't keep being on.
[x] Verify if the measurements are OK.
[x] Pressing the activation shortcut again should close the measure tool UI.
[X] Measure tool OOBE screen is not correctly wired up yet.
[x] Disable measurement whenever the cursor is within the overlay toolbar? Therefore, controls can still be selected by mouse without using the ESC key first. This is also important for a11y I can imagine.
[x] Measure tool UI doesn't exit when stopping runner in the Visual Studio debugger.
[x] OOBE and Settings imagery (cc @niels9001) (src/settings-ui/Settings.UI/Assets/Modules/OOBE/ScreenRuler.png, src/settings-ui/Settings.UI/Assets/Modules/ScreenRuler.png)
[x] Add a shadow to the tooltip (optional)
[x] In settings say it's inspired by Roolr.
[x] Telemetry.

PR Checklist

[x] Closes: #863
[ ] Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
[ ] Tests: Added/updated and all pass
[ ] Localization: All end user facing strings can be localized
[ ] Dev docs: Added/updated
[ ] New binaries: Added on the required places

[ ] JSON for signing for new binaries
[ ] WXS for installer for new binaries and localization folder
[ ] YML for CI pipeline for new test projects
[ ] YML for signed pipeline

[ ] Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

@jaimecbernardo @yuyoyuppe
Love this tool already😊!
One quirk: should we disable measurement whenever the cursor is within the overlay toolbar? Therefore, controls can still be selected by mouse without using the ESC key first. This is also important for a11y I can imagine.

Thanks for the feedback @niels9001 , I've added it to the checklist in the PRs description so we can keep track of the changes still needed.

Make having feet in the ticker an option. (Not working on continuous mode, though).

Does this mean the distance is shown in feed unity? Then we should add pixel, centimeter, millimeter and maybe zoll as option too.
We should have an info bar on the settings page about all these restrictions in continues mode.

I saw the gifs in the description now. And I love yet until try it by myself.
As I wrote somewhere it would be nice to have the ability of choosing the unit (mm, cm, px, zoll) and it would be great to have the unit abbreviation in the tooltip.
Regarding the toolbar I suggest to change the cross capture icon in the toolbar to a cross to make it more clear. Maybe a cross with arrows on all ends (up, down, left, right).

@htcfreek Icons have been updated in the latest commit:

I would like to see two additional things:

Ability to move the toolbar
Ability that it ignores text while measuring elements of apps

Ability that it ignores text while measuring elements of apps

great idea. could be a setting

placeholder assets are:
src/settings-ui/Settings.UI/Assets/Modules/OOBE/ScreenRuler.png
src/settings-ui/Settings.UI/Assets/Modules/ScreenRuler.png

@yuyoyuppe
I want to try the new tool. But as far as I press one of the buttons in the toolbar the program crashes:

Additionally I want to suggest two features:

Showing an indicator about which number is X (left/right) and which is Y (up/down) when measuring in rectangle mode and cross mode.
Maybe a featur to measure at one side to the nearest monitor border. (Example: You have a background that is very detailed and you want to measure the space between window and left monitor border. Then you press a key and the tool ignores the background image and enlarges the measurement until the left monitor border.) - Not sure if this is a real scenario as I can't try the tool currently.

What is left so we can get this in for this iteration?

@htcfreek Something has happened during initialization of the native DLL/overlay UI. I've noticed that you're compiling it in Debug mode (need to try it for once 🙂) and also using an RDP session, right? That might also affect it. You could attach (CTLRL+ALT+P) to PowerToys.MeasureToolUI.exe but manually selecting "Native" for debug session type, then you could see a proper call stack.

Showing an indicator about which number is X (left/right) and which is Y (up/down) when measuring in rectangle mode and cross mode.

I like it, but since we're going to allow different display units of measure soon, it could look a bit cluttered, i.e. "W:10px H: 20px". 🤔

Maybe a featur to measure at one side to the nearest monitor border. (Example: You have a background that is very detailed and you want to measure the space between window and left monitor border. Then you press a key and the tool ignores the background image and enlarges the measurement until the left monitor border.) - Not sure if this is a real scenario as I can't try the tool currently

I think we could investigate changing desktop background to solid color during measurement.

@crutkas

improve stability
wheel for tolerance adjustment (no slider for now, since WinUI doesn't support it I guess)
module/OOBE description images
telemetry

@htcfreek Something has happened during initialization of the native DLL/overlay UI. I've noticed that you're compiling it in Debug mode (need to try it for once 🙂) and also using an RDP session, right? That might also affect it. You could attach (CTLRL+ALT+P) to PowerToys.MeasureToolUI.exe but manually selecting "Native" for debug session type, then you could see a proper call stack.

It's a Hyper-V-VM in extended (rdp) display mode. The rdp thing is something I can test tomorrow by using normal (non rdp) mode.
Can you please give me a hint how and where to select this "native" mode?

Showing an indicator about which number is X (left/right) and which is Y (up/down) when measuring in rectangle mode and cross mode.

I like it, but since we're going to allow different display units of measure soon, it could look a bit cluttered, i.e. "W:10px H: 20px". 🤔

Can we have a line break like this:
Width: 10px
Hight: 20px

Then it looks cleaner.

Maybe a featur to measure at one side to the nearest monitor border. (Example: You have a background that is very detailed and you want to measure the space between window and left monitor border. Then you press a key and the tool ignores the background image and enlarges the measurement until the left monitor border.) - Not sure if this is a real scenario as I can't try the tool currently

I think we could investigate changing desktop background to solid color during measurement.

Let's talk about later in a different step an create an issue for discussion.

@htcfreek

start PowerToys normally (not from VS)
win+shift+m to launch the tool
ctrl+alt+p to invoke attach dialog
select PowerToys.MeasureToolUI.exe
press "Select..." -> "Debug these code types:" -> Native
press Attach
click on some tool icon on the toolbar

@yuyoyuppe
Crash is fixed.

@yuyoyuppe
Did you implement line break and direction information in the tool tip?

@htcfreek could you please create an issue for it? It could be a part of a bigger task, i.e. supporting different units of measure. And for now let's stick with the same thing Roolr does.

@yuyoyuppe
I created the two issue for my open requests.

The words "Pixel tolerance" are not very clear at first. What is actually used here? Maybe "contrast threshold"?

The words "Pixel tolerance" are not very clear at first. What is actually used here? Maybe "contrast threshold"?

Fwiw - PixelSnap uses "Tolerance mode" -> Low/Normal/High.

Added a feature to allow saving bounds measurements by shift-dragging. Right-click clears them.

Added a feature to allow saving bounds measurements by shift-dragging. Right-click clears them.

What means saving? I can imagine that users will ask for key/shortcut customization.

it's for retaining them on screen. let's see what feedback do we get first :)

it's for retaining them on screen. let's see what feedback do we get first :)

I don't understand the use case. For what do I need this?

Don't forget to add this to the issue templates.

Are left and right mouse buttons literal or is it primary and secondary?

@Jay-o-Way what do you mean? we handle WM_LBUTTONDOWN and WM_RBUTTONDOWN window messages.

@Jay-o-Way if I enable this setting:

the controls are swapped, so those messages signify logical buttons after all :)

@Jay-o-Way if I enable this setting:
the controls are swapped, so those messages signify logical buttons after all :)

That's good. 👍🏻 Looks like the names Lbutton and Rbutton are old. (Primary/Secondary would be better)

Wasn't sure if this is already implemented: but should we have Narrator announce something when a measurement is made?

It's not implemented yet, since we're using Direct2D to display the measurement box. I've created a task for it.

Don't forget the github label.

I think the default sensitivity needs to be increased and would really like a visual for what that is.
Past that feels good

For possible “future improvements”

toolbar visual for sensitivity
Toolbar shows continual vs static state
Shift icons back to duals. Showed a demo and someone thought the plus and minus zoomed.

Tested with switching desktops, it looks like ruler still measures the previous one after the switch. Is that known?
https://user-images.githubusercontent.com/8949536/186504879-185eb55d-ac0b-42a7-9d3c-8816c945cf60.mp4

@SeraphimaZykova Looks like "Capture screen continuously during measuring" setting is disabled for. In that state we assume that things are static, so we do a single screenshot which is then later measured. If you enable the setting, it works as you expect.
Come to think of it, perhaps we should enable it by default.

Looks like "Capture screen continuously during measuring" setting is disabled for you. In that state we assume that things are static, so we do a single screenshot which is then later measured. If you enable the setting, it works as you expect.

Yes, it was disabled. In this case label "For measuring animated graphics" may be a bit confusing. After you explained I got the idea, but it didn't come to my mind at first since I had static pictures on different desktops.

Also, an edge case: with a tolerance of 255 it shows the screen width larger than the actual one. Height is always correct.

In this case label "For measuring animated graphics" may be a bit confusing.
Agreed, let's change it.

Also, an edge case: with a tolerance of 255 it shows the screen width larger than the actual one. Height is always correct.

What are your screen params and what does it show instead? I cannot repro it on my<EMAIL_ADDRESS>

Screen is 3000x2000 with 200% scaling. I got 3008 width.
https://user-images.githubusercontent.com/8949536/186517579-1eac09e6-bf42-408b-a517-9b25dadcc7bb.mp4

@SeraphimaZykova interesting, does it also happen with 254?

@SeraphimaZykova I've updated the setting's description and tried to fix your issue, please try again.

Let's do a final round of testing.
@crutkas feedback has been addressed:

default pixel tolerance increased
in a non-continuous mode, we draw captured screen, so we always see what we're measuring
tolerance slider will be done as a future improvement once we figure out WinUI issues

Sent via email screenshots, i think for the horizontal bar is off by one.  It is 1 px too high.  I'm at 100% scale.  Using it to measure the minimize button / maximize button as hit points, you can see it stops 1 px above minimize

@niels9001 are you ok with merging this? :) I believe AutomationPeer changes are now addressed.

when appropriate, (hoping today 😊), we can get this in so.  I want to kick off a signed test build with all the new stuff and just be hyper critical of all the new stuff and what could be adjusted / should be adjusted before we release.

when appropriate, (hoping today 😊), we can get this in so. I want to kick off a signed test build with all the new stuff and just be hyper critical of all the new stuff and what could be adjusted / should be adjusted before we release.

Figuring out those last build CI errors and we'll be merging it afterwards 😉


Some libraries like  hyperHeap.fst  and  map.fst  cannot be extracted together with their .fsti.

Some libraries like hyperHeap.fst and map.fst cannot be extracted together with their .fsi.
As a side remark, we should rename .fsi to .fsti.
We get the following error
now synthesizing expression :  (includes i j)

Unexpected error; please file a bug report, ideally with a minimized version of the source program that triggered the error.
(hyperHeap.fsi(43,24-43,32)) free Variable includes not found

when running
fstar.exe ext.fst classical.fst set.fsi set.fst heap.fst map.fsi listTot.fst hyperHeap.fsi --admit_fsi FStar.Map --admit_fsi FStar.Heap  --codegen OCaml --lax --debug Extreme --trace_error

@markulf can you kindly help test this with Universes (it is the default now)

FSIs dont exist anymore. So closing the issue.

.fsi files should now have extension .fsti. We do have .fsti files for some libraries, so this may as well still be a bug.

Nikhil, comments ?
From: Santiago Zanella-Beguelin<EMAIL_ADDRESS>Sent: Friday, July 15, 2016 12:27 PM
To: FStarLang/FStar<EMAIL_ADDRESS>Cc: Sreekanth Kannepalli<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Subject: Re: [FStarLang/FStar] Some libraries like hyperHeap.fst and map.fst cannot be extracted together with their .fsti. (#384)
.fsi files should now have extension .fsti. We do have .fsti files for some libraries, so this may as well still be a bug.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://github.com/FStarLang/FStar/issues/384#issuecomment-233048642, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ASzQ2L4-JybVU4tYqzfogBvsXpkueHDhks5qV98ggaJpZM4GDN7H.

but we do extract .fsti+.fst after interleaving them. Do we know of a case where it doesn't work?

I don't know of any case.
The issue was about FStar.HyperHeap, but we no longer have FStar.HyperHeap.fsti. Feel free to close.

@adl ran into a similar problem today (can we have a minimal example, perhaps in a new issue?)


Build options are not provided to hooks from within the start command

I want to copy platform dependent files in the 'beforeBuild' hook during development but build options are not passed along to the hooks when the hooks are called from within the 'start' command.

Merged. Will our in the next release. Appreciate the Pr!


Added option to specify rounding precision

I added the option to keep more than 5 decimal places in the timestamps. The read functions still accept the old calling conventions, and still default to rounding to 5 decimal places.

Thanks for this. A few questions before I merge, though.
It seems the default rounding precision ought to match Praat's precision. Do Praat textgrids use doubles or floats? What is the right precision of rounding to match Praat? MLF files, IIRC, give times in 100 ns frames, but the precision used is much less (the last couple trailing digits is always zero). It would also make sense to match the precision of HTK and/or Praat, whichever is smaller, as the default.
One code-review critique: module-level globals should be in all ALL_CAPS like so (and the comment that it's a module-level global isn't needed), unless we were previously inconsistent about this, in which case I'll just fix it in one fell swoop.

Re: default rounding precision: I chose 5 digits solely because that's what was previously used in the code. Perusing the Praat source reveals doubles throughout for timestamps, so we're likely looking at 15 digits of precision in the mantissa. (And for me, at least, praat produces TextGrids with 15-decimal-place timestamps.) Since the times are being floated before the rounding, though, there is implicit rounding occurring as well (for me, this is to 11 digits). I'm not as familiar with MLF, so I couldn't say how precise it is.
Re: variable names: there didn't appear to be any other module-level variables, so I just figured I'd follow PEP8.
I'm happy to make either/both of these changes (_default_precision to 15, name to _DEFAULT_PRECISION) in a new commit, or you're welcome to amend if you'd prefer.

Let's make 15 the default for both MLF and TextGrid, given that information.
Python floats have a 53-bit mantissa, IIRC, like a C double, but Python displays considerably less. (I'm not sure the exact rules on how it truncates trailing non-zeros for display.)
PEP8 says DEFAULT_PRECISION unless I'm misreading: https://www.python.org/dev/peps/pep-0008/#constants
Could you make these in a new commit? Much easier for me (because Reasons). Thanks for the patch!

Done.
(You're absolutely right about PEP8 - see previous comment re my failure to read properly...)


Parsing Error for scenario outline with commented Examples row.

When I've got scenario with outline, and I comment all of the table rows, parsing error is seen.
@P2T6
Scenario Outline: Test Scenario
Given Project DC <DC_Center> is available
And I am already logged in with multi-Project user
Given I am on "Projects" tab
And I Search Cloned_Project AND Deactivate
Examples:
|DC_Center|
#|UK|
Unable to parse above scenario and got error below.
[ERROR] Failed to execute goal com.github.temyers:cucumber-jvm-parallel-plugin:2.2.0:generateRunners (generateRunners) on project adoddle.p2: Execution generateRunners of goal com.github.temyers:cucumber-jvm-parallel-plugin:2.2.0:generateRunners failed: Parser errors:
[ERROR] (155:1): expected: #TableRow, #Comment, #Empty, got '@P2T6'
[ERROR] (156:1): expected: #TableRow, #Comment, #Empty, got 'Scenario Outline: Test Scenario'
[ERROR] (157:1): expected: #TableRow, #Comment, #Empty, got 'Given Project DC <DC_Center> is available'
[ERROR] (158:1): expected: #TableRow, #Comment, #Empty, got 'And I am already logged in with multi-Project user'
[ERROR] (159:1): expected: #TableRow, #Comment, #Empty, got 'Given I am on "Projects" tab'
[ERROR] (160:1): expected: #TableRow, #Comment, #Empty, got 'I Search Cloned_Project AND Deactivate'
[ERROR] -> [Help 1]

@jasminprajapati Its not this plugin issue. You are not following Gherkin Best practices. Gherkin don't parse silly mistakes.
when you are using Examples at least table header and row is expected. if you want to use NULL instead of UK just leave it as blank |  | .
Examples:
|DC_Center|
|UK|


python311Packages.annexremote: 1.6.0 -> 1.6.4

Diff: https://github.com/Lykos153/AnnexRemote/compare/refs/tags/v1.6.0...v1.6.4
Changelog: https://github.com/Lykos153/AnnexRemote/releases/tag/v1.6.4
Description of changes

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

14 packages built:

datalad
datalad.dist
git-annex-remote-dbx
git-annex-remote-dbx.dist
git-annex-remote-googledrive
git-annex-remote-googledrive.dist
python310Packages.annexremote
python310Packages.annexremote.dist
python310Packages.heudiconv
python310Packages.heudiconv.dist
python311Packages.annexremote
python311Packages.annexremote.dist
python311Packages.heudiconv
python311Packages.heudiconv.dist


Reformat Transform(2D) matrix display in the inspector

Previously the Transform editors in the inspector were very sub-optimal. Columns were displayed horizontally, rows displayed vertically, there was repeated information, and labels were non-unique.
This PR fixes all of these problems. Here are some before and after screenshots, the left side is before, the right side is after.

The items have been transposed to display columns vertically and rows horizontally (as it should be). I decided to use the fourth color as Cyan, which I think looks better. This Cyan color also replaces gray in Quaternion and Plane (but of course we can change this back if desired).
The names are row-column, just like in math, such that "yx" is equivalent to transform.basis.x.y, etc. This is much better than the previous ambiguous, repeated, non-unique "x", "y", and "z". This notation was suggested by tagcup.
Coloring is now done by a helper method in editor/editor_inspector.cpp. I also made everything else use these helper methods, which helps avoid code duplication.

EDIT: Marked as draft because #47635 should be merged before this one (it's a subset).
Implements and closes https://github.com/godotengine/godot-proposals/issues/1820, and fixes #44669.
Previously the Transform editors in the inspector were a bit of a mess. Columns were displayed horizontally, rows displayed vertically, there was repeated information, and labels were non-unique. Also, Node2D is completely missing a section for its matrix, so it's impossible to edit a 2D node's transform matrix directly without using a script.
This PR fixes all of these problems. Here are some before and after screenshots, the left side is before, the right side is after. There are exported values, Node2D, and Node3D. Each side has equivalent values to each other, the Y component of the X column vector (row 2 col 1) is set to 5 for most of the examples, and for Node2D the rotation is set to 5.

The "Matrix" section has been renamed to "Raw Matrix" to better convey that this is how Godot works under-the-hood, and to slightly discourage users who don't know what it is from touching it. Editing the matrix of a transform directly is something users should know how it works before jumping in, or else they will get confused.
The items have been transposed to display columns vertically and rows horizontally (as it should be), except that for Node2D and Node3D, the origin vector is not displayed, instead, only the Basis is displayed. This is because we don't need to duplicate information already present in "Translation". The origin vector is still displayed for exported transforms. I decided to color it Cyan, rather than leave it gray, which I think looks better. This Cyan color also replaces gray in Quat and Plane (but of course we can change this back if desired).
The names are row-column, just like in math, such that "yx" is equivalent to transform.basis.x.y, etc. This is much better than the previous ambiguous, repeated, non-unique "x", "y", and "z".
Previously, the transform matrix was not displayed at all for Node2D. The display now exists, and closely resembles the section for Node3D, it only shows the basis part (excludes the origin vector) because the information exists in "Position".
Coloring is now done by a helper method in editor/editor_inspector.cpp. I also made everything else use these helpers methods, which helps avoid code duplication (and also, while I haven't benchmarked it, I'm fairly confident this will run faster since it's not re-calculating the same colors multiple times anywhere that uses the colors multiple times).

transform.basis.x.y would be yx not xy

Row is the first letter for matrices in standard math notation

@tagcup I think it's more intuitive conceptually to think of a Transform of its set of component vectors (columns) and their components, and that is how programmers would be interacting with transform most of the time, so the xy == x.y makes more sense for Godot. We could also just add a . between the letters to show this if desired.

I disagree. That's against every math or physics book out there so we shouldn't redefine standard linear algebra notations, or introduce new notations (the dotted version which becomes one new nonstandard thing that you need to explain) which flip the standards upside down and would ultimately create confusion only down the road.
I understand the urge stems from identifying the columns of the transform matrix as basis vectors of the frame, but everything actually reads correct if you use the correct, standard notation, and would be wrong, inconsistent and ultimately confusing with that notation.
The reason is when you multiply a matrix with a vector, you sum over the second index not the first one: R_ij v_j The basis vector interpretation is when v is (1, 0, 0), (0, 1, 0) or (0, 0, 1) which gives you (Rxx, Ryx, Rzx) and so on, as it should. If R.(1,0,0) was (Rxx, Rxy, Rxz) it would just be wrong.
It's be to accept as a matrix for what is it: a matrix (or a rank 2 tensor in this case), and avoid such confusing notations that flip the literature upside down.

Should the origin column be changed to xo, yo, and zo in your opinion?
I still think it's best to reflect how the matrix is actually used in Godot, so I'm still in favor of the column-major syntax, but I will add dots (unless we reach a consensus that we should indeed use the row-major syntax). This isn't just any matrix, it's a specific kind of matrix of a fixed size and its components have specific purposes. It would be confusing if you accessed xy with y.x.

There is no column major in maths or physics, that's just a computer language convention in languages which support multi dimensional arrays related memory access speed. A matrix that is printed on the screen must always follow the row major. See the image here:

https://en.m.wikipedia.org/wiki/Row-_and_column-major_order

C++ basis in Godot is actually row major b[row][column]. Transform 2D is column major for whatever reason

Vectors are columns, that's consistent with typical math on paper. That has nothing to do with row or column major

Old OpenGL transposed everything for some obsolete optimization (which caused a lot confusion because you had to transpose everything you feed, they now have a flag for this behavior) so that matrix multiplication with a vector is vi Rij. Godot math library doesn't do that, R.v is Rij vj also consistent with math on paper so it's not relevant either

@tagcup I've added the ability to display matrices with math notation as a 2nd commit:

When enabled, the inspector looks like this:

The "M" could either mean math or matrix, and in any case it's useful to differentiate it in case users are creating screenshots/videos/tutorials and are wondering why the labels look different.
It's disabled by default right now, but it would be trivial to change this if you wish to open a new issue after this pull request is merged (assuming it will be).

the basis vector interpretation is already conveyed through the colors

Yes, but note that this isn't the case in the current master.

The translation vector in the "raw matrix" is redundant, the same vector is displayed twice

Yes, which is why I made Spatial display the Basis instead. However, there is no separate Basis2D type, so we can't do the same for Node2D unless we want to implement Basis2D, but I think that's out of the scope for this pull request. Or maybe there's a workaround I haven't considered.

For the reasons that I explained above multiple times, Basis should never be displayed like that, having such modes is even more confusing. No such notation exists anywhere, and Godot should never have it.  This should never be merged.
Basis is a matrix, not an array of vectors. I know it is tempting to try to interpret it like that but there are very different things. Just accept the notations the mathematicians and physicists and everyone else agreed on and please stop pushing this nonsense any further.
Please don't ping me anymore. I'm 100% against this in any form, optional or not, I gave the reason, and I don't have anything else to add.

Dug into the code a bit further, figured out a way to make Node2D's raw matrix display without the origin. It checks if p_usage is 2 or not, so it may unexpectedly hide Transform2D if p_usage is 2 in other places with Transform2D (I don't think there are any, though?). Also, it still says "Transform".

I don't understand the benefit of this.

@fire Read the OP. In master, these editors are very confusing. Columns are displayed horizontally, rows displayed vertically, there was repeated information, and labels were non-unique. It doesn't make sense to display rows vertically and it doesn't make sense to display columns horizontally.

Can we split the matrix convention change from the current pr?
I can add my approval for the rest of the changes.
However, I'm not sure if transposing the matrix is better. My opinion is that you're changing conventions for people and people need to relearn.
I'm not convinced by the convention change. However that shouldn't block the rest of the changes.

I dont kinda like the idea of changing this as I prefer it the current way, which works better for horizontally compact inspectors.
Also, #44669 is no longer a bug in master.

@reduz There are many problems with the current master, so we should still do something, but we can change this PR. If being horizontally compact is important, we could change it so that the origin vector is at the bottom like it is now, but keep the other changes in this PR including making rows display horizontally as rows and (non-origin) columns display vertically as columns.
(Note that the placement of the origin vector will only affect exported variables, since for the Node2D and Node3D inspectors the origin vector is hidden as it's not needed)

@reduz Is this better? I added this change as a 2nd commit.

I think as far as showing transforms in itself, this is ok and should be able to go through. About the position I believe there is a different PR/Idea for this.

Is there a reason Transform2D's xo and yo labels are blue (like the Z axis) instead of cyan? I'd expect the Transform origin properties to always be cyan, regardless if they're 2D or 3D.

@Calinou Good idea, done, and updated the image.

Thanks!


Fix numpy stacking

When getting items using a column name as a key, numpy arrays were not stacked.
I fixed that and added some tests.
There is another issue that still needs to be fixed though: when getting items using a column name as a key, pytorch tensors are not stacked (it outputs a list of tensors). This PR should help with the to fix this issue.

This PR also fixed a bug where numpy arrays were returned instead of pytorch tensors when getting with a clumn as a key.


Auto-advancement: use media length over default duration

Summary

Relevant Technical Choices

If there is are videos on page, the longest media is taken as the page advancement, even if the longest media is very short
If there is animation, the longest animation takes priority over the media if applicable.
If there is animation shorter than the default duration, default duration is used.

To-do

User-facing changes

Testing Instructions

Add a few pages
Add short video on a page (e.g. 2 seconds)
To another page add a short animation
To another page add a short video and some animations longer than the video
Verify that if there's only a video on page, the page advances right after the video ends, even if very short (previously the default page duration was used instead)
Verify that in case of just a short animation on the page, the default page duration is used for advancing
Verify that if a short video and long animation are on the page, the page advances after the animation.

QA
See steps above.

[ ] This is a non-user-facing change and requires no QA

This PR can be tested by following these steps:

Checklist

[x] This PR addresses an existing issue and I have linked this PR to it in ZenHub
[x] I have tested this code to the best of my abilities
[x] I have verified accessibility to the best of my abilities (docs)
[x] I have verified i18n and l10n (translation, right-to-left layout) to the best of my abilities
[x] This PR contains automated tests (unit, integration, and/or e2e) to verify the code works as intended (docs)
[x] I have added documentation where necessary
[x] I have added a matching Type: XYZ label to the PR

Fixes #7053

Also, maybe we should put more info in the Auto-advance option explaining how it works?

+1 to updating the copy.


Moved to netcore 3.0

Updated the code base to use the MVC and dotnet core 3.0 (LT)

Modified the program and startup to reflect the right libraries and remove deprecated functions.

Isn't .NET Core 3.0 EOL and .NET Core 3.1 is the LTS you are looking for?
Source: https://dotnet.microsoft.com/download/dotnet-core

Isn't .NET Core 3.0 EOL and .NET Core 3.1 is the LTS you are looking for?
Source: https://dotnet.microsoft.com/download/dotnet-core

it is 3.1 what was pulled.


Add WinGet as an installation option

It would be nice if this could be installed via WinGet

Sorry for the late answer. I'll take care of it and report back once it's done.

Hi, I've looked into WinGet a lot since I made this issue and the reason I closed this issue was WinGet currently does not support zip files, only installers:

Note: At this time installers must either be MSIX, MSI or .exe application installers. Standalone or portable executables, compressed .zip files, and fonts are not currently supported.

Therefore, it looks like this project would have to compile a binary that is installable in order to package it on WinGet.

That's right, but we should be able to create a windows installer using Inno Setup and make it part of the CD pipeline.

Coincidentally, I stumbled on microsoft/setup-msbuild after seeing it used in this workflow. Don't know much about making Windows installers, but it might be useful.

I found a rust project that does exactly what we want: it calls a shell script from ci and it uses iscc.exe (Inno Setup) with an iss file to generate the installer.

Onefetch 2.12.0 can now be installed using winget 🎉
I have updated the wiki  with a new entry for winget and #668 should take care of generating a new installer on release.

If it's helpful, I use the Winget Releaser GitHub action in my repositories that runs on release and will automatically create a pull request on WinGet packages.

Indeed, this would be the last task to have a fully automated winget deployment process..

I'm happy to make a PR for this if it would be beneficial.

That would be great @russellbanks 🚀

Onefetch 2.12.0 can now be installed using winget 🎉

Just installed and working great, thank you!

That would be great @russellbanks 🚀

PR incoming!


Image filter methods, size of output

In OpenCV, the output image is the same size as the input image. The indices for x,y in the output image corresponds to the x,y in the input.
But in Pal, the 3x3 methods have output sizes that are two pixels smaller in width and height than the input size. This is more economical on memory but does not have corresponding x,y locations. Is this the preferred method?
The size of the output images should be added to the comments and documentation for these methods.

Some design decision is needed there, I also noticed an inconsistency while making this example : https://github.com/parallella/pal/pull/92
It's not clear what need to be followed, the original filters output a smaller image, but the sobel filter doesn't. Users will expect an output of the same size, but it's not trivial (specially for large radius) :

is the margin set to zero ?
or should we take the nearest value after (or before) filtering ?

In hi-quality filters what is done is :
1 : a temporary image is created at size = input size + radius
the margin value is equal to the nearest pixel
2 : the output is computed using the larger temp input at input size
It make sense on x86, but might be inefficient on simple processor with no cache.

I think that the low-level methods should only focus on the fastest/lightest code, and so output a smaller image.
Example :
A user wants to apply multiple filters to the same input image while keeping the original size, the optimal method in this case would be to create an oversized image (2 pixels larger for 3x3 filters, with nearest value for the margin) and then only apply all the filters. = 1 resize only then multiple raw speed.
Pal can propose additional higher level functions for the filters, that output the expected image size, by internally pre-resizing the input and call the lower level function.

Agree 100%
On Jun 14, 2015 2:50 PM, "Anaël Seghezzi"<EMAIL_ADDRESS>wrote:

I think that the low-level methods should only focus on the
fastest/lightest code, and so output a smaller image.
Example :
A user wants to apply multiple filters to the same input image while
keeping the original size, the optimal method in this case would be to
create an oversized image (2 pixels larger for 3x3 filters, with nearest
value for the margin) and then only apply all the filters. = 1 resize only
then multiple raw speed.
Pal can propose additional higher level functions for the filters, that
output the expected image size, by internally pre-resizing the input and
call the lower level function.
—
Reply to this email directly or view it on GitHub
https://github.com/parallella/pal/issues/106#issuecomment-111863992.

@anael-seghezzi: I think you're wrong. It can't  be faster to create another input buffer (whose size depends on the number of filters to be executed!!!), when most current systems have the memory bus as a bottleneck. A better choice here would be to compute some garbage values for the pixels that are on the border, and offer a post-processing function for those who also need the border to be correct ( and offer a number of possibilities in extending the image by 1 - clone neighbor, fill with value, and such).

I agree with @anael-seghezzi. Filtering done on certain nodes should be as fast as possible. That implies no extraordinary possibilities (border pixels, post-processing, etc.).
@tcptomato In my opinion your way of thinking covers higher level of abstraction - feature level. Here, we're discussing the building blocks of such features. Which are pretty basic in their inner workings.

Thomas,
These kernels will always work on local copies. You never read directly
from dram. The intent here is that each core will work on a sub tile of a
larger image.
On Jun 14, 2015 4:05 PM, "Thomas Böhm"<EMAIL_ADDRESS>wrote:

@anael-seghezzi https://github.com/anael-seghezzi: I think you're
wrong. It can't be faster to create another input buffer (whose size
depends on the number of filters to be executed!!!), when most current
systems have the memory bus as a bottleneck. A better choice here would be
to compute some garbage values for the pixels that are on the border, and
offer a post-processing function for those who also need the border to be
correct ( and offer a number of possibilities in extending the image by 1 -
clone neighbor, fill with value, and such).
—
Reply to this email directly or view it on GitHub
https://github.com/parallella/pal/issues/106#issuecomment-111871082.

Andreas,
I have experience in implementing image processing algorithms on this kind of multicore architecture ( even doing it in assembler), so I know the idea behind it and what I'm talking about.
The currently implemented image processing algorithms treat the output as a vector, and after computing 1 element, they advance by 1 element size in memory. This means that a simple 2 pixel enlargement won't suffice for running multiple filters, since they lack the understanding of the line stride, and will just output a smaller image, contiguously in memory. So either after each filter you resize, or you transfer the image with the padding logic encoded ( the DMA controller will probably love this, I foresee alignment issues here, or byte as transfer size). And additionally, before each DMA transfer you need to zero the buffer in order to have the correct values in the padding pixels.

@tcptomato Can you clarify what the problem is? Can you clarify further what problem you are concerned about? Please keep in mind that these low level functions are not meant to be "perfect functions". Perhaps some of your concerns could be addressed in a higher level function?
Let's take the following use case:
-There is a 128 x 128 pixel image to process in DRAM
-We want to run a sobel filter on this 2D array using 16 cores
-Each core would work on separate 32 x 32 sub tiles of the image
-Each core needs to bring in a 32 x 32 sub tile + a 1 pixel halo around the tile from DRAM and produces a complete 32x32 sub result image.
Please describe your proposal for addressing the above example.

Assumption:
We ignore the border artifacts when cutting the image into tiles.
For your example:
We transfer the 32x32 tile using DMAs and we use it to create the 1 pixel halo at the same time. The first line of the extended image is 34 pixels of border (for simplicity we assume its 0).  On the second, the first pixel is again 0, after which the actual data begins. Meaning that that the 36th pixel needs to be correctly aligned in memory. Worse after the 32 pixels of this line, there will be again 2 halo pixels So the difference between the start address of the 2 lines is 16 ( modulo 64), so any DMA transfer size bigger than half-word will be a misalignment. ( output stride needs to be a multiple of transfer size in all DMA controllers I've seen).  Meaning that transfer speed is a quarter of what is possible.
For the next issue allow me to replace Sobel by the Gaussian blur ( since it's more likely to be ran multiple times on the same image, and has the same halo issue). In order to apply the blur filter 2 times on the image, after the first run the halo needs to be recreated either by transferring the image to DRAM and copying back with the stride ( or does the DMA controller support local to local transfer ? even if it does it's another memory transfer), or the local processor needs to add it.
To recap, biggest bottleneck here is DMA running at 1/4 speed and needing to prepare the buffer for each new run.
How I see it.
The image image is sliced 8 x 128. Which is transferred as a contiguous block of memory by the DMA at full speed. Now we run the filter on the full block, and being implemented as pointer arithmetic on a 1d vector it will generate a value for all output pixels ( the ones on the border will be garbage). It might need an empty line at the top and the bottom of the block to prevent memory access errors. Since the output size is the same as the input, we can use it as the input for a new run of the function without any changes.
Both options discussed here have issues in stitching back the tiles, but we'll discuss them when we get there.

Please explain assumption. How can we ignore border artifacts?
On Mon, Jun 15, 2015 at 1:37 PM, Thomas Böhm<EMAIL_ADDRESS>wrote:

Assumption:
We ignore the border artifacts when cutting the image into tiles.
For your example:
We transfer the 32x32 tile using DMAs and we use it to create the 1 pixel
halo at the same time. The first line of the extended image is 34 pixels of
border (for simplicity we assume its 0). On the second, the first pixel is
again 0, after which the actual data begins. Meaning that that the 36th
pixel needs to be correctly aligned in memory. Worse after the 32 pixels of
this line, there will be again 2 halo pixels So the difference between the
start address of the 2 lines is 16 ( modulo 64), so any DMA transfer size
bigger than half-word will be a misalignment. ( output stride needs to be a
multiple of transfer size in all DMA controllers I've seen). Meaning that
transfer speed is a quarter of what is possible.
For the next issue allow me to replace Sobel by the Gaussian blur ( since
it's more likely to be ran multiple times on the same image, and has the
same halo issue). In order to apply the blur filter 2 times on the image,
after the first run the halo needs to be recreated either by transferring
the image to DRAM and copying back with the stride ( or does the DMA
controller support local to local transfer ? even if it does it's another
memory transfer), or the local processor needs to add it.
To recap, biggest bottleneck here is DMA running at 1/4 speed and needing
to prepare the buffer for each new run.
How I see it.
The image image is sliced 8 x 128. Which is transferred as a contiguous
block of memory by the DMA at full speed. Now we run the filter on the full
block, and being implemented as pointer arithmetic on a 1d vector it will
generate a value for all output pixels ( the ones on the border will be
garbage). It might need an empty line at the top and the bottom of the
block to prevent memory access errors. Since the output size is the same as
the input, we can use it as the input for a new run of the function without
any changes.
Both options discussed here have issues in stitching back the tiles, but
we'll discuss them when we get there.
—
Reply to this email directly or view it on GitHub
https://github.com/parallella/pal/issues/106#issuecomment-112149182.

--
Andreas Olofsson, CEO/Founder at Adapteva
Cell: +1<PHONE_NUMBER>
Twitter: @adapteva
Web: adapteva.com
Linkedin: linkedin.com/in/andreasolofsson
http://www.adapteva.com/

The artifact appears for the border pixels, who need values in other slices to be computed correctly. Ignoring this artifact ( for the current discussion), we use the value in the halo ( in your case ), or some other one ( in mine).

Well, there is definitively some taught to have about memory, I honestly have no good insight about paralella memory transfer cost vs computation power.
What I know (I tested it on intel), is that, in the case of a "correct" gaussian filter (meaning it will output clean filtered border) it is slower to take care of the border inside he processing loop than to prepare an enlarged image and then execute a simpler processing loop.
Also, tile-based filtering will have to make a copy of the input data anyway, and will have to be larger than the output tile also anyway (or the tile-borders will not match each other).

Do you have by any chance the code pushed somewhere, so I can extend it and we can talk about the same thing ?
I didn't say to take care of the border in the processing loop ( that would be counterproductive). If correct borders are needed, a helper function could correct them. If not, processing is done.

The "intel" code ? It's on my github account > https://github.com/anael-seghezzi/Maratis-Tiny-C-library
I think it's better to have correctness, even if the resulting image is smaller, in my view, if the output has to be the same size as input, the corner has to be correct.
Also, I don't see how a helper function can simply correct a border in a tile-based system, because you will still need the extra input data to correct the border.
That said, I still agree that the memory transfer on the platforms targeted by pal needs to be optimal, I don't have a parallela so I'm not sure about that.

The helper function is for the border of the complete frame, where you have to assign values to the non existent pixels when computing the value of the pixels on the border. OpenCV has here 5 different options ( reflect, constant, wrap , ... ), and I was saying that the default should be don't care ( but due to the way it's implemented in pointer arithmetic it will be a kind of wrap for most of the image ).
And the way I was proposing to split the image, you would have to bring 2 more lines ( 256 pixels ) at full speed. For the tile-based one you need 132 more pixels, but it will be at 1/4th of the speed due to memory alignment.

If you are saying that transferring horizontal blocs (128x8) aligned in memory will remove a bottleneck on this platform versus a tile-based system (32x32), it should be considered and tested.
I'm not sure how this will react with larger radius where you cannot parse the radius-source pixels continuously. But larger radius have other winning strategies, large blur radius are usually processed in two passes horizontal blur then vertical blur, how is this regarding memory transfert on paralella ?

I'm saying a contiguous block transfer will remove a bottleneck that a halo based approach would incur.
And I'm not sure I understand what you say by not being able to parse the source pixels continuously.

I mean that, int the way you propose to split the image, if we have to deal with a larger blur radius, or if the image width is very large, you won't be able to fit the extra data in memory if you want contiguous pixels. Or maybe I misunderstood a step.
How do you deal with a large image width for example ? You will have to tile the image anyway no ?

An interesting link about this subject : https://www.youtube.com/watch?t=549&v=3uiEyEKji0M


Legacy API Deprecation for FCM

We've received an email yesterday regarding deprecation of the legacy API for FCM. It links to an FAQ entry, which says to migrate usages of SendMulticastAsync to SendEachForMulticastAsync.
I see this method was added in commit 74bd9e50, but there has not been a release tagged since 24/03/2022.
Is there any chance a new release might be tagged and pushed to NuGet at some point soon (preferably before the API cutoff on 20/06/2024...)?

I note that this seems to affect every version of the Admin SDK, including:

.NET (this issue)
Go
Java (functions implemented in https://github.com/firebase/firebase-admin-java/commit/d1baee366cebf121aa6d5a62593c08cc26ce97a8 but no release tagged)
Python (functions implemented in https://github.com/firebase/firebase-admin-python/commit/4323ed88cef168d66844add3aeaf3b7d19b46be6 but no release tagged)

In fact, the only version that seems OK is Node (functions implemented in https://github.com/firebase/firebase-admin-node/commit/0da72ef60535b6a9d0267e3843f45512718b8e74 and seemingly included in release 11.9.0)

I was wondering the same. The FAQ page specifically says >= 2.4.0 for .Net, but apparently 2.4.0 is not released on either GitHub or Nuget.

In addition, I got the following advice of the Firebase guys for replacing the batch/multicast message: "you should consider using HTTP/2 to send multiple requests over the same HTTP connection to the HTTP v1 API". I think, looking at the code, HTTP/2 is not supported yet. Are you planning that in the near future?
For completeness I added my question to the Firebase guys and the answer I got:
Question

Subject: Multicast messaging removed?
I got a mail that batch messaging will be removed from the FCM API. I was wondering, if both multicast and batch-messages will be removed. Why removing this efficient way of communicating with the platform? For my app I send the same push message to a lot of users (sometimes 1000 to 2000) depending on their location. Currently I can do this with 4 calls (4 times 500 messages). In the future I have to perform 1000 to 2000 calls...
Just wondering... I hope to hear from you and thanks for taking the time to take a look at this request. Have a nice day.

Answer

I understand that you’ve received an MSA informing you that some FCM APIs are being deprecated and will be decommissioned by June 2024 recently. This section of our Frequently Asked Questions page highlights the specific steps and processes that many developers such as yourself may want to follow to ensure that things work as expected after June 2024, so we usually recommend customers with similar inquiries start from there. I’d also suggest reading this guide about migrating to the HTTPv1 API. Of course, I’ll do my best to address your questions below.
This feature, called "multicast" in legacy HTTP APIs, is not supported by the HTTP v1 API. For use cases where end-to-end latency is critical, or where total fanout size is small (fewer than 1 million), Google recommends the HTTP V1 API. The HTTP V1 API over HTTP/2 can achieve up to ~1/3 of total message throughput rate compared to legacy multicast when sending on a single connection.
For use cases where throughput and egress bandwidth are prioritized or where total fanout size is large (greater than 1 million), Google recommends topic messaging. Topics are the most widely supported mechanism for sending to multiple devices and are usually able to handle most use cases in a meaningful way. Plus, they’re generally simple to understand and use, and developers can create an unlimited number of topics. So, I’m pretty confident that you will be able to translate your implementation to topics with a bit of experimentation.
Lastly, as an alternative to the legacy batch send method, you may use the standard HTTP v1 API send method, implementing your own batch send by iterating through the list of recipients and sending to each recipient's token. The FCM batch send API uses the same message format and authentication mechanism as the HTTP v1 API. However, it uses a different endpoint. If you want to improve efficiency, you should consider using HTTP/2 to send multiple requests over the same HTTP connection to the HTTP v1 API.
Hope this helps point you in the right direction, or at least gives you some options to consider. Don’t hesitate to reconnect should you have any additional questions, concerns, clarifications, or comments after considering the above and we can dive deeper.

I saw the changes to 2.4.0, however the suggested usage of HTTP/2 for the HttpClient is not implemented yet. Right?
I am not sure how the HttpClient behaves. Does it automatically use HTTP/2 in some situations? From what I understand you have to set the handler of the HttpClient the following way:
DefaultRequestVersion = new Version(2, 0); // Use HTTP/2

Additional to the above questions and important in relation to the performance of the library with this new (batch/multicast replacing) functionality:
I saw that in 2.4.0 the suggested usage of HTTP/2 for the HttpClient is not implemented yet. Right?
I am not sure how the HttpClient behaves. Does it automatically use HTTP/2 in some situations? From what I understand you have to set the handler of the HttpClient explicitly in the following way:
DefaultRequestVersion = new Version(2, 0); // Use HTTP/2

Just wondering...
Furthermore, keep up the good work!

Same question here.
From this doc, the default version is 1.1 on .NET 6

In .NET Core, the default message version differs based on the version you're using. .NET Core 2.1 changed the default value from 1.1 to 2.0. In .NET Core 3.0, the default value was reverted back to 1.1.
https://learn.microsoft.com/en-us/dotnet/api/system.net.http.httprequestmessage.version?view=net-6.0#property-value

FirebaseAdmin supports netstandard2.0, while netstandard2.0 compatible with  .NET Core 2.1 and 2.2
https://github.com/firebase/firebase-admin-dotnet/blob/bc7bc090a0636b4c7487dd530511139ec60b167a/FirebaseAdmin/FirebaseAdmin/FirebaseAdmin.csproj#L5C30-L5C30
https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0
According this comment, the default behavior will vary between different .net versions

The HTTP message version. The default value is 1.1, unless you're targeting .NET Core 2.1 or 2.2. In that case, the default value is 2.0.

Now that 2.4.0 has been released, I've updated my project to it.
It looks like SendMulticastAsync hasn't been marked as obsolete/deprecated as the ObsoleteAttribute is commented out: https://github.com/firebase/firebase-admin-dotnet/blob/bc7bc090a0636b4c7487dd530511139ec60b167a/FirebaseAdmin/FirebaseAdmin/Messaging/FirebaseMessaging.cs#L422
It seems the attribute was added but commented out in https://github.com/firebase/firebase-admin-dotnet/commit/74bd9e5038aa49562a093fa72c80c252384e85c8 - this is fairly easy to miss as Visual Studio by default continues the block comment when you enter a new line at the end.

Hey folks, you are right there was a delay on the .NET release and the new batch send APIs are now available in v2.4.0
https://firebase.google.com/support/release-notes/admin/dotnet#version_240_-_12_july_2023
Thank you for flagging the issue with the Obsolete tag! @Doris-Ge could you take a look at the ObsoleteAttribute when you get a chance, please? Thanks!

Thank you for flagging the issue with the Obsolete tag! @Doris-Ge could you take a look at the ObsoleteAttribute when you get a chance, please? Thanks!

Sure. I think I misunderstood the usage of Obsolete.
Thanks for flagging the issue! Will fix it.

I upgraded a project to v2.4.0 and replaced usages of SendMulticastAsync with SendEachForMulticastAsync and had to revert the upgrade a few days later because SendEachForMulticastAsync did not deliver notifications to devices as reliably as SendMulticastAsync - some notifications seemed to be lost. Has anyone else that upgraded ran into this? I haven't yet dug into where in the stack the notifications were being lost, and it's possible it was a fluke.

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?
Does SendMulticastAsync use Batch send API?

On June 20, 2024, we’re reducing the number of Firebase Cloud Messaging (FCM) legacy register APIs and legacy send APIs that provide similar functionality. This step will allow us to provide you with a more consistent experience and align with Google security standards to improve security, reliability and performance.
Because of these API decommissions, some already-deprecated SDKs and features will stop working after June 20, 2024.
Please consult the tables below to find which Firebase Cloud Messaging (FCM) APIs and corresponding services/SDKs/features will be discontinued and replaced with new alternatives.

I upgraded a project to v2.4.0 and replaced usages of SendMulticastAsync with SendEachForMulticastAsync and had to revert the upgrade a few days later because SendEachForMulticastAsync did not deliver notifications to devices as reliably as SendMulticastAsync - some notifications seemed to be lost. Has anyone else that upgraded ran into this? I haven't yet dug into where in the stack the notifications were being lost, and it's possible it was a fluke.

I am now performing the same upgrade to v2.4.0, but need more time to test the new SendEachForMulticastAsync method for notifications. Any particular use case when this happens? Is it happening for a high volume of notifications?

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?
Does SendMulticastAsync use Batch send API?

Yes and yes.

Hi all. Since this issue is still open, I wish to inquire about the status of it.
Reading back in this thread, it should be fixed when people upgrade to 2.4.0?
For example, I am using SendAllAsync and SendAsync. Do I need to do anything else?

Hi all. Since this issue is still open, I wish to inquire about the status of it. Reading back in this thread, it should be fixed when people upgrade to 2.4.0?
For example, I am using SendAllAsync and SendAsync. Do I need to do anything else?

You just need to replace SendAllAsync with SendEachAsync.
https://firebase.google.com/support/release-notes/admin/dotnet#cloud-messaging

There are ~2 months left before the completion of firebase legacy methods, is there any news? Our company is waiting for a solution to this problem. Is there really only a manual way left for us, like presented above?

There are ~2 months left before the completion of firebase legacy methods, is there any news? Our company is waiting for a solution to this problem. Is there really only a manual way left for us, like presented above?

As far as I know, just replace the SendAllAsync with SendEachAsync as @EricaLi123 mentioned. We did this with our company a few months ago. It works well.

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?這與將於 2024 年 6 月 20 日停用的舊版 Firebase Cloud Messaging (FCM) API 有關嗎？
Does SendMulticastAsync use Batch send API?SendMulticastAsync 是否使用批量發送 API？

Yes and yes. 是的，是的。

I just want to confirm that we are currently using SendMulticastAsync .
Should we switch to SendEachForMulticastAsync by June 20th, or am I misunderstanding something?
Thank you QQ

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?這與將於 2024 年 6 月 20 日停用的舊版 Firebase Cloud Messaging (FCM) API 有關嗎？
Does SendMulticastAsync use Batch send API?SendMulticastAsync 是否使用批量發送 API？

Yes and yes. 是的，是的。

I just want to confirm that we are currently using SendMulticastAsync .
Should we switch to SendEachForMulticastAsync by June 20th, or am I misunderstanding something?
Thank you QQ
Yes, you should start using SendEachForMulticastAsync instead of SendMulticastAsync

Is this related to the legacy Firebase Cloud Messaging (FCM) APIs which will be discontinued on June 20, 2024?這與將於 2024 年 6 月 20 日停用的舊版 Firebase Cloud Messaging (FCM) API 有關嗎？
Does SendMulticastAsync use Batch send API?SendMulticastAsync 是否使用批量發送 API？

Yes and yes. 是的，是的。

I just want to confirm that we are currently using SendMulticastAsync .
Should we switch to SendEachForMulticastAsync by June 20th, or am I misunderstanding something?
Thank you QQ

Yes! Use SendEachForMulticastAsync now instead of SendMulticastAsync

Step 1:
go to https://developers.google.com/oauthplayground/
1.Select the autorize api and after fill the input your own scopes (email, https://www.googleapis.com/auth/firebase.messaging) once it is complete after displayed the client id and client secret key for refresh_token.
Step 2:
POST  => https://developers.google.com/oauthplayground/refreshAccessToken
{"token_uri":"https://oauth2.googleapis.com/token","refresh_token":"1//04BZzVDcaVl4vCgYIARAAGAQSNwF-L9IrPUzn_0****"}  in body
Step 3:
POST  =>> https://fcm.googleapis.com/v1/projects/chat-2dc2d/messages:send
headers: Bearer Y29**********.......
{
"message": {
"token": "*********",
"notification": {
"title": "Sample",
"body": "Sample"
}
}
}  in body

Performance of the SendEachForMulticastAsync methods is too slow
After updating to v3.0.1, I am facing performance issues.
I am passing 500 tokens to the new SendEachForMulticastAsync for sending, but it takes several times (up to 20 times) longer compared to the old SendMulticastAsync.
Is there a way to resolve this? Also, from what I can see in this thread, it seems that sending via HTTP 2.0 may improve performance. Can this be applied to my project (.Net Framework 4.7.2)?

Indeed, performance is diabolical with this new SendEachForMulticastAsync method
The HttpClient it uses is not configured to use HTTP 2.0. For .NET Framework, it needs to use the System.Net.Http.WinHttpHandler nuget which is what provides HTTP 2.0 support on NetFx.

@nbevans
Thank you for the information. I'll look into configuring the HttpClient with HTTP 2.0 support using the System.Net.Http.WinHttpHandler for .NET Framework as suggested. I appreciate your help!

Thank you! I’ll try a few different approaches and see what works.


chore: refactoring cow swapper and type system for exchange client

Description

Pull Request Type

[ ] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)

closes #
Risk

Testing

Engineering

Operations

Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #4882   👈

This comment was auto-generated by Graphite.


ArrayIndexOutOfBoundsException in ByteBlockPool [LUCENE-8614]

A field with a very large number of small tokens can cause ArrayIndexOutOfBoundsException in ByteBlockPool due to an arithmetic overflow in ByteBlockPool.
The issue was originally reported in https://github.com/elastic/elasticsearch/issues/23670 where due to the indexing settings the geo_shape generated a very large number of tokens and caused the indexing operation to fail with the following exception:
Caused by: java.lang.ArrayIndexOutOfBoundsException: -65531
	at org.apache.lucene.util.ByteBlockPool.setBytesRef(ByteBlockPool.java:308) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.util.BytesRefHash.equals(BytesRefHash.java:183) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.util.BytesRefHash.findHash(BytesRefHash.java:337) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.util.BytesRefHash.add(BytesRefHash.java:255) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.index.TermsHashPerField.add(TermsHashPerField.java:149) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.index.DefaultIndexingChain$PerField.invert(DefaultIndexingChain.java:766) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.index.DefaultIndexingChain.processField(DefaultIndexingChain.java:417) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:373) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:231) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:478) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1575) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]
	at org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1320) \~[lucene-core-6.4.0.jar:6.4.0 bbe4b08cc1fb673d0c3eb4b8455f23ddc1364124 - jim - 2017-01-17 15:57:29]

I was able to reproduce the issue and somewhat reduce the test that reproduces it (see enclosed patch) but unfortunately it still requires 12G of heap to run.
The issue seems to be caused by arithmetic overflow in the byteOffset calculation when BytesBlockPool advances to the next buffer on the last line of the nextBuffer() method, but it doesn't manifest itself until much later when this offset is used to calculate the bytesStart in BytesRefHash, which in turn causes AIOB back in the ByteBlockPool setBytesRef() method where it is used to find the term's buffer.
I realize that it's unreasonable to expect lucene to index such fields, but I wonder if an overflow check should be added to BytesBlockPool.nextBuffer in order to handle such condition more gracefully.

Migrated from LUCENE-8614 by Igor Motov (@imotov), updated Mar 03 2022
Attachments: LUCENE-8614.patch
Linked issues:

#11477

I opened a PR that addresses the overflow. I couldn’t reproduce the error using the test in the patch file, but the overflow is easy to reproduce if we test the ByteBlockPool directly.

@stefanvodita Seems the issue is resolved? I closed the issue, feel free to reopen it

Yes, it's resolved. Thanks, Patrick!


Hi i was wondering if it would be possible to just have one post on the landing page but loaded randomly?

I don't believe it's possible with Gatsby's built-in functionality, but I'm sure you can do it with a little customization.


e2e test for SGT

A list of manual tests are done here: https://perfect-amphibian-929.notion.site/SWC-Devnet-1282e493e88380648486d4961eb91a8d
To be more specific, we want to test

SGT without native balance
Full SGT payment with native balance
Partial SGT payment with native balance, where SGT becomes zero, and the rest of gas is paid by native.  This ensures that as long as SGT + native balance >= tx cost, we will always accept the tx
Insufficient gas with both SGT and native balance, i.e.,  SGT + native balance < tx cost

Besides these, we should also check whether the balances of the vaults (fee recipients) are expected.

Done in https://github.com/ethstorage/optimism/pull/125


Measuring User Journeys and Steps

Final Part of User Journey feature addition.
Added ability to measure User Journeys and steps
** Still need to fix one of the tests

Going to merge this one, and than do a cleanup on my own.

Thank you @Cdub-9


⚠ Bofrost.at has degraded performance

In 4e0846a, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1182 ms

Resolved: Bofrost.at performance has improved in e5af780.


OpenSource or not?

Description
18 pull requests ignored
How to reproduce
check github
What do you expect
pull requests addressed
What happened instead
pull requests ignored
Software:

docker version: [Add docker version here, client and server]
docker-maven-plugin version: [Add docker-maven-plugin version here]
maven version: [Add maven version here]

Full backtrace
Pull request.

Hi @karlnicholas, as mentioned in the README and CONTRIBUTING.md, we don't plan on making major contributions to this repository going forward as we instead are using https://github.com/spotify/dockerfile-maven for many internal projects.
Spotify open sources code in the hopes that the work we have done is useful to others. In the lifetime of this repository we have about 20 contributors from outside Spotify and we've closed 135 issues.
We are happy to accept pull requests and review issues when we can, but our time has to compete with other priorities and we also have to balance changes to the source code with how we use the code internally. The same is true of our other open source repositories related to Docker (docker-client, dockerfile-maven, docker-gc, etc).
If we are not able to review PRs as fast as contributors would like, or able to accept proposed changes or resolve issues in a way that the reporters would like, forking the code is always an option that we would have no problem with. Our goal with open sourcing code is to contribute back to the community, not to create or maintain the single "build docker images from Maven" plugin or to have a single project that solves every docker/maven need.
If there is a specific PR or issue you would like to have reviewed it would be more constructive to poke people in that PR or issue.

I was looking for the EXPOSE option because OpenShift (Kubernetes?) needs to have a EXPOSE in the dockerfile for a service to be created when I create a new application from an image. Turns out that feature has been added. A documentation update would be useful. Thanks.

@rhuss -- looks great thanks for heads-up.


Is there a way to contribute to the documentation and descriptions on the site?

I think this project could be way bigger if the spelling was better on the site.
Example: "Deployer has very clean code and good tested."
should be something like: "Deployer has a very clean, and well tested code."
IMHO sentences like this does not help the credibility of the project.
What do you think @elfet ?

YES! It's will be so gooв! English is not my primary language, so i have problems some time with.
Doc located here: https://github.com/deployphp/docs
Site located here: https://github.com/deployphp/deployer.org (pages)

Excellent, I'll see what I can do there. :)


Correct way to add Equihash 192,7 support.

Note
Please use the following format to file an issue. Issues that fail to comply will delay our responses.
Please remove this section when you submit the issue. Thank you for your cooperation.
Description
I am currently trying to add support for Vidulum (Equihash 192,7) From what I could gather, Equihash 96,5 144,5 and 209,9 are supported. What is the correct way to add 192,7? I have tried editing EquihashSolver.cs to allow 192,7 but when I try to re-build it throws this error: Crypto/Hashing/Equihash/EquihashSolver.cs(135,45): error CS0117: 'LibMultihash' does not contain a definition for 'equihash_verify_192_7' [/home/pool/miningcore/src/Miningcore/Miningcore.csproj]
I have since tried to look inside Miningcore.csproj file and cannot find anything relevant to equihash there.
Steps to Reproduce

Add changes to EquihashSolver.cs
Rebuild using guide on Github
Error is produced.

Expected behavior
Compile complete
Actual behavior
Error's out.
Reproduces how often
100%
Version
If you are using released version, please state your version.
If you are using clone from dev branch, please state commit hash of your copy.
Also, please include the OS name and version you're currently running.
I am running the latest version of MiningCore and have done some adjustments to the back end to allow Lyra2v3 and x21s. I am running Ubuntu Server 16,04 LTS
Additional Information
Any additional information, log, configuration or data that might be necessary to reproduce the issue.

It sounds like you haven't added the relevant C code for equihash_verify_192_7 to Libmultihash
Here's an example commit from when Lyra3 was added to roughly see what types of changes need to be made
https://github.com/coinfoundry/miningcore/commit/47ab0e6a2ae2c33629d3c000b65be5d0fba6c66d

Hi thank you for your help, I have since amended the files as requested and this is what I put in my Libmultihash file:
[DllImport("libmultihash", EntryPoint = "equihash_verify_192_7_export", CallingConvention = CallingConvention.Cdecl)] public static extern bool equihash_verify_192_7(byte* header, int headerLength, byte* solution, int solutionLength, string personalization)
I am now receiving this error,
 from assembly 'Miningcore, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null'.    at System.Reflection.RuntimeAssembly.GetType(RuntimeAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type, ObjectHandleOnStack keepAlive)    at System.Reflection.RuntimeAssembly.GetType(String name, Boolean throwOnError, Boolean ignoreCase)    at Miningcore.Crypto.Hashing.Equihash.EquihashSolverFactory.InstantiateSolver(IComponentContext ctx, Object[] args) in /home/pool/miningcore/src/Miningcore/Crypto/Hashing/Equihash/EquihashSolverFactory.cs:line 44
Which leaves me to line 44 of EquihashSolverFactory.cs:

var hashType = typeof(EquihashSolver).Assembly.GetType(hashClass, true);

This has now been solved thanks to @bitspill


Add support for ALBs Target Groups

Adding support for assign workers to Application LoadBalancer Target Group

Codecov Report

Merging #353 into master will increase coverage by 0.08%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #353      +/-   ##
=========================================
+ Coverage   40.71%   40.8%   +0.08%
=========================================
  Files          19      19
  Lines        2009    2012       +3
=========================================
+ Hits          818     821       +3
  Misses       1076    1076
  Partials      115     115

Impacted Files
Coverage Δ

core/controlplane/config/config.go
63.91% <100%> (+0.18%)
:white_check_mark:

Continue to review full report at Codecov.

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

Great work @Vrtak-CZ!
Thanks for also covering E2E and integration tests. It really helps 👍


enchantment

Hey, I have issues with players with multiple accounts and multiple ips.
the enchantment would track all ips and all players whom join with any of the ips so for example:
**for the example i used names but the names will be the users UUID's
Theshadyonehd ip: <IP_ADDRESS>
Theshadyonehd Ip: <IP_ADDRESS>
Epic_ninja ip: <IP_ADDRESS>
Theshadyonehd Ip: <IP_ADDRESS>
shadyone ip <IP_ADDRESS>
shadyone ip: <IP_ADDRESS>
thisenchantment ip <IP_ADDRESS>
Say we want to ban thisenchantment. we write (/banall thisenchantment hacking). this would ban all the above names and ips because they are linked in one way or another, by ip or UUID. then after the ban the plugin will scan the ips and UUID's to further ban other ip's and UUIDs linked to the players original account.

Hey @theshadyonehd,
not sure what the issue/question is right now.
Is the /banall command new? I never heard of that one.

its an enchantment to the current plugin, hence the title.

This isn't the repo for the plugin, this is repo is a fork of the webUI.
You should go to the plugin repo if you have a suggestion for the plugin.

ah sorry

@FourDown thanks for clarification. I didn't know what was going on :P
@theshadyonehd not an problem!


Allow customizing build dir

Docker allows specifying the build directory: docker build target/artifacts. People usually use it with docker build ., but it is useful at times.
We're relying on using non-. build dir in our build system, so draft doesn't work for us as it doesn't allow customizing build dir (only Dockerfile location).
It would be great if the support for customizing build dir was added to draft.

that would be a great thing to add, you're right. Unfortunately, we do not have resources to apply to draft at the moment; if things change, this is on the list.


RLP Should expose certs via bosh link

The RLP certs should be discoverable: expose them via a bosh link

I disagree with this. With BOSH 2 it is easy enough to create a cert signed by the loggregator CA. Certs/keys should be unique to a service. e.g. why would google and yahoo use the same cert?

While I agree, CF and BOSH don't really seem to support any form of RBAC. Based on previous decisions within CF, I think we should move forward with exposing the link. We should lean on BOSH to allow for better control for the operator on which services can consume which links.

Instead of exposing a link for each component (in this case the RLP), consumers should just use the link that doppler provides (https://github.com/cloudfoundry/loggregator-release/blob/4e84261c22294570da734950ebd7c667274f46fa/jobs/doppler/spec#L20-L25). This way consumers don't need intimate knowledge of the loggregator architecture.

@poy wouldn't that require doppler to mark its loggregator link with shared: true in the PCF manifest?
I'm not sure how to use that link in a tile.yml configuration.

@bradylove I found documentation on how to generate signed certificates in a tile form,
But is that possible directly with just a BOSH manifest? If so how do I do that? Do you have any documentation I can follow?

@mattysweeps You can use BOSH variables to generate certificates. Here is the BOSH documentation on how to do so, and here is an example of how we are generating the certificate for the RLP in CF Deployment.


How can I prevent a mat-expansion-panel from opening when clicked?

I want to control my mat-expansion-panel solely with the panel's [expanded] input property. I am using NGRX as state management.
Therefore, I don't want the panel to open when clicked. Instead, I have my own click listener that will dispatch the right action that will lead to the panel to open.
How can I prevent it from opening when clicked? I tried (click)="$event.stopImmediatePropagation(); but it does not do the trick.
<mat-accordion [multi]="true">
  <mat-expansion-panel [expanded]="item.isOpen">
    <mat-expansion-panel-header (click)="togglePanel($event, item)">
        <!-- Header Content-->
    </mat-expansion-panel-header>

    <ng-template matExpansionPanelContent>
        <!-- Panel Content -->
    </ng-template>
  </mat-expansion-panel>
</mat-accordion>

Any ideas?

You can bind to the disabled property on the mat-expansion-panel.

@crisbeto That would change the appearance, make it unusable with keyboard and propagate wrong information to screen readers. It should just not open automatically :wink:
Ideally there would be a boolean input to disable automatic opening and an event so the developer doesn't need to write the listener itself.
Btw this may be useful for other components too. e.g. Tabs, Tree etc.

Isn't this the point though? Otherwise the user would click it without any feedback on why nothing is happening.

using css to disable pointer events works:
.disabled-pointer {
  pointer-events: none;
}

See https://stackblitz.com/edit/angular-wykguu for exmaple

@crisbeto The event handler will dispatch an action and as result of the action processing and state change the panel will open.
In the easiest case the action will just open the panel. But it's also possible to open the panel only after you have successfully loaded data from external sources, or display an error if that fails.
The possibilities of what is done before opening the panel are almost unlimited.

I think this looks like a good feature request, but I'm not sure if that complies with the Material Design specification the expansion panel is based on. Also it's unclear how this plays together with accessibility.


Wrong modified row when editing using rowIndex

I'm submitting a ...
[x] bug report
[ ] feature request
[ ] support request

Current behavior
When a column is sorted (either ascending or descending), modifying a row as shown in the demo using the row index seems to modify other rows.
Expected behavior
Only the correct row comment should be modified.
Reproduction of the problem
Load the following component (a simplified version of row-grouping):
import { Component } from '@angular/core';

@Component({
  selector: 'row-grouping-demo',
  template: `
    <div>
      <ngx-datatable
        class='material'
        [rows]="rows"
        [rowHeight]="40">
        <ngx-datatable-column prop="id"></ngx-datatable-column>
        <ngx-datatable-column prop="comment">
          <ng-template ngx-datatable-cell-template let-rowIndex="rowIndex" let-value="value">
            <input
              (change)="updateByIdx($event, rowIndex)"
              type="text"
              [value]="value"/>
          </ng-template>
        </ngx-datatable-column>
      </ngx-datatable>
    </div>
  `
})
export class RowGroupingComponent {
  rows = [
    { id: 'A', comment: '1' },
    { id: 'B', comment: '2' },
    { id: 'C', comment: '3' }
  ];

  updateByIdx(event, rowIndex) {
    this.rows[rowIndex]['comment'] = event.target.value;
    this.rows = [...this.rows];
  }
}

Steps:

Click on the Comment column header to sort in ascending order.
Click on the comment with id A. Write 5 as comment and press Enter. At this point everything is working as expected and the rows will be automatically sorted. The cursor is now modifying the comment with id B
Write 1 in the comment with id B and press Enter. A will be modified instead of B.

Please tell us about your environment:

OS: macOS High Sierra 10.13.3
Table version: 13.0.0
Angular version: 6.0.0
Browser: Chrome 66

Why did you close your issue @carmocca ? Did you find a solution? The row index is not updated after sort the table.

@issaacfi I closed the issue since I am no longer working on the project which made use of this library and there was no response from the devs. As a workaround, we had to update the rows attribute using a timeout, e.g:
setTimeout(() => {
   this.rows = [...this.rows]; // Toggle Angular detection
}, 150);

Which is, of course, a huge hack.

Thanx @carmocca
I had to sort manully as the server side sort example, and with this, the row index changed to its right value.
Regards.


pd/etcd: fix hyper client

Hyper async client queues the request handlers and call the first handler on the first response.
But this will be a problem if we do not handle responses in order.
So we reuse the hyper client only if we complete the request/response.
ref #956

This will cause infinite timeout if we start TiKV before PD.

Do we need to report the issue to hyper project?

ref https://github.com/hyperium/hyper/issues/901

I think we can remove hyper pd client now.

Now we don't need to get pd leader first.

OK, close here and remove hyper client in another PR.


driver.js not showing popover in angular8

import * as Driver from 'driver.js';
import 'driver.js/dist/driver.min.css';
driver = new Driver();
const steps = [
{
element: '#apiheader',
popover: {
className: 'first-step-popover-class',
title: 'API header',
description: 'API header',
position: 'right'
}
},
{
element: '#newapi',
popover: {
title: 'Title on Popover',
description: 'Body of the popover',
position: 'top'
}
},
];
this.driver.defineSteps(steps);
this.driver.start();`
Above code is showing only white color on the item.

Could you please provide a sample example on codesandbox?

Closing it for no response