Upcoming Changes to Rakudo.org and Perl6.org/downloads

Since there's been apparent confusion on what changes the upcoming rakudo.org migration will bring, this document describes them in full.
The changes concern rakudo.org website in its entirety and download-related pages on perl6.org (home banner; main downloads page; recently-added "others" download page).
Table of Contents

Changes to rakudo.org

Rakudo.org Download Page Changes
API Endpoint
Release Management Changes

Changes to perl6.org

Changes to rakudo.org
The preview of changes is available on UNFINISHED PREVIEW DEMO SITE at hack.p6c.org:4242. Any particular current behaviour and content of the demo site is not indicative of the behaviour and content on the final site.

Blog posts older than 2015-11-28 to be deleted

2015-11-28 is the date when the beta release was announced
The vast majority of these are Rakudo Star release announcements
Links for removed release announcements will be rewritten to point to release announcements in rakudo/star repository; other posts will be either kept or deleted, depending on their relevance to today's rakudo

Restructured/Removed Content

The content for Bug tracker, Community, Documentation, and How to help has been rewritten, with consideration that most of it is now available in expanded and up-to-date version on perl6.org/docs.perl6.org websites. The demo shows new, abridged versions of the content.
Bug tracker no longer offers RT as the primary tracker. Due to huge amount of spam and poor interface RT is falling out of favour, which is why the GitHub Issue tracker is now listed as the primary tracker. The RT is listed as a fallback option for users who don't have a GitHub account and as the "old tracker" with still-open tickets.
About page has been removed. The only info which it contains that isn't already clear from other pages of the site is the licensing version, which is available from LICENSE file in download options.

Rakudo.org Download Page Changes
These changes concern the download page on http://rakudo.org/how-to-get-rakudo/ NOT https://perl6.org/downloads/

Use platform detection to highlight the most-relevant download options for the user
Separate the currently-existing instructions for Rakudo Star and instructions for Rakudo Compiler-Only into separate sections/pages
Add from-source instructions for Windows
Add errata notes for the Rakudo Star releases
Add button for the appropriate release announcement next to the latest Rakudo
Star releases
List 3rd party packages, which is largely the info listed on https://perl6.org/downloads/others.html at this time

Rakudo Star 3rd party packages are listed as "Other variants" in installation instructions for particular OS

Likely a "3rd party packages" button will be added to the Rakudo Star section on new files page just as it already exists for Rakudo-Only section.

Rakudo-Only 3rd party packages get a full separate page linked to from "3rd party packages" button on new files page

Build from source instructions are offered on two separate pages linked to from new files page (on old site, these were merely mentioned third-party instructions)

Instructions will primarily offer to build the latest compiler release; with development version build mentioned as an aside

API Endpoint
And API endpoint will be added that will offer a programatic way to obtain:

Version number for the latest release of Rakudo Star
Links to latest release of Rakudo Star
Errata for latest Rakudo Star release

Release Management Changes
From the current release guide:

Step 12, upload to rakudo.org will be removed
Step 13, Pulicize on rakudo.org , Publicize on http://rakudo.org/how-to-get-rakudo, and Publicize on http://perl6.org/ will be removed

The sites will obtain that information automatically from the release guide in the repo and binaries uploaded to www.p6c.org
Changes to perl6.org

The 3rd Party Packages sidebar on main downloads page will be removed, together with the "others" download page, content of which will be moved to rakudo.org
Version information, download links, and release announcement for latest Rakudo Star on home page and download page will no longer be edited manually and will be instead loaded via rakudo.org API

Errata notes will now be entered into a (to be implemented) JSON file in perl6/rakudo.org repo, NOT the perl6/perl6.org repo

The text content of the main downloads page will be restructured:

Only core-team-built Rakudo Star options will be advertized. All other Star and non-Star downloadables will be offered via a single "Pre-built Packages and Other Options" button that will link to rakudo.org files page
Simplify the content to offer instructions/downloadables for different OSes in different sections. The content will largely be similar to Rakudo Star section (and only that section) on rakudo.org files page

Link to binaries from the main buttons directly
The "installation instructions" for all three options will link to the corresponding pages on rakudo.org

I don't want see any changes to perl6.org or rakudo star errata or the rakudo star release process.

I don't want see any changes to perl6.org or rakudo star errata or the rakudo star release process.

Can you expound the reasons?
The changes automate the relevant part of the process entirely, and considering you're resigning after the next 3 releases, the more we automate, the easier it will be for the replacement person to learn the release process.

One problem is that isn't any clear distinction between what content should be
hosted on rakudo.org and what should be hosted on perl6.org.  I don't see much
point in having two websites while there is only one implementation of perl 6.
It's still very confusing to a new user. I'm interested in perl 6 and I have
the choice of two websites. Why? What's the difference? Which one should I use?
Anyway from the changes above
I like:

Not having to use wordpress to upload Rakudo Star release announcements
since rakudo.org uses the "rakudo/star" repo automatically.

Not having to publicise in three places.

Editing less HTML.

Potentially only one scp and one definitive download directory (available
via http and https).

Possibility of download stats! I suggest the links (even external) be
constructed to log this. I think I'd be a little scared to look at the
results but we probably should check this.

Not linking to the old 32 bit Windows MSI

Not Keen on:

"Errata notes will now be entered into a (to be implemented) JSON file in
perl6/rakudo.org repo, NOT the perl6/perl6.org repo"

