Test auto-milestone from org member

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


add package.json hint

For non-super-duper experts, it can be helpful to have a hint that those files must be exported, see my struggle and the helpful answer of @Fryuni
https://github.com/withastro/astro/issues/7721#issuecomment-1878267678

Hello! Thank you for opening your first PR to Astro’s Docs! 🎉
Here’s what will happen next:

Our GitHub bots will run to check your changes.
If they spot any broken links you will see some error messages on this PR.
Don’t hesitate to ask any questions if you’re not sure what these mean!

In a few minutes, you’ll be able to see a preview of your changes on Netlify 🥳

One or more of our maintainers will take a look and may ask you to make changes.
We try to be responsive, but don’t worry if this takes a few days.

Hi @nadar! I'm glad that you found a solution that worked for you, and that you want to help others who have the same issue! Thank you for coming to add extra information to the docs.
We really try not to add "notes" and "tips" unless they fit certain criteria. These should be things that are almost not a part of docs at all, but extra, external or tangential things. If the information is truly important, then it should be properly documented as a part of the instructions or explanation.
For example, if it is necessary to also update another file, then we should properly show that file being updated as part of the complete instructions. This does not go in a "note" if it's key information. Would you be willing to revise this to include it at the appropriate step, not using a "note" for things that should have been done in the first place?

Thank you @sarah11918 for guiding me in the right direction. I've revised the sentence and eliminated the note syntax. Hopefully, it's better now. Since English is not my first language, I don't want to mess up the quality of the Astro documentation. 🙂

Those are not the same @VoxelMC
"export": "./dashboard.astro" allows importing that page from the root of the component:
import Dashboard from '@some/integration';

It is equivalent to this:
"exports": {
  ".": "./dashboard.astro"
}

To import from a subpath like this
import Dashboard from<EMAIL_ADDRESS>
Is what requires this export:
"exports": {
  "./dashboard.astro": "./dashboard.astro"
}

The same applied for entrypoints passed to injectRoute
More information here: https://nodejs.org/api/packages.html#subpath-exports

Those are not the same @VoxelMC
"export": "./dashboard.astro" allows importing that page from the root of the component:
import Dashboard from '@some/integration';

It is equivalent to this:
"exports": {
  ".": "./dashboard.astro"
}

To import from a subpath like this
import Dashboard from<EMAIL_ADDRESS>
Is what requires this export:
"exports": {
  "./dashboard.astro": "./dashboard.astro"
}

The same applied for entrypoints passed to injectRoute
More information here: https://nodejs.org/api/packages.html#subpath-exports
It's not an Astro requirement, Node won't even try to resolve the import if it is not declared in the package, so Vite's module loader won't be called, and neither is Astro's Vite plugin.

Ohhhh, that makes a lot more sense. You explained it much better than the npm and nodejs docs, imo! Thanks Fryuni :)

Would love a final review over this content from @nadar and @Fryuni ! (Especially since I proposed shortening the suggestion.)
What is the group consensus here? Do we think this is enough to be helpful in the docs??

Would love a final review over this content from @nadar and @Fryuni ! (Especially since I proposed shortening the suggestion.)
What is the group consensus here? Do we think this is enough to be helpful in the docs??

I think it is a pretty niche case. However, I can see it being a very annoying bug to research if it happens to someone. I agree with shortening the suggestion. I say keep it!
What do you say to it being a :::note aside? Probably no, but a thought!

I think the shortened version is enough, no need to get in the details of how it fails otherwise.
Users will see that on their terminal if they don't follow.
LGTM

Alright, I'm going to take this all as NWTWWHB!
(PS: Not a "note" because it's actually a required step. All the asides are for things outside of "normal procedure")


upserting entity with ManyToMany

When upserting an entity with A ManyToMany relationship I get a Foreign Key constraint failed exception on the Junction Table entity because it already exist in the JunctionTable. When I set through it with debugger all the entity have CascadeMode.UPSERT in the EntityWriter but the Junction Table has CascadeMode.INSERT when it tries to insert the same object which has previously been inserted.
Shouldn't it have CascasdeMode.UPSERT since it has a valid primary key?
The entities I use are below.
@Entity
public interface Thread {
    @Key
    String id();

    @Column(nullable = false)
    String subject();

    @JunctionTable
    @ManyToMany
    List<AccountEntity> participants();
}

@Entity
public interface Account {

    @Key
    String id();

    @NonNull
    @Column(nullable = false)
    String email();
}

Thanks for reporting will try to reproduce this, but yes sounds like it should be upsert in the chain.


okular pulls in mbrola worth > 600 mb

This should be an optional dependcy

$ nix-instantiate --eval -A okular.outPath '<nixpkgs>'
"/nix/store/6c0h3b3a3p8qnhjipmxjfygsdqr027i8-okular-22.08.3"
$ nix-store -qR /nix/store/6c0h3b3a3p8qnhjipmxjfygsdqr027i8-okular-22.08.3 | grep mbrola
/nix/store/cfzmf36asbcjiq5h4pn4fznzk6rqc4gn-mbrola-3.3
$ nix why-depends /nix/store/6c0h3b3a3p8qnhjipmxjfygsdqr027i8-okular-22.08.3 /nix/store/cfzmf36asbcjiq5h4pn4fznzk6rqc4gn-mbrola-3.3
/nix/store/6c0h3b3a3p8qnhjipmxjfygsdqr027i8-okular-22.08.3
└───/nix/store/fazbdx73b4w17sd0mvphdbpm7zci38nw-qtspeech-5.15.7
    └───/nix/store/cl38aj8cxhfjjraic8r4dks29gq0yqig-speech-dispatcher-0.11.2
        └───/nix/store/cfzmf36asbcjiq5h4pn4fznzk6rqc4gn-mbrola-3.3

Would have to be made an optional dependency here:
https://github.com/NixOS/nixpkgs/blob/cc1bb678f4205ad1c4db34c20b4327cb2cc89a93/pkgs/development/libraries/speechd/default.nix#L42-L48

I can suggest you add an overlay disabling all heavy speech synthesizers backends, as I did for my config:
arcanPackages.espeak = super.arcanPackages.espeak.override { mbrolaSupport = false; pcaudiolibSupport = false; sonicSupport = false; };

This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/switch-cache-nixos-org-to-zstd-to-fix-slow-nixos-updates-nix-downloads/23961/44

It's also pulled by GNOME parts, including the ISO.  Or at least it was, recently:
https://github.com/NixOS/nixpkgs/issues/159612
I agree that such huge speech synthesizers should not be contained in defaults (of DEs, ISOs, and other packages except those very focused on speech synthesis)

(Sorry, miss click)

Same with kmail. mbrola needs to be explicitly enabled, it's too big :-(

I am not sure if this is actually worth it unless we also drop mbrola from chromium. I had an overlay for this locally before but there is not point in having it when I need to compile chromium.

I think it may be time to just disable it by default.
A few questions before we do that:
Does our speech synth even work?
Why does the data need to be compiled into the respective apps?
Could they not look for data via env vars instead?

Alright, I had a quick look at what we're doing at it seems we hard-code the output path of the voices into espeak-ng.
What we should instead be doing IMO is:

Ask upstream to provide a better mechanism for providing mbrola voice data to espeak-ng than a hard-coded path (i.e. env var)
Patch the espeak-ng discovery algorithm to look for data in /run/current-system/sw/share (NixOS compat) and then in /usr/share (non-NixOS compat) instead of hard-coding mbrola-data
Properly split mbrola outputs (current drv is just weird, it already has two separate drvs but they're symlinkJoined? Why?)
Provide a mechanism in NixOS to optionally install mbrola-data for espeak system-wide, disabled by default.

https://github.com/espeak-ng/espeak-ng/issues/1779

Why don't we patch espeak-ng to use /run/current-system/sw/share in https://github.com/espeak-ng/espeak-ng/blob/master/src/libespeak-ng/synth_mbrola.c#L93 ?

@dotlambda we're currently patching it to use /nix/store/...-mbrola/share.
Doing that instead (and perhaps also /usr for non-NixOS people) is what I meant with step 1.

1. Patch the espeak-ng discovery algorithm to look for data in `/run/current-system/sw/share` (NixOS compat) and then in `/usr/share` (non-NixOS compat) instead of hard-coding mbrola-data

$XDG_DATA_DIRS and $NIX_PROFILES/share may be better choices. That's exactly what we are doing with aspell dictionaries.

still suffering :-(


Update  projects

See the 404 found in
https://github.com/dkhamsing/open-source-ios-apps/pull/538

@dkhamsing Hi! I have tried to check them but couldn't find anything.. What do you think about this?

what do u mean you couldn't find anything? your change look ok..

could u also remove these

[L169] 404 https://itunes.apple.com/app/lunchify/id1099214692
[L170] 404 https://itunes.apple.com/app/bat-loves-bugs/id969817533
[L173] 404 https://itunes.apple.com/app/space-zero/id1141164238
[L176] 404 https://itunes.apple.com/app/codesprint/id1148072754
[L188] 404 https://itunes.apple.com/app/terrarium/id891232736
[L198] 404 https://itunes.apple.com/app/token-wallet/id1200463445
[L217] 404 https://itunes.apple.com/app/fusecloud/id1173516856

@dkhamsing I meant that I was hoping to find a few new links instead of existing ones. But, I couldn't find any new links.

Oh yea I think they were removed but thanks for looking
Sent with GitHawk


[strip-frameworks.sh] Force code re-signing after stripping architect…

…ures
Closes #1854.
\c @jpsim @bdash

:+1:


macos metal backend crash with CA_ASSERT_MAIN_THREAD_TRANSACTIONS

Hi!
My app doing render stuff in separate thread (not main), and when I try to run it with env var CA_ASSERT_MAIN_THREAD_TRANSACTIONS=1 (Xcode Instruments run it like this), I see crash in this line.
If comment out described line application works fine, looks like only setAllowsNextDrawableTimeout message make CA transaction under the hood.
Error happens during creating swapchain through wgpu library.
macOS Big Sur 11.2.3
Crash error:
CoreAnimation: CA_ASSERT_MAIN_THREAD_TRANSACTIONS is set and an implicit transaction wasn't created on a main thread.
Thanks.

Wow, that's quite something... I don't know right off the bat how we should be handling this.
gfx doesn't control threading, and we can't launch a helper thread just to do this (would be super awkward).
I wonder if just checking for the thread ID there would be an acceptable workaround? I.e. remember which thread owns the surface, and compare the current thread before calling setAllowsNextDrawableTimeout.
If you want to try this and make a PR, that would be wonderful!


[Feature Request] Remote database connection gives error on Backpack Admin

Feature Request
What's the feature you think Backpack should have?
?? Remote database connection working with Laravel Backpack
Have you already implemented a prototype solution, for your own project?
?? Yes, I tried that but it's showing database schema error.
Do you see this as a core feature or an add-on?
?? add-on.

Hey @munjaldevelopment ,
Not sure I understand the feature request here. Backpack doesn't do anything special about connection with Databases, local or remote. It just plugs into Eloquent. If you DB connection is properly set up, and your Laravel app works with it... so should Backpack, because it uses the same DB connection. So if you're seeing DB schema errors, it's probably not Backpack who is the problem, but your DB connection setup.
Hope it helps.

Hi @tabacitu
I am getting "Schema" error from backpack/setting SettingsServiceProvider.php on this line if (!\App::runningInConsole() && Schema::hasTable(config('backpack.settings.table_name'))) {
let me know if this helps.


Added Sequence.count(predicate)

Returns the number of elements in the sequence that pass the predicate.
It could also have been implemented as:
count(f) { reduce(0) {|a, b| f.call(b) ? a + 1 : a } }

But I considered the simple version more readable.
Also documented Sequence.count.

Cool idea. Do you think it's particularly useful? I can't recall wanting this very much when I've worked with collections.

Do you think it's particularly useful? I can't recall wanting this very much when I've worked with collections.

I've needed the function in the past week (while coding in Lua, but still) so I definitely think it is useful. Just consider the alternatives if you get into the situation where you could use this function, and you'll be glad it exists when you do.
Quite short would be list.where { ... }.count, but this is wrong in terms of efficiency. :-)
Also it's pretty common:
Ruby: http://ruby-doc.org/core-2.2.1/Array.html#method-i-count
C#/Linq: https://msdn.microsoft.com/en-us/library/vstudio/bb535181(v=vs.100).aspx

Rebased to latest master to resolve merge conflict.

Quite short would be list.where { ... }.count, but this is wrong in terms of efficiency. :-)

If we're moving to lazy collections, do you think this is still worth adding?

Well, not in terms of memory usage, but it's still a nice shortcut and I think one that is expected to be available (see references to Ruby and C#).

Fair enough. :)

Yay! :-)


