Error to run NODE.JS application in intel edison

Hi guys,
I put ubilinux in my intel edison and I blink led with c++ and python.
Now I have problems to blink led using node.js:
root@neuberfran:/usr/share/mraa/examples/javascript# node -v
v5.4.0
root@neuberfran:/usr/share/mraa/examples/javascript# npm -v
3.3.12
root@neuberfran:/usr/share/mraa/examples/javascript# node Blink-IO.js
module.js:423
return process.dlopen(module, path._makeLong(filename));
^
Error: Module did not self-register.
at Error (native)
at Object.Module._extensions..node (module.js:423:18)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
at Module.require (module.js:354:17)
at require (internal/module.js:12:17)
at Object. (/usr/share/mraa/examples/javascript/Blink-IO.js:25:9)
at Module._compile (module.js:398:26)
at Object.Module._extensions..js (module.js:405:10)
at Module.load (module.js:344:32)
To install node.js I’m using this tutorial
blog.wia.io/installing-node-js-v4-0-0-on-a-raspberry-pi/
But I changed nodejs.org/dist/v4.0.0/node-v4.0.0-linux-armv6l.tar.gz
To nodejs.org/dist/v4.0.0/node-v4.0.0-linux-x86.tar.gz
Because intel Edison is a x86 32 bits
https://www.youtube.com/watch?v=z3O26CC9nAc
I'm trying transport this tutorial (above) to intel edison. The first part: http://localhost:3000 worked. Than, If I try hello world here, will worked
About this site: http://stackoverflow.com/questions/28486891/uncaught-error-module-did-not-self-register/30233557
I tried every things:
npm rebuild
rm -rf node_modules
npm i
But don't solved
http://www.emutexlabs.com/forum/general-questions/96-error-to-run-node-js-application-in-intel-edison#162

you'll have to compile nodejs from source, don't use a prebuild binary. Get the source tarball and rebuild. Then do an npm install mraa and clear the existing stuff from node_modules.

Please I need more detail step by step I have to do even
If possible with commands

You should be able to do something like this:
wget https://nodejs.org/dist/v4.2.4/node-v4.2.4.tar.gz
tar xf node-v4.2.4.tar.gz
cd node-v4.2.4/
./configure --prefix=/usr
make
make install

And then:
npm install mraa

I think the correct is node-v4.2.4-linux-x86.tar.gz
The instalation interrupetd here in make command

Are you sure you didn't just run out of disk space? I see no error there,
please send text not screenshots
On 18 Jan 2016 19:36, "neuberfran"<EMAIL_ADDRESS>wrote:

I think the correct is node-v4.2.4-linux-x86.tar.gz
The instalation interrupetd here in make command
[image: image]
https://cloud.githubusercontent.com/assets/7308528/12400854/b7278114-be09-11e5-9428-0fc39e9a31f0.png
—
Reply to this email directly or view it on GitHub
https://github.com/intel-iot-devkit/mraa/issues/406#issuecomment-172630870
.

root@neuberfran:~# cat /proc/cpuinfo | grep -E '^(b|pr|v|mo|$)'; uname -a; echo;                                                                                free; echo; df; echo
processor       : 0
vendor_id       : GenuineIntel
model           : 74
model name      : Genuine Intel(R) CPU   4000  @  500MHz
bogomips        : 998.40
processor       : 1
vendor_id       : GenuineIntel
model           : 74
model name      : Genuine Intel(R) CPU   4000  @  500MHz
bogomips        : 998.40
Linux neuberfran.dyndns.ws 3.10.17-yocto-standard-r2 #7 SMP PREEMPT Thu Feb 26 0                                                                                9:57:06 UTC 2015 i686 GNU/Linux
         total       used       free     shared    buffers     cached

Mem:        983516      83348     900168          0      14780      33260
-/+ buffers/cache:      35308     948208
Swap:            0          0          0
Filesystem      1K-blocks    Used Available Use% Mounted on
rootfs            1441648 1172656    173968  88% /
/dev/root         1441648 1172656    173968  88% /
devtmpfs           491448       0    491448   0% /dev
tmpfs               98352     300     98052   1% /run
tmpfs                5120       0      5120   0% /run/lock
tmpfs              196700       0    196700   0% /run/shm
tmpfs              491756       0    491756   0% /tmp
/dev/mmcblk0p7      32686    5352     27334  17% /boot
/dev/mmcblk0p10   1337936    2060   1319492   1% /home

I still don't see an error. Please stop with the screeenshots, paste logs in dpaste.com or a similar pastebin!

I downloaded wget https://nodejs.org/dist/v4.2.4/node-v4.2.4-linux-x86.tar.gz and before tar I command cd node-v4.2.4-linux-x86
But I can't do command ./configure --prefix=/usr Because ./configure does not exist in this package

You where wrong I gave the correct tarball. You're downlading a pre compiled tarball. https://nodejs.org/dist/v4.2.4/node-v4.2.4.tar.gz

Ok. I'm trying this now and mistakes(fix) are repeating
where I find the logs files to put in pastebin ?

below I will put the link for the end of the installation (make) and after (make install) and node -v and npm -v
http://dpaste.com/3BP8N0K

Looks like I made a mistake, you need gcc 4.8 and above for node 4.x so it won't build on edison. My bad. You may have to downgrade to 0.12.x

I have just tried - on Yocto image it compiles from sources just fine. Took about 1-1.5 hrs with "make -j2", but works nicely:
root@edison1:~/nodejs/node-v4.2.4# ./node -e "console.log('Hello from node.js ' + process.version)"
Hello from node.js v4.2.4

The error @neuberfran has looks like an incorrect gcc version indeed - however they should have added a check for that, so that's a bit strange. One more reason not to use ubilinux on Edison to me :smiley: with all due respect to Emutex folks.
@neuberfan, check what gcc you've got, on Yocto it's
root@edison1:~/nodejs/node-v4.2.4# gcc --version
gcc (GCC) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@edison1:~/nodejs/node-v4.2.4#

root@neuberfran:~# gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

So you need to update your edison image :)
Btw @alext do you think you could push node 4.x to your repo instead of
node 0.12.x?
On 19 January 2016 at 22:04, neuberfran<EMAIL_ADDRESS>wrote:

root@neuberfran:~# gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
—
Reply to this email directly or view it on GitHub
https://github.com/intel-iot-devkit/mraa/issues/406#issuecomment-173002862
.

I've been thinking about this for a while now, the biggest problem is that there are some node.js apps in the image (like xdk-daemon and somesuch), which sometimes are sensitive to Node.js versions, so I'd need to find all of them and somehow test.
But in general I'd like to do that, yes. Especially if we make 4.x the only officially supported branch for mraa.

I'm not using edison image (yocto) in this intel edison. I'm using ubilinux. Because I need debian here also

I need help to upgrade gcc to 4.9
root@neuberfran:~/node-v4.2.4# cat /proc/version
Linux version 3.10.17-yocto-standard-r2 (root@p32mac) (gcc version 4.8.2 (GCC) ) #7 SMP PREEMPT Thu Feb 26 09:57:06 UTC 2015
root@neuberfran:~/node-v4.2.4# gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Sorry but no one on here can help you easily upgrade your image to use gcc 4.9, it's not an easy task to do. I'd recommend not using ubilinux because we don't officially support it because it uses a mismatch of components leading to unreliability and isn't fully recompiled from source.
I would recommend rethinking why you want/need debian, but this is a debate best left to the community forum, not for here.

Don't close issue

Sorry but this is not the right place for generic upgrade help to gcc 4.9 or really to help with node compilation in general :) Since we've ascertained that there is no issue with mraa I consider this 'closed'.

I'll be waiting for the release ubilinux jessie  scheduled for January this year


Demonstration Action Not Successful

Hi, I wrote a toy code snippet to test the demo data to see if they are perfect but have found much of the data does not contain successful demonstrations (see the video below). The code to reproduce is:
import gym
import mani_skill.env
import numpy as np
from sapien.core import Pose
import h5py
from h5py import File

f = File('/home/knox/OpenCabinetDoor/OpenCabinetDoor_1061_link_0-v0.h5', 'r')
acts = f['traj_0']['actions'][()]
env = gym.make("OpenCabinetDoor_1061_link_0-v0")
env.set_env_mode(obs_mode='pointcloud', reward_type='sparse')
obs = env.reset(level=0)
for i in range(100):
    env.step(np.zeros(13))
    if i > 50:
        env.step(acts[i-50, :])
    env.render('human')
env.close()

I don't know if i am doing anything fundamentally wrong or there's some internal problems with the data. Please advise. Thanks.
https://user-images.githubusercontent.com/43732483/136081245-464af68a-0d13-4740-9b6f-5cf4cb86f8b7.MOV
o)

Each demonstration trajectory corresponds to a particular level for a training environment. The level information is not contained in the point cloud demonstrations, but is contained in state demonstrations you downloaded in ./full_mani_skill_state_data/ (see "Generating custom point cloud demonstrations" -> "env_levels"). A demo trajectory that is successful on a particular level will not be successful on another level.


Fix launching the CLI without access_control_allow_origin

The default behavior in the CLI was broken.  Also added a warning message fixing #211.

This change is

:lgtm: merging

also cherry-picked to v1.x.x


[MNOE-710] Rename Super Admin -> Admin, Admin -> Manager

This has more changes than https://github.com/maestrano/mno-enterprise-angular/pull/387
You've missed a few in mno-enterprise-angular. Please open a new PR to add them


Cont3xt d3

just testing and diffing. going to delete
TODO

[ ] do this on the dev6 branch
[ ] put d3 top level instead of in viewer AND cont3xt
[ ] put cont3xt assets in top level assets?
[ ] more stuff I'm sure

postponing this for more important tasks


Proper LALR parser

The existing parser calculates lookaheads for reductions by looking at the FOLLOW set of the grammar, making it actually an SLR(1) parser. LALR(1) parsers have the same number of states as SLR(1) parsers, but parse a strict superset of SLR(1) grammars, so they are generally preferred.
These commits implement the algorithm described in Compilers: Principles, Techniques, and Tools (2nd edition) to (supposedly) efficiently calculate LALR(1) lookaheads. This now implements DeRemer and Pennello's LALR lookahead algorithm, based on PLY and The Theory and Practice of Compiler Writing. It does not generate LR(1) states (which may be orders of magnitudes larger) to merge into LALR(1) states. Update: it is now much much faster than the old (dragon book) algorithm.
At a high level, the algorithm:

Generates LR(0) itemsets/states (similar to the existing parser, see below for minor change)~~
Calculates lookaheads
Attaches lookaheads to the LR(0) kernels to form LALR(1) kernels
Generates the LR(1) closure of the LALR(1) kernels to obtain the LALR(1) states (same number as LR(0) states)
Does some stuff I can't really explain 😅