Yes I know you want JSON for your API but it doesn't fit well with the fairly
free text errata (of necessity since we can't predict problems) and I really
don't want to edit JSON.
Neither does it fit well in any website repo. I'd rather create a text file
under a new "errata" directory under the "rakudo/star" repo. It seems to me it
should belong there and be converted automatically to JSON.
I could also create a VERSION file in the root directory of the "rakudo/star"
repo to communicate the current release.
It might also be nice to host Rakudo Star Release Candidates on rakudo.org using a
VERSION.RC file.  These don't get enough testing and need greater promotion.

Changes to perl6.org

I'd rather have seen no change there and I don't see much point in refactoring
download links between the two sites' download pages.  The reasons for doing this
aren't clear to me.
But if you are going to move parts of the download page to rakudo.org why not just
move the whole thing and just link from the perl6.org homepage? (I'm not keen
on linking to external sites from the perl6.org top nav and suggest just
deleting the download nav).
In this case at least some simplification is done in only have one download
site (although still two websites).
3 . New Download Page
Looking at  http://hack.p6c.org:4242/files
I still think the rakudo.org main download page should only include Rakudo
Star and the other options should be on a secondary download page.
Yes its there now at http://rakudo.org/how-to-get-rakudo/#Using-Rakudo but I
think it shouldn't be if you are migrating most of the download to rakudo.org.
Neither do I like "Rakudo Compiler Only" being described as "light-weight"
since I think this will encourage people to install it over Star.
And "to install the Rakudo compiler and module manager only" implies the Compiler
Only release contains zef (which it doesn't).  nxadm's Rakudo packages include
zef but that makes them not a "Compiler Only" release but a minimal distribution.

Generally I like what I see here. Pretty sure we'll tweak some details, and it's ok if later we change our mind on things. But IMO right now the plan can be executed as is and it'll be a huge win.

I agree with @AlexDaniel. @zoffixznet's current approach is much better than what we have now, mostly in terms of:

design
the ability for us to support TLS
contributing via git + markdown

I'm opposed to fudging the lines between Rakudo and Perl 6 too much; if we do, Rakudo will stay the only implementation, and projects like Niecza will be greatly discouraged.
Right now the priority should be get things set up by the time that the old rakudo.org goes down; @zoffixznet if you need any help on the infrastructure side (apache config, letsencrypt, Debian stuff, whatever), please let me know and I'll try my best to help.

I don't see much point in having two websites while there is only one implementation of perl 6.

I'm :+1: on nuking rakudo.org's content entirely and having all the download info on perl6.org only.
I know @pmichaud mentioned in the past that they worked hard to keep compiler v.s language distinction. I don't know whether @pmichaud would agree to this change and I see @moritz above said he's :-1: on it.
To me, this sort of move doesn't really appear to significantly impact other potential implementations. If anything ever appears that has usable binaries for download, we can then easily modify the downloads page to include all implementations.

I'd rather create a text file under a new "errata" directory under the "rakudo/star" repo

That works. Preferably in markdown, so it can just be converted to HTML and inserted into the site.

On Mon, Mar 12, 2018 at 04:20:21PM +0000, Zoffix Znet wrote:

I don't see much point in having two websites while there is only one implementation of perl 6.

I'm :+1: on nuking rakudo.org's content entirely and having all the download info on perl6.org only.
I know @pmichaud mentioned in the past that they worked hard to keep
compiler v.s language distinction. I don't know whether @pmichaud would
agree to this change and I see @moritz above said he's :-1: on it.

I'm strongly with Moritz and others that we want to avoid blurring the lines between the language and implementation.  I know that to many people it seems like an unnecessary distinction as long as there's only one implementation.  But whenever that distinction is lost or blurred, we seriously risk becoming a culture that builds tools and infrastructure based on the assumption of a single implementation.  That provides short-term shortcuts at the cost of (often unknown) long-term limitations and restrictions that are hard to overcome later.
Also, @moritz correctly points out that when people start equivalencing "Rakudo" and "Perl 6" we make it much more likely that Rakudo will be the only implementation of Perl 6.  It can be a very subtle and pernicious effect that is hard to see until later.
All of that said, I think it's entirely plausible to have rakudo information hosted as a subsection of perl6.org, as long as the language/compiler distinction can be maintained.  (The rakudo.org address could then redirect to that subsection.)  In particular, I'd want to make sure there's a clear understanding of how other implementations would be hosted under the perl6.org domain, if that's the way it's to be done.
Perhaps a way to blaze the trail for this is to also include subsections on perl6.org for Pugs, Niecza, and any other implementations (past or present) that are analogues to the subsection being create for Rakudo, even if those other subsections are simply historical reviews and details of the implementations.
So, if the distinction can be maintained, I don't see that there must be a separate rakudo.org, but if it looks like things are gettin blurry, a separate rakudo.org (with a better factoring between perl6.org and rakudo.org) is probably the way to go.  And at least for a short time I suspect it's okay to try one and switch to the other if it looks like there are complications arising from it.
Hope this helps,
Pm

Ok, then:

At the moment I'll update rakudo.org only, so we're good to go when the old server service expires
Then I'll prepare a demo of updated perl6.org version that:

Incorporates the full download information without blurring the line between compiler vs lang.
I'd also like to update to Bootstrap 4, now that it's released
Polish the design a bit too

So that'll let us preview all three changes at once and then decide if it should go live.

All of that said, I think it's entirely plausible to have rakudo information hosted as a subsection of perl6.org, as long as the language/compiler distinction can be maintained. (The rakudo.org address could then redirect to that subsection.) In particular, I'd want to make sure there's a clear understanding of how other implementations would be hosted under the perl6.org domain, if that's the way it's to be done.

+1

Perhaps a way to blaze the trail for this is to also include subsections on perl6.org for Pugs, Niecza, and any other implementations (past or present) that are analogues to the subsection being create for Rakudo, even if those other subsections are simply historical reviews and details of the implementations.

I would argue against this. Having dead implementations next to the only active one is way more confusing than all the confusion we already have. I would suggest a "history" link/tab or something similar.

Having dead implementations next to the only active one

I have a mental picture for how to weave it all in reasonably on one page. Let's just wait until the demo is available before bikeshedding that portion of the changes.

@zoffixznet, challenge accepted :)

@pmichaud new rakudo.org is good to go.
All you need to do is change the IPs for the domain to <IP_ADDRESS>  /  2001:780:101:ff00::80:A
The app is already running. You can view most of it at http://perl6.org:4242/ but all the rewrites from old URLs won't work until the URL is rakudo.org (you can just add the IP into your local /etc/hosts to test that stuff, if you want).
Also copied all of the content from original site, despite originally planning to leave behind old blog posts.
If you have any questions, ping me on IRC. Note: I'll be on vacation and likely unreachable from March 24 through April 4. If there are any problems with the site, its code is in the perl6/rakudo.org repo and its README.md along with infrastructure docs explain all the maintenance bits, so hopefully I won't be needed.

@stmuk I left you a robo message

Great job. And have fun and relax during the holidays.

@pmichaud pinging a reminder. The old rakudo.org hosting will expire in 6 days. Let's swap the domains.

Thanks you @zoffixznet!


ci: fix invalid release configuration

So, it does create the GitHub release and tags the commit. But for some reason it skips publishing to NPM. There's a bunch of Skipped package ... because <older-version> already exists ... logs, which I don't understand because they reference a different version (0.29.0) than what's being correctly calculated (0.31.0) in the logs above :confused:
Also, it seems to commit something and not push it (there's no release: ... commit), which causes the subsequent Code PushUp step to error (it looks up the current commit with git log -1). No clue what's happening there.
Originally posted by @matejchalk in https://github.com/code-pushup/cli/issues/591#issuecomment-2025729389

I suspect the first problem is due to using the cached build, which then contains package.json with the previous version.
For the missing commit, could this be a missing permission in the Github actions workflow?

Looking at the logs, it appears that the git push step is skipped by nx release.

My bad, in the latest version, Nx logs when pushing to Git, however in the Nx version used by code-pushup, it is not.
Looking at the code used to push to Git during the changelog command, it passes the git remote option, which is set in nx.json. Could that be why the commits are not pushed in the actual repository?
I'll try removing it.

After further testing, it became clearer that there were some issues with the step to push commits in the changelog command.
I upgraded to the latest Nx version (18.2.1), and the changes have been pushed correctly. I tried on this branch.
The only changes with this upgrade are related to Vitest, but there are no breaking changes this time :D

tests fail when no tests file are found => solved with passWithNoTests option
Vitest  "cache.dir" is deprecated, use Vite's "cacheDir" instead if you want to change the cache director. Note caches will be written to "cacheDir/vitest" => i did not change this option

Tests were passing on my machine after applying this changes

OK, if updating to Nx 18 helps, then let's do it. Do you want to create a PR? Or do you need some assistance?

OK, if updating to Nx 18 helps, then let's do it. Do you want to create a PR? Or do you need some assistance?

Since the changes were rather small, I combined the upgrade in #595.


Can remove tools from plugin_manifest even if not built now

Codecov Report

Merging #710 into master will decrease coverage by 0.13%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #710      +/-   ##
==========================================
- Coverage   88.24%   88.11%   -0.14%
==========================================
  Files          48       48
  Lines        3743     3744       +1
==========================================
- Hits         3303     3299       -4
- Misses        440      445       +5

Impacted Files
Coverage Δ

vent/api/plugins.py
93.22% <100%> (+0.53%)
:arrow_up:

vent/api/actions.py
89.16% <0%> (-2.26%)
:arrow_down:

vent/menus/tools.py
88.62% <0%> (+0.59%)
:arrow_up:

vent/api/plugin_helpers.py
81.87% <0%> (+0.6%)
:arrow_up:

Continue to review full report at Codecov.

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


FutureStream does not propagate errors

This may have been design initially, but results in different behaviours than other ReactiveSeq implementations (which has knock-effects on IO behaviour)
Also important for #988

Released in 10.3.0


[Enhancement] Move chat commands to folder

due the long list of future commands i think is a good idea to move to separated folder

I can't see the failed log :S

Me too, I’m not on my desk atm :(
Have you tried building the whole solution?
Sorry for the inconvenience

Yes, it builds in my local.
Can we re-dispatch checks from here without any push?

Error in the Azure Pipeline Log:
PlugIns\CreateItemChatCommandPlugIn.cs(26,48): error CS0246: The type or namespace name 'IChatCommandPlugIn' could not be found (are you missing a using directive or an assembly reference?) [D:\a\1\s\src\GameLogic\MUnique.OpenMU.GameLogic.csproj]

I think the original CreateItemChatCommandPlugIn.cs wasn't committed as moved or deleted, that's why the error occurs

Ok, now with the log i can fix it
Thanks you!


We want to speak to you!

If you are using the ALZ Bicep modules in production, we would love to speak to you!
Please fill out this short form to nominate yourself for a short meeting:
https://aka.ms/alz/customerinterview
Thank you, the ALZ Bicep team

Thanks for those of you that have filled in this form, we are now closing this issue and will be in touch in the coming weeks to arrange calls


verdi calcjob input cat fails

verdi calcjob input cat fails with the message:
Critical: "CalcJobNode" and its process class "Cp2kCalculation" do not define a default input file (option "input_filename" not found).
Please specify a path explicitly.

Thanks for the report @ConradJohnston.

@yakutovicha  - no problem! Looks like a one-liner fix.


Adds ambiguity to the PA term

Authored-by: Todd Sedano<EMAIL_ADDRESS>

For collisions, you can add a second text file for the second definition. E.g. PA2.txt to hold the knowledge that PA = "Palo Alto".


Update to incorporate go-nvml updates to expose interface types

Closes #57

Do we want to include this in the upcoming 0.7.0 release?

Do we want to include this in the upcoming 0.7.0 release?

I'll leave this to @klueska to decide. I think we said that it was not a hard requirement for the 0.7.0 release.

I think we should explicitly leave it out of the imminent release (in case there are any unexpected issues it introduces).

This is now ready from my perspective. Please review again.


Are you using Shmipc ?

The purpose of this issue
We are always interested in finding out who is using Shmipc, what attracted you to using it, how we can listen to your needs and if you are interested, help promote your organization.

We have people reaching out to us asking, who uses Shmipc in production?
We’d like to listen to what you would like to see in Shmipc and your scenarios?
We'd like to help promote your organization and work with you

What we would like from you
Submit a comment in this issue to include the following information

Your organization or company
Link to your website
Your country
Your contact info to reach out to you: blog, email or Twitter (at least one).
What is your scenario for using Shmipc?
Are you running you application in testing or production?

Organization/Company: ByteDance
Website: https://bytedance.com
Country: China
Contact<EMAIL_ADDRESS>Usage scenario: Using Shmipc to build large scale Service Mesh applications
Status: Production

Organization/Company: CloudXaaS
Website: https://cloudxaas.com
Country: Australia
Usage scenario: Using Shmipc for 5x IPC performance than unix domain socket for internal workloads
Status: Production

想用这个，但没有C++版本，在嵌入式中无法使用go，也无法在别的OS，比如QNX中使用。


Adds some missing proxy headers

pass through x-forwarded-proto if set, otherwise use current scheme
add host header to match config from jwilder/nginx-proxy

LGTM thanks!!

Nice, thanks!  Any chance of a release so I don't have to figure out how to compile and push my own image? :)


spago: 0.19.0 -> 0.20.0

Motivation for this change
Update spago to 0.20.0.
Changelog: https://github.com/purescript/spago/releases/tag/0.20.0
cc @f-f
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[X] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build spago

I think you can remove the dhall == 1.37.1 line from configuration-hackage2nix.yaml as well?

@sternenseemann Ah, great catch.  I've removed this in 8c36813a426.

ofborg is succeeding, so going ahead and merging this in.


Tool not working

I receive an error every time I try to use this tool, I have tried opening the client first and then the tool and vice versa. I have also tried using multiple different accounts with the same result

Take this path from the client

Put the path in the clientPath text file and then save it

See if that fixes it

looks like that fixed it

选择客户端的路径

将路径放入clientPath文本文件，然后保存它

看看这是否能解决问题

这个怎么弄，把啥子代码放进去，代码是啥


Add if-else expression

Syntax:
if <exp> do
  exps
else
  exps
end

if is always followed by an else. This can be parsed into the AST node {{:if, line}, condition_exp, true_exps, false_exps}
Type checking:
The true_exps and false_exps can return two different things which make the return type a union type (example: {:ok, Int} | {:error, String}), but we don't have union types now, so for now we'll just make sure they both return the same type. In short, the type checks needed for now:

The condition_exp should be a boolean.
The return types of true_exps and false_exps should be the same.

Once these checks pass, the type of the if-else expression is inferred as the type of the true_exps or false_exps blocks.
Erl translate
In Erl Abs form, this can be represented as a case node.

am picking this one 👍

@sreecodeslayer it's yours!


BigQuery Storage API insert with writeResult retry and write to error table

I’m currently using the legacy big query insert on a streaming pipeline (not using the streaming engine) like this:

bqWriter = bqWriter.withFailedInsertRetryPolicy(InsertRetryPolicy.retryTransientErrors())
.withCreateDisposition(BigQueryIO.Write.CreateDisposition.CREATE_NEVER)
.withWriteDisposition(BigQueryIO.Write.WriteDisposition.WRITE_APPEND);

      .withExtendedErrorInfo();
bqErrorHandler = (writeResult, eventsProcessingOptions1) ->

  writeResult.getFailedInsertsWithErr().apply("BQ-insert-error-write",
                HandleInsertError.of();

and in  HandleInsertError we process the BigQueryInsertError add some metadata and write to a desired big query error table:

@Override
public PCollection<Void> expand(PCollection<BigQueryInsertError> input) {
 return input

       .apply("transform-err-table-row", ParDo.of(new DoFn<BigQueryInsertError, KV<TableRow, TableDestination>>()
{
             @ProcessElement
             public void processElement(ProcessContext c) {

           BigQueryInsertError bigQueryInsertError = c.element();
                 TableRow convertedRow
= new TableRow();
                 convertedRow.set("error", bigQueryInsertError.getError().toString());

               convertedRow.set("t",  CommonConverter.convertDate(new Date()));
                 convertedRow.set(UUID,
bigQueryInsertError.getRow().get(UUID));
                 TableDestination tableDestination = BqUtil.getTableDestination(bigQueryInsertError.getTable().getProjectId(),

                       bigQueryInsertError.getTable().getDatasetId(), errorTable);

 c.output(KV.of(convertedRow,tableDestination));
             }
         }))
         .apply(new
BqInsertError());
}

I’m trying to change the write method to use the new one

.withMethod(BigQueryIO.Write.Method.STORAGE_WRITE_API);

but I get this error:

When writing an unbounded PCollection via FILE_LOADS or STORAGE_API_WRITES, triggering frequency must
be specified

even though the documentation indicates that the triggering frequency is relevant to FILE_LOAD method:
https://beam.apache.org/releases/javadoc/2.36.0/org/apache/beam/sdk/io/gcp/bigquery/BigQueryIO.Write.html#withTriggeringFrequency-org.joda.time.Duration-

after I’ve added the triggering frequency and NumStorageWriteApiStreams im getting this error:

Cannot use getFailedInsertsWithErr as this WriteResult does not use extended errors. Use getFailedInserts
instead

but the difference between these functions is that getFailedInsertsWithErr expands PCollection<BigQueryInsertError>
and there we have 2 features that are not avaliable from the getFailedInserts function because it expands PCollection<TableRow>:

we can get the insert error  bigQueryInsertError.getError()
we can determine the projectid and dataset id by using
       bigQueryInsertError.getTable().getProjectId(),
       bigQueryInsertError.getTable().getDatasetId()
       we need them because our pipeline is a multi tenant use case and to get                             those prarameters otherwise would require a lot of overhead.

and also when I’m trying to run it with the getFailedInserts like that:

bqWriter = bqWriter.withFailedInsertRetryPolicy(InsertRetryPolicy.retryTransientErrors())

.withMethod(BigQueryIO.Write.Method.STORAGE_WRITE_API)
        .withTriggeringFrequency(Duration.standardSeconds(5))

      .withNumStorageWriteApiStreams(12);
bqErrorHandler = (writeResult, eventsProcessingOptions1)
->
        writeResult.getFailedInserts().apply("BQ-insert-error-write",
                HandleStorageWriteApiInsertError.of();

I get the following error:

Record-insert retry policies are not supported when using BigQuery load jobs.

but I’m using the STORAGE_API_WRITES which normally should support retryTransientErrors
So first i think  there is a something missing in the implementation of that write method  that makes the retry feature not supported,
and as a feature request is to support getFailedInsertsWithErr in the writeResult when using BigQueryIO.Write.Method.STORAGE_WRITE_API
if there is an existing workaround for that now it would be great because switching the write method significantly cuts our costs
Thanks!
Imported from Jira BEAM-14135. Original Jira may contain additional context.
Reported by: yoni.be.

Having a row-level error is crucial. We would like to migrate to Storage API as soon as possible (for better performance and higher limits), but without said functionality it would be no way of knowing if we lost any data.

@johnjcasey @reuvenlax @chamikaramj  I think the biggest issue here is: can you get a PCollection<BigQueryInsertError> when using the storage API? If not, what are users supposed to do?

yes - but it's a new method.
PCollection errors = writeResult.getFailedStorageApiInserts();

I believe @bvolpato  updated the logging on this recently. #22405

I believe that means this issue can be closed

Agree.


Assign url value to InlineKeyboardButton in constructor.

I saw that it was implemented earlier but I can't find a reason why it was removed. Could you merge it please?

This change will not be backwards compatible without recompiling the code. To ensure backwards compatibility, add a new overload with a non-optional parameter.

@mhverbakel check it please.

Are you sure this works? I believe that ctor(string, string) is now ambiguous... The last parameter shouldn't be optional if I'm not mistaking.

The last parameter shouldn't be optional

It's not necessary. In this case ctor(string, string) the next ctor public InlineKeyboardButton(string text, string callbackData = null) will be executed.
But you are right that ctor(string, string) is ambiguous for understanding. I've changed this. Check it please.

You have my blessing!


Incompatibility with Foundation 5 Tabs?

Please find my codepen here -> http://codepen.io/wutz/pen/KrYaxJ
For the divs wrapped in the section on the top (class testDiv), it works like a charm.
For foundation 5 tabs (class testTab), it does not.

I don't see the problem.
If you never want the text below the tab-content being adjusted in the height, then just assign a height to the class tabs-content, perhaps even dynamically by JS. Default behavior is that the height of the current tab determines the height of the following content - but it can be reasonable to avoid jumping of the following content, then just assign a static height to the tab-container.
I don't see that match-height is faulting here because it's always only one sub-container visible and match-height is not considering invisible parts.

Actually @DavidBruchmann matchHeight supports invisible content :)
@1903Daniel the reason is that the default is to match by row. Since your tabs are only one element per row, then nothing happens. Try disabling byRow:
$('.testTab').matchHeight({ byRow: false });

@liabru :+1:  works like a charm, thank you very much :-)

@liabru thanks for the info, good to know!


Globalize Server side messages for CLI

The server-side messages that the CLI (any Client of the REST API) displays should be considered for globalization.

great idea. as long as we have a shared CLDR, then the UI should be able to pick these up.

I've slowly started consolidating controller/API messages in the Messages singleton.


Support iterators as view arguments

This resolves #63. To test this out:

Go to the examples directory
Run python adv_app.py
Reorder tasks, they should no longer fail

Great!


Missing TMB in Kids_First_Biospecimen_ID in the PBTA

What data file(s) does this issue pertain to?
This is related to the snv-mutation-tmb-coding.tsv file.
What release are you using?

Put your question or report your issue here.
There is missing TMB information for some Kids_First_Biospecimen_ID in the PBTA cohort. This will result in cases with no matched longitudinal samples (tumor_descriptor) per Kids_First_Participant_ID.
I compared the tmb to the pbta file, and filter out any missing data (see attached file named as tmb_missing_bs.tsv).
Input files are located at analyses/tmb-vaf-longitudinal/input/snv-mutation-tmb-coding.tsv and analyses/sample-distribution-analysis/results/pbta.tsv, respectively.
Can we find out why this is happening?

@AntoniaChroni can you add the list of missing bs ids to this ticket please? Also, I will transfer this over to the OPC repo as it deals with the underlying data there. Thanks!


Got an TS error with the withFileUpload method

Hey I use your lib on my projects but I always have an error here.

Can you help me ?

Oh hey @MatteoGauthier, for some reason I didn't get the Notification. You probably figured out the error already, but it's because with withFileUpload function updates the type of NextApiRequest so req.file is typed. You will need to change the types in your handler


Static Site deployment

Hi, I got this issue when deploying a static site to Azure Storage. using version 3 or 4-Preview. it is fine with v2.
##[error]Upload to container: '$web' in storage account: 'xxx' with blob prefix: '' failed with error: 'AzCopy.exe exited with non-zero exit code while uploading files to blob storage.' For more info please refer to https://aka.ms/azurefilecopyreadme

please provide detailed logs,

@baoduy  If you are still facing this issue, can you please set the variable "System.debug" with value "true". Redeploy and share pipeline zip logs here.

Also, can you try deploying via CLI as a workout:

az storage blob upload-batch --account-name myaccount -s . -d $web

@eaarora-ms sure let me try

@baoduy Sure, Please do let us know the results.

@baoduy Can you please let me know if you were able to try the workaround?

Closing due to no response from the customer. Please comment to re-open the issue.


Using Azure.Identity.DefaultAzureCredential, how to handle the token expiry after 24 hours?

I'm using EF6 (Database First Code/EDMX) and ASP.net MVC .Net Framework 4.8
My issue is also mentioned on this GitHub issue:
https://github.com/Azure/azure-sdk-for-net/issues/35732#issue-1678674908
The error that I'm running into is this:
"The underlying provider failed on Open. Login failed for user ''. Token is expired."
My DBContext includes the code below to fetch token for the system assigned managed identity:
Azure.Identity.DefaultAzureCredential credential;
var managedIdentityClientId = ConfigurationManager.AppSettings["ManagedIdentityClientId"];
if(managedIdentityClientId != null ) {
    //User-assigned managed identity Client ID is passed in via ManagedIdentityClientId
    var defaultCredentialOptions = new DefaultAzureCredentialOptions { ManagedIdentityClientId = managedIdentityClientId };
    credential = new Azure.Identity.DefaultAzureCredential(defaultCredentialOptions);
}
else {
    //System-assigned managed identity or logged-in identity of Visual Studio, Visual Studio Code, Azure CLI or Azure PowerShell
    credential = new Azure.Identity.DefaultAzureCredential();
}
var conn = (System.Data.SqlClient.SqlConnection)Database.Connection;
var token = credential.GetToken(new Azure.Core.TokenRequestContext(new[] { "https://database.windows.net/.default" }));
conn.AccessToken = token.Token;

Can you please help me with an example of how to handle the token expiry after 24 hours?
I can't use EF Core today that's why I need to make this work with EF6.

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

ID: 1e119045-e113-d9d1-1b5e-a87e6befe3aa
Version Independent ID: 98fcc13e-5da6-7251-d702-d9ee07c00581
Content: Tutorial: Access data with managed identity - Azure App Service
Content Source: articles/app-service/tutorial-connect-msi-sql-database.md
Service: app-service
GitHub Login: @cephalin
Microsoft Alias: cephalin

@ryms-nnit
Thanks for your feedback! We will investigate and update as appropriate.

@ryms-nnit
Thank you for bringing this to our attention.
I've delegated this to content author, who will review it and offer their insightful opinions.

Internal item created: https://dev.azure.com/msft-skilling/Content/_workitems/edit/288709
#please-close


IGNITE-5732 Provide API to test compatibility with old releases

Special module contains testing framework which provides methods for testing backward compatibility.
It allows to start Ignite-cluster in multiversion mode. It means that nodes with different build version is allowed to join topology.

Merged to the master branch by the commit


Some problems compiling for linuxArm32Hfp

Ok, I've started using the sample from Dominaezzz's kotlin-imgui library for the K/N, but I get errors thrown when trying to compile it for linuxArmHfp.
error, my build.gradle.kts and my folder layout

It compiles and runs fine on the host, but it doesn't get past the errors when compiling for the ARM32HFP.
I can also test new builds on this architecture. I have a Raspberry Pi 2b+ and an IMX6 to test it on.

I've gotten to my laptop now. You seem to have only edited the samples build.gradle.kts file and left the ones for imgui and cimgui. They each have to be configured for linuxArm32Hfp.
I've made some changes and pushed it to the raspberrypi branch. It should allow you to run the sample via JVM but Native will require you to do cinterop for OpenGL( ES?) and GLUT/GLFW/SDL. I don't know enough about raspberry pi to set it up in CI.
I can try and assist you through Gradle issues if you make a PR or something.

I'll test that branch out for JVM and will try to make the cinterop work with the RPi!
Thanks for the good work!

At least SDL2 is available in K/N prebuilt sysroot for RPi, see samples/Tetris in K/N repo.
Should work on any host, including CI.

Ah, I forgot about that. Thought should make things easier.

Just checked samples/tetris - it's a little bit broken, did PR JetBrains/kotlin-native#3813

@MGlolenstine Are you still interested in this? Particularly in testing builds?

@Dominaezzz I have a free Raspberry Pi 2B+, so I can test out Arm32 builds with no problem.


Make Labels visible all the time?

Hey there,
Is there a way to keep Icon labels visible all the time, even when not clicked on?
Would super appreciate that feature!

Thanks for the suggestions. You will get this feature in the next release. Chears.

Much appreciated!


How do we use a read-only database in Django?

We have a replicating AWS database in our server network. I would like to start using that end point for API calls that don't require any write activity. For this issue to be satisfied, please:

[ ] Propose changes to WeVoteServer/config/environment_variables-template.json for the read-only database
[ ] Update election/views_admin.py elections_sync_out_view to use the read-only database

What calls electionsSyncOut?  I couldn't find a reference in python or React.   If servers are using this to synchronize datasets, Postgres replication would do it much better.  (Probably orders of magnitude faster).

We want two sets of django dbs, and two sets of config for them in environment_variables.  Need to figure out how django discovers it's db, most likely on two different instances.

/Applications/Postgres.app/Contents/Versions/9.6/bin/pg_dump -p5433 WeVoteServerDB > backup.sql
Create WeVoteServerDbReadOnly with pgAdmin4
/Applications/Postgres.app/Contents/Versions/9.6/bin/psql -p5433 WeVoteServerDbReadOnly < backup.sql

Info on how to test this on two macs on your local network:
[https://docs.google.com/document/d/1MJML7aT_QjSGtf_R1P9OpeILexRl5Ma5SZDiLuR5A68/edit?usp=sharing]

I think this is complete.

Thank you @SailingSteve I have marked this as VerifyFix until we can test it on the production server.


Plugin Description
x64dbgbinja
Official x64dbg plugin for Binary Ninja.
Installation
Clone this repository in your Binary Ninja plugin directory.
Menu options
Import x64dbg database
Import comments/labels from an uncompressed x64dbg JSON database in Binary Ninja.
Symbols for imported functions and or library functions can be overwritten via the "Overwrite X" entries in Settings.
Export x64dbg database
Export comments/labels to a JSON database that can be loaded by x64dbg.
To export labels only: uncheck "Export Comments" under "x64dbg Database Export" in Settings.
Plugin Repository URL
Repo URL: https://github.com/x64dbg/x64dbgbinja
Real Release

[X] I have made a real release

added, thanks!


Ignore items with NBT option

Your Idea
I was recently using this on my server and it grabbed a iron and gold ingot from a plugin called SlimeFun which uses some normal ingots to show their own,
but these ingots cannot be used in a crafting table for normal recipies so a option to ignore either specific NBT tags or ignore items that have NBT that normally dont have NBT

Currently there is an option to ignore items with custom names. For NBTs that's a bit tricky, how would you like to go about this?
I'm unsure how to check for NBT that's "not normal". And if I include an option to "protect/ignore" items with a given NBT, how would the user figure this out?

Currently there is an option to ignore items with custom names. For NBTs that's a bit tricky, how would you like to go about this?
I'm unsure how to check for NBT that's "not normal". And if I include an option to "protect/ignore" items with a given NBT, how would the user figure this out?


Translate README.md

What: we should translate the project's README to English.
Why: this is necessary so foreign people can contribute to our project.
When it will be done: when the README file could be read by a foreign contributor.

Done!


Relativesource bindings and syntax.

We discussed this a bit in chat and came up with a couple of ideas for syntax:
<Foo Bar="{$parent[Window].Baz}" /> would bind to the first ancestor of type Window.
<Foo Bar="{$parent[Grid, 2].Baz}" /> would bind to the second ancestor of type Grid. Not sure how useful this is.
<Foo Bar="{$root.Baz}" /> would bind to the first parent of type Window or userControl
The equivalent WPF syntax is so ugly I don't even want to type it :)

We'll still need the {Binding} part according to XAML syntax (though I would love to have a similar binding syntax to polymer where e.g. {{Value}} would mean the same as {Binding Value}.
Given that, here are a few more ideas:

{Binding $parent.Foo} logical parent
{Binding $parent[1].Foo} logical grandparent
{Binding $self.Foo} property on self

I'm going to take a stab at implementing this.


about corners in the code

Thank you for your great work, but I got some questions.
Why put p_mean_variance and conditional_mean in
for (hi, wi) in corners:
what x_grid_mask means and why new_out_mean = th.div(new_out_mean, x_grid_mask)?

why ddpm and guidance is limit to 256*256 every loop?


Getting slower and slower

Hi! I really love this package! When I started using it this september it made the life so much easier!! but for some reason it started getting slower through time. Today I just realized that after installing it in a new environment, the new version 0.6 made it even slower. Now I reverted back to 0.5.0. Can you replicate the speed issue? I cannot remember what was the fastest version, and there are really huge differences between them

Thanks for the issue! I suspect the copying of the sample made it slower. I will try to dig deeper. Could you tell me which class are you using? RaggedMmap, StringsMmap, or the numpy module?
https://github.com/hristo-vrigazov/mmap.ninja/commit/7a7b50308d26de73a0c08e055fccfae50c040360

Thank you very much for the fast reply!!
I use only RaggedMmap. Actually both the creation and accessing samples got slower. I have a creation script which is running in a cluster for 25 days now and it doesn't seem to finish anytime soon... (before the same operation took 2 days). But my biggest issue is the read time, before everything was running at an instant, I guess it was the version 0.2.4 which worked smoothly. I will try to revert  to that.

That helps a lot! I figured out what the problem as when accessing sampes, it was introduced in 0.5.4, and it was because the sample was copied regardless of whether wrapper_fn was passed (in older versions, it never did a copy). . Today I released 0.6.1 which does the copying of a sample only when wrapper_fn is passed (this is done to avoid warnings when you do something like RaggedMmap('out_dir', wrapper_fn=torch.tensor) about getting an unwritable sample.
Do you pass a wrapper_fn argument when you open the RaggedMmap? If not, I think the new version should fix the item accessing.
I am still not sure about the slowing down of the creation, I will try to create benchmarks for it on a small corpus so I could get quick feedback. But a few versions ago I did refactoring and I reused a function, which could be the culprit. I will update you here with the developments.
Your feedback and inputs are invaluable :) And yes, I think 0.2.4 is safe to use for now, until I am sure it's fixed and have benchmarks to avoid such regressions in the future

By the way, you can chat about mmap-ninja anytime here: https://app.gitter.im/#/room/#mmap-ninja:gitter.im
You can log in into gitter with your github account.

Thank you very much! I do not use a wrapper, indeed, I take small windowed frames of audio/video from lists of huge arrays, so I only get a fraction of a sample per batch to np.array(sample[segment]). Normally reading a small window from an arbitrary point of an audio file is very costly since you have to at least read to the related segment, i.e., if the segment is at the end of the wav file, you end up opening the entire file of 100MBs.
The ability of immediately reading and passing only a segment of the mmap array into the memory is really helpful for me. Then I guess it got slow because the copy operation creates the array of from the huge mmap arrays at the moment I access the sample, no? It doesn't keep the sample in the mmap before reading the segment?

Yes! So, basically, I added the copying of the sample because otherwise there were PyTorch warnings when passing torch.tensor as a wrapper function. However I had added the copying in the wrong place, and it was always making a copy. And since you use the operation so often, the small difference quickly added up to a huge difference.
In version 0.6.1, the accessing of samples is similar to 0.2.4 in terms of speed. I tested it on the pets image dataset. There, for one iteration over the memory map, 0.2.4 takes ~0.150 seconds, while 0.5.* were taking ~1.20 seconds, so there was a huge difference. 0.6.1 takes again ~0.150 unless you pass a wrapper_fn. So I think in terms of accessing it should be fixed now.
I still have not figured out what would be the problem in the creation, but I am investigating it.
By the way, I was just working on parallel initialization, which could probably speed it up even more, but I think it's better to fix the existing issues first, and then will expand with new functionalities.
Maybe you could create a smaller version of your dataset, so you would get a quick estimation of which version is ok for you to use. I think in 0.6.1 the creation will still be slower, but accessing items should be ok now.

Thank you very much!!

 I am really happy when I hear feedback from users, means that someone is using it :) If you have any questions, problems, etc. or anything else, do not hesitate to open an issue here, or chat on Gitter.
I will update here once I figure out why the creation has slowed down, and when I release the parallel initialization.
By the way, one feature in the newer versions of mmap-ninja is the lazy creation. For example, you can now do this:
from mmap_ninja.ragged import RaggedMmap

ragged = RaggedMmap('out') # This line used to throw an error if the mmap did not exist
ragged.append(np.arange(10)) # This line now will initialize the memory map


Minor task test file fixes

TODO:

Add description, improve title
Update status of #49 (close and draft separate PR for report publishing and CI exit code?)

Thanks, @lbeckman314 :pray: @LakiG, can you have a look? It looks good to me, but I'm not sure about the inputs vs input. And perhaps you can also comment on the second point in the "TODO" in the PR description.


The Datepicker is extremely slow

I tried using this datepicker and i liked everything about it the only problem is that its extremely slow, meaning the window for pick the date lags and it has low FPS
"react": "^16.8.6",
import "react-persian-calendar-date-picker/lib/DatePicker.css";
import DatePicker from "react-persian-calendar-date-picker";

<DatePicker
    selectedDay={null}
    onChange={null}
    inputPlaceholder="انتخاب روز"
/>

Hi, @ahmadi3d can you provide an example in Codesandbox? As far as I've tested it's completely 60fps.

Hi, @Kiarash-Z , I managed to find the reason for this issue, this bug (low fps and lag) happens when instead of using hook, you simply call the component inside a class component, i don't know why this happens but i managed to fix it after using react hooks similar to the examples in the documentation

It shouldn't make a difference:/ feel free to reach out if the issue appears again❤


Alternative to Tiltfile for defining team-level config

We have a number of different Tiltfiles in use within our org, and are having some difficulty ensuring settings like experimental_telemetry_cmd, disable_snapshots and set_team are applied correctly everywhere.
It would be helpful to be able to decouple some of these settings from the "project" level settings. A few possible avenues:

Environment variables, perhaps even defining an "always-run" Tiltfile
A .tiltrc file
We have a monorepo, so something like Bazel's WORKSPACE would also be an option

Interesting! Will bubble this up to product :)
To be clear, how much is your concern consistency vs enforcement? There's potentially an implementation difference between "Want to make sure all the settings get applied the same across a project" and "an engineer shouldn't be able to turn on snapshots by locally editing their Tiltfile".

Consistency is the main concern. If someone creates a brand-new Tiltfile inside our monorepo, I'd like to have snaphots disabled by default.
If someone has the know-how to get around it, it's not the end of the world.

I have a Thought, so I'm going to try to be extra clear.
It seems like this is fundamentally about "per-service Tiltfile configuration should be done in the context of a wider config".
The specific idea is "point the per-service config at the wider config".
I think the arrow should point the other way: "the wider config should point at each per-service config".
I call this the "single entry-point Tiltfile". (To be clear, this is not a good name.)
In this model:

there's one top-level Tiltfile that does all the setup.
the args to it decide what subset of services/Tiltfiles to run
users never tilt up on a different Tiltfile.

It's nice that bazel build in a subdirectory and have that context be relevant to your command; we could add a way to do that to Tilt

This would be a refactor for you (and is the opposite of how bazel does it), but I think it has real advantages for Tilt. I'm about to run to a meeting, but can write more or chat about it. (We should have a docs page that describes this better.)

Thanks @dbentley! This is the model we've been trying to maintain thus far. We have a root Tiltfile in our monorepo that points to all other Tiltfiles, with the specific applications selected using args.
The problem we've experienced is that it's very easy for someone to create a "rogue" Tiltfile and run that standalone (especially if they dive into the official Tilt docs rather than our internal intro page). This then bypasses the configuration we're relying on for telemetry, snapshot control, etc.
To the point of Bazel context being relevant to subdirectories, do you mean the "//..." style paths from the workspace? Something like that would also be super useful, as we have a lot of "../../../" imports going on.

Do you have all of them named Tiltfile?
Would it help if the per-service Tiltfiles had a distinct fixed name? Like foo/Setup.tlt and bar/Setupt.tlt? (with .tlt being the extension for the Tiltfile language).
A 3rd kind of file is for libraries. E.g. you might have tilt/k8s.tlt and tilt/mesh.tlt for reusable stuff the different per-service files would load and then use?

We do have our library files named .tilt, might tweak that to .tlt if the VSCode plugin will recognize that extension :)
I've considered something like an application.tlt file for each project, which would help to drive people to the root file as convention.
@jfancher I know you've expressed a preference for independent Tiltfiles, would this model be a major issue with your workflow?

I wouldn't call it a major issue with my usage so far, but I don't see how it's preferable. I can appreciate the desire to set certain settings globally (.rc style), but the things listed are Tilt runtime settings, nothing to do with starting or running workloads. I think those are separable concepts.
I'm not clear on exactly what the proposal is here; right now we have a root service -> Tiltfile map that just does include(fileMap[service]) for each service listed in args. Is the suggestion to essentially codify that pattern, or would there be more advanced federation and dependency management involved?
I can give more details about a case I've been thinking about where this approach would pose a practical challenge, but to start out more philosophically: I've yet to be convinced that top-down single entrypoint delegation is the right default choice for a monorepo. We have dozens of teams and hundreds of mostly-independent apps; very few subsets of those apps will ever need to be run together, and almost all local runs are "this single app I'm working on, and whatever dependencies that app needs to function". What are the benefits of coordinating "every potential workload in this repo" in a single central location compared to closer to the unit of development?
Of course I don't want to blow this out of proportion -- we historically have used Edward, which is structured similarly top-down, and it's fine. But it has never struck me as ideal.

I don't think the single entrypoint is perfect, nor is it philosophically the One True Way. So I'm not going to try to convince you it is. (FWIW, I really like your point of allowing more coordination the closer you get.)
Right now my opinion is close to "whether the root config is included by the child or vice versa is close to syntactic sugar". As we want to support more of the cross-service patterns, I think it's better to support one style well than trying to support both styles... less well.
I'll see if I can dig up some notes on advantages of the single entrypoint. It would be great to know if there are showstoppers with the single entrypoint approach. So the practical challenge example would be super useful. (Happy to take to a video chat as well)

Okay, this is pretty far afield from Tom's original issue, but since you asked... the following is the sort of scenario I'm trying to think through. It's long and a bit abstract, but hopefully illustrates my mindset.
TL;DR: In a complex project with many configuration options, it seems more tractable to start from a target service and fan out to set up its dependencies, compared with starting a bunch of services separately and hope they add up to the system configuration you want.

Say I am working on a project processor, a component of a streaming pipeline.
processor is a sort of 'hub' service, which connects to:

state - its main data store
config - processor configuration
resources - shared auxiliary resources/configuration
input - streaming input
output - streaming output

In a live environment, these are handled by a variety of other services and infrastructure components:

state: processor-db database
config: processor-conf service

using processor-conf-db database

resources: registry service

using registry-db database

input: connected via kafka to source service

source is connected to source-db

output: connected via kafka to sink service

This is a ton of stuff to run, and it also requires seed data copied or generated to make it do anything useful. Luckily, each of these also has alternatives:

state: may be configured to use an ephemeral in-memory store, or connect to the shared dev processor-db
config: may be stubbed out to read static config from a local disk, or connect to the shared dev processor-conf-db
resources: similarly, may be configured statically or connect to the shared dev registry
input: may be bypassed (data injected directly) or connect to a topic in the shared dev kafka
output: may be stubbed (write to console) or write to the shared dev kafka

Of course, if I do choose to run them locally, each of registry, source, and sink may have similar capabilities (including options for additional dependencies I've left out for brevity).
Some high-level observations:

Running the "full" processor system locally is not a practical default. It's nice to be able to do, but it's too expensive and complex for day-to-day development.
However, there are a variety of useful subsets of components that are useful to run together depending on particular area of development (not every possible permutation, but at least a few).
The processor deployment needs to be configured explicitly based on which components you want to connect it to.
Some infrastructure pieces, like kafka, may be shared between processor and other services (if they're configured to use it).

With that long wind-up, here's an example of what concretely I'd like to do. To debug the "ingestion" component, I want to bring up locally:

source and source-db seeded with some initial configuration
processor with in-memory storage, local configuration, and targetting the shared dev registry
kafka, to be shared by the two

This would be a bad way to do this:
/repo $ tilt up source source-db processor registry kafka

Because:

It's too much typing and requires knowledge the processor developer may not have at top-of-mind
It's not reusable -- this set of services and configuration means something specific in the context of processor development, so it should be encoded in something I can check in
Most importantly, per 3. above, it wouldn't work anyway -- outside of local development processor has no need to run in so many different configurations, so it's not like it has a service discovery mechanism that says "source is running, so I should use that". Something about the k8s resources has to be different to accomplish this (command-line flags/env vars via kustomize right now, though arguably not the best way)

Whereas, if I'm focusing only on the processor Tiltfile, I can imagine doing something like:
/repo/path/to/processor $ tilt up --debug-ingestion

And the Tiltfile like (pseudocode):
load("//infra/path/to/kafka:kafka.tilt", "kafka_cluster")
load("//src/path/to/source:source.tilt", "source_service")

config.define_bool("debug-ingestion")

processor_yaml = "deployment/local"
if cfg.get("debug-ingestion", False):
  kafka_cluster(topics = ["processor-test-topic"])
  source_service(
      static_config = "local/path/to/processor-specific/config",
      produce_topic = "processor-test-topic",
  )
  processor_yaml = "deployment/local-with-source-service"

k8s_yaml(kustomize(processor_yaml))

Of course, this would require structuring the Tiltfiles of the other component as an API rather than just "dump the file's text in here and execute it"; I don't mean to imply that'd be the default or even common, but for a few high-value complex cases it could be super useful. Even for the cases where it is just include(), it may be conditional or need to happen in a particular order compared with the rest of the file.
Anyway, maybe this kind of thing is not impossible to do with a top-down management, but approaching it from the point of view of "I'm a processor developer, I want to set something up for myself and other developers to do some class of work on processor", it seems most natural to silo it under processor.
In writing this out, it occurred to me that it's sort of reminiscent of a "declarative-vs-imperative" debate -- if things were purely declarative, then maybe it'd be as you say, that things could be defined anywhere and where they get composed is not that important. To frame it in those terms, I think Tilt it lacking the declarative toolbox w.r.t. dependencies, conditionals, orchestration in general to make cases like the above work, when it's fairly simple to imagine (if not to fully implement) imperatively.

Thanks for the concrete example.
I agree totally that it makes sense for processor to have a lot of logic like this, and it should be grouped with processor. I was thinking something like "if you run tilt up from within the processor directory, it should use the parent Tiltfile to setup team-level stuff and then get processed down here". Obviously a lot of extra support is required to make that easy.
My big remaining question is about cross-constellation work. What if you want to run processor together with another project of similar scope? Does processor get data from some other completely different service? How much cooperation/similarity do you want between those? It's those kinds of issues that make me think it's worth a bit of forcing people to play together (i.e. in the same root Tiltfile) early. WDYT?

That's a good question, but not one I have a lot of insight on.
Speaking only for myself, the set of services I listed in my example is about the upper limit of the universe of stuff I'd like to run locally at once -- or rather, the limit of what I think is practical for my situation. Beyond that point:

Resource constraints become a concern. Even with just a subset of the processor case implemented I'm running into limits of what my laptop can handle (I mostly blame docker-desktop for this though, as it's fine outside of k8s).

The setup / configuration / data burden of initializing a fresh environment becomes overwhelming.

Other than debugging production issues where the point of failure is unclear (i.e. for everyday development) it's generally faster and easier to only have to run a single microservice or a small related set. This definitely isn't true for all teams or projects -- to reiterate, only speaking for myself here -- but IMO it's usually worth devoting effort to make it more true (vs effort towards making it easier to run all dependencies).

Additionally, we have a pretty ingrained "fallback to shared development sandbox resources" setup, which mitigates the first two points above. It's not perfect, but it provides a simpler alternative than "figure out how to run it locally" for many dependencies.
At a conceptual level, I do really like the idea of having a self-contained, personal instance of any subset of our entire platform, where you just up service1 service2 ... serviceN for any group and it all just works together seamlessly (in particular, as opposed to hundreds of devs stomping around the same shared sandbox). However, whenever I consider the practical work that'd need to be done to enable this universally (at the app/infra/config/data level, not just Tilt) it just doesn't seem tractable, or worth it. Hence my focus on the smaller scale.
I'd be happy to be proven wrong though, to see a "mix and match platform" working at a grand scale without sacrificing flexibility or productivity when developing individual components.


CI not working

Appveyor can build manually but does not seem to be detecting commits across all branches.  Is this by design (only dev branch runs)?
Personally I'd prefer CI across all branches.

//FAO @mattridgway

We were missing the appveyor webhook.  Should work as expected now.


Add qollama to list of Web & Desktop integrations

QOllama is a Qt-based client for ollama, providing a user-friendly interface for interacting with the model and managing chat history. It supports cross-platform functionality, ensuring a seamless experience on Windows, macOS, and Linux.
Goto QOllama: https://github.com/farleyrunkel/qollama

Windows
MacOS
Linux

todo

A huge improvement in program architecture and UI interface
😁😁😁😁


finish 'sampling' code

There are four files started to hold functions to 'sample' our 'true' population and then inform the .dat file...all of them start with 'sample-...' and are in the folder Obs_Error.  These all need some work still. The -biom and -numbers will draw a fishery biomass and survey abundance index, respectively, but aren't doing that correctly yet. The other two will generate age comps with error, but aren't done either.

Still stuck on the age comp sampling code.

I just pushed a new version of the agecomp sampling code that now only works with a single vector of numbers or proportions at age to the main folder.
My R/Obs_Error folder doesn’t contain anything, so I just updated “sample-age-comps.R” in the main /R directory.
Give it a try, with cpar as NULL. This will add simple multinomial error, with a specified multinomial sample size Nsamp.
Cheers,
Curry

On May 28, 2019, at 8:08 AM, Kari Fenske<EMAIL_ADDRESS>wrote:
Still stuck on the age comp sampling code.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/khfenske/Sablefish_ApportionmentStrategies/issues/14?email_source=notifications&email_token=ABB2BMOQUWRPPXLTH6GDKDDPXVKGDA5CNFSM4GKROJM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWMUAUA#issuecomment-496582736, or mute the thread https://github.com/notifications/unsubscribe-auth/ABB2BMJJ6TCBVFWHAJI5TLLPXVKGDANCNFSM4GKROJMQ.

Curry J. Cunningham, Ph.D.
(907) 360.4217
Website: currycunningham.com/
Twitter: @CurryCunningham


docs(jenkins): disable password auth

We use only keys for ssh auth. Disable password authentication
altogether to avoid future mishaps.

bors merge

bors merge


Custom error map not working

Hello,
I'm trying to customize the error messages using an error map but it doesn't seem to have any effect, the function gets executed, but the returned message doesn't come from the map.
Example:
const customErrorMap = (issue, ctx) => {
  return { message: "custom" };
};

const email = z.string({ required_error: "required" }).email("invalid");

const res = email.safeParse("email", { errorMap: customErrorMap });

I would expect res to contain the custom error message, but in fact it returns:

If I remove .email("invalid") it works, so seems like the chained validation has a higher priority than the error map which should not be the case.
Repro:
https://codesandbox.io/s/festive-gould-m7y3nk?file=/src/index.ts:22-297

Yes, the default error map has the highest priority, no matter what you do...
There are a lot of issues like that. This behavior is also stopping me from creating good error messages in nestjs-zod library.
https://github.com/colinhacks/zod/issues/1043#issuecomment-1126859190

Yes, the default error map has the highest priority, no matter what you do...

This isn't the problem described by OP. If there's a scenario where the default map takes precedence over one passed into .parse please file an issue with a minimal reproduction.

the returned message doesn't come from the map

In this scenario, the "hard coded" error you passed into .email and z.string({ ... }) take preference over the contextual one. That's intentional and makes sense to me. If you want to override those error messages why are you hard-coding them into your schema?

@colinhacks I need my error messages localized so I'm hardcoding the i18n keys and I was hoping to use .safeParse later once the t() function is ready to get the actual messages.
Do you have some better example of doing this? I didn't find any mention of internationalizing the messages in the docs, thanks

I have the exact same use case, translating "hardcoded" messages.
z.setErrorMap((issue, ctx) => {
  if (!issue.message) {
    return ctx.defaultError;
  }

  return {
    message: i18n._(issue.message),
  };
});

Unfortunately, this does not work, but really should.

I'm doing the same thing, and running into the same problem. The issue is this line:
message: issueData.message || errorMessage

Which clearly deprioritizes the message produced by my custom error map. So frustrating.

I also faced this issue when dealing with i18n. I solved it by not specifying a message at all and instead pass the key through params to then intercept it in the error map:
const register = z.object({
  email: z.string().email().trim(),
  password: z
    .string()
    .min(8)
    .max(250)
    // Use params instead of message
    .refine(minLowercase(1), (v) => ({
      params: {
        i18n: "errors.custom.minLowercase", // "Should at least contain {{count}} lowercase character(s)"
        count: 1,
      },
    }))
});

// Intercept "custom" issue and use the t function to translate it

z.setErrorMap((issue, ctx) => {
  let message = ctx.defaultError;

  switch (issue.code) {
    case "custom":
      if (issue.params && "i18n" in issue.params) {
        message = t(issue.params.i18n, { values: issue.params });
      }
  }

  return { message };
});

// Parse the schema and check error

JSON.stringify(register.safeParse({ email<EMAIL_ADDRESS>password: "MYPASSWORD" }))

/*

Looks good ✅

{
  "code": "custom",
  "params": {
    "i18n": "errors.custom.minLowercase",
    "count": 1
  },
  "path": ["password"],
  "message": "Should at least contain 1 lowercase character(s)"
}

*/


Test-TargetResource no longer throws when Chocolatey is not installed.

#36

Looks good, thanks for the PR!


Moving web_pubsub(4), windows(4) resources to v1beta1 version

web_pubsub 4

[x] azurerm_web_pubsub
[ ] azurerm_web_pubsub_hub
[x] azurerm_web_pubsub_network_acl
[ ] azurerm_web_pubsub_shared_private_link_resource

windows 4

[ ] azurerm_windows_function_app
[ ] azurerm_windows_function_app_slot
[ ] azurerm_windows_web_app
[ ] azurerm_windows_web_app_slot

azurerm_web_pubsub_hub
message: 'observe failed: cannot run refresh: refresh failed: "Hub (Subscription:       \"038f2b7c-3265-43b8-8624-c9ad5da610a8\"\nResource Group Name: \"subhub-rg\"\nWeb       Pub Sub Name: \"webpubsubname\"\nHub Name: \"webpubsubhubname\")" was not found: '     reason: ReconcileError

azurerm_web_pubsub_shared_private_link_resource
    message: 'observe failed: cannot run refresh: refresh failed: "Shared Private       Link Resource (Subscription: \"038f2b7c-3265-43b8-8624-c9ad5da610a8\"\nResource       Group Name: \"privatelink-rg\"\nWeb Pub Sub Name: \"webpubsubnameab\"\nShared       Private Link Resource Name: \"sharedplresourcename\")" was not found: '     reason: ReconcileError

    message: 'observe failed: cannot run refresh: refresh failed: parsing "SystemAssigned":
      expected 8 segments within the Resource ID but got 1 for "SystemAssigned": '
    reason: ReconcileError


network prediction examples

My 2 cents: The last part of your code generating scores was unclear to me.
Instead, the below exemplified how the trained network outputs 1 when the two vectors are uncorrelated, and something close to 0.5 when they are.
Feel free to add it to your code.
Also, maybe a jupyter notebook would make more sense, as it can display in github the results without you having to copy paste them in-line the code as comments.
(Pdb) model.predict([X_1[0:1,:], np.zeros(shape=(1,50))])
array([[0.9999989]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], np.ones(shape=(1,50))])
array([[0.9999285]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], np.random.randn(N, INPUT_DIM)])
array([[0.99992096]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], X_1[0:1,:]])
array([[0.5]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], X_2[0:1,:]])
array([[0.9995178]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], X_1[0:1,:]+0.1])
array([[0.47106665]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], X_1[0:1,:]+0.2])
array([[0.44332358]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], X_1[0:1,:]-0.2])
array([[0.5630561]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], X_1[0:1,:]+0.1*np.random.randn(N, INPUT_DIM)])
array([[0.46504748]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], X_1[0:1,:]+0.1*np.random.randn(N, INPUT_DIM)])
array([[0.5252977]], dtype=float32)
(Pdb) model.predict([X_1[0:1,:], X_1[0:1,:]+0.1*np.random.randn(N, INPUT_DIM)])
array([[0.4684026]], dtype=float32)

