Foreach: refactor from recursive to iterative implementation to keep stack depth constant

Prior to this change, ForEach action is recursive, adding 180 frames to the dotnet call stack, resulting in foreach over large collections throwing StackOverflowException. This recursive nature is, in part, created by the nature of how DialogContext works.
This PR changes ForEach to be iterative. Inheriting from action scope makes it not possible to have an iterative version because when a foreach has multiple turns, continue goes straight to the active action and foreach cannot resume. Instead, we use a method similar to how adaptive calls actions, by creating a child dialog context and iterating.
Also, there were bugs for multi-turn that got fixed in this PR.
Before change: Stack depth = ~180 * ElementCount in collection. For 100 elements, stack depth = 180*100 = 18000
After change: Stack depth = < 203 in the same dataset. For 100 elements, stack depth = 203

Pull Request Test Coverage Report for Build 280927

0 of 0   changed or added relevant lines in 0 files are covered.
57 unchanged lines in 4 files lost coverage.
Overall coverage decreased (-0.1%) to 78.638%

Files with Coverage Reduction
New Missed Lines
%

/libraries/AdaptiveExpressions/BuiltinFunctions/GetNextViableTime.cs
1
90.91%

/libraries/AdaptiveExpressions/BuiltinFunctions/GetPreviousViableTime.cs
2
90.91%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Actions/ActionScope.cs
3
96.34%

/libraries/Microsoft.Bot.Builder.Dialogs.Adaptive/Actions/ForEach.cs
51
0%

Totals

Change from base Build 280796:
-0.1%

Covered Lines:
24815

Relevant Lines:
31556

💛  - Coveralls


Custom printer name setup in config

What would you like to see added?
When the printer is started, the first message is "printer online".
I have multi printers, all with there own klipper environment. But also with there own hardware. Both give the first message "printer online"
Would like to modify the name "printer" so that i know which one is online.
Tried in mainsail to modify the printer name, but that isn't send in the telegram messages

Don't you use individual bots? In my case, I have named the bot corresponding to my printer, which gives me a nice notification:

No, i use 1 bot for all. It is also used for my home automation. This gives me all information in 1 bot view.
I know that i can't use the commands from telegram, to control the printer. Because more environments are lissening to the same bot. But i think that has nothing to do with the name "printer online"

So if I've understood correctly, something like this?

Yes, that is exactly the idea.
If i see it correctly, it is waiting for approve, to get merged?

Be aware that sending commands by telegram doesn't work then. If you are adware for this and don't use it, then it is no problem

We do not support and will never support multiple bots per instance. This is insanity, do you want to run one klipper/moonraker instance for multiple printers as well? All that to not create an additional bot via botfather? :D
If you want to aggregate notifications in a single place, you can use a group, as suggested above.
Progress on control from a group will be tracked in #283.
@Altblechkutscher You are welcome to open a PR request, this is a nice fun little option, if you think it has value. On our side nothing speaks

@aka13-404 Indeed I did, which you can see here  #https://github.com/nlef/moonraker-telegram-bot/pull/302


Use GitHub Workflow to Release/Publish

