text:
Linting the spec

I would like to start enforcing some basic sanity checks for the spec. Some of them will end up implemented in other projects, but I would like to use this issue to track possible lint rules everywhere.
The main goal of this is to reduce editorial churn and correctness issues, but I know that it would also be helpful to people who build tooling based on the spec, like https://github.com/jscert/jsexplain (so cc @brabalan in case you have any ideas).
Currently these are mostly enforced by editors noticing them or @jmdyck submitting after-the-fact PRs, which isn't sustainable.
Here's a few possibilities to get started. Please suggest more.

Output is valid HTML
~No trailing whitespace~
In algorithms:

Consistent spacing, e.g. ~foo ( a, b ) in algorithm headers and~ foo(a, b) in algorithm steps.
Parameter names are surrounded by _
If an If has substeps, the If line ends with , then
If an If has an Else which has substeps, it is spelled Else, not Otherwise
If an If has an else on the same line, it is spelled ; else  rather than , else  or ; else,  or ; otherwise  (we are inconsistent about else vs otherwise here, and I am OK not enforcing it, but we should at least enforce the semicolon and lack of following space).
Lines end in ., :, ,, do, or then
Any line not ending in . is followed by an indented sequences of steps.
Consistent casing for variable names - currently we're very bad about this one
If we say "A and B" or "A, B, and C", the commas are as they are in those examples (rather than "A, and B" or "A, B and C")
Consistently "let x be" and "set x to" (e.g. not "let x to", "set x be", or "set x to be")
Ban If _foo_ is present, let _bar_ be _foo_; else let _bar_ be *undefined*. (https://github.com/tc39/ecma262/pull/1411) [edit: actually that PR only applied to functions, not AOs, so we can only do this if we first sort out the treatment of missing parameters in AO e.g. by banning optional parameters in AOs)
"... to a new empty List" rather than "to a new List", "to be a new List", "to be a new empty List"

Probably something similar for records

The last step should not be Return., since that's implicit (as of https://github.com/tc39/ecma262/pull/2397).

Grammar lookahead restrictions and flags are omitted in early error definitions and syntax-directed operations
In the grammar:

Lookahead restrictions and flags do not have spaces between brackets (so [lookahead != `let`] or [+Await] rather than [ lookahead != `let` ] or [ +Await ], etc)
One space before the : on the LHS
One space between each terminal or nonterminal on the LHS
~Grammar flags are consistent: every ?-prefixed flag on the RHS appears as a parameter flag on the LHS, and every LHS flag is passed down at least one nonterminal in one production on the RHS, or is used to gate a production (see more about what grammar flags mean here)~

A bunch of HTML consistency stuff:

tags are lowercase https://github.com/tc39/ecmarkup/pull/367
attribute values are quoted (or unquoted; I don't care as long as we're consistent)
tags don't have any unexpected attributes (e.g.)
tags have all the expected attributes (e.g. <emu-xref="foo>" should be caught, since they meant <emu-xref href="foo">)
for tags for which the closing tag is optional, they are always included (or not included; again, as long as we're consistent)
≥ is spelled ≥ (etc) https://github.com/tc39/ecmarkup/pull/481
no unknown emu tags https://github.com/tc39/ecmarkup/pull/279
sec- is only a prefix for an ID when attached to a clause (cf https://github.com/tc39/ecma262/pull/2103)
all rows in a table have the same number of cells (account for colspan)
consistent indentation
emu-grammar and emu-alg tags are not adjacent with others of their kind
~no more than one blank line in a row~

~and maybe consistent rules about where blank lines go, at least in some cases: e.g., never between <emu-clause> and
.~

Consistent spacing for records: exactly the spacing in { [[key]]: value, [[key2]]: value2 }

Consistent spelling

~the *this* value, not *this* value or the *this* object~

we have a lint for "this object" but not no-"the" "this value" because the latter form is still in use (generally as an argument to an AO call)

~British vs American spelling for words where it's an issue, like "behaviour"~
~"one's complement" and "two's complement", not "1's complement" or "2's complement"~
"uppercase" and "lowercase", not "upper case" or "upper-case" (https://github.com/tc39/ecma262/pull/2598)

Annex A ("Grammar Summary") has emu-prodrefs to all productions (or, ideally, is automatically generated)
As of https://github.com/tc39/ecma262/pull/1914, every abstract operation has a preamble in the correct format (though, what is an abstract operation from the perspective of ecmarkup? - I guess an emu-clause with an AOID is a reasonable heuristic.)
When the steps or prose for a syntax-directed operation refer to the name of a nonterminal, it is surrounded with |, as in |UnicodeLeadSurrogate|.
In syntax-directed operations,

All referenced nonterminals occur in the production for the SDO.
In the algorithm steps or prose, opt subscripts and grammar parameters are not included.

Miscellaneous stuff:

~~Always *+0*𝔽 or *-0*𝔽, never *0*𝔽. ~~(https://github.com/tc39/ecmarkup/pull/257)
"be the Record {", not "be a new Record {"
Never *+1* for any string of digits except 0.
Exactly one space between sentences.

 is not followed by a linebreak, and
 is not preceded by a linebreak (even with intervening whitespace).
[Cc]lauses? \d should be forbidden.
An inline if does not have a then: If foo, return false. not If foo, then return false.
"ECMAScript language value", not "ECMAScript value"

No namespace collisions between constants and AOs (and maybe other namespaces)
All AOs have structured headers (once people have had time to get used to the new syntax)
No unnecessary explicit suppressions / annotations for can-call-user-code
Every algorithm returns.
consistently "a number or a bigint", in that order, in types: https://github.com/tc39/ecma262/pull/2622
no unused Let bindings or captured variables in AOs: https://github.com/tc39/ecma262/pull/2836 https://github.com/tc39/ecmarkup/pull/483
If _x_ is *null*, return *null* rather than If _x_ is *null*, return _x_, per https://github.com/tc39/ecma262/pull/3122 - anywhere there's a comparison against a thing in *s or ~s, or a literal number or +/-∞, and then the alias is returned, we should return the constant instead.

It would also be nice to have a few more static-analysis-y checks, like

The grammar should be unambiguous

And LR(k)

Typechecking for abstract operations

All used operations are defined
They are invoked with the right number of arguments
They don't reference any values which are not defined https://github.com/tc39/ecmarkup/pull/483

And when updating an already defined value, this is done with set rather than let, increase, increment, add, etc.

Their return value is treated as a completion record or not as a completion record, as appropriate (pending https://github.com/tc39/ecma262/issues/1796)
In an ideal world, actual typechecking for values

Given that, enforce the * vs ~ vs _ vs " rules for referring to different kinds of values
As a particular case, algorithms should say If _x_ is *true*, not If _x_ is true.

Grammar productions have all and only the appropriate flags
All syntax-directed operations correspond to actual productions

Edit: some of these are done in #199, #205, #207, #209, #210, and #239. I've struck them from the above list. I'm keeping this issue open to track remaining items.

All used operations are defined

This would need to be amended for AOs that are only called upstream, but at least it would force us to enumerate such AOs.

As an additional step here, I would like for us to define a bunch of "pattern matchers" of some sort that identify idiomatic spec phrasing, and use a special rendering of the spec that highlights/styles these idiomatic sections of text so that we can identify algorithm steps and whatnot that (unexpectedly) do not conform. We might even want to track/relate the idiomatic phrasing in the same way we do AO references.

I'll point out that ecmaspeak-py does almost all of what @bakkot listed, and more. Not that that helps ecmarkup a whole lot, but you're welcome to adapt my code.

@jmdyck Can you expand on the "and more"? What other things does it do that aren't listed in @bakkot's comment?

In addition to the things @bakkot listed, ...
analyze_spec.py checks that...

Only expected elements are used, and that their content conforms to expected content models.
re 'id' attributes:

There are no duplicates.
They conform to certain expectations (e.g., the 'id' of an emu-table should start with "table-").
A name isn't both an 'id' and an 'oldid'.
There's a defining 'id' for every id-reference.
Defined ids (with many exceptions) are referenced somewhere in the spec.

Some of the above similarly for 'aoid' attributes.
emu-tables with certain kinds of caption have expected column-heads.
The content of the well-known intrinsics table conforms to certain expectations.
Each %Foo% in the spec (outside the intrinsics table) resolves to one in the intrinsics table.

Section.py checks that...

clause-headers conform to certain expectations.
Within certain clauses (e.g., the properties of object Foo), sub-clauses are in 'alphabetical order'.

emu_grammars.py checks that...

Every emu-grammar element is syntactically well-formed.
Every production in a 'definition' emu-grammar "makes sense" in various ways, especially in its use of grammatical parameters.
The total set of defining productions makes sense as a whole.
Every production in a non-definition emu-grammar is a version of some defining production. (In general, it needn't be an exact copy of one, for various reasons.)
Outside of emu-grammar elements, references to nonterminals are well-defined.
(It also generates a good approximation to Annex A.)
(It also has in-progress code to generate a parser.)

Pseudocode.py ...

Attempts to parse every chunk of pseudocode (emu-alg, early error, emu-eqn, inline SDO definition), and complains about any failures. (See *.grammar for the grammars it uses.)
(Builds data structures for use in static analysis.)
Builds a static call graph and looks for anomalies.
Attempts to check SDO coverage (See tc39/ecma262#1301)

static_type_analysis.py...

Extracts parameter info + return type info from preambles (and complains about any anomalies it sees).
Attempts to perform an interprocedural static type analysis of all the pseudocode (and complains about any type errors it detects).

@bakkot

Grammar lookahead restrictions and flags are omitted in early error definitions and syntax-directed operations

I think you mean included, right?

If we decide they should be universally included, sure.

@bakkot I thought that's what we decided in the editor call. We even have it on our editor update slides.

I only remembered that we were vaguely in support of it, not that we necessarily intended to actually change it. But if we did, sure, sounds good.

I'm not good at remembering those sorts of things without notes. We can confirm at the next call.

emu_grammars.py checks that...

Every emu-grammar element is syntactically well-formed.
Every production in a 'definition' emu-grammar "makes sense" in various ways, especially in its use of grammatical parameters.
The total set of defining productions makes sense as a whole.
Every production in a non-definition emu-grammar is a version of some defining production. (In general, it needn't be an exact copy of one, for various reasons.)
Outside of emu-grammar elements, references to nonterminals are well-defined.
(It also generates a good approximation to Annex A.)
(It also has in-progress code to generate a parser.)

grammarkdown already does a lot of this, ecmarkup just doesn't employ those features.

Feel free to file bugs against grammarkdown for anything you think needs to be added to the parser, checking, etc.: https://github.com/rbuckton/grammarkdown

Nesting more than one AO invocation as parameters to another AO should be disallowed. See https://github.com/tc39/ecma262/pull/1573#issuecomment-553719055

To confirm, it seems like they should be disallowed only because the current macro doesn't handle them, not because they're inherently something we don't want?

The issue there isn't about the macro, it's the fact that there's no evaluation order for the arguments defined, and when they're abstract operations they can have side effects which must be specified to happen in a specific order.

In algorithm steps, all aliases should be introduced using Let or with a parameter list before they are used. (see tc39/ecma262#1954)
Forbid introduction of aliases that are never referenced.

In algorithm steps, each alias should only be introduced with Let at most once for any possible trace through the algorithm.

In algorithm steps, all aliases should be introduced using Let or with a parameter list before they are used.

There are other ways we introduce aliases. Other than those Let and parameter lists (including parameter lists of abstract closures), we also have various permutations on:

For each _x_ (For each element _k_ of _keys_, For each integer _k_ that satisfies ..., etc)
Evaluate |Foo| to obtain _x_, which is used only in regexes and is complicated by the fact that some of the regex operations return multiple results
If there exists  _x_ (e.g.)
the smallest possible integer _k_ not smaller than (e.g.)
For yield we say something like when evaluation is resumed with a Completion _resumptionValue_ the following steps will be performed, which introduces _resumptionValue_ for use in those steps
For MakeDay we say Find a value _t_ such that

Also, we occasionally refer to aliases from other algorithms. For example, the Function constructor says Let _args_ be the _argumentsList_ that was passed to this function by [[Call]].
Also also, some places we have algorithms (especially but not uniquely in Annex B, e.g. in the Note at the end of Number.prototype.toExponential) we're actually defining replacements to existing steps in to other algorithms, in which case it is not possible to locally determine which aliases are in scope.

Also, the things which are currently console.log warnings should become linting errors, ideally.

We should figure out if we want to use html entities for non-ASCII stuff, and enforce that decision. Currently we use both « and «.

Since I'm on a Mac, it's easy to type the actual characters, so I'd prefer that; but if others editing the spec aren't, it might not be as easy.

It's 2020, embrace the Unicode.

We should figure out if we want to use html entities for non-ASCII stuff, and enforce that decision.

Why not use ASCII quotes and convert automatically in build time? Here is how markdown-it does this.

If an If has an else on the same line, it is spelled ; else rather than , else or ; else, or ; otherwise

Instead of enforcing consistency, how about adding tags for this, e.g.
1. <emu-if><cond>x is 1 and y is 1</cond><then>return 1</then></emu-if>
1. <emu-else>return 0</emu-else>

and
1. <emu-if-multiline><cond>_exponent_ is *+∞*𝔽</cond><then>
  1. <emu-if><cond>abs(ℝ(_base_)) > 1</cond><then>return *+∞*𝔽</then></emu-if>
  1. <emu-if><cond>abs(ℝ(_base_)) is 1</cond><then>return *NaN*</then></emu-if>
  1. <emu-if><cond>abs(ℝ(_base_)) < 1</cond><then>return *+0*𝔽</then></emu-if>
</then></emu-if-multiline>
1. <emu-else-multiline>...</emu-else-multiline>

This would allow enforcing a consistent style, would also allow authors to not have to remember where commas/semicolons go, and would also let you change the style across the entire document anytime (after all ifs have been converted of course).

Instead of enforcing consistency, how about adding tags for this

The ecmarkdown page says:

Some of Ecmarkdown's biggest benefits are when using it to write algorithm steps, without the many formalities HTML requires for list items and inline formatting of common algorithmic constructs.

Adding tags as you suggest would make algorithms harder to write + edit (and read, in source).

When For each iterates over the elements of a List, we say "of", not "in".
https://github.com/tc39/ecma262/pull/3382#discussion_r1735231822

authors: NotWearingPants bakkot jmdyck ljharb michaelficarra rbuckton syg


text:
Make aarch64 tests complete consistently

Seriously it's annoying that they constantly have to be restarted because it means the test doesn't complete. Then GH only allows kicking it off again after all jobs have finished. This was okay at first but at some point it has started to happen way more than bearable.
Options, I think, are:

Improve test runtimes significantly
Stop using spot instances
Find a way to have the instance hibernate, then rerun it?
Find a way to have GitHub rerun the test if it was interrupted

There is a 5th way possibly:
Figure out if plrust can be cross-compiled in an x86 environment, then run it in docker with qemu or something, which would be hosted in Github's environment instead of something we set up in The Cloud™ .
There are probably a lot of things that could be done to the aarch64 CI infrastructure to make it better, but I just assembled the "quickest thing possible that could work". Also being mindful of costs and whatnot.

ime QEMU takes even more time to execute.

ime QEMU takes even more time to execute.

Yeah that's the fear.
Trying to match Github 1:1 on infrastructure implementation details is a bit tricky. I could use normal on-demand instances (as opposed to spot instances) that could "spring to life" when they need, but then I'd probably have to incorporate something with AWS Lambda to get that to work properly (i.e. adds more machinery). I could also consider going down the route of using something like ECS to handle the workload as well if this keeps becoming an issue or if we have so many CI runs that everything sits in a queue forever.
Maybe the short term remedy for now is to increase the number of spot instances available? Right now it's set to 2 available at any given time (simply because commits happened so infrequently), but there's a ramp-up and ramp-down time when the spot instances are terminated and the new ones are instantiated to take their place.

aarch64 tests have been running just fine for as long as I can recall now.  CI is super slow, but that's a different problem.

source: gharchive/issue

repo: tcdi/plrust

license: PostgreSQL

license_type: permissive

license_source: github-api


text:
Support for setting watering timer during switch.turn_on service call

@tchellomello,
Thanks for developing this wonderful integration with HA. I noticed that the watering time is only possible to be configured in configuration file which is basically set on startup. I tried to set the watering time via switch.turn_on service call but the service data is not accepted. Is it possible possible to add this parameter in the switch component?
Additionally it'll be great if you could consider adding other service calls such as setting rain delays.
The thing is that I use voice commands via my google home as well as automation and it'll be great if I could use these services to turn on the watering for certain time frame or add rain delay by just a voice command or based on weather forecast which triggers a rain delay setting via your newly added service call.
Once again much appreciate adding this component to HA.
Cheers

Hello @mehdiheidari,
Thanks for your kind words and for your interest in getting this library better.
I like your idea of adding the rain delays via service.
So, basically, your idea is to keep the watering_time value active for all switches, but have a call via service to override that if needed. Is that what you want?
Thanks @mehdiheidari

Hi @tchellomello,
Yes, that's exactly right.
Thanks again.

Hi @tchellomello,
Any luck?
Cheers

authors: mehdiheidari tchellomello

repo: tchellomello/raincloudy


text:
"amazon2csv" command not accessible in Windows 10

Hello @Suleman-Elahi. Sorry to hear that :(
I don't have a Windows machine to test it.
Can you please check that amazon2csv is in your <python_directory>/Scripts?
Check also that this folder is in your PATH.
Source : https://superuser.com/questions/1204232/why-arent-pip-installed-executables-available-from-the-command-line?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

Just wanted to bump this issue as I have the same problem on Windows 10.

Yeah. The scripts folder is in the path but the actual problem is that it creates the binary file for Linux I think. Ideally, on Windows, it should create "amazon2csv.exe" file in the "Scripts" folder.

I'm not sure that it is a binary file, could you please check with an editor?
What is written at the top 3-4 lines?
Could you add a .py extension to the file, and check again the execution in your command prompt?
Thank you, your help is greatly appreciated @Suleman-Elahi

The contents of the "amazon2csv" file are:

And after running it with ".py" extension , following happens.

That's weird. I am currently building a Windows VM to reproduce this issue and try to fix it. I'll let you know @Suleman-Elahi and @ReedJessen

Hello,
I renamed amazon2csv to amazon2csv.py, and updated the pip package accordingly.
Could you upgrade and test on Windows?
pip3 install --no-cache-dir -U amazonscraper
amazon2csv.py --keywords="Python programming" --maxproductnb=2

I tested on Windows today, and that worked properly.
Recap :

make sure <python_directory>/Scripts is in your PATH
execute amazon2csv.py --help in a cmd window to check

Hi Tilbault. My issue may related to this one. It seems executing, but no output? can you help?

Hello @davidliu1978
That is still difficult for me to reproduce it since I don't have a Windows host.
Could you try to execute this?
python3 amazon2csv.py --help

thanks

@davidliu1978 Have you tried to install amazon2csv with pip3 install -U amazonscraper?

authors: ReedJessen Suleman-Elahi davidliu1978 tducret

repo: tducret/amazon-scraper-python

license: MIT


text:
Use more generic device over camera in term names

The name "camera" works well for a device recording images or videos. The name doesn't work well for audio (only) recording devices. While we haven't fully considered those devices, Camtrap DP probably has a good model and terms to exchange that data.
It might therefore be useful to be already change term names to use a more general:

device
recordingDevice (see https://en.wikipedia.org/wiki/Category:Recording_devices)
captureDevice (see https://ac.tdwg.org/termlist/#ac_captureDevice)
recorder (see https://en.wikipedia.org/wiki/Category:Recording_devices)
sensor (but I consider that a part of a device)

I think camera trap folk might still recognize it as an applicable name and it would prevent us from having to change the term names in the future if we broaden the scope. More generic names also allow other standards to refer to it.
Affected terms are:

table
current term
new term

Metadata
n.a.
n.a.

Deployments
cameraID
deviceID

Deployments
cameraModel
deviceModel

Deployments
cameraDelay
deviceDelay (or sensorDelay)

Deployments
cameraHeight
deviceHeight

Deployments
cameraTilt
deviceTilt

Deployments
cameraHeading
deviceHeading

Media
n.a.
n.a.

Observations
cameraSetupType
deviceSetupType

Definitions could refer to "device", "camera or other recording device" or "camera" (when specific to camera), example:

Maximum distance at which the ~camera~ device can reliably detect activity. Expressed in meters. For cameras, typically measured by having a human move in front of the ~camera~ device.

Discussed with @kbubnicki, we both agree on device as name change. Since we currently don't have a real use case for non-camera devices, we have moved this to 1.1. For software that has to support Camtrap DP 1.0 it is fairly trivial to rename terms.

repo: tdwg/camtrap-dp


text:
Support autocompletion for command options

@teaishealthy Mentioning you as per request

Needs #3

Done

authors: teaishealthy toolifelesstocode

repo: teaishealthy/comity

license: ISC


text:
✨ Bump CAPI to v1.8.0

Testing https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/pull/3151

/test pull-cluster-api-provider-vsphere-e2e-govmomi-blocking-main
/test pull-cluster-api-provider-vsphere-e2e-govmomi-conformance-ci-latest-main
/test pull-cluster-api-provider-vsphere-e2e-govmomi-conformance-main
/test pull-cluster-api-provider-vsphere-e2e-govmomi-main
/test pull-cluster-api-provider-vsphere-e2e-govmomi-upgrade-1-30-1-31-main
/test pull-cluster-api-provider-vsphere-e2e-supervisor-blocking-main
/test pull-cluster-api-provider-vsphere-e2e-supervisor-conformance-ci-latest-main
/test pull-cluster-api-provider-vsphere-e2e-supervisor-conformance-main
/test pull-cluster-api-provider-vsphere-e2e-supervisor-main
/test pull-cluster-api-provider-vsphere-e2e-supervisor-upgrade-1-30-1-31-main
/test pull-cluster-api-provider-vsphere-e2e-vcsim-govmomi-main
/test pull-cluster-api-provider-vsphere-e2e-vcsim-supervisor-main

/retest
(probably just Boskos busy)

/retest

source: gharchive/pull-request

authors: chrischdi sbueringer


text:
Feat/50 read labels

Closes #50
Changes made by this Pull Request

Introduces task specifications
Loads labels dynamically from this

Definition of Done

[x] Tests are written and run successful
[x] Code is documented
[x] User Manual is updated
[x] All requirements of the user story are met

Codecov Report

Merging #63 (c5b9024) into dev (fe3f3fb) will increase coverage by 0.13%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##              dev      #63      +/-   ##
==========================================
+ Coverage   99.21%   99.35%   +0.13%
==========================================
  Files           5        7       +2
  Lines         128      155      +27
==========================================
+ Hits          127      154      +27
  Misses          1        1

Impacted Files
Coverage Δ

api/mod/src/app.py
100.00% <100.00%> (ø)

api/mod/src/models/annotation.py
100.00% <100.00%> (ø)

api/mod/src/models/task.py
100.00% <100.00%> (ø)

api/mod/src/routers/images.py
100.00% <100.00%> (ø)

api/mod/src/routers/tasks.py
100.00% <100.00%> (ø)

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 fe3f3fb...c5b9024. Read the comment docs.

authors: bewee codecov-commenter

repo: team-folivora/annoto


text:
Lane changing and acceleration/deceleration.

That's going to be last code thing from me (I hope).
This change set introduces new behavrio into the cars (they try to speed, change lanes, brake if they can not), two types of cars - big and slow lorries and faster passenger cars, new visual inspection tools (cars have real width/height which can be seen after zoom in, we have the 'impact radius' visible if we select a car - that is, we can see when it will start of thinking to brake for example.
Now cars have HSB colors with Hue component dependent on car's speed.
I haven't done much unit tests here (none actually), sorry for that. For the final thing - as soon as it works, it works (again, sorry, and again, don't do it later:).
Please try running first, and then see the code changes.

Looks good and works like a charm :+1:
Might need to complete the docs otherwise the javadoc generator is going complain at the end.

license: mit

license_source: bigquery


text:
Link in header

The label "Dipartimento per la trasformazione digitale" in the header, should have this link https://innovazione.gov.it/ and not https://innovazione.gov.it/dipartimento

closed by #142

authors: danieledebernardinDTD sebbalex


text:
vcs & opensource & recent SUMMARY

vcs & opensource & recent SUMMARY
원래 기존에는 vcs와 opensource가 합친 챕터로 있었는데 vcs 내용을 넣다보니 내용이 길어지게 되어 두 챕터로 나누어 작성하였습니다!!

보시고 기존 처럼 합친 챕터로 있으면 좋겠다고 의견이 많으면 그렇게 수정할 수 있도록 하겠습니다!

repo: teamkw/unibook


text:
How to use CacheWrapper?

I use composer
The box below is my code
ini_set('memory_limit', '-1');

use Discord\Discord;
use Discord\Http\Http;
use Discord\Parts\Channel\Channel;
use Discord\Factory\Factory;
use Discord\Wrapper\CacheWrapper;

/**
 * Globel Variable
 * @var String $token Discord API BOT Access_Token
 */
$token = '*************************************';

require 'vendor/autoload.php';

$discord = new Discord(['token' => $token]);
$CacheWrapper = new CacheWrapper();
$Http = new Http($CacheWrapper, $token, '1.0');
$Factory = new Factory($discord, $Http, $CacheWrapper);
$Channel = new Channel($Factory, $discord, $Http, $CacheWrapper, null ,false);

$discord->on('ready', function ($discord) {
    echo "Bot is ready!", PHP_EOL;

    // Listen for messages.
    $discord->on('message', function ($message, $discord) {
            echo "{$message->author->username}: {$message->content}", PHP_EOL;
        }
        );
    });

$discord->on('reconnecting', function () {
    echo "reconnecting";
});

$discord->on('disconnect', function () {
    echo "disconnect";
});

$discord->joinVoiceChannel($Channel, false, true, null);

$discord->run();

You probably should've removed the bot token from the block code.

And I hope you know we can still see it in the edit history. ;)

So sad😭😭

See the options documentation for more information.

repo: teamreflex/DiscordPHP


text:
More descriptive validation errors

Getting really deep into working with Avro schemas from an old dynamic json system and have found the conversion difficult because error messages are no descriptive.
After looking over the validation piece, we found thay the basic validation function could use some modifications. I will be looking to publish changes in the future referencing this issue.
I'm not familiar with cython development, so I'll try my best to do the cython side as well but may require assistance.

Do you mind giving an example of what a current error is and what you think would be better? I had some ideas about this a long time ago in https://github.com/tebeka/fastavro/pull/52 and https://github.com/tebeka/fastavro/pull/53 but ultimately neither of those were merged. My idea at the time was to have the exception include some information such as the following:
Path is: <record[0]>.<field[aa]>.<field[b]>.<field[c]>
Datum is 2 of type <type 'str'>
Expected avro schema type: int

I have the Python version written, need to write unittest, but all existing test are passing.
Need to write cython version as well after I proofed the regular Python version.

Would you mind going ahead and pushing a branch or starting a PR? I tend to do the python side first as well, and that way we can make sure that end of it looks good and prevent having to fix both the python and cython if anything needs modifying.

How to create a PR to a non existing branch on repo? or do you want commuted to master?
https://github.com/rhaarm/fastavro/tree/Validators

@scottbelden see my previous comment

Resolved via https://github.com/tebeka/fastavro/pull/182

authors: rhaarm scottbelden

repo: tebeka/fastavro


text:
名前案

概要

名前について何も決まってなかったので、一旦ここに案を集める

今出てるもの

disaster-platform
リアルタイム被災者マップ

くらい

infoRelay 情報をつなぐという観点で
一応それっぽい名前の商標登録無いことは確認済みです。
ただ、語感や略語がちょっと響き悪い

HandUp(ハンドアップ)
助けを求める、援助を提供する、挙手する
・被災者自身の助けて、これが欲しいという挙手
・非被災者から援助を提供しますよという挙手
割と安直（よく言えばシンプルイズベスト）ですが、誰かの挙手に気づく・誰かを支援する挙手をつなげるをイメージした名前です。
複数形でもいいかもなのですが、私に支援が必要です、私がやります、というときには片手のイメージなので単数形にしています。が、複数形の方が意味が伝わるのかな…（検討したいです）
Put your hands up.（手をあげてください）のハンド（ズ）アップです。悪人の叫ぶやつではありません。
【イメージ過程】
・我々開発に携わった人たちが、思い思いに手を挙げて開発しているのを見て想起しました。
・意外と海外から見てもポジティブに聞こえるというGPT4のアドバイスもあり、これがハマるのでは、と思いました。
【懸念点】
・被災者を助けるための〜という文脈が伝わりづらいかもしれないので、ロゴデザインなどを考えて支援をイメージするアイコンなどを検討すべきかもしれません。

災害情報プラットフォーム：InfoRelayみたいな感じで合体させるのもあり。

authors: lumiere41 nakaji-kazu suguru-toyohara

repo: tech-creative-club/disaster-platform


text:
💄 ইডিটরের আগের কোড ব্লকটাই ভালো ছিলো

ইডিটরের আগের কোড ব্লকটাই ভালো ছিলো বর্তমানের কোড ব্লকটা ইউজারের ব্লগ পড়তে চোখে কিছুটা সমস্যা হয়।

আমিও বিশ্বাস করি আগের এডিটর টা অনেক ভালো ছিল, কিন্তু সবাই মার্কডাউনটা আসলে বুঝে না। বুঝতে পারছি না কি করা যায়। @kingRayhan

আমিও বিশ্বাস করি আগের এডিটর টা অনেক ভালো ছিল, কিন্তু সবাই মার্কডাউনটা আসলে বুঝে না। বুঝতে পারছি না কি করা যায়। @kingRayhan

এখনকার ইডিটরটা ব্লগ লেখার জন্য খুবই উপযোগী এবং সহজ দ্রুত ব্লগ লিখা যায়। আমি বোঝাতে চেয়েছি কোড ব্লক গুলোর বর্তমান কালারটা তেমন সুন্দর ভাবে ফুটে ওঠে নাহ, আগের হাইলাইট কালারটাই অনেক ভালো ছিলো।

authors: asifadib shoaibsharif

repo: techdiary-dev/techdiary


text:
Dark Theme & Updated UI for ContactUS

Add an issue reference
This is a reference to the issue #10
Description of the changes proposed in the PR
The changes in the PR include

Dark Mode
Improved UI

Add relevant screenshots

Add mentions of person or team
team femmetech
@sonalsk

Nice work


text:
saveDatabase() error when invoked too quickly

I am writing an app in Node that uses LokiJS.
I am manually calling saveDatabase() every time I insert an object. If I create multiple objects quickly, the saveDatabase method is invoked multiple times in a short period of time and after the first call it complains because it cannot rename the dbName~ file. The problem is that the fs.writeFile and fs.rename (lokijs.js lines 2020 - 2025) are executed asynchronously so in some cases, when the code tries to rename dbname~ to dbname, dbname~ does not exist any longer because it was already renamed in a previous callback.
I fixed the issue by making sure the temp db name is unique by changing lokijs.js line 2019 from:
var tmpdbname = dbname + '~';
to
var tmpdbname = dbname + Date.now();
The way I am calling saveDatabase is not efficient and should probably use the autoSave feature.
The reason I do it this way is because my code does not write often, so I wanted to avoid having the autosave timer function running periodically (though it may be cleaner to do so).
Would you like me to submit a pull request?

Yea loki is mostly synchronous except most persistence adapters are asynchronous (for good reason).  Ideally you would pass a callback to saveDatabase and wait for it to notify you the save was completed.
I think the best way to handle this might be to async throttle database saves to occur only after you have yielded the thread (perhaps as an option?).
We could take this standalone logic :
var db = new loki('test.db');
var coll = db.addCollection('coll');

var saveQueued = false;

function throttleSave() {
  if (saveQueued) return;

  saveQueued = true;

  setTimeout(function() {
    db.saveDatabase(function(err) {
       console.log('save completed');
    });
  }, 1);
}

coll.insert({a:1, b:2});
// this will queue up the save for when we yield thread
throttleSave();

coll.insert({a:2:, b:3});
// this will detect a save is already queued
throttleSave();

// now that we yield thread, our timeout will fire and save (once)

Test it and if needed add it to our Loki.saveDatabase.  So basically you call saveDatabase and keep crunching data and it wont actually save until you are done... at which point the timeout will fire and save once.
If you prefer multiple saves (not sure why but maybe use case) you could clone the LokiFsAdapter and replace all asynchronous filesystem calls with their equivalent synchronous versions.  We do have a few synchronous adapters like LokiLocalStorageAdapter and LokiMemoryAdapter and those would behave as you are expecting our node fs adapter to behave.

Thanks @obeliskos for your reply. I am including a code snippet that triggers the issue I mentioned (my real case involves multiple calls from remote clients, so even if I wait for the db.saveDatabase callback I still get errors due to timing issues as the requests are not serialized):
`
var loki = require('lokijs');
var db = new loki('loki.json');
var children = db.addCollection('children');
var s = 0;
function insert() {
console.log('Inserting: ' + s);
children.insert({name:'' + s, legs: 8});
s++;
db.saveDatabase();
}
for(var i = 0; i < 100; i++) {
setTimeout(insert, 100);
}
`
At the end of the run you get:
/lokijs/src/lokijs.js:2158
throw err;
^
Error: ENOENT: no such file or directory, rename 'loki.json~' -> 'loki.json'
I tried your throttleSave approach and worked. I just had to make a minor change to your code. I added another flag called saveRequested. If you call throttleSave and saveQueued is set, instead of returning, I set saveRequested to true. This way, in the db.saveDatabase callback, if I see someone tried to save while we were saving, I call throttleSave again. Otherwise, there are cases where we don't save the latest version of the Db (I have a code snippet that triggers the error in case you are interested)
I made the changes to the code and had to update some of the tests because they were failing (mostly tests that save and then load the db immediately). Unfortunately I have one test error that I am not able to resolve. Would you mind having a look?
I tried to upload my changes to a new throttlesave branch but I don't have permissions. What is your policy for submitting changes? Should I fork the project first?
Thanks again for your help.

Yes that makes sense if you kick off an async save, yield thread, and (via event?) grab the thread again to modify and save before the first save finished.
Sure go ahead and fork and I will take a look at it... we are in the process of merging changes from master to 2.0.0 so maybe once we finalize your p.r. it can be once that is complete.  At that point we may want to duplicate that fix on newer 2.0.0 version.

Exactly, that was the issue with saving but missing a later update.
Will fork an upload the code into a branch.
BTW, great work with the Db I find it very useful.

Ok, submitted the pull request

@mromanbcn Nice elaboration in the first comment... I'm facing the same issue

Thanks @ohenepee. I have been working with @obeliskos and we are almost done with a set of changes that will fix the issue. The pull request is almost ready

Described now in wiki here :
https://github.com/techfort/LokiJS/wiki/LokiJS-persistence-and-adapters#high-frequency-save-throttling

Thanks @obeliskos!

@obeliskos, when do you plan to release a new package (1.4.3?) with the new throttle save functionality?
Thanks

techfort will do a release whenever he finds time and we bug him enough...  I would think we would give people a chance to test out a week or so and I will need to update a few tests / jsdocs but we can look to do it after then

Fair enough, I agree about the testing. I will update my package.json so I use the latest git version for now and then will use the release version when it comes out

I have updated the throttling wiki entry to cover new additions I just made.
Basically I was adding unit tests and figured I would add method to wait for queue to drain.
Then I figured I would add that logic to loadDatabase (to wait for save queue to drain) to turn this into more of a high level contention management that works within a single loki instance.  Multiple loki databases saving to the same file or multiple node processes saving to the same file can still conflict with each other, but with a single loki instance this should be managed to avoid conflict.
This option is made default for upcoming 1.43 release, anyone wishing to report any issues with latest master src, feel free to report before we update npm and releases.

I just experienced this issue, it seems like it solved my problem, Looking forward for the release.
in the mean time working with master

techfort released 1.4.3 today, so npm has this now

authors: dror-ventura mromanbcn obeliskos ohenepee

repo: techfort/LokiJS


text:
This week filter in all sections

[x] 'To date' must be consider up to last day of week.
[x] 'From date' and 'To date' will be vary based on preferences

Issue Closed

repo: techgebra/polosys-books

license: Unlicense


text:
vsock: Handle Tx and Rx in separate threads

A crude PoC handling Tx and Rx in separate threads instead of a single thread for both.
Note: This is a dummy PR just to aid in review of my commits.

Overall looks the good direction, but I suggest you to start to split in multiple commits with a good description to simplify the review.
I also suggest making it configurable (let the user choose if enable or not the multi-threading).
Anyway it looks great so far :-)
Did you run iperf-vsock?
Using --bidir should show better performance compared to the single thread approach.

Thank you for your time!

Overall looks the good direction, but I suggest you to start to split in multiple commits with a good description to simplify the review.

Okay, I will do it but please give me some time.

I also suggest making it configurable (let the user choose if enable or not the multi-threading).

Yes, I will do this once we finalize the code for the multi-threaded approach.

Anyway it looks great so far :-)
Did you run iperf-vsock?
Using --bidir should show better performance compared to the single thread approach.

Unfortunately, running iperf-vsock (even with --bidir) currently shows worsened performance compared to the single thread approach. I ran top while executing iperf-vsock and found out that one of the threads remains suspended for a large period of time. This might be due to some poor synchronization code. I will have to look into it.

authors: stefano-garzarella techiepriyansh

repo: techiepriyansh/vhost-device


text:
Use commands config to execute wrapper commands

Added a config file that contains the supported commands, their description and whether or not they are simple "wrapped" commands. With this data we can simply detect if a command like bundle is a wrapped command and execute bin/wrap_command rather than having a duplicative script for each.
This would be a good start for addressing #39.

👀 @blankenshipz

LGTM!!!!

repo: technekes/nib


text:
Add fetch command

I would like to have the git fetch command available through homesick.
This way I can do a homesick fetch to see if I am behind from the remote.
I have a homesick-all function in my bash functions that will run the provided homesick arguments for all castles.
So then I could do a homesick-all fetch and immediately see if any of my castles need updating.

I just realized that the new version has a -all switch for some commands, so hopefully my bash function will eventually become obsolete :)

As mentioned in the comments on #135

As mentioned in the comments on #135 this can be achieved through the exec_all command.

Closed as per #135

repo: technicalpickles/homesick


text:
wechat icon

Proposed Changes

Add wechat icon

Screenshot (If Applicable)
Checklist

[ ] Tested locally
[ ] Ran yarn ci to test my code
[ ] Did not add any unnecessary changes
[ ] All my changes appear after other changes in each file
[ ] Included a screenshot (if adding a new button)
[ ] 🚀

Hey thanks!  I think we will need more code than this to merge it.  Look for an example in a previous PR!

Just rechecked. Wechat released an update 6.3.25 on 2016-09-05, which blocks almost all URL schemes request from non-weixin's application. Only requests from weixin's applications and some "white-listed" applications are allowed.
Hence normal browser application doesnt execute the url scheme now. Will have to relook into this if there's any changes

repo: techno-tim/littlelink-server


text:
release: v1.1.30

Changes

chore: update npm dependencies (3251e8cbc58e40608d05c759d7722411f25f1763)

Base PullRequest
default branch (https://github.com/technote-space/anchor-markdown-header/tree/master)
Command results

Details:

add path
/home/runner/work/_actions/technote-space/create-pr-action/v2/node_modules/npm-check-updates/bin

cli.js -u --packageFile package.json
Using yarn
Upgrading /home/runner/work/anchor-markdown-header/anchor-markdown-header/package.json

 @types/node                       ^16.7.8  →  ^16.7.13
 @typescript-eslint/eslint-plugin  ^4.30.0  →   ^4.31.0
 @typescript-eslint/parser         ^4.30.0  →   ^4.31.0

Run yarn install to install new versions.

yarn install
yarn install v1.22.11
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@2.3.2: The platform "linux" is incompatible with this module.
info "fsevents@2.3.2" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
Done in 19.73s.

yarn upgrade
yarn upgrade v1.22.11
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@2.3.2: The platform "linux" is incompatible with this module.
info "fsevents@2.3.2" is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Rebuilding all packages...
success Saved lockfile.
success Saved 345 new dependencies.
info Direct dependencies
├─ @commitlint/cli@13.1.0
├─ @commitlint/config-conventional@13.1.0
├─ @types/jest@27.0.1
├─ @typescript-eslint/eslint-plugin@4.31.0
├─ @typescript-eslint/parser@4.31.0
├─ emoji-regex@9.2.2
├─ eslint@7.32.0
├─ husky@7.0.2
├─ jest@27.1.0
├─ lint-staged@11.1.2
├─ ts-jest@27.0.5
└─ typescript@4.4.2
info All dependencies
├─ @babel/compat-data@7.15.0
├─ @babel/core@7.15.5
├─ @babel/helper-compilation-targets@7.15.4
├─ @babel/helper-function-name@7.15.4
├─ @babel/helper-get-function-arity@7.15.4
├─ @babel/helper-hoist-variables@7.15.4
├─ @babel/helper-member-expression-to-functions@7.15.4
├─ @babel/helper-module-imports@7.15.4
├─ @babel/helper-module-transforms@7.15.4
├─ @babel/helper-optimise-call-expression@7.15.4
├─ @babel/helper-replace-supers@7.15.4
├─ @babel/helper-simple-access@7.15.4
├─ @babel/helper-validator-option@7.14.5
├─ @babel/helpers@7.15.4
├─ @babel/highlight@7.14.5
├─ @babel/plugin-syntax-async-generators@7.8.4
├─ @babel/plugin-syntax-bigint@7.8.3
├─ @babel/plugin-syntax-class-properties@7.12.13
├─ @babel/plugin-syntax-import-meta@7.10.4
├─ @babel/plugin-syntax-json-strings@7.8.3
├─ @babel/plugin-syntax-logical-assignment-operators@7.10.4
├─ @babel/plugin-syntax-nullish-coalescing-operator@7.8.3
├─ @babel/plugin-syntax-numeric-separator@7.10.4
├─ @babel/plugin-syntax-object-rest-spread@7.8.3
├─ @babel/plugin-syntax-optional-catch-binding@7.8.3
├─ @babel/plugin-syntax-optional-chaining@7.8.3
├─ @babel/plugin-syntax-top-level-await@7.14.5
├─ @babel/plugin-syntax-typescript@7.14.5
├─ @babel/template@7.15.4
├─ @bcoe/v8-coverage@0.2.3
├─ @commitlint/cli@13.1.0
├─ @commitlint/config-conventional@13.1.0
├─ @commitlint/ensure@13.1.0
├─ @commitlint/execute-rule@13.0.0
├─ @commitlint/format@13.1.0
├─ @commitlint/is-ignored@13.1.0
├─ @commitlint/lint@13.1.0
├─ @commitlint/load@13.1.0
├─ @commitlint/message@13.0.0
├─ @commitlint/parse@13.1.0
├─ @commitlint/read@13.1.0
├─ @commitlint/resolve-extends@13.0.0
├─ @commitlint/rules@13.1.0
├─ @commitlint/to-lines@13.0.0
├─ @commitlint/top-level@13.0.0
├─ @eslint/eslintrc@0.4.3
├─ @humanwhocodes/config-array@0.5.0
├─ @humanwhocodes/object-schema@1.2.0
├─ @istanbuljs/load-nyc-config@1.1.0
├─ @jest/globals@27.1.0
├─ @jest/reporters@27.1.0
├─ @jest/test-sequencer@27.1.0
├─ @nodelib/fs.scandir@2.1.5
├─ @nodelib/fs.stat@2.0.5
├─ @nodelib/fs.walk@1.2.8
├─ @sinonjs/commons@1.8.3
├─ @sinonjs/fake-timers@7.1.2
├─ @tootallnate/once@1.1.2
├─ @types/babel__core@7.1.16
├─ @types/babel__generator@7.6.3
├─ @types/babel__template@7.4.1
├─ @types/babel__traverse@7.14.2
├─ @types/graceful-fs@4.1.5
├─ @types/istanbul-lib-coverage@2.0.3
├─ @types/istanbul-lib-report@3.0.0
├─ @types/istanbul-reports@3.0.1
├─ @types/jest@27.0.1
├─ @types/json-schema@7.0.9
├─ @types/minimist@1.2.2
├─ @types/normalize-package-data@2.4.1
├─ @types/parse-json@4.0.0
├─ @types/prettier@2.3.2
├─ @types/stack-utils@2.0.1
├─ @types/yargs-parser@20.2.1
├─ @typescript-eslint/eslint-plugin@4.31.0
├─ @typescript-eslint/experimental-utils@4.31.0
├─ @typescript-eslint/parser@4.31.0
├─ abab@2.0.5
├─ acorn-globals@6.0.0
├─ acorn-jsx@5.3.2
├─ acorn-walk@7.2.0
├─ acorn@7.4.1
├─ aggregate-error@3.1.0
├─ ajv@6.12.6
├─ ansi-colors@4.1.1
├─ ansi-escapes@4.3.2
├─ anymatch@3.1.2
├─ argparse@1.0.10
├─ array-ify@1.0.0
├─ array-union@2.1.0
├─ arrify@1.0.1
├─ asynckit@0.4.0
├─ babel-jest@27.1.0
├─ babel-plugin-jest-hoist@27.0.6
├─ babel-preset-jest@27.0.6
├─ balanced-match@1.0.2
├─ brace-expansion@1.1.11
├─ braces@3.0.2
├─ browser-process-hrtime@1.0.0
├─ browserslist@4.17.0
├─ bs-logger@0.2.6
├─ bser@2.1.1
├─ buffer-from@1.1.2
├─ camelcase-keys@6.2.2
├─ caniuse-lite@1.0.30001255
├─ chalk@4.1.2
├─ char-regex@1.0.2
├─ ci-info@3.2.0
├─ cjs-module-lexer@1.2.2
├─ clean-stack@2.2.0
├─ cli-cursor@3.1.0
├─ color-convert@2.0.1
├─ color-name@1.1.4
├─ colorette@1.3.0
├─ combined-stream@1.0.8
├─ commander@7.2.0
├─ concat-map@0.0.1
├─ conventional-changelog-angular@5.0.12
├─ conventional-changelog-conventionalcommits@4.6.0
├─ conventional-commits-parser@3.2.1
├─ convert-source-map@1.8.0
├─ cross-spawn@7.0.3
├─ cssom@0.4.4
├─ cssstyle@2.3.0
├─ dargs@7.0.0
├─ data-urls@2.0.0
├─ decamelize-keys@1.1.0
├─ decamelize@1.2.0
├─ decimal.js@10.3.1
├─ dedent@0.7.0
├─ deep-is@0.1.4
├─ deepmerge@4.2.2
├─ delayed-stream@1.0.0
├─ detect-newline@3.1.0
├─ diff-sequences@27.0.6
├─ dir-glob@3.0.1
├─ doctrine@3.0.0
├─ domexception@2.0.1
├─ dot-prop@5.3.0
├─ electron-to-chromium@1.3.830
├─ emoji-regex@9.2.2
├─ enquirer@2.3.6
├─ error-ex@1.3.2
├─ escape-string-regexp@4.0.0
├─ escodegen@2.0.0
├─ eslint-utils@2.1.0
├─ eslint@7.32.0
├─ espree@7.3.1
├─ esprima@4.0.1
├─ esquery@1.4.0
├─ esrecurse@4.3.0
├─ fast-glob@3.2.7
├─ fast-levenshtein@2.0.6
├─ fastq@1.12.0
├─ fb-watchman@2.0.1
├─ file-entry-cache@6.0.1
├─ fill-range@7.0.1
├─ flat-cache@3.0.4
├─ flatted@3.2.2
├─ form-data@3.0.1
├─ fs-extra@10.0.0
├─ fs.realpath@1.0.0
├─ function-bind@1.1.1
├─ gensync@1.0.0-beta.2
├─ get-own-enumerable-property-symbols@3.0.2
├─ get-package-type@0.1.0
├─ get-stream@6.0.1
├─ git-raw-commits@2.0.10
├─ glob@7.1.7
├─ global-dirs@0.1.1
├─ globals@13.11.0
├─ globby@11.0.4
├─ hard-rejection@2.1.0
├─ has@1.0.3
├─ hosted-git-info@4.0.2
├─ html-encoding-sniffer@2.0.1
├─ html-escaper@2.0.2
├─ http-proxy-agent@4.0.1
├─ https-proxy-agent@5.0.0
├─ human-signals@2.1.0
├─ husky@7.0.2
├─ iconv-lite@0.4.24
├─ inflight@1.0.6
├─ inherits@2.0.4
├─ ini@1.3.8
├─ is-arrayish@0.2.1
├─ is-core-module@2.6.0
├─ is-extglob@2.1.1
├─ is-glob@4.0.1
├─ is-number@7.0.0
├─ is-obj@1.0.1
├─ is-plain-obj@1.1.0
├─ is-potential-custom-element-name@1.0.1
├─ is-regexp@1.0.0
├─ is-stream@2.0.1
├─ is-text-path@1.0.1
├─ is-unicode-supported@0.1.0
├─ isexe@2.0.0
├─ istanbul-lib-instrument@4.0.3
├─ istanbul-lib-source-maps@4.0.0
├─ istanbul-reports@3.0.2
├─ jest-changed-files@27.1.0
├─ jest-cli@27.1.0
├─ jest-docblock@27.0.6
├─ jest-jasmine2@27.1.0
├─ jest-leak-detector@27.1.0
├─ jest-pnp-resolver@1.2.2
├─ jest-resolve-dependencies@27.1.0
├─ jest-serializer@27.0.6
├─ jest-util@27.1.0
├─ jest-watcher@27.1.0
├─ jest@27.1.0
├─ js-tokens@4.0.0
├─ jsdom@16.7.0
├─ jsesc@2.5.2
├─ json-parse-even-better-errors@2.3.1
├─ json-schema-traverse@0.4.1
├─ json-stable-stringify-without-jsonify@1.0.1
├─ json5@2.2.0
├─ jsonfile@6.1.0
├─ jsonparse@1.3.1
├─ JSONStream@1.3.5
├─ kind-of@6.0.3
├─ kleur@3.0.3
├─ leven@3.1.0
├─ lines-and-columns@1.1.6
├─ lint-staged@11.1.2
├─ listr2@3.11.1
├─ locate-path@5.0.0
├─ lodash.clonedeep@4.5.0
├─ lodash.merge@4.6.2
├─ lodash.truncate@4.4.2
├─ lodash@4.17.21
├─ log-symbols@4.1.0
├─ log-update@4.0.0
├─ make-dir@3.1.0
├─ make-error@1.3.6
├─ makeerror@1.0.11
├─ map-obj@1.0.1
├─ mime-db@1.49.0
├─ mime-types@2.1.32
├─ mimic-fn@2.1.0
├─ min-indent@1.0.1
├─ minimist-options@4.1.0
├─ minimist@1.2.5
├─ ms@2.1.2
├─ node-int64@0.4.0
├─ node-modules-regexp@1.0.0
├─ node-releases@1.1.75
├─ normalize-package-data@3.0.3
├─ npm-run-path@4.0.1
├─ nwsapi@2.2.0
├─ onetime@5.1.2
├─ optionator@0.9.1
├─ p-each-series@2.2.0
├─ p-limit@2.3.0
├─ p-locate@4.1.0
├─ p-map@4.0.0
├─ p-try@2.2.0
├─ parent-module@1.0.1
├─ parse5@6.0.1
├─ path-is-absolute@1.0.1
├─ path-key@3.1.1
├─ path-parse@1.0.7
├─ picomatch@2.3.0
├─ pirates@4.0.1
├─ pkg-dir@4.2.0
├─ please-upgrade-node@3.2.0
├─ progress@2.0.3
├─ prompts@2.4.1
├─ psl@1.8.0
├─ queue-microtask@1.2.3
├─ quick-lru@4.0.1
├─ react-is@17.0.2
├─ read-pkg-up@7.0.1
├─ read-pkg@5.2.0
├─ readable-stream@3.6.0
├─ redent@3.0.0
├─ require-from-string@2.0.2
├─ resolve-cwd@3.0.0
├─ resolve-global@1.0.0
├─ resolve@1.20.0
├─ restore-cursor@3.1.0
├─ reusify@1.0.4
├─ rimraf@3.0.2
├─ run-parallel@1.2.0
├─ rxjs@6.6.7
├─ safe-buffer@5.1.2
├─ safer-buffer@2.1.2
├─ saxes@5.0.1
├─ semver-compare@1.0.0
├─ semver@7.3.5
├─ shebang-command@2.0.0
├─ shebang-regex@3.0.0
├─ sisteransi@1.0.5
├─ source-map-support@0.5.19
├─ source-map@0.6.1
├─ spdx-correct@3.1.1
├─ spdx-exceptions@2.3.0
├─ sprintf-js@1.0.3
├─ string_decoder@1.3.0
├─ string-argv@0.3.1
├─ stringify-object@3.3.0
├─ strip-bom@4.0.0
├─ strip-final-newline@2.0.0
├─ strip-indent@3.0.0
├─ strip-json-comments@3.1.1
├─ supports-color@7.2.0
├─ supports-hyperlinks@2.2.0
├─ symbol-tree@3.2.4
├─ table@6.7.1
├─ terminal-link@2.1.1
├─ test-exclude@6.0.0
├─ text-extensions@1.9.0
├─ text-table@0.2.0
├─ through@2.3.8
├─ tmpl@1.0.5
├─ to-fast-properties@2.0.0
├─ to-regex-range@5.0.1
├─ tough-cookie@4.0.0
├─ tr46@2.1.0
├─ trim-newlines@3.0.1
├─ trim-off-newlines@1.0.1
├─ ts-jest@27.0.5
├─ tslib@1.14.1
├─ type-detect@4.0.8
├─ type-fest@0.20.2
├─ typedarray-to-buffer@3.1.5
├─ typescript@4.4.2
├─ util-deprecate@1.0.2
├─ v8-compile-cache@2.3.0
├─ v8-to-istanbul@8.0.0
├─ w3c-hr-time@1.0.2
├─ w3c-xmlserializer@2.0.0
├─ walker@1.0.7
├─ whatwg-url@8.7.0
├─ which@2.0.2
├─ word-wrap@1.2.3
├─ write-file-atomic@3.0.3
├─ ws@7.5.4
├─ xmlchars@2.2.0
├─ yallist@4.0.0
├─ yaml@1.10.2
├─ yargs-parser@20.2.9
└─ yocto-queue@0.1.0
Done in 10.10s.

yarn audit
yarn audit v1.22.11
0 vulnerabilities found - Packages audited: 536
Done in 0.77s.

Changed files

Changed 2 files:

package.json
yarn.lock

:octocat: Repo | :memo: Issues | :department_store: Marketplace

Codecov Report

Merging #50 (e9ffb45) into master (5e21e35) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master       #50   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            1         1
  Lines           62        62
  Branches         8         8
=========================================
  Hits            62        62

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 5e21e35...e9ffb45. Read the comment docs.

authors: codecov-commenter technote-space

repo: technote-space/anchor-markdown-header


text:
This migrates the A2 port usage check to be a common check

Supports chef-server, automate and a2
This replaces #92 with a more generic check.
Signed-off-by: Will Fisher wfisher@chef.io

Not sure about recommending that net.ipv4.tcp_tw_reuse setting as it has lots of consequences
See: https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

repo: teknofire/gatherlogs-inspec-profiles


text:
Tekton Taskrun Metrics are not accurate

Expected Behavior
Tekton metrics should match the data provided by kubectl.
Actual Behavior
I have been trying to gather the taskrun duration using tekton_taskrun_duration_seconds_sum and tekton_taskrun_duration_seconds_countby doing
sum(rate(tekton_taskrun_duration_seconds_sum{cluster_name="dev",namespace="tekton",taskrun="task-run-tekton5g444"}[1h])) / sum(rate(tekton_taskrun_duration_seconds_count{cluster_name="dev",namespace="tekton",taskrun="task-run-tekton5g444"}[1h]))
I am seeing the value being reported twice in prometheus. Sometimes the value is reported 2-3 times resulting in duplicate values for taskrun duration seconds.

Here is another example where the duration_seconds value is being reported multiple times. As if the controller is resetting and then incrementing the value again ?
The query used here is sum (rate(tekton_taskrun_duration_seconds_sum{namespace="tekton",cluster_name="dev",taskrun="task-run-tektonhfvhq"}[5m]))

Another issue is the timestamp being reported.
Here is the taskspec
`
status:
completionTime: "2021-02-01T15:00:32Z"
conditions:

lastTransitionTime: "2021-02-01T15:00:32Z"
message: All Steps have completed executing
reason: Succeeded
status: "True"
type: Succeeded
podName: task-run-tekton5g444-pod-cwbvx
startTime: "2021-02-01T15:00:27Z"
`

As per above the job ran at 15:00 GMT but based on the prometheus screenshot above the timestamp being reported is 16:36 which does not quiet add up to the time being reported in kubectl get taskrun taskrun_name -o yaml
Steps to Reproduce the Problem

Enable Tekton metrics.
Enable prom scrape.
Use the above sum/count method to track taskrun duration.

Additional Info

Kubernetes version:
*Output of kubectl version:

$ kubectl version Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-14T05:13:35Z", GoVersion:"go1.15.6", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.12-gke.20", GitCommit:"0ac5f81eecab42bff5ef74f18b99d8896ba7b89b", GitTreeState:"clean", BuildDate:"2020-09-09T00:48:20Z", GoVersion:"go1.12.17b4", Compiler:"gc", Platform:"linux/amd64"}

Tekton Pipeline version:
Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

$ tkn version Client version: 0.15.0 Pipeline version: v0.10.2 Triggers version: v0.3.1

/assign sbwsg

Seems like a legit bug - we should at least investigate if we can reproduce before closing.
/remove-lifecycle rotten

/priority important-soon
/remove-lifecycle rotten
There's a TEP for improving our metrics, this should be addressed there

/assign @khrm
Should be fixed with https://github.com/tektoncd/pipeline/pull/4468

/unassign

/assign khrm

Thank you for working on this.

Both the PRs with the fixes are merged:

https://github.com/tektoncd/pipeline/pull/4468
https://github.com/tektoncd/pipeline/pull/4469

/close

authors: bobcatfish ibexmonj khrm lbernick pritidesai sbwsg wlynch

repo: tektoncd/pipeline


text:
TEP-0090: Refactor GetChildReferences

Changes

In this change, we separate that logic to fetch the childRef of a
specific TaskRun from the function that gets the childRefs for all
TaskRuns in the PipelineRunState. This is separate function is
helpful for reuse and readability.
No functional changes made in this commit.
/kind cleanup
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[n/a] Docs included if any changes are user facing
[n/a] Tests included if any functionality added or changed
[x] Follows the commit message standard
[x] Meets the Tekton contributor standards (including functionality, content, code)
[x] Release notes block below has been filled in (if there are no user facing changes, use release note "NONE")

Release Notes

NONE

cc @abayer @lbernick @pritidesai

/lgtm
Much less ugly than my original effort! =)

@abayer @pritidesai - thank you for the reviews, this PR is ready for another look (cc @lbernick)

/lgtm

authors: abayer jerop


text:
🛑 Observatoire des Saisons is down

In 3bbb349, Observatoire des Saisons (https://www.obs-saisons.fr/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Observatoire des Saisons is back up in 52f04af after 1 hour, 2 minutes.

repo: telabotanica/status


text:
Issue/doc update

REVIEWERS
@hmunfru
DESCRIPTION
Resolve some problems in the ReadTheDocs documentation

LGTM

authors: flopezag hmunfru

repo: telefonicaid/fiware-paas


text:
License and PyPI package

Hi!
We would like to use this package with our library called your.
Can you please add a license and, if possible, make it available via PyPI.
Thanks!

Hey @devanshkv -- agreed this should have a license. This has portions of code extracted from sigpyproc so dependent on that.

@ewanbarr would you be happy for this code to be licensed under MIT? (I've basically just wrapped the sigpyproc 1/2/4 bit unpack code with pybind11 so you can use it on numpy arrays)

@telegraphic No objections from me.

Hooray, thanks Ewan 🎉

authors: devanshkv ewanbarr telegraphic

repo: telegraphic/numbits


text:
Publicar código no npm

Publicar versão que possa ser usada:

No navegador, talvez usando o unpkg
Em projetos ES6 com import
Em projetos node com require

https://docs.github.com/en/packages/guides/configuring-npm-for-use-with-github-packages

Feito https://www.npmjs.com/package/spreadparser

repo: teles/spreadparser


text:
Feature/claim aave comp to user

Claim aave and comp to user if loan status is completed or liquidated. If not, claim accrued interest to escrow address

yarn test polygon gives me:
18 passing (2m)
1 failing

Story Test Suite - DAPP.CLAIM.AAVE
AAVE Claim AAVE:
Error: VM Exception while processing transaction: reverted with reason string '29'

Do you see the same ?

yarn test polygon gives me:
18 passing (2m)
1 failing

Story Test Suite - DAPP.CLAIM.AAVE
AAVE Claim AAVE:
Error: VM Exception while processing transaction: reverted with reason string '29'

Do you see the same ?

yes, same.
On the issue

authors: admazzola dumebi


text:
Variable rendering error in v2.0.7

Teller was functioning correctly using variables in my yml file, until I upgraded to version 2.0.7. After upgrading I get the following error:
Error: Failed to render '__tera_one_off'

Caused by:
    Variable `env_prefix` not found in context while rendering '__tera_one_off'

Location:
    /tmp/teller-20240519-15158-k6qv7l/teller-2.0.7/teller-cli/src/cli.rs:218:18

My teller.yml file looks like this:
project: test

opts:
  env_prefix: env:ENV_PREFIX
  env_devregion: env:DEVOPS_REGION

providers:
  hashicorp_vault:
    env:
      TF_VAR_nr_license_key:
        path: "{{env_prefix}}-test-secrets/data/newrelic"
        field: nr_license_key
      TF_VAR_nr_api_key:
        path: "{{env_prefix}}-test-secrets/data/newrelic"
        field: nr_api_key
...

ENV_PREFIX and DEVOPS_REGION are env vars that are predefined on my system.

Hi
Please notice that Teller 2.0 is a complete rewrite, and so there are a different config templating constructs.

OK. Looks like I need to do a rework on my teller config file due to the tera templating system. Thanks for the pointer. I'll close this issue.

authors: jderieg jondot

repo: tellerops/teller


text:
Database url

Fixes: #200

Pull Request Test Coverage Report for Build 366706449

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 36.572%

Totals

Change from base Build 362582871:
0.0%

Covered Lines:
1596

Relevant Lines:
4364

💛  - Coveralls

authors: coveralls themandalore

repo: tellor-io/TellorMiner


text:
Expand navBar if scrollView's window is visible

Fixes an issue when the navigation bar is manually hidden in another UIViewController in the stack. This PR makes sure that when the app becomes active it will only expand the navBar if the current scrollView is visible on the window.

Makes sense! Thanks!

authors: Mazyod greis

repo: telly/TLYShyNavBar


text:
update: docs url

Update doc url

Thanks!

Pull Request Test Coverage Report for Build 11033773398
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 93.027%

Totals

Change from base Build 10826744301:
0.0%

Covered Lines:
1561

Relevant Lines:
1678

💛  - Coveralls

authors: PyaeSoneAungRgn brendt coveralls

repo: tempestphp/highlight


text:
Fix typo

middleware instead of middelware

This fix is also contained in #10

repo: tempestphp/tempest-docs


text:
🛑 MYSITE2 is down

In 44d14af, MYSITE2 ($SECRET_SITE_OBOERU) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MYSITE2 is back up in e7dd222 after 9 minutes.

repo: templain/mywatcher


text:
🛑 Secret Site2 is down

In 4660394, Secret Site2 ($SECRET_SITE_2) was down:

HTTP code: 404
Response time: 91 ms

Resolved: Secret Site2 is back up in 3438b75.


text:
bump node 20.11.0 LTS

Applied mkpr on package.json
sed s/"node": ">=20.10.0"/"node": ">=20.11.0"/

Pull Request Test Coverage Report for Build 7486769270
Warning: This coverage report may be inaccurate.
We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 58.883%

Totals

Change from base Build 7466541505:
0.0%

Covered Lines:
109

Relevant Lines:
182

💛  - Coveralls

repo: template-tools/template-sync-cli


text:
chore(deps): bump

Applied mkpr on undefined
/tmp/mkpr.sh

:tada: This PR is included in version 1.10.31 :tada:
The release is available on:

v1.10.31
GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:

repo: template-tools/template-sync-hook


text:
merge from template-kronos-app

.github/workflows/ci.yml

chore: add actions/setup-node@v4 (jobs.test-node.steps.uses)
chore: add actions/setup-node@v4 (jobs.release.steps.uses)

.github/workflows/codeql_analysis.yml

chore: add actions/setup-node@v4 (jobs.analyze.steps.uses)

.github/workflows/update_package_lock.yml

chore: add actions/setup-node@v4 (jobs.update_package_lock.steps.uses)

:tada: This PR is included in version 1.11.0 :tada:
The release is available on:

npm package (@latest dist-tag)
v1.11.0
GitHub release

Your semantic-release bot :package::rocket:


text:
Simplify async activity implementation

To not tie up threads users requested support for activity implementations that return CompletableFuture. As we don't want to have Future in the activity API the strawman proposal is to add adapter methods that can be called from activity (similar to Async class from workflow package)
class ActivityAsync {
  public static <A1, R> R function(Functions.Func1<A1, CompletableFuture<R>> function, A1 arg1) { ... }
  // similar methods for procedures and argument counts
}

Then an activity implementation could look like:
String myActivity(String foo) {
   return ActivityAsync.function(myActivityReturningFuture, foo);
}

CompletableFuture<String> myActivityReturningFuture(String foo) {
   ...
}

where only myActivity method is part of the interface. Then a dynamic proxy adapter can be written to convert from a class that has methods that return ComletableFutures to the activity interface that returns values:
interface MyActivities {
   String foo();
   void bar();
}

@ActivitiesImplementation(implements=MyActivities.class)
class MyActivitiesImpl {
   CompletableFuture<String> foo();
   ComletableFuture<Void> bar();
}

Then the Worker would just accept MyActivitiesImpl instance and internally create the dynamic proxy.

Resolved in https://github.com/temporalio/sdk-java/pull/291
We now provide ability to get a completion client easily thus simplifying user experience.

Resolved in https://github.com/temporalio/sdk-java/pull/291
We now provide ability to get a completion client easily thus simplifying user experience.

authors: mfateev vitarb

repo: temporalio/sdk-java


text:
Rename UpdateHandle to WorkflowUpdateHandle (💥 - incompatible change)

What was changed

Renamed UpdateHandle to WorkflowUpdateHandle.
This is a breaking change.
⚠ Feature tests are failing; I can update them as a fast follow-up.
Why?

Consistency. (as discussed previously)
Checklist

How was this tested:
Existing tests.
Any docs updates needed?
I checked https://docs.temporal.io/develop/java/message-passing and the UpdateHandle type isn't mentioned anywhere.
I also cannot see it in the samples repo (search)
The release docs will need to mention this change, though.

LGTM, you'll need to create a feature branch and update the code since it did use UpdateHandle

Let me know if you need any help with that!

👀 https://github.com/temporalio/features/pull/532

LGTM!

authors: Quinn-With-Two-Ns stephanos


text:
Add support for yml based TLS configurations

New key: TEMPORAL_TLS_CONFIG_PATH
yml file format:
cert: <certData in base64>
key: <keyData in base64>
clientca: <caData in base64>
hostname: hostname

so we have two ways to config TLS now. could we document whichever we think most people will use? perhaps even suggesting a default location.

authors: feedmeapples sw-yx

repo: temporalio/web


text:
Develop

Add: suport for sorting select dropdown options
Fix: hard error on a failed api response
Fix: select dd options sorting for case-insensitive labels

@Nitinrajyadav can you please fix merge conflict.


text:
OGPのサムネをいい感じにする

現在、OGPのサムネイルには固定の画像が表示されているため、各ページで異なる内容が表示されるようにしたい。

異なる内容ではなく、適当な画像に変更してclose
8fff318a64cfeb8e1bbbeea1a302db0b312e33fd


text:
Details about resampler/Q-former

Hello, thank you for sharing this impressive work as open source!
In your wiki section, I came across the statement "we use a Q-Former (16 tokens) to extract face features from CLIP image embeddings." Does the Q-former correspond to the resampler structure here? If so, it appears to be a modified Q-former without self-attention. Consequently, there may be no interaction among queries, correct?
I'm also curious about the PerceiverAttention line 63, where it seems that the key and value take both x and latent as input. I'm interested to know the reasoning behind designing a cross-attention like this.
Thank you in advance for your insights!

the keys and values of attention include self feature https://github.com/tencent-ailab/IP-Adapter/blob/main/ip_adapter/resampler.py#L63, hence, there is interaction among queries. You can think that we merge a self-attention and a cross-attention into a attention.

repo: tencent-ailab/IP-Adapter


text:
🛑 Beeldoverleg Website is down

In 38e1daa, Beeldoverleg Website (https://beeldoverleg.nl) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Beeldoverleg Website is back up in 1eb8144 after 12 minutes.

repo: tendsgn/upptime


text:
Mps expectation values

Opening this PR so we can discuss and see it in the v1.0 milestone.

This branch had changes on top of the shift-symmetry branch (#183) starting with a8844fe2309f108953ba5cd5cdb60859b0e566dc.
With Wilhelm, we've rebased those changes on top of the up-to-date main and merged them in #267.

authors: Jakob-Unfried jhauschild

repo: tenpy/tenpy


text:
🛑 Cloud Services (Onlyoffice) is down

In b87e710, Cloud Services (Onlyoffice) (https://onlyoffice.tcloud.dev) was down:

HTTP code: 523
Response time: 3247 ms

Resolved: Cloud Services (Onlyoffice) is back up in 6230f45 after 6 hours, 17 minutes.

repo: tensegrity-labs-admin/uptime


text:
feat: Support cli argument for host key

If you don't specify a host key, it will generate one every time. This is convenient except you'll have to deal with clients being confused that the host key is different. It's a better idea to generate or point to an existing key on your system:

https://pkg.go.dev/github.com/gliderlabs/ssh@v0.3.5
The host key in envd-sshd is generated every time. Thus the fingerprint of the sshd always changes. This PR is to add a cli argument to support custom host key.
Ref #101
Signed-off-by: Ce Gao cegao@tensorchord.ai

Ref https://www.ssh.com/academy/ssh/host-key

/lgtm

authors: VoVAllen gaocegege

repo: tensorchord/envd


text:
Callbacks: Initial Folder Setup

Initial Folder Setup for Callbacks submodule

In your BUILD file you've included OneCycleLR and its test, but there's no implementation. If you want, you can close this PR and open one after your implementation is complete, or you could keep updating this PR.

@Gokkulnath Updates?

@Gokkulnath I've created the structure for callbacks. You can open another PR with the implementation of OneCycleLR. Thanks for your contribution.

authors: Gokkulnath Squadrick

repo: tensorflow/addons


text:
seg fault trying starter ipython notebook in ipython - linux

I just tried some of the notebook and I got a segfault. Here is what my session looks like, this is from ipython in a conda environment, will describe the environment below:
(ana-1.2.7-gpu) : ~ $ ipython
Python 2.7.12 |Continuum Analytics, Inc.| (default, Jul  2 2016, 17:42:40)
Type "copyright", "credits" or "license" for more information.

IPython 5.3.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import random
   ...: import tensorflow as tf
   ...: sess = tf.InteractiveSession()
   ...: import tensorflow_fold as td
   ...:
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcublas.so.8.0 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcudnn.so.5 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcufft.so.8.0 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcuda.so.1 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcurand.so.8.0 locally
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE3 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.1 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.2 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use AVX instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use AVX2 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use FMA instructions, but these are available on your machine and could speed up CPU computations.
I tensorflow/core/common_runtime/gpu/gpu_device.cc:885] Found device 0 with properties:
name: Tesla P100-PCIE-16GB
major: 6 minor: 0 memoryClockRate (GHz) 1.3285
pciBusID 0000:02:00.0
Total memory: 15.89GiB
Free memory: 15.61GiB
I tensorflow/core/common_runtime/gpu/gpu_device.cc:906] DMA: 0
I tensorflow/core/common_runtime/gpu/gpu_device.cc:916] 0:   Y
I tensorflow/core/common_runtime/gpu/gpu_device.cc:975] Creating TensorFlow device (/gpu:0) -> (device: 0, name: Tesla P100-PCIE-16GB, pci bus id: 0000:02:00.0)
I tensorflow/core/common_runtime/gpu/gpu_device.cc:975] Creating TensorFlow device (/gpu:0) -> (device: 0, name: Tesla P100-PCIE-16GB, pci bus id: 0000:02:00.0)
In [2]: scalar_block = td.Scalar()
   ...: vector3_block = td.Vector(3)
   ...:
   ...:

In [3]: def block_info(block):
   ...:     print("%s: %s -> %s" % (block, block.input_type, block.output_type))
   ...:
   ...: block_info(scalar_block)
   ...: block_info(vector3_block)
   ...:
<td.Scalar dtype='float32'>: PyObjectType() -> TensorType((), 'float32')
<td.Vector dtype='float32' size=3>: PyObjectType() -> TensorType((3,), 'float32')

In [4]: scalar_block.eval(234)
Segmentation fault (core dumped)

I'm on red hat 7 - linux, working from a anaconda environment. I have
cudnn 5.1
tensorflow-gpu 1.0.1
which were done as proper conda packages, I made the packages myself -- I did not build tensorflow with bazel, use wrap the output of pip in a conda package.
Then I did a pip install to get tensorflow-fold 0.0.1, being to lazy to make a proper conda package out of it since I wanted to quickly try it.
Maybe it is some weird issue with the construction of the environment, but thought I'd mention it in case you haven't tested this combo - ipython/tensorflow-gpu/tensorflold

did you try running this with tensorflow 1.0.0?

authors: davidslac mbosnjak

repo: tensorflow/fold


text:
moved NIPS and ai-duet into a demos folder

Not a huge change, but will be helpful to have demos all in one place as we add more (nsynth etc.)

I also think we should consider renaming NIPS_2016 to something like ai-jam

Sounds reasonable. Maybe ableton-jam, or ableton-ai-jam, to make it more clear? @cghawthorne , should this be inside or outside the main magenta folder? The jam does have a dependency on having the pip package installed, but doesn't need to include anything in the pip package itself.

authors: adarob jesseengel

repo: tensorflow/magenta


text:
Modifying recurrent layer for readability

As discussed here.
This is a WIP. I'd like to discuss about a few things before changing them.
In the RNN, h_W, h_b correspond to Weight and bias. The h_ prefix for hidden.
I was unsure about what to write concatenatedInputSize.
Finally, I wanted to write newState as c_t, but didn't because the naming convention in that case was for cell state at time t. But since we are talking about a single cell, any ideas as to what we can change that to.
In the LSTM, It was much easier, All gates were made into short forms with weight changed to _W and bias changed to _b.
Finally, I was wondering how to italicize the text for u,o,f like it was done in #110 .
newHiddenState and newCellState can we written as h_t and c_t. I just wanted to confirm if that was okay.
Should this convention be added to the comments as well?
I'm sorry for so many question.

cc: @rxwei , @dan-zheng.

@rxwei any comments on,

newHiddenState and newCellState can we written as h_t and c_t. I just wanted to confirm if that was okay.

and this

I was unsure about what to write concatenatedInputSize.

@rxwei any other notable changes in this? Should we wait for @dan-zheng to review and comment on this?

@rxwei can this be merged?

There are four test failures. Could you please look into fixing them?
Test Case '-[DeepLearningTests.LayerTests testRNN]' started.
/Users/rxwei/Development/ML/swift-apis/Tests/DeepLearningTests/LayerTests.swift:106: error: -[DeepLearningTests.LayerTests testRNN] : XCTAssertEqual failed: ("[[[ -0.00262943, -0.005866742,  0.044919778,   0.20036437]], [[0.066890605, 0.049586136, 0.024610005,  0.09341654]], [[0.065792546, 0.009325638,  0.06439907, 0.114802904]], [[  0.055909205, 0.00035158166,   0.054020774,    0.09812111]]]") is not equal to ("[[[-0.0026294366, -0.0058668107,    0.04495003,    0.20311214]], [[ 0.06788494, 0.050665878,  0.02415526,  0.09249911]], [[ 0.06621192, 0.009049267, 0.065047316,  0.11534518]], [[   0.05612204, 0.00022032857,    0.05407162,    0.09784105]]]")
/Users/rxwei/Development/ML/swift-apis/Tests/DeepLearningTests/LayerTests.swift:111: error: -[DeepLearningTests.LayerTests testRNN] : XCTAssertEqual failed: ("[[          0.0,           0.0,           0.0,           0.0],
 [-0.0051169936,  0.0014167001,  0.0074189613,   0.017496519],
 [ -0.010233987,  0.0028334002,  0.0148379225,   0.034993038],
 [ -0.015350982,  0.0042501003,   0.022256885,    0.05248956],
 [          0.0,           0.0,           0.0,           0.0],
 [          0.0,           0.0,           0.0,           0.0],
 [          0.0,           0.0,           0.0,           0.0],
 [          0.0,           0.0,           0.0,           0.0]]") is not equal to ("[[          0.0,           0.0,           0.0,           0.0],
 [-0.0051278225,  0.0013102926,    0.00740262,   0.018119661],
 [ -0.010255645,  0.0026205853,    0.01480524,   0.036239322],
 [ -0.015383467,   0.003930878,    0.02220786,   0.054358985],
 [          0.0,           0.0,           0.0,           0.0],
 [          0.0,           0.0,           0.0,           0.0],
 [          0.0,           0.0,           0.0,           0.0],
 [          0.0,           0.0,           0.0,           0.0]]")
/Users/rxwei/Development/ML/swift-apis/Tests/DeepLearningTests/LayerTests.swift:120: error: -[DeepLearningTests.LayerTests testRNN] : XCTAssertEqual failed: ("[-0.051169936,  0.014167001,   0.07418961,   0.17496519]") is not equal to ("[-0.051278222,  0.013102926,    0.0740262,   0.18119662]")
Test Case '-[DeepLearningTests.LayerTests testRNN]' failed (0.016 seconds).
Test Case '-[DeepLearningTests.LayerTests testSimpleRNNCell]' started.
/Users/rxwei/Development/ML/swift-apis/Tests/DeepLearningTests/LayerTests.swift:95: error: -[DeepLearningTests.LayerTests testSimpleRNNCell] : XCTAssertEqual failed: ("[[0.9921227, 0.9999934, 0.9921227, 0.9999934, 0.9921227]]") is not equal to ("[[  2.76649, 6.2999997,   2.76649, 6.2999997,   2.76649]]")
Test Case '-[DeepLearningTests.LayerTests testSimpleRNNCell]' failed (0.001 seconds).
Test Suite 'LayerTests' failed at 2019-04-25 18:52:18.315.
	 Executed 10 tests, with 4 failures (0 unexpected) in 0.057 (0.057) seconds

Oh I'm sorry I had no idea. I had been relying on docker for that. I'll fix them.

Thanks. The docker CI is currently down, so we need to manually run swift test.

@rxwei I think that should solve it, there was a mismatch since i didnt reflect the change in the test file.

@saeta I think this works now.

@rxwei althought i've made all the required changes, i seem to be getting a mismatch test error where the output of my layer is
[[0.9921227, 0.9999934, 0.9921227, 0.9999934, 0.9921227]

while the one in the test is : [[2.76649, 6.2999997, 2.76649, 6.2999997, 2.76649]])

I fail to see how this improves the readability of this Layer. If the goal is to build Swift friendly APIs then it would make sense to follow the common naming and code styling conventions adapted by the Swift community.
For upper level (exposed) APIs consistency with Keras would make sense but for implementations writing swifty code would be easier to maintain in the long run in my opinion.

I fail to see how this improves the readability of this Layer. If the goal is to build Swift friendly APIs then it would make sense to follow the common naming and code styling conventions adapted by the Swift community.
For upper level (exposed) APIs consistency with Keras would make sense but for implementations writing swifty code would be easier to maintain in the long run in my opinion.

Thanks for raising your concerns. As a Swift API designer who absolutely enjoys Swift naming conventions, I don't quite agree with your view. A key part of the Swift API Design Guidelines is "strive for fluent usage". The Use Terminology Well section has a great explanation on how to strike a balance between general Swift names and established terms of art.
While avoiding abbreviations is generally the code style for Swift application projects and a lot of our carefully curated APIs, the goal there is clarity and fluency, not merely consistency. Deep learning layers often have a canonical definition on papers, and their Wikipedia pages often use short mathematical symbols. When code looks like their canonical definition in paper, it is immediately readable and fluent.
To quote the Swift API Design Guidelines:

Stick to the established meaning if you do use a term of art.
The only reason to use a technical term rather than a more common word is that it precisely expresses something that would otherwise be ambiguous or unclear. Therefore, an API should use the term strictly in accordance with its accepted meaning.

Don’t surprise an expert: anyone already familiar with the term will be surprised and probably angered if we appear to have invented a new meaning for it.
Don’t confuse a beginner: anyone trying to learn the term is likely to do a web search and find its traditional meaning.

Embrace precedent. Don’t optimize terms for the total beginner at the expense of conformance to existing culture.
It is better to name a contiguous data structure Array than to use a simplified term such as List, even though a beginner might grasp of the meaning of List more easily. Arrays are fundamental in modern computing, so every programmer knows—or will soon learn—what an array is. Use a term that most programmers are familiar with, and their web searches and questions will be rewarded.
Within a particular programming domain, such as mathematics, a widely precedented term such as sin(x) is preferable to an explanatory phrase such as verticalPositionOnUnitCircleAtOriginOfEndOfRadiusWithAngle(x). Note that in this case, precedent outweighs the guideline to avoid abbreviations: although the complete word is sine, “sin(x)” has been in common use among programmers for decades, and among mathematicians for centuries.

These recommendations from the Swift API Design Guidelines heavily influenced some of the important decisions made in Swift Evolution reviews of standard library numerics. To quote some proposal review decision rational for SE-0251:

It is a primary goal of Swift to support fluent and expressive libraries. The API design guidelines 1 are explicit that the highest priority in library design is clarity at the point of use. Consistency is only a means to that end, not a goal in itself. In many cases, using a uniform language construct like method calls to spell an API is good design because the consistency contributes to clarity: programmers already understand how method calls work, and method calls combine naturally with features like optional chaining instead of requiring circumlocutions that would harm the overall clarity of the code. But any and all will often be used directly on the result of a binary comparison, making a method call awkward and harder to read, and they will often be used directly as if conditions and rarely in conjunction with optional chaining. In this case, the Core Team feels that a more "DSL-like" approach like that proposed for any and all creates an overall more fluent API.

Specifically about this PR that changes RNNs to use terms of art, the use of non-camel-case variable names are definitely weird in the context of most other Swift application APIs, but the code is more fluent and more mathematically relatable in this domain. As Swift has just take off in the space of machine learning, we should absolutely strive to find the right balance between these naming options while always remembering that our goal is to design expressive and fluent APIs for machine learning.

Thank you @rxwei for your detailed response, it was informative. I am not 100% sold but I get your point.

Thanks! I'm not 100% sold on W_i either because there are other options such as wh, Wh. It would be very useful to start a conversation about "naming mathematical variables in numerical Swift code" at some point with the Swift community and the Swift for TensorFlow community and standardize things.

@rxwei @dan-zheng can you maybe run the swift test once and tell me what values you get for the tests, i seem to have some discrepancies when i do it locally, for example :

and

The latter though, feels like the system is rounding off somewhere where it's unwanted.

@rxwei I have concern against these changes. They've made the code harder to read.
It's not obvious for a new reader what do these variables represent:
public var W_i, W_u, W_f, W_o: Tensor<Scalar>
public var b_i, b_u, b_f, b_o: Tensor<Scalar>

There is no convention on them in the literature. The RNN Wikipedia article doesn't state them at all. We do not want the reader to guess variables meaning, right? So, a comment is needed. And then we need to maintain that comment to keep it in sync with the code. And the reader should keep variable meanings he learned from the comment in short-term memory while reading the code. And learn again each time he forgot them once he has not read the code for a while.
All this doesn't sound like good DX to me and definitely doesn't make reading easier. It doesn't even make writing easier because of autocompletion.
I propose to keep the code self-documented and not to bind names to unconventional notation that need to be explained. I'm for rejecting these changes.

@liberium I will write comments for these once they are approved and i go update the respective changes.
Just one point, I would like to mention is anyone researching in Deep learning would have a fair idea of the four gates within an LSTM and the respective mathematical equations. The earlier names, although good were too long, So in my opinion it would be better if we wrote the code in terms of the mathematical equations they represented and this has been an attempt at that. When i read this code, since i come from a research perspective, this makes a lot of sense to me. So I will either write the equations themselves in the comments or link to the paper.

While I agree mostly with @Shashi456, I'm not fully sold on either end. Notations in publications are not unified either. Let's keep the current state as is for now, and find the most productive way to find a consensus. I plan to start a serious investigation about naming some time next month, and post on the mailing list and Swift forums.

@rxwei should I close this PR then?
It's just that whatever notations ive seen across various framework in deep learning, have a short-form notation like this and they have just explained what they stood for in the comments.

@rxwei should I close this PR then?

Sounds good!

Also, thank you @Shashi456 for driving this.  We'll get back to it in a month or two.

@Shashi456 I agree on using W, x, and b as arguments to a linear classifier because they are absolutely conventional across the literature.
But it's not the case here and some kind of compromise should be accepted.
It could be a hybrid naming scheme:
public var W_in, W_update, W_forget, W_out: Tensor<Scalar>
public var b_in, b_update, b_forget, b_out: Tensor<Scalar>

Thank you for the detailed answer.

This is from the wikipedia for LSTMs :

and this is from the wikepedia for RNNs:

So in a very straightforward manner, W_f, W_o correspond to the weights for forget, and output gates, so on so forth.

I don't see W_u in LSTM formulas. But it could be renamed in the code.
To get the best of two worlds, I propose to follow the hybrid scheme above, refer to the Wikipedia article in the code (/// above the function) and leave a comment on the meaning of the variables (// near the variables declaration).

authors: MostafaGazar Shashi456 liberium rxwei

repo: tensorflow/swift-apis


text:
Use control flow AD in layers and add leak checking utility.

Remove custom VJPs from all layers so that they go through control flow differentiation. This applies to BatchNorm and Dropout. Dense was already using control flow differentiation.
Introduce a tensor leak checking test utility withTensorLeakChecking { ... } and use it in tests. A globalTensorCount variable is added to the thread-local Context to keep track of the number of live tensors, and TFETensorHandle's init(_owning:) and deinit increases and decreases globalTensorCount, respectively.
Resolves #389.

Tests are failing because the toolchain is old. We are updating it later today.

This is awesome!

authors: lattner rxwei


text:
TypeError: Cannot interpret feed_dict key as Tensor: The name 'save/Const:0' refers to a Tensor which does not exist. The operation, 'save/Const', does not exist in the graph.

From this file: https://github.com/llSourcell/pong_neural_network_live/blob/master/RL.py
I've updated the lines
#first convolutional layer. bias vector
#creates an empty tensor with all elements set to zero with a shape
W_conv1 = tf.Variable(tf.zeros([8, 8, 4, 32]) , name='W_conv1')
b_conv1 = tf.Variable(tf.zeros([32]), name='b_conv1')

W_conv2 = tf.Variable(tf.zeros([4, 4, 32, 64]), name='W_conv2')
b_conv2 = tf.Variable(tf.zeros([64]), name='b_conv2')

W_conv3 = tf.Variable(tf.zeros([3, 3, 64, 64]), name='W_conv3')
b_conv3 = tf.Variable(tf.zeros([64]), name='b_conv3')

W_fc4 = tf.Variable(tf.zeros([3136, 784]), name='W_fc4')
b_fc4 = tf.Variable(tf.zeros([784]), name='b_fc4')

W_fc5 = tf.Variable(tf.zeros([784, ACTIONS]), name='W_fc5')
b_fc5 = tf.Variable(tf.zeros([ACTIONS]), name='b_fc5')

and:
saver.save(sess, './' + 'pong' + '-dqn', global_step = timestamp )

and in:
def main():
    # ////
    tf.reset_default_graph()
    imported_meta = tf.train.import_meta_graph('./' + 'pong' + '-dqn-' + '48000' + '.meta')
    imported_meta.restore(sess, tf.train.latest_checkpoint('./'))
    # ////

To try and restore the model but I get this error:
TypeError: Cannot interpret feed_dict key as Tensor: The name 'save/Const:0' refers to a Tensor which does not exist. The operation, 'save/Const', does not exist in the graph.
When I try this:
 graph = tf.get_default_graph()
 W_conv1 = graph.get_tensor_by_name("W_conv1:0")
 b_conv1 = graph.get_tensor_by_name("wb_conv1:0")
 W_conv2 = graph.get_tensor_by_name("W_conv2:0")
 b_conv2 = graph.get_tensor_by_name("wb_conv2:0")
 W_conv3 = graph.get_tensor_by_name("W_conv3:0")
 b_conv3 = graph.get_tensor_by_name("b_conv3:0")
 W_fc4 = graph.get_tensor_by_name("W_fc4:0")
 b_fc4 = graph.get_tensor_by_name("b_fc4:0")
 W_fc5 = graph.get_tensor_by_name("W_fc5:0")
 b_fc5 = graph.get_tensor_by_name("b_fc5:0")

I get this error:
"The name 'W_conv1:0' refers to a Tensor which does not exist. The operation, 'W_conv1', does not exist in the graph.
Why is this happening? I've created my game in pygame and I'm trying to connect it to the RL. I'd like to make sure I can save and load my progress. I'm just having trouble with the logic of how to save and load.
Thanks in advance!
Why is this happening?

It's hard to help without the details asked for in the new issue template (which includes information about the version of TensorFlow being used) and detailed instructions to reproduce the problem (ideally ones which do not involve having to install additional libraries, scan through some other code  and manually merge snippets).
I tried the following in TensorFlow 1.4.0 and 1.3.0 but was unable to reproduce the problem you observed:
import tensorflow as tf

def save():
  W_conv1 = tf.Variable(tf.zeros([8, 8, 4, 32]), name='W_conv1')
  saver = tf.train.Saver()
  with tf.Session() as sess:
    sess.run(tf.global_variables_initializer())
    saver.save(sess, '/tmp/foo')

def load():
  with tf.Graph().as_default():
    saver = tf.train.import_meta_graph('/tmp/foo.meta')
    with tf.Session() as sess:
      saver.restore(sess, tf.train.latest_checkpoint('/tmp'))

      graph = tf.get_default_graph()
      print(graph.get_tensor_by_name("W_conv1:0"))

save()
tf.reset_default_graph()
load()

Perhaps this isn't accurately reproducing what you're trying. If you could provide a similar self-contained snippet, that would enable us to debug and help.

Nagging Awaiting Response: It has been 14 days with no activityand the awaiting response label was assigned. Is this still an issue?

I am having a similar issue. I have an RNN that I'm running in a CV loop and each time through the loop I call a function to make the model. (If I reuse the same model, it continues training, which renders CV useless.) Just to be safe, I included tf.reset_default_graph() at the start of the model-making function and on the second time through the CV loop I get the error:
ValueError: Tensor Tensor("embedding_input:0", shape=(?, ?), dtype=float32) is not an element of this graph.
and
TypeError: Cannot interpret feed_dict key as Tensor: Tensor Tensor("embedding_input:0", shape=(?, ?), dtype=float32) is not an element of this graph.

Nagging Awaiting Response: It has been 14 days with no activityand the awaiting response label was assigned. Is this still an issue?

Nagging Awaiting Response: It has been 14 days with no activityand the awaiting response label was assigned. Is this still an issue?

It has been 14 days with no activity and the awaiting response label was assigned. Is this still an issue?

It has been 14 days with no activity and the awaiting response label was assigned. Is this still an issue?

It has been 29 days with no activity and the awaiting response label was assigned. Is this still an issue?

authors: LoseTheQuit asimshankar tensorflowbutler waynefoltaERI

repo: tensorflow/tensorflow