Japanese font is not correctly selected

When a document containing Japanese characters is compiled, Chinese fonts are embedded in the Japanese portion of the document and some characters are not displayed correctly. Is there a way to explicitly specify the language of the document?

Yes, it is via \UseLanguage (globally), or \UseOtherLanguage (locally).

The name \UseOtherLanguage seems rather unclear, in the next version I shall also add two equivalent commands under the name \LocallyUseLanguage and \UseLanguageLocally so that you may choose a preferred one to use.

Here is an example:
\documentclass[use indent = false]{einfart}

\AddLanguageSetting[Japanese]{\color{blue}} % Blue for Japanese
\AddLanguageSetting{\color{black}}          % Black in general

\begin{document}

字 % By default it uses the Simplified Chinese glyph, as you observed

\UseLanguage{Japanese} % Switch to Japanese, it is also possible to write "JP"

字

\UseLanguage{Chinese} % Switch to Simplified Chinese

字 \UseOtherLanguage{Japanese}{字} % Locally write in Japanese

%% ONLY WITH THE NEXT VERSION
% \LocallyUseLanguage{Japanese}{字}
% \UseLanguageLocally{Japanese}{字}

\end{document}

I have set the Japanese characters to be rendered in color blue, so the result looks like this:

I hope that I could finish writing the documentation soon, until then I shall leave this Issue open.


make all our generated javascript target es6 instead of es5

This is really just practice for https://github.com/sagemathinc/cocalc/issues/6128 but with a much easier less consequential (there are zero users!) codebase.

It targets es2020.


Multiarch Image not build

Multiarch Image not build
with platforms: linux/amd64,linux/arm64/v8,linux/arm/v7 in one github action job.
Sat, 26 Nov 2022 16:56:56 GMT #18 2495.2 2022-11-26 16:56:55.990 UTC [29650] LOG:  could not bind IPv4 address "<IP_ADDRESS>": Address in use
Sat, 26 Nov 2022 16:56:56 GMT #18 2495.2 2022-11-26 16:56:55.990 UTC [29650] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
Sat, 26 Nov 2022 16:56:56 GMT #18 2495.2 2022-11-26 16:56:55.995 UTC [29650] LOG:  could not bind IPv6 address "::": Address in use
Sat, 26 Nov 2022 16:56:56 GMT #18 2495.2 2022-11-26 16:56:55.995 UTC [29650] HINT:  Is another postmaster already running on port 5432? If not, wait a few seconds and retry.
Sat, 26 Nov 2022 16:56:56 GMT #18 2495.2 2022-11-26 16:56:55.996 UTC [29650] WARNING:  could not create listen socket for "*"
Sat, 26 Nov 2022 16:56:56 GMT #18 2495.2 2022-11-26 16:56:55.997 UTC [29650] FATAL:  could not create any TCP/IP sockets
Sat, 26 Nov 2022 16:56:56 GMT #18 2495.2 2022-11-26 16:56:56.000 UTC [29650] LOG:  database system is shut down

Temporary solution: build each architecture separately.
Anybody have any ideas?

arm64 error, when build in separately job but one workflow:
#9 1327.2 Creating database 'postgis_reg'
#9 1328.0 Preparing db 'postgis_reg' using: CREATE EXTENSION postgis SCHEMA public
#9 1333.5 PostgreSQL 13.9 on aarch64-unknown-linux-musl, compiled by gcc (Alpine 11.2.1_git20220219) 11.2.1 20220219, 64-bit
#9 1333.5   Postgis 3.3.2 - (0) - 2022-11-26 18:25:58
#9 1333.5   scripts 3.3.2 0
#9 1333.5   GEOS: 3.10.3-CAPI-1.16.1
#9 1333.5   PROJ: 9.0.0
#9 1333.5
#9 1333.5 Running tests
#9 1333.5
#9 1333.5  after-create-script ../regress/hooks/hook-after-create.sql .. ok
#9 1333.6  ./core/affine .. ok in 345 ms
#9 1334.4  ./core/bestsrid .. ok in 266 ms
#9 1335.0  ./core/binary ..2022-11-26 18:45:48.175 UTC [29650] LOG:  server process (PID 29936) was terminated by signal 7: Bus error
#9 1336.7 2022-11-26 18:45:48.175 UTC [29650] DETAIL:  Failed process was running: SELECT 'geometry', count(*) FROM tm.geoms_in i, tm.geoms o WHERE i.id = o.id
#9 1336.7 	 AND ST_OrderingEquals(i.g, o.g);
#9 1336.7 2022-11-26 18:45:48.175 UTC [29650] LOG:  terminating any other active server processes
#9 1336.7 Died at ../regress/run_test.pl line 799.
#9 1336.7 2022-11-26 18:45:48.182 UTC [29660] WARNING:  terminating connection because of crash of another server process
#9 1336.7 2022-11-26 18:45:48.182 UTC [29660] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
#9 1336.7 2022-11-26 18:45:48.182 UTC [29660] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
#9 1336.7  failed (psql exited with an error: /tmp/pgis_reg/test_4_out)
#9 1336.8 2022-11-26 18:45:48.187 UTC [29650] LOG:  all server processes terminated; reinitializing
#9 1336.8 make: *** [runtest.mk:24: check-regress] Error 2


NOP opcode

Please, add support for NOP instruction.
patch for tricore.sinc:
was:
# NOP (SR)
:nop  is op0007=0x0 & op0815=0x0 unimpl

# NOP (SYS)
:nop  is op0007=0xd & op0815=0x0 ; op1631=0x0 unimpl

corrected:
# NOP (SR)
:nop  is op0007=0x0 & op0815=0x0
{
}

# NOP (SYS)
:nop  is op0007=0xd & op0815=0x0 ; op1631=0x0
{
}

oh, sorry it looks OK in latest version


missing fwpuclnt API

All APIs and types from Windows Filtering Platform are missing.

PR https://github.com/retep998/winapi-rs/pull/526 from 2017 adds this, but it has yet to be reviewed and merged.


chore(deps): upgrade vue-demi to 0.12.1

Composition API changed ESM file from esm.js to .mjs
https://github.com/vueuse/vue-demi/releases/tag/v0.12.1

Thank you for your PR! I updated vue-demi to 0.12.5 here: https://github.com/vuejs/apollo/commit/af9f20f131667f173c9708a375e24d676c7adf95


Separate location

Here is a "drafty" form of drawing location off of the main ship table to a separate ship_location table.

I was a bit worried about currval(seq) due to the way ID's are handled in the game but I just gave some code a go to test it and there were no complications. There is no reason why we cannot trust currval('ship_id_seq) in the insert into the ship_location table during the my_ships view insert rule.
CREATE SEQUENCE s_seq
INCREMENT 1
MINVALUE 1
MAXVALUE<PHONE_NUMBER>854775807
START 1
CACHE 1;
create table s (
id integer,
val integer
);
create table s_l (
id integer,
val integer
);
create view s_v as select
s.id, s.val sval, s_l.val as slval FROM s, s_l WHERE s.id=s_l.id;
CREATE OR REPLACE RULE s_insert AS
ON INSERT TO s_v DO INSTEAD (
INSERT INTO s(val) VALUES(NEW.sval);
INSERT INTO s_l VALUES(currval('s_seq'), NEW.slval);
) ;
CREATE OR REPLACE FUNCTION id_dealer()
RETURNS trigger AS
$BODY$
BEGIN
NEW.id = nextval('s_seq');
RETURN NEW;
END
$BODY$
LANGUAGE plpgsql VOLATILE SECURITY DEFINER
COST 100;
CREATE TRIGGER d_dealer
BEFORE INSERT OR UPDATE
ON s
FOR EACH ROW
EXECUTE PROCEDURE id_dealer();
-- Run each of these in a different process
INSERT INTO s_v(slval, sval) SELECT 1,1 from generate_series(1,1000000);
INSERT INTO s_v(slval, sval) SELECT 2,2 from generate_series(1,1000000);
INSERT INTO s_v(slval, sval) SELECT 3,3 from generate_series(1,1000000);
--Check to missmatched results
select * from s_v where slval <> sval
-- No Results were returned