For easier maintenance it would be great if the release/publish was done through a GitHub Workflow. Ideally the release process should also be documented (e.g. https://github.com/zaproxy/zaproxy/blob/main/RELEASING.md).

You can use this reusable workflow of ours: https://github.com/Lombiq/GitHub-Actions/blob/dev/.github/workflows/publish-nuget.yml Or take it as an inspiration.


Having multiple pie charts in overview data

What feature do you want to see added?
In overview, we have only 1 pie chart for 3 column (from example).
Sometimes, each columns are independant data and it would be good to have 1 pie chart for each columns (kind of option to force or not single pie chart)
Upstream changes
No response

It could be done by an option:

for example "independantColumn = True" will consider that columns are independant (in overview, data won't be sume and each column will have 1 pie chart)


gh-2 created classes for Bot related objects in the bootcommand module

created classes for Bot related objects in the bootcommand module #6
deleted the bot-related files

This is really good. sorry I had taken long to review this. on the next pull request, please ping me using @ht-thomas or ask me to review by clicking the review button so that I get notified quickly


[Storage] az storage blob directory move: Fix the problem that the directory fails to move when the source path contains spaces (#1277)

Issue: #1277

This checklist is used to make sure that common guidelines for a pull request are followed.

For new extensions:

[ ] My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish
There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

add to S169

@Juliehzl please help review this PR.


Unable to parse jmod files

Context: https://stackoverflow.com/a/64202720
JDK 9 added a new .jmod file format, which appears to be "normal ZIP" with a { 4a 4d 01 00 } file header.  These files are able to be ready by unzip -l.
For example, if you have a xamarin-android build environment, then you have a JDK 11 provisioned, which contains .jmod files:
% unzip -l $HOME/android-toolchain/jdk-11/jmods/java.base.jmod  | grep /Object.class
warning [/Users/jon/android-toolchain/jdk-11/jmods/java.base.jmod]:  4 extra bytes at beginning or within zipfile
  (attempting to process anyway)
     1944  01-22-2021 19:28   classes/java/lang/Object.class

unzip is also able to extract the file contents:
% unzip $HOME/android-toolchain/jdk-11/jmods/java.base.jmod classes/java/lang/Object.class
Archive:  /Users/jon/android-toolchain/jdk-11/jmods/java.base.jmod
warning [/Users/jon/android-toolchain/jdk-11/jmods/java.base.jmod]:  4 extra bytes at beginning or within zipfile
  (attempting to process anyway)
  inflating: classes/java/lang/Object.class

% echo $?
1

Odd that unzip sets an error exit code, though…. The file does exist:
% ls -lh classes/java/lang/Object.class
-rw-r--r--  1 jon  staff   1.9K Jan 22  2021 classes/java/lang/Object.class

Regardless, attempting to process this file with LibZipSharp results in an error:
% csharp -r:path/to/libZipSharp.dll
using System.IO;
using Xamarin.Tools.Zip;

var a = ZipArchive.Open(Path.Combine(Environment.GetEnvironmentVariable("HOME"), "android-toolchain/jdk-11/jmods/java.base.jmod"), FileMode.Open);
// Xamarin.Tools.Zip.ZipIOException: The file '$HOME/android-toolchain/jdk-11/jmods/java.base.jmod' is not a ZIP archive.
//   at Xamarin.Tools.Zip.ZipArchive.Open (System.String path, System.IO.FileMode mode, System.String defaultExtractionDir, System.Boolean strictConsistencyChecks, Xamarin.Tools.Zip.IPlatformOptions options)
// …

.jmod support was implemented without needing libZipSharp changes: https://github.com/xamarin/Java.Interop/commit/8ccb8374d242490d8d1b032f2c8ca7a813fd40f3
Closing…


[Question]: How to right structure the data? (Company chat history)

Question Validation

[X] I have searched both the documentation and discord for an answer.

Question
Hello, we're trying to use our support chat history (from our database) to feed the llama_index, right now I've exported all the data to a JSON file and put it on the "data" folder (millions of lines). But I was wondering how will the AI know what is the customer question vs what is the chat attendant answer? Is there a way to send like an index for each phrase (QUESTION:, ANSWER:)?

you may need to write your own data loader and add that info manually.
It's pretty easy actually! Just load the JSON in python, iterate over it, and manually create Document objects
Full guide on documents here: https://gpt-index.readthedocs.io/en/latest/core_modules/data_modules/documents_and_nodes/usage_documents.html


Random start points option for profiled POIs

This PR adds an option --pointsRandProf to MultiDimFit.

The purpose of this option is to try to avoid finding and getting stuck in the wrong minima, as discussed in these slides.
If the option takes as input the number of random starting points to try for the profiled POIs in the n==1 case of the doGrid() function. If the option can be disabled by either not specifying the option, or by specifying 0 for the number of points.
This technical details of this approach are probably not implemented in an optimal way, so I'd be very happy to improve the implementation based on any suggestions and corrections that the combine experts would have.

Thank you!

I start running some test. The automatic ones run w/o this option on, but I think it is still a useful thing to assess.

As mentioned above, if it's not too difficult, it could be better to put this code into a new class in a separate .cc file, which could then be called by MultiDimFit when the extra command line option is added. MultiDimFit is already due a clean up in the near future, and I think this would make things easier to maintain.

Thank you @adewit and @ajgilbert for the reviews. We're working on addressing the comments, and will get back to you as soon as possible. However, we're a bit swamped with work on other areas of our analysis right now, so it might take us a few weeks. But if this timeframe would present an issue for eventually moving forward with merging this PR (e.g. if other large changes to this section of the code are expected soon), please let us know and we attempt to get it done more quickly. Thanks!

Hi @kmohrman, no problem from our side I think - we're usually pretty slow getting our own developments in. Will let you know if/when a big refactor of MultiDimFit is imminent.

Hi, thanks again for the reviews of this PR. Sorry for our long silence, things have been very busy with other parts of our analysis. We're now pushing through the final stages, and have run into a few things we wanted to add to this PR in order to make this random starting point method work better for our analysis.
Anyway, just wanted to give a heads up that we'll be pushing a few changes to this branch, and wanted to say sorry in advance for the noise!

As mentioned above, if it's not too difficult, it could be better to put this code into a new class in a separate .cc file, which could then be called by MultiDimFit when the extra command line option is added. MultiDimFit is already due a clean up in the near future, and I think this would make things easier to maintain.

Hi @ajgilbert and @adewit, we apologize for a very long delay in addressing the comments in this PR. I have taken over the remaining work on this project from @kmohrman. To begin with, I recently pushed some changes that include a new class that contains all the relevant functions used in random starting point implementation. This new class implementation works fine as expected.

Hi, my apologies for the noise, but since it has been a couple of weeks since I last pushed the updates, I was just wondering if anyone has had a chance to review the latest changes. Please let me know if there are any comments, and I would be happy to work more towards improving the random start point algorithm. Thank you.

Hi @abasnet97, sorry for the delay. The first issue is that since you started the developments, we have switched to a new default branch of combine (main) and there a quite a few updates since you branched off. I changed the target branch for this PR, and now there are some conflicts - can you check these? In the meantime I will try and understand the proposed changes

Hi @ajgilbert, thank you for getting back, and no worries for the delay. Yes, main seems to have quite a lot of changes that this branch is not up to date with, so I will have to spend some time checking these. Unfortunately, I do not have a lot of time currently to dedicate towards this, but I will try to allocate some time for this. Again, thank you, and let me know once you finish reviewing the proposed changes.

Hi @ajgilbert, my apologies for a delayed response to this. At this point, I have resolved the merge conflicts that arose after we switched the target branch to main. Fortunately, it was not as tedious as I had expected it to be. I was also wondering if you have had a chance to review the random starting point class implementation and/or if you have any comments on that?

Hi @abasnet97, sorry for the delay. The first issue is that since you started the developments, we have switched to a new default branch of combine (main) and there a quite a few updates since you branched off. I changed the target branch for this PR, and now there are some conflicts - can you check these? In the meantime I will try and understand the proposed changes

Hi @ajgilbert, sorry for the noise. I was wondering what the status of the review is. Let me know if you have had a chance to work on this and if you have any comments.

I tried compiling under CMSSW_11_3_4 and i'm hitting compilation errors at src/MultiDimFit.cc:712 . Unfortunately, the automatic checks are using CMSSW_10_2 which seem to pass. @abasnet97 , can you confirm which CMSSW version you have been testing your PR with?

I tried compiling under CMSSW_11_3_4 and i'm hitting compilation errors at src/MultiDimFit.cc:712 . Unfortunately, the automatic checks are using CMSSW_10_2 which seem to pass. @abasnet97 , can you confirm which CMSSW version you have been testing your PR with?

@nucleosynthesis, looks like I am using CMSSW_10_2_13.

I tried compiling under CMSSW_11_3_4 and i'm hitting compilation errors at src/MultiDimFit.cc:712 . Unfortunately, the automatic checks are using CMSSW_10_2 which seem to pass. @abasnet97 , can you confirm which CMSSW version you have been testing your PR with?

Hi @nucleosynthesis , I wanted to follow-up to see if there has been any development on this front. Were there some issues with cmssw release mismatch?

Hi Again,
apologies for the delay in responding. @abasnet97 - can you try to compile under CMSSW_11_3_4 and see if there is a way to fix the errors? Let us know if you get stuck
All the best,
Nick

Hi Again,
apologies for the delay in responding. @abasnet97 - can you try to compile under CMSSW_11_3_4 and see if there is a way to fix the errors? Let us know if you get stuck
All the best, Nick

Hi @nucleosynthesis, after fixing some errors, I can now compile the repo using CMSSW_11_3_4. I have also merged all recent changes from main to this branch.

Just adding @anigamova and @kcormi here to keep CAT-stats in the loop.

I think this looks ok, but I'd really like to test it. @abasnet97  - can you provide an example command that will work with one of our tutorial datacards?
For example, if you try the following,
cd data/tutorials/CAT23001
text2workspace.py multi-signal-datacard.txt -P HiggsAnalysis.CombinedLimit.PhysicsModel:floatingXSHiggs --PO modes=ggH,qqH -o  multi-signal-datacard.root --mass 125
combine multi-signal-datacard.root --pointsRandProf=20  --parameters r_ggH -v 9 -M MultiDimFit --floatOtherPOI=1

When I try the above, I don't see the multiple fits being performed that I would have expected - can you try and see if there's edits to the command line that would make it work?
Nick

Hi @abasnet97 ,
Right of course, I missed that the grid algo is needed since this is only intended for scans (though I wonder why this wouldn't also be useful for the global fit part to make sure the correct global minimum is found)
Anyway I'll try with the --grid added,
Thanks
Nick

Ok, adding the --algo grid option seems to work. I noticed (again using the tutorial card) that there are many cases where the parameter values go to regions where the pdfs no longer make sense. I tried setting the range of the parameters to stop this, but it seems the random starting values don't respect these ranges - is that intended, did you check that setting the range of the parameters is respected by the random value setting?

Hi @nucleosynthesis, a quick question. When you say:

I tried setting the range of the parameters to stop this, but it seems the random starting values don't respect these ranges

What command line option are you talking about?

Here is the command I tried, where I was seeing the errors
combine multi-signal-datacard.root --parameters r_ggH  -M MultiDimFit --floatOtherPOI=1 --algo grid --points 5 --setParameterRanges r_ggH=0,10:r_qqH=0,10 --pointsRandPro=2

Here is the command I tried, where I was seeing the errors
combine multi-signal-datacard.root --parameters r_ggH -M MultiDimFit --floatOtherPOI=1 --algo grid --points 5 --setParameterRanges r_ggH=0,10:r_qqH=0,10 --pointsRandPro=2
(note, as per my earlier comment, you can create this workspace via
cd data/tutorials/CAT23001

text2workspace.py multi-signal-datacard.txt -P HiggsAnalysis.CombinedLimit.PhysicsModel:floatingXSHiggs --PO modes=ggH,qqH -o  multi-signal-datacard.root --mass 125

)

Ok let me try this quick.

Hi @nucleosynthesis, so I tested your command. And yes, I did see those warnings.
However, I want to mention that there also exists a command line option called --randPointsRanges, which allows one to set the range from which the random start points are chosen for the profiled parameters. By default, this is set to -20,20. So when I tried something like:
combine multi-signal-datacard.root --parameters r_ggH -M MultiDimFit --floatOtherPOI=1 --algo grid --points 5 --setParameterRanges r_ggH=0,10:r_qqH=0,10 --pointsRandProf=2 --randPointsRanges r_ggH=-1,1:r_qqH=-1,1
I saw significantly less number of warnings. Now, what range to pick for these random start points are of course specific to each parameters, so my dummy values might not have been the best range.

Thanks for checking - I think its not great to have a separate option to set these ranges, nor to use -20,20 as the default (what if the POI was a mass variable for example).
Given most physics model define sensible default ranges, I would remove the --randPointsRanges and simply use the existing ranges on each parameter (this can be obtained using the RooRealVar::getMin() and RooRealVar::getMax() methods. That way, if the user specifies a new range with --setParameterRanges, the ranges will be taken from that - I think this behaviour would be much better.

Thanks for checking - I think its not great to have a separate option to set these ranges, nor to use -20,20 as the default (what if the POI was a mass variable for example).
Given most physics model define sensible default ranges, I would remove the --randPointsRanges and simply use the existing ranges on each parameter (this can be obtained using the RooRealVar::getMin() and RooRealVar::getMax() methods. That way, if the user specifies a new range with --setParameterRanges, the ranges will be taken from that - I think this behaviour would be much better.

Hi @nucleosynthesis, thank you for the comments. I agree that your suggestion would be a possibility. However, in some cases (e.g. TOP-22-006, which was the use case this PR was developed for), we believe it is useful to have a separate option for specifying the ranges from which to draw the random points. I think the following reasons contribute to the usefulness of the --randPointsRanges  option:

It can be very computationally expensive to create the work space (up to ~7hr for the case of TOP-22-006) so it makes sense to define in the model very large ranges for the parameters. E.g. for TOP-22-006 we defined something like -200 to 200 for all 26 POIs (which is much larger than needed for all POIs). This is because ranges in the model that turn out to be too large are not detrimental, whereas ranges that are too small may result in needing to remake the workspace. Thus the ranges we define in the model are generally much larger than the ranges we would like the random starting points to be drawn from.
Since the ranges for the POIs in these EFT fits are not known ahead of time (and it is not convenient or efficient to remake the workspace every time one would like to adjust the ranges explored for starting points for the profiled POIs), it is very useful to have the flexibility to be able to set the ranges of the profiled POIs at the time of the fit.
Another use case for the dedicated --randPointsRanges is the ability to explore a certain subset of ranges of starting points. E.g. if one happens to know something about how the topology of the space (e.g. from a higher dimensional scan) and one wishes to explore a scenario around a particular minima, it may be useful to be able to restrict the range of the random starting points for that POI (or subset of PIOs) to a particular range one has in mind.

For these reasons, we would prefer to keep the --randPointsRanges option in place, though we would of course be very interested to hear your thoughts on the above comments as well.
Thanks!

The point is that the ranges for the parameters are already modifiable in the command line using --setParameterRanges. I don't see an argument for having another option that clashes with this one and is only used specifically to set the allowed ranges for the random initialisation since either

the parameter is set to some value within the range (which then will cause an issue if the range is larger than the one currently set for the parameter) or
the parameter range is adjusted by the --randPointsRanges which overrides the range set by the user,

either of the above will just cause confusion and moreover will spoil setting the ranges used in the fit for the parameter. Unless there is a specific reason to have a different range for the random starting point vs that allowed in the fit, I really think we need to avoid introducing this extra option.

After thinking about and discussing your points, we agree that a clash between --setParameterRanges and --randPointsRanges is undesirable and could cause confusion to the users. So we agree that the behavior should aim to avoid such clashes. However, we still feel that having a --randPointsRanges option is useful in cases where the user would like to explore certain subsets of ranges for starting point values. E.g. a user may wish to explore what happens when starting points are chosen to be near some local minima, but the user might not want to restrict the POI to stay within that small range (i.e. the user may wish to allow the POI to float to a different minima if it is able to, even if that minima is outside of the range specified in --randPointsRanges).
To this end, we would propose the following:

We would like to keep the --randPointsRanges option
But we would set up the behavior such that --randPointsRanges would never override the max and min values already in place for the POI (which are set by either --setParameterRanges and/or specified in the physics model)
We can add a comment to the help string for --randPointsRanges that would mention that this range should be equal to or smaller than the max and min values already in place for the POIs (and that if a random starting point larger/smaller than these max/min is requested, it will not be respected)

We are wondering if you would have  thoughts on this proposal?

This sounds ok to me, but please consider changing the name of the option to something more informative than --randPointsRanges (i.e like something I suggested previously).

That name (--setParameterRandomInitialValueRages) sounds fine to us. Thank you for all of the feedback on this option and its functionality. We will proceed with making the changes discussed above.

Hi @nucleosynthesis, I have implemented the changes that @kmohrman described in [https://github.com/cms-analysis/HiggsAnalysis-CombinedLimit/pull/713#issuecomment-1907304823](this comment). And like you suggested, I have also edited the name of the CLI option to be a bit less confusing.


Feature/improve quick search

Fixes

Improve quick search functionality by searching more columns in the database as well as using wildcards and "like" in the queries

Description

Add psycopg2 package and set up connection with Supabase
Change query to a raw SQL query to add additional columns to filter with both on the search term and county name
Incorporate an NLP (spaCy) to depluralize search term values

can you rename "county" to "location" as it has expanded?

Just resolved all your comments. Let me know what you think @mbodeantor


Ver 7.x - Edit Gunsmith Details on Walther P22

Got the following error when attempting to edit details on the Walther P22, and nothing comes up in the window
frmViewCollectionDetails.LoadMaintData::5::TotalRoundsFired::BurnSoft.Applications.MGC.Global.DatabaseRelated.GetTotal - Object cannot be cast from DBNull to other types.

Might be while view details of the Walther, Added work to Glock 17, no error, attempted to edit, no data returned and no error


[ENSCORESW-3683] Software/Schema Release Version Update to 106

Requirements

Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion;
Review the contributing guidelines for this repository; remember in particular:

do not modify code without testing for regression
provide simple unit tests to test the changes
if you change the schema you must patch the test databases as well, see Updating the schema
the PR must not fail unit testing

Description
As part of Core Release Activity 1, update the software and schema release versions from 105 to 106.
Use case
After the REST code branching, the software and schema release versions on the master branch of this repo require updating for the subsequent release (i.e. 106).
Benefits
N/A
Possible Drawbacks
N/A
Testing
Have you added/modified unit tests to test the changes?
No.
If so, do the tests pass/fail?
Tests are currently failing because some tests are not expecting a version mismatch between release 105 and 106.
Have you run the entire test suite and no regression was detected?

Changes include increment in ApiVersion as well as SQL patch file
All test databases have been updated with new release version, as per SOP
SQLlite build fails with issues getting the Compara checkout, unrelated to this PR
MySQL build fails because it is trying to compare releases 104 and 105, as 106 is now yet available on a main branch
This should get resolved once the PR is merged into master

Coverage increased (+0.06%) to 82.388% when pulling 31fb38b981c29a56410e4e6b685a864a7ea9bbb9 on version_update_and_schema_patches into 79219ffbe07fd59602c355d1faf6e498348f6ff4 on master.


Issues with Handling Different Encoding Formats & Prompt Structures

Dear authors,
Thanks very much for your generous and valuable contributions to this project! When I was trying to hack the code, I discovered a few minor issues. I listed all of them below:
1. Error when indexing files with encoding formats other than 'gbk'
When I try to run the code as per the instruction of readme.md with mock_data.txt as input (which is encoded as "utf-8-sig"), an error occurs in the indexing stage:
While following the instructions in readme.md and using mock_data.txt (which is encoded as "utf-8-sig") as input, I encountered an error during the indexing stage. The error output has been shown below:
...
⠸ Processed 93 communities
INFO:httpx:HTTP Request: POST https://api.openai.com/v1/chat/completions "HTTP/1.1 200 OK"
INFO:nano-graphrag:Writing graph with 678 nodes, 563 edges
Traceback (most recent call last):
  File "D:\GraphRAG\nano-graphrag\tests\test.py", line 9, in <module>
    graph_func.insert(f.read())
  File "D:\GraphRAG\nano-graphrag\nano_graphrag\graphrag.py", line 169, in insert
    return loop.run_until_complete(self.ainsert(string_or_strings))
  File "C:\Users\lenovo\AppData\Local\Programs\Python\Python310\lib\asyncio\base_events.py", line 641, in run_until_complete
    return future.result()
  File "D:\GraphRAG\nano-graphrag\nano_graphrag\graphrag.py", line 274, in ainsert
    await self._insert_done()
  File "D:\GraphRAG\nano-graphrag\nano_graphrag\graphrag.py", line 289, in _insert_done
    await asyncio.gather(*tasks)
  File "D:\GraphRAG\nano-graphrag\nano_graphrag\_storage.py", line 37, in index_done_callback
    write_json(self._data, self._file_name)
  File "D:\GraphRAG\nano-graphrag\nano_graphrag\_utils.py", line 74, in write_json
    json.dump(json_obj, f, indent=2, ensure_ascii=False)
  File "C:\Users\lenovo\AppData\Local\Programs\Python\Python310\lib\json\__init__.py", line 180, in dump
    fp.write(chunk)
UnicodeEncodeError: 'gbk' codec can't encode character '\u2122' in position 170847: illegal multibyte sequence

In my case, I fixed it by simply modifying the write_json function to make its written format align with the input file format:
def write_json(json_obj, file_name):
    with open(file_name, "w") as f:
        json.dump(json_obj, f, indent=2, ensure_ascii=False)

I don't expect this to fully resolve the whole issue as it doesn't apply to all encoding formats. Perhaps we could find a more flexible solution that can handle various encoding formats for the input text file.
2. issues with csv-formatted prompts
Specifically, in the function async def _build_local_query_context in _op.py, I noticed that the strings communities_context and text_units_context are designed to follow the .csv format. However, while each cell represents the content of a multiline text chunk or a community summary, the cells are not enclosed in double quotes. For example, the string looks like this:
index, content
1, xxx
    xxx
    xxx
2, yyy
    yyy
    yyy
...

While I think the following looks more formal as the .csv format, if it contains multiple lines:
index, content
1, "xxx
    xxx
    xxx"
2, "yyy
    yyy
    yyy"
...

In contrast, other strings like entities_context and relations_context are correctly enclosed in quotes to preserve cell boundaries. Although this is a minor issue, I am concerned that it might lead to potential problems, such as misrecognition by LLMs.

That's the full description. Wish this project continued growth!

Hi, thank for you enthusiasm
For the first issue: sorry I don't find the differences between the implementation and your  fixed version
https://github.com/gusye1234/nano-graphrag/blob/681667963c0f6fbedef53e5dbb6786ac64b2634d/nano_graphrag/_utils.py#L71-L73
Maybe you copy the before implementation not your fix?
For the second issue: Yeah, I think that's a problem. We should enclose multi-line cell.

Hi, thank for you enthusiasm For the first issue: sorry I don't find the differences between the implementation and your fixed version
https://github.com/gusye1234/nano-graphrag/blob/681667963c0f6fbedef53e5dbb6786ac64b2634d/nano_graphrag/_utils.py#L71-L73
Maybe you copy the before implementation not your fix?
For the second issue: Yeah, I think that's a problem. We should enclose multi-line cell.

For issue 1: sry for making a mistake here. See the latest update: the fixed version is
def write_json(json_obj, file_name):
    with open(file_name, "w", encoding="utf-8-sig") as f:
        json.dump(json_obj, f, indent=2, ensure_ascii=False)


Remove the selection border after the handle was moved

Is it possible to remove the selection border after the handle was moved?

It's possible but not recommended as highlighting the focused element is useful for visually impaired users: http://www.outlinenone.com/


Electron spitting out errors

Believe this is an electron error, after hours of testing.

Turns out I was running with node, should've been running with electron...


Make the application name translatable

While I was doing the Brazilian Portuguese translation I realized that the application name on the page title and on the navbar couldn't be translated. Since it is a descriptive name, I think it would be nice for it to be translatable.

I don't think it's a good idea. I prefer to left it untranslatable as static project name.

To me it sounds more like a descriptive name than a brand. Also, it has already been translated to French and Spanish (in the title.homepage message).

I'm also divided about this. Using "Symfony Demo Application" for all languages is better for our branding. But displaying "Symfony Demo Application" in any language different from English may seem weird.
I definitely need to read more opinions from other developers. Let's see what does the community think about this.

After musing about this issue, I think it's better to maintain the "Symfony Demo" name for all languages. However, I also think we can improve the current situation. Right now we call this app the "Symfony Demo Application". We could rename it just to "Symfony Demo" application.
Before

After

Before

After

Great compromise! It's much more clearer. I like it :+1:

The changes have been done in #101.

Nice! 👍


Bugfix for decoder: t() -> transpose()

probably an issue of pytorch versioning

@emanjavacas Related to the last bug, this is something else I fixed in the PR, patch is in isolation this way.
Feel free to bump to 0.2.7 or whatever ?

I remember seeing this merged already, indeed. Anyway I will merge.

@emanjavacas Pretty sure same fix, but different decoder :D


Re-export hyper Request

The field Request.request is a hyper::server::request::Request. Please consider re-exporting (pub use) that type (e.g. as HyperRequest) in your API, so that users don't have to add an explicit dependency on a specific version of Hyper.

If we are doing that,  we might need to re-export everything else too, not a good idea.  For now I think it is ok for one application to depend on a specific version of Hyper if the app needs it.  If there are any better solutions, please wake me up :)

Iron is also re-exporting Hyper types.

The problem is that the user needs to update the version of Hyper every time he/she updates pencil (even for a minor version). And to be able to do that, one needs to look at the source repository at that version to see the exact dependency requirement.

I would propose to do the entire opposite: hide hyper as much as possible and only give access to it through well hidden APIs. Hyper will undergo big changes going forward from what I can tell and the typed high level access is actually really inconvenient as a user.
I would propose to find the places where one currently needs to get the hyper object and instead to provide convenience APIs to avoid it.  For instance there should be a header view for the request to access the header values a strings.  Likewise there should be a way to set and view response headers as strings without having to interface with hyper as well.
Ideally in the public API hyper is entirely invisible.
WRT version mismatches: cargo is planning on coming up with a story for such public API re-exports so this will get easier going forward.

Hide hyper as much as possible, we should try to do this better.

I think I agree with @mitsuhiko.


Flutter macOS close button shouldn't quit the app

Use case
Most macOS apps, on clicking the close button at top-left of the window, just hides the app.
But flutter closes the app completely. Is it possible to just hide the app by changing some settings?
Proposal
Not sure if there is a way to already change this flow but if not, it will be good to have one.

Most macOS apps, on clicking the close button at top-left of the window, just hides the app.

This is not accurate; I have never seen a single macOS application with this behavior, in fact. macOS convention is:

multi-window applications keep running after closing the last window, and activating the app with no open windows opens a new one. (This is likely what you are thinking of, but hiding an application on macOS is completely different from closing all windows.)
single-window applications quit when closing the last window.

flutter create currently makes a single-window application.

But flutter closes the app completely. Is it possible to just hide the app by changing some settings?

You can remove the applicationShouldTerminateAfterLastWindowClosed override in your application if you are making a multi-window application, or want to violate platform conventions for some reason.

@stuartmorgan thanks for the reply but I did notice many popular apps like github desktop, todoist etc don't quit completely when clicked on the close button(even though it's the last window).
I tried changing applicationShouldTerminateAfterLastWindowClosed to false and the app does stay in background on clicking close but when I click on the app from dock, it won't open again.
Is it possible to make it exactly how "github desktop" does it i.e on close, the app is hidden but doesn't quit completely and when you click on the app icon from dock, it opens immediately.

@stuartmorgan thanks for the reply but I did notice many popular apps like github desktop, todoist etc don't quit completely when clicked on the close button(even though it's the last window).

Please re-read my comment. I didn't say that applications should quit when their last window closes, I said that applications that are designed as single-window applications should quit when their window is closed.
If the applications you are referring to allow opening windows beyond the first, they are behaving as expected. If not, they are violating platform conventions.

when I click on the app from dock, it won't open again.

Yes, because you would need to handle the appropriate application delegate methods and open a new window, just as in any other macOS application.

Is it possible to make it exactly how "github desktop" does it i.e on close, the app is hidden but doesn't quit completely and when you click on the app icon from dock, it opens immediately.

Again, the app is not hidden in that scenario. Being hidden is a specific state for a macOS application; it is not equivalent to having no windows open.

@stuartmorgan thanks for the detailed explanation.

Again, the app is not hidden in that scenario. Being hidden is a specific state for a macOS application; it is not equivalent to having no windows open.
Is it possible to override the close button with hide state in macOS. I am not sure if this can be on Flutter side and I don't know enough macOS development. Can you pls point me in the right direction?

There is currently no delegation of window events to Dart in the macOS embedding (there's an issue tracking that). You would need to do so in native code.


Graph Application doc needs to be updated to clarify client credential flow

Client credential flow is not supported in this scenario. As per the doc it should be working. Quoting the document statement here that needs to be updated - "Although the OAuth 2.0 client credentials grant flow is not currently directly supported by the Azure AD B2C authentication service, you can set up client credential flow using Azure AD and the Microsoft identity platform /token endpoint for an application in your Azure AD B2C tenant. An Azure AD B2C tenant shares some functionality with Azure AD enterprise tenants." Could reproduce the issue on our end using Postman with client credential flow. The issue is not reproducible in MS Graph Explorer which uses Auth_Code grant flow.

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

ID: 45fe2896-2630-fcfa-97ed-c11f5bcdeb26
Version Independent ID: fa30e08e-3f8e-0305-a061-6d3e74bbd5de
Content: Register a Microsoft Graph application - Azure AD B2C
Content Source: articles/active-directory-b2c/microsoft-graph-get-started.md
Service: active-directory
Sub-service: b2c
GitHub Login: @msmimart
Microsoft Alias: mimart

@JJ Thank you for your feedback . We will have this reviewed and update the thread.

@JJ Thank you for your feedback . We will have this reviewed and update the thread.


Failing to run globalroute for MegaBoom on Nangate45.

Description
For one of our projects, we used OpenROAD and ran P&R for MegaBoom on Nangate45. We found that even after reducing the floorplan utilization to 20%, OpenROAD fails to run global routing. We have updated the fastroute.tcl file to allow more routing resources than the default. It would be good if you could suggest some solutions or enhance your global route engine to fix the problem.
We have uploaded the CTS, DEF, Verilog, and SDC files that were the input to the global route stage. We use the default Nangate 45 lef and lib available  in the ORFS GitHub.
Please let us know if you have any suggestions to fix the problem, and if you need any more information to debug it further.
Thanks,
Sayak
Suggested Solution
No response
Additional Context
No response

Using the macro.mod.lef to get the TAP cell to load def and then display the RUDY routeablilty heat map  ..
OpenROAD-flow-scripts/flow/platforms/nangate45/lef/NangateOpenCellLibrary.tech.lef, created 22 layers, 27 vias
OpenROAD-flow-scripts/flow/platforms/nangate45/lef/NangateOpenCellLibrary.macro.mod.lef, created 135 library cells
This doesn't look like a GRT problem at all, this looks like GIGO, a bad netlist being unplaceable.
Simply querying the instances in the dark middle of the chip shows "regfile" as instance names.
Just synthesizing the abstract description of the "regfile" of a VLIW will not get you a placeable netlist.
Maybe physical synthesis tools got better over the last couple of years, but a regular structure like a regfile
will at the very least need careful attention to the structure of the muxes and very likely some data path placement.
You'll have to isolate the muxes in separate RTL hierarchy and script the placement of the sequential elements.

I've seen this behavior a few times before when I synthesized a register file. I noticed that during global placement the register file would get to densities much greater than requested (90+%, even when the density requirement is set to 40%). The commercial tools struggle with this too, but the placement density they achieve is usually around 70%.
I would suggest taking a look at the global placement step maybe try turning off routabilty driven placement since that appears to be when the density climbs up.

@sakundu Have you considered looking at https://github.com/The-OpenROAD-Project/megaboom ?
The register files and SRAMs will probably have to be crafted in some way that is outside the scope of OpenROAD and then provided to OpenROAD as macros.
What I do w.r.t. register files and SRAMs is that I "mock" them, which you can read more about in https://github.com/The-OpenROAD-Project/megaboom.
Basically, I create a macro that is an area and timing representation of the register file (to be provided by some non-OpenROAD means later), which allows me to run the rest of the design through OpenROAD to look for issues.
Since nangate45 isn't a production process anyway, perhaps you don't need anything more than mock register files and srams?

https://github.com/bespoke-silicon-group/bsg_fakeram
Is a good place to start if you're trying to generate rams

https://github.com/jjcherry56/bsg_fakeram might be better

https://github.com/bespoke-silicon-group/bsg_fakeram
Is a good place to start if you're trying to generate rams

This wont work for Megaboom to create e.g. the registerfiles and many other SRAMs because there is a mismatch between the module interface and what these tools produce.
As a start, I recommend mocking these modules as described in the megaboom repository.
Mocking is much more general and can also handle cases such as mocking multipliers, barrel shifters, reorderbuffers or really anything.

@oharboe that's true of most SRAMs even foundry provided ones. The user is expected to wrap them in their own logic. For BIST, ECC or whatever.
Mocking is also valid, but you're giving up accuracy, which is valid if you don't need that level of detail.

@oharboe that's true of most SRAMs even foundry provided ones. The user is expected to wrap them in their own logic. For BIST, ECC or whatever.
Mocking is also valid, but you're giving up accuracy, which is valid if you don't need that level of detail.

Indeed... mocking is a stop gap useful in early iterations of setting up a flow. You can explore what the problems the design runs into with an close zero latency SRAM and maybe tinker a bit with the verilog.to.mock something closer to realistic. Area can also be mocked(smaller and bigger). However, mocking will not give you any insights into what constitutes realistic latency and area...
Though for Megaboom on nangate45 as a starting proposition, I dont think physical realism is being studied, would be my guess...

@oharboe that's true of most SRAMs even foundry provided ones. The user is expected to wrap them in their own logic. For BIST, ECC or whatever.
Mocking is also valid, but you're giving up accuracy, which is valid if you don't need that level of detail.

If you do want to target a real PDK, then the starting point is not the currently generated Verilog, but Chipyard. Chipyard can be fed the available SRAMs and then it will generate the bridging logic to connect Megaboom to avaialable SRAMs. This is called Barstools. I am not familiar with it...


Submission

[ ] author contributions are checked by all
[ ] acknowledgements are completed by all authors
[x] affiliation/ORCID etc. are correct

@sje30 Since we make a new submission, should do it to become corresponding author?
It would of course be welcome if you can help out with a cover letter again.

@nuest I'm not familiar with CRediT, what do you  need me to do?

@vsoch You have taken a look at the contribution section, and already fixed the roles, so you're good.

Timeline
Let's target Wed May 20 as a deadline for the visual summary and changes to the text. Then, everyone will have one week to take another look at the full draft to comply with the authorship requirements and I will submit on May 29.

Author contributions
"I have checked and approve the assigned roles in the author contributions", see https://github.com/nuest/ten-simple-rules-dockerfiles/blob/master/ten-simple-rules-dockerfiles.Rmd#L827

[ ] @vsoch
[ ] @nuest
[ ] @sje30
[ ] @betatim
[ ] @psychemedia
[ ] @benmarwick
[ ] @bdevans

Deadline looks good to me.

Author contributions
"I have checked and approve the contents of the final revision of the article", see Version 4 of preprint at https://osf.io/fsd7t/
(The only expected change before submission: visual summary figure by @bdevans.)

[ ] @vsoch
[ ] @sje30
[ ] @betatim
[ ] @psychemedia
[ ] @benmarwick
[ ] @bdevans
[ ] @nuest

Hi @nuest, I've checked off my name above in anticipation of merging PR #86. These will hopefully be the final changes before submission! 🥳

@bdevans thanks for joining this paper, this is an excellent example of open collaboration!

It's been a pleasure @sje30 - thanks to all for including me! 😊

@psychemedia friendly ping! I hope you find the time to give the text another read, because there were significant changes since we've last conversed on the paper, and I still found a few small mistakes this morning.

@nuest APols for tardiness; I've ticked off required checkboxes and made some minor language change suggestions in branch th-final-comments if you want to cherry pick any of them.

They look like good edits to me @psychemedia - would you like to submit them as a PR so that they can be merged into the main repo?

Thanks everyone! I'll keep you posted on the next steps.

Preprint updated base on the Travis CI rendering, now at version 5: https://osf.io/download/5e9964fbf135350557d5a298/?version=5&displayName=ten-simple-rules-dockerfiles-2020-06-16T10%3A28%3A50.369Z.pdf


Support for on-premises repositories, like TFS/TFVS.

Describe the solution you'd like
We currently use Azure DevOps Server for version control and would like to use App Center build and test module to build and test our Xamarin.iOS and Xamarin.Android Apps.
Describe alternatives you've considered
None at the moment.
Additional context

Thanks for this feature request @lxshertz! We'll keep this open to track interest for the future.

How can this still be an outstanding issue with App Center?  I just migrated a couple of my hockeyapp mobile apps over to App Center, and I'm no longer able to access my source controlled files in Azure DevOps (TFVC repo)???  If we are being forced off HockeyApp, shouldn't the functionality of the latest option be the same or better?

Hi @tonykchan, what specific functionalilty are you looking for that is available in HockeyApp related to this? This feature request is around the Build/CI service which isn't available in HockeyApp and is an additional service in App Center.

I think that what we need here is to be able to connect an App Center app to a 'Azure DevOps Server' (on-premises) repository. At this moment only 'Azure DevOps' (cloud) is allowed.
Is there any update on this?

@farlop, no update on this at the moment. We're continuing to track interest in this feature request.

@nrajpurkar  We are currently using Hockey App, but there is no path forward with App Center with our on-prem TFS.

@msallmen can you be specific about what scenarios you are blocked on coming from HockeyApp? This issue refers to Build support requiring on-premises repo support, but HockeyApp didn't have a build service. Thanks!

This feature should be a minimum. We are using TFS locally here and we can't use AppCenter to distribute our apps because of this.

What we ended up doing is building locally in Azure DevOps Server and then push the resulting apk to App Center

Very odd that tfs isn't supported. This would be very beneficial.

Agreed, we need on premise support for app center.

@nilofer any news on this request??? even gitlab(self-hosted) has support for app center.

I no longer work on App Center. Tagging in @elamalani to provide further answers.


Installation on Ubuntu 22.04

Is there a way to install the gateway as a service on Ubuntu 22.04?
Any hint to documentation or how to build a custom package would be appreciated.
Thanks and regards,
Michael

Hi @mbrohl,
From my point of view, you can proceed on Ubuntu 22.04 using the container image.
In addition, you setup a systemd service that manage the container (see the following blog for example: https://blog.container-solutions.com/running-docker-containers-with-systemd).
That said, there is a work-in-progress PR to support DEB package: https://github.com/rchakode/hugo-mx-gateway/pull/10.
Take a look and feel free to improve it.
R.

Thanks for the pointer, @rchakode !
The PR currently only contains some documentation changes, i cannot see any code or configuration towards debian packaging there. But I can see that there is a package for Ubuntu kinetic (https://packages.ubuntu.com/search?suite=default&section=all&arch=any&keywords=hugo-mx-gateway&searchon=names)
Where can I find the code for Debian packaging of the gateway?
One final question: does the gateway support fileupload/mail attachments?
If yes, I will go an try to get it to run on the Ubuntu server.

I think the package is there : https://packages.debian.org/bookworm/hugo-mx-gateway
Again this is a WIP, as you can see the person that have proposed the PR does not finish it yet.
About the attachment, that was not included in the initial design goals. That said, feel free to contribute such a feature.


Add protobuf-subscriber command

Add cli utility subscribing to a given topic on the mqtt broker and decoding the protobuf payload.
Timestamp, sequence number and values are printed in human readable format to stdout.

809285aa251504fc9f4e339bd95a3970a062743c Reverts the crpytopgraphy bump to restore compatiblity on the gateway


Hiding pending tag for anon

And some css color change that still will need some work

Coverage decreased (-0.05%) to 24.015% when pulling 6aca11a7e2dffa1b739a4b7ecb31103fff040a46 on Kiloutre:patch-32 into b21a09b9d4674417fafd6a15434a73af89038358 on NyaaPantsu:tags.

Coverage decreased (-0.05%) to 24.015% when pulling dd09888aa1e5e552fa3fbb557797796622875393 on Kiloutre:patch-32 into b21a09b9d4674417fafd6a15434a73af89038358 on NyaaPantsu:tags.

Coverage decreased (-0.05%) to 24.015% when pulling dd09888aa1e5e552fa3fbb557797796622875393 on Kiloutre:patch-32 into b21a09b9d4674417fafd6a15434a73af89038358 on NyaaPantsu:tags.


Docker: add volume information

Small addition to the README and documentation regarding persitence of anna when running in docker.
Signed-off-by: Tim Beermann<EMAIL_ADDRESS>

Thank you for the PR!


Chore/refactor to multi currency setup

This PR is a huge refactoring to our discussed multi-currency setup.

[x] One api namespace per currency like api.etc.getSyncProgress and api.ada.getSyncProgress
[x] All apis are available at the same time (that's why you can start the app with API=etc npm run dev now and it only uses etc stuff for the loading page but ada for the rest. This will change as soon as we start to swap out containers to build etc specific versions)
[x] All currency specific stores are namespaced under their currency (e.g: stores.ada.wallets
[x] We can reuse / share logic on all layers:

api: flow types and common errors can be shared in api/common.js
stores: The first level of stores is currency agnostic and can use environment.API to access currency specific universal apis like getSyncProgress (see example in the NetworkStatusStore)
components: loaded as implemented by nikola (components in sub-folders override generic ones)

I think with this setup we can start working on the etc client for real 😉

@darko-mijic acceptance tests are fixed now (although sending money does not work 100% correctly with the backend at commit 516641351cdf510ddbc894ebce1793381cbf4489) - from my side this PR is now ready for review and merging 👍

@DominikGuzei actions namespacing is now also done and all acceptance-tests are green. We are ready for the merge 🎉

Great work @nikolaglumac 👍  merging now 🎉


Anomalous Mass With FAR

If I install only this mod - everything is fine. If I also add FAR, the mass doubles (in simplest case), but, depending on the setting of strenght/mass and if vessel has many Pwing parts, in some cases, mass may even become negative (stock wings behaves normally). This problem occurs only in this fork, in the original B9 Aerospace mass seems to be behaving normally with FAR.
Reproduction on fresh KSP 1.0.5:
1)Install FAR and this mod (I used CKAN)
2)Go to SPH
3)Create new vessel consisting of one light part(I use FL-T100 Fuel Tank)
4)Attach B9 PW Procedural Wing to tank
5)Right click on wing and notice curWingMass, it has to be approximately 0.75
6)See in engineer`s report window that vessel mass is 1.5 tons
Wrong mass calculations affect CoM position, but I dont know, how it affect vessel in flight...

Crzyrndm, please, explain to noob, what this code do? What is "GetModuleMass" method needed for?
public float GetModuleMass(float defaultMass)
{
    return part.mass - part.partInfo.partPrefab.mass;
}

I rebuild your project without this, and mass calculatios seems to be normal... I do this because original B9 Pwings code not conain this, but it already contains in FAR.

it's a place holder that was added for stock support. Looks like it needs to return 0 for FAR though. Will fix

Fixed


records vs recordings

Isn't it most appropriate "recordings" name path than "records", or like openATV "movie"?

At the moment this is not necessary. Due to this problem, It will probably made some refactoring and changes in path handling. I think it will be possible to take into account your proposal.


The Helm Install docs in the API Aggregation Setup don't work on a Mac

The helm install command in this section don't work on a mac. They produce the following error output:
admins-MacBook-Pro:service-catalog aaschles$ helm install charts/catalog     --name ${HELM_NAME} --namespace ${SVCCAT_NAMESPACE}     --set apiserver.auth.enabled=true         --set useAggregator=true         --set apiserver.tls.ca=$(base64 --wrap 0 ${SC_SERVING_CA})         --set apiserver.tls.cert=$(base64 --wrap 0 ${SC_SERVING_CERT})         --set apiserver.tls.key=$(base64 --wrap 0 ${SC_SERVING_KEY})
base64: unrecognized option `--wrap'
Usage:	base64 [-hvD] [-b num] [-i in_file] [-o out_file]
  -h, --help     display this message
  -D, --decode   decodes input
  -b, --break    break encoded string into num character lines
  -i, --input    input file (default: "-" for stdin)
  -o, --output   output file (default: "-" for stdout)
base64: unrecognized option `--wrap'
Usage:	base64 [-hvD] [-b num] [-i in_file] [-o out_file]
  -h, --help     display this message
  -D, --decode   decodes input
  -b, --break    break encoded string into num character lines
  -i, --input    input file (default: "-" for stdin)
  -o, --output   output file (default: "-" for stdout)
base64: unrecognized option `--wrap'
Usage:	base64 [-hvD] [-b num] [-i in_file] [-o out_file]
  -h, --help     display this message
  -D, --decode   decodes input
  -b, --break    break encoded string into num character lines
  -i, --input    input file (default: "-" for stdin)
  -o, --output   output file (default: "-" for stdout)
Error: a release named "catalog" already exists.
Please run: helm ls --all "catalog"; helm del --help

gnu base64 (linux) vs bsd base64 (mac).
We can say, run it on linux, or run it on gnu base64, but since it's a user run thing, we probably have to figure out how to use bsd base64 and tell the user what they might need to run.

@MHBauer see how I fixed this in #1005

@MHBauer update: I closed #1005 without merge. We can't say that this must be run only on linux.
I can think of a few options:

Enable people to run the helm command in a container
Enable people to run the base64 command in a container
Do the base64 encoding inside the helm chart (I did this in #1005)

Use the stringData field in secret and you won't have to b64 encode anything
On Mon, Aug 28, 2017 at 5:47 PM Aaron Schlesinger<EMAIL_ADDRESS>wrote:

@MHBauer https://github.com/mhbauer update: I closed #1005
https://github.com/kubernetes-incubator/service-catalog/pull/1005
without merge. We can't say that this must be run only on linux.
I can think of a few options:

Enable people to run the helm command in a container
Enable people to run the base64 command in a container
Do the base64 encoding inside the helm chart (I did this in #1005
https://github.com/kubernetes-incubator/service-catalog/pull/1005)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes-incubator/service-catalog/issues/1004#issuecomment-325492585,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAWXmEYhkN8WR_N3tSyX2ZVSsaJNDsTqks5sczVSgaJpZM4OMjUk
.

@pmorie the files have newlines in them - do you know another good way to pass them in on the helm CLI?


Remove REPO_URL from Docker build script

This should fix the Docker build

@shumkov note: We still get [Warning] One or more build-args [npm_token] were not consumed in the output of the Docker build. Do we still need it?

@shumkov I also removed NPM_TOKEN per above b/c the Dockerfile is not using it any more. Can you re-review?


Spinners wrong pos/human_pos/per_sec after .finish()

Spinners display a very large (incorrect) number when .finish()ed if {pos}/{human_pos}/{per_sec} are included in the style template.
From the source code, I see that when calling .finish() the pos is set to the len of the ProgressState. When creating a new_spinner though, this len is set to !0, which I have never seen in Rust, but calling .finish() displays a very large number that looks like an unsigned underflow or an uninitialized integer.
An easy way to get around this is to use .abandon() which doesn't override pos with len.

Actually, calling .abandon() displays a correct pos but per_sec is still corrupted.
The workaround I found for this is to do ::new(0).with_style(ProgressStyle::default_spinner()... and then inc_length along with every inc. This way len is the same as pos at all times, which keeps things clean. In this case .finish() works as intended, .abandon() is no longer needed.
But yeah, this is obviously quite cumbersom.

Please have a look at #415 and test if it fixes your issues.

This problem still seems to exist in the latest version.

@stackinspector sorry for the slow response -- would you be able to come up with a minimal reproduction scenario, ideally as a unit test?


Strip spaces from fields in enrollment from CSV

Just had a case where a student didn't get scores on bCourses because they had a space after their SID.

Forms are supposed to strip whitespace for text fields by default thanks to https://github.com/Cal-CS-61A-Staff/ok/blob/master/server/forms.py#L120 - not sure how that happened.

CSV most likely? Updated the title.

These are the lines that we should look at: https://github.com/Cal-CS-61A-Staff/ok/blob/master/server/models.py#L854
Should be as simple as doing a .strip()


UnboundLocalError: cannot access local variable 'font_scale_factor' where it is not associated with a value

Is anyone know how to solve this?
Thanks

Do you have the traceback available?


My graphs broke from 2.0.2 to 2.1.0. Follow semver?

I had ^2.0.2 in my package.json, so when running a clean npm install I got the new 2.1.0
and my chart went from working

to not working (I've set black on the points so we can see them)

The fill doesn't seem to work at all. Any ideas why?
This line in the release notes is telling me you don't follow semver which I really think you should.
I used those in my code so that broke, but I've fixed that so it doesn't seem related to the chart looking weird.

You can now share data between charts. Note that this will require changes if dataset.metadata or dataset.metaDataset were being used. There is now a helper function to retrieve the correct meta data for a given dataset

And right when I posted I figured it out.
I had to rename tension to lineTension here:
elements: {
    line: {
        lineTension: 0,
    },
}

Didn't think I needed to do that. Again semver

The old options will still work in this release.
Renamed dataset tension property to lineTension

hi @olyckne
I'm sorry that we broke your chart(s). We may have, wrongly, assumed that not many people were using the meta objects yet. We are committed to keeping the config fully backwards compatible and we don't forsee needing any changes in stuff like this again.
Regarding your tension issue, I have just merged #2473 which fixes them and am preparing for v2.1.1 release that will include those fixes.

I guess that is a fair assumptions to make though. Sometimes you're wrong :)
Glad I noticed it before we did a new release, and it was a pretty easy fix.
Any idea why the chart suddently isn't taking up the whole canvas?
It makes my really small chart look a lot different.
Guess it might be something with the axes that I've set to display: false, but they're still taking up space?
2.0.2:

2.1.0:

@olyckne looks like that is getting set at https://github.com/chartjs/Chart.js/blob/master/src/core/core.scale.js#L281
We can either add a check for display: false or you could set the following in the scale config
{
  gridLines: {
    tickMarkLength: 0
  }
}

Thanks!
tickMarkLength: 0 works, but I think taking display: false into account makes sense.

@olyckne v2.1.1 released with the tension fix included. I will work on the display: false sizing shortly


Failure to update the number of error/warning in the file when a record is updated.

Have added code to test3 that adjusts the count of warning messages during correction when validating.
Irrespective of this the coordinator should always reprocess the file at the end of validation and before incorporation


Can't draw fullscreen on Android phone with notch

Steps to Reproduce
Flutter app doesn't draw fullscreen on Android phones with a notch. I tried all the combinations of window flags and Flutter setEnabledSystemUIOverlays.

I can either use SystemChrome.setEnabledSystemUIOverlays([]); or WindowManager.LayoutParams.FLAG_FULLSCREEN which will result in app completely ignoring top area around notch:

Or I can use WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS which will make it draw around notch area but it doesn't hide the status bar

Target Platform: Android with a notch
Devices: tried with 2 physical devices and emulator
Logs
[✓] Flutter (Channel master, v1.9.8-pre.3, on Mac OS X 10.14.6 18G1012, locale en-HR)
• Flutter version 1.9.8-pre.3 at /Users/jokr/Downloads/flutter
• Framework revision d67f47b21e (3 months ago), 2019-08-29 11:28:04 -0700
• Engine revision f52c0b9270
• Dart version 2.5.0
[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
• Android SDK at /Users/jokr/Library/Android/sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-29, build-tools 28.0.3
• ANDROID_HOME = /Users/jokr/Library/Android/sdk
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 10.2.1, Build version 10E1001
• CocoaPods version 1.7.2
[✓] Android Studio (version 3.5)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin version 41.1.2
• Dart plugin version 191.8593
• Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

Hi @itsJoKr
could you please run  flutter upgrade
If the issue persist please provide your updated flutter doctor -v
thank you

Sure. I can report that after the upgrade issue is still present.

Normal app with just blue background

With WindowManager.LayoutParams.FLAG_LAYOUT_NO_LIMITS

With WindowManager.LayoutParams.FLAG_FULLSCREEN or SystemChrome.setEnabledSystemUIOverlays([]);

Logs
[✓] Flutter (Channel master, v1.13.1-pre.63, on Mac OS X 10.14.6 18G1012, locale en-HR)
• Flutter version 1.13.1-pre.63 at /Users/jokr/Downloads/flutter
• Framework revision 5e06984854 (6 hours ago), 2019-12-09 04:54:33 -0500
• Engine revision 4beaa696fc
• Dart version 2.7.0 (build 2.7.0-dev.2.1 a9c77229c2)
[✓] Android toolchain - develop for Android devices (Android SDK version 28.0.3)
• Android SDK at /Users/jokr/Library/Android/sdk
• Android NDK location not configured (optional; useful for native profiling support)
• Platform android-29, build-tools 28.0.3
• ANDROID_HOME = /Users/jokr/Library/Android/sdk
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 10.2.1)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 10.2.1, Build version 10E1001
• CocoaPods version 1.7.2
[✓] Android Studio (version 3.5)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin version 41.1.2
• Dart plugin version 191.8593
• Java version OpenJDK Runtime Environment (build 1.8.0_202-release-1483-b49-5587405)

This may be a regression already being tracked in #47683, which was bisected to #44369
cc/ @blasten

@itsJoKr can you help me out? on #53056

I am not using WindowManager.LayoutParams.FLAG_FULLSCREEN or SystemChrome.setEnabledSystemUIOverlays([]);, but still have the black area near the notch on my screen

Has this problem been solved? I also encountered this problem.
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Align(
          alignment: Alignment.topLeft,
          child: Image.network("https://shorturl.at/otCU9")),
    );
  }
}

I hope the picture will start to show from the red square. How to solve.

Has this problem been solved? I also encountered this problem.
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Align(
          alignment: Alignment.topLeft,
          child: Image.network("https://shorturl.at/otCU9")),
    );
  }
}

I hope the picture will start to show from the red square. How to solve.

Seems to have just happened to me also after upgrading to Android 10!

Adding this to the styles.xml helped me
<item name="android:windowLayoutInDisplayCutoutMode">shortEdges</item>

@xster I'm going to remove the milestone from this since it doesn't look like anyone is assigned.

Adding this to the styles.xml helped me
<item name="android:windowLayoutInDisplayCutoutMode">shortEdges</item>

how can i revert it to default on the next page ?
there is no option to alter style.XML programmatically

after use this code
<item name="android:windowLayoutInDisplayCutoutMode">shortEdges</item>

flutter can show as fullscreen，but the safeArea is doesn't work

is there any solution to this through dart?

is there any solution to this through dart?

@GaryQian maybe you have some ideas

@GaryQian maybe you have some ideas

i fix this problem, in styles.xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- Theme applied to the Android Window while the process is starting -->
    <style name="LaunchTheme" parent="@android:style/Theme.Black.NoTitleBar">
        <!-- Show a splash screen on the activity. Automatically removed when
             Flutter draws its first frame -->
        <item name="android:windowBackground">@drawable/launch_background</item>
    </style>
    <!-- Theme applied to the Android Window as soon as the process has started.
         This theme determines the color of the Android Window while your
         Flutter UI initializes, as well as behind your Flutter UI while its
         running.

         This Theme is only used starting with V2 of Flutter's Android embedding. -->
    <style name="NormalTheme" parent="@android:style/Theme.Black.NoTitleBar">
        <item name="android:windowBackground">@android:color/white</item>
    </style>
</resources>

i think problem was in popular package: flutter_native_splash: ^0.2.5

i fix this problem, in styles.xml
<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- Theme applied to the Android Window while the process is starting -->
    <style name="LaunchTheme" parent="@android:style/Theme.Black.NoTitleBar">
        <!-- Show a splash screen on the activity. Automatically removed when
             Flutter draws its first frame -->
        <item name="android:windowBackground">@drawable/launch_background</item>
    </style>
    <!-- Theme applied to the Android Window as soon as the process has started.
         This theme determines the color of the Android Window while your
         Flutter UI initializes, as well as behind your Flutter UI while its
         running.

         This Theme is only used starting with V2 of Flutter's Android embedding. -->
    <style name="NormalTheme" parent="@android:style/Theme.Black.NoTitleBar">
        <item name="android:windowBackground">@android:color/white</item>
    </style>
</resources>

i think problem was in popular package: flutter_native_splash: ^0.2.5

Verified this on latest stable and master and using below code changes, we can draw fullscreen on Android phone that has notch. (ex : tested on Pixel 3XL emulator).

Add SystemChrome.setEnabledSystemUIOverlays([]);
Add <item name="android:windowLayoutInDisplayCutoutMode">shortEdges</item> in styles.xml as mentioned in https://github.com/flutter/flutter/issues/46486#issuecomment-654796115.

With above, a sample image is rendered full screen as shown:

 code sample
void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    SystemChrome.setEnabledSystemUIOverlays([]);
    return MaterialApp(
      home: Scaffold(
      //  backgroundColor: Colors.blue,
        body: new Image.network(
          "https://picsum.photos/250?image=9",
          fit: BoxFit.cover,
          height: double.infinity,
          width: double.infinity,
          alignment: Alignment.center,
        ),
      ),
    );
  }
}