I tried my best to maintain Lark's coding style and I believe the code is well documented documented wherever I thought possible. My main concern is the naming scheme, particularly the lr0_* member variables introduced to GrammarAnalyzer. The LALR(1) algorithm I implemented does not use an $END token for the root rules. However, I did not want to overwrite the existing member variables as it would affect the Earley parser. Update: I can't really explain why the algorithm works, so I couldn't add many insightful comments unfortunately.
The LALR(1) parser can be tested with the following grammar/program:
from lark import Lark

grammar = r'''
EQUALS:  "="
STAR: "*"
ID: "id"

s: l EQUALS r | r
l: STAR r | ID
r: l
'''

parser = Lark(grammar, parser='lalr', lexer='standard', start='s')
text = '*id=id'
print(parser.parse(text).pretty())

The older parser (with debug enabled) logs a shift/reduce conflict. While shifting produces the right behaviour in this example (which is the default conflict resolution mechanism), LALR(1) parsers are known to be more powerful than SLR(1) parsers. As it is, users may see shift/reduce or reduce/reduce conflicts with proper LALR(1) grammars, if the grammars are not SLR(1).
I have run the tests and only 3 tests in tests.test_nearley.test_nearley.TestNearley fail, which were failing for me before my changes (they have a FileNotFoundError, so I assume I'm just missing some test files). However, I have not profiled these changes. Theoretically, parsing speed should be the same because the parsing table format and algorithm were only minimally changed (removed the artificial $END token appended to root rules. Now, a successful parse ends in a reduce action). Generating the parser may be slower as the lookahead calculation is more complex compared to SLR(1).

Great PR! I like how you maintained the coding style, and wrote code that's clean and understandable.
The only thing missing is a test case, that would that it does indeed improve the parser, and prevent future degradation.
There is also another problem, of performance. It's probably not noticeable in tiny grammars, but for medium grammars like examples/python3.lark, it's very noticeable. Here's the performance of the latest master:
$ time python3 -m examples.python_parser
test_python_lib (170 files), time: 31.67557168006897 secs

real    0m36.733s
user    0m33.656s
sys     0m0.422s

That means that compiling the grammar took about 3 seconds. Still much more than desirable, but somewhat acceptable.
Here is the performance of your PR:
test_python_lib (170 files), time: 34.119346380233765 secs
real    1m16.430s
user    1m11.047s
sys     0m0.734s

Compiling the grammar took 42 seconds!! This is serious degradation, which I would be very cautious to spring on users.
My point is, perhaps there are simple optimizations you could use to bring this down to single-digits?  After all, if PLY can do it, then I'm sure it's not that hard :)

For sure I'll look into it! I was mindful of avoiding unnecessary work/stuff that had obviously bad time complexity, but I don't claim to be a performance guru and I wasn't specifically trying to optimize the code. I will profile the code and see what I can do

This is looking much much better!
I cleaned up the code a little (many of the hash tricks you added are no longer necessary, and I simplified what I could), and pushed it to the true_lalr branch. I'm going to let it sit there for a bit, maybe try to improve the code a little further (mostly just try to make it more readable), and I think soon it will be ready to merge into master.

If you feel like working on true_lalr and improving it, either by simplifying, documenting, or any other way, feel free to send a PR for it. I can also just give you push permissions for that branch, which would be a little simpler as a workflow.

I remembered something/thought of something minor to improve the code last night while falling asleep haha. Instead of checking s not in self.rules_by_origin to see if it's a terminal, you can just check .is_term. Lines 190 and 205 in lalr_analysis.py.
I'd be happy to keep looking at it, to improve it. Push permissions for that branch would be nice, though I don't mind updating this/sending another PR

@Raekye My bad, github doesn't allow such granularity. So if you don't mind sending PRs, let's stick with that for now :)

What GH can do, though, if I remember correctly, is to "allow edits by maintainers" when you open a PR (there's a box to check), so @erezsh could edit the PR branch, which solves the present problem I think.

I have the "allow edits from maintainers" box checked. Although it might be awkward, since erezsh already merged this into a new branch and made commits to it

Okay, I added my cleanup commits. You can edit on top of them now.

You can get detailed performance per function call with this snippet. Edit the lark main and add the setup to the beginning and the result printing to the bottom. Optimally, lark could have a command line option which activates this on its main.
import sys

import io
import pstats
import cProfile

profiller = cProfile.Profile()
profiller.enable()

# Core here

profiller.disable()
outputstream = io.StringIO()

profiller_status = pstats.Stats( profiller, stream=outputstream )
profiller_status.sort_stats( "time" )
profiller_status.print_stats()

sys.stderr.write( outputstream.getvalue()[:2000] + '\n' )

Running this solemnly will output:
         1 function calls in 0.000 seconds

   Ordered by: internal time

      ncalls     tottime     percall     cumtime     percall filename:lineno(function)
           1       0.000       0.000       0.000       0.000 {method 'disable' of '_lsprof.Profiler' objects}

Adding a few cool stuff inside it like:
import mmap
import json

# https://docs.python.org/3.9/library/mmap.html
# https://blog.askesis.pl/post/2019/02/mmap.html
memory = mmap.mmap( -1, 20, access=mmap.ACCESS_WRITE )
memory.write( b'{ "var": 10 }' )

end_of_the_file = memory.tell()
print( 'memory {:,}, end_of_the_file {}\n'.format( len( memory ), end_of_the_file ) )

memory.seek( 0 )
print( 'raw', memory.read( end_of_the_file ), file=sys.stderr )

memory.seek( 0 )
loaded = json.loads( memory.read( end_of_the_file ) )

print( 'json', loaded, file=sys.stderr )
print( 'loaded', memory[:end_of_the_file], file=sys.stderr )

Will output:
         3,031 function calls (2,921 primitive calls) in 0.006 seconds

   Ordered by: internal time

      ncalls     tottime     percall     cumtime     percall filename:lineno(function)
          17       0.001       0.000       0.001       0.000 {built-in method nt.stat}
        15/6       0.000       0.000       0.001       0.000 F:\Python\lib\sre_parse.py:475(_parse)
           4       0.000       0.000       0.000       0.000 {built-in method marshal.loads}
           4       0.000       0.000       0.000       0.000 <frozen importlib._bootstrap_external>:914(get_data)
           4       0.000       0.000       0.001       0.000 <frozen importlib._bootstrap_external>:793(get_code)
        25/6       0.000       0.000       0.000       0.000 F:\Python\lib\sre_compile.py:71(_compile)
           4       0.000       0.000       0.000       0.000 {method 'read' of '_io.FileIO' objects}
          14       0.000       0.000       0.000       0.000 F:\Python\lib\sre_compile.py:276(_optimize_charset)
           6       0.000       0.000       0.001       0.000 <frozen importlib._bootstrap_external>:1356(find_spec)
           4       0.000       0.000       0.000       0.000 {built-in method builtins.print}
         102       0.000       0.000       0.000       0.000 F:\Python\lib\sre_parse.py:233(__next)
       31/12       0.000       0.000       0.000       0.000 F:\Python\lib\sre_parse.py:174(getwidth)
           3       0.000       0.000       0.000       0.000 {built-in method builtins.__build_class__}
           2       0.000       0.000       0.000       0.000 {built-in method _imp.create_builtin}
         6/2       0.000       0.000       0.006       0.003 <frozen importlib._bootstrap>:978(_find_and_load)
         123       0.000       0.000       0.000       0.000 F:\Python\lib\sre_parse.py:164(__getitem__)
          39       0.000       0.000       0.000       0.000 {method 'format' of 'str' objects}
           1       0.000       0.000       0.000       0.00

Just merged it into master. After an appropriate waiting period I plan to release it with 0.8
@Raekye thank you for a great contribution, and sorry it took so long!

P.S. I plan to mention you in the next release. Would like to add a few words?

@erezsh Hi! No worries, sorry for the late response myself. Would it be alright to add my username and email (libraekye at gmail dot com) to lalr_analysis.py? Totally minor thing, no worries if you prefer not. Other than that, I can't think of anything at this time. Thanks for your work on this project and time reviewing the PR!

@Raekye Yes, that's completely acceptable. And let me know if you think of anything else.


Test Automation: Some tests do not work on Windows when using AWT Robot Adapter

By default, TestFX uses the "awt" robot adapter. At least on Windows, this results in the SHIFT key not properly handled when selecting text. RichTextFX test cases such as those in the ShiftDown test suite are then failing.
When setting the property testfx.robot to glass, text selection with the pressed shift key works and those test cases succeed.
The solution for the gradle build is to add integrationTest.systemProperty "testfx.robot", "glass" to the build file. (Will submitt a pull request after checking the same on Linux).
See also https://github.com/TomasMikula/RichTextFX/wiki/Test-Automation

Good to know. I'll wait for your PR

I verified that the tests are running fine on X11 / Linux with the glass robot - would you be fine with setting the testfx.robot property to glass independant of the OS? Someone should test on Mac, though ;-)
BTW: Those integration tests are really cool. Can we establish a policy so that we accept pull requests only if a corresponding test is provided? :-)

Someone should test on Mac, though

I think the headless Travis build uses the glass robot anyways, so I don't know if we need to test it on a mac. Mind submitting a PR?

Can we establish a policy so that we accept pull requests only if a corresponding test is provided?

It would be ideal, but we should clean up the tests that we have right now. When I first wrote them, I wasn't going for accuracy as much as I was just trying to prove that the code works. So, some tests should have a few additional checks that aren't currently there right now.

Closed by #589

@afester Can you list which tests failed on Windows when the awt robot adapter was used? I'd like to have this build on both adapters on Windows in the CI build if possible. I'm not sure if the tests are flaky or not.

I quickly run the tests from within Eclipse, using the awt robot. The failures are usually compare assertions (selection does not match the expected text) while the errors are usually something like java.lang.IllegalArgumentException: Invalid key code. I also aded my "counter" workaround for waitForMultiLineRegistration so that pressing_up_moves_caret_to_previous_line does not block the test execution (and that test than fails with a timeout):

BTW: I think this is more a TestFX issue. I have written this simple pure JavaFX test case: https://github.com/afester/FranzXaver/blob/testfx/Examples/src/main/java/afester/javafx/examples/testfx/SelectionTestFXExample.java and it also failes with the awt robot. I see the cursor moving in the input text field, but the text does not get selected. With the glass robot, this worked immediately.

