text:
atexit issues with exceptions

I have to "reopen" the issue with the JVM shutdown again.
Partly to document an underlying problem which might help someone else with debugging, partly to enforce the importance to fix the current solution.
With the current setup, atexit calls .exit(0). This shuts down the python interpreter with exit status 0. Additionally, as
stated in the atexit docs:

If an exception is raised during execution of the exit handlers, a traceback is printed (unless SystemExit is raised) and the exception information is saved. After all exit handlers have had a chance to run the last exception to be raised is re-raised.

Thus, any exception raised by actually ANY code after importing client will be printed, however is lost afterwards. A standard use case at least for me is building python script which then runs a model by loading, doing some adaptions, solving etc...Another case would be even running a script using subprocesses.
In both cases neither stderr nor the exit code are set. This is quite drastic...
Have you had an issue running on jpype regarding changes in between 0.75 and >1.0? I did a backward test and with 0.7.5 everything works smoothly as you stated in the original issues (this also holds on macOS)

Can you elaborate what you mean by this:

Thus, any exception raised by actually ANY code after importing client will be printed, however is lost afterwards.

Maybe with a code example. I don't quite see the problem with exceptions. I also don't understand how that quote from the atexit docs applies, as it only talks about exceptions raised inside the exit handler(s). As far as I can tell, exceptions (anywhere else in the code) are handled properly, even those raised inside the JVM.
I do see your point concerning the exit code. Currently, a script like this one
import mph, sys
client = mph.Client()
sys.exit(1)

exits with code 0, and not 1 as intended. It surprises me a bit as I didn't think Python would pay any attention to the exit code passed to the JVM inside the exit handler, which is indeed 0. But apparently it does. Maybe some JPype magic takes care of that?
Anyway, according to this Stackoverflow question, this issue can be fixed with a little bit of monkey-patching.

I have to patch up some code for examples, but I will need some days sorry. To give you a quick answer: Running something like above but
import mph, sys
client = mph.Client()
raise RuntimeError(‘Something‘)

and connecting a subprocess will not only yield code 0 but also an empty stderr. Leaving the client away will give you an exception in stderr and an exit code. The emptiness of stderr and exit code 0 makes it virtually impossible to check if a subprocess raised an exception after client =
If atexit finishes normalles, e.g. not forcing an interpreter shutdown, the exception is in stderr...

No worries, take your time.
I was planning on adding an example to the documentation that demonstrates running multiple processes, either via the subprocess module or via multiprocessing, but also haven't found time for that yet. It would be an instructive example, that's for sure, so the more we learn about it, the better.
As hinted at in #10, I have built a job scheduler based on MPh before. (I'm not at liberty to publish it as I coded that on company time.) It's basically a Qt front-end for running simulations in parallel. The different "workers" were started as a subprocess, but the "scheduler" that would start them didn't rely on stderr or exit codes. I instead used file-based communication to relay status information between the processes. So I may have unintentionally worked around this problem.
Regarding the JPype issue you opened: It remains a mystery why JPype 0.7.5 worked so much better with Comsol. But, as explained in #1, going back to the old JPype isn't really an option as it won't work with the latest Python versions. Calling .exit()is our best option at this point, I think. Calling .halt() would not change things for the better, unless it somehow returned control to Python afterwards, which I don't think it does. I've also tinkered with Comsol threads (in this old test script, which I've since removed), but got nowhere. Though I also didn't really know what I was doing there. After all, the Comsol implementation is a black box for us.

For reference here is the differences in question
From native/common/jp_context.cpp
void JPContext::shutdownJVM()
{
        JP_TRACE_IN("JPContext::shutdown");
        if (m_JavaVM == NULL)
                JP_RAISE(PyExc_RuntimeError, "Attempt to shutdown without a live JVM");
        //      if (m_Embedded)
        //              JP_RAISE(PyExc_RuntimeError, "Cannot shutdown from embedded Python");

        // Wait for all non-demon threads to terminate
        JP_TRACE("Destroy JVM");
        {
                JPPyCallRelease call;
====== old
               JPJavaFrame frame(this);
               JPPyCallRelease release;
               if (m_JavaContext.get() != 0)
                       frame.CallVoidMethodA(m_JavaContext.get(), m_ShutdownMethodID, 0);
====== new
                m_JavaVM->DestroyJavaVM();
======
        }

        JP_TRACE("Delete resources");
        for (std::list<JPResource*>::iterator iter = m_Resources.begin();
                        iter != m_Resources.end(); ++iter)
        {
                delete *iter;
        }
        m_Resources.clear();

        // unload the jvm library
        JP_TRACE("Unload JVM");
        m_JavaVM = NULL;
        JPPlatformAdapter::getAdapter()->unloadLibrary();
        JP_TRACE_OUT;
}

In the old version there is a message to Java which tells it to free resources, then it goes straight to unload the Library which effectively halts a running JVM without any clean up.   Crashes could happen because any calls between the delete of resources and the terminate would access dead objects.
In the new version we first issue a destroy which must not return until all Java threads and proxies are terminated. Then once everything is dead we then clean up the resources and then finally unload the JVM.
There is a possible argument that we should unload before we kill the resources.  That would have made it a bit safer in the old version, but there is still the possibility of an active proxy which would crash if it were waiting with a java resource on the call stack.

@Thrameos:
I'm pretty sure it's the m_JavaVM->DestroyJavaVM() call were the delay occurs. That's the conclusion I came to in issue #1.
I don't really know what proxies Comsol might create. (Or what proxies really are, due to my very limited knowledge of Java.) But I did try to terminate the non-daemon threads that Comsol creates. Only that didn't solve the issue either.
Here's how far I got. I took this test script and added the following debug code right before calling jpype.shutdownJVM():
threads = jpype.java.lang.Thread.getAllStackTraces()
current = jpype.java.lang.Thread.currentThread()
threads = sorted(threads, key=lambda thread: thread.getId())

for thread in threads:
    id = int(thread.getId())
    name = str(thread.getName())
    daemon = '(daemon)' if thread.isDaemon() else ''
    print(f'{id:2}: {name:<25} {daemon}', flush=True)

for thread in threads:
    if thread != current and not thread.isDaemon():
        print(f'Stopping thread {thread.getId()}.')
        thread.stop()
        while not thread.isInterrupted():
            pass

for thread in threads:
    id = int(thread.getId())
    name = str(thread.getName())
    state = '(alive)' if thread.isAlive() else '(stopped)'
    print(f'{id:2}: {name:<25} {state}', flush=True)

If we comment out the lines in the test script where the Comsol client loads the simulation model from a file, the output is this:
Starting Comsol's Java VM via JPype 1.2.1.
Java VM started in 0.547 seconds.
Starting stand-alone Comsol client.
Client started in 2.632 seconds.
 1: main
 2: Reference Handler         (daemon)
 3: Finalizer                 (daemon)
 4: Signal Dispatcher         (daemon)
 5: Attach Listener           (daemon)
10: Python Reference Queue    (daemon)
 1: main                      (alive)
 2: Reference Handler         (alive)
 3: Finalizer                 (alive)
 4: Signal Dispatcher         (alive)
 5: Attach Listener           (alive)
10: Python Reference Queue    (alive)
Shutting down Java VM.
Java VM shut down in 0.275 seconds.

So here the shutdown works fine. But once the model is actually loaded, I get this:
Starting Comsol's Java VM via JPype 1.2.1.
Java VM started in 0.556 seconds.
Starting stand-alone Comsol client.
Client started in 2.671 seconds.
Loading model file.
Model loaded in 14.944 seconds.
 1: main
 2: Reference Handler         (daemon)
 3: Finalizer                 (daemon)
 4: Signal Dispatcher         (daemon)
 5: Attach Listener           (daemon)
10: Python Reference Queue    (daemon)
13: Thread-2                  (daemon)
15: EMF Reference Cleaner     (daemon)
18: pool-5-thread-1
19: pool-6-thread-1
20: pool-7-thread-1
Stopping thread 18.
Stopping thread 19.
Stopping thread 20.
 1: main                      (alive)
 2: Reference Handler         (alive)
 3: Finalizer                 (alive)
 4: Signal Dispatcher         (alive)
 5: Attach Listener           (alive)
10: Python Reference Queue    (alive)
13: Thread-2                  (alive)
15: EMF Reference Cleaner     (alive)
18: pool-5-thread-1           (stopped)
19: pool-6-thread-1           (stopped)
20: pool-7-thread-1           (stopped)
Shutting down Java VM.
Java VM shut down in 60.070 seconds.

So there are three extra (non-daemon) threads that Comsol apparently creates when it loads the model into memory. However, forcing those threads to stop doesn't eliminate the shutdown delay. I would conclude from this that the threads as such are not the issue.

Seems like a deadlock issue.  There is a java utility to dump all thread states.  Unfortunately as this is commercial software it would be difficult to replicate.

Ill check other options and the detailed discussion later on, but just to give you a quick replicator what my main concern is.
Running the following via python simpleExample.py > testout 2> testerr should come close to your file solution. The same applies to running it as a subprocess, obviously.
import sys
from mph import Server, Client

raise RuntimeError('Im very lazy today')

print('Starting')
cServer = server.Server()
port = cServer.port
host = 'localhost'
print('Local server created')

raise RuntimeError('Im lazy today')

cClient = client.Client()

raise RuntimeError('I am at least trying')

model = cClient.load('testVNew_caeModel.mph')

raise RuntimeError('I loaded a model')