There is an alternate perspective of "currval" which involves the function returning the most recently generated sequence value from ANY sequence associated with your DB connection.
Which is perhaps the most terrible behavior possible; it means that if you decided to (say) replicate Schemaverse using Slony or Londiste, you might instead capture sequence values being used as part of the internals of those replication systems.  Horrible, horrible, horrible.
(Poking at docs...)
But if you use currval('specific_seq_name'), it's all good.
A couple years ago, I was working on an experimental domain registry prototype where we were using currval() extremely heavily to establish transaction contexts.  Basically, we'd create a logical transaction:
insert into transaction (id, when, who) values (nextval('tx'), now(), 'my-user-name');
and then, throughout the rest of the DB activity, HEAVY use was made of currval('tx') to reference the transaction context data.
"Oh, what time are we using for this transaction?"  (It didn't have to be NOW() - it was meaningful to backdate/forward date activity.)

select when from transaction where id = currval('tx');

"Oh, who's the user?"

select who from transaction where id = currval('tx');

We'd attach all kinds of additional data to the transaction by joining in extra tables; the key to getting at it was always currval('tx').  And this worked out AOK.  I have a fair bit of faith in currval() :-).


All the countries in a region organised by largest population to smallest

As an organisation, we want to use a computer so that we can see a list of all the countries in a region in population order from largest to smallest.


Update Android CI to use JDK 11.

As described in https://github.com/godotengine/godot-docs/pull/5312, the current specified Java version should be updated to JDK 11.
Note: JDK 11 is required to upgrade the Android Gradle plug-in to 7.0.
Can be cherry-picked for 3.x.

Thanks!


Fix deprecated set-output command with $GITHUB_OUTPUT (Software-5354)

Replaced with updated syntax echo "KEY=VALUE >>$GITHUB_OUTPUT"

@brianhlin I think white space issue should be okay now.


Resolve idependent spanning types when comparing

Issue: #3066
Any feedback is appreciated.

@scoder this also should be close now when #4660 is merged

Superseded by #4660.


Storytell a new paradigm for Virtual Worlds

I don't think the environment should be a primary in the metaverse.
Legos
second grader. enthusiastic about lego, invite a friend, show off cool things they made, teach something about it
what is environement?
could you take the people out of it? no
one observer? get some value (can touch friends lego but not play)
two? blossoms out because now you can synthesize new virtual realities to roleplay on the fly through improv
three? a crowd. chaotic?
can take HMD to 0, but there is still value.
but you can take the environment out of it??

Superseded by https://github.com/V-Sekai/V-Sekai.github.io/issues/358.


Inverted plus/minus logic in the duration

This card allows the user to change the duration of the graph. It even shows + and - buttons for quick toggling:

So, if it's showing "1 day" and I press +, what do I expect? I expect it to increase, possibly to 2 days. Instead, the logic is reversed: it reduces to 12 hours. Similarly, when pressing - I would expect the duration to decrease, but it actually increases.
Maybe those symbols were chosen while thinking about zoom+ and zoom-. However, we already have a zoom button, so those symbols intuitively mean something else.
My suggestion is to just reverse the logic, so that + increases the duration and - decreases it.

uiLayout:
  invertZoom: true

See this issue for more info on why / how / etc if you're curious. For some reason that option flew under the radar and didn't make it in the readme.


put with _deleted: true

This is rebased on #33
With the current implementation, the _deleted property gets encrypted with the other properties, so that a db.put(deletedDoc) will not remove the doc, but create a new revision without the _deleted true property. See https://travis-ci.org/calvinmetcalf/crypto-pouch/builds/128413187 for failing test

I’ve run into another issue when I do the following in the browser (with the _deleted fix, otherwise workaround with localDb.crypto('password', ignore: '_deleted'):

create a doc in local db (crypto)
sync with remote db (CouchDB)
delete local doc
sync with remote db
doc is not deleted in remote CouchDB. Reason seems to be that the POST _bulk_docs request has no _revissions key for the deleted doc.

I tried to write a test for it but it just passes:
test('sync deleted docs', function (t) {
  t.plan(1);
  var dbName = 'thirteen';
  var remoteDbName = 'fourteen';
  var db = new PouchDB(dbName, {db: memdown});
  var remoteDb = new PouchDB('http://admin:funkyfresh@localhost:5984/crypto-couch-test', {db: memdown});
  db.crypto('password')

  var doc = {_id: 'baz', foo: 'bar'};
  db.put(doc).then(function (result) {
    doc._rev = result.rev;
    return replicate(db, remoteDb);
  }).then(function () {
    return remoteDb.get('baz');
  }).catch(function (err) {
    t.error('should find doc after sync');
    throw err;
  }).then(function () {
    return db.remove(doc);
  }).then(function () {
    return replicate(db, remoteDb);
  }).then(function () {
    return remoteDb.get('baz');
  }).then(function () {
    t.error('should not find doc after syncing delete');
  }).catch(function (err) {
    t.equal(err.status, 404, 'cannot find doc after syncing delete');
  });
});

function replicate (db1, db2) {
  return new Promise(function (resolve, reject) {
    db1.replicate.to(db2).on('complete', resolve).on('error', reject);
  });
}

Nevertheless I suggest we add _revisision next to _deleted, even without a test

You can reproduce it with this test app: https://github.com/gr2m/crypto-pouch-webpack-app
make this change in entry.js
- localDb.crypto('password', {ignore: ['_attachments', '_deleted', '_revisions']})
+ localDb.crypto('password', {ignore: ['_attachments', '_deleted']})

Then below "local encrypted databse"

Hit add button
Hit sync button
Hit delete button
Hit sync button
Click "open in fauxton", you’ll see the doc that you deleted.


When strongly-typed-Id is the type of Guid, some error occurs!

When I use “new UserId();", there's no compile error in Visual Studio.
But if [strongly-typed-id] is the type of Guid, the new UserId is the default value of Guid and it's not what I want.
So why don't provide a parameterless constructor for Guid type, it just initializes the Guid type with "Guid.NewGuid()";
After doing that, when I use "new UserId();", I can get a correct Guid value instead of the default value(Guid.Empty)  of the structure;

Thanks for your suggestion.
I have updated the project to support it.

Please upgrade LessCode.EFCore.StronglyTypedIdGenerator to the latest version.


iOS: Access HTTP  Response Headers

Environment
Flutter version: 2.10.2
Plugin version: 5.3.2
iOS version: 15.2
Description
What you'd like to happen:
I would like to have the possibility to access all HTTP response headers on iOS.
I am aware that it is possible to access the request headers using useShouldOverrideUrlLoading, but did not find any possibility to access the corresponding response headers.

If there is a request like this:
GET /lauritz.html HTTP/1.1
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_0_1 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Mobile/14A403 Safari/602.1
Host: lauritz-holtmann.de

And a response like this:
HTTP/2 200 OK
Date: Sun, 20 Feb 2022 21:34:30 GMT
Content-Type: text/html; charset=UTF-8

I would like to access all header fields of request and response.
Thank you very much for your feedback in advance! :)

I have the same issue, did you find the solution request http:// connection

No, I did not find a solution, yet.
This issue was opened a week ago and would also benefit from a solution here, I think :)

You can add exceptions for specific domains that still use HTTP in your Info.plist:
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSExceptionDomains</key>
    <dict>
        <key>yourdomain.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <true/>
            <key>NSExceptionRequiresForwardSecrecy</key>
            <true/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
            <key>NSThirdPartyExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSThirdPartyExceptionRequiresForwardSecrecy</key>
            <true/>
            <key>NSThirdPartyExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
            <key>NSRequiresCertificateTransparency</key>
            <false/>
        </dict>
    </dict>
</dict>


Update mrlearning-base-ch5.md

Docs Build status updates of commit e00dae5:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

mixed-reality-docs/mrlearning-base-ch5.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Promise static method gives error

TypeScript Version:  2.2.1

Steps to Reproduce:

Code used

let p = Promise.resolve([1, 2, 3]);
p.then(function (v) {
  console.log(v[0]); // 1
});

Both the compiler and vscode give this error.

src/main.ts(17,9): error TS2693: 'Promise' only refers to a type, but is being used as a value here.

 Promises are not part of ES5. They're part of ES6/ES2015.
To use Promises, you'll need to adjust your lib option in tsconfig (see http://www.typescriptlang.org/docs/handbook/compiler-options.html).

I've run into the same issue, even when targeting ES6.
Trying to compile this:
const p = new Promise<string>((resolve, reject) => { resolve('a string') });

with the following tsconfig.json:
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es6",
        "outDir": "out",
        "lib": [ "es6" ],
        "sourceMap": true,
        "rootDir": ".",
        "types": [ "node" ]
    },
    "exclude": [
        "node_modules",
        ".vscode-test"
    ]
}

results in the following compiler error:
error TS2693: 'Promise' only refers to a type, but is being used as a value here.

I've been fighting against this for a couple days now and have no idea at all what to do.  It does appear to be some kind of bug in the compiler.

@ellismarkf, if you run tsc --listFiles what lib files do you see?

@mhegazy: here are the lib files I see after running tsc --listFiles
/node_modules/typescript/lib/lib.es2015.d.ts
/node_modules/typescript/lib/lib.es5.d.ts
/node_modules/typescript/lib/lib.es2015.symbol.wellknown.d.ts
/node_modules/typescript/lib/lib.es2015.reflect.d.ts
/node_modules/typescript/lib/lib.es2015.proxy.d.ts
/node_modules/typescript/lib/lib.es2015.promise.d.ts
/node_modules/typescript/lib/lib.es2015.iterable.d.ts
/node_modules/typescript/lib/lib.es2015.symbol.d.ts
/node_modules/typescript/lib/lib.es2015.generator.d.ts
/node_modules/typescript/lib/lib.es2015.collection.d.ts
/node_modules/typescript/lib/lib.es2015.core.d.ts

I am unable to reproduce this locally, can you share a repro project that demonstrates the issue?

I had the same issue. Reverting to 2.2.0 solved it for me.

> tslint --fix --type-check --project .

Error at src/Server.ts:102:20: 'Promise' only refers to a type, but is being used as a value here.
Error at src/Server.ts:133:20: 'Promise' only refers to a type, but is being used as a value here.
Error at src/Server.ts:149:20: 'Promise' only refers to a type, but is being used as a value here.
Error at src/Server.ts:165:20: 'Promise' only refers to a type, but is being used as a value here.

my tsconfig.json
{
    "compilerOptions": {
        "module": "commonjs",
        "target": "es6",
        "outDir": "dist",
        "rootDirs": [
            "src",
            "test"
        ],
        "sourceMap": true,
        "declaration": true
    },
    "exclude": [
        "node_modules",
        "dist"
    ]
}

I have the same issue if I delete my tsconfig.json file (my TS config is in my webpack configuration in the ts-loader options).
If I create an empty tsconfig.json, no more errors!
TS version 2.2.2

Try to add :
 "lib": [             "es6"         ]
to compilerOptions, then go to close the file and open again, just for refresh ...
worked for my project...