flutter doctor -v
[✓] Flutter (Channel stable, 1.22.6, on Mac OS X 10.15.4 19E2269 darwin-x64,
    locale en-IN)
    • Flutter version 1.22.6 at /Users/dhs/documents/Fluttersdk/flutter
    • Framework revision 9b2d32b605 (6 days ago), 2021-01-22 14:36:39 -0800
    • Engine revision 2f0af37152
    • Dart version 2.10.5

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/dhs/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.9.3

[!] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.52.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (2 available)
    • SM A260G (mobile)            • 5200763ebcfa861f • android-arm • Android
      8.1.0 (API 27)
    • AOSP on IA Emulator (mobile) • emulator-5554    • android-x86 • Android 9
      (API 28) (emulator)

! Doctor found issues in 1 category.

[✓] Flutter (Channel master, 1.26.0-13.0.pre.229, on Mac OS X 10.15.4 19E2269
    darwin-x64, locale en-IN)
    • Flutter version 1.26.0-13.0.pre.229 at
      /Users/dhs/documents/Fluttersdk/flutter
    • Framework revision 650b240634 (5 hours ago), 2021-01-27 21:39:06 -0800
    • Engine revision 68cd4c42b5
    • Dart version 2.12.0 (build 2.12.0-267.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/dhs/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[!] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    ! CocoaPods 1.9.3 out of date (1.10.0 is recommended).
        CocoaPods is used to retrieve the iOS and macOS platform side's plugin
        code that responds to your plugin usage on the Dart side.
        Without CocoaPods, plugins will not work on iOS or macOS.
        For more info, see https://flutter.dev/platform-plugins
      To upgrade see
      https://guides.cocoapods.org/using/getting-started.html#installation for
      instructions.

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.52.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (4 available)
    • SM A260G (mobile)            • 5200763ebcfa861f • android-arm    • Android
      8.1.0 (API 27)
    • AOSP on IA Emulator (mobile) • emulator-5554    • android-x86    • Android
      9 (API 28) (emulator)
    • macOS (desktop)              • macos            • darwin-x64     • Mac OS
      X 10.15.4 19E2269 darwin-x64
    • Chrome (web)                 • chrome           • web-javascript • Google
      Chrome 88.0.4324.96

! Doctor found issues in 1 category.

Closing this as fixed. If anyone disagrees, write in comments and I'll reopen it.

Verified this on latest stable and master and using below code changes, we can draw fullscreen on Android phone that has notch. (ex : tested on Pixel 3XL emulator).

Add SystemChrome.setEnabledSystemUIOverlays([]);
Add <item name="android:windowLayoutInDisplayCutoutMode">shortEdges</item> in styles.xml as mentioned in https://github.com/flutter/flutter/issues/46486#issuecomment-654796115.

With above, a sample image is rendered full screen as shown:

 code sample
void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    SystemChrome.setEnabledSystemUIOverlays([]);
    return MaterialApp(
      home: Scaffold(
      //  backgroundColor: Colors.blue,
        body: new Image.network(
          "https://picsum.photos/250?image=9",
          fit: BoxFit.cover,
          height: double.infinity,
          width: double.infinity,
          alignment: Alignment.center,
        ),
      ),
    );
  }
}