The purpose of RankNet is to rank things (like documents), so I wanted to demonstrate how you would generate scores for ranking. My code shows that, e.g., documents with higher similarity features compared to a query (i.e., X_1 vs. X_2) will produce higher scores and thus be ranked higher. Your examples are showing that similar input vectors produced similar scores (i.e., the difference of their scores is close to 0, which corresponds to a probability of 0.5 when passed through a sigmoid function because 1 / (1 + e-0) = 0.5), which is exactly what you would expect because the model is a Siamese network.


Updated Datadog logo and added Mirantis, Giant Swarm to Tech Partner Section

This change is

@ankurshukla  Looks like this might need a rebase?

@irabinovitch now rebased!

Hi
Not sure why but my pull request is failing the build (https://travis-ci.org/kubernetes/kubernetes.github.io/builds/174638275)
Is there any more insights into what went wrong? My local branch seems to be up and running fine with my changes.

closing this PR and will be submitting a new one.

@ankurshukla Please squash the commits and I will merge

I just rebased my changes, Can you try now. Seems to be some issues with my repo. If this doesnt work, would have to create a new PR.
apologies on my handicap with github :(

You will need to do something like
git rebase -i HEAD~11 and then change the commits to fix ups.  Then repush with git push <remote> <branch> --force

just did it, Thanks  :) my 2FA was causing issues that why rebasing didnt worked!

Looks like there are still 13 commits

rebased and pushed again.

I did the commits myself. Just had to generate a new access token to push the changes. Please add the Google CLA back. Screenshot attached in previous comment for reference.

Look at the commits.  Something seems very broken.

yeah....my whole workspace seems a bit off now, due to continually adding commits to an open PR. Lemme start over, probably easy and cleaner than fixing and re-rebasing.
Apologies for all the inconveniences.

@ankurshukla No problem, but I think it might be worth your time to better understand the git workflow.
I would do this:
git fetch upstream
git rebase upstream/master
git rebase -i HEAD~3

Squash the commits in the editor

git push origin master
Then see what happens

closing this PR. Will submit a new (and tested) one.


Wireframe for Dashboard

Link for Dashboard prototype
https://www.figma.com/proto/RRtoRLyr5Spf0KiyRfEclt/DMP-Explain?node-id=886-782&t=ezIW5k9IdmCi0hHx-9&scaling=min-zoom&content-scaling=fixed&page-id=177%3A504&starting-point-node-id=886%3A782&show-proto-sidebar=1
This is a bit of a departure from phase 1, We went with a card-based dashboard instead of the table-style dashboard.

There are a few reasons for this

Data - We had problems trying to fit a lot of "data" in the table before, cards allow us to show more up-front data to the users without trying to squeeze it in columns.
Ease of use/smaller-screen-responsive - A card is more "collapsible" and flexible especially on smaller devices.
Project-focused - As we have moved to a "project" approach, this means a researcher can have more than 1 DMPs - the card gives us some flexibility on displaying multiple DMPs
The number of items - we know that most "normal users" doesn’t have too many active DMPs, so sacrificing some vertical space for more data feels worth it.

The nice thing about the cards is they are quite familiar to the rest of the user interface and mostly mirror the "edit project/plan" view
There is a slight experimental "red dot" to suggest "action required", this is a bit of a discussion point/experiment of having some kind of action require indicator with text that exists on the card explaining the "action". so this might be "related works found", or "Accept invite to collaborate on this project" or something like this.
However, with all that said I did do an "alt" which is more "list-like" below the cards there is a little "Switch to alt view" - which would work like a collapsible panel - where a section of the information is in the "list item" and a panel can be expanded to show more detailed information, These would effectively became cards on smaller devices.

@briri @bofstein @andrewebdev @mariapraetzellis @PaulaReeves @jupiter007 @cazinc

Would it be possible to keep the cards, but allow for the collapsing of some info within the card if there is a lot of data? If most users don't have that many projects, then maybe it's ok not to collapse though. I was also thinking about a mobile scenario where the cards will stack, and then require lots of scrolling, so in that case, it might be nice to have the expand/collapse option.

Just wanted to expand on Juliet point around data density.
I think it would be better to try to make the hard decisions upfront, and trim the amount of data on display - if there are concerns on density.
It's tricky to expand/collapse cards generally because when it is in a grid, you end up with a weird grid where one item in a row has double the height of the rest of the row, never quite works.

@bofstein is it ok to close these wireframe tickets #623, #624, #625

Let's wait to close this until we decide on one of the two options, then when its closed we'll know which is our final wireframe.
I personally prefer the collapsible list view because I think it makes more sense as an ordered list personally; I don't think it needs to show a huge amount of information, as they're generally just looking for the one they want to open, so they need enough to identify it.  Two users so far also preferred it, will see what the next couple say.

@briri as to your question on the 3 feedback tickets, I think we can close the Guidance one since we've made revisions after testing, but we should keep the other two open while we're processing user research testing for those flows.  I'll comment on each.


updating data methods and adding binary search post-hoc sparsity operation

includes related updates to data object
introduced binary search as a method for sparsity enhancement

Thanks for the suggestions Amit.. have included relevant comments.


Maximum file size?

I recorded a long video-call today that lasted 1:23h. Everything worked fine until about 1:10h at which point wf-recorder started printing lots of these lines:
[mp4 @ 0x7f4370000d00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 386544055 >= 64755793
[mp4 @ 0x7f4370000d00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 386544055 >= 64760065

In the resulting file the video is missing after 1:10h. Seeking there with MPV crashes MPV, but VLC plays the file fine and has audio after 1:10h but no video.
No extra args beyond --audio were provided. Version is 0.2 on Void Linux.

Duplicate of #78. Please try latest.

Also worth mentioning, there is a 0.2.1 release which already has a fix for this bug, you might want to report the package to be updated.


Export setup symbols if appropriate

This exports the *_setup symbols when compiling with MSVC so that pure-data can find them when loading the objects.
On UNIX platforms this is not necessary at the moment because the default symbol visibility is set to default at compile time.
This includes the CYCLONE_SINGLE_LIBRARY definition in preparation for another PR I will submit soon where I add an option to create a single library including all cyclone objects as including so many libraries is not very practical for us.

This includes the CYCLONE_SINGLE_LIBRARY definition in preparation for another PR I will submit soon where I add an option to create a single library including all cyclone objects as including so many libraries is not very practical for us.

what do you mean by " including so many libraries is not very practical for us"?

At the moment one library is generated for each cyclone object. That amounts to 193 (times two as we build release and debug). In our organization it would be confusing and impractical for our colleagues to have 386 new libraries actually belonging to cyclone.
That is why I will add an option to build all cyclone objects into one single library.

At the moment one library is generated for each cyclone object.

I see, what you call "library" is what I call a binary. In Pd context, the library is the set of objects and they can be separate single binaries, and there's nothing wrong with that as it is usual. In fact, there can be advantages in a setup like this and is what's common in regards to libraries.

that amounts to 193 (times two as we build release and debug). In our organization it would be confusing and impractical for our colleagues to have 386 new libraries actually belonging to cyclone.

Now I'm curious, who are "we" and "our organization"? How are you using cyclone and Pd?

I see. I agree that there is nothing wrong with many separate binaries. It would just be impractical to us.
Anyway the single library build option is a separate issue and exporting the setup symbols is actually necessary when compiling them as separate libraries/binaries with MSVC.
I cannot name the "we" here, as it could be understood as some kind of endorsement.
I build libpd as a dynamic library and cyclone as another dynamic library that links to libpd.

and what about the abstractions in cyclone? how would that work in libpd?

The CYCLONE_SINGLE_LIBRARY definition actually corrupted the [cyclone] library binary, as discussed in https://github.com/porres/pd-cyclone/issues/434 - this pull request fixed it https://github.com/porres/pd-cyclone/commit/42f5dcec7b205a2b0c9e0fcbd7e641faa2061a4d
I'm going ahead and also remove the single_lib.c.in file as it's not doing anything as it is..

This could be fixed in a different way. The whole thing works fine if compiling with CMake. The single_lib.c.in is a template file where calls to the objects activated are added. The method is then called in the cyclone setup as I have detailed in the Readme. I will add a PR fixing the single library build option for the make build option.

I have detailed how this works in the Readme.

I hadn't actually seen that, amazing work, thanks a lot!
So, is the single library build option working already or what?
We're about to release the final version in the next couple of weeks. I was hoping to include this feature!

Awesome, that's good enough for now, I guess. I'd like to have that built for macOS just to test it out in vanilla and see how it goes.

Yes, the CMake build script works on Windows, Linux and macOS.


As a taq end-dev, I would like the LIGO plugin to provide a template for a contract

Describe the feature you would like
When #915 is implemented, plugin authors can expose named templates (programmable content) that can be instantiated using taq create.
This task is to implement a template for the LIGO plugin called contract which when instantiated, creates a LIGO sourcefile in the contractsDir directory.
The contract template should accept one required positional argument called sourceFileName.
In the handler of the template, we need to examine the sourceFileName file extension and determine what syntax is being requested (jsligo, mligo, etc).
The contract itself should have sufficient comments to help someone get started. The increment contract is probably a good example, although I would make the storage a bigmap with metadata as one of its keys that follows the TZIP-16 spec. Again, as there's multiple syntaxes, we need to write the contract in all LIGO syntaxes.
Lastly, the template handler should register the contract using the SDK method implemented in #907 .
Is this feature solving a problem?
As we now require users to register their contracts, having a template for providing an easy way to create and register a contract at the same time will enhance the end-developer experience.
Please share any additional details you have?
Although #915 needs to be finished before we can test, as we know the interface, we should be able to develop the template nonetheless.
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Closing, as duplicate of #907.


collapse managedFields trash by default

maybe with an option, but also as default behaviour would be okay - nobody needs to see these.

This may help us implement: https://stackoverflow.com/questions/12823456/programmatically-fold-code-in-ace-editor

Or maybe as an entry in the settings to specify which fields should be collapsed by default.

I think we will hold off on this until https://github.com/lensapp/lens/pull/2949 is merged.

This is extremely annoying. I'd prefer a fold or remove ... either way ... it's nothing I care to look at and it's just noise.

If kubectl client can do this, why not leverage that? Forget the fold, just make it an option to filter it ... folding seems overkill.

I'm quite surprise to see this issue. Coming to Lens, there are a few differences first the metric doesn't use metric server like k8s Dashboard then the edit doesn't the same with kubectl edit. This is not the same DX, took sometime to figure out it is Lens issue.
At first, I thought this is something to do with k8s, then > 1.21 already hide by default. Then I thought my k8s issue and looking for if there a default to set. Finally realize it is only edit on Lens.
I'm not sure how Lens edit get the yaml to be applied but I believe it must be the same with kubectl edit. Please decide where to go for this issue.

I'm not sure I follow you statement. I use kubectl to edit resources ... and I don't see the field mapping. I do certainly see the field mapping for managedFields when I edit a resource in Lens. Where Len's is picking that up, I assume it's direct from the API call. As of kubectl 1.18, it actively filters it ... why can't Lens do the same?
https://stackoverflow.com/questions/62077977/kubectl-get-o-yaml-is-it-possible-to-hide-metadata-managedfields/67056145

@alan-marcinkowski Yeah, that's what I mean and the same question too. kubectl edit can, why not Lens.
I forgot to add about your last comment, I do agree to forget about the fold and just make the experience the same.

How does this work under the hood? Does Lens call kubectl get deploy -o yaml? The reason I ask is that that command has an option --show-managed-fields which by default is false and when passed shows exactly the bit that we're asking to hide here. So maybe a checkbox could be added to either use or not use this argument?

Would be so great to be able to hide managed fields in the editor, either with UI option like checkbox or just to save the state when you already collapsed once

Adding my vote that this issue gets addressed.

I think we can close this one because the latest version removes managedFields trash for the editor. It's not meant for humans.


[Feature Request] Make Shortcuts Tab Bar Position Configurable

Describe the bug
By default the tab bar with shortcuts is displayed at the bottom of the screen for smaller widths and at the top for larger viewports. This can not be what the user expects / desires, e.g. on on a vertical iPad Mini, I’d expect the shortcuts to be at the bottom for easier reach (they are at the top), while in a narrow window to the side on desktop, I’d want them at the top.

Which site: dev.phanpy.social
Which instance: mastodon.design

To Reproduce
Enable shortcuts, have them display as tabs and scale the window size / open the site on a small tablet.
Expected behavior
I’d expect the positioning of the tab bar to follow platform conventions and not be tied to device size.
Additional context
I think instead of trying to be smart about the positioning by figuring out in what device Phanpy is running on, there could just be an additional option in the shortcut settings to specify where the bar (and perhaps even the action button) should be placed.
Thank you for the time and effort you’re putting into this client! 😊

Two questions:

If using it on iPad Mini in landscape mode, do you expect the shortcuts tab bar to be at the top or bottom?
Re: "in a narrow window to the side on desktop", do you mean a small-width window on a large desktop screen?

Yes, I would. I think they only make sense at the top when using a mouse
cursor. That may be a personal preference though—I'm not exactly sure what
the official guidelines are for the platform.

Yes, I mean a narrow / small-width window on a large screen. For example
when keeping it open next to the things I'm working on.

I hope that clears things up a little! 😊
Chee Aun @.***> schrieb am Mo., 30. Okt. 2023, 04:23:

Two questions:

If using it on iPad Mini in landscape mode, do you expect the
shortcuts tab bar to be at the top or bottom?
Re: "in a narrow window to the side on desktop", do you mean a
small-width window on a large desktop screen?

—
Reply to this email directly, view it on GitHub
https://github.com/cheeaun/phanpy/issues/289#issuecomment-1784414761,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADUQN7ZJAUFZCTGYKZPRG3LYB4MUXAVCNFSM6AAAAAA6UWEGLGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBUGQYTINZWGE
.
You are receiving this because you authored the thread.Message ID:
@.***>


Add full-text search field

Builds on @bsobhani's commit from #76
Closes #59

Added follow-up commits. See commit messages for details. The most important change is that RunSearch now checks to see whether its catalog supports $text queries and degrades gracefully if not. Given a msgpack-backed catalog, there is no text search UI:

and attempting to set SeachInput.text from the console raises an informative error:
In [9]: app.searches.active.input.text = "something"
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-9-2cac80aa1b9d> in <module>
----> 1 app.searches.active.input.text = "something"

~/Repos/bnl/bluesky-widgets/bluesky_widgets/models/search.py in text(self, text)
    369     def text(self, text):
    370         if text and not self.text_search_supported:
--> 371             raise RuntimeError("This catalog does not support text search.")
    372         self._text = text
    373         self.events.text(text=text)

RuntimeError: This catalog does not support text search.

With this change to bluesky_widgets.examples.qt_search:
-from bluesky_widgets.examples.utils.generate_msgpack_data import get_catalog
+from bluesky_widgets.examples.utils.generate_mongo_data import get_catalog

a text search UI now appears

and can be updated from the console:
In [4]: app.searches.active.input.text = "scan"

Thanks, hiding the search if it is not supported is a good idea.


Deploy waring

Warning: Detected "engines": { "node": ">=18.14.1" } in your package.json that will automatically upgrade when a new major Node.js Version is released. Learn More: http://vercel.link/node-version

This really is more of an issue with Vercel than this repo.
It is letting you know that at some point in the future Vercel will default to Node 20 vs Node 18 and that your package.json allows it switch automatically. I am running Node 20 without any issues, so it looks like a false positive and the solution to hiding the warning is going to be specific to Vercel - try changing >= to == to let Vercel know not to upgrade to Node 20 automatically.
Recommend you close this issue.


On Revisions and Publishing to Read the Docs

@MoNorouzi23 @nassimgha @allan8392
I have reviewed the documentation and the README.md and created the PR for the changes. Please review and merge. I also connected Read the Docs with our repository this morning.
After the PR is merged, please review everything again especially for proper writing. Note that please also review our Read the Docs pages to see if there anything that need to be changed. Link to Read the Docs: https://text-processing-util-mds24.readthedocs.io/en/latest/.
If there is no PR or concern raised by 10am on Saturday. I will submit.

Thanks Jerry, I reviewed it on the website and it is well-formed.


Connection, track restriction and protobuf.js fixes

[#111] Fixed connection issues (TrackError: Account subscription status not Spotify Premium)
[#107] Fixed protobuf.js support
Updated track restriction checks to fix Error: Track is not playable in country errors

Note: It sounds like there might be some problems with the new track restriction checks, haven't received enough details to debug this issue..

Just tried out this branch, runs nicely under node 0.12. kudos!

Thanks a lot Dean Gardiner! Your code is working very well :+1:

I am still experiancing the Track is not playable in country "GB" error. However this seems to have resolved the protobuf issues.

Experiencing this error,
Error: Illegal value for Message.Field .spotify.metadata.proto.AudioFile.format: 7 (not a valid enum value)


Question about trained model

Hi, thank you for sharing the project. Can you share the link of trained model?Because of the limit of space of disk, I can't train the model.

you can download pre-trained models here.
pretrained model:[Google Drive]


Wallet synced, old TX uncnfrmed. No TX history on blockchain from all walletdump addresses.

Was cleaning out storage room and stumbled across old PC from 2014. Opened old PC. Saw old dogecoin client. Opened it up.
Exited old version of qt and downloaded most up to date client (1.14.2 WIN 64bit).
Went through the sync process (used bootstrap), but no updates to balance and all transactions remained unconfirmed. TXIDs not in mempool and zero history on the blockchain for the addresses from/to transactions.
I remember the passphrase, but not the wallet address.
Walletdumped and checked all addresses. No history on any of them.
There were no additional transactions added to the TX history after full sync.
Any ideas?
From new client:

Is it possible that those unconfirmed transactions were mined on the wrong side of a fork?

I really don't know. I had a traumatic brain injury in 2014. I wouldn't know where to begin to look to investigate.

Transaction dates on the wallet encompassed between Jan 24, 2014 to Jan 26, 2014.

I wouldn't know where to begin to look to investigate.

You'll want to start up your old client and dump the mempool txs, you can parse them with a dogecoin-tx from your new client and check what the origins of these coins were. Note down the inputs and then compare what happened on the recorded chain using a block explorer.

Sorry, but I'm afraid that's beyond my capabilities.

Is it possible that those unconfirmed transactions were mined on the wrong side of a fork?

Only way he could check this is if he still had the original blockchain at that time and do a comparison of the block hashes against the explorer ?

@PaekNikler once you have your client started (the new version), run the command dogecoin-cli getrawmempool

@PaekNikler Were you able to recover your coins?

No, unfortunately I was unable to sync them. I'm guessing the wallet was from another coin and the file inadvertently placed in the Dogecoin folder.

@PaekNikler Given the amount of coins in the wallet I'd suggest to ascertain if in fact you have a dogecoin wallet, and furthermore, if you do, recover the coins. I can do this work for you. You can reach me at<EMAIL_ADDRESS>to discuss further.


Add Fabric CI/CD GitLab sample

Type of PR

Documentation changes
Code changes
CI-CD changes

Purpose

Add a new Fabric CI/CD sample for GitLab and multi-tenancy

Does this introduce a breaking change? If yes, details on what can break
Author pre-publish checklist

[ ] Added test to prove my fix is effective or new feature works
[x] No PII in logs
[x] Made corresponding changes to the documentation

Validation steps

...

Issues Closed or Referenced

Closes #677

Another note about not renaming the "Deployment Pipelines" in the diagram to "Release Pipelines" or something else to avoid confusion with Fabric deployment pipelines.


publishing latest from master

Proposed changes

Unreleased project version (optional)

Related issues (optional)

Deploy preview for docsdocker ready!
Built with commit 996f2e7d43b572e5b102bb82cd0ad176ddc54d2f
https://deploy-preview-9518--docsdocker.netlify.com


cant autodecode and cant use mp4 format

i don't know if I am doing something wrong here but the autoconversion does not work selecting files manually does work.
[autovideoconverter] Waiting 5 seconds before processing '/watch/BSG_S1_D1 converted/Battlestar Galactica- Season 1 (Disc 1)_t13.mkv'...
[autovideoconverter] Starting conversion of '/watch/BSG_S1_D1 converted/Battlestar Galactica- Season 1 (Disc 1)_t13.mkv' (2a8a7de180491a564e3b3c0d8f8dd766) using preset 'default'...
[autovideoconverter] 1 title(s) to process.
[autovideoconverter] Conversion failed.
also i cant select mp4,mkv etc the only options i can select are

what is happening?

For details about the failure, you can look at log/hb/conversion.log, under the directory you mapped to /config.
MPEG-4 is mp4 and Matroska is mkv.

Hi , thanks for the response. I was not aware those are different names. I
seem to have the issue resolved by importing a profile from my of, also the
auto conversions didn't work as I had the output set to mp4 but my profile
was for MPEG. This resolved it l.
Op za 11 apr. 2020 02:15 schreef Jocelyn Le Sage<EMAIL_ADDRESS>
For details about the failure, you can look at log/hb/conversion.log,
under the directory you mapped to /config.
MPEG-4 is mp4 and Matroska is mkv.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jlesage/docker-handbrake/issues/112#issuecomment-612276178,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIYLJVMDMNLMOMZ3FAYCD7LRL6ZAVANCNFSM4MFEBYDA
.