Depending on where the exception is raised (specifically after the Client() part where the JVM starts, the return code will be 0 AND the stderr file will be empty. Thats a bad combination...

I had a call with Support. They will report the bug but state that this is neither a confirmation for a solution nor a timeframe for solution.
Regard ing the behavior windows (stopping after some time) and UNIX (running indefinitely): Support stated that there are two completely different frameworks for windows and UNIX, which can lead to this.

Yeah, we shouldn't be holding our breaths. There is no money in it for Comsol, not even in the long run, because there are certain "contractual reasons" why they cannot work on a Python API.
There are clearly differences in behavior between Windows and Unix. The issue you report here is a good example: I can reproduce it on Linux, but not on Windows.
If I run this test
import mph
client = mph.Client()
raise RuntimeError

on Windows (python test.py 2>stderr.txt), it's all good and I get the expected
Traceback (most recent call last):
  File "test.py", line 5, in <module>
    raise RuntimeError
RuntimeError

in the stderr output file. If I run it on Linux though, there is indeed nothing in stderr, just like you report for macOS.
So this (part of the) issue cannot be fixed with a little bit of monkey-patching, it seems. And it's almost certainly related to the JVM shutdown, as starting the client is definitely what triggers this behavior, and it's also at that point that we register the hard .exit() of the JVM.

I guess MathWorks got them by their best parts...A last try to stand the fight against python...
So with all the information collected, I forked Jpype and build a flag in which allows the old way. This actually works quite well and does not interfere to much with the rest, since you have to register atexit to set the flag in shutdownJVM() from its default value.
I asked them if they would like to merge. If not, we can think about either building wheels (I can do macOS) and distributing them with Mph or any other way of distribution. However I would not add a git address to requirements since this would mean compilation and at least on windows compiling C for python is a headache for a normal user ...

Yes, that's true. I myself refuse anything that requires a C compiler on Windows. It's just too much of a headache.
I saw your JPype PR and read Thrameos's excellent explanation. I finally understand what the issue is: It's who goes first, Python or Java. If they do add some way to configure the shutdown behavior, then that's a pretty easy choice for us since MPh only accesses Java objects from the Python side, not the other way around, so we want Python to die last.
Also, in my last comment, I spoke too soon. There is actually a very easy fix for that too. The reason we see no output in the file (but do see it in the console), it the "lazy writing" on the Unix-like systems. So all it takes is to flush stdout and stderr right before exiting. Like so:
sys.stdout.flush()
sys.stderr.flush()
logger.info('Exiting the Java virtual machine.')
jpype.java.lang.Runtime.getRuntime().exit(0)

Yes I was aiming for a sort of fallback solution for locken java processes and by hiding it like this it should not interfere too much. If there‘s a superior solution down the road on either end changing back would be very easy.
...I think I tried that during debugging to no avail, however I am not 100% sure. I’ll check that on Monday, I have left my work for the weekend and intend to not code too much...we will see... ;)
If this works, shouldn‘t it be possible to check if something is in stderr and if so set .exit(1)? I had that idea but tried it using sys.exc_info() which failed due to the above discussed reasons..

I agree, this is not a clean solution. But see if it works for you when you get a chance next week.
I've also just committed the monkey-patch for the exit-code issue: 7feee561435561b892e4c84251d076ffcda3e23b. This only hooks into sys.exit() for now. I don't know what's supposed to happen after an exception. Does that automatically change the exit code? If so, yes, we'd have to add a second hook into sys.exc_info(). Just checking stderr, if that's even possible, is probably not a good solution. Because stderr also receives all kinds of warnings that can often be ignored (from Qt for example), but shouldn't necessarily change the exit status.

I dod forget about that use of stderr. Not a good idea then.

I don't know what's supposed to happen after an exception. Does that automatically change the exit code?

Terminating a script with raise will set an exit code of usually 1. However sys.exc_info() exits only in the except clause so its gone in the shutdown routine

By the way Thrameos offered a fix over at Jpype. I will test it on Monday too ...

Great. I'll happily revert all changes if we get a clean solution in the end.
Though in the meantime, I have committed the missing monkey-patch with the exception hook: a88cf7fbcdcc03e71a2d36d877efeb80e5476b4e.

First of all here too: Thanks for the effort and the great work!
I managed to run some tests via VPN which confirmed that the hooks and the exit codes are working. I will do some more testing on Monday. If this is confirmed my suggestion would be to leave this as a fix and if / when jpype adds a shutdown config this can be rolled back. This would prevent having to deal with custom dependencies and compile issues. Also, I feel like Thrameos solution might be vastly superior to my patching.

Thanks. And also thanks for getting the ball rolling again on this issue.
I've also run some tests with the latest JPype PR. As far as I can tell (by running the test suite on Windows and Linux), this solves the issue of extended shutdown delays if all we do is jpype.config.destroy_jvm = False and then just use the regular jpype.shutdownJVM(). (Or not call it at all as it would run automatically anyway. But I like to have some logging around it.)
I've created a branch named shutdown_fix which implements the new (old) shutdown behavior, and also reverts all the work-arounds discussed above. I haven't tested exceptions and exit codes with it, but I trust that it would work as Python is now in full control again after the JVM shutdown (as the logs of the test suite show).
We'll have to wait for the next JPype release before rolling it out in MPh. I could release the work-arounds earlier if you want. Or we just discard them and wait.

I think this fix is ok and will not interfere to much with anything else so I suggest to release. With the complexity of a package like jpye, I think until a new release with the fix and with wheels is available it will take some time.
If you want to wait a few days I have some convenience functions in the model class for common tasks like toggling boundary conditions or adding new file data to interpolation functions. I think I could offer a PR starting next week...However I have to work out how to catch exceptions from java in python, I am still looking for the appropriate classes...

Okay, I released 0.8.2 with the work-arounds. Yeah, the next JPype release may be a while, especially as it would introduce new API features.
Speaking of new API features, I'm open to that, but also want to keep the scope manageable. Like anything needed for general scripting, yes. But nothing too project-specific. So importing data for interpolation functions is a definite yes, but changing boundary conditions maybe not. But we can discuss/negotiate that in a new issue one of these days.

authors: John-Hennig Thrameos max3-2

repo: John-Hennig/MPh


text:
API usage

How to use this extension as API?

If I get it to work, I'll probably add documentation in the readme or the wiki.

Because of how this extension works, implementing the web API route for it would be kinda tricky to do.
I'm not planning to use it myself, so I don't think I want to spend more time on this for now.
If anyone wants to implement it in a PR, I'll gladly review and test the code though.

You can use the API here on this extension instead. It's not the same thing as this extension, but rembg is still accessible through the API and you can simply chain that call with a normal img2img api call to do the same thing this extension does:
https://github.com/AUTOMATIC1111/stable-diffusion-webui-rembg/blob/master/scripts/api.py
I will close this issue as not planned.

source: gharchive/issue

authors: John-WL SLiMBokER

repo: John-WL/sd-webui-inpaint-background

license: MIT

license_type: permissive

license_source: github-api


text:
MacBook Pro and bluetooth keyboard locking up... Catalina 10.15.6

General troubleshooting tips
Before logging an issue please check that:

[x] You have the latest version installed (There may be a beta version that fixes your issue), see here for the latest releases and bug fixes: https://github.com/JohnCoates/Aerial/releases
[x] Your issue isn't already mentioned in our issues. You may find a workaround there or a similar request already made.
[x] Your problem isn't mentioned in the troubleshooting page.

If none of this fixes your issue, tell us about the problem you are experiencing or the feature you'd like to request.
Required information
In order to help us sort your issue, we ask that you provide the following information:

[x] Mac model: MacBook Pro
[x] macOS version: Catalina 10.15.6
[x] Monitor setup: 3 external

If appropriate, please enable Debug mode and Log to disk in Advanced tab and replicate your bug, then attach the AerialLog.txt file (You can access this file through the Advanced tab).
Description of issue / Feature request: Both the keyboard on my MacBook Pro and bluetooth keyboard become inoperable intermittently after installing Aerial. I have to restart my MacBook to resolve.
{{Replace this}}

Wonderful. p.s. Love the app
Sent from my iPhone

On Aug 23, 2020, at 11:16 AM, Guillaume Louel notifications@github.com wrote:

Interesting, in general, the video mode should have no impact but I’ve noticed you had 3 monitors.
This may be related to something else I'm working on now, I’ll get back to you soon and let you know.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Good day... Just an update on my current observations. I have tested all modes (cloned, mirrored and spanned) without a recurrence of the keyboard locking up. My keyboard has NOT locked up over the past 2 days. So it might have been on of those IT gremlins, and/or something that just cleared up by itself. I will keep you posted if the issue reappears. Thx. And again, LOVE THE APP!

repo: JohnCoates/Aerial


text:
Cannot select options for the Screensaver

I use MacOS X 10.11.1 in a MacBook Pro (15-inch, Early 2011). Although the screensaver runs smoothly, I cannot select any options in the Screen Saver Options window (see attached screenshot, sorry for Greek letters!)

For no apparent reason, I am now able to select from the list of the available locations. I changed nothing.
I just went off the WiFi, saw that it doesn't stream videos when my Mac is offline, and then it worked properly.

This is happening for me as well. Seems to randomly glitch out

If anyone is still struggling with this issue please try the newest release that amongst other things offering caching.
https://github.com/JohnCoates/Aerial/releases

authors: alistairmcmillan manosbar tm1000


text:
Comment cant display on firefox 35 ie 11 chrome 39

On windows7 64bit, build the latest version, after comments plugin installed, the comment input dialog is showed. But the comments of the pad dont display.
Steps:
1 build the latest version,  install comment plugin  ,open a pad
2 click the comment button, they comment input dialog shows
3 type something, click comment to submit
4 the dialog dispear, but the comment not display on the pad content
attachs:

Do you still get the javascript errors when ep_comments_page is not installed?  They don't look related.

Tested on beta.etherpad.org and everything is fine.

You do realize you have to select the content you want to comment on before commenting right?

Yes, I select content to comment.
After uninstall the ep_comments_page plugin, the error dispear.
I installed the plugin with url/admin/plugins, the url is yundoc.cc:9003
The error means the request url changed from yundoc.cc:9003/socket.io to yundoc.cc/socket.io, and this change realate with the ep_comments_page plugin

@liuliming2008 sounds like your plugin issue is environment specific then.  Without being in your environment I can't fix.  You might want to hire either me or another Etherpad consultant to look into your environment for you.  I cannot connect to your instance.

@JohnMcLear
I fixed this in my way.
I find that if the plugin file use relative uri, such as io.connect("/comment"), it will lead to socket.io.js line 1050:
uri = loc.hostname + uri; // var loc = loc || global.location;
The loc.hostname is yundoc.cc, not yundoc.cc:9003.
Here of loc.hostname should be repalced by loc.host or loc.hostname+':'+loc.port.
So I modified the socket.io.js like that, the comment functionality is basically ok now.
But, I find another promblem that:
The pad cant display the synced commets exactly.
Steps:
1 open two client(client-A,client-B) for the same pad pad-n
2 input n comments at client-A
3 client-B show n-1comments on the pad
4 input n+m comments at client-A
5 client-b show n+m-1 comments on the pad
I tested this on the last dev version and beta.etherpad.org, on windows 7 chrome 39, ie 11, firefox 35.

And the comment replies will not be updated until input a new replay at local pad.

Please create issues for each problem.  Do not put all issues here.
RE path, can you submit a pull request with a fix?

@liuliming2008 please read this before posting further: http://mclear.co.uk/2015/01/15/how-to-write-a-bug-report/

@JohnMcLear  Relaitive path is a socket.io bug I think, I will submit to socket.io.

pushed fix for socket issue.


text:
Sql Alchemy Dialect Doesn't Work

It does not, and that's an issue, it's designed to be a skeleton so people can issue pull requests against it to make it more working. Eventually it will work for a majority of things (rather than not work) and as little issues crop up we can fix them fast.

Progress is being made in a separate git at https://github.com/JohnOmernik/sqlalchemy-drill

repo: JohnOmernik/caraveldrill

license_source: bigquery


text:
无法下载用户发布视频

描述出现的错误
使用配置文件与CLI下载抖音用户发布视频失败