flutter doctor -v
[✓] Flutter (Channel stable, 1.22.6, on Mac OS X 10.15.4 19E2269 darwin-x64,
    locale en-IN)
    • Flutter version 1.22.6 at /Users/dhs/documents/Fluttersdk/flutter
    • Framework revision 9b2d32b605 (6 days ago), 2021-01-22 14:36:39 -0800
    • Engine revision 2f0af37152
    • Dart version 2.10.5

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/dhs/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.3)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.9.3

[!] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    ✗ Flutter plugin not installed; this adds Flutter specific functionality.
    ✗ Dart plugin not installed; this adds Dart specific functionality.
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.52.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (2 available)
    • SM A260G (mobile)            • 5200763ebcfa861f • android-arm • Android
      8.1.0 (API 27)
    • AOSP on IA Emulator (mobile) • emulator-5554    • android-x86 • Android 9
      (API 28) (emulator)

! Doctor found issues in 1 category.

[✓] Flutter (Channel master, 1.26.0-13.0.pre.229, on Mac OS X 10.15.4 19E2269
    darwin-x64, locale en-IN)
    • Flutter version 1.26.0-13.0.pre.229 at
      /Users/dhs/documents/Fluttersdk/flutter
    • Framework revision 650b240634 (5 hours ago), 2021-01-27 21:39:06 -0800
    • Engine revision 68cd4c42b5
    • Dart version 2.12.0 (build 2.12.0-267.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/dhs/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[!] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    ! CocoaPods 1.9.3 out of date (1.10.0 is recommended).
        CocoaPods is used to retrieve the iOS and macOS platform side's plugin
        code that responds to your plugin usage on the Dart side.
        Without CocoaPods, plugins will not work on iOS or macOS.
        For more info, see https://flutter.dev/platform-plugins
      To upgrade see
      https://guides.cocoapods.org/using/getting-started.html#installation for
      instructions.

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.52.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.16.0

[✓] Connected device (4 available)
    • SM A260G (mobile)            • 5200763ebcfa861f • android-arm    • Android
      8.1.0 (API 27)
    • AOSP on IA Emulator (mobile) • emulator-5554    • android-x86    • Android
      9 (API 28) (emulator)
    • macOS (desktop)              • macos            • darwin-x64     • Mac OS
      X 10.15.4 19E2269 darwin-x64
    • Chrome (web)                 • chrome           • web-javascript • Google
      Chrome 88.0.4324.96

! Doctor found issues in 1 category.

Closing this as fixed. If anyone disagrees, write in comments and I'll reopen it.

@darshankawar I tried your solution and it does extend the screen to the edges, but it creates another problem, the widget SafeArea stops working.

flutter doctor -v
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 2.0.1, on macOS 11.1 20C69 darwin-x64, locale pt)
[!] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    ! Some Android licenses not accepted.  To resolve this, run: flutter doctor --android-licenses
[✓] Xcode - develop for iOS and macOS
[✓] Chrome - develop for the web
[✓] Android Studio (version 4.0)
[✓] VS Code (version 1.54.2)
[✓] Connected device (3 available)