The tests in question are currently skipped when using the AWT robot adapter (see #596), so that one can still build the project without needing to specify this directly. Still, it'll be better to learn more about the issue in the mentioned TestFX issue.


moving multi-tenant laravel from localhost to sever: Database [tenant] not configured.

Description
I have build a web app using hyn and laravel 5.3 on my computer (local). Everything works, so now I wanted to move it to a server. I uploaded the source code, changed the user/pass for the hyn db connection (and other laravel-related configs). Copied the database hyn_multi_tenancy and emptied the customers. hostnames and websites tables.
I tried to add a tenant using the setup step in the documentation:
sudo php artisan multi-tenant:setup --customer=EXAMPLE<EMAIL_ADDRESS>--hostname=example.com --webserver=apache
but a strange thing happens:
it does not create the tenant database, no customer/website/hostname is added in the hyn database tables, instead it just adds all the tables (articles, roles etc.) inside the hyn_multi_tenancy database... then it gives the following errors in the shell:

Thank you so much for pointing me in the right direction...
Actual behavior
..
Expected behavior
..

Information

hyn/multi-tenant version: 2.0.0
laravel version: 5.3
database driver and version:
webserver software and version:
php version:

tenancy.php config

webserver.php config

Error log

Some questions to identify possible causes;

Are the multi-tenant configuration files in your code base too?
Is the system connection configured?
Is the tenant connection not configured?
Does the system connection user have the necessary rights, eg almost root access?

Figured it out... Yes, everything was configured, but the db connections were defined with <IP_ADDRESS> and for some reason on the production server that didn't work. Changing that to localhost solved it. Maybe this will save some time for other people.
Thanks.
Cheers!


Fix for issue #4: Support VS2013 for CC Editor Extensions

Added referenced assemblies from VS2010 and VS2012 to fix Contracts Editor Extensions compilation. Updated VS extension projects to not trigger one-way upgrade warning.
Possible fix for issue #4.

I need to take a closer look at this. I have a set of NuGet packages designed specifically to address these concerns with greater assurance, all without adding the binaries to source control.
I'm :-1: on this particular approach, not because it won't work but because there is an easier, cleaner way.
I'll add more information soon.

@hubuk I made an initial pass through this. I plan to resolve this issue as follows:

Use a single project/assembly for the Adornments code targeting Visual Studio 2010+. This is easy since the project does not depend on any newer/incompatible APIs.
Use a single project/assembly for the ContractAdornments code targeting Visual Studio 2010+. The only difficult part here is a dependency on the C# language service which is specific to specific versions of Visual Studio. To resolve this, I plan to use exactly the same approach that I used for my Inheritance Margin extension (which depends on exactly the same set of assemblies).

Move the code which requires the C# language service to a set of small assemblies that are tied to specific versions of Visual Studio
Load the correct assembly at runtime

@sharwell Your approach seams to be nice and clean. I suspected that there are no differences between these projects other than referenced assemblies. This can be handled out of the box thanks to version redirections in devenv.exe.config (except laguage services as you mentioned). I don't know if Adornments* and ContractAdornments* projects are using all the declared references but the list is quite big. It is also worth mentioning that following assemblies are missing from the repsository:
Microsoft.VisualStudio.CoreUtility.dll
Microsoft.VisualStudio.Editor.dll
Microsoft.VisualStudio.Language.StandardClassification.dll
Microsoft.VisualStudio.Text.Data.dll
Microsoft.VisualStudio.Text.Logic.dll
Microsoft.VisualStudio.Text.UI.dll
Microsoft.VisualStudio.Text.UI.Wpf.dll
It would be best to have Visual Studio extension libraries accessible via NuGet but unfortunately Microsoft has not published them for dev10.

@hubuk Microsoft has not. But I have.

This is (presumably) superseded by #66.

Yup, closing it now.


Fix go module change

workaround https://github.com/golang/go/issues/30515

Codecov Report

Merging #51 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #51   +/-   ##
=======================================
  Coverage   71.96%   71.96%
=======================================
  Files          56       56
  Lines        2240     2240
=======================================
  Hits         1612     1612
  Misses        504      504
  Partials      124      124

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 1d00a51...22ad976. Read the comment docs.


Refactored Drawinglogik and Shuttle Launch

Implemented more generalized Drawing with a lot of interfaces and general behaviour
Restoring the old state of the application with new interfaces
Minor improvements to shuttle - it launches if its closest to its target, and can change direction to have smaller paths

Nice Job!


TCP Traffic not always routed to correct namespace/subdomain

Bug Description
i am not 100% sure this is a bug as i may just be missing something on the implementation. when using multiple namespaces, all of which use the same port. incoming traffic will stick with the first one connected even when trying to disable the connection and connect to a different namespace/subdomain.
subdomain1.domain.com:5591  ----> TCP connection internet endpoint
subdomain2.domain.com:5591
attempt to switch to subdomain2 fails.
subdomain1.domain.com:5591
subdomain2.domain.com:5591  ----> TCP connection internet endpoint attempted, but doesn't work
Traffic is not routed unless I manually change to unique ports via kubectl edit....
subdomain1.domain.com:5592
subdomain2.domain.com:5591  ----> TCP connection internet endpoint works now.
So, it is almost as if istio ignores the subdomain for TCP and just relies on unique ports.
Gateway and VirtualService info in 'Additional Info' section.
Version
[opc@tf4-operator ~]$ kubectl version --short
Client Version: v1.21.6+2.el8
Server Version: v1.22.5
[opc@tf4-operator ~]$
[opc@tf4-operator ~]$ helm version --short
v3.6.3+g809dabc

Additional Information
not using istioctl
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
annotations:
meta.helm.sh/release-name: infra
meta.helm.sh/release-namespace: default
creationTimestamp: "2022-06-22T12:19:56Z"
generation: 1
labels:
app.kubernetes.io/managed-by: Helm
name: ingressgateway
namespace: istio-system
resourceVersion: "7317"
uid:
spec:
selector:
app: istio-ingressgateway
servers:

hosts:

'*'
port:
name: http
number: 80
protocol: HTTP
tls:
httpsRedirect: true

hosts:

'*'
port:
name: https
number: 443
protocol: HTTPS
tls:
credentialName: ingress-cert
mode: SIMPLE

hosts:

'*'
port:
name: tcp
number: 5591
protocol: TCP

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
annotations:
meta.helm.sh/release-name: examplename
meta.helm.sh/release-namespace: examplens
creationTimestamp: "2022-06-29T14:28:06Z"
generation: 2
labels:
app.kubernetes.io/managed-by: Helm
name: ingress
namespace: examplenamespace
resourceVersion: "3178035"
uid:
spec:
gateways:

istio-system/ingressgateway
hosts:
subdomain1.domain.com
http:
match:

uri:
exact: /connect-server
name: cs
route:
destination:
host: primary
port:
number: 4444

match:

uri:
prefix: /
name: secondary
route:
destination:
host: secondary
port:
number: 8080
tcp:

match:

port: 5591
route:
destination:
host: primary
port:
number: 5591

For TCP there is no "host" to match on so we only have port which leads to conflicts here


Upgrade requirements

Codecov Report

Merging #74 (5ad8da4) into main (0eba751) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main       #74   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines           50        49    -1
  Branches         6         6
=========================================
- Hits            50        49    -1

Impacted Files
Coverage Δ

src/django_read_only/__init__.py
100.00% <0.00%> (ø)

Continue to review full report at Codecov.

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


Save to file

currently standard output is used:
https://github.com/moon004/Go-deezer-downloader/blob/fdfac3f112003a4ce4730a79fe2c0dae38d5796c/Utils.go#L175
this can be a problem on Windows, as redirects add carriage returns

https://github.com/moon004/Go-deezer-downloader/pull/14

@89z
Sorry for the late reply, the reason i wanted to stream to standard output is because it is for vm used, maybe we could create another branch, for this version, that we stream the output to a file, or also we can branch out a version that is for windows.

https://github.com/moon004/Go-deezer-downloader/pull/15


Add some (very) high-level docs for the data format

I wanted to do this before the previous formats are lost to time. I don't think it's necessary to create a complete specification, just the broad strokes to give folks an idea.
This is very rudimentary and I'll probably flesh it out with some moar details in the future once v1 is properly finished.

Other than that, LGTM


Archive with BitCode check fails

I do have all my frameworks compatible with bitcode.
It was working fine on 0.12.4 I guess but now it fails on both with 0.12.5.
When I archive I get this errors:
https://s3.postimg.org/fpw9yvwjn/Branch_Errors.png
Anyone getting the same problem?

Update: Look lite without bitcode it's not working.
Maybe it is a carthage error?
I do 'clean' and 'clean build folder', then use 'carthage update --platform ios' and use latest version of Branch.
When I archive to make a testflight version I always get the errors, whatever I check or not the bitcode enable.

@damien-nd sorry to hear that you are having trouble. The image URL you posted gives 404. Could you please update the link so that I can see the error you are getting.

Sorry, the link is wrong but the text is good.
The good link is https://s3.postimg.org/fpw9yvwjn/Branch_Errors.png https://s3.postimg.org/fpw9yvwjn/Branch_Errors.png
http://www.octopepper.com/ http://www.octopepper.com/
Damien NOEL DUBUISSON
iOS / Android developer	 http://octopepper.com/contact.php
<EMAIL_ADDRESS><EMAIL_ADDRESS>| +33(0)9 50 27 90 74

Le 17 août 2016 à 23:53, ahmednawar<EMAIL_ADDRESS>a écrit :
@damien-nd https://github.com/damien-nd sorry to hear that you are having trouble. The image URL you posted gives 404. Could you please update the link so that I can see the error you are getting.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/BranchMetrics/ios-branch-deep-linking/issues/408#issuecomment-240560982, or mute the thread https://github.com/notifications/unsubscribe-auth/ABxqpMO3SsJnyvCFWWFOMUqC5Asl6ABGks5qg4LZgaJpZM4Jmg94.

I'm really sorry for the issue.
I end by deleting all Carthage folders, clean builds folder and clean app.
Then I restart all carthage configuration in build phases.
Now everything is working fine. So maybe in long use Carthage mixed up some files, but nothing on your side.
Again sorry for that and will enjoy to continue with branch.

Glad you figured it out. Happy Deep linking!


Port to Rust using Async

Hey!
First of all, thanks for this library. It is a nice & simple way to start with queues without too much complexity.
We are making an async port to rust as we may use it soon. Just though about saying it here in case it is useful to anyone.
https://github.com/Couragium/rsmq_async
Best!

Cool!
Also there is https://github.com/dvdplm/rsmq-rust which is not async.
I'm looking forward to use it.

Yeah. I found that one, but it looked not maintained and was sync. But that is good, depending on if you are using async or not, you have both crates.
To be honest, migrating the js code to proper rust was very easy when using async.

Thank you @DavidBM
I added your port to the README.
Thank you for your work.


add middle size

Hello, i have add a button and function for middle size.

@eldinomick,
Thanks a lot for your improvement!.
There are the following issues:

When the tool is used in an image, the caption is moved to the left.

One test failed.

Best,
Mario

ok thanks, i modify ;-)
good day