I failed to follow up, I ended up using the "lib" option, but what my intent was that TypeScript knows I specified target "es5" that needs a polyfill for promises  on the browser. However I am using Node and what I found odd was that I also need to specify "dom" within lib. I would be happy with TypeScript being smarter to not have me specify the "lib" part in the configuration.

but what my intent was that TypeScript knows I specified target "es5" that needs a polyfill for promises on the browser

TypeScript does not inject polyfills into your code. The assumption is you will include these independently.

Well TS does something when I add lib: [ "es5", "dom" ], so I can use promise in Node with es5. I don't see the point of me having to do this, if I already set target to "es5". My point is make the configuration smarter. One thing most people don't like about TS is dealing with confusing configuration and typing error eating up all their time.

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy yep

I made it!
The problem is that Typescript doesn't add polyfills for you, so you have to add them.
npm install --save es6-promise
and then
import { Promise } from 'es6-promise';
wherever you need promises. This is my tsconfig.json
{
    "compilerOptions": {
        "module": "es6",
        "target": "es5",
        "outDir": "dist",
        "rootDir": "src",
        "sourceMap": true,
        "lib": [ "es6", "dom" ]
    },
    "include": [
        "./src/"
    ],
    "exclude": [ "node_modules" ],
    "compileOnSave": true
}

Could someone explain why the code in the following repository doesn't work? I think I've stripped everything down to the most simple version possible and I still get the Promise error. https://github.com/danielcovill/typescript-issue

Still having this issue; these little errors are annyoing

See a solution here: https://stackoverflow.com/a/51334882/984471


core-plugin-api: Improve API docs

Signed-off-by: Johan Haals<EMAIL_ADDRESS>Hey, I just made a Pull Request!

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[ ] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[ ] All your commits have a Signed-off-by line in the message. (more info)

Too slow 👴. Community member beat me to this task ❤


Tag functions explicitly for shared library visibility

Functions tagged, makefile updated, LuaRocks rockspecs updated.

Addresses #139

I just merged the pull request, but didn't see the pragmas. It's not that we need them. We didn't even need to mark all internal symbols. I still think this is not a good solution. It is best to have the default  be hidden, and only mark explicitly the three symbols we want to export. The best way to do this is to use the compiler option. The second best is to use the pragmas, because one day somebody will add an internal function to LuaSocket and forget to add the LUASOCKET_PRIVATE decoration. If this happens and the default still is hidden, no problem. The user simply forgot to document the fact that he expects a given function to be private.
I think LuaRocks is wrong (twice). Once for not using this option by default for every library. And again for not using it for LuaSocket since we do that explicitly in the makefile. This problem will bite somebody else in the future. It may even bite us. :(

I agree completely.  I'm actually still working on the pragma approach.  (For some reason I'm getting a relocation error in the link phase.)  And I'm also not done trying to coerce LuaRocks into using -fvisibility without going all the way to build.type='makefile'.  But if we eventually have to go there, so be it; that'll still be better than this, for the reasons you just articulated.

I never used the pragma myself. Maybe it changes something besides the visibility? when you compare the object file generated with -fvisibility=hidden and with no -fvisibility but with the pragma, do the symbols end up in a different section?

I'll look into that.  On a related topic, how do you feel about using strip during the install phase of the makefile?  It seems that distros commonly do that when they package builds.  Seems appropriate for non-debug builds.

The binary is indeed smaller. 6x smaller sounds a lot, but the library is 360k before stripping... :) I don't think it makes much difference.
In Mac OS X, I saw no difference. But removing the MACOSX_DEPLOYMENT_TARGET did reduce size.


[Backport release-24.05] mosquitto: 2.0.18 -> 2.0.20

https://github.com/eclipse/mosquitto/blob/v2.0.20/ChangeLog.txt

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Includes the fix for CVE-2024-3935.


Feature/additional tag specifications

what

Adds additional tag_specification blocks

why

Spot requests are not currently getting tagged

references

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/launch_template#tag-specifications

/rebuild-readme

/test all

/test all

It looks like the template module has been deprecated: https://registry.terraform.io/providers/hashicorp/template/latest/docs
I'll look at this later today when I have a few minutes.

/test all

/test all

/test all

/test all

/test all

@tthayer After #39 merges, please rebase and update this PR.

This would be better as a dynamic using a list to feed into resource_type.

/test all

/test all

/test all

/test all

/test all

Thanks for picking up this PR @nitrocode !

np! If you noticed, I removed the original default of
  tag_specifications_resource_types = ["instance", "volume", "elastic-gpu", "spot-instances-request"]

because the elastic-gpu failed when I did not use elastic so I figured an input variable that can be modified depending on what you need would be the best of both worlds.

/test all


Fix Swagger Anchor links

Fix integrity value, add SRI to CSS, bump Swagger UI version
Add a workaround to make scrolling work

Linked Issue
Closes #5940

Change Description
Background
See #5940 for full details. tl;dr anchor links within the Swagger page don't work (they don't scroll to where they should)
Bug Fix
Add a bit of JS to parse the page's URL for an anchor, find that in the DOM, and scroll to it (taking into account the header height)
Testing Details
Tested manually

Thanks. Suggest to perform the lookup once inside the onComplete callback
let me know if you need help.

@rmoff this is what I've hacked that worked for me (I was using the latest swagger ui bundle):
        onComplete: function() {
            const elemId = window.location.hash.replaceAll('!/', '').replaceAll('/', '-').replaceAll('#', '');
            const elem = elemId && document.getElementById('operations' + elemId);
            if (elem) {
                elem.scrollIntoView();
            }
        }

Closing this one a new fix pr with updated code will address the issue.


Protect VmCtx and ID_COUNTER with RwLock

    Protect VmCtx and ID_COUNTER with RwLock

    AtomicU64 causes compilation issues when used as a subcrate of another
    crate when the toolchain configurations conflict. The problem was observed
    with ID_COUNTER when Polkadot SDK was compiled for riscv32emac, which could
    not be found from core.

    The documentation also states that:

    "This type is only available on platforms that support atomic loads and
    stores of u64."

    Address this by protecting ID_COUNTER with `spin::RwLock` and `VmCtx` with
    `std::sync::RwLock`.

Noteworthy argument is also that a register state itself is an atomic state. Using atomic for different registers does not guarantee this any better than u64.

Turned this into draft to give some peace to finalize my idea/PoC. I'll undraft it when I seek for comments.

This is from discussion where the conclusion was that kernel will never use Rust's atomic type, as it BTW does not use C's atomic types:
<EMAIL_ADDRESS>Linus is absolutely correct in what he is saying here. Generally language provided atomic is types are unreliable and should be avoided when there is no actual need. By heavily deploying atomic like it is deployed like now in the code base without compiler we make the code only more sensitive to the compiler bugs. And also incompatibilities as documentation specifically says not to support AtomicU64 on 32-bit architectures.
Also in most cases where atomic is used and where I migrated to plain u64 it has no value. E.g. register state is defined as the atomic snapshot of all registers.
To summarize that using more coarse locking we make the code more robust and compatible despite some minor differences in the environment.
Thus, I ended up that better granularity is to protect VmCtx and ID_COUNTER. This should make the code a factor more reliable too: you can change this with the lock and be sure that all other threads see only the final state.
In the crates I used spin, which I've previous used in https://github.com/enarx/enarx and also Google recommends this crate for bare metal, which also PolkaVM is (it is software-define bare-mental or this is how I like to think of it):
https://google.github.io/comprehensive-rust/bare-metal/useful-crates/spin.html

From Google's recommended bare metal I'd also recommend to check out:

https://github.com/rcore-os/buddy_system_allocator
https://github.com/Lokathor/tinyvec
https://github.com/google/zerocopy/