! Doctor found issues in 1 category.
leonardosilva@MacBook-Pro-de-Leonardo versus % flutter doctor -v
[✓] Flutter (Channel stable, 2.0.1, on macOS 11.1 20C69 darwin-x64, locale pt)
    • Flutter version 2.0.1 at /Users/leonardosilva/development/flutter/flutter
    • Framework revision c5a4b4029c (11 days ago), 2021-03-04 09:47:48 -0800
    • Engine revision 40441def69
    • Dart version 2.12.0

[!] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
    • Android SDK at /Users/leonardosilva/Library/Android/sdk
    • Platform android-30, build-tools 30.0.0
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
    ! Some Android licenses not accepted.  To resolve this, run: flutter doctor --android-licenses

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.3, Build version 12C33
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.0)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin version 49.0.2
    • Dart plugin version 193.7547
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.54.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.20.0

[✓] Connected device (4 available)
    • moto g 9 play (mobile)      •<PHONE_NUMBER>                               • android-arm64  • Android 10 (API 29)
    • iPhone de Leonardo (mobile) • ac197a55a52fbad3d364054a4c99dbe29ed46b23 • ios            • iOS 14.3
    • macOS (desktop)             • macos                                    • darwin-x64     • macOS 11.1 20C69 darwin-x64
    • Chrome (web)                • chrome                                   • web-javascript • Google Chrome 89.0.4389.82
    ! Error: iPhone de Leonardo is busy: Copying cache files from device. Xcode will continue when iPhone de Leonardo is finished. (code -10)

