Question: Scharr derivatives in AKAZE

Hi Pablo,
I'm working on performance improvements of OpenCV version of your code. Thanks a lot your code, it is nicely readable. I have a few questions however:

Why does the Scharr needs to be computed twice? First here for computing diffusivity and then for computing Hessian determinant here. First is standard 3x3 Scharr, the second is using sigma-sized kernels. Would it be possible to compute it just once (either using sigma-sized or 3x3 kernel)?

Would it be possible to use only standard 3x3 Scharr for computing Hessian Determinant? There is a huge possible speedup.

Before processing the image is converted to floats. Could some parts use just bytes, without affecting accuracy too much?

Have a nice day.
Cheers,
Jiri

Hi Jiri,
Why does the Scharr needs to be computed twice? First here for computing diffusivity and then for computing Hessian determinant here. First is standard 3x3 Scharr, the second is using sigma-sized kernels. Would it be possible to compute it just once (either using sigma-sized or 3x3 kernel)?
The first computation is to get a regularized version of the gradient so we can compute the diffusivity function. The rest of computations are to compute the multiscale derivatives with increasing size with respect to scale. Perhaps here you can approximate some of the kernels with the first Scharr filter.
Would it be possible to use only standard 3x3 Scharr for computing Hessian Determinant? There is a huge possible speedup.
As I mentioned above perhaps it is possible. I think the correct way to do it is the way I did, but if performance does not suffer you may get big speed ups by using just the standard 3x3 Scharr kernel.
Before processing the image is converted to floats. Could some parts use just bytes, without affecting accuracy too much?
I believe some pre-processing functions can be done with unsigned char or int. I have not explored much these options.
Regards,
Pablo

Thanks a lot for your insights.
I just quickly tried to used 3x3 Scharr for computing multiscale derivatives, but that does not play very well with finding scale space extrema, which runs much longer and probably is broken.
I'll keep you updated, if I achive anything interesting.
Have a nice weekend.

ups, I kinda forget a bit about this issue. Thanks much for the feedback, AKAZE in OpenCV is now 2.2x - 3.77x faster. Reworking finding of scale space extremas with more efficient approach helped a lot when there is a lot of features detected.
https://github.com/opencv/opencv/pull/9444


How to delete Data when Diagnostics is disabled?

I disabled diagnostics after using the storage account some days already. Later I noticed that all the metric data recorded during that time is not deleted, even though it already passed the retention time.
As I am not able to access these tables via PowerShell, C# or Azure CLI, what is the way to delete all the data, or even better delete the entire tables? Azure Storage Explorer shows an "permission not sufficient" error when trying to delete the tables, and deleting the data on row level is too much manual work for me.
Thanks,
Stefan

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

ID: 5b725b36-8d87-7e36-5d0d-a08f906c237c
Version Independent ID: 424e6b29-68d1-ee75-cf07-49211d2882d4
Content: Azure Storage analytics metrics (Classic)
Content Source: articles/storage/common/storage-analytics-metrics.md
Service: storage
Sub-service: common
GitHub Login: @normesta
Microsoft Alias: normesta

@InstanceFactory Thanks for the question. We are looking into this and will get back to you shortly.

@InstanceFactory Apologies for delay in responding here!
Can you share the screenshot? I'd recommend posting your question in https://social.msdn.microsoft.com/forums/azure/en-US/home?forum=windowsazuredata since it's not directly related to the documentation. We'll follow up there. We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Assets being proxied only first time and than being replaced by original version

[x] I tried updating to the latest version.

[x] I can't, there is an issue.

[ ] I Am on Windows
[ ] I Am on Bash on Windows
[ ] I Am on Linux
[x] I Am on OS X

Description

Steps

Add asset tag with any of the processing settings. For example,

{% asset src magick:resize=500x500^ magick:gravity=center magick:crop=500x500+0x0 %}

Generate your site - asset processed through proxies and everything looks fine
Stop jekyll server and run it again
All assets which should be processed being replaced with their original versions

Output
# Doing stuff.
# Doing more stuff.
# Oh no error.

Expected
Assets being processed only first time and than reused from the cache. But instead of proxies assets true value is being putted to the cache. And processing is preformed inside cache block, with prevents from executing is every time.
Any advice?

What version of Jekyll-Assets?

I've tried 3.0.1 and 3.0.2. I think it is because true is being returned from the cache.fetch block.
Right now, I've disabled caching at all and assets do not regenerated between jekyll restarts.

What do you mean by "assets do not regenerated between jekyll restarts"?

With sprockets caching enabled:

Clean site directory
Start jekyll server
Look to the logs for the assets being processed. It is expected.
Restart jekyll server and check logs for assets being processed. I'd expect that since nothing changed in the site sources all assets generation should be either skipped or fetched from the cache. But assets being replaced with versions without proxies being applied (f.e. cropped images being replaced with full size versions)

With sprockets caching disabled:

Clean site directory
Start jekyll server
Look to the logs for the assets being processed. It is expected.
After server restart all assets being skipped since they already copied to the _site directory. It is expected as well.

Can reproduce

This issue is being automatically locked to prevent noise.

Example 2 is expected behavior.  Behavior #1 (where it doesn't log) is us, we don't log our proxies that deeply, and we should, but aside from that, I'm pretty sure the problem is that we don't guard copying assets when a proxy starts, we only guard running the proxy if an asset has been cached, we need to move up everything and guard it inside of the entire cache, and then just return what we need.

@envygeeks Thank you for updating. When we could expect fix?

That I don't know, our donations are nil right now which is forcing me to look for work and put OpenSource on the back burner, I'm sure it'll be taken care of soon regardless of whether people donate but when is questionable.

@envygeeks Got it. Anyway, thank you for investigating this.


ase: update QUARTUS_HOME environment variable to QUARTUS_ROOTDIR

Resolves OFS/opae-sdk#2952

Why not just replace all instances of QUARTUS_HOME with QUARTUS_ROOTDIR and call it a day?
Is there a need for the new override?

This is done based on Mike's comment here, he found that the Quartus doc specifies users to set QUARTUS_ROOTDIR_OVERRIDE when they "have multiple copies of the Intel® Quartus® Prime software on the same computer and want to determine which version to open by default".


Warning does not indicate the cproject.yml file that is processed

When a csolution.yml includes multiple cproject.yml files (or even clayer.yml files), the following warning does not indicate in which cproject.yml or clayer.yml a component with dependencies was identified.
C:\Test\Test-C0>csolution convert -s MyName.csolution.yml
warning csolution: dependency validation for context 'MyName.Debug+MyTargetName' failed:
SELECTABLE<EMAIL_ADDRESS>  require CMSIS:CORE
  require Device:STM32Cube Framework

My recommendation, replace the text SELECTABLE with 'component: ` and add file name that contains the component, i.e.
C:/Test/Test-C0/MyName.cproject.yml - warning csolution: dependency validation for context 'MyName.Debug+MyTargetName' failed:
component<EMAIL_ADDRESS>  requires component: CMSIS:CORE
  requires component: Device:STM32Cube Framework

A similar problem applies to the list dependencies command where also the *.yml file that defines the component would be useful. For example:
C:\Test\Test-C0>csolution list dependencies -s MyName.csolution.yml
C:/Test/Test-C0/MyName.cproject.yml - component<EMAIL_ADDRESS>requires component: CMSIS:CORE
C:/Test/Test-C0/MyName.cproject.yml - component<EMAIL_ADDRESS>requires component: Device:STM32Cube Framework

Actually the word SELECTABLE brings information in itself that would be lost with a simple replacement by component:.
I would recommend to elaborate it better according to the meaning of each condition result:
https://github.com/Open-CMSIS-Pack/devtools/blob/main/libs/rtemodel/src/RteItem.cpp#L34-L49

Project file is written to output

Project file is now present - it is therefore a duplicate of #1187 1187


cc1352r1_launchxl: configure jtag reset for openocd.cfg

The cc1352r requires
reset_config trst_only
Fixes #18852.

@cfriedt I was unable to reproduce the issue. In fact, it fails for me with "Invalid ACK (0) in DAP response" once I made the change to openocd.cfg, and now my board always fails even if I revert to the original openocd.cfg. I see from your bug report that openocd is invoked from /usr/local/bin/openocd. Could you verify that you are indeed using openocd from the Zephyr SDK 0.10.3? I am wondering if you aren't using the older TI OpenOCD. Make sure your PATH is pointing to zephyr-sdk-0.10.3/sysroots/x86_64-pokysdk-linux/usr/bin where openocd is located. And you may wish to try using a new board if you happen to have another one lying around, just in case it got into the same state mine did.

I do not have this issue with the openocd version in the Zephyr SDK. I believe @cfriedt is using upstream openocd. As I recall, upstream openocd did not work correctly when I added support for these boards. I used the TI openocd and the Zephyr SDK and it worked so I did not look further into it. I am having a hard time identifying the actual changes we have in our version of openocd.

@vanti @bwitherspoon - I didn't realize that zephyr bundled OpenOCD. I wonder what the exact differences are in the bundled version vs upstream. Is there some effort to get the changes upstreamed?
Thanks for the heads-up though. I'll see if that helps with my other issue was well, which I now believe is due to the lack of SRST.

@vanti @bwitherspoon - I didn't realize that zephyr bundled OpenOCD. I wonder what the exact differences are in the bundled version vs upstream. Is there some effort to get the changes upstreamed?
Thanks for the heads-up though. I'll see if that helps with my other issue was well, which I now believe is due to the lack of SRST.

The Zephyr SDK openocd version pulls in some changes from TI:
https://github.com/zephyrproject-rtos/openocd/commits/zephyr-20190226
https://github.com/zephyrproject-rtos/openocd/commit/3333261df1edf48571d6415e4383d7c78753eeed
https://github.com/zephyrproject-rtos/openocd/commit/697677c416da65bc3458ec1aefe70992b1e9ef82

@galak
TI has committed to pushing their changes upstream, so I wonder why there are issues still...
http://www.ti.com/tool/SIMPLELINK-OPENOCD

@galak @vanti @bwitherspoon - Is there a stable branch for zephyrproject-rtos/openocd ?
I just ran west flash from zephyrproject-rtos/openocd branch zephyr-20190226 and there are definitely still issues with it. Below is the output (I removed my changes to boards/arm/cc1352r1_launchxl/support/openocd.cfg).
 0* cc13x2.cpu         cortex_m   little cc13x2.cpu         running
Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
Info : JTAG tap: cc13x2.cpu enabled
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Could not find MEM-AP to control the core
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x1000118e msp: 0x11001ff0
auto erase enabled
wrote 360448 bytes from file /home/cfriedt/workspace/zephyrproject/zephyr/build/zephyr/zephyr.hex in 4.382249s (80.324 KiB/s)
Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
Info : JTAG tap: cc13x2.cpu enabled
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Could not find MEM-AP to control the core
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x1000118e msp: 0x11001ff0
verified 360448 bytes in 2.901136s (121.332 KiB/s)
Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
Info : JTAG tap: cc13x2.cpu enabled
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Could not find MEM-AP to control the core
shutdown command invoked
Info : XDS110: disconnected