E.g. we could in future consider do we need our own allocator or would widely use allocator crate do the job (out-of-scope but it is just one thing I've spotted where we could tighten up).

One thing noticed: convert Box to Arc:

Box: drop + free
Arc: drop

One thing noticed: convert Box to Arc:
1. Box: drop + free

2.


Consider migration from ZenHub to GitHub Projects

I'll put together a proof of concept this month for team review in December.

@hancush confirming I'm able to access it. Looks great!


Fix target for doc test cross compilation

for target paths Compilation::target only contains the shortened file name, but we need to pass the full path to rustdoc

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Thanks!
It seems like Compilation.host and Compilation.target only exist for doc tests. Perhaps those should just be removed?  Then run_doc_tests can just look at the build_config to decide what to do.
Also, can you add a test for this?  There are some examples in custom_target.rs.  There is documentation for writing tests in CONTRIBUTING and cargo-test-support.

It seems like Compilation.host and Compilation.target only exist for doc tests. Perhaps those should just be removed? Then run_doc_tests can just look at the build_config to decide what to do.

Compilation is part of the public api though so removing host and target is technically a breaking change

Also, can you add a test for this? There are some examples in custom_target.rs. There is documentation for writing tests in CONTRIBUTING and cargo-test-support.

there is a similar bug #71002 in rustdoc that needs to get patched first. when that pr is merged I can add tests

Compilation is part of the public api though so removing host and target is technically a breaking change

Cargo's public API isn't stable, so each release is a breaking change.

It seems like Compilation.host and Compilation.target only exist for doc tests. Perhaps those should just be removed? Then run_doc_tests can just look at the build_config to decide what to do.

I played around with this and it seems to me that removing those two attribute results in messy/more complex code, so imho it's not worth removing them.

Hm, ok, I see that doctests have the unusual behavior that --target HOST still needs to work.
Perhaps add a comment explaining that, perhaps along the lines of "Use rustc_target() to properly handle JSON spec paths.".
Let me know if you have any issues adding the test.

Let me know if you have any issues adding the test.

okay so the fix in rustdoc got merged this morning, so I'm guessing it should be in the next nightly version. I'll try adding the tests tomorrow (and the comment regarding rustc_target)

the custom targets obviously can't use std, so exiting cleanly is a bit of a challenge. the only way I can think of right now is by using inline assembly and manually calling the system calls to exit. the downside of this approach is that it wouldn't be cross platform

Hm, I'm wondering, are you somehow using json specs to build std?  I'm having a hard time imagining an environment where these kinds of tests would even work.  (I'm only familiar with using specs with no_std.)

I'm using it for my os kernel using the bootimage/bootloader crates which procss the compiled binaries into a disk image

Can you say more of how that would work? Without std, I don't think the tests will work (maybe with a custom test runner, but those don't work with rustdoc afaik).

correct. i'm using custom test frameworks for normal tests. doctests are actually just small programs that all get compiled and executed individually.
usually rustdoc wraps the code in a main method, but if it detects that you wrote your own, it will use that instead. that way you can also use outer attributes like #![no_std] or use extern crate.
so in my case I have some hidden code in the doctests that runs the os initialization and the os uses qemu's exit decice feature to stop itself and signal whether the tests ran successfully. if i remember correctly i think i managed to get it to work at one point by manually fixing all the target path bugs.
i checked some cross compiled binaries earlier and it seems like they were normal elf files (im not sure if thats the default or if it is influenced by some config key i set). those elf files also had an entrypoint, so i was able to open them in a debugger (they pretty much instantly segfault, but thats probably caused by my kernel trying to setup memory and not because they're inherintly broken)

That is an impressive level of dedication to get doctests working! :smile:
Considering that getting an actual doctest working will likely be very difficult, perhaps it should just have a test that cargo passes the correct --target flag to rustdoc.  So maybe in custom_target_minimal, add something like the following:
    // Ensure that the correct style of flag is passed to --target with doc tests.
    p.cargo("test --doc --target src/../custom-target.json -v -Zdoctest-xcompile")
        .masquerade_as_nightly_cargo()
        .with_stderr_contains("[RUNNING] `rustdoc [..]--target [..]foo/custom-target.json[..]")
        .run();

with the goal just to check that it passes the correct form of --target. How does that sound?

sounds good to me

Thanks!
@bors r+

:pushpin: Commit e5d9b034ec7e4a2513f0f7600139a0b81274406f has been approved by ehuss

:hourglass: Testing commit e5d9b034ec7e4a2513f0f7600139a0b81274406f with merge 6d76d7cc9893d7e831613303e7c34adbe9fe50cb...

:sunny: Test successful - checks-azure
Approved by: ehuss
Pushing 6d76d7cc9893d7e831613303e7c34adbe9fe50cb to master...


Make MicroWin perform certain tasks based on Image Type (Home, Pro, LTSC, etc...) & Image Language

Is your feature request related to a problem? Please describe.

Currently MicroWin, as far as I understand, perform actions regardless of the Image Type, making it treat LTSC versions like it's Pro or Home Editions, and so on.. or have International Language Version of Windows be treated like other languages, as certain languages have some packages removed due to reasons unknown to us, or for example, Microsoft complying to EU's Policies, or other reasons as well.
Describe the solution you'd like

I'm not experienced with MicroWin's Code base.. but, if it's possible to get an Image type & language, we could do a State Machine (or a Finite one) that'll do certain tasks for specific editions and languages.
Describe alternatives you've considered

There's probably other ways that I haven't thought of.. so this's up to the people who know what they're talking about (i.e. not me 😆)
Additional context

In the end.. this's just a suggestion, no pressure to do it if nobody wants this added complexity into MicroWin.

Yeah I was thinking that maybe an toggle our button for an expert mode
I do agree with Mr. Titus, with the concept that MicrWin, should be very easy to you.
Me being new at game, I am that guy that would get lost on how to do something.

It would be really nice to have an "expert" toggle that lets us choose what to disable and what to keep.
Once toggled it will show more options to check for example:
To delete Ms store but to keep the gamebar as it's used by people to record and screenshot.
And in ltsc, AI is already disabled so it doesn't matter if microwin removes it again it's just redundant

Good idea!
I would like to thank you in advance for any assistance that you can
provide in this matter. Please feel free to contact me at the below listed
address, Telephone and/or email.
Richard K. L'Italien
Disable Veteran of the US Army
The Fat Bastard
5637 Monte Corita Circle
Citrus Heights California 95621
(916) 915-3883 http://voice.google.com/calls?a=nc,%2B19169153883
http://voice.google.com/calls?a=nc,%2B19169153883 Voice
(916) 943 4967 http://voice.google.com/calls?a=nc,%2B19169434967
http://voice.google.com/calls?a=nc,%2B19167453437

This communication (including any attachments) may contain privileged or
confidential information intended for a specific individual and purpose,
and is protected by law.  If you are not the intended recipient, you should
delete this communication and/or shred the materials and any attachments and
are hereby notified that any disclosure, copying, or distribution of this
communication, or the taking of any action based on it, is strictly
prohibited.
Thank you.
On Mon, Oct 7, 2024 at 1:29 PM Bash @.***> wrote:

It would be really nice to have an "expert" toggle that lets us choose
what to disable and what to keep.
Once toggled it will show more options to check for example:
To delete Ms store but to keep the gamebar as it's used by people to
record and screenshot.
And in ltsc, AI is already disabled so it doesn't matter if microwin
removes it again it's just redundant
—
Reply to this email directly, view it on GitHub
https://github.com/ChrisTitusTech/winutil/issues/2869#issuecomment-2397830404,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BJPGEYG24MHAEHBESOKHYFDZ2LVIZAVCNFSM6AAAAABPKJ3XS2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJXHAZTANBQGQ
.
You are receiving this because you commented.Message ID:
@.***>


Add relational ops to TTNN

Is your feature request related to a problem? Please describe.
We need a new operation to perform relational operations similar to what was implemented in torch.
ex. gt , le
Following are the ops needed
nez, ltz, gtz, eqz, ne, lez, lte, lt, gt, gte, eq, gez
Describe the solution you'd like
This will perform relational operation between two input tensors and return one output tensor.
Describe alternatives you've considered
It's possible that two ttnn tensor could be converted to a pytorch and then do relational operations with pytorch.  Then the result would be returned by using a ttnn.from_torch operation.
Additional context
The reference implementation in this case is:
import torch

tensor1 = torch.tensor([1, 2, 3])
tensor2 = torch.tensor([4, 5, 2])

result_tensor = torch.gt(tensor1, tensor2)
print(result_tensor)

Merged to main
https://github.com/tenstorrent-metal/tt-metal/pull/5120


adding basic gocron-gorm-lock functionality.

What does this do?
Which issue(s) does this PR fix/relate to?

Adding basic gocron-gorm lock functionality. It should be described in the Readme file.
Important topic to discuss:

It needs the cron_job_locks table to exists in the database because that's where the cron jobs are stored.
it is using a combination of job name + job execution timestamp (precision to miliseconds) to uniquely identify the running job, so it avoids running several times the same jobs.
In order to test the implementation, I needed to add a gorm driver, in this case I used postgres, so the driver is included in the go.mod, but I also tested it with another driver and it works, that's actually the magic of Gorm.

List any changes that modify/break current functionality
Have you included tests for your changes?
I added a test following the convention in gocron-redis-lock, I also added an extra test that checks the uniqueness of the job name + timestamp in the database.
Did you document any new/modified functionality?

[x] Updated example_test.go
[x] Updated README.md

Notes
Any feedback is appreciated.

I updated the PR

Looks like the test is failing

Looks like the test is failing

yes. This is a  problem I discovered some time ago. The miliseconds precision (the one I put by default), gives problems since the operation to lock and unlock sometimes takes quite some time. I decided to change the precision to seconds, and change the test accordingly.

I forgot to update one part of one test

@JohnRoesler could you run the workflows again?

is something else missing?


Refactor mbe parsing code

Inspire by #5426 , this PR refactor out the parsing code such that it only parsed on mbe::Rule, but not on invocations.
However, it just improve the overall performance unnoticeablely :(

This looks slightly better.. I guess?

This looks slightly better.. I guess?

I think so, and let's merge it first and I would try to perf and refactor more in these few days.
bors r+


Expose valuesPerTask and taskIndex to environment provider

Needed if the environment depends upon the values processed by this task.

Coverage remained the same at 95.881% when pulling 1e8e75bc0edf8bb8a1ae04f668d08835b50d2896 on expose-task-environment-to-environment-provider into 4110a8fb19b214d44e79ba8100c62396c8a58be1 on master.


Added Simon Game and Drum Kit

Simon game tests memory power of the user

Drum kit allows to enjoy beats of drum

mention the issue no. and resolve the conflict

@iamrahulmahato I have added the Simon game belonging to issue #131 and also I have added the Drum-kit belonging to issue #138 in the same pull request


Support local development

The problem

When a site is being developed locally, Netlify CMS still makes all changes to the remote repository. This creates a few problems:

you can't use Netlify CMS locally until your site is pushed to a remote
if you do have a remote, all cms changes are occurring there, which causes the local and remote repo to go out of sync, often unexpectedly
you have to make decisions about your site, like where to put the source, when you may not be ready to do so

@mjackson summed it up pretty well:

Proposed solution

From a user/developer standpoint, Netlify CMS running a local environment should work like so:

Run my site locally
Navigate to the CMS on my locally served site
The CMS detects that it is running locally
The CMS automatically activates local development mode (breaking change)
Any work in the CMS affects local files

For most use cases, this should "just work", out of the box.
Technical details
Detect local environment
The CMS can be loaded in many ways, including from a CDN via script tag, even during local development. For this reason, the only generally applicable approach to local env detection is by url. We can provide obvious defaults like localhost and <IP_ADDRESS> and allow a custom url to be configured.
Working against local files
Netlify CMS always expects to run in a browser with no access to servers, local or otherwise. Backends bridge this gap. To make changes to data, the CMS as a browser app requires a running server somewhere to access the data to be changed, and a backend extension to interface with that server via API calls.
For local development to work a running server must provide a local URL that the CMS can make API calls against. This can happen in at least two ways:

CLI package
This is the "universal" approach that will work for any setup - a companion package distributed via npm and run via CLI
Tool/starter specific
This approach removes the concern of running a CLI tool from the developer, but requires integration of the local file system server with the developer's tooling. This can be done by providing middleware for specific stacks, (as @talves has done with create-react-app - link), or including middleware in Netlify CMS starters that run with the development server.

UI
This could change, but the UI will likely consist of a conspicuous switch in the top right corner, near the user avatar, perhaps showing green when live and red when local. To make local development mode more conspicuous, another indicator like a color bar and notice at screen top may also be added.
This switch will only be visible if local_backend is configured, which will happen by default only for users of the netlify-cms package.
It will probably happen often that a user hits the local development switch and the server isn't running. We should anticipate this by first ensuring the server is reachable when the switch is flipped, and if it isn't, switch back off and provide notification that the local development server isn't reachable.
Configuration
Sites will often have a live backend and a local backend that have nothing to do with one another, and as backends are allowed to have arbitrary configuration schemas, the local backend configuration should be a separate object with the same allowances. A sample configuration might look like this:
backend:
  name: github
  repo: my/repo

local_backend:
  name: file-system
  url: https://random.local.url:2345

Note that the url key would not be required by the cms, but could be required by the backend in use.
Default behavior
Default behavior will be provided through the netlify-cms package. If no local backend is configured, the netlify-cms package should register and configure the file system backend.
Local development should be switched on automatically when a local environment is detected, but this would be a breaking change, so if this feature is included in a minor release, the switch will remain in "live" mode by default, and local-by-default can be added in the next major release.
Related issues
Resolves:

#329
#1085
#2236

Somewhat related to:

#1795

Coincides with:

#2333

Paves the way for:

#2251

In #2333, I outline the first phase of the configuration defining a development backend and having it trigger a default backend when in development mode. I am not sure if this would meet the Default behavior section above, but we can discuss further if needed. Once a default development backend can be configured in the CMS, we can concentrate on how we solve the adding of a file-system cli to expose the fs-api without a manual configuration.
As mentioned above, if you have a Gatsby or CRA application, it is fairly easy to configure the fs backend if you need/want it during development. The readme's will get you started in those cases.

Hi guys, how's the progress with this issue?

It isn’t in active development, still roadmap. But it’s almost hit the top of our most requested issues in a short period of time, so likely to be prioritized soon. Never stale, this one.
Sent with GitHawk

Just switched from Wordpress to self-hosted Hugo on my home personal server. I'd like to use netlify CMS locally.

Bumping this for good measure. I'm currently in the same boat, configuring Netlify CMS for my Gatsby site, and I'd like to have a valid option to test locally first, rather than having to test remotely.

Best way to move this forward is up vote the issue. This is currently number 3 on our list.

I use this feature with great success. Thanks!
One thing I run into today: When I tried to upload an image (size 442K) during the creation of a post, I got PayloadTooLargeError: request entity too large at readStream at the console where I run npx netlify-cms-proxy-server and Failed to persist entry: SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data on the Netlify CMS Frontend.
The error on the Frontend didn't make any sense. After some minutes I checked the console log. I guess the image is too large and also that this happens only locally. Not sure if this is intended behaviour.

Thanks @ndalliard a fix for that was merged today https://github.com/netlify/netlify-cms/pull/3229/files#diff-216dd90ce734cc01217c9959f0b240d2R14
Apparently express's default for JSON body is something like 100kb

It would be nice to have it also available as a middleware. So it could be easily attached to, for example, Gatsby dev server. Without starting a separate process.

Also, when developing locally you don't usually want to make actual commits when editing content via cms. What you want is just writing changes to local files. What netlify-cms-backend-fs does.

Also, when developing locally you don't usually want to make actual commits when editing content via cms. What you want is just writing changes to local files. What netlify-cms-backend-fs does.

That's actually the new default with the latest version of the proxy server

It would be nice to have it also available as a middleware. So it could be easily attached to, for example, Gatsby dev server. Without starting a separate process.

Our next step is to integrate it into the different SSG plugins

I'm new to react and front-end tech so bear with me, but I'm having some issues following your guidelines. My config looks like this:
backend:
 name: git-gateway
 repo: rebelastronaut/trinity

local_backend: true
media_folder: src/pages/images
public_folder: src/pages/images```

and I run the proxy as stated and it's at the newest version ( 1.1.4) However when I try to publish I get this error coming out of the proxy server:

```"encoding":"base64"}],"options":{"newEntry":false,"parsedData":{"title":"testing","description":"No Description!"},"commitMessage":"Update static_pages “about”","collectionName":"Static Pages","useWorkflow":false,"unpublished":false,"status":"draft"}}}: Cannot read property 'mkdir' of undefined