! Doctor found issues in 1 category.


VMware vFabric GemFire

Hi, Please accept DB implementation for GemFire. I have added documentation to db/gemfire/lib/README.txt. Please let me know if this should move.

Hi sbawaska,
We recently changed DB API to use ByteIterator instead of String for field values. Could you update your driver?
https://github.com/brianfrankcooper/YCSB/blob/master/src/com/yahoo/ycsb/DB.java
https://github.com/brianfrankcooper/YCSB/blob/master/src/com/yahoo/ycsb/ByteIterator.java
Thanks!
--Michi

Hi Michi,
I have made changes to accomodate ByteIterator. Please let me know if you need anything else.
Thanks,
Swapnil.

HI Swapnil,
Sorry it took a while to get back to you.

Could you pull changes from the master branch one more time and resubmit the pull request?
It would be great if you can add gemfire to Makefile ( https://github.com/brianfrankcooper/YCSB/blob/master/Makefile ).

Thanks!
--Michi

Hi Michi,
I just completed both these changes. Let me know if there is anything else.
Thanks,
Swapnil.

Merged to the master branch. Sorry it took me a while to get to this, and thank you for the patch!
--Michi

Hi sbawaska,
We are working on mavenizing YCSB, and we are having trouble with GemFire repository:
https://github.com/brianfrankcooper/YCSB/pull/64#issuecomment-4019735
Do you happen to know who I should talk to about the maven repository?
Thanks!
--Michi

I will get back to you in a couple of days
On Feb 17, 2012 2:21 PM, "Michi Mutsuzaki" <
<EMAIL_ADDRESS>wrote:

Hi sbawaska,
We are working on mavenizing YCSB, and we are having trouble with GemFire
repository:
https://github.com/brianfrankcooper/YCSB/pull/64#issuecomment-4019735
Do you happen to know who I should talk to about the maven repository?
Thanks!
--Michi

Reply to this email directly or view it on GitHub:
https://github.com/brianfrankcooper/YCSB/pull/55#issuecomment-4028948

Hi sbawaska,
Thank you for your reply. It looks like I was specifying a wrong version of GemFire in the pom.xml. It's working now.
Thanks!
--Michi


Update the wooting.rules file

The following update allows more keyboards to be used by wootility. Rules were fetched from this site  https://help.wooting.io/en/article/wootility-configuring-device-access-for-wootility-under-linux-udev-rules-r6lb2o/
Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] 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.05 Release Notes (or backporting 22.11 Release notes)

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

