Substitutig node-zopfi-es with @gfx/zopfli

Here is an example using zopfi but from @gfx/zopfli instead of node-zopfi-es.  The advantage of the former is that it does not depend on node-gyp and the disadvantage of the latter is that it takes very, very long on every yarn update.
import { gzipAsync } from '@gfx/zopfli';

… gzipPlugin({
  customCompression: content => gzipAsync(Buffer.from(content), {numiterations: 15}),
  })

hi @dilyanpalauzov , thanks for all your suggestions, I tried to add them to the README :blush:

For @gfx/zopfli the readme does not clarify that gzipAsync() must be used.  It took me a lot of time to figure this out myself.

:flushed: of course you're right - my node-zopfli example was wrong already as their gzip function takes a callback as well. Only they provide a gzipSync alternative while @gfx/zopfli provides a gzipAsync alternative :roll_eyes:


Upgrade to Psycopg3

https://learndjango.com/tutorials/psycopg3-binary-and-django-42-installation-quick-t

closed with 33459f3


[MacOS] Add SBT to MacOS 10.14, 10.15 and 11

Description
This PR adds SBT tool to MacOS 10.14, 10.15 and 11 images.
Related issue: https://github.com/actions/virtual-environments/issues/4065
Check list

[x] Related issue / work item is attached
[x] Tests are written (if applicable)
[x] Documentation is updated (if applicable)
[ ] Changes are tested and related VM images are successfully generated

/azp run macos1014, macos1015, macos110


Is it possible just to draw a bunch of points on say a background image using this?

I am looking at producing something similar to this drawing and am wondering if your node can do it of if you know of a node that can?

The Green and Blue lines are an array of points that I would want to have the node convert into a vector and then put them onto a background raster image.

@ozdeadmeat
You can draw a polyline in svg, to create a line chart.  But looks like a lot of work to me, and kind of reiventing hot water.  Can't you use the ui-chart node?


Adding data after model construction

Many thanks for creating BridgeStan.
Looking at the API, it seems like the data (the observations) can only be passed at the model construction stage (e.g., bs_model_construct in the C API). So, it is not possible to add data after that stage.
Possibly, there is a good reason I have not thought about yet.
Anyway, is this limitation expected to stay?

Of course, one may contact the data on the user side and pass it to a new bs_model_constuct call.
Is this the recommended practice in a case where new observations have arrived?

This question was answered at the talk of @roualdes last May at the Oklahoma Data Science Workshop.
https://mediasite.ouhsc.edu/Mediasite/Channel/python/watch/93ce0ad0ede74e1e84e60ee8607d6cb91d
around 1:10:10 time.
So yes, we need to reconstruct a model for new data. :pray:

Yes, not only is it required in the API, it's really required conceptually for standard Monte Carlo sampling for Bayesian inference, where we are taking draws $\theta^{(m)} \sim p(\theta \mid y)$ from the posterior for fixed data $y$.

Makes sense. Thanks for the quick help!


[$250] Desktop window does not keep the desired size

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.46-4
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @flodnv
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1728478035371609
Action Performed:

Open Desktop App
Resize Desktop App window
Quit Desktop App with Cmd+Q
Open Desktop App

Expected Result:
Size of window is the same as step 3 (after resizing it)
Actual Result:
Size of window is the same as step 1 -- it resets to some default. We should keep the user's resize.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Native
[ ] Android: mWeb Chrome
[ ] iOS: Native
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[x] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/12328452-213c-470b-b70d-3c3d9991ae15

Add any screenshot/video evidence

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~021844122075299762610
Upwork Job ID:<PHONE_NUMBER>299762610
Last Price Increase: 2024-10-09

Issue OwnerCurrent Issue Owner: @mananjadhav

Proposal
Please re-state the problem that we are trying to solve in this issue.
Desktop window does not keep the desired size
What is the root cause of that problem?
Here we always set the window size to 1200 x 900 when opening a desktop application.
What changes do you think we should make in order to solve the problem?
We need to save the window dimensions when the application is closed and get them when the application is opened. To do that we can done bellow steps

install 8.2.0 version of electron-store module
Add following lines in desktop/main.ts file

import Store from 'electron-store';

const store = new Store()

Update this part of code like below

const windowSize =  store.get('windowSize');