I've tried a few workarounds but it seems like I'm going round in circles. Any suggestions on how I can learn and develop locally.

@gileshinchcliff can you please open a new issue and share your config.yml and possibly the repo?

@erezrokah sure.

I think we can safely consider this issue satisfied, remaining points will be covered under #3285.
Docs for current support: https://www.netlifycms.org/docs/beta-features/#working-with-a-local-git-repository

Hi, if the local_backend: true is active in a live website this can cause problems?
There are any security issues in that case?

Hi @neokree, the CMS ignores that flag when not running on localhost:
https://github.com/netlify/netlify-cms/blob/72b26f4435b428f79805920566678627e60fffaa/packages/netlify-cms-core/src/actions/config.js#L178
So it should not cause any issues.

Hi, I may be wrong, but this does not seem to work with the editorial_workflow

@idrisadetunmbi, you're correct, by default the local mode works directly on the file system so it has not way of tracking unpublished entries branches, status, etc.
You can set it up to use a local git client using MODE=git npx netlify-cms-proxy-server which will give you editorial workflow support, but requires that you have not pending changes in your repo.

hi @erezrokah I hit the same need to run admin locally and need to test the Editorial Workflow, which I followed here.
The reason why I need to try Editorial workflow is it doesn't work on my live website and the Error message  is very generic and not helpful.

Is there any work around for this? I also need the editorial workflow working locally.

I appears using MODE=git does make the editorial workflow show up but, it doesn't work correctly - it breaks if you try and save anything. Not sure why that is the case.

Hi @alexboots can you please open a new issue for that and add supply the information in the issue template?

Does this feature allow for local development with the cms admin panel, but remote repo management if accessing from netlify url? Can we have 2 configs for different environments? Ideally I'd be able to test out products in local development, and then push the changes made locally to deploy to the real world, but then if the user of the website (not a dev) wants to change something, they can use the cms panel in the real url, and change things on the remote repo. Is this possible?
Another usecase I'd love being supported is having a 2 folders with 2 different repos, 1 fake for development which is used in node_env=development, and a real one which is used for prod, this would allow me to have edge cases to try out in local dev, while the final website is not contaminated.


HOW CAN I USE THIS LIB?

Is there any documentation out there about configuring this library?

Hi @hnwangkg-ezio, please see https://github.com/lancaster-university/microbit-v2-samples, where there are installation instructions. The build system there downloads this library and others.

Hopefully you've found the information you needed in https://github.com/lancaster-university/microbit-v2-samples. I'll close this as resolved, but feel free to reopen if you still have any questions.


object 'knit.only' not found

I keep getting this error when building the document now (and the sensitivity presentation).  Would it be related to issue 544 (https://github.com/cgrandin/hake-assessment/issues/544#issuecomment-461975206)?  I think it started just shortly after that.

the knit("beamer-hake-sensitivities.rnw") approach worked for the presentation build so I assume it will for the document so perhaps I'm good.  I'll leave open until I test the doc build.

Possibly related. Take out the rm(list=ls()) if you need to, I'll just restart R when necessary (I'd rather leave it in, but obviously not if it breaks stuff). (Yes, I put one in the sensitivity presentation).
Think it should only be a problem if you define some global things when you start R, that then get overwritten with rm(list=ls()).
How are you building the .rnw files? The batch files look fine (similar enough to what I do), and I can't find the object knit.only anywhere in any files. And the batch files start an R session anyway. Hmmm.....
Unfortunately, Googling knit.only mainly brings up patterns for making scarves and hats.....

I use build.doc().  And I was too quick to judge on the knit("...") process working, it also failed.  I'll try commenting out the rm(list=ls()) to get this to work for me

I see it in utilities.R:
build.doc <- function(knit.only = FALSE, make.pdf  = TRUE,

Aha - I thought everyone else was clicking the batch file (though you did mention build.doc() the other day).
So, yes, removing everything in R in the first line will presumably remove the function build.doc() and the value of knit.only.
Just delete the rm(list=ls()) from the document then. I'll do it from sens talk.

Sorry for messing it up...

No worries - I need to reconfigure my R environment workflow anyway in
between the 2019 and 2020 assessments. Probably switch text editors also
(Rstudio or emacs likely)..
On Thu, Feb 14, 2019 at 4:07 PM Andrew Edwards<EMAIL_ADDRESS>wrote:

Sorry for messing it up...
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/cgrandin/hake-assessment/issues/564#issuecomment-463853939,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHk_-tdqL69EdWwlnjSYECDryk1oS9vOks5vNfo0gaJpZM4a8oSj
.

--
Aaron M. Berger, Ph.D. Research Mathematical Statistician
Fishery Resource Analysis and Monitoring Division
Northwest Fisheries Science Center
2032 SE OSU Dr. Bldg. 955
Newport, OR 97365-5275
<EMAIL_ADDRESS><EMAIL_ADDRESS>

Emacs! I use it for everything (since 1999.....)

We should clarify/resolve some of these things at our JTC meeting in December. Just need to be aware of how we're all running things slightly differently (which occasionally impacts the running of identical code).

I use sublime and the command line
On Thu, Feb 14, 2019 at 4:13 PM Andrew Edwards<EMAIL_ADDRESS>wrote:

We should clarify/resolve some of these things at our JTC meeting in
December. Just need to be aware of how we're all running things slightly
differently (which occasionally impacts the running of identical code).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cgrandin/hake-assessment/issues/564#issuecomment-463855430,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD6xFPa3lDFIlug2VbPKYcCEPyu3frg2ks5vNfu7gaJpZM4a8oSj
.

--
Kelli Faye Johnson, PhD
Research Fish Biologist
Northwest Fisheries Science Center
National Marine Fisheries Service
2725 Montlake Boulevard East
Seattle, Washington 98112
(206) 860-2465
<EMAIL_ADDRESS>

Ha ha. Yes, no-one's going to change their workflow - just good to be aware of what we're each doing.
Chris uses an abacus.

Sublime and command line sounds closest to me (emacs and command line)....


#5811: Fixed forge fabric8-setup to update the pom.xml with all the d…

…etails and not lose changes.

[merge]


What do you think about integrating node-snowball?

Hey all,
I need a stemmer for romanian and I found node-snowball. What do you think about integrating it into natural?
Pros

support for multiple languages
separate module only for stemming

Cons

uses C library, can't be browserified
project is 2 years old, might be inactive, an october PR hasn't been merged

well based on the number of issues we see on here re browserify it seems like theres a large number of people using natural that way so im not sure we'd be able to integrate something like that right now. Would totally lover to hear what everyone else thinks about it thought

What about this one?
https://github.com/mazko/jssnowball
Is it browserifiable?

Or allow to set a stemmer with a particular API something like:
var natural = require('natural');

natural.setStemmer('en', nodeSnowball); // or whatever

If a stemmer is just a function that recieves a word and return a stem, that could be an option that would allow everybody to use Natural both server and client side, but would also allow those users that needs this only server side to use external stemmers for different languages.

I've been looking into things, and it would be possible to fork the snowball code generator (https://github.com/snowballstem/snowball/blob/743b5af/compiler/generator_js.c#L1272) to emit modern js (or natural specific) stemmers. (personally, I also want to make an assemblyscript version)


Update v0.2.2-beta

Refer to changelogs for more information about this update.

Merging v0.2.2-Beta-Stable-Build with the main branch, refer to changelogs for more information about this update.


DRILL-6268: Drill-on-YARN client obtains HDFS URL incorrectly

DRILL-6268: Drill-on-YARN client obtains HDFS URL Incorrectly
Description
The Drill-on-YARN client must upload files to HDFS so that YARN can localize them. The code that does so is in DfsFacade. This code obtains the URL twice. The first time is correct:
 private void loadYarnConfig() {
    ...
      URI fsUri = FileSystem.getDefaultUri( yarnConf );
      if(fsUri.toString().startsWith("file:/")) {
        System.err.println("Warning: Default DFS URI is for a local file system: " + fsUri);
      }
    }
  }