[ ] Fits CONTRIBUTING.md.

Check the contributing guidelines for the commit message format

Check the contributing guidelines for the commit message format

Will do, apologies for the inconvenience


Bump version (v1.8.3-rc.2)

Right now BrowserStack has a problem with starting iPhone 7 used in tests. I'll fix the build before the next release.


Is there plan for schedualing strategies like binpack?

As exists in Swarm?
in the readme:
Strategies: The project currently ships with a spread strategy which will attempt to schedule tasks on the least loaded nodes, provided they meet the constraints and resource requirements.
but no mention about roadmap

We will be working on additional scheduling strategies in the near future.
We'll start by focusing on strategies that optimize on "safety" (e.g. High Availability) rather than bin pack at first.
/cc @aaronlehmann

Moved HA scheduling to 1.13 in #1034

should probably be https://github.com/docker/swarmkit/issues/308


Fix ValuesValidator for params wrapped in with block

This PR fixes a bug #2376 in Grape's ValuesValidator, specifically when parameters are nested within a with block. Previously, the validator did not correctly handle the required validation for nested parameters in this context.
Changes:

The required_for_root_scope? method in ValuesValidator has been modified to correctly detect if a parameter is required when it's nested inside a with block. The fix involves checking the parent scope of the parameter until a non-lateral (non-with block) scope is found, and then determining if it's the root scope.
A test case has been added to values_spec.rb to cover the scenario where a parameter nested within a with block doesn't meet the validation criteria, ensuring that the correct error response is generated.