Cadot Michaël

Linkedin [8]
Github [1]
Stackoverflow [9]

Le 2021-09-30 17:59, Mario Alejandro Rodríguez a écrit :

@eldinomick [1],
Thanks a lot for your improvement!.
There are the following issues:

When the tool is used in an image, the caption is moved to the left.
[2]
*
One test failed.
[3]
Best,
Mario
--
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [4], or unsubscribe
[5].
Triage notifications on the go with GitHub Mobile for iOS [6] or
Android [7].

Links:
[1] https://github.com/eldinomick
[2]
https://user-images.githubusercontent.com/64106728/135497868-21f44a83-526e-4eb9-9dd2-2882edf54e37.gif
[3]
https://user-images.githubusercontent.com/64106728/135498539-82f28cc3-92dc-4ee7-b070-f1dc5f4b6b1b.png
[4]
https://github.com/kommitters/editorjs-inline-image/pull/40#issuecomment-931500131
[5]
https://github.com/notifications/unsubscribe-auth/AQIFRTV65GVQA6WBSOWQUOTUESJONANCNFSM5EQZSHNQ
[6]
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
[7]
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub
[8] https://www.linkedin.com/in/michael-cadot
[9] https://stackoverflow.com/users/3955573/cadot-michael


[SPARK-13769][Core] Update Java Doc in Spark Submit