The fsUri returned is hdfs://localhost:9000, which is the correct value for an out-of-the-box Hadoop 2.9.0 install after following these instructions. The instructions have the reader explicitly set the port number to 9000:
<configuration>
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://localhost:9000</value>
    </property>
</configuration>

The other place that gets the URL, this time or real, is DfsFacade.connect():
    String dfsConnection = config.getString(DrillOnYarnConfig.DFS_CONNECTION);

This value comes back as hdfs://localhost/, which causes HDFS to try to connect on port 8020 (the Hadoop default), resulting in the following error:
Connecting to DFS... Connected.
Uploading /Users/paulrogers/bin/apache-drill-1.13.0.tar.gz to /users/drill/apache-drill-1.13.0.tar.gz ... Failed.
Failed to upload Drill archive
  Caused by: Failed to create DFS directory: /users/drill
  Caused by: Call From Pauls-MBP/<IP_ADDRESS> to localhost:8020 failed on connection exception: java.net.ConnectException: Connection refused;

For more details see:  http://wiki.apache.org/hadoop/ConnectionRefused
(Shout out here to arjun kr for suggesting we include the extra exception details; very helpful here.)
The workaround is to manually change the port to 8020 in the config setting shown above.
The full fix is to change the code to use the following line in connect():
    String dfsConnection = FileSystem.getDefaultUri(yarnConf);

This bug is serious because it constrains the ability of users to select non-default HDFS ports.
Documentation
No user facing changes.
Testing
Unit tests pass.

@paul-rogers Could you check please? I am going to check it on the cluster. Are there any specific cases? Non default hadoop ports, possibly modified yarn config file should be checked or smth else?

@paul-rogers Could you check please? I am going to check it on the cluster. Are there any specific cases? Non default hadoop ports, possibly modified yarn config file should be checked or smth else?