@galak
TI has committed to pushing their changes upstream, so I wonder why there are issues still...
http://www.ti.com/tool/SIMPLELINK-OPENOCD

@cfriedt It's possible @galak might know more, but my understanding is that OpenOCD upstream is pulling changes in at a slow rate. Changes like the ones @galak highlighted don't seem to have made it on the upstream's master branch yet.

TI's openocd seems to work. Still getting a user fault though. Tried increasing stack sizes. Usually 2048 bytes is fairly sufficient..

@galak @vanti @bwitherspoon - Is there a stable branch for zephyrproject-rtos/openocd ?
I just ran west flash from zephyrproject-rtos/openocd branch zephyr-20190226 and there are definitely still issues with it. Below is the output (I removed my changes).
 0* cc13x2.cpu         cortex_m   little cc13x2.cpu         running
Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
Info : JTAG tap: cc13x2.cpu enabled
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Could not find MEM-AP to control the core
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x1000118e msp: 0x11001ff0
auto erase enabled
wrote 360448 bytes from file /home/cfriedt/workspace/zephyrproject/zephyr/build/zephyr/zephyr.hex in 4.382249s (80.324 KiB/s)
Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
Info : JTAG tap: cc13x2.cpu enabled
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Could not find MEM-AP to control the core
target halted due to debug-request, current mode: Thread
xPSR: 0x61000000 pc: 0x1000118e msp: 0x11001ff0
verified 360448 bytes in 2.901136s (121.332 KiB/s)
Info : JTAG tap: cc13x2.jrc tap/device found: 0x3bb4102f (mfg: 0x017 (Texas Instruments), part: 0xbb41, ver: 0x3)
Info : JTAG tap: cc13x2.cpu enabled
Error: Debug regions are unpowered, an unexpected reset might have happened
Error: JTAG-DP STICKY ERROR
Error: Could not find MEM-AP to control the core
shutdown command invoked
Info : XDS110: disconnected

Trying to debug this, lands me in a usage fault, just as before.

This is something we have seen as well. As far as we can tell, the code runs fine afterwards despite the messages.
If you do not start a debug session and just run the flashed code (e.g. by hitting the reset button), does the code run correctly?

@galak @vanti @bwitherspoon - Is there a stable branch for zephyrproject-rtos/openocd ?
This is something we have seen as well. As far as we can tell, the code runs fine afterwards despite the messages.

If you do not start a debug session and just run the flashed code (e.g. by hitting the reset button), does the code run correctly without usage fault?

Yes, it runs fine afterward - but I'm going to need JTAG functional for step-debugging through BLE code. I can't imagine that printf-debugging BLE code would be very pleasant.
@galak @bwitherspoon  do you have the cc1352r1_launchxl as well? Revision E silicon? If you're able to step debug through code, what exactly are your openocd versions / sources?
I will give the Zephyr 0.10.3 SDK a shot.

Yeah, unfortunately, even with the openocd in the zephyr-0.10.3 SDK release, I'm still unable to step debug using the XDS110 on the CC1352R1 LaunchPad.

Yeah, unfortunately, even with the openocd in the zephyr-0.10.3 SDK release, I'm still unable to step debug using the XDS110 on the CC1352R1 LaunchPad.

Is there an OpenOCD version that you are able to do this with?

Maybe I'm just being optimistic, but if I use #CONFIG_BOOT_BANNER is not set, I get to main() ... let's see if a custom application works as well.

Yeah, unfortunately, even with the openocd in the zephyr-0.10.3 SDK release, I'm still unable to step debug using the XDS110 on the CC1352R1 LaunchPad.

Is there an OpenOCD version that you are able to do this with?

Any of the versions are working better using a J-Link ;-)

Nope - I was just being optimistic. There always seems to be a usagefault triggered due to the systick.
__usage_fault() at fault_s.S:106 0x142a
<signal handler called>() at 0xfffffff9
z_new_thread() at thread.c:148 0x13e6
elapsed() at cortex_m_systick.c:83 0xe70