JIRA : https://issues.apache.org/jira/browse/SPARK-13769
The java doc here (https://github.com/apache/spark/blob/e97fc7f176f8bf501c9b3afd8410014e3b0e1602/core/src/main/scala/org/apache/spark/deploy/SparkSubmit.scala#L51)
needs to be updated from "The latter two operations are currently supported only for standalone cluster mode." to "The latter two operations are currently supported only for standalone and mesos cluster modes."

Can one of the admins verify this patch?

Jenkins test this please

Test build #52745 has started for PR 11600 at commit 104b505.

Sorry I just followed the rule. Your comment is applied now. Thanks a lot.

If the "what" and "how" are virtually identical, there's no point in making a JIRA.
"However, trivial changes, where the what should change is virtually the same as the how it should change do not require a JIRA. Example: "Fix typos in Foo scaladoc""

You are right !

Test build #52745 has finished for PR 11600 at commit 104b505.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/52745/
Test PASSed.

Merged build finished. Test PASSed.

Merged to master


[stable/eventrouter] Make eventrouter compatible with k8s >= 1.16

Is this a new chart
no
What this PR does / why we need it:
In kubernetes 1.16 apiVersion: apps/v1beta1 is retired now.
Snip from k8s CHANGELOG:

Continued deprecation of extensions/v1beta1, apps/v1beta1,
and apps/v1beta2 APIs; these extensions will be retired in 1.16!

Full changelog:
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md
Signed-off-by: Marco Kilchhofer<EMAIL_ADDRESS>Which issue this PR fixes
-
Special notes for your reviewer:
-
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[ ] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/assign @gianrubio

/ok-to-test

/assign

In the meantime someone else opened a PR for this:
https://github.com/helm/charts/pull/18673

/lgtm


Infinite circular menu

how to implement Infinite circular menu Spinning Wheel

This is not something that this project sets out to achieve. Really Sorry about that


BACKLOG-21467: Make JContent 3.0 compatible 8.2 only, nightly uses matrix. Changes test-reports name

JIRA

https://jira.jahia.org/browse/BACKLOG-2146
Description
Make JContent 3.0 compatible 8.2 only, nightly uses matrix. Changes test-reports name

should we also update parent version to 8.2? https://github.com/Jahia/jcontent/blob/master/pom.xml#L32

I did already


[Mono.Options] Fix typo in a few places.

Looks like it was copy-pasted across a few docs.

@patridge,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot


Enable config cache

1 problem was found storing the configuration cache.
- Task `:example-jvm:xuke` of type `io.github.chao2zhang.XukeTask`: invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/8.0.2/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution

5 problems were found storing the configuration cache, 1 of which seems unique.
- Task `:example-jvm:xuke` of type `io.github.chao2zhang.XukeTask`: invocation of 'Task.project' at execution time is unsupported.
  See https://docs.gradle.org/8.0.2/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution


Exposing private utilities to helpers for helping with other JOSE related tasks

Implementing a strict OAuth2 workflow is made very easy with this library. I have found myself extracting parts of the code in order to help with code_challenge generationg and JWK/JWKS related tasks.
Making the private utilities a part of the API will help other users of this library.

CI seems to be having issues today =S

@Thalhammer if you get the chance, can you please take a look at this PR :smile:

Would be you be able to make a new release? Maybe a v0.4.0 since all the CMake changes :heart:

Normally changes only to the build system would not be a reason to to a version bump, however as there have been quite a few changes to the headers as well in this and other PRs I dont see a problem with doing a new version.

Thank you so much! As you know it's much easier to track versions then commits


Fixed dry-run issue with kprove on Haskell Backend

Can we just return early on dry run instead of making the indentation level bigger?

Done that. I also did it to the execute and search methods. nothing else changed. please re-review.


What about i18n localization?

Is there an existing issue or pull request for this?

[X] I have searched the existing issues and pull requests

Feature description
I absolutely loved your framework, it's so much better and clearer than discord.js.
I would love to help the project! But I am still a novice programmer, but I know two languages: English (USA) and Russian (native speaker).
I would like to translate documentation, I have already had experience in translations, so I would like to contact you about it. What do you think?
Desired solution
i18n.
Alternatives considered
i18n.
Additional context
i18n.

Thank you! Have a great day/night,


[BUG][PySpark] Vacuum operation is too slow on very large delta table in S3

Bug
Which Delta project/connector is this regarding?

[ ] Spark
[ ] Standalone
[ ] Flink
[ ] Kernel
[X] PySpark

Describe the problem
We are using Delta Lake version 2.1.0 (in a Glue 4.0 job) to write data to a Delta table in S3. However, this has resulted in many small files (~15 KB each) across 27,000 partitions, with each partition containing about 50 files. While compacting some partitions has been straightforward, the vacuum operation is taking over 6 hours, even with a G2X configuration and 40 workers since vacuum runs across all the partitions.
I’ve explored the following options but need further guidance due to limited PySpark documentation:

Inventory File Feature: I couldn’t find clear PySpark documentation on how to use this.
Parallel Delete Configuration: I found the setting spark.databricks.delta.vacuum.parallelDelete.enabled=true, but since we’re not on Databricks, I’m unsure of the equivalent for PySpark.
Vacuum Lite Operation: I came across this option but need clarification on how to use it.

We’ve recently migrated to Glue 5.0, which supports Delta Lake 3.2.1. As a result, new tables will use version 3.2.1, while older tables remain on 2.1.0. I’d appreciate suggestions for handling this scenario in both versions.
Steps to reproduce

Observed results
delta_table.vacuum(24) taking more than 6 hours for very large delta tables with too many small files
Expected results
delta_table.vacuum(24) taking less than 15-20 minutes or option to execute vacuum only on certain partitions
Further details

Environment information
Both the environments listed below
1 -->

Glue version: 4.0
Delta Lake version: 2.1.0
Spark version: 3. 3
Scala version:

2-->

Glue version: 5.0
Delta Lake version: 3.2.1
Spark version: 3.5.2
Scala version: 2.12.18

Willingness to contribute
The Delta Lake Community encourages bug fix contributions. Would you or another member of your organization be willing to contribute a fix for this bug to the Delta Lake code base?

[ ] Yes. I can contribute a fix for this bug independently.
[ ] Yes. I would be willing to contribute a fix for this bug with guidance from the Delta Lake community.
[ ] No. I cannot contribute a bug fix at this time.

I figured out that we can use spark sql to use inventory table. However I am thinking if we can read json file corresponding to recent compaction in delta table myself (read the file in _delta_log directory), identify the files removed and pass them to inventory. I am not sure if this is a good approach but this can make vacuum much faster given we are vacuuming only the files that have been touched in certain versions


feat: add airflow.kubernetesPodTemplate.extraInitContainers

What does your PR do?
Added extraInitContainers to Pod template
Checklist

[x] Commits are signed
[x] Commits are squashed (only do this if appropriate)
[x] Chart version bumped (only do this if releasing a new version)
[x] Chart documentation updated
[x] Passes linting

Hey @thesuperzapper @gsemet  , is there anything else I need to do to get this merged?

@jmcgrath207 thanks for your work!
I will put this in the 8.6.0 milestone (as it adds a new value).

@jmcgrath207 do you still have time to apply the changes needed to address comments in https://github.com/airflow-helm/charts/pull/446#pullrequestreview-832165840?


Add high cardinality requirements doc

This is start at a requirements doc for #7151.
cc @benbjohnson @e-dard @pauldix

👍

Should also be able to show tag keys by measurement and be able to show tag values by key and measurement.

In terms of the performance we should probably have a reference machine/architecture that we expect to meet the targets on.

The perf targets are tricky. Might be easier to quantify other things than length of time for startup or query planning.
Like, query planning shouldn't require sorting anything (i.e. things should already be in sorted order). Or, if planning a query against a section of the index that is cold, it shouldn't require more than N disk seeks (for some value of N that makes sense).
Likewise, startup shouldn't require more than opening the file handles for TSM and index files and reading the WAL to load up in memory structures. Then also say that the WAL should be no larger than M bytes, which would be the thing that impacts startup time.

The performance targets are high level requirements that would meet a users needs. They should be verifiable through testing to determine if we are meeting them or not.  I think latency targets for startup make sense because that directly affects the end user (See #6250).    I'd rather not have them too specific to how the index is implemented as this document will drive design ideas.

There isn't anything in this document around renaming measurements, tags or values. I know it's not specific the problem we're trying to solve, but it might be worth being sympathetic to making this possible in the future when thinking about implementation. Just a thought.

@e-dard That's a good point, but I think that could broaden the scope too much.  Renaming also affects the TSM file indexes.

One thing we may want to add later to the query language is a starts with type query for measurement names and tag values. The only matching we have now is against regex, which is very inefficient since it has to scan all possible values.
Starts with is quite useful for doing auto-completion inside of a UI and those can be optimized much better than regex matches.

We could also rewrite simple regular expressions with a trailing .* to STARTS WITH queries automatically.

LGTM :+1:

One other thing I think we might want to add to this. For finding series, measurements, tag keys and tag values, we may want to have some method for returning a list on some rough period of time.
For example, if a user keeps their data around for a long time and they have a bunch of hosts or docker container IDs that are old, often they'll probably only want to return the set of items that have been written to in the last 24 hours.
Or if they're going back in time they wouldn't want to see everything for all time, just the relevant entries for that time range.
I don't think it needs to be down to the second accurate. Even 24 hours would probably be good enough. Just to narrow the space of items that show up. If accuracy is needed then the underlying series could be queried to see if they have data in that range.
What you guys think?

No further action specific to the 1.3 milestone. Closing this issue. We will track ongoing TSI work separately.


There are no commands defined in the "baum" namespace.

I installed Baum, and added it to config/app.php like so: Baum\Providers\BaumServiceProvider::class,
But when running the command "php artisan baum:install Thing2"
I get:

[Symfony\Component\Console\Exception\CommandNotFoundException]
There are no commands defined in the "baum" namespace.

Update: When trying to install Baum on my Macbook, it all worked like a charm. But on my Mac Mini it doesn't work... Weird huh : )

$ php artisan config:clear

Yep, same issue here with laravel 5.5.
Any solutions?
@mirzate php artisan config:clear doesn't help.


fix(Screensharing): Fix #41

Imma just merge it, it is tested and there is no harm in fixing bugs /shrug


useTableColumns.setActiveColumns doesn't allow column order to be set

Link to reproduction
No response
Environment Info
Paylaod: 3.0.0-beta.104
Next: 15.0.0-canary.104

Describe the Bug
In v2, useTableColumns.setActiveColumns respected the order of the columns that were passed to the function. In v3, the function only toggles columns on and off, but leaves the columns in it's previous order. This is a breaking change, and there is no longer a easy way to reset the columns to it's initial state.
It would be nice if the functionality of the function was kept as v2, or in alternative, we could add a function to reset the columns to the default state?
Reproduction Steps
"use client";

import { Pill, useListInfo, useTableColumns } from "@payloadcms/ui";

function ResetDefaultColumnsButton() {
  const { collectionConfig } = useListInfo();
  const { setActiveColumns } = useTableColumns();

  function handleOnClick() {
    if (collectionConfig?.admin?.defaultColumns) {
      setActiveColumns(collectionConfig.admin.defaultColumns);
    }
  }

  return <Pill onClick={handleOnClick}>Reset to default columns</Pill>;
}

export { ResetDefaultColumnsButton };

Adapters and Plugins
No response

Will be added with https://github.com/payloadcms/payload/pull/8296


Improve integration test suite

Improve the test suite in axes.tests.test_login; at the moment it's quite crufty and hard to read.
The tests need to be easily runnable for any new handler, and at the moment running them all for both the cached and database handler are harder than necessary.

Hey crew, I'll start working on this one.


Missing parent: [GO:0045815]

GO term ID and label for which you request a new superclass

GO:0045815	epigenetic maintenance of chromatin in transcription-competent conformation does not have a parent to any chromatin organization/remodelling term

New superclass (parent) suggested

chromatin organization/  or chromatin remodelling ?

@colinlog do you agree with this?


[LLVMGPU] Allow GPUReuseSharedMemoryAllocs to consider nested allocs.

This commit will consider all the shared memory allocs in the function, however while keeping the restrictive nature where it considers liveness on ancestor ops in the root block of the functions.
For e.g., this would allow allocs within a scf.for op to be reused with allocs in the root block.

@Max191 @qedawkins please take a look when you have some time..
I thought this is fine to do but I could be wrong..
Here Im doing a minor bump in the scope to capture all allocs and IIUC, it only considers the ancestor ops in the root block.
Thus, it would allow the cases Im interested in working for attention cases.
Note: it would still function in the root block just that it will try to consider all the allocs in nested regions as being used by the ancestor op.

This should be fine, but there might be a simpler solution. There's not actually such a thing as allocating shared memory, before lowering to LLVM we need to bound all allocations and convert them into globals. As a result, it should be fine to just move HoistSharedMemoryAllocs before this pass and then we don't need to change the logic here (and have to reason about allocations escaping their scope).

From my quick skim, HoistSharedMemoryAllocs is a rewrite -- currently.
Do you think it should made into a pass ? or do you mean to say we should call the pattern in this pass ?

Sorry I was being approximate with the pass name. I was referring to HoistStaticallyBoundAllocationsPass and thinking we can just call that pass before this pass.

@qedawkins thanks for the suggestion!
yes, the two passes together does what I want here.. I just renamed the PR to be just adding tests to make sure this behavior is maintained.
when you have some, can you take a look?


auth: Expect name in request params in Apple auth.

The name used to be included in the id_token, but this seems to have
been changed by Apple and now it's sent in the user request param.
https://github.com/python-social-auth/social-core/pull/483 is the
upstream PR for this - but upstream is currently unmaintained, so we
have to monkey patch.
We also alter the tests to reflect this situation. Tests no longer put
the name in the id_token, but rather in the user request param in the
browser flow, just like it happens in reality.
An adaptation has to be made in the native flow - since the name won't
be included by Apple in the id_token anymore, the app, when POSTing
to the /complete/apple/ endpoint,
can (and should for better user experience)
add the user param formatted as json of
{"email"<EMAIL_ADDRESS>"name": {"firstName": "Full", "lastName": "Name"}}
dict. This is also reflected by the change in the
native flow tests.
CC @gnprice @chrisbobbe

Merged, thanks @mateuszmandera!


CVE-2021-44228 - log4j vulnerability

https://github.com/gbif/ipt/blob/fc2db92e4422d1aec9d5eba577cbbf80efc3e65a/pom.xml#L73
References:

https://github.com/apache/logging-log4j2/pull/608
https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

Please consider merging https://github.com/gbif/ipt/pull/1698.

Thanks @frafra , those are merged now

@mike-podolskiy90 is the vulnerability exploitable by unauthenticated visitors? Is next release coming soon?
Thanks

@LocoDelAssembly We didn't have time to analyze how it affects the IPT. Anyway the new version is already available with fixes https://repository.gbif.org/content/groups/gbif/org/gbif/ipt/2.5.4/ipt-2.5.4.war, we'll announce it soon.

@mike-podolskiy90 Are you planning a release with log4j 2.17 any time soon?

https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/
https://www.zdnet.com/article/apache-releases-new-2-17-0-patch-for-log4j-to-solve-denial-of-service-vulnerability/

Hi @pieterprovoost , it's been already released, announcement is coming soon

https://github.com/gbif/ipt/issues/1708

Great, thanks!


Setting Fan Mode and Swing Mode does not work in FAN and DRY modes

Problem/Motivation
Starting with release 2024.7, Home Assistant supports setting the Fan Mode and Swing Mode for Tado AC Controls. But changing the Fan Mode and Swing Mode in HA does not work in FAN and DRY modes. As @EtienneSOU mentioned in https://github.com/home-assistant/core/issues/95389, the cause seems to be this library.
Expected behavior
Setting Fan Mode and Swing Mode does also work in FAN and DRY modes
Actual behavior
Setting Fan Mode and Swing Mode does not work in FAN and DRY modes
Steps to reproduce
Try to set Fan Mode and Swing Mode while running in FAN or DRY mode
Proposed changes
Add support for setting the Fan Mode and Swing Mode while running in FAN or DRY modes
Please consult issue https://github.com/home-assistant/core/issues/95389 for further details.
Thank you so much!

Thanks for reporting, this library is still in development and not yet actively used within Home Assistant. It will in time and this will be announced.
Your described issue is thankfully already picked up by Etienne in: https://github.com/home-assistant/core/issues/121120#issuecomment-2216903797.

@erwindouna
This will handle all the different fan modes?
I can test if you guide me through how to install the testing version.

Update: Bug still present in HA Core 2024.8.

Sad


Component should error when missing required variable

My employer had seen a post for this on react-intercom and decided to give it a shot.  Glad to see someone with an actively-maintained project for this!  However, I ran into a slight issue during my migration.  I couldn't figure out why for the longest time...until I realized that I was using a capital "D" in "appId", rather than a lowercase one.  It would have helped to have been alerted that app ID is missing.

@vinyldarkscratch Thanks for your suggestion. I'll definitely integrate your request in the next version.
I would suggest to make use of the out of the box autocompletion :). Or migrate to TypeScript, this
kind of problem would give you a compilation error when you're not using the correct properties.

Awesome, thank you!  A migration to TypeScript will be most likely impossible for the size of the project, but I'll be sure to pass along the idea of the autocompletion.  :)
P.S. you'll probably be seeing some PRs coming your way soon from yours truly!


[DRAFT] Switch to cilium/statedb

This PR removes pkg/statedb, pulls in cilium/statedb and fixes up StateDB usage in few places as cilium/statedb had evolved a bit.
Here's a summary of changes:

Remove pkg/statedb
Vendor cilium/statedb
Remove the StateDB Swagger API endpoints in favor of StateDB's built-in HTTP handler
Add the StateDB handler under /statedb/ in the UNIX socket HTTP API
Fix up uses of StateDB reconciler (StatusPendingDelete is gone, WithStatus is now SetStatus+Clone)
statedb.NewDB is now statedb.New
DeleteTracker() is now Changes()
Add metrics implementations for StateDB and the reconciler. Minor change to metrics, "package" label is now "handle" (extracting the package name with runtime.Callers was way too expensive). The metrics have been disabled by default and there should be no users yet depending on stability of the metrics.
Add module provider for statedb.Handle. Using statedb.Handle instead of *statedb.DB will account metrics to the module id instead of the generic "DB" handle.

The major change in cilium/statedb is the switch to an adaptive radix tree from go-immutable-radix which doubles the performance of StateDB and reduces memory usage.

/test

/test


Ocaml list-ops tests always time out

Even with the reference solution. It seems the resource limit in the worker is not sufficient to run the big tests. Either the tests should be made smaller or the worker limits should be raised.
https://exercism.org/tracks/ocaml/exercises/list-ops/edit

Just check the test.ml and found the List.range. Do we have this function in module List? ref


FIX Invoke method addHeader on NULL

Description
Check that $controller->getResponse() is not NULL before invoke addHeader on it.
Parent issue

https://github.com/silverstripe/.github/issues/162

This issue happens now only in CI and related to this PR.
I just might assume that something happens in mock controller.

Sorry I mean can you link to the broken build in CI?

Better to fix on ckan registry directly.  Closing this PR in favor of https://github.com/silverstripe/silverstripe-ckan-registry/pull/305


Fix errors and typos

In example in the line 25 of StyleJit class the function renderStyle is defined in StyleJit class and it should be called as self::renderStyle or as StyleJit::renderStyle.

Also make a test hehe


Always allow strict comparisons and Coalesce, forbid everything else

Hi, here the instructions to review this PR efficiently:

First commit https://github.com/voku/phpstan-rules/commit/fd9e7cc1cf96306cfcf499db149b923d19adc60b only splits logic into separate methods so we can leverage Replace Nested Conditional with Guard Clauses, as if were going a bit too crazy
Second commit does the topic: === and !== are always safe as far as I can tell, no way they can return true if not intended by programmer; in the same category falls ?? operator
Third commit https://github.com/voku/phpstan-rules/commit/84543c8f713b0503923be14b4afcb0ebe4bb201b describe the variable/object that triggers the error, as I sometimes wandered if the culprit is the left or right part, and I also need to know what PHPStan knows about the variable
Fourth commit https://github.com/voku/phpstan-rules/commit/e7fe71927510cf6df4b0f6e32e554019f68bb3d2 allow loose comparison between DateTime/DateTimeImmutable objects as PHP knows how to do it properly (see php_date.c#L1663 and php_date.c#L1671) but only when type is certain: no nullable allowed as per https://3v4l.org/dOiTf#v8.1.5

Following this refactor, now both left and right parts of a binary op raise and error if both should be make explicit, this is intended and adhere to PHPStan similar rules.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

66 of 72 (91.67%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+3.5%) to 76.582%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/voku/PHPStan/Rules/IfConditionHelper.php
66
72
91.67%

Totals

Change from base Build<PHONE_NUMBER>:
3.5%

Covered Lines:
121

Relevant Lines:
158

💛  - Coveralls

Thanks for this more strict checks and for this excellent PR description. :+1:


Vuepress vulnerabilities

remote: Resolving deltas: 100% (6/6), completed with 6 local objects.
remote:
remote: GitHub found 11 vulnerabilities on heig-tin-info/baygon's default branch (4 high, 5 moderate, 2 low). To find out more, visit:
remote:      https://github.com/heig-tin-info/baygon/security/dependabot
remote:

Perhaps migrate to Nuxt?

Fix in 5b9e3e8


bug-fix: patched dir owned by runner

in relation to:
https://github.com/summerwind/actions-runner-controller/issues/283

commit e719724 added so that images are always built using the latest possible actions/runner release.
could be nice to build this daily so no need to keep bumping the version


Add configuration for enable/disable linters.

Fixes #408 #399

@itowlson Comments addressed, revereed from 'enabled' to 'disabled' which feels cleaner.
Please take another look.

Comments addressed, please take another look (after the holidays of course :)
Thanks!


Now button broken

This fixes an issue we saw where pressing the "now" button multiple times causes the timezone to shift to an incorrect value.

Sorry, I know this has been quite the delay. Thanks for posting your fix, however it seems to cause an issue with this commit applied:
https://github.com/trentrichardson/jQuery-Timepicker-Addon/pull/887/commits/6b9c57689df355fd3e0fe3a6a062bffea29ad4a3
The first timezone example does not work in the docs. Here is how to reproduce:

click the input, choose a time, and change the timezone
close the picker by clicking Done
click the input to open the picker. The timezone dropdown is blank (it should be the timezone chosen in step one)

For now I have left this fix out of dev.


fix: Filter names overflow wrap

SUMMARY
Fixes a problem with the overflow wrap of filter names.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
https://github.com/apache/superset/assets/70410625/927989cd-a3a6-4e95-80d5-3b68a14e9fa2
https://github.com/apache/superset/assets/70410625/8055d8a7-e609-4b0e-b2c0-fd72c6f64d04
TESTING INSTRUCTIONS
Check the videos for instructions.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

The problem is that the FilterCard is already a tooltip and if we truncate the metric name we can't identify the metric.

I think this was the behaviour before the regression with overflowing title:

(added max-width: 100% to parent component to trigger the overflow). Could you elaborate why that won't work?

I thought we were avoiding tooltip on top of tooltip but it seems that's not the case given that Depend On will also show a tooltip. I'll add max-width: 100% to keep the previous behavior.

I thought we were avoiding tooltip on top of tooltip but it seems that's not the case given that Depend On will also show a tooltip. I'll add max-width: 100% to keep the previous behavior.

I think we treat FilterCard more like a popover and given it has very different styling than a tooltip it's ok for us to use both here

@kgabryje I roll back FilterCard to its previous behavior with the addition of overflow:hidden. max-width does not respect FilterCard's padding. Now it looks like:

@kgabryje I roll back FilterCard to its previous behavior with the addition of overflow:hidden. max-width does not respect FilterCard's padding. Now it looks like:

Great thank you! It seems unrelated to your fix, but the behaviour of displaying the tooltip seems flaky - when I open a filter card for the first time, the truncated title shows tooltip on hover, but when I close the filter card and open it again the tooltip doesn't appear anymore. Let's keep that in mind to fix it soon


GCP: Image

Use operating system images to create boot disks for your instances. You can use one of the following image types:
Public images are provided and maintained by Google, open-source communities, and third-party vendors. By default, all projects have access to these images and can use them to create instances.
 You can create a custom image from boot disks and other images. Then, use the custom image to create an instance.

API
https://cloud.google.com/compute/docs/reference/rest/v1/images

InstanceAttachedDiskInitializeParams should be updated to include sourceImage field when done.

Image should be added to Disk (#21) when it is implemented.


Run EXE without Debugging

I know many people want this. Its strange that still you cannot do it.
I have found a workaround.
This assumes you already compiled your exe.
Install Love2D launcher, which is used to launch love2d, and point at your exe file.
Assuming you will use the same exe file for the whole project this is a project-specific work around.
And honestly, its sad there is no way to do this otherwise.

/needsMoreInfo


Improve demo user feature

The demo user feature needs some changes...

[x] Mark the automatically generated demouser with "isDemoUser"
[x] Make it impossible to change password
[x] Do not persist clicking away the "Hints"
[x] Find a way that the admin can disable the demo user via settings

Closed with 052eb87323380977a5479355bc32425bea8ed941

Closed with 052eb87323380977a5479355bc32425bea8ed941


skip zip compression tests in certain environments

motivation: stable ci
changes: skip new zip compression tests where setting the process working environment is not supported

@swift-ci smoke test


Use MSYSTEM_PREFIX

Hi @Chocobo1, thx for the great GH action.
This line:
https://github.com/Chocobo1/setup-ccache-action/blob/8856534dac357009109dfd78c66a872bd81d03a9/src/utils.ts#L72
should be? MINGW_PREFIX or MSYSTEM_PREFIX:
return ${Process.env.MINGW_PREFIX}/lib/ccache/bin;
Currently, it is ${Process.env.MSYSTEM}, so the path will be /UCRT64/lib/ccache/bin.
With MSYSTEM_PREFIX it will be /ucrt64/lib/ccache/bin.
I think that the MSYSTEM env. variable is not supposed to be used in paths, that is why MSYSTEM_PREFIX exists.
Here is source where it is defined and link to all occurrences.
Later: Also when I looked at GHA output log I have found two more cases where this upper-case UCRT64 is used:
Clear ccache statistics
Prepend ccache symlinks path to $PATH
  ccache symlinks path (msys): "/UCRT64/lib/ccache/bin"
  (msys) PATH=/UCRT64/lib/ccache/bin:/ucrt64/bin:/usr/local/bin:/usr/bin:/bin:/c/Windows/System32:/c/Windows:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0/:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
Create environment variables
  ${{ env.ccache_symlinks_path }} = /UCRT64/lib/ccache/bin

So it should be changed for env.ccache_symlinks_path output variable and in prepend path too.
I'm not sure what is the difference between MSYSTEM_PREFIX and MINGW_PREFIX, or which one should be used when 🙂, if you want I can ask at the msys2 issue tracker.

Hi @Chocobo1, thx for the great GH action.

You are welcome.

should be? MINGW_PREFIX or MSYSTEM_PREFIX:
return ${Process.env.MINGW_PREFIX}/lib/ccache/bin;

That probably would be good, applied in 243d0770d62dcff499105d7b2c4e35fa0f6b53d8.

I'm not sure what is the difference between MSYSTEM_PREFIX and MINGW_PREFIX

Looks like MINGW_PREFIX is just an alias for MSYSTEM_PREFIX.
Also note that the msys testing CI is broken currently and I have no idea what caused it, it was working fine a few days ago. Last working instance: https://github.com/Chocobo1/setup-ccache-action/actions/runs/1458477952
I tried to replicate locally but it fails to show the symptom, i.e. it was working fine locally.
So msys support currently is in a perverted state and I cannot fully guarantee that it is working...

Thank you, for the patch.
I have setup it yesterday and it works for me, invoked like this:
    - name: ccache setup 🕺
      uses: Chocobo1/setup-ccache-action@v1
      with:
        windows_compile_environment: msys2
        prepend_symlinks_to_path: false
        install_ccache: false
        update_packager_index: false
        ccache_options: |
          compiler_check = %compiler% -v
          compression = false
          max_size = 3G

We will see, I don't know why it is failing when I have a problem like, then I use this after failing action:
    - name: Setup tmate session
      uses: mxschmitt/action-tmate@v3
      with:
        limit-access-to-actor: true

    - run: exit 1

Then ssh into the runner and try to invoke commands directly in the runner, but it looks like that fail exits the whole job so what I'm writing above will be useless for you.

I have setup it yesterday and it works for me, invoked like this:

Seems you skipped all possible failing points (by accident?), good for you.

We will see, I don't know why it is failing when I have a problem like this, then I use this after failing action:

Thanks! I'll take a look when I got the time.

Seems you skipped all possible failing points (by accident?), good for you.

That is true, I'm installing ccache myself, I'm not using prepend_symlinks_to_path because cmake has a problem with ccache wrappers when I use ninja.
So I'm practically using only caching capabilities of ccache's cache dir 😂 from this action and I also like output statistics.

It seems msys2 has done some update, now I can properly test my code.
And I found out that need to revert some of my changes and that includes declining/reverting what you suggested here. The reason is that MSYSTEM_PREFIX is only available within msys2 shell and not in the shell that setup-ccache-action is using.
Here you can see MSYSTEM but no MSYSTEM_PREFIX: https://github.com/Chocobo1/setup-ccache-action/runs/4392064323?check_suite_focus=true#step:4:90

Ok, thank you for info, it does not matter at the end of the day.


Quoted CRs in CRLF file incorrectly result in validation errors

So e.g.
"Foo","Bsr","Baz"^M
"Biff","Baff","Boff
"^M
"Qux","Teaspoon","Doge"^M

…results in:
$ csvlint test.csv
.!.
test.csv is INVALID
1. unclosed_quote. Row: 2. "Biff","Baff","Boff
"

According to the RFC 4180, though, I think this should be fine.

By default, the type of line endings used are auto-detected:
https://github.com/theodi/csvlint.rb/blob/873617f5/lib/csvlint/validate.rb#L302
…but the CSV is parsed row-by-row:
https://github.com/theodi/csvlint.rb/blob/873617f5/lib/csvlint/validate.rb#L182
So in the case described above, auto-detect gets it wrong.
irb(main):001:0> require 'csv'
=> true
irb(main):002:0> # load the data above
irb(main):003:0* contents = ["Foo,Bsr,Baz\r\n", "Biff,Baff,\"Boff\n", "\"\r\n", "Qux,Teaspoon,Doge\r\n"]
=> ["Foo,Bsr,Baz\r\n", "Biff,Baff,\"Boff\n", "\"\r\n", "Qux,Teaspoon,Doge\r\n"]
irb(main):004:0>
irb(main):005:0* # try to parse the second row, auto-detecting line endings
irb(main):006:0* CSV.parse_line(contents[1] + contents[2], {:row_sep => :auto})
CSV::MalformedCSVError: Unclosed quoted field on line 1.
  from …/csv.rb:1872:in `block in shift'
  from …/csv.rb:1779:in `loop'
  from …/csv.rb:1779:in `shift'
  from …/csv.rb:1310:in `parse_line'
  from (irb):6
  from …/irb:11:in `<main>'
irb(main):007:0>
irb(main):008:0* # try to parse the second row, manually specifying '\r\n' line endings
irb(main):009:0* CSV.parse_line(contents[1] + contents[2], {:row_sep => '\r\n'})
=> ["Biff", "Baff", "Boff\n"]

I guess the solution would be to set row_sep to @line_breaks or something like that.

Ah yes, @jenit and I were discussing this the other day, and we wondered if it was because of mixed line breaks as you've found. I think your solution will probably work; I need to check what the line-break behaviour inside quotes should be as well.

I realised I should be explicit that parsing the whole thing with auto-detect line endings switched on works fine:
irb(main):009:0* CSV.parse(contents.join, {:row_sep => :auto})
=> [["Foo", "Bsr", "Baz"], ["Biff", "Baff", "Boff\n"], ["Qux", "Teaspoon", "Doge"]]

So this is only an issue when parsing row-by-row.

I have run into this same issue or a very similar one. Behavior of Csvlint and stdlib CSV parse documented here. (Test structure described here)

The contributing guidelines say: "Before you start coding, please reach out to us either on our gitter channel or by tagging a repository administrator on the issue ticket you are interested in contributing towards to indicate your interest in helping."
I am not finding a list of the repository admins, and apparently I need push access to a repo to get that info from GitHub API, so I'm making assumptions based on who has merged all recent PRs and tagging @Floppy here to indicate that I'd like to attempt a fix for this issue.
Rationale/use case/background:
We use csvlint in a batch data import application to validate user-generated CSVs before allowing import of data in the files. Using csvlint to prevent the import of CSVs with issues like ragged rows, invalid encoding, and stray/unclosed quotes is important to prevent clients from inadvertently loading malformed data.
This issue is currently blocking some of our clients from importing valid CSVs with mixed EOL characters inside quoted values (an artifact of original data source, and what OS they used to prepare the data, apparently). If you export data from our application as CSV on a Windows machine for roundtripping via our import tool, you get mixed EOL characters and can't re-ingest the data because csvlint flags the CSV as invalid. Our users are primarily collection managers in GLAM institutions, not data wrangling/tech savvy people; they are going to tune out/give up if anyone starts explaining CR, LF, vs CRLF to them.
Mixed EOL characters are handled fine by the standard Ruby CSV library, and are not prohibited by RFC 4180 according to my reading, so csvlint flagging these as invalid needs to be fixed.

Hey, I solved this in two different ways, which can be examined here: https://github.com/kspurgin/csvlint.rb/pulls
I prefer PR2 as it feels more expressive of the actual problem, and less hacky than the other.
From what I can tell, the root of the problem is: once we are at Validate.parse_contents, we have already gotten the item of interest down to a single line of the CSV. But we then call LineCSV on it, passing the row_sep: :auto option in many cases. LineCSV subclasses CSV, whose Parser does a terrible job determining the proper row separator from a single line if there are EOL characters inside quotes.
If you let me know which of these is acceptable (if either is), I'll do a real PR with better commit messages.


"Draw Circle" function doesn't correctly handle out of bounds pixels.

When trying to call draw_circle and parameters in which include pixel coordinates outside of the screen, nothing is draw.
We should draw the circle's pixels on screen, regardless of location, assuming it actually has pixels inside of the screen.

now that draw_circle_filled exists I wonder if this issue also exists for it.

@RobDavenport, Yup, it does.
I think that solving the problem pointed out in #3 might solve this one here as well (this will be my next PR probably).
I'll take a closer look at the code base, as I'm not that familiar with it yet.

@Cardosaum , actually, draw horizontal and vertical already handle bounds checks. So in the cases where a draw_line is called with a perfectly vertical or horizontal one it works.
You can test this by doing a moving pixel where you move the end point (like a character) and put it at various points off screen.
I think the issue with draw circle is the radius is incorrect being clamped, so when a circle is drawn near the edge, it shrinks the radius.


TD-38 Account Recovery Has Been Setup

You can now change your password on the sign in page. Click on the button and follow the steps to receive an email to reset your password. The email will be send to the email address you have on your profile. Note that you can use the same password, and you can use previous passwords since the old passwords that where used are not tracked.

What was the website you used to generate temporary email addresses?

I have pushed a new commit for the updated changes, let me know if there is anything else.


Remove PMML processor coordinates from the bit.ly links

As a developer, I'd like to remove pmml processor coordinates from all the statically served bit.ly links including the SNAPSHOT/released files - we may have to manually edit the released property files.
Acceptance:

processor.pmml=maven://org.springframework.cloud.stream.app:pmml-processor-kafka:1.0.2.RELEASE is removed from all the static files
PMML processor README is updated with a note stating the license concerns and how to build/register the artifact for use
Update PMML sample to point to the new docs section

Honestly, I think you're going in the wrong direction here.
As a developer, you need to worry about functional dependencies. Your documentation (or hyperlinks to the said documentation) cannot be functionally dependent on my AGPLv3 library (unless you've copy&pasted library code to your documentation).
Yet, you have published application code that is functionally dependent on my AGPLv3 library, and released this Covered Work under AGPLv3 incompatible license - effectively restricting its freedom. As a side note, you cannot solve functional dependency simply by excluding JAR files from the distributable (and ordering end users to download them manually from someplace else such as the Maven Central repository).

@vruusmann: The pmml-processor has been move to spring-cloud-stream-app-starters/pmml and the repo in entireity is reclassified with AGPLv3 license. Please refer to the README for more details.


Standard Solver Concern

Noticed the standard solver is incredibly worse than a prebuilt macro, it's even skipping usage of great strides/byregots in some cases. Is this standard behavior or is there an issue?

If it's skipping GS/Byregots, it tells me your cutting it really fine with your CP since there's 2 conditions for the solver to use these.

If it will finish the quality, it will check if the combo of GS & BB will complete the remainder of the quality and if so, carries out the combo.
If you would run out of CP before using BB. The solver will pick a recommendation first and then do a follow-up check to see if using it will take you under the CP for BB, and if so will switch to using BB instead.

This second one is likely where your problem lies, since if the action would be Master's Mend, it has to use that or you'll fail, so if repairing takes you under BB CP range, it's unfortunately skipped.

Solver seems like its forcing itself into situation #2 and never considering #1, appears to be aiming to use BB alone to boost quality as much as possible as mentioned.
Gear wise I would not expect to have issues, as they're fairly easy to top quality with a static macro. Typically getting full quality even before GS/BB.

It's not really "forcing" itself into situation 2, that's just the way the craft might end up with the resources it has left. Standard crafts will only use one BB, so it tries to get as much value out of it as possible so will put it off until it's able to finish the quality or the next action would normally run out of CP for it. This isn't a problem until you land in an awkward position where the next action has to be Master's Mend but using that will put you under the CP for BB.
The solution to this is not going to be an easy one since it will require more foresight from the solver beyond just the current step. It would really have to assess the current step and assume the next one, and if that one is a mend step just BB and finish the craft instead. Not sure how long it will take me to logic this out but I have been aware it's a flaw of the solver currently.


Batch delete action snapshots

Microcosm master batch processes snapshots given a history range. We can do the same thing with removing snapshots. Basically, instead of:
_removeSnapshot(action: Action) {
  delete this.snapshots[action.id]
}

We could match the pattern for updating a snapshot range:
_removeSnapshotRange(source: Action, end: Action) {
  let focus = source
  while (focus && this.snapshots.hasOwnProperty(focus.id)) {
    delete this.snapshots[focus.id]
  }
}

There are two benefits:

History does not have to emit an action for every item it removes.
Microcosms can stop removing snapshots when they are out of snapshots

Implementation details have changed here.


backport: tests: keep same ceph release during handlers/idempotency test in stable-3.0

since latest points to mimic, we need to force the test to keep the
same ceph release when testing anything else than mimic.
Signed-off-by: Guillaume Abrioux<EMAIL_ADDRESS>(cherry picked from commit 21894655a7eaf0db6c99a46955e0e8ebc59a83af)

jenkins test luminous-ansible2.4-bluestore_osds_container

jenkins test luminous-ansible2.4-bluestore_osds_container


Any way to manually fire 'dragstart' on sortable element?

Hey, bit of an interesting one; though I'm trying to figure out how I can manually trigger 'dragstart' without actually clicking and dragging on a draggable element.
My (simplified) use case is this:
Section 1: menu w/ list of icons

red square button
blue square button

Section 2: Sortable box for active elements

red square element
red square element
blue square element

Section 1 is a menu with various buttons. I can click one of these buttons and it will generate a coloured square element at the bottom of section 2, and refresh the sortable so the new element can be dragged.
What I'm TRYING to achieve is to be able to drag the square button icons, have it generate the element as being mid-drag and under the mouse so users can place it wherever they want inside the section. (bypassing the need to click, find / click & drag the new element, and then order it).
The way I'm thinking to achieve this is as follows;
1 > Section 1 icon button is clicked.
2 > New element is generated at the bottom of section 2
3 > Section 2 sortable is refreshed
4 > 'dragstart' event is fired for new element, and it appears under mouse
5 > user places it inside section 2 wherever they desire.
Steps 2 - 4 will happen instantaneously, so it will appear as if a user is clicks an icon and it transforms into an element placeholder on drag.
Any advice / thoughts would be greatly appreciated! If you have a better way of approaching this let me know :)

Hmm, I am not sure if this is possible. Technically you could trigger a dragstart event via jquery, but I am not sure how this will work out. Why can't you use an invisible element which the user drags and show it after a distance of X px?

Alright I'll look into the jquery method, I initially thought of doing something similar it just didn't seem "clean". On second thought I guess it would be possible to replace the dragged invisible element from the origin container on sortupdate, which isn't as hacky as I initially thought. Thanks for getting back to me!


Lint that imports are sorted

Adds the I ruleset to Ruff to make it emulate isort.

I forgot to mention in the description that this was stacked on top of #122 to avoid the inevitable merge conflicts, so I'll be holding off on merging this until #119 and #122 are through.


Automated Package Upgrade

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Added Insertion sort

What the program do ?
It performs Insertion sort algorithm.
In what programming language it is written?
Python 3

Addresses Issue - #33


Feature Request: Edge length taking into account the geometry of the street

AFAIK the edge attribute length (by using add_edge_length) computes the great_circle_vec between the origin node and the destination node. So it doesn't take into account the full geometry of the edge, only the first and the last nodes of the edge.
On the other hand, the length of a (shapely) LineString (edge["geometry"].length) takes into account the full geometry of the street, but the distance function is the Euclidean Distance or Linear distance between two points on a plane (And the result is not measured in meters).
I think It'd be nice to have a sort-of street_length (a function to compute great_circle_vec with the full geometry of the LineString). Maybe the running time is to long? I know that this new street_length attribute would take longer compared to the current length...
My first approach is the following (Based on answers from StackExchange and StackOverflow):
def street_length(line):
    """Calculate length of a line in meters, given in geographic coordinates.
    Args:
        line: a shapely LineString object
    Returns:
        Length of line in meters

    Source:
        https://gis.stackexchange.com/a/115285
    """
    # Swap shapely (lonlat) to geopy (latlon) points
    latlon = lambda lonlat: (lonlat[1], lonlat[0])
    total_length = sum(
        great_circle_vec(*latlon(a), *latlon(b)) for (a, b) in pairs(line.coords)
    )
    return round(total_length, 0)

def pairs(lst):
    """Iterate over a list in overlapping pairs without wrap-around.

    Args:
        lst: an iterable/list

    Returns:
        Yields a pair of consecutive elements (lst[k], lst[k+1]) of lst. Last
        call yields the last two elements.

    Example:
        lst = [4, 7, 11, 2]
        pairs(lst) yields (4, 7), (7, 11), (11, 2)

    Source:
        https://stackoverflow.com/questions/1257413/1257446#1257446
    """
    i = iter(lst)
    prev = next(i)
    for item in i:
        yield prev, item
        prev = item

PS: I started using osmnx a couple of months ago. So please correct me if I am wrong.

AFAIK the edge attribute length (by using add_edge_length) computes the great_circle_vec between the origin node and the destination node. So it doesn't take into account the full geometry of the edge, only the first and the last nodes of the edge.

Yes, but: in the OSMnx workflow when you call, for example, ox.graph_from_place, OSMnx constructs the graph, then calls add_edge_lengths, and then simplifies the graph. Prior to simplification, the graph edges are all straight-line approximations of curves, so add_edge_lengths estimates the true length of each segment. When simplification occurs, we sum those length attributes of the segments as we aggregate them into a single (curving) edge in the final graph.

(Sorry for my late reply...)
OK. I understand the workflow now. Thanks.
However, I still think it'd be nice to have a sort of street_length as explained above.
For example: I just started a project where I have to split streets constructed with ox.graph_from_place. I also have to add new streets.
So my first approach of re-computing the lengths again with add_edge_lengths didn't work because of what you explained above. I think I'll run the version of street_length (proposed above) to get the length of the new/modified streets. Please let me know If there is a better OSMnx-ic way to do it.

Yes this might be a useful addition for the use case you describe. But I also wonder if it would be more sensible for the function to expect a projected graph and then just calculate euclidean distances of the sub-segments?

OK. I understand the idea, but I have no experience in spatial graph projections...
(If you have time) Could you please elaborate on this?
Do you have any specific reference to start reading about it? Or link to a piece of code?
I'll look into it.

I think what you suggest is the euclidean_dist_vec instead of great_circle_vec but over a projected graph? If this is the case, I still don't know how to project the graph...
I'll look into it.

I still don't know how to project the graph...

I'd suggest reading through the OSMnx documentation and examples repo to get started.


Generalize functors to restricted functors

Functor is currently described as:
map :: Functor f => f a ~> (a -> b) -> f b

The fact that there's no constraints on a or b means this is a functor over the category of all types in JS: it maps a morphism between any two types a -> b to a morphism f a -> f b (and implicitly, any type a to the type f a).
In some cases, a type may exhibit the characteristics of being a legal functor over some universe of types, but not behave as a legal functor over every conceivable type.
For example, Promise#then can be used to form a legal functor over non-"thenable" types, and those types only. Consider the following implementation:
const map = f => x => x.then(f)

map(x => x * 2)(Promise.resolve(10)) // Behaves as legal functor, produces Promise containing 20

map(x => ({ then: () => x * 2 }))(Promise.resolve(10)) // Does not behave as legal functor

While Promise does not form a legal functor over morphisms between all types, as shown above, it certainly does form a functor over types that satisfy a constraint (in this case, x => !isThenable(x)).
If the Fantasy Land spec allowed formalization of "functor over the category of some types", many more types naturally occurring in JS could be instantiated as lawful functors/applicatives/monads and benefit from code that works with these abstract classes.
RFunctor could hypothetically look something like this:
class RFunctor (s :: * -> Constraint) f where
  rmap :: (s a, s b) => f a ~> (a -> b) -> f b

instance RFunctor NonThenable Promise where ...

The existing Functor class would simply be RFunctor for a choice of constraint that accepts all types.
The specification has a choice between simply making the behavior of rmap with respect to non-suitable morphisms undefined, or requiring implementers to provide a suitable :: a -> Boolean implementation which will be used to produce type errors for invalid morphisms.
Prior art:

https://hackage.haskell.org/package/rmonad.
https://hsenag.livejournal.com/11803.html

Not sure if @hsenag is active on here, but maybe he has some thoughts.

I'm afraid I'm gonna have to give this a 👎 simply because it contains the word "functor". We don't have constraints (let alone constraint kinds) in JS, and I think this opens us up to a lot of misinterpretation. For example, Promise isn't a functor, and it's something I have to explain fairly regularly - I think saying "it's an rfunctor" implies that rfunctor is somehow related to functor, which (in JS) it isn't.
I see where you're coming from, but I'm already worried when we start talking about promises or sets as "lawful functors/applicatives/monads", because they're simply not - as soon as you introduce constraints, you un-introduce "functor" :(

I'm afraid I'm gonna have to give this a 👎 simply because it contains the word "functor"

All that said, if the objection here is only to the naming, I'd be happy with any synonym you can think of to express the concept of functor over a subcategory of all types.

Just a brief comment for now - I remember trying to write an RFunctor in rmonad, and deciding it was too complicated/ugly. I can't remember the details but I think the constraints got quite hard to manage in practice.

/shrug I've said my bit: I worry about misinterpretation. Ultimately, though, this is up to the collaborators within this repository, so I'm the wrong person to be talking to :sweat_smile:


Use index.ts to export public API

It's common practice to use one index.ts file to re-export the public API of the libraries, so we can hide inner structure of the files from the outside world.
so instead of
import { Transactional } from '@liberation-data/drivine/transaction/Transactional';
import { PersistenceManager } from '@liberation-data/drivine/manager/PersistenceManager';

we will have this
import { Transactional, PersistenceManager   } from '@liberation-data/drivine';

Is there any reason Drivine is not doing this ?

The only reason is we haven't set it up yet, but arguably we should have when we released official 1.x.x stream.


Fixed wrong header concatenation

The new version of PRS7 2.2.1 header validation is stricter this commit solves the header validation problem.
Current:
Vary: Origin\n
X-Origin\n
Referer\n

Should be:
Vary: Origin, X-Origin, Referer

https://github.com/guzzle/psr7
More information about concatenation of headers:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary
See https://github.com/googleapis/google-api-php-client/issues/2230

Do you think adding a test or extending an existing test in Http/BatchTest.php will make sense?

Do you think adding a test or extending an existing test in Http/BatchTest.php will make sense?

Hey @vishwarajanand currently the testBatchRequest function already performs this test, if you run the test with guzzlehttp/psr7 (2.2.1) the test does not pass without this fix.

This will work but will break set-cookie. The keys should be passed as array instead and should not be concat

Hey @bshaffer the tests already handle the changes, if you run the tests with the latest versions of prs the batch tests will fail. This fix is to fix this problem. The main disadvantage without this fix is that the batch will not work anymore, because now prs only accepts sending headers concatenated with comma (,) and not with newline (\n)

@bshaffer this started not working with guzzlehttp/psr7 2.2.1 I believe when they added validation of headers as part of a security fix. According to the RFC the way the Google client is sending headers is not correct. See https://github.com/guzzle/psr7/issues/494#issuecomment-1076189381

Thank you for your work @felipehertzer  (and your explanation @ejunker). This looks great now.

@bshaffer any idea on when you can release this? Since it breaks a lot if implementations that use the PSR package

@pimjansen it's been reñeased in [v2.12.2](https://github.com/googleapis/google-api-php-client/releases/tag/v2.12.2


[Fixed #945] Position of scrollbar after activity is quit

@llaske , Fixed issue #945
Tested on browser and android mobile.
https://user-images.githubusercontent.com/42293606/115149960-fbc3b880-a083-11eb-97a2-705ef5e08e29.mp4

@llaske , made suggested changes. Please review.

@llaske made suggested changes

Good job.
It's a very cool enhancement.
Thanks.


Customdata was not executing my script using CAF

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Versions

terraform:
azure provider:
module:
Description
Describe the bug

Steps to Reproduce

step 1
step 2
you get it...

Screenshots

Additional context

Hi Team,
I am passing the commands in vm.tfvars customdata block but it is not executing. Could some one please assist

Hi please could you detail the configuration you are using? I don't understand what you mean by customdata and vm.tfvars

Issue was resolved.
I am talking about below custom_data configuration.
    disable_password_authentication = true
    custom_data = "../../singtel/level3/Ss/scripts/fs.sh"

Regards,
Madhulika
From: Matt White @.>
Sent: Wednesday, 13 March 2024 5:59 pm
To: Azure/terraform-azurerm-caf-enterprise-scale @.>
Cc: Madhulika Sarangam @.>; Author @.>
Subject: Re: [Azure/terraform-azurerm-caf-enterprise-scale] Customdata was not executing my script using CAF (Issue #912)
[CAUTION: External email] Do not click links or open attachments unless you recognize the sender and know the content is safe.

Hi please could you detail the configuration you are using? I don't understand what you mean by customdata and vm.tfvars
—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/terraform-azurerm-caf-enterprise-scale/issues/912#issuecomment-1993995618, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A6BXQH2A3SBLGF3SGVHKI4TYYAPNXAVCNFSM6AAAAABEO7CSQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJTHE4TKNRRHA.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>

Thanks, I don't think this pertains to this module. Nevertheless thanks for letting me know we can close the issue


Update calculateAttestationRewards in ChainDataProvider

fixes #6702
Documentation

[ ] I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

[ ] I thought about adding a changelog entry, and added one if I deemed necessary.

i'd probably not say we're updating ChainDataProvider...