Impact:
This fix ensures more accurate validation of parameters nested within with blocks, and aligns the behavior with the expected norms of Grape's parameter validation. It's an important fix for Grape users who use nested parameter structures, improving the reliability and correctness of the validation logic.
I welcome any feedback or suggestions on this fix and look forward to your reviews!

Perfect, thank you. Update CHANGELOG and we're good to go!

Merged, thank you.


Ida 5.x/6.x support

Any reason not to create a bunch of macros dealing with the porting to 7.x and allow continued backward compatibility to 5.x/6.x?
I can submit a PR with the change if its worth it.  Mostly just a big conditional compilation blob in defs.h would do the trick, and a small handful of occurrences where class member calls need to be replaced by regular function calls to allow generality.  I am not sure how widespread the IDA 6.x usage is nowadays.
I know things were forward ported but its not difficult to maintain backward compatibility even for the CMake build.  It does not muddy the code too much either.

@PeterMatula What do you think about this?

 I'm afraid of increased code complexity, i.e. more time and trouble of moving forward. Also, more trouble with potential issues - we don't even currently have IDA 5.x/6.x to reproduce problems when they occur.
All of this could be dealt with of course, but I think the biggest question is how widespread the IDA 6.x usage is nowadays - i.e. is it even worth it? I don't know.
Soft NO for me at the moment.

Most problematic for maintaining backward compatibility in IDA is that HexRays doesn't really keep the API backward compatible. API names change, API parameters change, also the layout of the structures change.
Basically the only way to deal with it is to create a wrapper module for each IDA version with API incompatible with the other versions. I've been maintainind a debugger plugin for IDA 6.60 to 7.03 and it's a pain in the butt.

This is no longer possible, the new plugin version 1.0 will require IDA SDK 7.5.


First bit of admin interface, alias management, constants reset

This is a start on #16 with an admins-only page to perform admin tasks. The admins page will have alias management and a button to refresh all constants. Closes #41 and closes #18.

Depends on #57 for alias management


Clean up the compiler

[ ] Make everything reentrant.

Will help with compiling across multiple threads.
Compiler should suffer no performance impact from carrying around a context object.

[ ] Expose a better API than just the top-level krk_compile()

Can we expose subexpression compilation?

[ ] Can we fix error handling to get the best of both clear early SyntaxErrors and actually detecting multiple parse errors?

There's a lot of places where we may not be correctly breaking out of loops on errors.
We need a better system for collecting errors than raising a single exception or printing.

[ ] Merge the scanner into the compiler.

No solid reason for these to be separate sources, only done that way because of CI.
Might be able to eliminate the separation between parse rules and the big token enum?
Expose a better scanner API so we can build better REPL tools.

The title of this issue is extremely relatable


better docs

erm, the above comments are meant to be seen inline on the commit

I was thinking of doing a second PR. Two questions:

There is no consistent line wrapping standard throughout the documentation. I propose there should either be no line wrapping at all, or there should be an 80 character limit. See this discussion. Which is it? I personally feel more comfortable with no wrapping, but either way, I can fix it.
There is no consistent stylization of the word gopass throughout the documentation. Sometimes it is stylized as gopass and other times it is stylized as gopass. I think it actually reduces clarity to always stylize it as the latter, as it can cause confusion as to whether the docs are talking about the program or instructing the user to execute the gopass command. Which is it?

Please do so! That would be very welcome.

Personally I also avoid line wrapping and rely on my editor to do that. No hard feelings though. If anyone comes up with a case for line wrapping that'd be also OK for me.
I've tried to style it as gopass, but again: no strict preference from my side, I'd be fine with styling it as plain gopass if you prefer that and reserve the gopass styling for verbatim commands.