xPSR is also invalid (T bit is unset), which would probably explain the usagefault.
Uses PSP 0x0 return.
xPSR            0x1000000
ReturnAddress   0x13e6
LR (R14)        0xffffffff
R12             0x0
R3              0x1429
R2              0x14dd
R1              0x0
R0              0x0
Return instruction:
   0x13e6 <z_new_thread+126>:	str	r2, [r3, #8]
No line number information available for address 0x20000d28 <_main_stack+920>

I macroed-out the contents of z_init_static_threads() and used a string rather than pointer-based comparison in z_impl_device_get_binding() and now I'm able to get into the main thread again.

@cfriedt I played with this a bit today using OpenOCD from Zephyr SDK 0.10.3. I found that if I run
-> west debug
followed by these commands in gdb
-> load
-> c

hello_world (with NO_OPTIMIZATIONS=y) runs correctly with no usage_fault.
Whereas if I set a breakpoint on the main symbol
-> load
-> b main
-> c

This causes a usage_fault with the behavior you saw. Meanwhile, I noticed this message in gdb:

(gdb) b main
Breakpoint 1 at 0x3c: main. (2 locations)

But my main function is located at 0x460, not 0x3c.
Now if I set the breakpoint to the actual location of main:
-> load
-> b *0x460
-> c

This works fine. Do you see the same behavior? gdb for some reason seems confused about the location of main().

@vanti - I can confirm that if I set a breakpoint with b main I get the usage fault as well.

Thanks for the confirmation @cfriedt. I still think it is strange gdb is confused. It probably scribbled memory at the wrong place when setting the breakpoint via "b main". Does this unblock you with regards to debugging at least?

@vanti - yes! Thanks very much for your help. I'm good to debug now. Should I close the ticket?

Sorry for the delay - busy busy!

@vanti - yes! Thanks very much for your help. I'm good to debug now. Should I close the ticket?

yes please close if your issue is resolved, or this change isn't needed.


[Refactor] Search API Request & Response

What is frustrating you?
Clients of Search API cannot determine directly whether the returned link is matched for Short (or) Long link. Also, clients do not have control over the type of links searched for a particular request.
Your solution
Accept a match-type parameter (Short/Long/All) in the request and return the matched links in the response as separate arrays (ShortLinkMatches / LongLinkMatches).
Additional context
Explored as part of #866

I thought this is by design so that the backend can change the algorithm at any time😲

I'm not sure I understand what you are saying. Do you think type filter shouldn't be exposed?

@hemachandarv I see what you mean. I think it is exposed. Is it not?

@byliuyang I could see there is a param for the resource type. I don't see one for the match type (do we match the keywords in the short-links (or) the long-links?). Currently the app does both and ranks them accordingly.
I'm thinking this depends on the use-cases for which the Search is exposed. Do you think we should let the client provide the type of links to match the keywords on?

My main concern is that each attribute has unique way to be ranked. If we exposed, how are we going to expose ranking logic? Or we can abstract out search layer into a library for additional use cases? Could you please draw some UMLs or explain sample exact use cases? I can't just imagine the use cases themselves without knowing what they are. Thanks!

The ranking param & code are in pair.

I completely agree that each attribute has unique way to be ranked. For now, I see we allow link search only, based on the provided keywords. From what I see in the code, I could think of an use-case where a client wants to get links for the keywords that are matched only in short-link. However, the application returns matches from the long-links as well. This could become an issue if there are no matches in the short-links for the given keywords.
I do not know the current use-cases supported by Search. Would love to know them.

@hemachandarv That's how we made it now.  I think it good for now. We are explaining to make it a generic search engine moving forwards.

@hemachandarv I recommend paste the proposed UML or API definition here so that we can look it up together.

@hemachandarv How about this. Let's expose the API to allow the client to decide what fields we want to be sorted on. If nothing is specified, by default, we sort on both fields.


Startup error

What went wrong:
Could not determine the dependencies of task ':delightfulstudio_react-native-wheel-picker-android:compileDebugAidl'.

Could not resolve all task dependencies for configuration ':delightfulstudio_react-native-wheel-picker-android:debugCompileClasspath'.
Could not resolve cn.aigestudio.wheelpicker:WheelPicker:1.1.2.
Required by:
project :delightfulstudio_react-native-wheel-picker-android
Could not resolve cn.aigestudio.wheelpicker:WheelPicker:1.1.2.
Could not get resource 'https://www.jitpack.io/cn/aigestudio/wheelpicker/WheelPicker/1.1.2/WheelPicker-1.1.2.pom'.
Could not GET 'https://www.jitpack.io/cn/aigestudio/wheelpicker/WheelPicker/1.1.2/WheelPicker-1.1.2.pom'. Received status code 401 from server: Unauthorized

Same is happening here any luck with this?

Same is happening here any luck with this?


adding US data/reports

@moiradillon2 There's a conflict with the pull. I'll resolve and merge. Please, hold any other pulls for now. Thanks!

@moiradillon2 You're good to go!


DirEntries throws in foreach

jason reported this on 2014-03-17T07:52:24Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=12391
CC List

andre.artus
christof
ckatko
dlang (@Vild)
mike
timothee.cour2

Description
Using DMD Version 2.065, Windows 7 x86

A previous similar issue has been fixed on Linux.
http://d.puremagic.com/issues/show_bug.cgi?id=8298

To reproduce this try iterating over c:\windows it will yield an access denied exception. Alternatively create some directory in a sub directory and remove your access to it.

The error I got was: std.file.FileException@std\file.d(2519): c:/windows\CSC\v2.0.6: Access is denied

b2.temp commented on 2016-03-23T01:51:59Z
*** Issue 12513 has been marked as a duplicate of this issue. ***

jason commented on 2016-03-23T18:23:20Z
Could we not take something out of python's book (or some other language):

os.walk https://docs.python.org/2/library/os.html

(1) This [os.walk] gives an opportunity to have an error handler during the walk.
(2) alternatively a parameter that accepts a range that becomes a list of errors.
(3) something else...

#2 doesn't seem that flexible looking at it, #1 would seem to be the way, as it acts as a predicate in python too, if an exception is thrown from the error handler the walk is stopped, otherwise it is not.

Often times I would like to ignore errors but log them. Other times better to stop the traversal.

andre.artus commented on 2018-10-31T03:39:41Z
I would really like to see either a complementary function, or a parameter, or any other solution to this problem. At the moment I have to maintain a parallel implementation of dirEntries. While I'm sure it exists for someone, I don't have a use case favouring the current behaviour.

Most of my utilities where using dirEntries would be useful scan the full filesystem. I cannot even exclude these directories by name as the crash happens before I get the result.

auto dFiles = dirEntries(path,"*.{d,di}",SpanMode.depth);
foreach (d; dFiles) {
// nothing happening here
}

std.file.FileException@std\file.d(4573): [Folder]: Access is denied.

jason commented on 2014-03-17T07:55:30Z
example code:
    import std.file;
    foreach (DirEntry e; dirEntries("c:/windows", SpanMode.depth))
    {
        writeln("entry: ", e.name);
    }

timothee.cour2 commented on 2016-01-11T04:08:15Z
ping on this.

I made local modifications to my git repo as this error was a blocker:

auto h = directory.length ? opendir(directory.tempCString()) : opendir(".");

                if(!h) {
                    auto s = strerror(errno).to!string;
                    import std.stdio;
                    stderr.writeln("ERROR: ", __FILE__,":",__LINE__," ",directory , " ",s);
                    return false;
                }

mike commented on 2014-03-18T15:42:18Z
dirIterator throws an exception when it tries to traverse into a directory for which it does not have any read permissions.

This issue also exists on Linux/posix systems.

b2.temp commented on 2016-03-23T02:03:41Z
It seems to be by design. By hand it's possible to catch silently (e.g the /srv/tftpboot folder on linux).

void scan(string root)
{
    foreach(DirEntry entry; dirEntries(root, SpanMode.shallow))
    {
        try
        {
            writeln(entry.name);
            if (entry.isDir) scan(entry.name);
        }
        catch (FileException fe) {continue;}
    }
}

void main()
{
    scan("/srv/");
}�

The error happens in "bool stepIn(string directory)�" (std.file) because the folders are only put on a stack if they have a valid handle.

What could be done is to put them on the stack, always, and to test later, when the stack is used if the handle of each item is valid, but then the control is lost over when and why a problem happens. The iterator could even return a DirEntry with a special flag (hasNoHandle) to denote that an error occured.

dlang-bot commented on 2023-01-05T09:00:43Z
dlang/phobos pull request #8656 "Document dirEntries throws without read permission" was merged into master:

- 3aa94941b3a963d84f910bd31b2dd16e0b19665a by Nick Treleaven:
  Document dirEntries throws without read permission

  Part of:
  Issue 12391 - dirEntries throws in foreach

  Add example showing how to handle subdirectory read permission failures.

https://github.com/dlang/phobos/pull/8656

jason commented on 2022-12-28T18:57:53Z
I see that some documentation has been added to this, which is helpful. I do think however that SpanMode.depth is somewhat unhelpful to have, given that there is no possibility of handling errors and continuing; some people may miss the fact that it behaves in the way it does.

It may be better to remove the depth mode altogether if the API isn't going to be adjusted in any way, but equally I don't see why this API does not follow that of countless other languages that have solved the same problem as I previously mentioned. Here is rust's effort if the python one was unsound in some way. https://rust-lang-nursery.github.io/rust-cookbook/file/dir.html#recursively-find-duplicate-file-names

dlang-bot commented on 2022-12-27T11:09:59Z
@ntrel updated dlang/phobos pull request #8656 "Document dirEntries throws without read permission" mentioning this issue:

- Document dirEntries throws without read permission

  Part of:
  Issue 12391 - dirEntries throws in foreach

  Add example showing how to handle subdirectory read permission failures.

https://github.com/dlang/phobos/pull/8656

ckatko commented on 2022-12-23T15:55:31Z
This issue from 2014 is still not resolved?

The function as-is, is completely broken (and nearly useless) if it cannot handle a simple permissions issue. That means every single program using this function is subject to breaking if a file/folder with inaccessible permissions is placed in a desired search directory. Even if you catch exceptions overall, it's still going to terminate the loop from searching, breaking whatever file listing the program depended on.

And even if that was acceptable, it's still not documented that this happens.

This definitely needs addressed as it's a fundamental building block of D's standard library. You are basically expected to use this for any enumerated file access.

dlang-bot commented on 2023-01-13T22:27:11Z
@dukc updated dlang/phobos pull request #8657 "Fixed many issues in grapheme walker" mentioning this issue:

- Document dirEntries throws without read permission

  Part of:
  Issue 12391 - dirEntries throws in foreach

  Add example showing how to handle subdirectory read permission failures.

https://github.com/dlang/phobos/pull/8657


Add dev.amp.snowplow/amp_page_ping/jsonschema/1-0-0 (closes #1026)

Adds schema for AMP tracker to send page pings independently of the JS tracker's page pings (since data is defined differently)

Closing in favor of https://github.com/snowplow/iglu-central/pull/1029


Reuse TcpStream in case handshake fails

I currently have these types at hand:
reader: BufReader<Take<ReadHalf>>
writer: BufWriter<WriteHalf>
During the session, the connection can switch to using TLS and I'd like to switch the types to:
reader: BufReader<Take<ReadHalf<TlsStream>>>
writer: BufWriter<WriteHalf<TlsStream>>
But in case the handshake fails, I'd like to continue as before.
I tried many things in order to get back the original TcpStream (but there's no reuinite() on ReadHalf and WriteHalf yet).
Also I did not manage to have something working by borrowing the TcpStream in the first place.
I must be missing something as I'm rather new to Rust programming.
Thanks for your help, and thanks for your work !

With async-std, you can put TlsStream in an Arc wrapper, and then freely clone it around to pass it into async-tls:
Wrapper Code

#[derive(Clone)]
struct Stream(Arc<TcpStream>);

impl Read for Stream {
    fn poll_read(
        self: Pin<&mut Self>,
        cx: &mut Context,
        buf: &mut [u8],
    ) -> Poll<io::Result<usize>> {
        Pin::new(&mut &*self.0).poll_read(cx, buf)
    }
}

impl Write for Stream {
    fn poll_write(self: Pin<&mut Self>, cx: &mut Context, buf: &[u8]) -> Poll<io::Result<usize>> {
        Pin::new(&mut &*self.0).poll_write(cx, buf)
    }

    fn poll_flush(self: Pin<&mut Self>, cx: &mut Context) -> Poll<io::Result<()>> {
        Pin::new(&mut &*self.0).poll_flush(cx)
    }

    fn poll_close(self: Pin<&mut Self>, cx: &mut Context) -> Poll<io::Result<()>> {
        Pin::new(&mut &*self.0).poll_close(cx)
    }
}

Usage
let stream = Arc::new(stream);
tls::connect(stream.clone());

// can still use tcp stream after this

This means you're able to reuse the connection even if connecting fails the first time. We're currently tracking making TcpStream implement Clone in https://github.com/async-rs/async-std/issues/553, allowing us to get rid of the wrapper above entirely.
Hope this is helpful!

That certainly did help ! Thanks Yoshua.


Update UserGuide.md and Add image for list friend and game

Changes:

Update UserGuide.md
Add png images for list friend and game

Issues:

Resolves #13

Codecov Report

Merging #29 (f791548) into master (8963916) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #29   +/-   ##
=========================================
  Coverage     72.15%   72.15%
  Complexity      399      399
=========================================
  Files            70       70
  Lines          1232     1232
  Branches        125      125
=========================================
  Hits            889      889
  Misses          311      311
  Partials         32       32

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 8963916...f791548. Read the comment docs.


SEO multi Language perspective

From a SEO perspective the ideal solution for multi language/multi region url should be using sub-folders.
I'm starting to think about it but I kind of lost! I would like that the route:
http://isomorphic500.herokuapp.com/featured/fresh_yesterday
will be linked to
http://isomorphic500.herokuapp.com/it/featured/ieri for example
From the Html Document point of view it easy to change the title and the description meta tag to take an international message.
For achieving multi language routes it seams a bit tricky to me.
This is becoming a huge problem for me in production, since google is seeing my english website...

I try to be more clear on what I would like to achieve:
the route: "/folderEN/pageEN
should be replicated in different languages like
IT: "it/folderIT/pageIT"
but that's not all..

The meta data for the page should be created in many languages. This is fine since the RouteStore can give the route handler name, and so one can pick the international message.
The pages in other languages have to be linked to the main page using the meta tags for that:

Why this should bother us?
https://moz.com/blog/subdomains-vs-subfolders-rel-canonical-vs-301-how-to-structure-links-optimally-for-seo-whiteboard-friday
I hope that someone can give me a hint...

Ok,
as explained here: https://github.com/yahoo/fluxible-router/issues/50
in fluxible-router one should simply put:
{
    page: {
        method: 'GET',
        path: '/:lang([a-z]{2})?/page1',
        handler: require('../components/Page.jsx'),
        action: require('../actions/loadPage')
    }
}

and then the loadPage action should set the default lang for the page,
but how to link the corresponding pages in other languages.
I guess it should be done also in the loadPage action..

Ehy @maiopirata, for a better path matching use something like this:
const locales = ["en", "it"];
page = {
   path: `/:lang(${locales.join("|")})` // match only /en or /it, otherwise 404
}

If you want to localize the url, it really depends from what you want to do. For example, this path:
let path =  `/:lang(${locales.join("|")})/featured/:feature`

will match any "feature" string coming after /featured/. If you want to catch /it/featured/ieri, then your params will be { lang: "it", feature: "ieri" }. In the page action, do something for matching "ieri" with the actual feature the server wants (i.e. "fresh_yesterday") and you are done.

thank @gpbl!
I think it is ok. I will use a wrapper component that use the page action to match the route.
I could also use the same logic to obtain the links of the same page in the other languages!


reinstate RepresentationsFunctionalTest

This reinstates the RepresentationsFunctionalTest, which was ignored in
20e1597a7a7e9d97b.
I achieved this by removing the FunctionalTestBase superclass and
using a separate DropwizardAppRule which sets the register value to
register.
Furthermore, now that we have the /load-rsf endpoint, we can load data
in as RSF rather than using the grubby DBSupport class to write directly
into the database tables.

👍  merge! :rage4:


[BUG] Generator CMakeLists.txt assumes build artifacts already exist

Describe the bug
Try initializing the cmake build system on a new clone of the repository.
To Reproduce
Try initializing the cmake build system on a new clone of the repository.
cmake -DAVA_GEN_CUDART_SPEC=On -DAVA_MANAGER_LEGACY=On ../ava
# note out of source tree build

Expected behavior
Cmake completes successfully.
Error log
CMake Error at cava/CMakeLists.txt:39 (add_subdirectory):
  add_subdirectory given source "cudart_nw" which is not an existing
  directory.

You need to run generate.py first. It needs a better error message to inform the user.

Can this be automated as part of running cmake?
On Wed, Jun 2, 2021, 10:05 AM Zhiting Zhu @.***> wrote:

You need to run generate.py first. It needs a better error message to
inform the user.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/utcs-scea/ava/issues/144#issuecomment-853056796, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQTX2SPCPXUBP5OQLZLKE3TQY3A7ANCNFSM456WRA4A
.

It could be. https://cmake.org/cmake/help/latest/command/execute_process.html But it will make the configure time longer.

That seems ok. Better to keep the build process as simple as possible.


Implement Autokey cipher

Very similar to the Vigenere cipher, but uses a different method of generating the key.

See PR #19


Upgrade Papyrus version

Issue and tracking information
Developer's time Estimated effort to fix (hours):
Developer's Actual time spent on fix (hours)
Issue reporter to provide a detailed description of the issue in the space below
Ideally, upgrade to the latest version of Papyrus, but I'll leave that up to you to evaluate. I'd say at least 6.x. The version CX currently delivers is 4.8.0 (2020-06). There are two newer major releases 5.x and 6.x available on their home-page.

A quick status report.
I have been finally able to make a target platform based on the Papyrus 6.5 (2023-06) SDK, and after updating a lot of dependencies on manifest files, I am able to compile all (except for Papyrus Compare) within Eclipse. I have not yet tested it.
Next steps (not necessarily in order, as dependency management may require updates):

Try to build it with Maven.
Adjust the RCP product as needed by the new dependencies.
Test.
Include and adjust Papyrus Compare.

An update.
I got it building with Maven, including the Papyrus patch, but without Papyrus Compare, and updated the RCP product, although I might need to streamline the list of dependencies in the RCP product, as it seems to be getting too large, but that's a secondary concern at the moment.
I'm going to be testing now.

Some important info:
After building, I discovered that the RCP still contains two versions of log4j 1.2, in addition to log4j 2:
org.apache.log4j_1.2.15.v201012070815.jar
org.apache.log4j_1.2.24.v20221221-2012.jar
org.apache.logging.log4j_2.17.1.v20220106-2156.jar

Version 1.2.15 could possibly be explained by one of our existing plugins still having that dependency, but I didn't understand the presence of the 1.2.24 version, until I looked at a plain Papyrus install, and it turns out that plain Papyrus is the one that includes it, in addition to 2.17.1.
So there doesn't seem to be a clean way to simply get rid of log4j 1.x by upgrading (or otherwise)
I will investigate to see if perhaps I can find which plugins are dependent on 1.2.x, and hopefully I can patch them. The problem is that it may be a third party dependency, like EMF Compare, or worse, Xtext. This is very, very difficult because these, as well as Papyrus itself, have a very large code base.

And more info about this.
I have tried to install several variants of Eclipse to see which ones come with versions of log4j, and in particular I tried the following ones which are all relevant as they all include features that are included in Papyrus CX. They are all based on the latest release, which is 2023-06:
Eclipse RCP................................... Includes log4j ........ log4j versions
-----------------------------------------------------------------------------------
Eclipse Platform (minimal Eclipse install).... No
Eclipse for C/C++ Developers.................. No
Eclipse for Java Developers................... No
Eclipse for Java and DSL Developers........... Yes .................... 1.2.24
Eclipse Modeling Tools........................ Yes .................... 1.2.24
Papyrus....................................... Yes .................... 1.2.24, 2.17.1

So clearly version 1.2.24 comes from components in both the DSL package and/or the modelling package and Papyrus includes a great deal of both of these. These share a lot in common. My guess is that Xtext is the main culprit. I have been following details of Xtext development and they have been in trouble for at least two years with a lack of developers, so upgrades there are very unlikely. This is a big problem, because Xtext is huge, with an extremely complex code base.
I'll try to confirm which features and plugins exactly require 1.2.24.

My fears proved to be correct. Xtext (the latest version) depends on org.apache.log4j 1.2.24. And it's not just a few plugins that could be easily patched. It is all over the place: all 4 features including the "top-level" features and 71 plugins!!!
Removing this dependency will be very, very, very difficult, and you should take into account that we are not familiar with its code-base.
I will try to see how many of those plugins are actually included in Papyrus, in case its a smaller number that I can patch.
But either way, this is going to take a lot longer that we may have thought.
Xtext has an open issue on migrating to log4j2 but the discussion there is that they do not have the capacity to do so. There are some suggestions on what to do in that discussion, but I don't know if they would completely remove the 1.2.x versions. I'm reading on them. The discussion is found in this link.

An update:
I am working on trying to patch Xtext to use the latest version of log4j 2.
Plain Papyrus has 18 Xtext plugins. Unfortunately, there is no feature in plain Papyrus that includes these plugins explicitly. They are brought in during the build because they are listed as dependencies in some of Papyrus plugins MANIFEST.MF files. Now, this is a problem (that there is no explicit Papyrus feature with them) because it means there is no feature to patch. In an Eclipse product, if you want to patch a plugin, you can only do it by patching a feature that contains the plugin. Now, in Papyrus CX, we actually do include four Xtext features, so we can patch those. The problem is that it requires patching 36 plugins rather than 18. So it's double the work.
The good news is that I have been able to patch one Xtext plugin. 35 to go. Having done one, the others should, in theory, be easier, and a bit faster, but it's still quite a lot. And then after that, I will likely need to patch several other features, likely OCL, Xtend, Xpand, EMF Compare and maybe others. So it will take time.

I was thinking exactly that, to push my updates to the official Xtext repo. However, the full Xtext includes something like ~70 plugins, so patching all would still be a bit of a tall order. Furthermore, I'm doing the updates based on the latest release, (used by Papyrus) which is 2.31.0, but they are working on 2.32, so it might be a bit of a catch up game. Of course, I could try to update all their plugins if you wish me to do so, but that would take time away from dealing with CX issues directly, and I will still need to patch other things like OCL, Xtend, etc. It's up to you to set the priorities. But I might still do a pull request in their GitHub repo, so that at least others can continue.

Yes, I agree with you completely. We can push up the changes in an attempt to contribute but let's not put any extraneous effort into getting our changes accepted by their product.

An update:
I have patched almost the entire Xtext Runtime feature, 9 out of 10 plugins. I'm working on the 10th, which is the trickiest, as it deals directly with Log4j' extension mechanism, which changed a lot from Log4j 1 to Log4j 2. After that one, I think the remaining 26  Xtext plugins (in 3 features) will be a lot easier.

Glad to hear you are making good progress. Thank you for the update.

A status update:

I've migrated a total of 21 Xtext plugins from Log4j 1 to Log4j 2; this includes all the plugins in the main Xtext features included, but not the Xtext features included in the Xtend features
I've migrated 3 Xtext plugins from Apache Commons Logging (JCL) to SLF4J
I've migrated 5 CX plugins from Apache Commons Logging (JCL) to SLF4J

The last two need a bit of an explanation. Many plugins, both ours and our dependencies use "Apache Commons Logging" (previously known as Jakarta Commons Logging or JCL), which is provided by the org.apache.commons.logging plugin, provided by the Orbit repository, and unfortunately, this plugin depends on Log4j 1.2.x. SLF4J is a Java facade for several logging services, and it is easy to migrate from JCL to it, and it doesn't depend on Log4j 1.2.x. In fact, we could also migrate all Log4j to SLF4J instead, but at least for now, I'm trying to do whatever causes the least possible disruption.

Another update.
I've run into a big hurdle that has complicated the process of patching. Normally the dependency on log4j is declared in plugins, and those are the once I'm patching. But features can also declare hard requirements, and there are several features, including the core Xtext feature that declares log4j 1.2 as a hard requirement. These hard requirements are installed when the feature is installed. This is a problem, because the typical way to patch Eclipse products is to define a "Feature Patch" that specifies which feature is being patched and the plugins with the updates. But they way this works is that when Eclipse installs the feature patch, it first checks that the original feature is installed, and if not, it installs it, and then installs the patch, replacing the old versions of the patched plugins with the new ones included in the feature patch. But since it installs the original feature first, it also installs its required features and plugins, which in our case is the old Log4j 1. So this means that we cannot use the usual feature patching mechanism. Instead what I am trying is to copy the original feature entirely, removing the hard requirement to Log4j 1, and include this updated feature instead. It has been very difficult to build the product this way, but it looks like I have been able to build one with the new versions of the features.
Nevertheless, there are still many other features and plugins that have the log4j 1 dependency, including, critically, Xtend. This is critical because Xtend is the language in which the code generators are written. So as a next step, I'm going to try to remove the dependency in Xtend. After that, other dependencies such as MWE and MWE2 (the "Modeling Workflow Engine") also depend on it, and both Xtend and Xtext depend on MWE(2).

Thank you for this update. It looks like you have a path forward, even if it is difficult. I wish we could say that we didn't need this improvement, but we recently received security scans that flags all instances of log4j1 as critical/severe.
Now that you have brought up Xtend, I remembered you stating in a different post that the version of Xtend that we use is partially the reason for the generator slowness and that there is a newer version that is "faster". Does this newer version have log4j2 or log4j1 dependencies? I do not want to increase the scope of this ticket to also upgrade Xtend unless it completely removed the log4j1 dependency

A status report:
I have now patched almost all of the Xtext plugins and features (I think I'm missing one), and all of the Xtend2 feature and plugins.
Next, finish any pending Xtext plugins, and patch the old Xtend 1 features and plugins.

Status report:
I've finished patching all Xtext, Xtend 1 and Xtend 2 features and plugins that used Log4j1 or JCL (which uses Log4j1).
Next in the list: Xpand.

An update.
Xpand was very small and simple and I've patched it.
I encountered a difficulty with part of "ECF" (the Eclipse Communications Framework).
One of the core Eclipse features "org.eclipse.equinox.p2.core" requires a features called "org.eclipse.ecf.filetransfer.httpclient5", which itself requires JCL (org.apache.commons.logging), which requires org.apache.log4j, i.e. Log4j 1.
This means that the requirement is at the very heart of Eclipse itself.
It looks like I was able to patch org.eclipse.ecf.filetransfer.httpclient5 as I have with other features. But being required by a core feature makes me a bit nervous. Fingers crossed, it will work.
Next, I've found that "Ant" (a Java Building tool) is required by many plugins, and it itself depends on Log4j1. I'm trying to patch that now, although that is a standalone plugin, without a feature to contain it, so I'm not sure how that will work. Hopefully it will.

I ran into difficulties building Ant, because itself is built in a very different way and has dependencies which I haven't been able to find.
I'm going to leave that on hold for a while and move onto a different component and circle back to it later.

Is Ant itself installed with papyrus? Or just used to build other tools?
Either way, it is depressing to see that Eclipse and its foundational software isn't being maintained as much as we would have hoped. Log4j1 has been EOL since 2015.

Unfortunately Ant is installed with Papyrus. I'm not really sure why, but it is required by a lot of plugins, including some required directly by CX, like org.eclipse.emf.mwe.core.
I agree about the state of Eclipse and Papyrus updates. The only thing I can say about this is that it looks like the many projects that comprise Eclipse, such as Xtext and many, many more, do not have the capacity to make the updates, and, as the previous links I've provided suggest, the actual Log4shell vulnerability, which is the most famous, affected a version of Log4j 2 rather than Log4j 1, although Log4j 1 has its own vulnerabilities. So perhaps because of this, it has not been seen as a bigger priority by the different teams working on Eclipse projects. Also, some of these projects are not even Eclipse projects, like Ant.
I also think that when projects get too big, like many Eclipse projects, it becomes harder to upgrade dependencies as time passes. A component depends on another component, and then someone builds another to depend on it, and so on, so old dependencies linger for a long, long time. And since in this case the problem dependency was a logging library, it was considered low priority. But I think this sort of problem of legacy components lingering for a very long time, is not exclusive to Eclipse or Papyrus, but to software in general. As software becomes larger and more complex, it becomes more difficult to upgrade the older parts.
Anyway, today I'm working, not on OCL as I said, but on "Nebula", another set of plugins required by Papyrus. I decided to work on this one first, because it is smaller, just four plugins.

I've pushed my current progress to a PR #480 so that we have the code in the repo. Obviously it is far from ready, but it's better to have it in GitHub than just in my development machine.
You may even give it a try to see if you find unexpected behaviours. I imagine there will be some issues.
As for progress, I've finished with the Nebula/Nattable component. I'm looking to decide which one to update next.

A status update:
I decided to look into the dependencies in Papyrus itself before other components like OCL or MWE.
There are 29 Papyrus plugins with a dependency on log4j1, and one feature that lists it as a hard requirement.
I decided to start replacing the feature (org.papyrus.infra.gmfdiag.feature) by removing its hard dependency. But as I've mentioned before, this cannot be done by a "Feature Patch", but instead providing a copy of the original feature with the hard requirement removed. This then creates a problem, because during the build, maven tries to resolve feature's requirements, but if you have modified a feature, you get it with a new version number so when the build is trying to establish the requirements of other features that include the modified one, it fails to find it. More concretely, we modified the org.eclipse.papyrus.infra.gmfdiag feature (version 3.0.100.qualifier), so we get it with a new version (3.0.101.qualifier), and then, during the build, maven finds feature org.eclipse.papyrus.infra (version 3.2.100.qualifier) which requires org.eclipse.papyrus.infra.gmfdiag 3.0.100, so it doesn't find it. This means we have to create a new version of org.eclipse.papyrus.infra (3.2.101.qualifier) that contains the new one. But then this fails because the top feature org.eclipse.papyrus.sdk (6.5.0) expects org.eclipse.papyrus.infra (3.2.100.qualifier), so we have to modify that one again. But then this results in a new problem, with the build complaining that it cannot resolve a plugin from one of the feature patches.
So this suggests that the only way forward is to ditch entirely "feature patches" and only provide explicit new versions of features that we need to modify. I think this will be possible, and it may actually simplify the build since we now have to build feature patches separately because of Tycho limitations.
Hopefully this approach will work.

Thank you for the update. The issue with the feature patches makes sense. A change this large was bound to cause more and more issues the more we unraveled it, so the fact that we can't hack this altogether with patches isn't surprising.

An update:
I've upgraded the Papyrus feature that required log4j 1 as well as the other 4 features that depended on it.
I've also upgraded 6 of the 29 Papyrus plugins that depended on log4j1.

I've upgraded today 19 more Papyrus plugins, for a total of 25 out of 29.

All Papyrus features and plugins directly using log4j have been patched. Next on the list are MWE2 and OCL. MWE2 is smaller, so I'll start with that one.

I'm done with MWE2. I'll start with OCL. That's another big one. Looks like it's 26 plugins and at least 2 features.

A quick update.
As I mentioned in my previous message, I started patching OCL. Unfortunately I am currently stuck unable to build it.
There seems to be a major issue with building OCL related to its widespread use of some Eclipse Java annotations, specifically @NotNull and @Nullable. The compiler throws a lot of errors. I am trying to figure out how OCL is built in isolation. But the problem seems big and long-standing. There are some Eclipse Bugs about it such as Bug 526011 and Bug 564014. I am going through these bugs and trying to see if there are any workarounds.

I've made some progress. I was able to build (most of) OCL in isolation, in particular the version that we need. Now I have to figure out how to integrate that build into ours.

Some good news. I was stuck unable to build a single OCL plugin within our build, but I was finally able to do it. There are about 25 more OCL plugins, but having done the first one means that the others will proceed more quickly. I'm guessing it will take me two more days.

And to add to the previous comment, I've finished 6 out of the 26 OCL plugins today.

For OCL, I have finished 10 plugins and 16 more to go. After OCL there are not too many, but at least one (Ant) is tricky.
The remaining ones are:
org.apache.ant
org.apache.httpcomponents.httpclient
org.apache.xmlgraphics
org.eclipse.mwe.core
org.eclipse.mwe.utils
org.freemarker
So 6 more, but as I said, Ant is tricky. I tried it earlier but it has a dependency on what appears to be a proprietary plugin from IBM which I can't find anywhere. Unfortunately, a ton of plugins require Ant, including plugins from Papyrus, EMF, UML, Xtend, MWE, and even Eclipse itself.
I'm guessing the other Apache plugins and Freemaker are going to be tricky too, as they are not provided by Eclipse projects, where the build is generally easier to reproduce and the dependencies are generally easier to track.

A status update:
I finished MWE without problems. Now I moved to org.apache.xmlgraphics, but ran into an unexpected issue. Patching the plugin itself was easy, but it turns our that a core feature called "GMF runtime third party dependencies" has a hard dependency on the version of org.apache.xmlgraphics, which meant I had to patch that feature. But patching that one then causes a build problem because another feature "GMF core" depends on that one, so that has to be patched too, but the GMF repository doesn't seem to have that feature. Nevertheless, I got that repository and tried to build GMF Runtime in isolation, but apparently that requires Java 17, however that is incompatible with the version of Maven that we are using (3.6.3). I'm experimenting to see if we can move to a more recent Maven version, but at least OCL declared Maven 3.6.3 as a requirement in its build. I'll try to see if I can make it work with more recent Java and Maven versions.

Another update:
It seems like I can patch the GMF features without having to wreslte with the Java and Maven versions. However I encountered another problem. It turns out that one of the very core features of Eclipse itself (e4.platform.ui) has a hard version dependency on apache.xml graphics. Trying to patch that one, revealed that other core Eclipse features depend on it, namely e4.rcp and rcp. I am now trying to figure out if I can patch them. But the conclusion so far, is that the dependency on log4j 1 goes very, very deep into the core of Eclipse itself. And this has a big consequence: it may be very difficult, in the future, to upgrade to newer versions of all these dependencies, from Papyrus to Xtext to Xtend to OCL to Eclipse itself.

Maybe contribute all patches upstream so that they are hopefully integrated upstream so that a future upgrade can be done more easily?

@eposse We agree, this effort has certainly exposed just how deep log4j1 runs in eclipse as well as how ill maintained eclipses dependencies run. We are stuck between a rock and a hard place at the moment. I will reach out to my management to see if they have any thought for how we should proceed.
@jwillemsen We discussed this earlier in this Github issue, although that was before the scope grew to this level. If we continue to move in this direction, we will definitely attempt to have Ernesto contribute these to the open-source community.

@j26151 Sorry, missed the earlier discussion

Indeed, it's a difficult situation, but I just want to clarify that it still looks doable, patching the Eclipse core features that is.
There is something to say about maintenance of dependencies in Eclipse projects though. Eclipse itself consists of many, many independent projects (see https://projects.eclipse.org/) with different teams, and most don't have a lot of developers and limited funding, if any. They are open source and most developers are volunteers. They don't all have the same priorities either. How dependency management is done, is up to each project, so there is bound to be all levels of quality and maintenance there. In fact, that's what I have seen in all the projects that I've been patching. And with the log4j issue in particular, I think that these aspects, combined with the fact that the main vulnerabilities affected earlier versions of log4j 2 rather than log4j 1 and the ones that affected log4j 1 affected web applications rather than desktop applications and were considered much lower risk, meant that making such upgrade was never a high priority. So I think it is understandable that dependency maintenance in Eclipse projects is not the same as it would be in a closed product developed by a single organization.

Today's update:
While patching Eclipse features I got contradictory build requirements with OCL, but I managed to get it working again by upgrading to the latest version of ECJ (Eclipse JDT's own Java compiler) which is required by OCL. This is required because OCL uses some ECJ-specific annotations and won't compile without them.
After that, I'm still not able to completely build because org.eclipse.e4.rcp depends on a specific version of org.apache.xmlgraphics, so I needed to patch org.eclipse.e4.rcp, but in turn, org.eclipse.rcp depends on org.eclipse.e4.rcp, so I needed to patch that. The problem is that I did not know where is the source code for org.eclipse.rcp, as the structure of the nine core Eclipse Platform git repositories is rather strange, but I finally found it. Now I'm in the process of patching that one. So hopefully that will be the end of this one.

Finally I found the org.eclipse.rcp 4.28 source. It turns out that Eclipse went through a reorganization of their git repositories and this feature and version where on a now deprecated git repo (https://github.com/eclipse-platform/eclipse.platform.releng.git) which has been migrated to a new one (https://github.com/eclipse-platform/eclipse.platform.releng.aggregator.git) but the new one doesn't seem to contain the code for the older versions (< 4.29 or 4.30). I don't know if that is by design or an error during migration, but it doesn't matter now. We now have the correct version of that feature.

That seems to have worked (the build, I haven't tested the RCP yet). It now includes updated versions of the Eclipse Platform, RCP, e4 RCP, GMF Runtime and Apache XMLGraphics.
Now I'll move on to one of the three left:

org.apache.ant
org.apache.httpcomponents.httpclient
org.freemarker

A status update:\
I started working on the patch for org.apache.httpcomponents.httpclient.
Patching it was easy, but I have not been able to integrate it into the build because it has two non-OSGI dependencies.
In case you might not be familiar with this, Eclipse is a platform that implements the OSGI standard, a standard for development and deploying Java packages as modules. Eclipse plugins are OSGI "bundles" which are essentially jar files with extra meta-data, including of course, dependencies. Dependencies can be other OSGI bundles or plain Java packages available in the class-path. Now, Maven doesn't know anything about OSGI bundles and in particular it doesn't know how to deal with OSGI dependencies. On the other hand, Tycho, the Maven extension we use to build, does. Unfortunately, Tycho doesn't know how to handle non-OSGI dependencies. It expects them to be in a p2 site. But in many cases, like the one I'm dealing with now, dependencies don't exist as OSGI bundles on p2 sites. And this is the situation that I'm dealing with. However, I found out about a Maven plugin called p2-maven, which allows you to get non-OSGI dependencies, turn them into OSGI bundles and make a p2 site with them which can then be used by Tycho. So I am trying to use this to integrate those non-OSGI dependencies.

An update:
I was finally able to integrate apache httpclient to the build. It turns out the p2-maven plugin was not necessary. Apparently Tycho added the required functionality sometime in 2020 (see Bug 567098 - pomDependencies=consider should wrap non-osgi jars . The trick was to add the non-OSGI dependencies as normal maven dependencies and add the following to the tycho target-platform-configuration:
<pomDependencies>consider</pomDependencies>
<pomDependencies>wrapAsBundle</pomDependencies>

That took a long time to find out. But it was worth learning this, as I think this is probably going to resolve the issue I was having earlier building apache ant as well.
So right now, only two more patches left:

org.apache.ant
org.freemarker

I'll try apache ant first to see if I can integrate it with the solution above.

An update:
After finishing the 2.5.0 release (Issue #481), I went back to the patches, but I ran into some unexpected problems: in order to test the new papyrus branch which bumped versions to 2.6.0 as well as the new streams/v2.5.x-maintenance branch, I had to rebuild them, but a standard maven clean build failed, presumably because my latest builds are based on Papyrus 6.5 rather than 4.8 as the older branches, and therefore a lot of newer artifacts had been added to the maven repository that are incompatible with the older builds. So I had to reset the local maven repository (~/.m2/repository) to build the versions based on Papyrus 4.8. But when I went back to the build based on Papyrus 6.5, it failed building some patches for Xtend2 and Papyrus itself. The errors are all related to Xtend2, in particular, there are a number of plugins that include Xtend2 code which is supposed to be compiled into Java at build-time. But now the generated code results in several compile-time errors. I think the the build used to work because I had probably included pre-generated code. I have been able to fix one of the Papyrus plugins, but one of the Xtend2 plugins is giving me a lot of trouble, and this one is critical, because the generated Java code includes references to the old Log4j 1. Unfortunately it's a bit of a chicken-and-egg problem: the older, pre-installed version of Xtend2 is the one generating the code, but it generates code with a reference to the old log4j, which we have removed, resulting in a compilation error on the generated Java. But I can only update the patched Xtend2 to generate the correct code. But this means that I need the the patched Xtend2 to build the patched Xtend2. I'm not yet sure how to resolve this circular build problem. I think I may have to try pre-generating code and then manually updated the pre-generated code, commit the updated generated code and disable code generation for this plugin. That's the only solution that comes to mind at least for now. I'm working on that.

It looks like I was able to resolve the Xtend2 build issues by committing the generated xtend files to the repo.

Status update:
After resolving the Xtend2 issue I started looking at Apache Ant. Unfortunately I ran into a lot of trouble, as Ant is built in a radically different way to every other plugin. So today I spent the day trying looking instead at the other pending dependency: org.freemarker. But I ran into trouble there too. It's not as bad as Ant, but I still have a compile-time issue that seems to be about conflicting dependencies. I am looking into possible ways to resolve it.

An update:
Building org.freemarker is proving to be a bit of a nightmare. It is extremely old, with extremely old dependencies, and it is usually built with Ant. I've encountered many problems. I've been able to solve some, but currently I'm dealing with the issue that its source code includes classes that are supposed to be compiled conditionally depending on the build configuration and which are mutually exclusive, so I'm trying to figure out, first, which is the right subset of classes for a configuration, second, figure out which configuration we need for it, and third, how to select or filter the relevant classes in tycho/maven. It's tricky, but I think I have an idea on how to do it.

An update:
I managed to resolve the freemarker issues and I can build it. But it looks like its dependency on log4j is optional after all and we may be able to get away without its patch. The same may be true for Ant. I'm investigating this. I hope so, because Ant has a very weird and special build, different from anything else.
As I realized that the dependency is optional made me think that the same may be true for other patches, so I'm going step-wise through all the patches to see where it may be optional. The idea is to determine the set of patches that are absolutely required while ensuring that there is absolutely no bundle remaining depends on log4j 1.
While doing that, I discovered that another patch was missing for a component required by Papyrus called org.eclipse.nebula.widgets.nattable, but looks like it's easy to patch.

An update:
I've finally managed to build it so that the generated RCP doesn't include log4j 1, even though it still keeps the old apache ant.
So it is very close to be ready for testing. Nevertheless, I need to update the GitHub workflow because that one fails on this branch, since I updated only the RCP and not the other build artifacts (update sites, ATCD, etc.)
I'll let you know when I get the build working on GitHub.

@j26151 An update: (I posted this in the PR so I'm re-posting it here in case you didn't see it.)
I got the GitHub build working. It seems to be free of any traces of log4j 1. I am testing the resulting artifacts, but you might start your own tests as well. You can get the RPM and ZIP files here.
I expect there will be a few issues. I will be testing myself in the next few days.
Let me know of any issues that you run into.

BTW, it needs Java 17.

Preliminary testing on CentOS 7 seems to show everything working fine.

Java 17 shouldn't be a huge problem. We are no longer running on CentOS 7  since it is no longer supported. We have moved to Alma Linux 8. I wouldn't expect any different issues, just letting you know. Our team does not have any extra capacity to spare dedicated developers to test this feature for the rest of the year. I do not yet know about allocation for our team next year. I would not wait on our team to confirm these features.

Ok, I understand. I will keep testing on my end, and in particular I will setup an Alma Linux 8 VM to test. I will also work on integrating back Papyrus Compare, which if you remember, we had left aside while working on the rest of the patches, as you said it was not the main priority.
I assume we continue this work on the branch, leaving the PR open until you have time to test it, correct? Or should I merge it once I am confident enough and deal with potential issues in the new year?

An update:
I successfully integrated Papyrus Compare and I continued testing. Code generation works as before. But during testing I found a bug when opening diagrams and the deployment editor. I am debugging this by comparing the behaviour in the old version (Papyrus 4.8) with the new one (Papyrus 6.5). I found a difference in the objects representing diagrams being created which is the cause of the bug, but I do not know yet why that happens. I continue investigating.

A new update. I have been investigating problems related to the architecture context/viewpoints that arose during testing. I have fixed one that prevented the opening of the Deployment Editor, but there are others, preventing the creation and opening of standard UML diagrams, and resulting in  an empty "New Diagram" pop-up menu. These are all related. I was able to create a minimalistic architecture model and tested it in plain Papyrus 6.5 and can confirm that the problems are with Papyrus, not with CX. I have been able to narrow down the Papyrus component responsible for this bug (it's the "Architecture Domain Merger" and happens when you open a Papyrus model for the first time during a session.) I am now in touch with the Papyrus developers to try to figure this out. I'll keep debugging it to see if I can patch it myself, rather than wait who knows how long before the Papyrus team fixes it.
PS: I'm off next week and I'll be back after New Year's.

Thank you for the follow up. Hopefully this is something that can be resolved relatively quickly but keep us updated as you learn more.

A new update:
I was finally able to figure out the root cause of the bug. There is an bug in the algorithm that merges "Architecture Contexts" in Papyrus (not CX). I'm working on a solution, but it is not trivial, as this code impacts a lot of things that Papyrus does. But I have good reasons to think that I'll be able to fix it soon.

Glad to hear it! Thank you for the update.

A status update: I have a solution that appears to work and seems to work on most cases, but there are still a couple of things that don't quite work, so I'll be digging into these. But I think I'm nearly done. Nevertheless, I think that we may need to migrate models, which is natural to expect considering we are jumping from Papyrus 4.8 to 6.5. But I think the migration rule would probably be relatively simple.

By the way, since we are making such a major version jump, perhaps we should also do a major version jump in CX from 2.6 to 3.0?

I think it makes sense to do a major version jump to 3.0 personally. @J17359 thoughts?

Yes, 100% agree. Something this drastic should be a major version bump.

Sounds good. I'll update the version once I'm done fixing all the issues I've found with the patches.

I've finally resolved all the pending issues, and everything seems to be working well. I think it's ready for you to test. I'll just do a bit of code cleanup, start a build and let you know when it's ready for you to download.

Ok, the build is finally ready for you to test. You can get it in this link. I've tested it on AlmaLinux 8.9. Everything works as expected as far as I can see. No Log4J 1 to be seen. Only Log4J 2.17.1.
Note that the RPM still has version 2.6.0, but it is the right one, so you can test it. I'm now going to update the version to 3.0.0 as discussed in #490.

Closing as agreed with @j26151 by e-mail on February 26, 20024.


Node.js Serverless Function template doesn't work (gives a 404)

This is a duplicate of #767. It's about https://vercel.com/templates/other/nodejs-serverless-function-express.

Vercel's online demo works (https://nodejs-api-example.vercel.app/api/hello)
One-click deploy doesn't work (404)
Local development doesn't work (404)

Reproduction - deploy

Click deploy on https://vercel.com/templates/other/nodejs-serverless-function-express
Go through the process, i.e. authorize creating a repository
Go to your deployment
You will see a 404

Reproduction - local

Clone/copy the template locally
vercel dev
Go to localhost:3000
You will see a 404

You need to go to the route: /api/hello.
e.g. https://nodejs-api-example.vercel.app/api/hello

Right! Thanks and sorry for the confusion.


Fix configuration file documentation link in ReadMe

I was getting a 404 link. I think this new link is the proper location of the documentation.

Ghost redirects are not great apparently


Return defensive copies of TSet from the HQDM methods.

I did this in two places rather than just doing it in getRelated() since in some cases the TSet isn't returned outside the HQDM class so the clone would serve no purpose.

Is getRelated public API? The intention of my PR was that it should be (and so should relate and related), unless you have a strong objection. In which case the public getRelated also needs to return a clone, but maybe we want a private _getRelated which doesn't for internal use.

Good spot, I missed that. Originally I was going to put it in getRelated() but then saw the internal uses that don't need a clone. I can move cloning into getRelated() and add a private _getRelated().
On a private project I have an immutable version of TSet where the add method returns a new TSet, and I have an internal privateAdd which makes sure entries aren't duplicated. We'll end up with more copying of the internal array unless we switch to using lists internally where we add entries only at the head. This means the tail is immutable and can be shared between copies of the TSet and we won't need a clone(), but will mean we need a new implementation of Lists, which can be inefficient to traverse.
What do you think?

I would tend to agree - immutability is great but we're short on time. There are some other methods that also return Arrays so I'll update them all to return Iterables, which might be a breaking change but worth doing.

So, returning Iterables means that consumers can't easily cal methods like map(), size(), has() etc. that TSet provides - your only option is to iterate. So on balance I'd prefer to return a TSet.clone() instead. We're still able to change the underlying implementation to something other than an Array, and I can also make TSet return the underlying Iterator for the Array for people who prefer for loops over map, filter etc.
Is that ok?

Yes, sounds reasonable to me at this point. If it's straightforward it would be good to implement Symbol.iterator on TSet so that people can use it as a generic iterator if they want to.

Ok that's done, and there's a test to show that TSet is now Iterable as well.


GnuParser and OptionBuilder are deprecated

Apache Commons CLI's GnuParser and OptionBuilder have been deprecated, this PR replaces them with DefaultParser and Option#build.
This now also allows -lof JSON a.pdf, currently only -l -o -f JSON a.pdf works.
I also updated the error message if there is not exactly one file, it is a bit misleading.
Currently -lof JSON a.pdf would result in three args, of, JSON and a.pdf, the error ... needs one filename rather sounds like there was no file given.

Great contribution! Thanks a lot @criztovyl, merging.


Fix #673, Cancelling a file upload...

Fixes issue #673
As discussed in #673 adding only _uploadDialog = null, i thought it fixed the problem.
However it would cause multiple input lines to be inserted for each time we clicked cancel.

So it would prompt n+1 for each input statements.
To fix that I checked if the class upload-files-input-elem is already there or not. If its there don't append else append.
Results:

Love it. Assigning @flukeout as a second pair of eyes in case he spots visual quirks.

Testing now!

Hey, tested this and it works as expected! +1 from me - nice work @Shank09 if the code is good @Pomax go ahead and merge please.


Backport changes for multiple CP forward compat

See #20963
Replaces version with revision, uses istiod-revision if needed.

@costinm: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-security-k8s-tests_istio_release-1.5
dc77468af368856498e31c39437451f8034a5715
link
/test integ-security-k8s-tests_istio_release-1.5

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-security-k8s-tests_istio_release-1.5


Update concepts-extensions.md

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

#sign-off

@GennadNY: I'm sorry - only the author of this article, @sunilagarwal, can sign off on your changes. But we do have an exception process - if you are on the Microsoft content or product team for this product area, you can ask the PR review team to review and merge it by sending mail to the techdocprs alias.

Hi @GennadNY - PMs should work in the private repository. In the public repository, the documented process is for the article author to review and sign off on a proposed update. If you create a pull request in the private repo, you can sign off directly. We'll close this PR and ask you to submit the change through the private repo. Thank you!


Update docker image.

Shrink docker image from 635.6MB to 569.9MB.

Before
docker_gogs                         latest              06a8862057f6        3 hours ago         635.6 MB

After
docker_gogs                         latest                 5f9a6c952c9f        2 hours ago         569.9 MB

Update from fig (deprecated) to docker-compose.
Update README.md.

Signed-off-by: Tiago Pires<EMAIL_ADDRESS>

Thanks a lot!


[GUI-NX v-guinx-03-02-22] - Problem when removing widget

I'm submitting a ...

[x] bug report
[ ] feature request
[ ] support request

Dashboard screen add at least one widget

Remove widget.
Note: If you have more than one widget, remove them all.

Empty Dashboard

**Reload the page (F5), the last widget returns to the dashboard. **

Please tell us about your environment:

Version: v-guinx-03-02-22
Environment: [docker-compose]
Operating system: [Ubuntu 16.04]

Version tested: Version: DEV-220816
Widget has been successfully removed.


dx12: Destroy old swapchain on recreation

Fixes https://github.com/gfx-rs/gfx/issues/2431
PR checklist:

[x] tested quad with the following backends: dx12

Currently crashes on shutdown, not totally sure. Might be that the window handle is already invalid but the swapchain is still alive? Need to investigate further..

Remaining issue was that some resources associated with the swapchain were still in use.
bors r=kvark


Booking Confirmation Flow

After payment confirmation has been received and Book Room has been called successfully, the following two steps to be done:

[ ] #39
[ ] #40

[ ] Booking confirmation page frontend


invalid JSON output

Describe the bug
-of json is fine and export json using double quotes, -o json is exporting json with single quotes which is invalid and so break all json parsers.
To Reproduce
$ rawsec-cli list os -of /tmp/test.json
$ rawsec-cli list os -o json > /tmp/test2.json
$ diff test.json test2.json
$ rawsec-cli list os -o json | jq
parse error: Invalid numeric literal at line 1, column 12
$ cat test.json | jq # => ok

Expected behavior

identic output between -o and -of
-o json to return valid json

Environment (please complete the following information):

OS: AchLinux
Python Version 3.9.1
rawsec-cli, version: 1.1.1, commit: 1f86aed2a6c7af7d5b1e18eb1df043b7071247da

Idea
Just replace simple quotes with double quotes (or export python dict to JSON).

hey @noraj
thanks you for testing my code, awesome work, thanks a lot.
True i just needed to replace:
this code:
click.echo({"projects": projects, "total": len(projects)})

By:
click.echo(json.dumps({"projects": projects, "total": len(projects)}))

now:
rawsec-cli list os -o json | jq # => ok

I had a good guss it was a python dict vs JSON object issue.

yes


Globally set defaultStyle of markdown

At the moment the readme's in me storybook react project are styled pretty ugly, especially the props table, because it uses my custom storybook theme. Somehow the custom theme does not go well with the table. I want to use the defaultTheme for all the readme's as specified in the githubMarkdownCss.js file but I don't know how.
I can't seem to set any style globally though, although I have to say the docs are confusing. This one of the things I have be trying to just change the table background color:
config.js:
addDecorator(addReadme);

addParameters({
  options: {
    theme: myCustomTheme,
    panelPosition: 'right',
    readme: {
      theme: {tableTrBackgroundColor: '#fff',},
    }
  },
});

But then again, I preferably want to use the entire defaultTheme settings.
How do I do this?

Never mind I figured it out, except for my mistake to put 'readme' in the options param you need to change the original theme so storybook readme can do the rest, really vague though, I needed to search the source code. You might wanna consider updating your docs about that.
ddParameters({
  options: {
    theme: myTheme,
    panelPosition: 'right',
  },
  readme: {
    theme: {
      textColor: '#333',
      appBg: '#f7f7f7',
      barBg: '#fff',
    },
  }
});


Check sak modules with tfsec

Check sak modules with tfsec.
Why is this needed:`.
It will find potential misconfigurations.
This tool should be added into GitHub Actions.

TODO:
Re-check this PR
https://github.com/provectus/sak-external-dns/pull/7


Renamed Param expand options

[x] Closes https://github.com/pyviz/panel/issues/69

Codecov Report

Merging #127 into master will not change coverage.
The diff coverage is 95.65%.

@@           Coverage Diff           @@
##           master     #127   +/-   ##
=======================================
  Coverage   89.76%   89.76%
=======================================
  Files          27       27
  Lines        4025     4025
=======================================
  Hits         3613     3613
  Misses        412      412

Impacted Files
Coverage Δ

panel/tests/test_param.py
99.61% <100%> (ø)
:arrow_up:

panel/param.py
90.27% <93.75%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Unable to read m3u8 file from AWS Cloudfront (using AWS Signed URL technology)

I've got several audio and video files in an S3 bucket serviced by Cloudfront. I'm sure that the .m3u8 files are valid, as I can get access to them if I use a signed url. However, I can't seem to get the headers to get passed in the subsequent calls. Here's the code snippet that I'm using (taken string from the initState() method in the sample code):
    String url = "https://cdn.example.com/folder1/folder2/folder3/myMovie.m3u8";
    Map<String, String> httpHeaders = {
      "useCookies": "true",
      "CloudFront-Policy": "${AWSCloudFrontSignedUrl.cloudFrontPolicy}",
      "CloudFront-Signature": "${AWSCloudFrontSignedUrl.cloudFrontSignature}",
      "CloudFront-Key-Pair-Id": "${AWSCloudFrontSignedUrl.cloudFrontKeyPairId}",
    };
    _controller = VideoPlayerController.networkUrl(Uri.parse(url), httpHeaders: httpHeaders)
      ..initialize().then((_) {
        // Ensure the first frame is shown after the video is initialized, even before the play button has been pressed.
        setState(() {});
      });

When the player is trying to intialize, I see that some of the URLs have the correct URL on them, but some do not.

This is done in the same network call, but without all of the signature stuff added to it:

I'm not sure how to get the player to add the extra parameters to each and every item that is in the playlist. Thanks for your help!

There does seem to be a way to do this transparently using this article from AWS and having 2 different cloudfronts going on. So I don't think that this is going to stop me from using this, however, there still seems to be an issue with using the cookies passed in through the header consistently.

Did you ever find a satisfactory resolution to this?
Adam

Okay. If your organization wants to write me up an hourly contract, I'd love to take a look. This type of thing genuinely interests me so I'm willing to tackle it if you need help.


opendht: 1.5.0 -> 1.6.0

Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:

built on NixOS
ran /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtnode -h got 0 exit code
ran /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtnode --help got 0 exit code
ran /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtchat -h got 0 exit code
ran /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtchat --help got 0 exit code
ran /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtscanner -h got 0 exit code
ran /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtscanner --help got 0 exit code
found 1.6.0 with grep in /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0
found 1.6.0 in filename of file in /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0

cc @Radvendii @olynch for review

No attempt on x86_64-darwin
The following builds were skipped because they don't evaluate on x86_64-darwin: opendht
No log is available.

Success on aarch64-linux (full log)
Attempted: opendht
Partial log (click to expand)
shrinking /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0/bin/dhtscanner
shrinking /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0/bin/dhtchat
shrinking /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0/bin/dhtnode
shrinking /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0/lib/libopendht.so.0.0.0
gzipping man pages under /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0/share/man/
strip is /nix/store/lvx1acn1ig1j2km8jds5x3ggh3f2wa8v-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0/lib  /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0/bin
patching script interpreter paths in /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0
checking for references to /build in /nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0...
/nix/store/c50i6wc173szqav9k338hylkvn8vg42d-opendht-1.6.0

Success on x86_64-linux (full log)
Attempted: opendht
Partial log (click to expand)
shrinking /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtchat
shrinking /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtnode
shrinking /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin/dhtscanner
shrinking /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/lib/libopendht.so.0.0.0
gzipping man pages under /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/share/man/
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/lib  /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0/bin
patching script interpreter paths in /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0
checking for references to /tmp/nix-build-opendht-1.6.0.drv-0 in /nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0...
/nix/store/pr77bpwm850hdynaky1yddn1czy2rwx7-opendht-1.6.0


the network is down to one peer, behaving erratically, and my own nodes keep crashing for varying reasons

These are fun times to be mining Skepticoin.
A few things I noticed:

Only one peer remains up (not mine)
My own nodes I try to run keep crashing, or they are running but don't appear on the list of peers when I try to add a 3rd or 4th machine.
The one peer which is not mine behaves erratically, my logs showing Connection refused, Connection reset, No route to host.
My node keeps retransmitting the entire blockchain to the one peer, over and over.
Multiple "microforks" (blockchain diverges by few blocks) logged by the peers that manage to stay up a while.
Additional instances of the one peer showing up on different TCP/IP Ports (non-2412) causing "No route to host" on my end
Peers not responding to GetBlocksMessages or GetBlocksMessages not being sent.
Initially noticed GetBlocksMessages are sent twice to the same peer, after fixing this I noticed the peer disconnects in response to a legit 2nd GetBlocksMessages
netstat -an showing "Recv-Q" backlog indicating the code is not reading the data from the sockets

Issues fixed in PR #120

Updates:

~Only one peer remains up (not mine)~ and - ~My own nodes I try to run keep crashing, or they are running but don't appear on the list of peers when I try to add a 3rd or 4th machine.~ UPDATE: fixed, probably by #128 and/or #113
~The one peer which is not mine behaves erratically, my logs showing Connection refused, Connection reset, No route to host.~ UPDATE: Not sure if still happening, but hasn't been a problem
My node keeps retransmitting the entire blockchain to the one peer, over and over. UPDATE: Possible fix in 6dd8a4c cherry-picked from withdrawn PR... currently I'm not running this code, not sure if it would cause other problems.
~Multiple "microforks" (blockchain diverges by few blocks) logged by the peers that manage to stay up a while.~ UPDATE: This is better now that my nodes are patched but won't be fully resolved until #129 is released and deployed to remaining nodes.
Additional instances of the one peer showing up on different TCP/IP Ports (non-2412) causing "No route to host" on my end. UPDATE: Not sure about this, see possible fix in b1fcee2, cherry-picked from larger withdrawn PR, I'm not running this in prod.
Peers not responding to GetBlocksMessages or GetBlocksMessages not being sent. UPDATE: I haven't checked on this recently but it was probably caused by the slow disk writes holding up the network thread, fixed in #129
Initially noticed GetBlocksMessages are sent twice to the same peer, after fixing this I noticed the peer disconnects in response to a legit 2nd GetBlocksMessages. UPDATE: Relates to c5f72b6 and 61ce589, from the withdrawn PR #120 - I ran this code for a while but then decided to roll it back for now.
~netstat -an showing "Recv-Q" backlog indicating the code is not reading the data from the sockets~ UPDATE: this was also caused by the slow disk writes -  #129 fixes this.

Could the sole surviving peer be my cheap VM? Who knows... I do know that the fact that the whole chain was in-memory was making it so that the skepticoin-mine process kept getting killed.


add multiple mimeTypes support

Add support for more than one mime type in FileChooserDialog

@Warrocker looks like the build is failing

Travis logs is strange, similar it cant find android libraries, Ive to look what might went wrong

The problem is here

Thanks,  I'll fix it

Version 2.0 is under development as a rewrite, so this will no longer be applicable.


Unhandled error during execution of scheduler flush.

Version
3.0.5
Reproduction link
https://github.com/Jacopostortini/Twotter.git
Steps to reproduce
Run the project and from the home ("/") click on one of the names or go directly to /user/0
What is expected?
The page should load a UserProfile component
What is actually happening?
The component does not load

Actually I am new to Vue.js and this is a mini project to get to know the framework so I am sorry but I don't know whats going on. I just got a couple of warnings and an error in the console saying that it could be a bug and I should report it. It appeared after I added a route

Hi, thanks for your interest but Github issues are for bug reports and feature requests only. You can ask questions on the forum, the Discord server or StackOverflow.
Bug reports must have a boiled down reproduction (https://new-issue.vuejs.org/?repo=vuejs/vue#why-repro)

Hi, thanks for your interest but Github issues are for bug reports and feature requests only. You can ask questions on the forum, the Discord server or StackOverflow.
Bug reports must have a boiled down reproduction (https://new-issue.vuejs.org/?repo=vuejs/vue#why-repro)


Performance overlay can be broken by other layers

Run
void main() {
  runApp(new CupertinoApp(
      home: CupertinoPageScaffold(
          navigationBar: CupertinoNavigationBar(),
          child: Placeholder())));
}

and turn on the performance overlay.

It gets clipped by a clip layer from the content below.
TransformLayer#5e392
 │ owner: RenderView#d1a52
 │ creator: [root]
 │ offset: Offset(0.0, 0.0)
 │ transform:
 │   [0] 2.0,0.0,0.0,0.0
 │   [1] 0.0,2.0,0.0,0.0
 │   [2] 0.0,0.0,1.0,0.0
 │   [3] 0.0,0.0,0.0,1.0
 │
 ├─child 1: OffsetLayer#4c3fc
 │ │ creator: RepaintBoundary ← _FocusScopeMarker ← Semantics ←
 │ │   FocusScope ← PageStorage ← Offstage ← _ModalScopeStatus ←
 │ │   _ModalScope<dynamic>-[LabeledGlobalKey<_ModalScopeState<dynamic>>#a52e8]
 │ │   ← _OverlayEntry-[LabeledGlobalKey<_OverlayEntryState>#f837c] ←
 │ │   Stack ← _Theatre ←
 │ │   Overlay-[LabeledGlobalKey<OverlayState>#e173c] ← ⋯
 │ │ offset: Offset(0.0, 0.0)
 │ │
 │ ├─child 1: PictureLayer#52289
 │ │   paint bounds: Rect.fromLTRB(0.0, 0.0, 375.0, 667.0)
 │ │
 │ └─child 2: OffsetLayer#b18e0
 │   │ creator: RepaintBoundary-[GlobalKey#82d7e] ← IgnorePointer ←
 │   │   Stack ← _CupertinoBackGestureDetector<dynamic> ← DecoratedBox ←
 │   │   DecoratedBoxTransition ← FractionalTranslation ←
 │   │   SlideTransition ← FractionalTranslation ← SlideTransition ←
 │   │   CupertinoPageTransition ← AnimatedBuilder ← ⋯
 │   │ offset: Offset(0.0, 0.0)
 │   │
 │   ├─child 1: PictureLayer#c4d91
 │   │   paint bounds: Rect.fromLTRB(0.0, 0.0, 375.0, 667.0)
 │   │
 │   └─child 2: ClipRectLayer#c2c0b
 │     │ clipRect: Rect.fromLTRB(0.0, 0.0, 375.0, 64.0)
 │     │
 │     └─child 1: BackdropFilterLayer#2ae16
 │       ├─child 1: PictureLayer#94c87
 │       │   paint bounds: Rect.fromLTRB(0.0, 0.0, 375.0, 64.0)
 │       │
 │       └─child 2: AnnotatedRegionLayer<SystemUiOverlayStyle>#60d94
 │           value: {systemNavigationBarColor:<PHONE_NUMBER>,
 │             systemNavigationBarDividerColor: null, statusBarColor: null,
 │             statusBarBrightness: Brightness.light, statusBarIconBrightness:
 │             Brightness.dark, systemNavigationBarIconBrightness:
 │             Brightness.light}
 │           size: Size(375.0, 64.0)
 │
 ├─child 2: PerformanceOverlayLayer#bf57f
 └─child 3: PictureLayer#23747
     paint bounds: Rect.fromLTRB(0.0, 0.0, 750.0, 1334.0)

Actually this is only triggered if the clip layer (#c2c0b in the above) uses hardEdge clip behavior

I tried running the app, and the overlay is correctly on top of everything. Is this still an issue or was it fixed?

Ya, the caveat is it only breaks when the clip at https://github.com/flutter/flutter/blob/2c1d12d4f77e4d82fc47c15a773a6c9903f4274c/packages/flutter/lib/src/cupertino/nav_bar.dart#L120 is using hardEdge clipBehavior


PlatformIO IDE extension does not work on code-server v3.12.0 from Docker Hub

OS/Web Information

Web Browser: Chrome
Local OS: Ubuntu
Remote OS:MacOS
Remote Architecture:
code-server --version:3.12.0

Steps to Reproduce
1.Extension
2.install PlatformIO
Expected
install completed
Actual
PlatformIO: Can not find working Python 3.6+ Interpreter. Please install the latest Python 3 and restart VSCode
Logs
console.ts:137 [Extension Host] /usr/bin/python Error: Error: The Python 3.6.9 (/usr/bin/python) interpreter is not compatible.
Reason: Could not find distutils module
at /config/extensions/platformio.platformio-ide-2.3.4/node_modules/platformio-node-helpers/dist/index.js:1:769744
at ChildProcess.a (/config/extensions/platformio.platformio-ide-2.3.4/node_modules/platformio-node-helpers/dist/index.js:1:771334)
at ChildProcess.emit (events.js:400:28)
at ChildProcess.emit (domain.js:475:12)
at maybeClose (internal/child_process.js:1058:16)
at Socket.<anonymous> (internal/child_process.js:443:11)
at Socket.emit (events.js:400:28)
at Socket.emit (domain.js:475:12)
at Pipe.<anonymous> (net.js:686:12)

Screenshot

Duplicate of https://github.com/cdr/code-server/issues/1448


proper error message for fn source/sink when there are non-KRM resources

fixes https://github.com/GoogleContainerTools/kpt/issues/2039
sample output:
$ kpt fn source
error: f1.yaml: resource must have `metadata.name`

What's the behavior when encountering non-KRM for other commands such as render, eval, etc.? Are they consistent?

What's the behavior when encountering non-KRM for other commands such as render, eval, etc.? Are they consistent? If not, what's the plan for them?
Currently render and eval currently throw an error when encountering a non-KRM resource. Not sure what the plan is if we want to make it consistent with source/sink. @droot ?

@natasha41575 What is the status of this PR ?

@natasha41575 @phanimarupaka It is safe to close this PR because we don't need to enforce the invariants that we enforce in eval and render in source etc because if source is used with eval and render, then the invariants will be enforced anyways. And in all other cases where source is used without eval or render, we are not sure about enforcing the invariants. We can pick this later if we run in to cases.
closing this for now.