browserWindow = new BrowserWindow({
    backgroundColor: '#FAFAFA',
    width: windowSize?.width ?? 1200,
    height: windowSize?.height ?? 900,

Update this if block to below

if (quitting || hasUpdate) {
    const { width, height } = browserWindow.getBounds();
    store.set('windowSize', { width, height });
    return;
}

What alternative solutions did you explore? (Optional)

Proposal
Please re-state the problem that we are trying to solve in this issue.
Desktop window does not keep the desired size
What is the root cause of that problem?
We have fixed the width and height of the BrowserWindow when initializing the desktop version. This ensures consistency, but it may limit responsiveness and scalability across different screen sizes.
https://github.com/Expensify/App/blob/00b7426d3539cc16f0a714885da7cbf0796a04c7/desktop/main.ts#L292-L293
What changes do you think we should make in order to solve the problem?
We will store the width and height when the desktop app is closed and retrieve them when it is reopened. We should prioritize simplicity, lightweight design, and a focused approach by using straightforward APIs like electron-settings to handle basic configurations.
npm install electron-settings
import settings from "electron-settings";
// ./desktop/main.ts#L290
+      let windowState = settings.getSync('windowState') || {
+                    width: 1200,
+                    height: 900,
+                };

 browserWindow = new BrowserWindow({
-                    width: 1200,
+                   width: windowState.width,
-                    height: 900,
+                   height: windowState.height,
                    ...

// ./desktop/main.ts#L254
if (quitting || hasUpdate) {
// If the app is quitting or an update is available, save the current window size and position to settings.
+                    let {width, height, x, y} = browserWindow.getBounds();
+                    settings.setSync('windowState', {width, height, x, y});
return;

Proposal
Please re-state the problem that we are trying to solve in this issue.
When a user resizes the desktop app window and quits with Cmd+Q, the app does not remember the new size. It resets to the default size when reopened.
What is the root cause of that problem?
The app doesn’t store the window size, so it defaults to the original dimensions when restarted.
https://github.com/Expensify/App/blob/00b7426d3539cc16f0a714885da7cbf0796a04c7/desktop/main.ts#L290
What changes do you think we should make in order to solve the problem?
Since we are already using Onyx in our app, we don't need to install any additional packages
we will create a new Onyx key windowDimensions  in the ONYXKEYS.ts file,  to store the window's width and height.

Save the window size in windowDimensions whenever user is closing the app here

             const {width, height} = browserWindow.getBounds();
             Onyx.set('ONYXKEYS.WINDOW_DIMENSIONS', {width, height});

When the app starts, retrieve and apply the saved size.         let width;
         let height;
         Onyx.connect({
             key: ONYXKEYS.WINDOW_DIMENSIONS,
             callback: (windowDimensions) => {
                 width = windowDimensions?.width ?? 1200;
                 height = windowDimensions?.height ?? 900;
             },
         });

3. If no size is saved, use the default size.

Will review the proposals in a while.

Overall all the proposals identified the correct root cause. But I feel we should leverage Onyx instead of adding new packages. Hence, I think we should go with this proposal. We still need to workout the proper code logic.
🎀 👀 🎀 C+ reviewed.

@mananjadhav @tylerkaraszewski Hi there. I am sorry but All proposals are very close to mine. I first found the problem and suggested a way to fix the problem with the opinion of fixing the problems. And I do not think that the place where should be saved data significant difference in this case. And in my opinion, the other proposal does not correspond to below point  from CONTRIBUTING.md

Note: Before submitting a proposal on an issue, be sure to read any other existing proposals. ALL NEW PROPOSALS MUST BE DIFFERENT FROM EXISTING PROPOSALS. The difference should be important, meaningful or considerable.

Once again, I apologize if I'm wrong.

Thanks for raising this @shahinyan11. As I said I can see all proposals did identify the correct root cause. But the implementation details does differ. The change is anyway very trivial. I still stand by with my recommendation.
But I'll let @tylerkaraszewski decided.

Thank you, will submit the PR by tomorrow.

To resolve this issue, we needed to persist the window size between sessions. Several options were considered, including external packages, onyx, local storage, and using the fs module.
After exploring these options, I found that using the fs module was the simplest and most straightforward solution, requiring minimal changes to the existing code. This approach allows the window size to be saved to a local JSON file and restored on app reopen.

Starting the conversation here for using the code different from proposal (). @Shahidullah-Muffakir I don't think we should be using fs.  This isn't an ideal solution.
Also, I think if you were to change the approach we should post it on the issue to clarify before implementing the PR. The only reason the proposal was accepted because it reused existing lib.

Perhaps we can't use Onyx.connect in index.desktop.ts. I tried it before, but it didn't work, so I tried using the Electron package instead

Also, I think if you were to change the approach we should post it on the issue to clarify before implementing the PR. The only reason the proposal was accepted because it reused existing lib.

@mananjadhav Of course, that wouldn't be fair. The proposals should be re-review

@mananjadhav, I tried using Onyx, but it was quite difficult to make it work, and even if we could, it would add a lot of unnecessary complexity.
As for fs, it’s not an external package—it’s already built into our environment, we are not installing anything, which is why I chose it. Other plugins would also end up using disk storage, just like fs. For such a small change, I don’t think adding an external package makes sense, since we can get the same result with fs.
Let me know what you think. Thanks!

@mananjadhav,
The main issue I’m having is that I can't access the Onyx data in the main process when creating the main window. The window size is saved correctly when the user quits the app with Cmd+Q, but when the app restarts, I can't connect to Onyx.
I think it might be because Onyx uses browser storage, so before the browser window is created, its storage isn't available (but I’m not sure).
Could you help me figure out how to connect to Onyx before the main window is created? Sorry for the trouble.

@tylerkaraszewski @mananjadhav Hi guys. Is there any updates, what's next ?

@mananjadhav - can you address the above questions?

@mananjadhav @tylerkaraszewski , I was able to use Onyx to store the window dimensions for this. Can I update my proposal that way to resolve this issue?

I tried to check if we can use Onyx before the browser window is initialized. I am still exploring solutions, will keep you'll posted.

I checked to see if only Onyx can be used. It didn't work for me. But do we want to then add package or use fs for only storing the dimensions.
@tylerkaraszewski Are there any plans to store settings for the Desktop app? or should we invest in making sure that Onyx retains the value on app load?

Quick bump @tylerkaraszewski on the previous question.

I asked a question here but have received no response so far: https://expensify.slack.com/archives/C01GTK53T8Q/p1732665318386409
I should probably bring it up again.

I'm OOO Dec 16-20, I don't think this will need a BZ while I'm out so not adding a buddy

Discussion here: https://expensify.slack.com/archives/C01GTK53T8Q/p1734129503598689
We've decided to close this as too high of effort for low value returned.


Search for specific email or phone number

Hello, can any one explain how to search for a specific contact number or mail address? I spent many time to obtain this result but without success.
Many thanks to all!

This issue is three years old. If you are still having trouble with the latest version from master, please open a new issue.


[NTI] Weird order-dependence in ObjectType#joinSets

Say we have a base class Foo with two separate subclasses Bar and Baz.  The union Bar|Baz is perfectly normalized to not contain any subtype-supertype pairs.  But if we join this union with Foo, the result should be Foo, since Bar and Baz are direct subtypes.  If we call ObjectType#joinSets(Foo, Bar|Baz), this is exactly what happens.  But if we swap the arguments, the result is Foo|Bar.  This is because the outer iteration ensures we try to join every member of objs2, but later members of objs1 get left out if an earlier member matches.
I believe the proper fix is to be more careful about how we iterate.  Suppose we have two sets: [A, B, C] and [D, E, F].  We need to check all cross-combinations: A∨D, A∨E, A∨F, B∨D, B∨E, B∨F, C∨D, C∨E, and C∨F.  If one of these pairs does join, we might be able to save some work, but we need to ensure that we don't lose any individual comparison.  If all the A∨* joins fail, we add A to the output set.  Otherwise, say A∨D joins to G.  We replace both A and D with G for the rest of the operation, and do not add anything to the output set just yet.  If any further A∨* joins succeed (say G∨E is H) then we again replace G with H (in both A and B's original position), but we can also remove E entirely since D and E have collapsed via A into H.  When we finish a pass of an element of the first set without any joins succeeding, we add it directly to the output.  We then add whatever's left from the second set (which may have been replaced/modified).  This is a different operation from just retaining keptFrom like we currently do.
That said, I don't fully understand the issue with record types (the nt2.isBuiltinObject && nt1 != null && obj1.isSubtypeOf(obj2) check), so I'm not confident implementing this myself (without grokking that part better), nor do I know a good way to write a regression test for the non-normalized union.

Ignoring the records (though we may want to change the break to a continue), the fix should be as simple as
for (ObjectType obj2 : objs2) {
  int foundIndex = -1;
  for (int i = 0; i < objs1Arr.length; i++) {
    if (objs1Arr[i] == null) continue;
    if (areRelatedNominalTypes(obj1.nominalType, obj2.nominalType)) {
      // possibly handle records - break? continue?
      if (foundIndex >= 0) objs1[foundIndex] = null;
      objs1Arr[foundIndex = i] = obj2 = join(obj1, obj2);
    }
  }
  if (foundIndex < 0) newObjs.add(obj2);
}
for (ObjectType o : objs1Arr) {
  if (o != null) newObjs.add(o);
}

This is actually a bit simpler than the existing code: we don't need to worry about the keptFrom1 array since we modify objs1Arr in-place.  We don't get the benefit of breaking out of the inner loop early as often, but that only happens when a join succeeds, and so is not likely to be an important factor.

I'm also not sure why the ObjectsBuilder resolution policy does not already handle this automatically.

Repro without generics


LuaPreprocess docs are unavailable

Playbit docs redirect to the LuaPreprocess docs in several places, since it made more sense to link already existing documentation. However it seems the LuaPreprocess site has gone down. I opened a ticket in the repo requesting that the docs be restored or moved.
Given the status of the domain on ICANN and that there hasn't been a commit in 2 years, I'm dubious it will come back up. Since Playbit depends so heavily on the external tool, I'll likely fork it and add the docs into the repo.

I've forked the original repo here and added docs in Markdown format. Just need to update submodule and docs in Playbit.

Fixed in 499bdc523f2122998d6e97ad636132db0cc7964d


Add link to ClickUp bounty program

ClickUp is a project management tool that pays for security exploits that are discovered.

Thanks 👍


Use Dart expressions in compiled sql queries

As discussed in #142, we can have a convenient way inline moor's Dart api in compiled sql queries.
Syntax (not settled yet)
We could introduce a $<name> syntax in sql queries to denote that a Dart expression is expected. So queries could look like SELECT * FROM tbl WHERE $predicate or SELECT * FROM tbl WHERE a = $expr. That syntax would parse to a new ast node inheriting from Expression (in the sqlparser package), so it neatly integrates with our existing type resolvers.
Generated code
We can infer the type for these expressions using our existing resolver for variables. Then, we could generate methods with the following signature:
Selectable<Tbl> query1(Expression<bool, BoolType> predicate);
Selectable<Tbl> query2(Expression<String, StringType> expr);

If a type can't be inferred statically, we can generate a Expression parameter without type arguments.
Restrictions
To make sure that we can still generate efficient and type-safe code, the expressions (which are bound at runtime), can't have any effect on what the query returns (which needs to be known at build time). This means that we have to disallow:

Expressions having an impact on column names returned by a SELECT query, e.g. when using SELECT a = $expr FROM tbl. When a is a column in tbl, we infer expr to have the same type, but the name of the column depends on what's used for expr at runtime. This would break our mapping code.
A column type of a select statement can't be inferred: SELECT $expr AS e. We can't generate a type-safe class to hold the result in that case. Maybe we can just make it have a dynamic field though?

Open questions
A Expression in moor can contain an arbitrary amount of (not explicitly indexed) variables, which would be inserted into the query. We should evaluate if and how these might interfere with

variables defined in the query
expanding array variables, which are also resolved at runtime

Another question is whether we should allow the same expression to appear multiple times: SELECT * FROM tbl WHERE a = $expr OR b = $expr. If we allow that, should we make variables appearing in that expression explicitly-indexed so that they only appear once?

Another question is how ORDER BY expressions should be handled:
SELECT * FROM tbl
ORDER BY $expr DESC

This $expr should only be allowed to define a single OrderingTerm with no OrderingMode.
SELECT * FROM tbl
ORDER BY $expr

Whereas this $expr could allow multiple OrderingTerms with their own OrderingModes.

Interesting point. In the first example, $expr is unambiguously an expression as defined by sqlite, so I think the most reasonable way would be to expose it as an Expression in the generated method. In the second query, $expr could either be an expression, an ordering term or multiple ordering terms.
I wanted to focus on expressions in the initial version because they require little adaption from the parser. Later, we may extend the grammar to denote that a Dart component should be used as a List<OrderingTerm>:
SELECT * FROM tbl ORDER $orderingTerms; -- should generate List<OrderingTerm>
SELECT * FROM tbl ORDER BY $term; -- should generate Expression

Although I guess we can also support something like
SELECT * FROM tbl ORDER BY $term1, $term2, $expr DESC; -- OrderingTerm, OrderingTerm, Expression
SELECT * FROM tbl ORDER BY $term; -- List<OrderingTerm>

at a parser level if we make the precedence be Expression < OrderingTerm < List<OrderingTerm>. But in that case we'd have to support it from the very first version to avoid a breaking change later. I'll see how much more work that would actually be.
We also hit a similar issue with LIMIT clauses:
SELECT * FROM tbl LIMIT $lmt; -- Expression<int, ...> or LimitClause?
SELECT * FROM tbl LIMIT $a, $b; -- definitely two expressions here

A first version of this is now on develop, I went for the $name syntax. In sqlite, $name is a variable declaration, but we don't support those variables and I don't think they're widely used. The $ is annoying to use with queries defined in Dart, but I that should be ok since this feature is only necessary for dynamic queries in moor files.
We can generate parameters for expressions, single ordering terms, full order by clauses and limits, using the class that provides most flexibility in each use case. This feature should be compatible with both arrays and regular variables, but variables with an explicit index may not appear after a Dart template.
It doesn't contain the two checks that ensure expressions can't cause invalid code. Also, we would generate invalid code then the same template shows up multiple times (e.g. WHERE x = $expr OR y  = $expr). We should detect these cases and provide error messages for all of them.

Wow that was fast! I've been playing around with it a bit and the dynamic ORDER BY is a really powerful feature... much cleaner than writing this and mapping from an enum!
ORDER BY
  CASE WHEN :order_ = 0 THEN updated_timestamp END DESC,
  CASE WHEN :order_ = 1 THEN last_name END ASC,
  CASE WHEN :order_ = 1 THEN first_name END ASC,
  CASE WHEN :order_ = 1 THEN updated_timestamp END DESC,
  id ASC

I'm having some trouble getting WHERE expressions to work though. Here's my SQL (not sure if all of these should even be valid queries btw - especially _testWhere3 vs _testWhere4):
create table tbl (col text);
_testWhere1: select * from tbl where $expr;
_testWhere2: select * from tbl where col = $expr;
_testWhere3: select * from tbl where col IN $expr;
_testWhere4: select * from tbl where col IN ($expr);

And the errors:
[WARNING] moor_generator:moor_generator on lib/src/database/db.dart:
Error while generating APIs for _testWhere1
Bad state: Unknown expression Instance of 'DartExpressionPlaceholder'
[WARNING] moor_generator:moor_generator on lib/src/database/db.dart:
Error while generating APIs for _testWhere2
Bad state: Unknown expression Instance of 'DartExpressionPlaceholder'
[WARNING] moor_generator:moor_generator on lib/src/database/db.dart:
Error while generating APIs for _testWhere3
Bad state: Unknown expression Instance of 'DartExpressionPlaceholder'
[WARNING] moor_generator:moor_generator on lib/src/database/db.dart:
Error while generating APIs for _testWhere4
Bad state: Unknown expression Instance of 'DartExpressionPlaceholder'
[INFO] Running build completed, took 216ms

With c95a3badb252d03f77a9172fd63de3a451ed50db the generator will accept all 4 without complaining. It should reject the third query though, because expanding that into an expression doesn't yield valid sql (I don't think we should generate a List<Expression> in that case - it would be a lot of additional work and the same thing can be achieved with the first query). Rejecting that should probably happen in the parser.

Yeah that makes sense to reject the third query.
I'm having a new issue with the same sample queries - the generator is now working correctly, but the generated code has some errors:
Selectable<TblData> _testWhere1(Expression<bool, BoolType> expr) {
  final generatedexpr = $write(expr);
  $arrayStartIndex += generatedexpr.amountOfVariables;
  return customSelectQuery('select * from tbl where ${generatedexpr.sql}',
      variables: [...generatedexpr.introducedVariables],
      readsFrom: {tbl}).map(_rowToTblData);
}

The Expression class and $arrayStartIndex variable are both undefined

Thanks for the report, it should work now. We report a syntax error for the third query, expose the Expression and Limit class from moor and make sure the $arrayStartIndex variable is present when it's needed.
We'll also print lints for the two problematic uses (query has a result column with an unknown type, name of the result column depends on a Dart template).


Improvements for components in storefront

Copying this from #2156.
Fixing the broken links in that issue but the rest should be looked at.
For zeroheight:

[ ]  Avatar - it doesn't exists in Components section, but there is documentation in Foundation section. Maybe there is a reason for it 🤔 ?
[ ]  Autocomplete - there is no documentation.
[ ]  Banner - got additional description &Text example is wrong is a repetition of Text and Icon example.
[ ]  Breadcrumbs - lack of links to rest of the examples.
[ ]  Button - i would link Icon button & Progress button & Full width examples.
[ ]  Card - got additional description & i would link With media & With divider examples.
[ ]  Chip - lack of links to rest of the examples.
[ ]  Dialog - lack of links to rest of the examples & the Demo view it doesn’t show well the example after triggering the Dialog.
[ ]  Divider - got additional description & lack of links to rest of the examples.
[ ]  Menu - link is broken & i would link Complex example.
[ ]  Paper - it does't exists in Components section, but there is documentation in Foundation as Elevation. Not sure if we need listed as a component 🤔 .
[ ]  Popover - i would link With Tooltip example.
[ ]  Progress:Dot - link is broken.
[ ]  Scrim - link is broken & got additional description.
[ ]  Search - link is broken & lack of links to rest of the examples.
[ ]  Select:Native - link is broken.
[ ]  Side Sheet - - link is broken & lack of links to rest of the examples & got additional description.
[ ]  Slider - lack of links to rest of the examples.
[ ]  Snackbar - got additional description.
[ ]  Table - got additional description.
[ ]  TableOfContent - link is broken.
[ ]  Tabs - the link might broke after the merge, maybe link more examples? And the most confusing is this: Tabs have a minimum width of Spacer/16 - Medium on each side of the label. we took it away from the storybook.
[ ]  TextField - lack of links to rest of the examples. The examples from Figma in Zeroheight are misleading because the helper text is overlapping with icon and another text.

Will wait for @lucasveil to return from vacay so we can discuss.

After meeting with @BeckyBrekke 08/09 I will fix the list and have Rebecca do a last review

The zeroheight fixes are good to go, will publish a new release soon so all the changes are pushed out.

TODO:

[ ]  Avatar - it doesn't exists in Components section, but there is documentation in Foundation section. Maybe there is a reason for it 🤔 ?
NOT DONE - relevant issue: #251 . @lucasveil works on new variants - relevant issues: #2252 #2270
[ ]  Autocomplete - there is no documentation.
NOT DONE

@lucasveil When I published the changes, none of the links in the "More examples available in the code tab" worked. @
https://app.zenhub.com/workspaces/equinor-design-system-604f57c09e350a0011b654f4/issues/equinor/design-system/2156
You did most of them, but I did some too and was pretty sure I did it the correct way. Can we look at it next week?

@lucasveil When I published the changes, none of the links in the "More examples available in the code tab" worked. @

Some links works, the only ones that didn't work i listed above.

The issue was that zeroheight made a redirect to the links in the CMS. I have now fixed all the url and it should work on the next publish @BeckyBrekke @martalalik

Looks good, small changes:
Fixed the link to storybook for the topbar.
Made the windows taller for the progress indicators to remove scrollbars
Bolded the period at the end of the sentence: "More examples available in the code tab." since the whole sentence was bold.


Spacing issue at the end of the create retire request screen on mobile version of Guardian

Problem description
Spacing issue at the end of the create retire request screen on mobile version of Guardian
Step to reproduce
Steps to reproduce the behavior:
1.Login as normal user
2.Click on the header and navigate to Tokens
3.Click on create retire request button
4.Scroll all the way down
5/Extra space is displayed at the end of create retire request screen
Expected behavior
Spacing issue to be aligned for create retire request screen on mobile version of guardian.
Screenshots

Issue is resolved


We no longer check any tic related repo on appveyor. GHA only.

Ah ok. Should i add gha files?

All other example tic repos only build on Travis for now. It's sufficient for us but you are of course free to add more to the bag :)


DailyWirePodcastProxy completely stopped working

This service worked great for me up until a little more than a week ago. I tried completely removing and re- installing the container but nothing worked.
Today I noticed the DW website UI quite drastically changed, which made me think they might have changed their backend too, causing their private API to break.
Am I the only one with this issue? And if not, is this project still maintained? I would love to have this working again

Mine has gone down too, unfortunately..

One problem is how I originally intercepted the login page via headless chrome. I don't run it in a container and I still have the same chrome version installed on my server, so it still runs for me (I just got a latest episode about an hour ago). I have some ideas for what needs to be done, so I'll start working on it soon.

One problem is how I originally intercepted the login page via headless chrome. I don't run it in a container and I still have the same chrome version installed on my server, so it still runs for me (I just got a latest episode about an hour ago). I have some ideas for what needs to be done, so I'll start working on it soon.

Interesting, that sounds very promising! Really hope you get this working again i was VERY happy about this service

The latest episode i see is the morning wire on the 25th of October. All evening shows that same day broke, those i have only until the 24th.

My logs suggest mine went down yesterday. It was a wall of text, but I had GPT analyse the error message:

This error suggests that there’s a misconfiguration issue with the dependency injection setup, specifically around the IGraphQLClient service, and it seems to be related to the Simple Injector and Microsoft.Extensions.DependencyInjection configurations. The error indicates that the program times out when attempting to retrieve IGraphQLClient, which may be related to either the network dependencies or the configuration of your DI (Dependency Injection) setup.

I would guess that your access token has expired, as that's been 99% of the cause of graphql error. Try deleting the tokens.dat file to force it to login again.

My logs suggest mine went down yesterday. It was a wall of text, but I had GPT analyse the error message:

I have the same error messages, also about IGraphQLClient

I would guess that your access token has expired, as that's been 99% of the cause of graphql errors. Try deleting the tokens.dat file to force it to login again.

I always delete tokens.dat when it goes down, but this time it doesn't take.

@samuelvisser Have you managed to make it work again? I've done a fresh install, tried both Linux and Windows versions, but same error on all.


Simplify draw signature for performance reasons

When using an entity pool, I discovered that the single largest source of allocations in Firefox (~90%) seemed to be instantiating the arguments object in the webgl draw method.
That method accepts optional arguments, but they're not used anywhere in Crafty, and I'm fairly certain they wouldn't work correctly if you tried to pass them in -- the signature and surrounding logic was cloned from the canvas implementation, and never cleaned up.
So

Remove the arguments completely from the webgl draw method.
Remove the reference to arguments.length from the canvas draw method, and simplify the signature

It was even causing deoptimizations in chrome. 👍


Create devcontainer.json

abukiis' projects Template_ Requests by Hostname - 2023-11-19 to 2023-11-21.json

@Abukiis Sorry your PRs are looking phishy, closing them.


WIP: Client metrics

First implementation for Java client metrics.

This change is

Pull Request Test Coverage Report for Build 3090

0 of 240 (0.0%) changed or added relevant lines in 5 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.9%) to 39.722%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

platform/dolphin-platform-core/src/main/java/com/canoo/dp/impl/platform/core/http/HttpClientConnection.java
0
12
0.0%

platform-extras/dolphin-platform-metrics-client/src/main/java/com/canoo/dp/impl/platform/client/metrics/MetricsServiceProvider.java
0
12
0.0%

platform-extras/dolphin-platform-metrics-server/src/main/java/com/canoo/dp/impl/platform/server/metrics/servlet/PrometheusPushGatewayProxyServlet.java
0
13
0.0%

platform-extras/dolphin-platform-metrics-client/src/main/java/com/canoo/dp/impl/platform/client/metrics/MetricsPush.java
0
50
0.0%

platform-extras/dolphin-platform-metrics-client/src/main/java/io/micrometer/prometheus/PrometheusPushMeterRegistry.java
0
153
0.0%

Totals

Change from base Build 3086:
-0.9%

Covered Lines:
4827

Relevant Lines:
12152

💛  - Coveralls


Limit splitting terminals to a max value

With latest release (1.21) you can split terminal infinitely. This breaks badly the terminal area.
Probably the IDE should limit this to a defined maximum or something?

I considered adding a max value but you would always be able to break it then by sizing down. As a mitigation we could disallow creating terminals if the desired room isn't there but the real fix is proper overflow behavior.

Thanks @Tyriar , I would agree that proper overflow behaviour is the way to go. Thanks!

I think the easiest way to improve this is to only allow terminals to be created if there's a reasonable amount of room. This can exist with our current lack of overflow behavior as it's an improvement on the current and will prevent 100 terminals from being created..

I suggest the minimum size of a terminal should be an option in Settings.


Can not delete a cluster with stopped VMs

Related to https://github.com/Azure/ARO-RP/issues/687
There are several flavours of this issue. We currently can not recover from cases 1 & 2.

When a cluster in failed state from where we can not run admin update. For example provisioningState=Failed and failedProvisioningState=Deleting (ref).
When a cluster is in succeded state, but VMs are stopped + we can not start them (in a suspended subscription, for example)
When a cluster is in succeded state, but VMs are stopped + we can start them (cluster was in suspended subscription, but it's no longer a case) - should be possible to recover and delete once we have a proper fix for https://github.com/Azure/ARO-RP/issues/687

RP panics with runtime error: index out of range [0] with length 0 here on line 30 (see full panic at the end).
https://github.com/Azure/ARO-RP/blob/64a15e5b607bb6d77f666ab88a088994262e8197/pkg/backend/openshiftcluster/delete.go#L28-L31
This happens because worker profile is a dynamic data which we receive from cluster's API server. When we can not reach the API server worker profile is not populated (nil).

pkg/util/recover/recover.go:19 recover.Panic() goroutine 314 [running]:
runtime/debug.Stack(0xc00042d110, 0x2, 0xc0006d1a08)
	/usr/local/go/src/runtime/debug/stack.go:24 +0x9d
github.com/Azure/ARO-RP/pkg/util/recover.Panic(0xc00042d110)
	/Users/mradchuk/workspace/src/github.com/Azure/ARO-RP/pkg/util/recover/recover.go:19 +0x9a
panic(0x65b1d80, 0xc000c73480)
	/usr/local/go/src/runtime/panic.go:679 +0x1b2
github.com/Azure/ARO-RP/pkg/backend/openshiftcluster.(*Manager).Delete(0xc002f7e300, 0x6d29f20, 0xc000c6e800, 0x1, 0x1)
	/Users/mradchuk/workspace/src/github.com/Azure/ARO-RP/pkg/backend/openshiftcluster/delete.go:30 +0xd20
github.com/Azure/ARO-RP/pkg/backend.(*openShiftClusterBackend).handle(0xc000118288, 0x6d29f60, 0xc0000d6000, 0xc00042d110, 0xc000400300, 0x0, 0x0)
	/Users/mradchuk/workspace/src/github.com/Azure/ARO-RP/pkg/backend/openshiftcluster.go:126 +0x33d
github.com/Azure/ARO-RP/pkg/backend.(*openShiftClusterBackend).try.func1(0xc00042d110, 0xc000118288, 0xc000400300)
	/Users/mradchuk/workspace/src/github.com/Azure/ARO-RP/pkg/backend/openshiftcluster.go:62 +0x121
created by github.com/Azure/ARO-RP/pkg/backend.(*openShiftClusterBackend).try
	/Users/mradchuk/workspace/src/github.com/Azure/ARO-RP/pkg/backend/openshiftcluster.go:49 +0x309

I don't think we don't call Enrich() on the backend currently?  What are the circumstances in which WorkerProfiles does not have length 1?
Possibly the logic here should walk the NSGs in the managed RG and make sure they are detached from any subnets so they can then be deleted.

@jim-minter hm, right we do not call Enrich() on backend. But in my db (RH subscription, v4-eastus RG) I somehow ended up with a document which does not have worker profiles. Wondering if there is a bug somewhere in front-end where we call Enrich and save the enriched document in DB... Need to try this:

Create a cluster
Stop VMs
Make sure that DB document has worker profiles field
Try to send an admin udpate (patch) request while VMs are powered off
Check DB

I'll try to reproduce it tomorrow.

My suspec is this bit:
https://github.com/Azure/ARO-RP/blob/64a15e5b607bb6d77f666ab88a088994262e8197/pkg/frontend/openshiftcluster_putorpatch.go#L110-L114
And below we have:
https://github.com/Azure/ARO-RP/blob/64a15e5b607bb6d77f666ab88a088994262e8197/pkg/frontend/openshiftcluster_putorpatch.go#L203

Makes sense.  In that case I think the delete code should iterate NSGs.

I agree on the priority.


⚠ Mobitopup has degraded performance

In 321a320, Mobitopup (https://napcard.voz.tech) experienced degraded performance:

HTTP code: 200
Response time: 3167 ms

Resolved: Mobitopup performance has improved in 2a1552c after 11 minutes.


Devnet -> Devnet2 to fix errors with manually deleted namespace

PR to match what's currently actually deployed for devnet

!approved-for-mainnet


feat: stripMine and goToSurface actions

Add stripMine action (see docstring)
Add goToSurface action (see docstring)
Added conversation_examples for these actions to andy.json
started breaking out scripts into individual files in the /scripts dir

@kolbytn  @MaxRobinsonTheGreat

Would be cool if you added the examples to all of the bots instead of just Andy, looks good so far.

I am closing this pr, sorry if you put a lot of work into it.
For now I want commands to be for rudimentary behaviors, stripMine is too complex. Long term I want complex/specific behaviors to be programmed by LLMs and saved as new commands, rather than be hard-coded by humans. stripMine is something like that.
goToSurface is more basic and useful, though I suspect it wouldn't work in a lot of cases. You could be in a deep chasm with nothing above you and think you're on the surface, or you could be in your house and think you're underground because the ceiling is above you.
If you open another pr with just gotosurface and your refactoring we can talk more about it. thanks


Remove python installer

Now that we have a shell one, which has fewer deps than the python, and now that all the documentation has been updated to point at install.sh, we should remove the python installer.

Should we have a deprecation period? Perhaps print a warning to stderr that it will be removed at some future date?

Yes that sounds good. I think by March 1, 2019 we can remove it.


Alignment Issue: Dialog Not Centering After Page Scroll

"The Dialog I'm Using Doesn't Center Immediately After Page Scroll, Remaining Stuck on Screen."

Could you please elaborate more on the issue, and how can one reproduce it?


More tests added.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

58 of 65 (89.23%)  changed or added relevant lines in 3 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage increased (+5.5%) to 91.878%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/Traits/ArrayViewAccessTrait.php
26
33
78.79%

Files with Coverage Reduction
New Missed Lines
%

src/Views/ArrayView.php
4
93.94%

Totals

Change from base Build<PHONE_NUMBER>:
5.5%

Covered Lines:
181

Relevant Lines:
197

💛  - Coveralls