Metadata Undefined

Please describe your problem in as much detail as possible:
Metadata is undefined when playing any song. Have tried to update node,distube.
Further information:
distube.on("playSong", (queue, song) => { console.log(song.metadata); }

DisTube version: latest
discord.js version: 12.5.3
Node.js version: latest
Operating system: Heroku Host (linux?)

Because metadata property is what you attached with #play method. Make sure this option is defined.
https://distube.js.org/#/docs/DisTube/stable/class/DisTube?scrollTo=play

Sorry I cannot seem to find a way to define the metadata, how would I do this?
Would it be like this? because if so I still can't get the metadata to show.
distube.play(message.member.voice?.channel, args.join(" "), {
member: message.member,
textChannel: message.channel,
message,
metada: queue?.songs[0]?.metadata,

Metadata is what you define, distube doesn't define it.
Example:
.play(..., {metadata: 1})

.on("playSong", (queue, song) => {
    if (song.metadata === 1) console.log("This is the song played with metadata: 1 option.")
})

Oh alright. Now I understand. I thought it had information about the song in metadata.


Fix markdown link check github docs 403

Overview/Summary
Fixing 403 errors for GitHub Docs causing Markdown Link Checks to fail incorrectly.
Fix found here: https://github.com/tcort/markdown-link-check/issues/201
This PR fixes/adds/changes/removes

Fixing 403 errors for GitHub Docs causing Markdown Link Checks to fail incorrectly.

Breaking Changes
None
Testing Evidence
If markdown link check passes on this PR this is the evidence
As part of this Pull Request I have

[x] Read the Contribution Guide and ensured this PR is compliant with the guide
[x] Checked for duplicate Pull Requests
[ ] Associated it with relevant GitHub Issues
[ ] (ALZ Bicep Core Team Only) Associated it with relevant ADO Items
[x] Ensured my code/branch is up-to-date with the latest changes in the main branch
[x] Performed testing and provided evidence.
[x] Updated tests (if required) Unit - Linting - E2E (End-To-End)
[x] Updated relevant and associated documentation (e.g. Contribution Guide, Module READMEs, Wiki Docs etc.)
[x] If relevant, created or updated Code Tours here

/azp run e2e

/azp run e2e


Merging Develop into Master 7.8.2018 - removing helper functions that aren't actually supported

Hello @ksigler7,Thanks again for the PR! We appreciate your contribution and look forward to                                              continued collaboration. Thanks!                                             Team SendGrid DX


goerli: Advance Shooting Range decals wont disappear

Explorer Alpha build version:
0.3.402-g7a23dc7e-main
Issue Description:

When going to the position (83,-3) or (83,-1) we should be able to play on the practice shooting range, and interact with the targets.
The normal shooting range is working correctly, but the Advance Shooting Range still has an issue, namely:

The Bullet holes decals do not disappear after the allotted time, they stop moving with the targets for example, but they stay on the visible.

Evidence:
https://github.com/decentraland/unity-explorer/assets/56565104/f93cf1e7-217e-48b7-9ad5-85ea8af08839

The shooting range is working, the advance shooting range still has issues

We fixed the raycast issues, but there is still an issue with the Advance range and the bullet hole decals not disappearing. I updated the ticket with the relevant info.

Decal won't disappear because it contains 2 Entities, only parent Entity would be deleted, but child Entity stays in the world by this logic:
`
[Query]
[All(typeof(SDKTransform), typeof(TransformComponent), typeof(DeleteEntityIntention))]
private void OrphanChildrenOfDeletedEntity(ref TransformComponent transformComponentToBeDeleted)
{
foreach (EntityReference childEntity in transformComponentToBeDeleted.Children)
{
SetNewChild(ref World.Get(childEntity.Entity),
childEntity, 0, sceneRoot, SpecialEntitiesID.SCENE_ROOT_ENTITY);
}
transformComponentToBeDeleted.Children.Clear();

}
`

Previous renderer cleans entities recursively:
    void CleanUpEntityRecursively(IDCLEntity entity, bool removeImmediatelyFromEntitiesList)
    {
        using (var iterator = entity.children.GetEnumerator())
        {
            while (iterator.MoveNext()) { CleanUpEntityRecursively(iterator.Current.Value, removeImmediatelyFromEntitiesList); }
        }

        OnEntityRemoved?.Invoke(entity);

        if (Environment.i.world.sceneBoundsChecker.enabled)
        {
            entity.OnShapeUpdated -= OnEntityShapeUpdated;
            Environment.i.world.sceneBoundsChecker.RemoveEntity(entity, removeIfPersistent: true, resetState: true);
        }

        if (removeImmediatelyFromEntitiesList)
        {
            // Every entity ends up being removed through here
            entity.Cleanup();
            entities.Remove(entity.entityId);
        }
        else { Environment.i.platform.parcelScenesCleaner.MarkForCleanup(entity); }
    }

Pending comments from @nearnshaw


new static site generator for new ford

Fixes issue #818
Actually I rewrote the thing to be a simple generator that uses ford rather than a janky app that tries to replicate ford.
How it works now is you put your input files in /web/static-site, then run |static, and the output files will go in <pier>/.urb/put

Just getting around to reviewing this. On a fakezod I get this:
activated app home/static
%cx /~zod/home/~2018.10.4..22.00.06..6e2d/app/static/hoon
scry failed for
ford: %hood failed for /~zod/home/0/app/static/hoon:
ford: %core on /~zod/home/0/app/static/hoon failed:
>> [%mo-not-running %static %peer]
> |start %static
>=

There's apparently no app/static/hoon file in the %home desk. That's what
the "scry failed" error is trying to say, somewhat clumsily.
On Thu, Oct 4, 2018 at 3:01 PM Anthony Arroyo<EMAIL_ADDRESS>wrote:

Just getting around to reviewing this. On a fakezod I get this:
activated app home/static
%cx /~zod/home/~2018.10.4..22.00.06..6e2d/app/static/hoon
scry failed for
ford: %hood failed for /~zod/home/0/app/static/hoon:
ford: %core on /~zod/home/0/app/static/hoon failed:

[%mo-not-running %static %peer]
|start %static
=

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/822#issuecomment-427183970, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA1Y9U7qItJj6Qq6Oxj3hf2gIV_T3jXqks5uhoUvgaJpZM4W5Oa2
.

--
—
~rovnys-ricfer
https://urbit.org

Its not an app anymore bro, please read my comment.

whoa
—
~poldec-tonteg
http://urbit.org
On Thu, Oct 4, 2018 at 5:02 PM ixv<EMAIL_ADDRESS>wrote:

Its not an app anymore bro, please read my comment.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/urbit/arvo/pull/822#issuecomment-427206635, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABiQ46yXl9OFJZg92dqamJo-uXGjOc4rks5uhqGUgaJpZM4W5Oa2
.


Decouple from GLFW

I really like this library and would like to use it in my project. However, its dependency on GLFW conflicts with the windowing system already being used with another dependency.
I do not see any reason for this coupling - is there a way to simply render figure to an OpenCV image so that I can do what I want with it, without requiring GLFW create window function to be called?
Thanks in advance.

Closing - found a way around myself.

Closed - managed to solve myself. Basically, the windowing used in this library was conflicting with the windowing used by another, causing the program to crash. I made the following changes and everything works fine for my purposes:
Window::Window(std::string title)
    : offset_(0, 0),
      title_(std::move(title)),
      cursor_(-10, -10),
      name_("cvplot_" + std::to_string(clock())) {
  // cv::namedWindow(name_, cv::WINDOW_AUTOSIZE);     // causes conflicts
  // cv::setMouseCallback(name_, mouse_callback, this);     // causes conflicts
}

Hi @PatJRobinson, thanks for sharing how you addressed the issue. I had not considered your usecase, but it makes sense to use cvplot without rendering to the screen.


[v1.15] bpf: lxc: trace fixes

Resolving trivial conflicts, here is a manual backport of

[ ] #33083
[ ] #33085

Once this PR is merged, a GitHub action will update the labels of these PRs:
 33083 33085

/test-backport-1.15

/test-backport-1.15

/test-backport-1.15

/test-backport-1.15


keyError using example

Hi,
Thanks for this great demo!
However - when I run it (python 3.6 or python 2.7) I get the following problems:
1 - running as is I get no result from the calculation and a console error reporting "Lost remote after 10000ms"
2 - If I instead run the python code in the background (rather than from the electron app) then fire the electron app I see the following errors:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/gevent/greenlet.py", line 536, in run
    result = self._run(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.6/site-packages/zerorpc/core.py", line 166, in _async_task
    bufchan.close()
  File "/usr/local/lib/python3.6/site-packages/zerorpc/channel.py", line 202, in close
    self._channel.close()
  File "/usr/local/lib/python3.6/site-packages/zerorpc/heartbeat.py", line 70, in close
    self._channel.close()
  File "/usr/local/lib/python3.6/site-packages/zerorpc/channel.py", line 138, in close
    del self._multiplexer._active_channels[self._channel_id]
KeyError: '7abdbe44-4e8b-4b0a-879f-000000000000'
Fri Feb 17 12:28:19 2017 <Greenlet at 0x105142178: <bound method ServerBase._async_task of <zerorpc.core.Server object at 0x1045b6f28>>(<zerorpc.events.Event object at 0x104fc6870>)> failed with KeyError

This looks to be something to do with the way strings are being passed around, but any suggestions? Running on OSX

Hi.
Thanks for your interest. Sorry I don't have Macbook. So let me guess...
1
First of all, please download the repo as is. The code snippet in README.md may or may not be totally correct (it should be, but...)
It seems that the problem occurs on the python part.
(Maybe because of incorrect installation of gevent?)
run
# strongly recommend: do this inside virtualenv

# !! pay attention to this !!
pip install gevent

pip install pyzmq
pip install future # necessary in python 2
pip install msgpack-python

pip install zerorpc

# run
python ./pycalc/api.py
## start running on tcp://<IP_ADDRESS>:4242  <- this line should show up?

Open another terminal and run
zerorpc tcp://localhost:4242 calc "1 + 1"
## connecting to "tcp://localhost:4242" <- it should show up
## 2.0 <- it should show up

I believe that, if there are any errors, you should see the errors in the above two steps.
Furthermore, open python and check whether it works:
import gevent

For example, I have to run something like sudo apt-get install libevent-dev on Ubuntu Linux.
2
And since you run python as it is, and open Electron, then maybe you can try to comment out the python subprocess codes and see if it is ok?
I mean line 10 ~ 61 in https://github.com/fyears/electron-python-example/blob/master/main.js.
Why? Because you don't need to start a subprocess of python from node.js in this case

There is another problem. After npm installed dependencies there is an "Uncaught Error: Module version mismatch. Expected 50, got 51." bindings.js:83

Thanks for getting back to me so quick. I also have seen the Module mismatch error...
However - all of the tests you suggest above work correctly and as expected. I see no errors. I have also commented out lines starting the python subprocess.
It looks to me that this is something more fundamental in the python node zerorpc ?

@ar7max
When you are doing npm install, you need to specify npm_config_* as shown in here.
Pay attention to your electron version and
# Electron's version.
export npm_config_target=1.2.3

Then
rm -rf ~/.node-gyp
rm -rf ~/.electron-gyp
rm -rf ./node_modules

And try npm install again.
@mattloose
Very "interesting"... And I get confused... 🙁
Maybe your node.js code could not communicate with python server correctly????
How about this:

run standalone python server python pycalc/api.py

use another clean node.js environment, npm install zerorpc, then run line 1 ~ 12 in renderer.js in node.js cli. As you can see, the only thing it does is to call echo() function defined in the python part.

If, step 2 goes well, also try to invoke calc() from pure node.js environment (you know how to do it 😜). If it also goes well, then we know that some problems occur while installing node.js libraries for electron, which needs your further investigation.

@ar7max
One more thing, when you are in Windows, checkout the syntax about setting environment variables.
export npm_config_target=1.4.15 # electron version
export npm_config_arch=x64
export npm_config_target_arch=x64
export npm_config_disturl=https://atom.io/download/electron
export npm_config_runtime=electron
export npm_config_build_from_source=true

npm config ls

The above export K=V syntax is available for Linux/OS X, and git-bash and mingw bash, etc, on Windows. But it's NOT available on Windows cmd.exe or PowerShell. If you are in cmd.exe or PowerShell, use set K=V syntax as shown here.

@fyears using Arch Linux with Python 3.6.

Electron side works after setting env vars and re-installing node modules;
Python 3.6 side works fine after removing pypiwin32 dependency and running pip install again.

Not quite sure how I have fixed this, but a complete rebuild of electron and cleaning up of node seems to have worked. Thanks for the cool demo!

@ar7max By the way, may you consider removing my personal blog repo from your account? If necessary you may just fork the current dev repo instead of the blog repo. Thank you! :-)

@fyears, done.


No Single Mobs Spawn, Only MUD

terralith, byg, 1.18.2

https://pastebin.com/3zfYgBLN temporal fix but only for vanilla biome rather than nothing


Is it possible to get evaluation result synchronously?

Hi,
I need to evaluate an expression, but I need the result immediately, not wrapped into a promise. The evaluator is executed in a synchronous context and I cannot switch to async pattern. All used variables are ready, no promises.
Is this possible with the current version?
If not, are you planning to add this feature? How difficult is it to implement in current architecture, if I decide to add it by myself?
Thank you.

Sorry, I did not notice the closed ticket addressing this. Now I see, that is not possible. OK (sigh)...

Indeed-- that response is still accurate. Sorry Jexl doesn't fit the synchronous use case!


sumatrapdf: Fix URLs / Add ARM64 / Update to 3.5.2

Use target URLs as mentioned in #8679

Add ARM64 version

Update to 3.5.2

[x] I have read the Contributing Guide.

I had to choose the latest PR to merge due to the fact that it had been unmaintained for a long time.
go #12251


Download failed

Hi @007jiang7442262 - I just tested this with one of my packages and it worked great.


Unable to Achieve Custom Width in Custom Component Class

I would like to add a responsive custom width to a custom component class.
My (simplified) configuration looks like this:
spacing: {
      px: '1px',
      '0': '0',
      '1': '0.25rem',
      '2': '0.5rem',
      ...
      '16': '4rem',
      '18': '4.5rem' // This is custom
      ...
    }

My CSS looks like this:
@tailwind base;

@tailwind components;

.btn {
    @apply h-12 lg:w-18 m-0 p-0
}

@tailwind utilities;

I get this error:
 `@apply` cannot be used with `.lg\:w-18` because `.lg\:w-18` either cannot be found, or its actual definition includes a pseudo-selector like :hover, :active, etc. If you're sure that `.lg\:w-18` exists, make sure that any `@import` statements are being properly processed *before* Tailwind CSS sees your CSS, as `@apply` can only be used for classes in the same CSS tree.

Obviously I am missing something in how to configure things. Any help is appreciated.

You've got it configured correctly but you can't use @apply with responsive prefixes yet.
Explained in the docs here:
https://tailwindcss.com/docs/functions-and-directives#apply
TL;DR write it like this:
@tailwind base;
@tailwind components;
.btn {
@apply h-12 m-0 p-0
}
@screen lg {
.btn {
@apply w-18
}
}
@tailwind utilities;

Ah missed that in the documentation. Thanks for the prompt response.


Crystals not generating with 0.2.2

The natural crystals don't appear to be generating with 0.2.2.
To reproduce, create a new instance with ElecCore 1.4..130, Deep Resonance 0.2.2, Thermal Foundation 1.2.0-102, CoFHCore 3.0.4B1-308. Then use cofh clearblocks on a large area (I used 256x256) to remove water/lava/stone/sand/gravel. You'll see the standard ores, cofh ores and the DR ore but no crystals at all.
Thanks.

Actually they do generate but they are very rare. I just did the same test as you but instead I did: /cofh clearblocks McJty 256 256 256 deepresonance:resonatingCrystalBlock and it cleared a few.

Using your command I found a single crystal in the area. 1 crystal in 256 chunks? I'm sure part of that is just bad RNG, but if this mod is supposed to be an option for early game power maybe you should increase the default spawn rate a bit?

Yes I will probably increase it somewhat.

IIRC, this can be changed in the configs, right?

yes indeed. But I'll also increase the default


added tour, tools, workflow

Missing methyldackel tool on toolsched

Thanks @polkhe!
The tests are failing. Can you check, please?

@joachimwolff and @dpryan79, can you check?

@bebatut done :)

It is in the toolshed under its old name 'PileOMeth' https://toolshed.g2.bx.psu.edu/repository?repository_id=d32aec850d519e76

@joachimwolff and @dpryan79 is the content okay for you?

@bebatut Looks nice! You might add a small note in the methylation bias part mentioning that biases of less than 5% can be ignored. You're always going to get a bit of wiggle on those graphs and 5% higher/lower is well within the range of biological insignificance.

ping @polkhe. Can you add @dpryan79 comment, please?

@bebatut added remark

The tests are failing because Zenodo is down for now :(

It is green! Thanks @polkhe


Context menu: add context menu to streams tree

Actions:

Add entity to new space view
others??

Fixed by https://github.com/rerun-io/rerun/pull/5422


ws close multithreading

v0.14. A multithreaded call to close crashes. Review code, webSocket list has no locks, timer has no locks, close() do not support multithreading. How do I resolve a multithreaded call to close?Use uS::Async close()?

v0.14 is not developed or supported


docs: tutorial introducing request/reply

Description
The PR adds a tutorial document to demonstrate implementation of request/reply pattern with AsyncAPI under the Getting-Started content bucket
Related issue(s)
Related to #1434

/rtm


UISwipeGestureRecognizer

How can I use UISwipeGestureRecognizer on chartView? I wrote some code but it didn't work.

(void)viewDidLoad
{
UISwipeGestureRecognizer *swipeRight = [[UISwipeGestureRecognizer alloc] initWithTarget:self action:@selector(slideToRightWithGestureRecognizer:)];
swipeRight.direction = UISwipeGestureRecognizerDirectionRight;
[_chartView addGestureRecognizer:swipeRight];
}

-(void)slideToRightWithGestureRecognizer:(UISwipeGestureRecognizer *)gestureRecognizer{
NSLog(@"here");
}

There was a problem specifically in a PieChart/RadarChart, where after a gesture was cancelled, touches were not restored. That was fixed in the latest commit.
Other than that, UIGestureRecognizers should work, as most gestures are already handled by native UIGestureRecognizers.
You may want to loop the gestureRecognizers array of the view, and modify their properties to allow correctly playing with other conflicting gesture recognizers.

@elifsimit
hi, I have similar scenario with you,that,I disable Y axis scale,but I can not scroll tableview in the chart.
I just do a simple hack,that if chart disable Y axis scale,enable UITableView vertically scrolling.
		if !self.isScaleYEnabled {
			_outerScrollView?.nsuiIsScrollEnabled = true
		} else {
			_outerScrollView?.nsuiIsScrollEnabled = false
		}

in func @objc fileprivate func panGestureRecognized(_ recognizer: NSUIPanGestureRecognizer)
of BarLineChartViewBase.swift file
diff:
@@ -688,7 +688,11 @@ open class BarLineChartViewBase: ChartViewBase, BarLineScatterCandleBubbleChartD
                     if _outerScrollView !== nil
                     {
                         // Prevent the parent scroll view from scrolling
-                        _outerScrollView?.nsuiIsScrollEnabled = false
+                                               if !self.isScaleYEnabled {
+                                                       _outerScrollView?.nsuiIsScrollEnabled = true
+                                               } else {
+                                                       _outerScrollView?.nsuiIsScrollEnabled = false
+                                               }
                     }
                 }


JsDiagGetStackTrace returns empty array when stack is not empty

I'm having a bizarre issue where JsDiagGetStackTrace() returns an empty trace even when there's something on the stack.  This only seems to happen on Linux and what's very strange is that it appears to depend on optimization settings; I can't reproduce it in an unoptimized build at all (this being strange because ChakraCore itself is a fully optimized shared-library build in all cases, so the optimization settings of the host shouldn't matter).
To verify there was indeed something on the stack, I gave my debugger the following code:
function doStuff()
{
    print("Checkpoint 1");
    debugger;
    print("Checkpoint 2");
}
doStuff();

Running this code, execution pauses at the debugger statement but the backtrace is completely empty--and remains empty even as I step through the remainder of the code.
To rule out that this isn't a bug in one of my abstractions, I added some instrumentation at the point I actually retrieve the stack:
	if (JsDiagGetStackTrace(&backtrace) != JsNoError)
		return false;
	JsPropertyIdRef propId;
	JsValueRef propValue;
	int length;
	JsCreatePropertyId("length", 6, &propId);
	JsGetProperty(backtrace, propId, &propValue);
	JsGetValueType(propValue, &type);
	JsNumberToInt(propValue, &length);
	printf("%d: %d\n", type, length);

The output was 2: 0 (2 being JsNumber); so it seems that I've indeed been handed back a zero-length array.  If I recompile the host with -g instead of an optimization flag, this same code prints 2: 2 upon hitting the debugger statement.  It's very, very strange.

I note that this seems unlikely to be an optimizer bug, as the issue is equally reproducible with both gcc and clang.  The reproduction above was on Ubuntu 16.04; I've received reports of it happening on Arch Linux as well.

Adding the result of our discussion on gitter: This might be due to -fomit-frame-pointer in the host code leading to stacks that we can't traverse properly. I would have expected that we would get at least one frame since gdb was able to see at least one JS frame, but it might use a different stack walking approach to us.

Here's the root of the problem:

x64: https://github.com/Microsoft/ChakraCore/blob/dcecda54309f23f673aa0cc149eb65f0b2b8d72c/lib/Runtime/Language/amd64/StackFrame.cpp#L103
x86: https://github.com/Microsoft/ChakraCore/blob/dcecda54309f23f673aa0cc149eb65f0b2b8d72c/lib/Runtime/Language/i386/StackFrame.cpp#L32

tl;dr
Always compile the host with -fno-omit-frame-pointer if you need ChakraCore to be able to see the callstack at runtime.**
Having spent some time looking into this, what I've found out is that:

Traditionally on x86 and x64, BP is the nonvolatile register used to store the address where the current stack frame begins (EBP on i386, RBP on x64).  As this register is nonvolatile (saved in the prologue, restored in the epilogue), a stack trace can be generated simply by following the chain of pushed BP values up the stack, in the style of a linked list.  This is exactly what ChakraCore does when it needs to do a JavaScript stack walk.
Compiling with -fomit-frame-pointer, which is the default in GCC and Clang for all optimization levels other than 0, allows the compiler to not only avoid saving BP in every function, but also frees it up for use as a general-purpose volatile register.  So not only can that register no longer be relied upon to refer to the stack frame address--or even to be an address at all--it's no longer possible to follow BP up the stack as it might not even be saved.
When JsDiagGetStackTrace is called, ChakraCore begins walking the stack from that point, and promptly runs into a wall because BP was not saved for the function that made the call in the first place; without that, it's now impossible to find the return address and the walk fails.  It never sees the JavaScript calls simply because they are not visible to the stack walking mechanism.
I initially thought all calls to _AddressOfReturnAddress() might be unsafe as this Windows intrinsic is aliased to __builtin_frame_pointer(0) on xplat, but it turns out to be fine since the compiler is smart enough to leave BP alone for any function using the builtin.  This still doesn't help us walk the callstack, however, since the register is not saved for other functions.
Despite all this, GDB appears to be able to produce a backtrace even under these difficult circumstances.  It would be helpful to know what they're doing so that perhaps we could adopt that behavior.  For now though, it seems that including -fno-omit-frame-pointer when building the host is the only option if you need realtime stack traces.

Slight correction to the above: BP is saved for all calls regardless of the OFP optimization (and this must happen otherwise OFP would be an all-or-nothing optimization), however the saved BP values are not guaranteed to point to stack frames nor is the register itself.  So the problem remains.

@dilijev I see you closed this as Answered - but is this actually a bug?   I'll open it back up as a bug and let the folks working on debugging APIs decide.


just use one upload method, as go-acd can determine size itself now (fixes #874, #669)

This patch will break existing rclone features unless https://github.com/ncw/go-acd/pull/3 is merged first. See there for the details of this patchset.

(and of course, rclone needs its vendor version updated, which I didn't include in this patch)

Hi,
Write support seems working perfectly now, what about seeking write ?
I tried two method to download torrent directly on my mounted acd drive

NOT WORKING: preallocated file space --> before download, torrent client (qbittorrent in my case) write a blank file with 1 byte per 1 byte (this may take a very long time to build a 1go blank file) but after a while, the blank file upload failed with this error ...pacer: Rate limited, increasing sleep....
WORKS with issues.: not preallocated file space ---> the torrent download and upload in same time on acd mounted drive pretty well but if a close my torrent client or pause and restart on incompleted download, i have an I/O error.
NB: if i don't stop the download, the download is fine.

I will provide a complete log this afternoon.

I've merged that - thank you very much :-)
PS I'd like to get the ACD integration tests working again - did you have some patches for that too?


Some bugs on website

Hello. I'm faced some bugs on website elementary.io
First: Don' access to page
http://shot.qip.ru/00LtnB-61q1ISSOX/
Second: i'm pay 1$ and website was stoping.
Not download, not error. Only grey wrapper, when i click "download" button
http://shot.qip.ru/00LtnB-51q1ISSOY/
http://shot.qip.ru/00LtnB-61q1ISSOZ/
My country Russia. My browser Chrome.
ps. if delete subdomain "beta", all working. But google make link on site with subdomain. I'm think that need take redirect.

You should not be on the beta subdomain. Could you tell me how you got there?

I get the beta subdomain if I enter elementary os beta, so yeah we need to add a robots file there

Definitely relevant issue: #780
I think one of them should definitely be closed.

http://shot.qip.ru/00LtnB-51q1ISSPa/
it's "elementary os freya download"

Maybe that's a result of translation being available for that language on beta but not master, regardless, this is definitely a duplicate of #780.


JSON:API v1.1 New Directions

A couple months ago, @gabesullice and I requested feedback regarding the adoption of v1.1-RC1 of the spec, which was first published in December of 2018. You can read the request and responses in this issue, which also includes my analysis.
According to our own rules, we saw insufficient adoption of RC1 to move forward with finalization of v1.1, and we think we understand why. The main feature introduced in v1.1 (as of RC1) was "profiles", which are based on IETF RFC 6906. By design, profiles are limited in scope and can't be used to extend the spec to include new document elements and processing rules. Many developers seem to have chosen to sit out implementing v1.1 and wait for v1.2 to solve more pressing problems that can only be solved through extensions of the spec. And others have attempted to stretch the limits of profiles beyond their defined scope, since profiles represent the only "official" tool offered to customize the spec. Both scenarios are understandable, but not desirable.
Since then, Gabe and I have had our heads down trying to plot a new course for v1.1, and we're now ready to make a proposal to the community.
The gist of our proposal is that we would like to simplify and descope profiles as they're currently defined in v1.1-RC1 AND simultaneously introduce a complementary means to customize the spec: "extensions". While profiles can only specify meaning for members already reserved for users, extensions can only specify meaning for members reserved for the spec itself. Because any members added by extensions will be namespaced, extensions do not block any future expansion of the spec. Rather, most extensions should be viewed as a way to explore just such a future expansion.
The details of our proposal are discussed below, along with a few other significant changes planned for v1.1.
Simplify Profiles
The first part of our proposal is to scale back the complexity of profiles as they're defined in v1.1-RC1. The following simplifications are either planned or underway:

Change profiles to be purely opt-in by the server to align with RFC 6906. A client may request one or more profiles (via the Accept header), but the server is under no obligation to honor that request in the response. The server can choose which profiles to apply, and should reflect those profiles in the returned Content-Type. The concept of a profile query param will be removed, since it also violated the spirit of RFC 6906. This change has been PR'd.

Remove the ability for profiles to assign meaning to reserved query params such as filter and page. RFC 6906 states that "A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation.". Since these params are intended to provide processing instructions, they are inappropriate for profiles.

Move profile authoring guidelines out of the base spec. We can make recommendations for best practices in a non-normative way.

Remove guarantees about profile registration and publication on jsonapi.org.

Introduce Extensions
Just as profiles can be negotiated via the profile media type parameter, extensions will be negotiable via the ext media type parameter. Unlike profiles, a server will be required to understand and apply every extension requested via Content-Type and Accept headers, or else respond with an error. In this way, clients can be guaranteed that their requests will be processed according to the base spec plus any extensions they've applied.
Extensions are strictly additive to the base spec, and can never impose rules about members already reserved for users. Any members introduced via extensions MUST be namespaced with a : prefix (e.g. local:id). Namespaces can only be used by extensions. Besides the fact that members are namespaced, most extensions could be merged with the base spec.
Extensions will become the means to define custom processing directions for query params such as filter and page.
Sharing Official and Community Extensions and Profiles
Extensions and profiles are both specified by URI, so we (the spec editors) have no means or desire to control which ones are used by the community.
However, we do feel a responsibility to provide a means to share extensions and profiles on the official site (jsonapi.org) just as we share implementations of the spec.
We plan to be cautious in particular about which extensions are seen as "official". We may choose not to support any community extensions at first on jsonapi.org as we wade into this new territory. Essentially, we have to be cautious about making the spec confusing through an endless array of conflicting extensions.
Since profiles are applied purely to "user space", we don't see the need to be so cautious about publishing community profiles.
First Official Extensions
Two of the longest awaited additions to the spec, Local identifiers and Operations, are proposed as the basis for the spec's first "official extensions". Content from the original PRs has been simplified, refactored, and reopened as new PRs that are compatible with the new extension proposal.
The "Atomic Operations" extension (#1437) will use the namespace atomic to emphasize the atomicity guarantee that motivates the need for operations. Operations will be requested via an atomic:operations member, and results returned as atomic:results.
The "Local Identitities" extension (#1436) will use the namespace local. Local identity members (local:id) can be used to identify resources that have not yet been assigned an id by the server. This fills a gap in the base spec in which resources without IDs assigned can't yet reference themselves in relationships. This extension will also be critical to enable resources in different operations to reference each other without IDs.
Note that neither of these extensions will be part of the base spec nor do they need to be versioned along with it. Care will be taken to allow side-by-side evolution. It's possible that one or both of these extensions will land in the base spec eventually (without namespaces of course).
Links Upgrade
The other change that we'd like to support for v1.1 has been PR'd and refined by Gabe for a while: Upgrade links to RFC8288-modelled web links. This PR should help improve hypermedia support by allowing params to be optionally added to links to convey more information about them.
Summary
All aspects of this proposal are either currently in development or already PR'd. We now want to reach out to the community for feedback and support in helping us reboot v1.1 of the spec ASAP. Please let us know your thoughts!

Any members introduced via extensions MUST be namespaced with a : prefix (e.g. local:id).

This seems reasonable to me, but just to clarify:

this means the spec itself is prevented from ever using members with a :, correct?
this doesn't specifically infer where the members with a : are allowed, is it the intention to allow them anywhere (e.g. within all types of top level object types)?

Please let us know your thoughts!

I'm excited!

@rwjblue thanks for reviewing :)

this means the spec itself is prevented from ever using members with a :, correct?

That's correct. The spec will reserve : for namespacing extensions.

this doesn't specifically infer where the members with a : are allowed, is it the intention to allow them anywhere (e.g. within all types of top level object types)? Wouldn't there still need to be some restrictions (to avoid collisions with userland attribute names for example)?

That's correct. Extensions should be viewed as potential additions to the spec itself, so they shouldn't take liberties that the spec couldn't. I feel strongly that extensions shouldn't be able to add members to objects that are reserved for users, just as the spec itself could never add a new member to attributes or meta.

A recommendation on how JSON:API can leverage HTTP/2 features like server push would be hugely beneficial for the community. This can be absorbed in the specification in the near future.
cc: @gabesullice

Thanks for your work on this @dgeb!

Excellent stuff. I really like the turn around regarding profiles, because I felt there were being misused (and probably Dret as well).
In an ideal world, we should opt for a decoupled IETF RFC that covers the functionality of the extensions, in relation to RFC 6838 (Media Types). I had done some research (introspected.rest) around Media Types in the past and I had seen the same issues: it's important to be able to extend the spec with small well-known (or even non-well known, although it should be avoided) reusable modules (=extensions), in a way to compose the needed functionality for our Hypermedia Interface. This has many advantages, one of them being evolvability. But current Web Infrastructure don't really allow us to do that. There is not even a proper way to negotiate those extensions, starting from the client side (unless you do reactive negotiation). And that's a big problem, that here JSON:API needs to solve by itself coming up with some custom solutions which I don't think it's a good for the community (introspected.rest did the same).
To sum up, my point is that I completely like/need/want/support extensions, and I am looking forward to that, I just think we have to push in general for a common extension mechanism in HTTP through IETF, regardless what's going to happen in JSON:API.
Because in the end, some of those extensions could be designed in a more generic way, outside of JSON:API (although that would be orders of magnitude more challenging).

thank you for that large & great effort! as soon as people think the specs are more or less stable I could offer one of the first implementations in the context of crnk.io.

@jugaadi, entirely agreed! I'm excited for experimentation/modernization like you describe.

When does a proposal(spec related changes, extensions, etc) enter FCP(Final Comment Period) and how long does it last?

So one concern I have with opening up an extension point is that there might be some things better suited in the spec itself. I've seen other ecosystem open up an extension point like this and everything gets pushed out into an extension and it becomes the wild-wild-west. Additionally, it's easier to create an implementation when things are fairly strict. To that, is it expected that implementations build support for extensions/profiles or are they to open up extension points themselves for others to build support for JSON:API extensions/profiles??
Also, when can we expect a new 1.1 draft? 😅

@gabesullice and I have been working to simplify profiles for v1.1. Please review #1456 as we'd like to merge this soon.

Also, please review #1457, which introduces extensions for v1.1.
This completes much of the work described in this issue, and should clear the path for a new v1.1 draft soon.

Profiles and extensions look awesome.
They could also help to model and document domain- and company-specific conventions. So beside the shared official and community extensions and profiles there might be internal ones.
Not sure if such internal extensions and profiles would be powerful enough to cover all cases. For example they can't put restrictions on fields. So a convention like "the value of an attribute that end with At must be an ISO 8601 date time string" can not be modeled using them. But they should be able to cover most conventions.

According to the spec, profiles and extensions should be requested by "Accept" or "Content-Type" headers but the server may return a very different output depending on the profile or extension. Do (reverse) proxies treat those headers the same as GET parameters and use them to return the appropriate cached content? I don't think so.
If there's a proxy between client and server, it will return the first cached request regardless of the "Accept" or "Content-Type" headers because it will make its decision purely on the GET parameters. Thus, the requested profiles or extensions must be part of the GET parameters if I'm correct.

One of the most tedious parts of the 1.0 specification is the "included" array being a flat array because you have to loop over all elements to build a map of types and IDs that can be accessed directly when resolving relationships. The original intend was that those included elements are in the correct order but that's irrelevant because the "relationships" in the "data" sections define the order of the related/included items for each data entry.
Now you say:

Extensions are strictly additive to the base spec, and can never impose rules about members already reserved for users.

Thus, it would be only possible to add a new "map:included" element to return a structure like:
"map:included": {
    "<type>": {
        "<id>": {
            "id": "<id>",
            "type": "<type>",
            "attributes": {}
        }
}

If the "included" array from 1.0 spec can't be removed or left empty, this would double the amount of data returned, which is highly undesireable. In my opition, there should be a way to replace or remove existing elements by extensions to solve problem of the 1.x spec until 2.0 fixes the problem.

What about m2m relationships? Are there no plans to support this and if not could someone please explain the rationale behind not supporting this?

One of the most tedious parts of the 1.0 specification is the "included" array being a flat array because you have to loop over all elements to build a map of types and IDs that can be accessed directly when resolving relationships.

@aimeos Could you elaborate on this a little bit. I haven't ever seen it as a limitation in an existing library. Only heard if people try to hack together ad-hoc solutions. Do you have examples for which such a map would be required?

The original intend was that those included elements are in the correct order

Can't follow you here. Do you have a source?

What about m2m relationships? Are there no plans to support this and if not could someone please explain the rationale behind not supporting this?

@geoidesic Many-to-many relationships are supported. Could you link to a more concrete explanation of the limitations you are facing?

@jelhan
I mean specifically when POSTing.
Let's say e.g. I have Enquiries and People as an m2m relationship in my database via a link table. Now I'm creating a new Enquiry on the front-end and in the process, I want to also:
A. Link some existing People to that Enquiry (I understand that this can be done)
B. Create some People and link them to the Enquiry (my understanding is that this cannot be done as part of the same request)
It seems the only way to B currently is as two separate requests – first POST to create the People, then add these ids to the People relationship of the enquiry before posting it.
There are two problems with this:

It doesn't support an offline / synch architecture. In an offline architecture, each of the two requests would be serialised and put in a queue. Because they are serialised static requests, the Enquiry request can't receive the id's of the created People.
Also, having it as two requests prevents one from doing it all as one database transaction, which may be counterproductive in certain instances. E.g. you might not want the Enquiry to be created if there's a validation problem on the related Person.

Maybe I'm approaching the JSONAPI architecture in the wrong way, so please let me know if there's already a pattern for handling this effectively.
The only solution I can think of to these problems within the existing spec is to use client-generated uuids instead of integer primary keys – I'm not wild about the idea because that would represent a big architectural change to the app with all kinds of potential fall-out.

@geoidesic This should be provided by Atomic Operations extension. See #1437 for details.

One of the most tedious parts of the 1.0 specification is the "included" array being a flat array because you have to loop over all elements to build a map of types and IDs that can be accessed directly when resolving relationships.

@aimeos Could you elaborate on this a little bit. I haven't ever seen it as a limitation in an existing library. Only heard if people try to hack together ad-hoc solutions. Do you have examples for which such a map would be required?

The original intend was that those included elements are in the correct order

Can't follow you here. Do you have a source?

@jelhan Consider a typical response like this:
"data": [{
  "id": "37", "type": "product",
  "relationships": {
    "price": {
      "data": [{
        "id": "321", "type": "price"
      }]
    }
  }
}, {
  "id": "48", "type": "product",
  "relationships": {
    "price": {
      "data": [{
        "id": "283", "type": "price"
      }]
    }
  }
}],
"included": [{
  "id": "283", "type": "price", "attributes": {}
}, {
  "id": "321",  "type": "price", "attributes": {}
}]

To get the referenced price items in the included array, you have to loop over the complete array once because you can't directly access the right price item. This would be possible if included would be a nested object with the type and id as keys:
"included": {
  "price": {
    "283": {
      "id": "283", "type": "price", "attributes": {}
    },
    "321": {
      "id": "321",  "type": "price", "attributes": {}
    }
  }
}

Then, you could access the referenced price item directly by
response.data.included["price"]["281"]

Then, you could access the referenced price item directly by response.data.included["price"]["281"]

@aimeos There is no guarantee of this, which is why we didn't pursue this approach in the first place. The base specification requires that only one representation of a resource can be in data and included, and if that resource appears in data, then it must not be duplicated in included. This could happen in your example if resources of type price are both primary and included.
Note that extensions could be used to add new ways to embed, include, and nest resources. However, they should not attempt to redefine existing members in the document structure (like included) nor reserved query params with meaning (like include). So you could create an extension that supports your map:included structure as long as it doesn't attempt to repurpose the already reserved include query param (but it could support map:include).

They could also help to model and document domain- and company-specific conventions. So beside the shared official and community extensions and profiles there might be internal ones.

@jelhan that's definitely something we've had in mind :)

Not sure if such internal extensions and profiles would be powerful enough to cover all cases. For example they can't put restrictions on fields. So a convention like "the value of an attribute that end with At must be an ISO 8601 date time string" can not be modeled using them. But they should be able to cover most conventions.

The v1.1 draft includes support for the describedby field in links. This field can point to a description document (e.g. JSON Schema or OpenAPI) that absolutely can make requirements on field contents. See https://jsonapi.org/format/1.1/#document-links
An example extension might strictly require usage of this field and enforce field validation according to it.

Then, you could access the referenced price item directly by response.data.included["price"]["281"]

@aimeos There is no guarantee of this, which is why we didn't pursue this approach in the first place. The base specification requires that only one representation of a resource can be in data and included, and if that resource appears in data, then it must not be duplicated in included. This could happen in your example if resources of type price are both primary and included.

@dgeb In data but not in included isn't a problem in most cases and doesn't affect if the included section is a flat array or structured as nested objects IMHO. If the resource already is in data, there's some extra code required but nested objects improve lookup speed a lot and avoids code for creating that map after each response. There are no guarantees, so the code must always look like
response.data.included && response.data.included["price"] && response.data.included["price"]["281"]

Note that extensions could be used to add new ways to embed, include, and nest resources. However, they should not attempt to redefine existing members in the document structure (like included) nor reserved query params with meaning (like include). So you could create an extension that supports your map:included structure as long as it doesn't attempt to repurpose the already reserved include query param (but it could support map:include).

Yes, in v1.x it's impossible to change that to keep backwards compatibility. Nevertheless, it would be a great improvement for v2 and GraphQL offers more structured data too which makes it much easier for frontend developers.

Any updates on publishing v1.1?

@dgeb @gabesullice   It would be really helpful if you can give us any update regarding v1.1 status.

@jugaadi We are both independently taking a pass through the v1.1 spec and plan to issue RC2 after making some final (minor) edits.
Now's a good time for others to do the same :)

According to the spec, profiles and extensions should be requested by "Accept" or "Content-Type" headers but the server may return a very different output depending on the profile or extension. Do (reverse) proxies treat those headers the same as GET parameters and use them to return the appropriate cached content? I don't think so.
If there's a proxy between client and server, it will return the first cached request regardless of the "Accept" or "Content-Type" headers because it will make its decision purely on the GET parameters. Thus, the requested profiles or extensions must be part of the GET parameters if I'm correct.

@dgeb What about profiles and proxies?

If there's a proxy between client and server, it will return the first cached request regardless of the "Accept" or "Content-Type" headers because it will make its decision purely on the GET parameters. Thus, the requested profiles or extensions must be part of the GET parameters if I'm correct.

If we could not rely on content type negotiation to work with the Accept header, then clients could not specify that they want the json:api media type (application/vnd.api+json). For that matter, they couldn't request application/json vs. application/xml. Certainly some APIs form their urls with these concerns in mind, but this is definitely beyond the scope of this specification.

For what it's worth, I'm finding it quite difficult to be interested in 1.1 when it remains difficult to get questions about 1.0 answered.  I've tried both the issue tracker and the general forum; while the forum provides responses, they're typically not definitive.
As a result, my own JSON:API support library is pretty solidly stalled, and I see little point in making it public if there's no future for it.

For what it's worth, I'm finding it quite difficult to be interested in 1.1 when it remains difficult to get questions about 1.0 answered. I've tried both the issue tracker and the general forum; while the forum provides responses, they're typically not definitive.
As a result, my own JSON:API support library is pretty solidly stalled, and I see little point in making it public if there's no future for it.

1.1 is more definitive

1.1 is more definitive

Agreed that 1.1 is better with regard to clarity.  But questions I've had regarding 1.0 have generally not been handled better in 1.1 (see #1496, #1502 for examples).
I'm not suggesting that no answers are forthcoming, either; @gabesullice helped work out clarifications for #1499, for example.

As with #1403, I'm closing this now that v1.1 RC3 has been released with all the planned updates discussed here. At this point we're just making fine tweaks and waiting for a couple initial implementations to be finished.


The tree always fully expands. The global toggle (levels={1}) and local for a node (state*.expanded*) has no effect

hi Akorp, did you find a solution to this? thanks.

No, had to use another library, which is a shame, cos this one would be much easier to use (https://github.com/chenglou/react-treeview)


How to you install Rpstart since the author forgot to include the details in his release

How to you install Rpstart since the author forgot to include the details in his release

It is covered here in the documentation https://github.com/dmcoles/AmiExpress/wiki/Host-Addresses

i'm not even sure this is needed to be honest. it was in the original documentation but I don't have anything called RPStart in my user-startup. Just RexxMast


Missing Documentation

Describe the bug
Referenced documentation appears to be missing.
To Reproduce
Steps to reproduce the behavior:

Go to https://github.com/dahall/taskscheduler#sample-code
Note this paragraph: "There is a help file included with the download that provides an overview of the various classes. There are numerous examples under the 'Documentation' tab."
Clone the repository
Note that the referenced help file isn't found in the cloned repository
Note that there is a file index.html in the docs subfolder, but that help collection doesn't include a Documentation tab as described.

Expected behavior
I expected to find the referenced help file.
Screenshots
N/A
Environment (please complete the following information):
N/A
Additional context
N/A

Download: https://github.com/dahall/TaskScheduler/releases
Online: https://dahall.github.io/TaskScheduler/html/R_Project_TaskScheduler.htm

@dahall Got it, thank you.


Add troubleshooting for "argument list too long"

It is possible for Kubelet to inject so many environment variables that executables cannot run.
We had a customer run into this problem and troubleshooting it was difficult due to the error message which mentions nothing about environment variables. This PR adds a troubleshooting solution with the real error message so that anyone else searching for the error will hopefully find this page.

@Porges : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Hi @ktoliver, what is the next step here?

The issue that's addressed in the PR appears to be addressed in master. We'll close the PR. If there are outstanding issues or questions, please add a comment or create a new pull request. Thanks.

The issue that's addressed in the PR appears to be addressed in master. We'll close the PR. If there are outstanding issues or questions, please add a comment or create a new pull request. Thanks.

Odd, it looks like my changes were somehow copied in without the PR being merged? Very strange!


Add GUI app for face recognition in videos

Add GUI app for face recognition in videos

Performing face recognition in videos based on photos given
Adding a GUI to this application

Fixes: #1118
Proposed Changes

I have used FaceNet from OpenCV and SVM Classifier from Sci-Kit learn to build this.
FaceNet is used to calculate the 128-d embeddings of each face
SVM is used to train on those embeddings
Streamlit is used to make a GUI

Screenshots

@akshitagupta15june I have moved the folder with my implementation to Face-X-GUI-applications. Please do check and let me know if any other changes are needed


Don't Clear Input Strings on Rerender

The strings in the load input and the email input disappear when rerendering or opening the results page.  This will keep them around (at least in some cases, still trying to figure out exactly when we want them and when we don't).

What this does:

Saves submitted input and email strings.  Switching to another step and then returning will still show the submitted value filled in the input.

What this doesn't do:

Will NOT save unsubmitted text in either input.  Type in a random string without submitting, switch to another step and return, and the string will be reset to either empty string or the last submitted value.
Will NOT populate the results page with values entered pre-run.  On the results page, the inputs will be empty.

I'm concerned about the results page and how it relates to the setup page.  @avirshup I think you and I should talk through how they relate and all the edge cases.  I could do fancier stuff with saving the input values in this PR, but it starts to be weird behavior or possibly irrelevant work on the results page.

After talking with @avirshup, in order to solve the problems that things like this are building up on the results page, I will disable the ability to edit and run on the results page for now.  That's coming soon in this PR.

Todo:

[ ] Populate Load input on results page
[ ] Show a download button at the bottom of Load

@avirshup I want to check with you one more time before I merge.  I've disabled the ability to run on the results page, populated the inputs on the results page, and displayed a download button on the "load" step.  The new download button looks like this:

I also changed the results step download button to say "Download Result" to clarify that the two download buttons aren't downloading the same thing.


Direct way to set dimming level

Hello,
I was wondering if you managed to dig a bit deeper into this and figure out how exactly MyASUS / Asus Optimization Service sets this brightness level ?
Most of ASUS hardware settings go via Asus ACPI commands. And I strongly suspect this one is also set via another endpoint.
I'm working on an app for controlling asus laptops, so you can check how other settings are done here
https://github.com/seerge/g-helper/blob/main/app/AsusACPI.cs
Main problem, I don't have an OLED device by myself :) so I can't debug much for it

Hello! Unfortunately, I didn't go deeper than the RPC call to AsusOptimization.exe and some security checks inside of it I think, so I have no idea what it does internally. If you'd like, I could check some things on my OLED laptop, I guess?


make document for api end point

please make document for api end point usage with a simple tool like curl

Hey is this project complete... as I can't find the code for user endpoint.

Hi @DhawalAgrawal
I implemented this project in an event; I didn't catch a time add users endpoint because it wasn't the goal. User endpoints support the only authentication actions. I will update the topic if I added the users/ endpoint. Otherwise, feel free to send a PR.
Thanks.


Reorganize cinder-csi and manila-csi tests to tests/ dir

What this PR does / why we need it:
This PR moves all the tests under /tests dir
Which issue this PR fixes(if applicable):
fixes #
Special notes for reviewers:

Release note:

NONE

/test cloud-provider-openstack-acceptance-test-keystone-authentication-authorization

/test cloud-provider-openstack-acceptance-test-keystone-authentication-authorization

/assign @lingxiankong

/lgtm
/approve


26 Releasing

What's left? A bunch of features not yet implemented, and an official release announcement.
Before we get to that point, we want to get pseudo into useable state: a user who installs a package and runs pseudo should at least have it working as expected.
This chapter is all about getting to that point.
A build script
To help us out with tedious repetitive tasks, I upgraded the test script to a build script: [35ad0136da01bd94ece8e6da6f43f520b8fec657]
https://github.com/nyjc-computing/pseudo-9608/blob/9ef71ebc9631207072efaf48adfc1f7527beb0c4/build#L34-L79
This is written in a scripting language, bash, and not Python. I won't be explaining this part in detail since it's not the focus here.

Usage help
Every commandline program provides some kind of help. Running python -h displays the following:
python -h
usage: /home/runner/pseudo-9608/venv/bin/python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-b     : issue warnings about str(bytes_instance), str(bytearray_instance)
         and comparing bytes/bytearray with str. (-bb: issue errors)
-B     : don't write .pyc files on import; also PYTHONDONTWRITEBYTECODE=x
-c cmd : program passed in as string (terminates option list)
-d     : debug output from parser; also PYTHONDEBUG=x
-E     : ignore PYTHON* environment variables (such as PYTHONPATH)
-h     : print this help message and exit (also --help)
-i     : inspect interactively after running script; forces a prompt even
         if stdin does not appear to be a terminal; also PYTHONINSPECT=x
[... more lines truncated]

pseudo is not so advanced, but nonetheless should still display some kind of help for new users.

Let's start by adding the message content: [dfdd2bec946c03f93a89d939479e295a2ee5b644]
https://github.com/nyjc-computing/pseudo-9608/blob/dfdd2bec946c03f93a89d939479e295a2ee5b644/pseudocode/__init__.py#L26-L31
We can print(HELP) when we want to display this help message.
Next, handling the -h flag.

And then handling the -h flag: [96daf1164684571c015ae643d10cabacb901263d]
https://github.com/nyjc-computing/pseudo-9608/blob/96daf1164684571c015ae643d10cabacb901263d/pseudocode/__init__.py#L129-L131

Testing
Testing the use of the main script is different from testing python code. Instead of running the code, or running unittests or mypy, we have to run this in the shell. The easiest way I found to do this is to build the package and then install it, with poetry:
$ poetry build
[...]
$ poetry install
[...]

This makes the pseudo script available for running:
$ pseudo
No argument provided.
Try `pseudo -h' for more information.
$ pseudo -h
usage: pseudo [option] ... file
Options and arguments:
-h     : print this help message and exit (also --help)
file   : program read from script file

Looks like it worked great!

Unrecognized options
Okay, what about unrecognized options? These are arguments that start with - but which we don't handle ... yet: [bab627bb6aa8a59238a6a3e72b99a86e32d3135f]
https://github.com/nyjc-computing/pseudo-9608/blob/bab627bb6aa8a59238a6a3e72b99a86e32d3135f/pseudocode/__init__.py#L130-L133
$ pseudo -v
Unknown option: -v
Try `pseudo -h' for more information.

Invalid file
What if a filename is provided, but can't be read for some reason?
First let's check that it exists:
https://github.com/nyjc-computing/pseudo-9608/blob/770bde0b257580010686e6927a169ac1a0f5e0d3/pseudocode/__init__.py#L137-L139
The easiest way to ensure it can be read is to ... try to read it:
https://github.com/nyjc-computing/pseudo-9608/blob/ef94cebd80717d3102fb1d7c876b2cc440f4cf7d/pseudocode/__init__.py#L140-L146
Some Python is leaking through, since we don't catch specific types of errors and print custom messages for them. We just dump Python's error message. This will do for now; pseudo-ish error messages are a feature for the future.

We now have something closer to what a user would expect for a commandline program; let's bump the version to 0.4.0! [9079ed76bb3abd9838725dfe61570c4f1791a35c]
And fix a bug in the build script that wasn't substituting the version correctly: [70ff246ca1fdd58ebcaef58ba4724b73bf1ec8b5]


clayCredentials.json documentation for github users

Thinking it would be useful to provide some documentation for users who want to use clay-cli but authenticate through Git. The login process asks for a password, but I don't have one. I dug around and discovered the structure of clayCredentials.json, created my own auth token, and that works; doubtless someone else will want to find this.

Thanks for the note! That's definitely an issue and we'll be fixing that so you can login with the cli even if you authenticated through git. Glad you worked around this and we'll be fixing it right away.


Log an otherwise ignored error from joining a net ns

As the title says - make sure we actually print the error occurring

/approve

LGTM

/lgtm

LGTM

bot, retest this please

/retest images

bot, retest this please

@baude Mind slapping another /lgtm on here?


Cuda shared memory support for Custom Backends

Does CUDA/system shared memory work with the custom backend? I haven't come across examples or tests for models using the custom backend with CUDA or system shared memory in the repository.

Yes, all backends are supported for shared memory. Some backends cannot accept input/output in CUDA memory and for those Triton needs to transfer the data.


WIP: Test this on python 3.9

I'm having a segfault in https://github.com/conda-forge/staged-recipes/pull/13710 and wanted to test if flaky is the culprit

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe:

License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

This has outlived its usefulness


Prefer ThreadLocalScopeManager when working with Maven

Impact

[x] Bug fix (non-breaking change which fixes expected existing functionality)
[x] Enhancement/New feature (adds functionality without impacting existing logic)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Switch from SingletonScopeManager to ThreadLocalScopeManager when used within Maven
Things to be aware of

In a maven context, where large projects are built in parallel, during the generate-sources phase Liquibase often got confused about threads. By switching to a theadsafe implementation this is prevented

Things to worry about

Couldn't directly deduce from the docs whether there is any downside of switching towards ThreadLocalScopeManager, especially since it's now also done if -T1 is supplied.

Additional Context
Closes https://github.com/liquibase/liquibase/issues/4031

@piotrwielgolaski-tomtom in your PoC which has this change plus your ChangeHistoryService refactoring, are you still seeing threading problems in maven? Or does the combination of the two work?

I'm moving this ticket along to the larger code review and testing phase. The suggested change makes sense here, but the question will be if there is more to make and if it actually works as expected.

@piotrwielgolaski-tomtom in your PoC which has this change plus your ChangeHistoryService refactoring, are you still seeing threading problems in maven? Or does the combination of the two work?

In my initial testing it works for offline DB scenario

Test Harness Execution Here: https://github.com/liquibase/liquibase-test-harness/actions/workflows/main.yml
Functional Tests Here: https://github.com/liquibase/liquibase-pro-tests/actions/runs/4927887463

@XDelphiGrl I still see this error using latest plugin version and mvn opts -T2
Error:  Failed to execute goal org.liquibase:liquibase-maven-plugin:4.23.0:update (liquibase) on project ordering-db-schema: Cannot end scope ztupxdjtqp when currently at scope root

@trico-tillster we are still working on some more code contributions from @piotrwielgolaski-tomtom and once they are merged this may be solved.

Hi @filipelautert, just want to know if currently at scope root issue is resolved or not.
Also if not, do we have a workaround for it as it may create problems in our production as we are using liquibase for schemas migration

Hello @caminaman741 - are you able to try it again with 4.24.0 ?


Bugfix/663 Password recovery

The bug was fixed. Token is being received.
Also Regex was fixed.

Checklist

[ ] 🔽 My branch is up-to-date with "development" branch
[ ] ✅All tests passed locally
[ ] ✨My changes working with up-to-date admin and back-end part locally, like charm
[ ] 🔗 Link pull request to issue

Resolve code smell, please


Fix #1971

This PR helps fix #1971 by allowing the user to override the relabeling configurations. Default values are blank to ensure backward compatibility

/reopen

/ok-to-test sha=bc8b6a8


Fix editor assembly definition

Fix Editor assembly definition settings to include in editor only.

Create branch from main
issue-7-fix-editor-assembly-definition


Fix RM machinelearning TypeScript readme

Latest improvements:
MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

The Node.js generation fails with this error message: https://travis-ci.org/Azure/azure-rest-api-specs/jobs/452541844#L594.
@kpajdzik Please figure out why no input files are being provided to AutoRest.


moved to multiset

Adopted code and all tests

remaining issues: should BNode remain a Functor?
brittle tests: order of parallel is an implementation detail, yet it is used in some tests.

The change seems to have performance issues....
Timing out more often than normal ;-(

Performance penalty too high


Build failure on ARM

Compiling for the Raspberry Pi, I get

error[E0308]: mismatched types
   --> /root/.cargo/registry/src/github.com-1285ae84e5963aae/minifb-0.18.0/src/os/posix/x11.rs:423:52
    |
423 |                     (d.lib.XInternAtom)(d.display, "_MOTIF_WM_HINTS\0" as *const _ as *const i8, 0);
    |                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `u8`, found `i8`
    |
    = note: expected raw pointer `*const u8`
               found raw pointer `*const i8`

error: aborting due to previous error

Probably best to use c_char?

Also, shouldn't that be a byte literal b"_MOTIF_WM_HINTS\0"?

Ok, I see this has been fixed already in master.  New release please? :)

Yeah, I can do a new release today

0.19 has now been released :)

Great, thanks!

np!


Exercise 6 Request the token fails with no such host

https://github.com/SAP-samples/cloud-btp-cli-api-codejam/blob/main/exercises/06-core-services-api-creds/README.md
When requesting the token with ./generate-password-grant-type cis-central-sk.json, it fails in the Business Application Studio. However it is successful from the Docker container.
BAS:

Docker:

Error Message in BAS:
Username (email address<EMAIL_ADDRESS>Password for<EMAIL_ADDRESS>dial tcp: lookup null on <IP_ADDRESS>:53: no such host

The latest BAS now has cf version 8 installed by default. Astonishingly, the JSON output produced, for the same request, between cf version 7 and version 8, has a different structure:
Version 7 (cf version 7.5.0+0ad1d63.2022-06-04):
{
  "endpoints": {
    "accounts_service_url": "https://accounts-service.cfapps.eu10.hana.ondemand.com",
    "cloud_automation_url": "https://cp-formations.cfapps.eu10.hana.ondemand.com"
  },
  "grant_type": "user_token",
  "sap.cloud.service": "com.sap.core.commercial.service.central",
  "uaa": {
    "apiurl": "https://api.authentication.eu10.hana.ondemand.com",
    "clientid": "sb-ut-9d5c5eb7-486e-4575-8acb-0bbc944c6311-clone!b169670|cis-central!b14",
    "url": "https://65137137trial-ga.authentication.eu10.hana.ondemand.com"
  }
}

Version 8 (cf8 version 8.5.0+73aa161.2022-09-12):
{
  "credentials": {
    "endpoints": {
      "accounts_service_url": "https://accounts-service.cfapps.eu10.hana.ondemand.com",
      "cloud_automation_url": "https://cp-formations.cfapps.eu10.hana.ondemand.com"
    },
    "grant_type": "user_token",
    "sap.cloud.service": "com.sap.core.commercial.service.central",
    "uaa": {
      "apiurl": "https://api.authentication.eu10.hana.ondemand.com",
      "clientid": "sb-ut-9d5c5eb7-486e-4575-8acb-0bbc944c6311-clone!b169670|cis-central!b14",
      "url": "https://65137137trial-ga.authentication.eu10.hana.ondemand.com"
    }
  }
}

In other words, version 8 of cf wraps the output JSON (specifically the endpoints and uaa properties) inside a new outermost property credentials).
Last time I ran this CodeJam the version of cf in BAS was 7. But I wouldn't have expected JSON output to change so significantly between cf versions!
I'll address this shortly. Thanks for catching!


Add Tanzu TV to RSS feeds

@jacksoncvm I think this should do the trick. Adds all Tanzu TV episodes along with blogs at the home RSS and also adds all episodes to https://deploy-preview-414--tanzu-dev-portal.netlify.app/developer/tv/index.xml, or you can go by show like: https://deploy-preview-414--tanzu-dev-portal.netlify.app/developer/tv/code/index.xml or https://deploy-preview-414--tanzu-dev-portal.netlify.app/developer/tv/tanzu-tuesdays/index.xml


Add test for #26 and scopes

With #43, issues like #26 are fixed. Also added tests to ensure that the code transformer respects function scopes.

Great!
The tests report a formatting issue. Can you fix it with deno fmt?

Thanks!


ADDED example comment to toml file on init #343

This is in reference to #343
To test

Create a blank project using $ dep init ensuring no dependencies are detected within the code. I.e a blank directory.
Check Gopkg.toml for some example text, commented out.

I signed it!

I'm having trouble with some of the tests (I'm a new contributor, sorry!).

@EwanValentine I love me some doc in the morning! ❤
https://travis-ci.org/golang/dep/jobs/221713388#L186 is a panic in a test I wrote, I'll take a look and see what's the matter there.
The remaining tests are failing because the generated file contains your help text, which the tests weren't expecting. The tests have "golden" files in the testdata directories that we compare against. The test runner can update those files for you with the -update flag, so that you don't have to fix them by hand:
go test . ./cmd/dep -update

After you run that, you should see a couple testdata files modified with the new helptext.

@carolynvs Thanks for your feedback, great shout! I've made those changes and updated the test data, still seems to be a panic regarding a missing lock file. Apologies, still getting to grips with the codebase!

Hey! Sorry I've been away this weekend, will pick this up again tonight :)

I've made those suggested changes and tested locally, similar story with failing builds though!

@EwanValentine ah yeah, we changed the name of the Manifest.Ignores field to Manifest.Ignored, for consistency with Required. If you rebase and refactor a bit, tests should start passing 😄

🎉

Awesome! One of my first ever open-source contributions! Thanks for all your help and patience! <3

Ah, sorry it took so long for me to come review and click the merge button! Thanks! 🎉


[Feature request] json configuration output for config endpoint

Hi,
it would be cool to add an option to the /config endpoint. This way it would be possible to query the endpoint and generate a listing of the current domain to service mappings. This could be used for monitoring software like Kibana for example.
Regards
Joke

Sorry for not responding to this issue earlier.
I'm currently in the process of moving everything from configuration files to in-memory structures. Once that is done, it'll be trivial to output configs as JSON.

type parameter was added to the config endpoint some time ago and I forgot to update this issue. After a very long delay, the feature is now available. Please see http://proxy.dockerflow.com/usage/#config for more info.


Use hammer.js as for hanlde touch events

Hammer.js is a library that provides you a consistent way to handle touch gestures across all devices, including desktop.
Also, you may find useful a react-wrapper for it: https://github.com/JedWatson/react-hammerjs
That issue was created as follow up to the comment in another issue

@just-boris I'm not sure to understand the underlying issue. What do you want to achieve in the end?

Exactly the same as @giladbr said:

is there any chance this component would be adjusted to support "swiping" with the mouse on desktop?

Hammer.js will emit consistent events for you, so you don't need to worry about differences in platforms. Mouse drags on desktop will be converted into touch events as well. Also, I believe that issues like #164 will also be fixed, but it needs more precise check

Interesting, my only concern with this approach is regarding the build size and introducing a large dependency.

I think I agree with this — the benefit of using a standardized library like hammer I think outweighs the weight of the library. (Hammer is pretty well-vetted, too — so no possibility of it disappearing or changing API dramatically!)
Right now I'm trying to find workarounds to get this library to work with mouse-events. Having native hammer support would be awesome.

@wub Thanks for you point of view. I'm closing it for #254.

Try react-slick. Very powerful, a lot of options, has swiping and many other abilities. Documentation a little lacking which may lead to integration problems, but we used it successful and boosted our site's user experience.


odgi stats: metrics for graph sorting goodness evaluation in 2D

mean_links_length

-G
path
in_2D_space
num_links_considered

1
all_paths
3324.91
81960

10
all_paths
3044.36
81960

100
all_paths
2946.87
81960

1000
all_paths
2867.06
81960

sum_of_path_node_distances

-G
path
in_2D_space_by_nodes
in_2D_space_by_nucleotides
nodes
nucleotides

1
all_paths
3324.43
1667.58
81972
163416

10
all_paths
3043.92
1526.87	81972
163416

100
all_paths
2946.44
1477.98	81972
163416

1000
all_paths
2866.64
1437.95
81972
163416


Gerowallet not working[BUG]

Describe :
Whenever i click on connect button it redirect me on install extension page of gero wallet.
This is the code im running .
<ConnectWalletButton
alwaysVisibleWallets={["gerowallet", "typhon", "flint", "nufi"]}
/>

Can you please test if the error will go away if you add gerowallet to the "supportedWallets" prop ?
<ConnectWalletButton supportedWallets={[["gerowallet", "typhon", "flint", "nufi"]]} alwaysVisibleWallets={["gerowallet"]} />

No it still not working . redirect me on a Gerowallet extension page

Ok I figured it out: gerowallet does not inject it's api to the window.cardano object on localhost nor on unsecure sites (invalid cert). If you deploy your site to production gerowallet will be shown up. You can test this by going to any https site, open the devtools and check "window.cardano.gerowallet" .. on localhost this will be undefined. I will close this issue here and suggest you to contact the gerowallet developers (maybe there is a dev/test mode).

yes its working now thank you so much.
Just for Public
Run your react app by this command   set HTTPS=true&&npm start  and Gerowallet will work


Very good framework

Suggest submitting to the official
Attract more people
https://github.com/ocornut/imgui/wiki/Bindings#python

Thanks, good idea. Will definitely do when I have pre-built binary packages.


Pull request - improved thumb tracking

First of all, thanks for contributing OBSlider to GitHub. It was exactly the solution that I was looking for to address some user feedback on my app.
I made two small improvements to the code:

39cab459 - This change more precisely positions the thumb when the user drags their finger back towards the slider through the different scrubbing "zones".
4c85ba31 - This change keeps the thumb in the highlighted visual state no matter how far the user's finger is from the slider, and smooths the movement of the thumb as the user moves their finger closer to the slider. Note that it does require that an image resource be include in the app. I've updated the demo app appropriately.

Let me know if you have any questions or comments.
Thanks,
Brad

I ended up merging the first commit 39cab45 but not the second 4c85ba3. While I think it's obviously a good idea to always highlight the thumb, I did not want to introduce a dependency on external images to the project. In that case, the class would not be a drop-in replacement for UISlider anymore. Thanks for your work, Brad!


refactor(NODE-5912): make server.command an async function

Description
What is changing?

Server.command is now written with explicit async/await syntax
Removed Server.commandAsync	and replaced all references
Removed ConnectionPool.withConnection, ConnectionPool.withReauthentiation
Refactored ConnectionPool.reauthenticate to use explicit async/await syntax and exported it for internal use in Server.command
Refactored ConnectionPool.checkOut to use async/await syntax with the support of promiseWithResolvers helper function
Removed callback property from WaitQueueMember and replaced it with explicit reject and resolve properties for more ergonomic use with promiseWithResolvers in ConnectionPool.checkOut

What is the motivation for this change?
NODE-5912, NODE-5913

Double check the following

[x] Ran npm run check:lint script
[x] Self-review completed using the steps outlined here
[x] PR title follows the correct format: type(NODE-xxxx)[!]: description

Example: feat(NODE-1234)!: rewriting everything in coffeescript

[x] Changes are covered by tests
[x] New TODOs have a related JIRA ticket

Currently only consistently failing these two tests across load-balanced variants. It seems strange to me that we'd fail operation count tests, but not connection pinning tests.

A couple of housekeeping questions:

Does this PR also cover NODE-5913? If so to not forget to close that ticket as well and maybe mention its number in the current PR.
Double-check the list in the PR description to see if it meets all expectations.

CI fails because the AWS Secrets Secrets Manager is not implemented yet NODE-5507 and Serverless credentials are rotated (should be fixed soon).


CButton SSR error (CoreUI PRO for Next)

I use CoreUI PRO for Next with ready template but I get errors when I try to use SSR. I've noticed so far CFormInput and CButton give errors.
For Instance:

Save

"Error: Event handlers cannot be passed to Client Component props.
<button className=... onClick={function onClick} disabled=... type=... children=...>
^^^^^^^^^^^^^^^^^^
If you need interactivity, consider converting part of this to a Client Component." error message is that.

You need to use "use client" directive at the top of the files including these components.
Because they are contains client side events.