@vdiravka, thank you for taking a look at this issue. It has been a while since I wrote this stuff. I've poked around a bit to refresh my memory of what we were trying to do.
The goal is to have a config system that draws from both the HDFS config and from the DoY config files. When this was written, Drill did not use the HDFS config files; the config info was stored by Drill in ZK. Also, during testing, we might target any number of HDFS systems, so we had to support more than just the local HDFS config file.
Those considerations led us to use a combination of the Drill-style config file and the HDFS config. Note that the DoY config is not the same as the Drill config (though both use the same HOCON library.) There is a chicken-and-egg problem: for the DoY client, Drill is a zip file; there is no actual Drill installed on the machine acting as the DoY client. Also, a single DoY client can run any number of Drill instances. Hence, DoY does not read a Drill config file; the DoY config is a separate entity.
With that background, let's look at the config file:
drill.yarn: {
  app-name: "Drill-on-YARN"

  # Settings here support a default single-node cluster on the local host,
  # using the default HDFS connection obtained from the Hadoop config files.

  dfs: {
    connection: ""
    app-dir: "/user/drill"
  }
  ...

Note that drill.yarn.dfs.connection is supposed to the the target DFS connection. So, if you set that to hdfs://localhost:9000, things should work.
You noted that we obtain the information twice. The code in DfsFacade.connect() appears correct:
  public void connect() throws DfsFacadeException {
    loadYarnConfig();
    String dfsConnection = config.getString(DrillOnYarnConfig.DFS_CONNECTION);
    try {
      if (DoYUtil.isBlank(dfsConnection)) {
        fs = FileSystem.get(yarnConf);
      } else {
        URI uri;
        try {
          uri = new URI(dfsConnection);
        } catch (URISyntaxException e) {
          throw new DfsFacadeException(
              "Illformed DFS connection: " + dfsConnection, e);
        }
        fs = FileSystem.get(uri, yarnConf);
      }
    } catch (IOException e) {
      throw new DfsFacadeException("Failed to create the DFS", e);
    }
  }

We first use the value from the DoY config. If not set, we fall back to the Hadoop config. This behavior gives us what we want: DoY config first, else fall back to the Hadoop config.
The initial note also mentions loadYarnConfig(). This method loads, well, the YARN config. The original thought, IIRC, is that the YARN config points to the YARN services; not the HDFS services. Also, the idea was that DoY works with a single YARN instance, identified by its YARN config. (Now, in reality, I suppose that there must be only one HDFS per YARN.) So, it should not be the case that the YARN config breaks HDFS.
Is it the case, in this instance, that the HDFS server is configured in YARN, but not in the HDFS config files?
At this point, I suspect I've exhausted my YARN knowledge. I can, however, offer a suggestion.
If the YARN config holds (or reads) the HDFS config more accurately than the default HDFS config, then change the connect() method above to use the (cached) YARN config.
Before doing this, I'd recommend researching these issues a bit more in the YARN and HDFS configs. Maybe that fs URI check in loadYarnConfig() is wrong.
It may also be that, to use YARN, you must have a valid YARN config and a valid HDFS config to go with it, so we might not need the DoY connect config. (I suspect this config was added, in part, because MapRFS didn't use the HDFS configs, but I could be wrong.)
So, perhaps do a bit more homework, then we can refine the fix.

@vdiravka, thank you for taking a look at this issue. It has been a while since I wrote this stuff. I've poked around a bit to refresh my memory of what we were trying to do.
The goal is to have a config system that draws from both the HDFS config and from the DoY config files. When this was written, Drill did not use the HDFS config files; the config info was stored by Drill in ZK. Also, during testing, we might target any number of HDFS systems, so we had to support more than just the local HDFS config file.
Those considerations led us to use a combination of the Drill-style config file and the HDFS config. Note that the DoY config is not the same as the Drill config (though both use the same HOCON library.) There is a chicken-and-egg problem: for the DoY client, Drill is a zip file; there is no actual Drill installed on the machine acting as the DoY client. Also, a single DoY client can run any number of Drill instances. Hence, DoY does not read a Drill config file; the DoY config is a separate entity.
With that background, let's look at the config file:
drill.yarn: {
  app-name: "Drill-on-YARN"

  # Settings here support a default single-node cluster on the local host,
  # using the default HDFS connection obtained from the Hadoop config files.

  dfs: {
    connection: ""
    app-dir: "/user/drill"
  }
  ...

Note that drill.yarn.dfs.connection is supposed to the the target DFS connection. So, if you set that to hdfs://localhost:9000, things should work.
You noted that we obtain the information twice. The code in DfsFacade.connect() appears correct:
  public void connect() throws DfsFacadeException {
    loadYarnConfig();
    String dfsConnection = config.getString(DrillOnYarnConfig.DFS_CONNECTION);
    try {
      if (DoYUtil.isBlank(dfsConnection)) {
        fs = FileSystem.get(yarnConf);
      } else {
        URI uri;
        try {
          uri = new URI(dfsConnection);
        } catch (URISyntaxException e) {
          throw new DfsFacadeException(
              "Illformed DFS connection: " + dfsConnection, e);
        }
        fs = FileSystem.get(uri, yarnConf);
      }
    } catch (IOException e) {
      throw new DfsFacadeException("Failed to create the DFS", e);
    }
  }

We first use the value from the DoY config. If not set, we fall back to the Hadoop config. This behavior gives us what we want: DoY config first, else fall back to the Hadoop config.
The initial note also mentions loadYarnConfig(). This method loads, well, the YARN config. The original thought, IIRC, is that the YARN config points to the YARN services; not the HDFS services. Also, the idea was that DoY works with a single YARN instance, identified by its YARN config. (Now, in reality, I suppose that there must be only one HDFS per YARN.) So, it should not be the case that the YARN config breaks HDFS.
Is it the case, in this instance, that the HDFS server is configured in YARN, but not in the HDFS config files?
At this point, I suspect I've exhausted my YARN knowledge. I can, however, offer a suggestion.
If the YARN config holds (or reads) the HDFS config more accurately than the default HDFS config, then change the connect() method above to use the (cached) YARN config.
Before doing this, I'd recommend researching these issues a bit more in the YARN and HDFS configs. Maybe that fs URI check in loadYarnConfig() is wrong.
It may also be that, to use YARN, you must have a valid YARN config and a valid HDFS config to go with it, so we might not need the DoY connect config. (I suspect this config was added, in part, because MapRFS didn't use the HDFS configs, but I could be wrong.)
So, perhaps do a bit more homework, then we can refine the fix.

@cgivre, Revisiting this one. The fix is probably not correct. As explained earlier, the goal is to 1) use the YARN config by default, unless, 2) overridden in the DoY config file. Here is the default config from drill-on-yarn-defaults.conf:
drill.yarn: {
  ...
  dfs: {
    connection: ""
    app-dir: "/user/drill"
  }

The code says:
    String dfsConnection = config.getString(DrillOnYarnConfig.DFS_CONNECTION);
    try {
      if (DoYUtil.isBlank(dfsConnection)) {
        fs = FileSystem.get(yarnConf);

So, if the dfs.connection property is blank, use the one from the YARN config file.
Again, why might there be a different DoY value? Because some users push apps to multiple servers, and the DoY config should be sufficient to do so, without having to have multiple different YARN configs available. (If, in practice, people use only one config, we can remove these DoY configs if not needed. But, let's assume they are needed.)
So, the question is, why did the user see the bug which was reported? Where did the "hdfs://localhost/" value come from? That is the bug we need to fix.
The answer seems to be that someone used drill-on-yarn-example.conf as their config, without inspecting if the example values are useful. (This is an example, not a default.):
drill.yarn: {
  ...
  dfs: {
    # Connection to the distributed file system. Defaults to work with
    # a single-node Drill on the local machine.
    # Omit this if you want to get the configuration either from the
    # Hadoop config (set with config-dir above) or from the
    # $DRILL_HOME/core-site.xml.

    connection: "hdfs://localhost/"

Why is that being used? The proper "default" file is drill-on-yarn-override.conf from distribution. But, it looks like the component.xml file is missing a line. So, maybe the user renamed the example file to drill-on-yarn-override.conf. We need:
    <file>
      <source>src/main/resources/drill-on-yarn-override.conf</source>
      <outputDirectory>conf</outputDirectory>
      <fileMode>0640</fileMode>
    </file>

With the above Maven fix, we don't need to change the code: the code does what it is supposed to do, if given a proper (blank) config entry.
An "extra for experts" fix is to add the updated port number to the example file above.

@paul-rogers
If I'm understanding you correctly, it sounds like the correct edits for this PR is that I need to:

Modify component.xml as noted above.
Add some documentation to explain how Drill is getting the config info.

Does that seem correct?


404 at /reference/commandline/inspect/

I found a broken link : https://docs.docker.com/reference/commandline/inspect/
I arrived on this page through: https://www.ctl.io/

Hi @newcuit , the correct page is https://docs.docker.com/engine/reference/commandline/inspect/. Where at ctl.io do you found the broken link?

Thanks for reporting the broken link. Please report this issue on the source page where the link is located.


ISS-93: support async callback

Adding support for async function
Since this is just for one single method and a limited scope (calling callback function), I've changed the verifiablePresentationFrom to make it async.

Codecov Report

Merging #94 (6285ba5) into develop (a65f137) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop      #94   +/-   ##
========================================
  Coverage    96.85%   96.86%
========================================
  Files           61       61
  Lines         2226     2230    +4
  Branches       489      447   -42
========================================
+ Hits          2156     2160    +4
  Misses          69       69
  Partials         1        1

Flag
Coverage Δ

unittest
96.86% <100.00%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

lib/PEX.ts
96.96% <100.00%> (+0.03%)
:arrow_up:

lib/PEXv1.ts
96.61% <100.00%> (ø)

lib/PEXv2.ts
94.82% <100.00%> (ø)

test/test_data/PresentationSignUtilMock.ts
85.71% <100.00%> (+1.33%)
: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 a65f137...6285ba5. Read the comment docs.

Could you have a look at the test coverage decrease?
Also: I haven't checked in an IDE, but the amount of overlapping code is quite high. I think we at least need to make a ticket for that, as this will utlimately lead to bugs being introduced by changes not reflected in all 3 PEX classes

Please use conventional commits, so changes like this end up in the changelog automatically.
For now it makes sense to create a small commit with "feat: description of the new feature" changing for instance a line in the README, so that at least the changelog reflects the work

Please use conventional commits, so changes like this end up in the changelog automatically.
For now it makes sense to create a small commit with "feat: description of the new feature" changing for instance a line in the README, so that at least the changelog reflects the work

added


geode not loading

Geode Issue

[X] I confirm that this bug is NOT related to a mod but directly to Geode Loader itself.

Platform
Windows
SDK commit
3ab7077
Geode Version
Pre-release commit 3ab7077
Mods Installed
gamemode picker,globed,icon_hack,custom keybinds,node ids, texture loader,unlisted objects in editor,openhack and click between frames

Expected Behavior
expected it to open and load normally(the version supported 2.206)
Actual Behavior
gave an error code thats 1114
Steps to Reproduce
install pre-release build and open the game and it gave the error code 1114
Additional Information
i have icedcave texture pack along with the icons and menu icons with futura ui

i tryed to open geometry dash with geode installed it just gave me an error code 1114, what is causing it?

idk i have som proplem

idk i have som proplem

you are having the same problem?

i try the same thing, but it doesnt gives me a error.
it just doesnt load

i try the same thing, but it doesnt gives me a error. it just doesnt load

in that case which build are you using with geode? im using nightly

i believe texture loading mod has some problems, so maybe remove it from your folders and try again? that a lot of my issues with geode not working correctly

update your visual c++ redistributables: https://aka.ms/vs/17/release/vc_redist.x64.exe

i already had the newest one and it now works since i changed commit version to the newest


How to code a fluid trackbar

Hi, i'm conding a program with vlc.DotNet et i have a little issue. i would like to know how to code a fluid trackbar like VLc does, but  I don't know whay to do. my trackbar is very jerky beacause it run thanks to poucentage.
By the way i d'ont have the new version of VLC.DotNet, does click listeners work without invisible panel now ?
Thank in advance

i think i should use a timer that ticks every second, what do you think ?

Hi, I think using a timer would be good. Input is now passed to VLC even in WPF.


Fix 'Uncaught ReferenceError: d is not defined'

Defining the global variable d throws errors in some contexts

@markstuart Thanks. I'll merge this over the weekend. I'll bump this release since this is a real actual bug. Definitely bug me if I don't.

Thanks @seabre, that'd be great. I actually found that another script that was being bundled with this in our project was declaring a 'use strict' statement at a bundle level, and that's why it was throwing the error for global variable declaration.
Still, I think it's best not to pollute the global namespace where possible. Thanks for responding so promptly to my PR :)

@markstuart FYI, bumped here and npm: https://www.npmjs.com/package/simplify-geometry

Thanks @seabre :+1:


Renew Google access tokens

Haven't added the code to refresh the tokens, it's valid for 1 hour if I'm not mistaken.

According to this it will be updated automatically https://github.com/omarryhan/aiogoogle/issues/61#issuecomment-835795122
Let's see.


chore(Merge): async-await-typescript-2.1 & strictNullChecks

Combines async-await-typescript-2.1 and strictNullChecks branches into one branch.
All merge conflicts resolved, best of both worlds!

Thanks! I've added some review comments to #230, it might be better to fix them in this PR.

I implemented almost all suggested changes in this branch. Only the EventRecorderReporter class needs further revision.

@Archcry @stienis96 @wesselhendriks @Floormidabel  I did a few commits. If you agree i want to merge this branch

I just had a look at the comments of the old PR: #230. Almost everything is solved in this PR.
But the following stood out.
EventRecorderReporter.ts had a comment that said:

This change actually result in a lot of code duplication. Isn't there a way to keep the functional implementation?

This isn't changed in this PR.
Should we still tackle this 'problem'?

@stienis96 good point. I've been going back and forth on this point. I don't like code duplication, but on the other hand i do like the object oriented implementation (and the readability that come's with it). If it was pure JavaScript i would probably go with the more functional approach. What do you think?

@nicojs because we made this StrictReporter interface we get this code duplication. We need this interface to ensure that the functions aren't null/undefined. See Reporter.ts, this was the old interface that was getting implemented.
I don't know if there is a way to implement this new interface (that is needed for the strictNullChecks) with a functional programming solution in TypeScript. So that you have the following situation: one function to implement all these functions and still being sure that they are all implemented.
If there is a possibility to implement it in one function, without throwing away the StrictReporter interface, I would prefer that. Because it's a lot of code for not that much functionality. Otherwise I would leave it like it's now.

@stienis96 I tried it in the latest commit: https://github.com/stryker-mutator/stryker/pull/236/commits/be8cad84716f65d30b4913b2513a27f4ca29a56e
Basically, i don't explicitly implement StrictReporter. Instead, I've implemented Reporter, which doesn't do anything, it might just as well not have been there. Later in the ReporterOrchestrator there is an any cast to make sure TypeScript ignores the fact that none of the StrictReporter's methods are explicitly defined on the reporter.
Like i said, it saves some code but complicates a lot as well. Maybe its not worth it. What do you think?
@simondel what do you think?

@nicojs Yeah it looks like the old way. I actually think it's still understandable, so I would leave it like this. But of course only when the build passes.

I'll try a different approach tonight. I actually don't like it :). I see a better implementation using the new keyof type operator

Is it possible to make this discussion easily accessible in the future. This might be good information to show people that question the design choice made here.

I've switched it up again. Now using the new keyof mapped type operator of TypeScript 2.1. This doesn't reduce the amount of code duplication, but it does introduce some type safety. I cannot just drop a use random string anymore. If you guys agree i'll merge it in tomorrow.
@Archcry

Is it possible to make this discussion easily accessible in the future. This might be good information to show people that question the design choice made here.

This merge request will always be kept.

@nicojs, I figured, but won't it be buried underneath lots and lots of other pull-requests?

@nicojs The keyof operator is a nice addition. Like you said: the code is a bit longer now, but it's all type safe now. So I'm ok with it. 👍

@Archcry good point! I've linked it in the issue about documenting our design choices.

Merged 🎉  🎊
Thanks for all the help!


Windows client: refresh only updated region(s) instead of whole screen

Fixed hdc initialization into wf_begin_paint (client/Windows/wf_client.c) so the region invalidation into wf_end_paint applies to the same hdc.
The objective is that only the updated region(s) are refreshed instead of the whole screen.
It's not much a problem for normal FreeRDP usage but becomes a serious issue if the display is processed, forwarded and rendered remotely, as done by web gateways such as Guacamole, FreeRDP-WebConnect and Myrtille (I'm the author of the latter).
Thanks :)

Anyway, it has an overall impact on performance

@freerdp-bot test.

Don't know what to think of that, any gdi expert to give a look ?


Use store_true to avoid boolean values parsing issue

This is regarding the caveat of argparse parsing boolean value:
If type=bool is specified, python will always use bool() to cast the input string to boolean. That means even specifying --limit-asg False would be interpreted as limit_asg=True, which would usually contradict what the user expects. https://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse for more details.
For testing, I have used my team's account to run fail_az.py and verified the parsing logic is correct. Btw thanks for making this great tool!

Awesome - thanks @fxingliu !


[DSA]: Greedy Algorithm

Description
Discuss in detail about Greedy Algorithm.
Domain
DSA
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign


New Feature: Automatic Network Scanning for Inverters

Currently, our system requires manual IP input for inverter onboarding. This is not only time-consuming but can also be confusing for users who are not tech-savvy.
In order to improve the user experience during onboarding and make the setup process smoother, it would be beneficial to implement a new feature that automatically scans the local network for inverters.
This approach is already adopted by several services like Home Assistant, which successfully recognizes numerous devices in the local network without the need for manual IP input. This kind of automatic recognition will enhance our onboarding process by presenting the inverter in the app without any extra steps from the user side.
We believe that the development of this feature is relatively straightforward and it will significantly improve the overall user experience.

nmap and get all with port 502 and 1502 open.

I have no idea on where to begin to integrate this into the larger project. So .-... I'll just leave this ..

The code in  get_ip_and_subnet() will not work as expected when running in a Docker container - it is not possible to get the host machine ip and thus subnet from within a container.
Rather this needs to be injected as a parameter from the outside (i.e. via an env).

Implemented this in https://github.com/srcfl/srcful-gateway/commit/323c4a77a4e619b1cc6ad32c9ac4c90e07258f0c. Seems to work at first glance, but need some testing..
Endpoint: /api/inverter/modbus/scan


Add space.

For some reason the missing space bothers me very much. Maybe a <br> would work too..

Since this depends on the language, it seems better to improve that i18n. (I will do it)
Thanks anyway.


[zh-cn]fix:modify an incoherent statement

[zh-cn]fix:modify an incoherent statement

Description

Issue

Closes: #

Thanks.
/lgtm
/approve