bug复现
复现这次行为的步骤：
1.使用命令行对主配置文件app.yam进行了初始化，然后使用了auto-cookie命令在app.yaml中成功设置cookie
2.使用VScode对app.yaml中各项参数进行配置
3.使用命令 “f2 dy -M post -u https://https://www.douyin.com/user/MS4wLjABAAAAgskWetxAG0wYF78v2pBEIGHrjKa0aMHgflAj_H5f2k4?vid=7356588700924497164 -c conf/app.yaml
命令运行结果
INFO     App: douyin
INFO     主配置路径：D:\Douyindownloader\venv\Lib\site-packages\f2\conf\app.yaml
INFO     自定义配置路径：D:\Douyindownloader\venv\Lib\site-packages\f2\conf\app.yaml
INFO     Version 0.0.1.5
Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in run_code
File "D:\Douyindownloader\venv\Scripts\f2.exe_main.py", line 7, in
File "D:\Douyindownloader\venv\Lib\site-packages\click\core.py", line 1157, in call
return self.main(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\click\core.py", line 1078, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\click\core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\click\core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\click\core.py", line 783, in invoke
return __callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\click\decorators.py", line 33, in new_func
return f(get_current_context(), *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\f2\apps\douyin\cli.py", line 443, in douyin
ctx.invoke(set_cli_config, **kwargs)
File "D:\Douyindownloader\venv\Lib\site-packages\click\core.py", line 783, in invoke
return __callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\click\decorators.py", line 33, in new_func
return f(get_current_context(), *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\f2\cli\cli_commands.py", line 135, in set_cli_config
asyncio.run(run_app(kwargs))
File "D:\Python\Python312\Lib\asyncio\runners.py", line 194, in run
return runner.run(main)
^^^^^^^^^^^^^^^^
File "D:\Python\Python312\Lib\asyncio\runners.py", line 118, in run
return self._loop.run_until_complete(task)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Python\Python312\Lib\asyncio\base_events.py", line 687, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\f2\cli\cli_commands.py", line 144, in run_app
await app_module.main(kwargs)
File "D:\Douyindownloader\venv\Lib\site-packages\f2\apps\douyin\handler.py", line 1484, in main
await mode_function_mapmode
File "D:\Douyindownloader\venv\Lib\site-packages\f2\apps\douyin\handler.py", line 257, in handle_user_post
user_path = await self.get_or_add_user_data(self.kwargs, sec_user_id, udb)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\f2\apps\douyin\handler.py", line 151, in get_or_add_user_data
await db.add_user_info(**current_user_data._to_dict())
File "D:\Douyindownloader\venv\Lib\site-packages\f2\apps\douyin\db.py", line 74, in add_user_info
await self.execute(
File "D:\Douyindownloader\venv\Lib\site-packages\f2\db\base_db.py", line 55, in execute
await cursor.execute(query, parameters)
File "D:\Douyindownloader\venv\Lib\site-packages\aiosqlite\cursor.py", line 48, in execute
await self._execute(self._cursor.execute, sql, parameters)
File "D:\Douyindownloader\venv\Lib\site-packages\aiosqlite\cursor.py", line 40, in _execute
return await self._conn._execute(fn, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\aiosqlite\core.py", line 133, in _execute
return await future
^^^^^^^^^^^^
File "D:\Douyindownloader\venv\Lib\site-packages\aiosqlite\core.py", line 106, in run
result = function()
^^^^^^^^^^
sqlite3.OperationalError: table user_info_web has no column named nickname_raw
桌面：
-操作系统：Windows11 64bit
-vpn代理：关闭
-项目版本：1.5.0.0
-py版本：3.12.3
附文
当相同操作步骤并使用自定义配置（其中填写了url未用CLI -u选项）时亦出现同样的提示，在Download文件夹中已新建文件，但文件下没有任何下载内容
(配置文件中cookie已使用--auto-cookie配置，图中已略去)

尝试过使用pip命令对f2进行卸载重装，但仍然未解决

升级前多留意readme

authors: Johnserf-Seed vain-Liang

repo: Johnserf-Seed/TikTokDownload


text:
remove index from everywhere it could possibly be stored

Preparing to have an automated refund scheme after 1 cycle, so old invites get refunded
It will use this method to  clean up index ranges

I think in case of campaign invites, they should return their funds to the campaign before delete the invite

Makes sense yes

I think in case of campaign invites, they should return their funds to the campaign before delete the invite

I am now sharing the code with cleanup, since it's so complicated - should work!

source: gharchive/pull-request

repo: JoinSEEDS/seeds-smart-contracts


text:
'autarky' and 'ratio' not being calculated

Hello!
Like the card, has the nice clean look that I like!
However, my autarky and ratio are not being calculated for some reason.
This is my setup:
type: custom:power-distribution-card
title: ''
entities:
  - decimals: 2
    display_abs: true
    name: home
    unit_of_display: adaptive
    unit_of_measurement: kW
    consumer: true
    icon: mdi:home-assistant
    entity: sensor.power_consumed
    preset: home
  - decimals: 2
    display_abs: true
    name: solar
    icon: mdi:solar-power
    producer: true
    entity: sensor.qmb392011c_output_power
    preset: solar
  - decimals: 2
    display_abs: true
    name: grid
    icon: mdi:transmission-tower
    entity: sensor.current_power_usage_calc
    preset: grid
center:
  type: bars
  content:
    - preset: autarky
      name: autarky
    - preset: ratio
      name: ratio
animation: flash

And this is the output:

Am I missing something?

Hi @JonahKr
I had played around with it, but did something wrong, I think 😄
It is working now, so thank you for the help!

repo: JonahKr/power-distribution-card


text:
walls covering important points

at the moment, auto generated walls could block off access to locations that need adjacent access. We currently solve this by placing an extra road, but instead we could just check for proximity and place a rampart instead. Ideally we'd only place one rampart per location. This will also be necessary for any attempt to go roadless. #167 #155

I like this one so much more than Commie. You got a stable bot and don't push unstable stuff to it. The code is also very easy to understand. And the best thing: it even compiles without any issues! I am having a good time working with this one.
Do you plan to go with (more) ramparts one day @JonathanSafer? the walls are restricting proper defense that we could add to it one day. Walls are also bad for the map, since they don't decay.
Also how about making walls not static? Maybe even slowly turning the base into something dynamic. I was thinking about using algorithmic to get all valid spots for ramparts/walls that are at least 3 or 4 tiles away from the base (so ranged attacks can't hit important infrastructure). Then figuring out the smallest amount of ramparts needed to protect the base from all exits. Perhaps including a special baseplanner logic to put all towers next to the exit, if it is the only entrance.

I think this could be split into two issues.

Dynamic wall placement would certainly be useful, and would lead the way for dynamic room planning in general.
Ramparts are still a challenging topic. There are scenarios where walls are much better (low combat, long term), and scenarios where ramparts are much better. (Short term high combat). Perhaps we could have some dynamic system that'll keep track of the local threat level and build walls/ramps accordingly.

repo: JonathanSafer/screeps


text:
Ignore underscore file & fixed multi-level navbar can not render

Ignore the underscore file.
Fixed multi-level navbar can not render.

Thank you for your work! 💯

authors: JonathanSchndr ZhongxuYang


text:
dying light 2 styled animations

i like dying light two's animations a lot maybe you could change the forward air kick and code it into a dropkick, just saying i would like to see a dl2 stlyed parkour and combat system in gmod.

no, sorry

authors: JonnyBro Mikeyisthatboi

repo: JonnyBro/beatrun

license: WTFPL


text:
Quinesha's branch

De admin's staan nu in de database en de admin pagina's zijn weer alleen beschikbaar voor admin's.

Ik heb het aangepast 👍

Oke, nu is het echt opgelost 🥲


text:
clear left side and clear right side don't work in the charter

Describe your bug here. Mind you, if you are modding, please try testing your bug in a clean version of the engine instead, this ensures the bug is actually caused by the engine itself. Also, if you're using an older version of JSE, please try the latest action build in the Actions tab or the latest release build. The issue has probably been fixed since that version. Oh yeah, and also be sure to check the pinned 'JS Engine: Known Issues' issue, to double check if your issue hasn't already been found!
clear left side and clear right side don't work in the charter
Command Prompt/Terminal/Crash logs (if existing)
dont have any

Have you identified any steps to reproduce the bug? If so, please describe them below in as much detail as possible. Use images if possible.
click clear left side or clear right side

Are you modding a build from source or with Lua?
Lua
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
no
If you use 1.12.0 or earlier, did you have Optimized Chart Loading turned on?
None
Did you check for any similar issues to what you're reporting? Check, then come back here. If there is a similar issue, then do not report the issue, otherwise it will be marked as a duplicate.
Yes

you have to move a bit for the line for it to work

i'm aware of this, and have no fix for it yet. for now to work around it when you switch sections you need to press W/S, this makes the game know what section you're on then it'll work


text:
Use ParseResults to improve performance

Please describe your suggestion
Use parse results to improve performance.
Relevant links:
Parsing user input (Brigadier docs)
Pseudocode
Creating a wrapped version of the parse results
Basically, create parse results for a "default command sender"
let cmdDispatcher = CommandAPIHandler.brigadierDispatcher

String command = command[0] == "/" ? command.substring(1) : command
ParseResults = cmdDispatcher .parse(command, NMSServer.getServerCommandListener())

WrappedParseResults = wrap(ParseResults)

Executing the parse results
cmdDispatcher.execute(unwrap(WrappedParseResults))

Or:
Upon execution, change the command sender?
let pr = unwrap(WrappedParseResults)
let playerContext:CommandListenerWrapper = NMSPlayer.getCommandListener();

cmdDispatcher.execute(new ParseResults<CommandListenerWrapper>(pr.getContext().withSource(playerContext), pr.getStartIndex(), pr.getReader(), pr.getExceptions()))

Cache design
map<<CommandStr, BukkitCommandSender_UUID>, ParseResult>

Does MC not normally allow inputting parse results into their execute method in NMS CommandDispatcher?
The main issue is trying to prevent memory leaks.
Also I don't see any performance benefit unless you parse it (weather sync or async is a different question) while the user is typing the command. I checked protocol and the clients does not send tab Complete request unless it's an ask server request.
So one solution for real time live parsing could be to make the command register an ask server request at every single position within the command tree so the client sends current command line every single time the client makes a modification and also merge other preexisting suggestions into that fray without breaking anything else. This is odd and only partially plausible.
Now if this were the client this would be easy since the client does use parse results in real time.

It's currently just a suggestion, but for clarification, you can use parse results to reduce the overhead of parsing user input. You could look it up in some form of cache and it goes straight to execution instead. NMS does let you execute parse results once they've been generated.
The idea would be if say you have a command block on some form of loop (say you run some command 20 times a second, it could get very intense).
The major issue as you've said would be memory leaks and I honestly haven't thought of a workaround for it. For now, this idea is just speculation.
I don't plan to include this in the 3.0 release, but it's a potential idea for the far future and I thought it would be good to note down.


text:
Bring in dependency banning and/or restricting rule(s)

Splitting out from #42: npm-package-json-lint has a family of rules that can ban variants of package dependencies:

https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-dependencies
https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-devDependencies
https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-pre-release-dependencies
https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-pre-release-devDependencies

Additionally, other rules exist in that package and elsewhere for restricting dependency ranges:

https://github.com/kellyselden/eslint-plugin-json-files/blob/master/docs/rules/no-branch-in-dependencies.md
https://github.com/kellyselden/eslint-plugin-json-files/blob/master/docs/rules/restrict-ranges.md

I'd like to add in some kind of rule or rules to this package equivalent to those. Not clear yet how they'd look. Should they be one big configurable rule? Granular rules like how npm-package-json-lint & co have them? More thought required.
~Blocked on #40. Not a high priority issue given that this wouldn't be enabled by default in any recommended configs.~ ✅

I'd love to see this - definitely something missing from the eslint ecosystem at the moment!
https://eslint.org/docs/latest/rules/no-restricted-imports#rule-details might be a good reference too, since it does something similar.
Some granularity would be nice - one thing I've struggled with in large monorepos is gradually phasing out a dependency, which requires having warnings for some dependencies (i.e., those being removed), and errors for others (i.e., those already removed) in parallel.

https://eslint.org/docs/latest/rules/no-restricted-imports#rule-details might be a good reference too, since it does something similar.

This raises a good point about the value of a new rule for this.  If the usage sites of a restricted package is being reported using no-restricted-imports what additional value would a rule applied to the package.json for the same package provide?  Wouldn't that be reporting effectively the same thing in two different places?  I guess one area that this would cover that that rule doesn't, is dev tool packages that are only being used in package.json scripts and not imported somewhere where the restricted imports rule would cover?  I guess my main concern is having two different rules firing errors for the same issue.

one thing I've struggled with in large monorepos is gradually phasing out a dependency

The way I would see this going in practice is adding the package as a restricted import using no-restricted-imports, disabling existing usage and gradually reducing usage until it's zero, at which point knip would report the package as unused and it's removed entirely.  I.e. the place where this rule would fit in seems rather narrow, unless I'm missing something.


text:
docs: add Development section in README

PR Checklist

[x] Addresses an existing open issue: fixes #661
[x] That issue was marked as status: accepting prs
[x] Steps in CONTRIBUTING.md were taken

Overview
Add a Development section in the README for better discoverability.

@all-contributors please add @rakleed for doc.

🤖 Beep boop! This comment was added automatically by all-contributors-auto-action.
Not all contributions can be detected from Git & GitHub alone. Please comment any missing contribution types this bot missed.
...and of course, thank you for contributing! 💙

authors: JoshuaKGoldberg rakleed


text:
Dose visibility "ON" in MPR views on resetting WL/WW

Dose is displayed while clicking "Reset WL/WW" on MPR views even when the DoseVisibility flag is off

This is fixed now.

repo: Jothy/KIMView


text:
not working at all

i tried another solutions but nothing works, code just frizzing when it trying download something
code i used:
from pytubefix import YouTube
yt = YouTube("https://www.youtube.com/watch?v=xxxxxxxxxx", use_oauth=True, allow_oauth_cache=False)
stream = yt.streams.filter(only_audio=True).first()
stream.download(output_path="audios/", filename=f"1.mp3")
it only creating 0 bytes file and frozzing, pls help

Same issue using the latest version. How can I solve it?

authors: Hoshinaku anAwesomeWave

repo: JuanBindez/pytubefix


text:
Racecondition-Free question order design & implementation

Description
Currently, every question is assigned a questionOrder (number)
For example, Given there are questions A(1), B(2), C(3) (A(1) means A has a questionOrder=1, and so on...)
we may want to request to swap the order between A and B , which turns out to be B(1), A(2), C(3)
Or we may want to assign a list of orders (2, 1, 3) to (A, B, C) which turns out to have B(1), A(2), C(3)
But if there are many order-adjustments request issued at the same time, a race condition may happen.
Acceptance Criteria
Given questions A(1), B(2), C(3), D(4), E(5)
when two order-adjustment requests issued at the same time
Then the order adjustment should be done properly without a race condition.

Resolved in #416

@Wally5077 I think you need to work on this.
Respond the updated question orders back to the client.

repo: Judge-Girl/Judge-Girl


text:
Daily interactions bug and request to increase daily interactions for plus/premium users

Firstly, despite 24 hours having passed since my last chat interactions, my daily limit has not reset. It still shows 100/100 interactions, which is causing inconvenience. I kindly request that you fix this bug as soon as possible.
Secondly, I am subscribed to the yearly plan of $219.89. However, my daily interaction limit is still capped at 100, which is too low considering my subscription plan. I respectfully request that you increase my daily interaction limit to 1000.
I would appreciate it if you could look into these matters urgently and take the necessary actions to resolve them.
CodeGPT Account Email : muhammadkamaluddin603@gmail.com

Hi @ai-kamal, we are reviewing your account. We will write to you as soon as we resolve the issue. On another note, the current Teams plan allows for 100 daily interactions. If you wish to increase the number to 1000, you must acquire the API plan. Please contact us at :pilar.hidalgo@judini.ai to discuss this plan.

authors: PilarHidalgo ai-kamal

repo: JudiniLabs/code-gpt-docs


text:
Set #juicy-ace-editor-container position to relative

With the current settings, #juicy-ace-editor-container's position is absolute. That means the juicy-ace-editor component will never take on the full height of the editor, and following sibling elements end up over the editor box.
Changing juicy-ace-editor-container's position to relative fixes the issue and does not seem to have any-side effect (as far as I can tell). Is it possible to either change that setting, or at least provide a css variable so an implementer can have control over that ?

Thanks for feedback @antoinegoutagny. Fair point. It seems to be some legacy workaround for something I cannot remember, or just a bug.
I'll test few things around, and fix it.

I have change it to use display:flex instead of position: absolute.
It's released as 1.2.0.
@antoinegoutagny I hope it works for you as well, if not please let me know.

authors: antoinegoutagny tomalec

repo: Juicy/juicy-ace-editor

license: mit


text:
Improve short version of show for measures

This PR tweaks a few anomalies for show(::MLJType) and addresses https://github.com/alan-turing-institute/MLJ.jl/issues/923.
using MLJBase, MLJModels

julia> evaluate(ConstantClassifier(), make_moons()..., measures=[macro_f1score, fpr])
PerformanceEvaluation object with these fields:
  measure, measurement, operation, per_fold,
  per_observation, fitted_params_per_fold,
  report_per_fold, train_test_pairs
Extract:
┌─────────────────────────────────────────┬─────────────┬──────────────┬────────────────────────────────────────────┐
│ measure                                 │ measurement │ operation    │ per_fold                                   │
├─────────────────────────────────────────┼─────────────┼──────────────┼────────────────────────────────────────────┤
│ MulticlassFScore{Float64,…}(β = 1.0, …) │ 0.311       │ predict_mode │ [0.324, 0.324, 0.286, 0.286, 0.324, 0.324] │
│ FalsePositiveRate(rev = nothing)        │ 0.5         │ predict_mode │ [1.0, 0.0, 1.0, 0.0, 1.0, 0.0]             │
└─────────────────────────────────────────┴─────────────┴──────────────┴────────────────────────────────────────────┘

@KronosTheLate How's this look to you?

Codecov Report

Merging #757 (43316d1) into dev (95efa58) will increase coverage by 0.00%.
The diff coverage is 91.66%.

@@           Coverage Diff           @@
##              dev     #757   +/-   ##
=======================================
  Coverage   85.41%   85.41%
=======================================
  Files          36       36
  Lines        3435     3443    +8
=======================================
+ Hits         2934     2941    +7
- Misses        501      502    +1

Impacted Files
Coverage Δ

src/measures/measures.jl
70.29% <ø> (-0.58%)
:arrow_down:

src/show.jl
40.11% <91.66%> (+3.07%)
:arrow_up:

Continue to review full report at Codecov.

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

This still looks too long for the measures I raised the issue with...

I would prefer to have something like no more than the 26 characters in "MulticlassTruePositiveRate".
How about using a function like my example _shorten_and_make_string, only in printing this table?
julia> measures = [Accuracy(), MulticlassTruePositiveRate(), MulticlassPrecision()]
3-element Vector{MLJBase.Aggregated}:
 Accuracy()
 MulticlassTruePositiveRate{MacroAvg,…}(average = MLJBase.MacroAvg(), …)
 MulticlassPrecision{MacroAvg,…}(average = MLJBase.MacroAvg(), …)

julia> function _shorten_and_make_string(measure::MLJBase.Aggregated)
           name = typeof(measure)
           name = string(name)
           if '{' ∈ name
               return name[begin:findfirst('{', name)-1]
           else
               return name
           end
       end
_shorten_and_make_string (generic function with 1 method)

julia> _shorten_and_make_string.(measures)
3-element Vector{String}:
 "Accuracy"
 "MulticlassTruePositiveRate"
 "MulticlassPrecision"

@KronosTheLate Thanks for the feedback!
I'm open for an ad-hoc method just for the table, but your suggestion does not address my previous concern copied below:

Yeah, this is tricky to get right in a generic way because some metrics really need the type parameters shown to be unambiguous. For example, in a regression problem you might use both LPDistLoss(1) and LPDistLoss(2).

function _shorten_and_make_string(measure)  <---- needed to broaden type here
                  name = typeof(measure)
                  name = string(name)
                  if '{' ∈ name
                      return name[begin:findfirst('{', name)-1]
                  else
                      return name
                  end
              end
_shorten_and_make_string (generic function with 2 methods)

l1 = LPLoss(1)
l2 = LPLoss(2)

julia> _shorten_and_make_string.([l1, l2])
2-element Vector{String}:
 "LPLoss"
 "LPLoss"

What I have done in new commits is to suppress printing of type parameters, which we should do anyway for consistency with the show_compact(object) = false variation.
julia> evaluate(ConstantClassifier(), make_moons()..., measures=[Accuracy(), MulticlassPrecision(), MulticlassTruePositiveRate()])
Evaluating over 6 folds: 100%[=========================] Time: 0:00:00
PerformanceEvaluation object with these fields:
  measure, measurement, operation, per_fold,
  per_observation, fitted_params_per_fold,
  report_per_fold, train_test_pairs
Extract:
┌─────────────────────────────────────────────────────────────┬─────────────┬──────────────┬─────────────────────────────────────┐
│ measure                                                     │ measurement │ operation    │ per_fold                            │
├─────────────────────────────────────────────────────────────┼─────────────┼──────────────┼─────────────────────────────────────┤
│ Accuracy()                                                  │ 0.4         │ predict_mode │ [0.44, 0.48, 0.4, 0.32, 0.44, 0.32] │
│ MulticlassPrecision(average = MLJBase.MacroAvg(), …)        │ 0.7         │ predict_mode │ [0.72, 0.74, 0.7, 0.66, 0.72, 0.66] │
│ MulticlassTruePositiveRate(average = MLJBase.MacroAvg(), …) │ 0.5         │ predict_mode │ [0.5, 0.5, 0.5, 0.5, 0.5, 0.5]      │
└─────────────────────────────────────────────────────────────┴─────────────┴──────────────┴─────────────────────────────────────┘

We could also change the order of the fields, to show operation last; in practice it would often not appear at all. I like having it because it emphasises the fact that the measures are different (probabilistic/deterministic) and there is occasionally confusion over this.
Perhaps you have a different suggestion on how to shorten further, without removing ambiguities?

Well, that is now how the MIME("text/plain") show looks for measures
julia> macro_f1score
MulticlassFScore(
  β = 1.0,
  average = MLJBase.MacroAvg(),
  return_type = LittleDict)

But if I don't know how to make that work in the evaluation table as PrettyTables does not appear to support multiline display:
julia> evaluate(ConstantClassifier(),
       make_moons()...,
       measures=[Accuracy(), MulticlassPrecision(), MulticlassTruePositiveRate()])
PerformanceEvaluation object with these fields:
  measure, measurement, operation, per_fold,
  per_observation, fitted_params_per_fold,
  report_per_fold, train_test_pairs
Extract:
┌────────────────────────────────────────────────────────────────────────────────────────────┬─────────────┬──────────────┬─────────────────────────────────────┐
│ measure                                                                                │ measurement │ operation    │ per_fold                            │
├────────────────────────────────────────────────────────────────────────────────────────────┼─────────────┼──────────────┼─────────────────────────────────────┤
│ Accuracy()                                                                                │ 0.427       │ predict_mode │ [0.4, 0.44, 0.32, 0.48, 0.44, 0.48] │
│ MulticlassPrecision(\n  average = MLJBase.MacroAvg(), \n  return_type = LittleDict)        │ 0.713       │ predict_mode │ [0.7, 0.72, 0.66, 0.74, 0.72, 0.74] │
│ MulticlassTruePositiveRate(\n  average = MLJBase.MacroAvg(), \n  return_type = LittleDict) │ 0.5         │ predict_mode │ [0.5, 0.5, 0.5, 0.5, 0.5, 0.5]      │
└────────────────────────────────────────────────────────────────────────────────────────────┴─────────────┴──────────────┴─────────────────────────────────────┘

I'd be happy if you want to work, in a new PR, on some evaluation-specify fix (eg, with blank entries in the table to accomodate multiple lines, or a non-PrettyTables solution). This PR is just tweaks to the generic display and I think we've pushed that about as far as we can, no?

Another option is to implement Tables.jl API for performance evaluation objects (including those fields that fit into a table). Then you can display the table however you like (eg, as DataFrame). @KronosTheLate would you find that useful?

Have you used the linebreaks=true keywork of pretty_table? Linebreaking works, as demonstrated in the discussion over at https://discourse.julialang.org/t/prettytables-linebreak-in-title/78017/5.
It seems like there is currently simply too much information on a single line. This would be a problem with a Tables.jl interface as well, no?
I would think that this is a special case, and that all entries in the measure column could be formatted to add a newline after parenthesis with contents. E.g.
julia> str1 = "Accuracy()"
"Accuracy()"

julia> str2 = "MulticlassPrecision(average = MLJBase.MacroAvg(), return_type = LittleDict)"
"MulticlassPrecision(average = MLJBase.MacroAvg(), return_type = LittleDict)"

julia>

julia> function insert_linebreak_if_parenthesis_with_contents(str::String)
           linebreak_after = []
           for (i, c) in enumerate(str)
               if c == '(' && str[nextind(str, i)] != ')'
                   push!(linebreak_after, i)
               end
           end
           # Reverse to add from back, else
           # inds need shifting after additions
           linebreak_after_rev = reverse(linebreak_after)
           for i in linebreak_after_rev
               str = str[begin:i] * "\n" * str[nextind(str, i):end]
           end
           return str
       end
insert_linebreak_if_parenthesis_with_contents (generic function with 1 method)

julia> insert_linebreak_if_parenthesis_with_contents(str1)
"Accuracy()"

julia> insert_linebreak_if_parenthesis_with_contents(str2)
"MulticlassPrecision(\naverage = MLJBase.MacroAvg(), return_type = LittleDict)"

By formatting entries in measures by insert_linebreak_if_parenthesis_with_contents and setting linebreaks=true in calls to pretty_table, I think the problem is solved.

Have you used the linebreaks=true keywork of pretty_table? Linebreaking works, as demonstrated in the discussion over at https://discourse.julialang.org/t/prettytables-linebreak-in-title/78017/5.

Ahh! I didn't know about that, thanks. I think this is now optimal:

julia> evaluate(ConstantClassifier(),
       make_moons()...,
       measures=[Accuracy(), MulticlassPrecision(), MulticlassTruePositiveRate()])
PerformanceEvaluation object with these fields:
  measure, measurement, operation, per_fold,
  per_observation, fitted_params_per_fold,
  report_per_fold, train_test_pairs
Extract:
┌──────────────────────────────────┬─────────────┬──────────────┬────────────────────────────────────┐
│ measure                          │ measurement │ operation    │ per_fold                           │
├──────────────────────────────────┼─────────────┼──────────────┼────────────────────────────────────┤
│ Accuracy()                       │ 0.447       │ predict_mode │ [0.4, 0.48, 0.44, 0.4, 0.48, 0.48] │
│ MulticlassPrecision(             │ 0.723       │ predict_mode │ [0.7, 0.74, 0.72, 0.7, 0.74, 0.74] │
│   average = MLJBase.MacroAvg(),  │             │              │                                    │
│   return_type = LittleDict)      │             │              │                                    │
│ MulticlassTruePositiveRate(      │ 0.5         │ predict_mode │ [0.5, 0.5, 0.5, 0.5, 0.5, 0.5]     │
│   average = MLJBase.MacroAvg(),  │             │              │                                    │
│   return_type = LittleDict)      │             │              │                                    │
└──────────────────────────────────┴─────────────┴──────────────┴────────────────────────────────────┘

authors: KronosTheLate ablaom codecov-commenter


text:
TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/42870

Triggering TagBot for merged registry pull request: https://github.com/JuliaRegistries/General/pull/43023


text:
Addressing review comments

Hey, @Datseris. I've tried to address all your comments on #96  in this PR.

Added alphabet_length function that dispatches on estimators (throws error if alphabet length cannot be obtained)
Standardised API for normalized Tsallis, Renyi and Shannon entropies.
Added literature references justifying that normalization for symbolic entropy estimators are valid for all orders q.
Made distance_to_whitenoise part of public API.
Some minor formatting and language fixes.

Some things to potentially discuss are:
Naming (normalization interface)

Instead of a single entropy_normalized function, I used entropy_renyi_norm,
entropy_tsallis_norm and entropy_shannon_norm. This mirrors the entropy_renyi and
similar functions we already have. The alternative is to have entropy_normalized(x, est = Renyi(); kwargs...) or something along those lines. As we already discussed elsewhere, I don't think the latter approach is a good idea.
Do we provide normalized version of the convenience functions too (entropy_permutation_norm), or leave it up to the user to figure out how to do so?

Normalization/alphabet length
Where to indicate which estimators implements alphabet_length? Alternatives are:

To throw an error in alphabet_length for estimators that don't support normalization, e.g. throw("unimplemented"). I favor explicitly throwing an informative error instead of silently
returning nothing when an estimator doesn't implement alphabet_length, because this
reduces changes of errors for users.
In the docstring for renyi_entropy_norm.
In each individual estimator under a ##Implements heading.
A combination.

For user-friendlyness, I think either of the latter is best. For code maintenance purposes, the first alternative is best (which is what I've done in this PR).

Here's my idea for a generic function:
function normalize(entropy_function, est::ProbabilitiesEstimator, args...; kwargs...)
    L = alphabet_length(est)
    np = Probabilities(ones(L))
    return entropy_function(est, args...; kwargs...)/entropy_function(np, args...; kwargs...)
end

Here's my idea for a generic function:

Excellent. I didn't think of that at all. I will adjust the PR accordingly and ping you when ready.

The citation
# Normalization is well-defined for all values of `q`, e.g. Kumar, U., Kumar, V., &
# Kapur, J. N. (1986). Normalized measures of entropy. International Journal Of General
# System, 12(1), 55-69.

should be included in the docstring of this function I guess.

Thinking a bit more about this, I'm not convinced that your pseudocode above is the best way to go.  There are two reasons for this:

We implicitly assume that all generalized entropies are maximized for a uniform distribution. I don't know of any proof that this is the case. For example, is the Kaniadakis entropy (#92) maximized for the uniform distribution?
If a generalized entropy E shows up that is maximized for some other distribution, do we introduce a new normalization function specifically for E (e.g. normalized_X)?
For entropies that actually are maximized for uniform distributions (the ones we currently have), why take the extra step of allocating an extra probability vector and computing the entropy of those probabilities too? This essentially doubles the computational cost of computing normalized entropies, when it can be done with a single division operation (dividing by log(alphabet_length(est))), like so:

function normalize(x, entropy_function, est::ProbabilitiesEstimator, args...; kwargs...)
    L = alphabet_length(est)
    np = Probabilities(ones(L))
    return entropy_function(x, est, args...; kwargs...)/log(L)
end

We implicitly assume that all generalized entropies are maximized for a uniform distribution

No, we never assume this. We return the entropy normalized versus the uniform distribution. We don't make claims of what the uniform distribution does.

If a generalized entropy E shows up that is maximized for some other distribution, do we introduce a new normalization function specifically for E (e.g. normalized_X)?

No, because maximizing was never the goal here. Normalizing versus an established standard is.

This essentially doubles the computational cost of computing normalized entropies

The cost of computing the entropy includes computing the probabilities. Here we just create a small vector, which I bet would have minimal cost versus that of actually computing the probabilities... But sure, if you are analytically certain that for all entropy methods, regardless of q, we get log(alphabet_length(est)) as the result, the use that, definitely. I don't know this for sure, and I don't want to study all these Tsallis entropies now to find out :D

No, we never assume this. We return the entropy normalized versus the uniform distribution. We don't make claims of what the uniform distribution does.

Sure, but the whole point of normalisation is to ensure that the computed value falls in the range [0, 1], so that entropy values can be compared. This happens precisely when normalising to the maximal value of the entropy. For the entropies we have now, normalising to the uniform distribution does normalize to [0, 1], but only because the uniform distribution is the one that maximizes Renyi and Tsallis entropies (according to the references in this PR).
For other entropies, this might not be the case. If there is suddenly an entropy that isn't maximised by the uniform distribution, then the normalized value is no longer guaranteed to be on [0, 1], but on [0, a], where a is determined by how that particular entropy behaves for the uniform distribution. Then entropy_normalized no longer behaves in a consistent manner.
Of course, we can just define normalization in Entropies.jl to mean normalization to the entropy of a uniform distribution (as you suggest), and leave it to the user to find out if this normalization is meaningful to them . However, I think we should strive to provide "meaningful" output out-of-the-box, which makes having a completely generic entropy_normalized function potentially problematic.

But sure, if you are analytically certain that for all entropy methods, regardless of q, we get log(alphabet_length(est)) as the result, the use that, definitely.

Based on the references I found, this is the case for Renyi and Tsallis entropies. Not sure about the Kaniadakis and entropies, though. But this is a potential issue regardless if we normalize to log(alphabet_length(est)) or manually construct a flat distribution and normalize to the entropy of that.

What do you think?

That we are spending way too much time thinking about this :P
Let's just say, clearly, in the docstring that we divide by log(alphabet_length, and that this corresponds to maximum value for the two entropies we already have, and be done with it.

new entropies will get same treatment, same division, and the user needs to be educated about whether this makes sense for them I think...

That we are spending way too much time thinking about this :P

Fair enough 😆

Let's just say, clearly, in the docstring that we divide by log(alphabet_length, and that this corresponds to maximum value for the two entropies we already have, and be done with it.

Ok, done. I'll tag you once I've implemented the new interface.

Changes since the last comments:

alphabet_length(est) throws error when the alphabet length is not defined for est.
Moved alphabet_length functions to the individual estimator files.
Added analytical tests for Tsallis entropy, based on the original paper. It turned out Tsallis himself had a more general normalization that I use instead (works for all q). Then, dividing by log(alphabet_length(est)) would no longer work, so I chose to divide by the entropy of a manually constructed flat distribution instead, like you initially proposed. It is still possible to dispatch on particular estimators if we need to reduce the computational cost of the extra allocation and entropy computation.
Normalization interface as discussed above, with signatures covering the use cases I imagine I'd want as a user.
Utility functions maxentropy_tsallis, maxentropy_renyi, maxentropy_shannon (listed under "Utility methods" in the docs) that can be used for manual normalization.

I'd still cut down on content here. E.g, i don't think providing maxentropy_renyi, which literally is the log, makes sense. Let me know if you want me to do the pruning here or if yo uwant to continue working here instead.

I'd still cut down on content here. E.g, i don't think providing maxentropy_renyi, which literally is the log, makes sense. we can mention it in the docstring isteadn. Let me know if you want me to do the pruning here or if yo uwant to continue working here instead.

See comment above

Let me do some pruning here, and if I prune too much, you let me know and we add back the things you believe are useful.

@kahaaga I'd prefer to make the first draft for the new API if that's okay with you and you can review it instead. I'll have it done by tonight.

@kahaaga Actually, wait, I'm confused, where was this PR just got merged into? Not at the api_refactor, right? Because I was going to update that PR to the new API!

@kahaaga Actually, wait, I'm confused, where was this PR just got merged into? Not at the api_refactor, right? Because I was going to update that PR to the new API!

This was merged into the dispersion_estimators branch.

@kahaaga I'd prefer to make the first draft for the new API if that's okay with you and you can review it instead. I'll have it done by tonight.

Perfect.

Forget everything I said, I haven't realized that refactor_api was already merged into main. We should merge #96 into main as well and I start a new pr with the new, new API.

Forget everything I said, I haven't realized that refactor_api was already merged into main. We should merge https://github.com/JuliaDynamics/Entropies.jl/pull/96 into main as well and I start a new pr with the new, new API.

Yes, precisely.

authors: Datseris kahaaga


text:
Continue to plot even when there's no agents

The changes is as the title said, the use case is when running abm_video.

abm_video takes a long time to run (despite being relatively fast thanks to Julia, since rendering video + ABM is very resource heavy), but it stops when there's no agent left and doesn't produce any output.
Despite saying can't plot anymore, it still can. It's just ids and other agent related array/iterator are empty.
There's no way to know at which step the agents will all die out, unless the model in ran once. So if someone wants to create a video, they would have to run the model twice.

Here's a video for demonstation (I used agent color and heatmap parameters for the video):
https://user-images.githubusercontent.com/33273948/119382507-4c19e000-bcec-11eb-8e51-d6db30f4cff7.mp4
Since abm_plot use the same code it would work, too.

There's no way to know at which step the agents will all die out, unless the model in ran once. So if someone wants to create a video, they would have to run the model twice.

I don't get this point. Why do you have to run the model "twice"?

Sorry I was not clear enough, when a full video of the simulation is needed, we first must implement the model that compliant with the RNG seed, then we run the model with a specific seed and collect the agent count with adata. With that data, we find the first step index where the agents are all gone. Finally, we feed that number into the frames of abm_video.
Also, if a simulation implementation decided that agents can appears from nowhere, there might be interleaved time intervals when there are/aren't any agents in the simulations

Sounds good to me, thanks!

authors: Datseris ndgnuh


text:
IJulia and Julia 0.7.0-DEV

I can't install IJulia in the current development version (0.7.0-DEV.4858):
│ # Build failed for IJulia
│   exception =
│    LoadError: UndefVarError: JULIA_HOME not defined

Is there any workaround?

See #623.  Waiting for work on ZMQ.

Duplicate of #637

authors: jheinen stevengj


text:
Feature request: MultipleFilePicker

I (and presumably other users) use Pluto to automate batch processes. We also find the FilePicker to be a convenient GUI feature to choose data files to process. But currently FP can only choose and upload one file at a time. I'd like FP to have the added ability to choose and upload multiple files at a time.

Thanks!

license: Unlicense


text:
New package: Keygen v0.1.0

Registering package: Keygen
Repository: https://github.com/aminya/Keygen.jl
Created by: @aminya
Version: v0.1.0
Commit: 7c0fe130fbf41d9aebadd28a2e944e5001a066ce
Reviewed by: @aminya
Reference: https://github.com/aminya/Keygen.jl/commit/7c0fe130fbf41d9aebadd28a2e944e5001a066ce#commitcomment-39708299

Should this be part of a larger OpenSSH.jl package rather than in a special Keygen.jl package? Note that we now have OpenSSH in Yggdrasil.

@ViralBShah
I think we can have an OpenSSH.jl that adds some Julia functions on top of OpenSSH_jil.
But also have an application layer that generates the correct key for different tasks. For example for Documenter, GitHub secretes, etc. This could be called Keygen.jl or be just part of OpenSSH.jl.
I am not picky about the name. 🤔

I think using our BB binaries and consolidating efforts into an OpenSSH.jl package perhaps in the JuliaCrypto org would be the right way.
If you are up for it, let's get it moved and renamed and updated to use the BB binaries. I can invite your as a JuliaCrypto owner.

Sure. I will close this until we have a working OpenSSH.jl. Then we can talk about the application layer.

I transferred the repository, but I lost the write access I guess. I cannot change the repo name or see the projects tab.

@ViralBShah Can you give @aminya the appropriate access?

I didn't change the access. Maybe I'll just make you owner.

authors: DilumAluthge JuliaRegistrator ViralBShah aminya

repo: JuliaRegistries/General


text:
New package: Reddit v0.1.0

Registering package: Reddit
Repository: https://github.com/kennethberry/Reddit.jl
Created by: @kennethberry
Version: v0.1.0
Commit: 44ff5d6a0044bfe4e372f787445c2c0cb2d063f0
Git reference: master

Needs a [compat] section in Project.toml with at least an entry for julia itself, e.g.:
[compat]
julia = "1"

would mean that the package is compatible with Julia versions [1.0.0, 2.0.0).

I've added a [compat] section to the Project.toml.  Do I just need to comment with @JuliaRegistrator register in my latest commit?

Yes, that will update this PR with the new commit.

I have commented on a commit with @JuliaRegistrator register but it doesn't seem to be triggering the Registrator.  I initially triggered this PR via the web interface.  Is there something else besides commenting on a commit that needs to be done to trigger the Registrator to update the PR?


text:
Change compat for ForwardDiff -- upper bound DiffRules

This adds an upper bound so that all existing versions of ForwardDiff will not use DiffRules 1.1, and stop at 1.02. This applies to ForwardDiff v0.10.8 to v0.10.18 (latest).
The reason to do so is that DiffRules supports N-ary rules, but ForwardDiff throws an error if given one, and DiffRules v1.1 added a few. This isn't even a new export from DiffRules, it's a documented feature, although the package contained no rules using it. That makes me think it's not a breaking change to DiffRules, but just a bug in some versions of ForwardDiff. So the aim of this PR is to prevent them from installing a version which triggers that.
(The immediate fix is that https://github.com/JuliaDiff/DiffRules.jl/pull/60 and DiffRules 1.2.1 has removed these rules, temporarily. So installing the latest should not at present break things.)

Did I get this right? When I try installing on a fresh environment, I seem to get DiffRules v1.2.1 which is outside "1-1.02".
(@v1.8) pkg> activate --temp
  Activating new project at `/var/folders/yq/4p2zwd614y59gszh7y9ypyhh0000gn/T/jl_ecsvaR`

(jl_ecsvaR) pkg> up
    Updating registry at `~/.julia/registries/General`
    Updating git-repo `https://github.com/JuliaRegistries/General.git`
  No Changes to `/private/var/folders/yq/4p2zwd614y59gszh7y9ypyhh0000gn/T/jl_ecsvaR/Project.toml`
  No Changes to `/private/var/folders/yq/4p2zwd614y59gszh7y9ypyhh0000gn/T/jl_ecsvaR/Manifest.toml`

(jl_ecsvaR) pkg> add ForwardDiff
   Resolving package versions...
    Updating `/private/var/folders/yq/4p2zwd614y59gszh7y9ypyhh0000gn/T/jl_ecsvaR/Project.toml`
  [f6369f11] + ForwardDiff v0.10.18
    Updating `/private/var/folders/yq/4p2zwd614y59gszh7y9ypyhh0000gn/T/jl_ecsvaR/Manifest.toml`
  [d360d2e6] + ChainRulesCore v0.10.9
  [bbf7d656] + CommonSubexpressions v0.3.0
  [34da2185] + Compat v3.31.0
  [163ba53b] + DiffResults v1.0.3
  [b552c78f] + DiffRules v1.2.1
...


text:
New version: QuantumCircuitOpt v0.3.5

Registering package: QuantumCircuitOpt
Repository: https://github.com/harshangrjn/QuantumCircuitOpt.jl
Created by: @harshangrjn
Version: v0.3.5
Commit: afb85eb788f59d52c322b1fee0812dcc37fa8a91
Reviewed by: @harshangrjn
Reference: https://github.com/harshangrjn/QuantumCircuitOpt.jl/issues/44
Description: A Julia/JuMP Package for Optimal Quantum Circuit Design

@harshangrjn did you skip version on purpose?  What would you like to do?
[noblock]

@giordano yes, I tried to skip to 0.3.5 on purpose as the changes were quite more than usual but wasn't worth an upgrade to 0.4. If this is an issue, I can revert it to 0.3.2.

Not really an issue, it's just that Julia packages should follow semver, so skipping versions doesn't make much sense in that context :slightly_smiling_face:  We can manually merge this PR if you want, but sticking to semver would be better, since Pkg assumes that all packages follow it.

@giordano Makes sense! I just updated the version to 0.3.2. Looks like skipping patch versions are not a norm, but directly jumping to a minor version from any patch is allowable (for example, from 0.3.1 to 0.4).

authors: JuliaRegistrator giordano harshangrjn


text:
Docstring for GBMatrix unclear on "maximum on each dimension"

Perhaps this comment was added to the wrong method?
Unclear how specifying rows/cols as a positional argument could also have a default large size.

Ah yes, sorry. The size used to have a default which it no longer does.

authors: BioTurboNick Wimmerer


text:
The dependency on jquery could be removed in examples/chat-client.html

As I played with the examples, I made changes to the js code in examples/chat-client.html. https://github.com/widged/WebSockets.jl/blob/master/examples/chat-client.html.
Let me know if this is of any interest to you and whether you are ok with es6 or prefer strict es5.

Part of tagged release 0.5.

authors: hustf widged


text:
Is additionalProperties not working?

Is additionalProperties not working? I tried the following but it gives no error.
schema = { "type" : "object", "additionalProperties":"false","properties" : { "price" : {"type" : "number"},"name" : {"type" : "string"},},}
v = Draft4Validator(schema)
v.validate({"foobydooby":"true"})

Am I doing this wrong or is this not supported?

You mean False, not "false"
On May 8, 2017 5:03 PM, "Edwin Evans" notifications@github.com wrote:

Is additionalProperties not working? I tried the following but it gives no
error.
schema = { "type" : "object", "additionalProperties":"false","properties" : { "price" : {"type" : "number"},"name" : {"type" : "string"},},}
v = Draft4Validator(schema)
v.validate({"foobydooby":"true"})
Am I doing this wrong or is this not supported?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Julian/jsonschema/issues/334, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUIXgBAlJECUo12tJXzx2oJBG-DkeMPks5r361ZgaJpZM4NUpbF
.

Ah! That was the problem. Closing and thanks!

authors: Julian edwinevans

repo: Julian/jsonschema


text:
Bot won't run after following all steps in guide

Please tick all applicable boxes.

[X] I am using Python 3.5 or higher (run python --version on the command line)
[X] I have followed the official guides to install the bot for my system
[X] I have updated my dependencies to the latest version using the appropriate update script

Which version are you using?

[ ] The latest master version (1.9.8)
[ ] The latest review version

What type of issue are you creating?

[ ] Bug
[ ] Feature request
[X] Question

Description of issue
[14.959812164] 2019-03-11 18:12:18,683 - INFO - launcher: Starting sanity checks
[14.959812164] 2019-03-11 18:12:18,683 - INFO - launcher: Checking for Python 3.5+
[14.959812164] 2019-03-11 18:12:18,683 - INFO - launcher: Checking console encoding
[15.957117081] 2019-03-11 18:12:18,684 - INFO - launcher: Setting console encoding to UTF-8
[15.957117081] 2019-03-11 18:12:18,684 - INFO - launcher: Ensuring we're in the right environment
[15.957117081] 2019-03-11 18:12:18,684 - INFO - launcher: Adding local bins/ folder to path
[272.927284241] 2019-03-11 18:12:18,941 - INFO - launcher: Required checks passed.
[274.889230728] 2019-03-11 18:12:18,943 - INFO - launcher: Optional checks passed.
[274.889230728] 2019-03-11 18:12:18,943 - INFO - launcher: Moving old musicbot log
######################### PRE-RUN SANITY CHECKS PASSED #########################
[0.5629410743713379] 2019-03-11 18:12:19,231 - WARNING - musicbot.config | In config.py::MainThread(4968), line 116 in run_checks: i18n file does not exist. Trying to fallback to config/i18n/en.json.
[0.5629410743713379] 2019-03-11 18:12:19,231 - INFO - musicbot.config | In config.py::MainThread(4968), line 127 in run_checks: Using i18n: config/i18n/en.json
[0.562941074] launcher-ERROR: Error starting bot
Traceback (most recent call last):
File "run.py", line 368, in main
m = MusicBot()
File "E:\MusicBot\musicbot\bot.py", line 75, in init
self.config = Config(config_file)
File "E:\MusicBot\musicbot\config.py", line 84, in init
self.run_checks()
File "E:\MusicBot\musicbot\config.py", line 188, in run_checks
self.bound_channels = set(int(item) for item in self.bound_channels)
File "E:\MusicBot\musicbot\config.py", line 188, in
self.bound_channels = set(int(item) for item in self.bound_channels)
ValueError: invalid literal for int() with base 10: 'bot'
[0.563938141] launcher-INFO: All done
Log file
musicbot.log
Please attach your MusicBot log file (located at logs/musicbot.log) to this issue. You can do so by dragging and dropping the file here. If you do not include your log file, you WILL be asked to provide one.

BindToChannels is Id's not names.

Ah my bad. Yes, this fixed the issue at hand. Thank you!

repo: Just-Some-Bots/MusicBot


text:
_ASFChangeNameDuringIdle and _ASFRespondtoMessagesduringIdle?

Hello,
is there a way to implement those functions in any way ?
Maybe its possible to change the name of the steam account during idle mode to a custom one and reply to message when ur in idle mode and inactive for more then 1 hour or sth?
Many thanks

In upcoming version there is CustomGamePlayedWhileIdle with similar purpose. Apart from that you can FarmOffline to show yourself as offline to your friends, so they know that you're not in front of the PC. Anything apart from is duplicating already existing functionality for no reason.

Thanks for your response Archi,
yes but i was looking forward for something like extend ASF to a usual Steambot by changing the Name or responding to Messages automaticly. Farmoffline is a bit different, cause i want to get messages and respond them automatically. If its not possible just close it again and i'm fine with that.
Anyway, many thanks for your service !

i was looking forward for something like extend ASF to a usual Steambot by changing the Name or responding to Messages automaticly

That's not the purpose of ASF, I'm sorry. You should create your own steam bot if you want something like this.

Allright, hopefully they will not disconnect each other cause i still use ASF 24/7.

They won't if you use custom LoginID that is different than the one ASF is using. Refer to the source, in particular to https://github.com/JustArchi/ArchiSteamFarm/blob/master/ArchiSteamFarm/Bot.cs#L49 if you want to take a look how ASF is doing everything.
Good luck.

repo: JustArchi/ArchiSteamFarm


text:
[WIP] Feature command rewrite

Implements #861 upon completion by rewriting ASFs internal handling of commands and within this change cleans up the huge file Bot.cs already is.
Any advice welcome. 👍

I just noticed that thanks to the dicitionary things like !stop bot1, bot2 will not be valid anymore as this would create ("STOP", 2). Users will have to use !stop bot1,bot2 (without a space between bot-names) to avoid the split of bot-names into two arguments -> ("STOP", 1)

Take a break for a week or so (I expect hotfixes in master regarding #810) and then rebase against master, thanks.

seems legit. v3.3 when all hotfixes are completed?

So definitely NOT 3.3.0.0 😉

authors: Abrynos JustArchi


text:
Expose Peripheral identifier

Closes #394

I just realized this is available already. I'm sorry, I must have missed it. Therefore I am closing this PR.

repo: JuulLabs/kable


text:
Revert version bump

If the publish test succeeds I'll merge this. If it fails I won't.
Maven publication was failing because modules that generated both JVM and Android targets were missing JavaDoc jar on JVM. This failed sonatype validation preventing publishing.

If reverting the version fixes this, we should probably look into if we should report the regression — or maybe we need to tweak our config? 🤷

Publishing test succeeded.

Filed vanniktech/gradle-maven-publish-plugin#333

authors: cedrickcooke twyatt

repo: JuulLabs/krayon


text:
Jehovah son Christopher Columbus pease

https://github.com/Jwcp2424/Go-Away-in-the-name-ofJehovah-/commit/bea6d448c635d6dee6819b756a64ebd4caecc619

https://github.com/Jwcp2424/Go-Away-in-the-name-ofJehovah-/commit/bea6d448c635d6dee6819b756a64ebd4caecc619


text:
멀티클러스터 환경 cp portal chaos status 조회 이슈

chaos-mesh dashboard api를 통해 chaos status 조회 불가로 인한 cp portal ui에서 chaos 메뉴 들어갈 때 오류가 생성됨.

해당 이슈는 Host 클러스터에서만 동작하도록 변경되어 처리되었습니다.
K-PaaS 컨테이너 플랫폼 v1.6.0 부터 Portal-ui에 chaos 기능이 추가되었으며,
사용방법은 chaos 사용가이드 를 참고해 주시기 바랍니다.

이 문제가 해결되었으므로 이 이슈를 클로즈합니다.
추가적인 문제가 있으면 언제든지 다시 열어주세요.

authors: dancingcarrot jinhyojin suslmk-lee

repo: K-PaaS/container-platform


text:
Volume rendering example

Hey,
We (@izaid and I) have an interest in volume rendering support in Three.js, so we're excited to see your work on https://github.com/mrdoob/three.js/pull/14530!
Today I tried to make something work based on the new Texture3D class, and I managed to put something together. For us it's good to see that your work will enable us to use Texture3D for our use-case (we're now using emulated 3D textures via tiling approach). Perhaps it would also serve as a nice example.
The example demonstrates volume rendering on float32 volumetric data. It supports two different render styles, colormaps and setting contrast limits. There is room for improvement, e.g. the example could have some ui controls to select the render style etc. But it should be a good start.
FYI starting this Sunday I will be away for three weeks. Feel free to edit as needed, merge as is (we can improve later), or leave unmerged for now. Whatever you and the Three.js devs think is best :)

Supersceded by https://github.com/mrdoob/three.js/pull/14847


text:
Analyse the various types of hosting

In order to decide which type of hosting currently fits our needs and requirements we must first understand what types of hosting is offered by companies.
The types are:

[x] Shared hosting
[x] VPS
[x] Dedicated

I've currently covered the shared hosting and will be starting soon with a chapter about "VPS-hosting".

I've finished with the hosting types:

Shared Hosting
VPS
Dedicated

Webhosting-aanbieders-analyse_11-01-2022_v2.pdf

repo: KA-Huis/space-management


text:
Medium severity vulnerability found in openssl/libcrypto3

As of v3.41.2 and latest image contains security vulnerability. Yet not critical.
PR https://github.com/KEINOS/Dockerfile_of_SQLite3/pull/37 may fix this problem. It bumps up Alpine v3.17.3 to v3.18.0.
$ snyk container test keinos/sqlite3:latest

Testing keinos/sqlite3:latest...

✗ Medium severity vulnerability found in openssl/libcrypto3
  Description: Out-of-bounds Read
  Info: https://security.snyk.io/vuln/SNYK-ALPINE317-OPENSSL-5438697
  Introduced through: openssl/libcrypto3@3.0.8-r3, openssl/libssl3@3.0.8-r3, apk-tools/apk-tools@2.12.10-r1, busybox/ssl_client@1.35.0-r29
  From: openssl/libcrypto3@3.0.8-r3
  From: openssl/libssl3@3.0.8-r3 > openssl/libcrypto3@3.0.8-r3
  From: apk-tools/apk-tools@2.12.10-r1 > openssl/libcrypto3@3.0.8-r3
  and 4 more...
  Fixed in: 3.0.8-r4

Organization:      keinos
Package manager:   apk
Project name:      docker-image|keinos/sqlite3
Docker image:      keinos/sqlite3:latest
Platform:          linux/amd64
Base image:        alpine:3.17.3
Licenses:          enabled

Tested 15 dependencies for known issues, found 1 issue.

Base Image     Vulnerabilities  Severity
alpine:3.17.3  1                0 critical, 0 high, 1 medium, 0 low

Recommendations for base image upgrade:

Minor upgrades
Base Image  Vulnerabilities  Severity
alpine:3    0                0 critical, 0 high, 0 medium, 0 low

Learn more: https://docs.snyk.io/products/snyk-container/getting-around-the-snyk-container-ui/base-image-detection

Fixed in v3.41.2.
$ snyk container test keinos/sqlite3:3.41.2

Testing keinos/sqlite3:3.41.2...

Organization:      keinos
Package manager:   apk
Project name:      docker-image|keinos/sqlite3
Docker image:      keinos/sqlite3:3.41.2
Platform:          linux/amd64
Base image:        alpine:3.18.0
Licenses:          enabled

✔ Tested 15 dependencies for known issues, no vulnerable paths found.

According to our scan, you are currently using the most secure version of the selected base image

$ snyk container test keinos/sqlite3:latest

Testing keinos/sqlite3:latest...

Organization:      keinos
Package manager:   apk
Project name:      docker-image|keinos/sqlite3
Docker image:      keinos/sqlite3:latest
Platform:          linux/amd64
Base image:        alpine:3.18.0
Licenses:          enabled

✔ Tested 15 dependencies for known issues, no vulnerable paths found.

According to our scan, you are currently using the most secure version of the selected base image


text:
Change directory detection in util#checkForGit

Node v6 may only be required due to fs.constants.F_OK that is only used in this function.
Removing this and finding a different method, may allow for backwards compatibility up to v3 or v4.

Changed from fs.access to fs.stat as in b074c29f.
However, this shows an issue that strict mode must be enabled to use block scoped declarations.


text:
Make obvious boot-up sequence

We need an obvious way to know if the bot is running.

is this using OpenCV?

Yes! We use opencv-python via “import cv2”.
On Tue, May 28, 2024 at 10:57 AM Roshan @.***> wrote:

is this using OpenCV?
—
Reply to this email directly, view it on GitHub
https://github.com/KMcCand/Tennis-Ball-Pickup-Robot/issues/9#issuecomment-2135822341,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKJFNV6MQBQY2JUN7SGIM7LZETAP7AVCNFSM4RYYKB6KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJTGU4DEMRTGQYQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

authors: KMcCand jmccand roshanmirajkar

repo: KMcCand/Tennis-Ball-Pickup-Robot


text:
PIN unlock?

Since version 8, Windows has provided the ability to log in by entering a 4-digit PIN. It would be great if I could also set an arbitrary PIN for QuickUnlock (not necessarily digits only), rather than entering the first/last N characters of the master password.

See v2.0


text:
Unhandled Exception when trying to update mod

Attempted to update USI-UKS and got the following message below
GameData/UmbraSpaceIndustries/Kolonization/CHANGELOG.txt
Installing Mod : USI-UKS-Shared 0.1.7.0
Owning Mod     : USI-Kolonization
CKAN Version   : v1.16.0-0-g7206ce5 (beta)
Your GameData has been returned to its original state.
Also recieved an unhandled exception. Below is the details:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
at CKAN.Main._MarkModForUpdate(String identifier)
at CKAN.Util.Invoke[T](T obj, Action action)
at CKAN.Main.PostInstallMods(Object sender, RunWorkerCompletedEventArgs e)
************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
ckan
Assembly Version: 0.0.0.0
Win32 Version: 0.0.0.0
CodeBase: file:///C:/Users/Kyle/Downloads/ckan.exe
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
System
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34238 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34251 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34270 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34234 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
Microsoft.GeneratedCode
Assembly Version: 1.0.0.0
Win32 Version: 4.0.30319.34234 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
Microsoft.CSharp
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/Microsoft.CSharp/v4.0_4.0.0.0__b03f5f7f11d50a3a/Microsoft.CSharp.dll
System.Numerics
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Numerics/v4.0_4.0.0.0__b77a5c561934e089/System.Numerics.dll
System.Dynamic
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Dynamic/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Dynamic.dll
Anonymously Hosted DynamicMethods Assembly
Assembly Version: 0.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/mscorlib/v4.0_4.0.0.0__b77a5c561934e089/mscorlib.dll
System.Transactions
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Transactions/v4.0_4.0.0.0__b77a5c561934e089/System.Transactions.dll
System.Runtime.Serialization
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34234 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Serialization/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll
System.Xml.Linq
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_MSIL/System.Xml.Linq/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.Linq.dll
System.Data
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.Data/v4.0_4.0.0.0__b77a5c561934e089/System.Data.dll
System.EnterpriseServices
Assembly Version: 4.0.0.0
Win32 Version: 4.0.30319.34209 built by: FX452RTMGDR
CodeBase: file:///C:/Windows/Microsoft.Net/assembly/GAC_64/System.EnterpriseServices/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.EnterpriseServices.dll
************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.
For example:

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

Fixed

repo: KSP-CKAN/CKAN-meta


text:
hopefully the final fix for AJE

Now using "find".

Thanks!

repo: KSP-CKAN/NetKAN


text:
Unfreeze netkans frozen in error

#7960 unfroze EnduranceSpaceExplorationSystem (which was frozen by #7513 along with 325 other mods that supposedly had not had a new release since 2017-01-01) because it had a new release. After merge, I checked whether a backfill was needed since the previous release was in late 2019:
https://spacedock.info/mod/357/Endurance (from Interstellar) Continued...
However, that release was already indexed!
https://github.com/KSP-CKAN/CKAN-meta/commit/8409fec5e6e7eeb4befcd404b7b4fc0c41b7c41c#diff-384b2401dd8f66b3b7518cfd79648eeb
Which means that the last_indexed of this module should have been way too recent for the search from #7960 to flag it, so something went wrong in the preparation of that pull request.
I dug into the git history and found about 16 mods whose most recent release was within the AutoFreezer's current 1000-day window to not be frozen. This PR unfreezes them.
Commands run for future reference (the first one takes several minutes):
# For each module frozen in #7960, find the most recent commit in its CKAN-meta
# dir in which the bot added a file, and print the date and file path
for M in $(git -C ~/Downloads/KSP/NetKAN show da46067 --name-only --pretty= | sed -e 's/^NetKAN\/\|\.frozen$//g' > identifiers) ; do echo $(git -C ~/Downloads/KSP/CKAN-meta log --diff-filter=A --grep='NetKAN generated mods' -1 --pretty=format:'%cI' --name-only $M) ; done | tee commits-netkan-only

# Sort by date (done separately so I could watch the progress of the above command)
sort -u commits-netkan-only > sorted

# Inspecting the output, 20 lines have a timestamp since 2017-09-13, extract those identifiers
tail -n 20 sorted | sed -e 's/^.* \|\/.*$//g' > not-stale

# Unfreeze them in NetKAN (4 that have already been unfrozen will error out)
for M in $(cat /tmp/ckan-investigation/mass-freeze/not-stale) ; do git mv $M.frozen $M.netkan ; done

[ ] Keep tags: KHWearableKISProps
[ ] Fix version file: AirParkContinued HullBreach ShowAllFuelsContinued
[ ] Consider adding vref: AirParkContinued CactEyeCommunity HullBreach LightsOut
[ ] Consider adding ModuleManager depends: CactEyeCommunity HullBreach SolarisHypernautics
[ ] Clear bogus URLs from SpaceDock: CloakingDevice EveryS NorthKerbinDynamics
[ ] Consider removing vref: EngineLighting
[ ] Consider removing ModuleManager depends: NorthKerbinDynamics


text:
IndexBuffer partial updates

Add start/count parameters to lock.

Also make sure start/count parameters are actually implemented for VertexBuffer.lock and drawIndexedVertices.

repo: KTXSoftware/Kha

license: Zlib


text:
Improve discoverability of your work on HF

Hi,
Niels here from the open-source team at Hugging Face. I discovered your work through the paper page: https://huggingface.co/papers/2407.15420 (feel free to claim the paper so that it appears at your HF account!).
However there are a couple of things which could improve the discoverability of your work, which I've listed below.
Add a model card
I see the model is already on the hub, but it's in a dataset repository: https://huggingface.co/datasets/hamacojr/LocoTrack-weights.
Would you be up for creating it in a model repository, rather than a dataset repository?
It would be great to also add a model card :) See here for some tips: https://huggingface.co/docs/hub/en/model-cards.
Moreover, the model could be linked with the paper, see here on how to do that: https://huggingface.co/docs/hub/en/model-cards#linking-a-paper
Uploading the PyTorch model
I see you're planning to release the PyTorch version as well. We recommend leveraging the PyTorchModelHubMixin to push your model to the hub and reload it using from_pretrained. This ensures a config.json along with safetensors weights are pushed to the hub.
Alternatively, we offer https://huggingface.co/docs/transformers/custom_models which ensures your model can be loaded using Transformers, with trust_remote_code=True.
Let me know if you need any help regarding this!
Cheers,
Niels
ML Engineer @ HF 🤗

And an HF demo of course.. :wink:

authors: NielsRogge bhack

repo: KU-CVLAB/locotrack


text:
Tracking hard rebase from Snitch cluster

This PR is for tracking purposes only. It is not intended to be merged but is meant for checking what needs to be changed in the main before a hard rebased forced push.

Deleting this because it's not needed but was placed for tracking purposes only.


text:
sTeX profiles as resources here?

Is it a good idea to put the sTeX profiles here into lib/LaTeXML/resources/profiles?

Yes, that's exactly right, you could consult the MWS plugin which also uses this technique

copied there, thanks.

authors: dginev kohlhase

repo: KWARC/LaTeXML-Plugin-sTeX