text:
ExtraContexts doesn't work after config

I recently changed the config of ExtraContexts from:
# ExtraContexts
# made with <3 by Luck

# Set a provider to true to enable it.
# Contexts are explained in more detail here:
# https://github.com/lucko/LuckPerms/wiki/Context

# Provides the 'wg-region' context.
# Returns the name of each WorldGuard region the player is currently in.
#
# e.g. wg-region=spawn
worldguard: false

# Provides the 'gamemode' context.
# Returns the players current gamemode.
#
# e.g. gamemode=creative
gamemode: false

# Provides the 'dimension' context.
# Returns the type of the players current world.
#
# e.g. dimension=nether
dimension: false

placeholderapi: false
placeholderapi-placeholders:
  allowflight: "%player_allow_flight%"

To this:
# ExtraContexts
# made with <3 by Luck

# Set a provider to true to enable it.
# Contexts are explained in more detail here:
# https://github.com/lucko/LuckPerms/wiki/Context

# Provides the 'wg-region' context.
# Returns the name of each WorldGuard region the player is currently in.
#
# e.g. wg-region=spawn
worldguard: true

# Provides the 'gamemode' context.
# Returns the players current gamemode.
#
# e.g. gamemode=creative
gamemode: true

# Provides the 'dimension' context.
# Returns the type of the players current world.
#
# e.g. dimension=nether
dimension: true

placeholderapi: true
placeholderapi-placeholders:
  allowflight: "%player_allow_flight%"

and added ChatControl Pro. I'm not sure what's wrong.

I forgot # had a Markdown value so I edited everything into codeblocks

Are there any errors in the console?
Also, what version of LuckPerms, ExtraContexts and server (including server type) are you using?

I use PaperSpigot (443) with LuckPerms 5.0.39 and ExtraContexts Build #12. I just restarted my server and when loading ExtraContexts I get this error output:
[22:04:19] [Server thread/INFO]: [ExtraContexts] Enabling ExtraContexts v2.0-SNAPSHOT
[22:04:19] [Server thread/INFO]: [ExtraContexts] Registering 'worldguard' calculator.
[22:04:19] [Server thread/ERROR]: Error occurred while enabling ExtraContexts v2.0-SNAPSHOT (Is it up to date?)
java.lang.NoClassDefFoundError: com/sk89q/worldguard/protection/flags/registry/FlagConflictException
	at me.lucko.extracontexts.libs.worldguardwrapper.WorldGuardWrapper.<init>(WorldGuardWrapper.java:38) ~[?:?]
	at me.lucko.extracontexts.libs.worldguardwrapper.WorldGuardWrapper.getInstance(WorldGuardWrapper.java:20) ~[?:?]
	at me.lucko.extracontexts.calculators.WorldGuardCalculator.<init>(WorldGuardCalculator.java:18) ~[?:?]
	at me.lucko.extracontexts.ExtraContextsPlugin.register(ExtraContextsPlugin.java:38) ~[?:?]
	at me.lucko.extracontexts.ExtraContextsPlugin.onEnable(ExtraContextsPlugin.java:26) ~[?:?]
	at org.bukkit.plugin.java.JavaPlugin.setEnabled(JavaPlugin.java:321) ~[patched.jar:git-PaperSpigot-443]
	at org.bukkit.plugin.java.JavaPluginLoader.enablePlugin(JavaPluginLoader.java:332) [patched.jar:git-PaperSpigot-443]
	at org.bukkit.plugin.SimplePluginManager.enablePlugin(SimplePluginManager.java:407) [patched.jar:git-PaperSpigot-443]
	at org.bukkit.craftbukkit.v1_8_R3.CraftServer.loadPlugin(CraftServer.java:359) [patched.jar:git-PaperSpigot-443]
	at org.bukkit.craftbukkit.v1_8_R3.CraftServer.enablePlugins(CraftServer.java:318) [patched.jar:git-PaperSpigot-443]
	at net.minecraft.server.v1_8_R3.MinecraftServer.s(MinecraftServer.java:408) [patched.jar:git-PaperSpigot-443]
	at net.minecraft.server.v1_8_R3.MinecraftServer.k(MinecraftServer.java:372) [patched.jar:git-PaperSpigot-443]
	at net.minecraft.server.v1_8_R3.MinecraftServer.a(MinecraftServer.java:327) [patched.jar:git-PaperSpigot-443]
	at net.minecraft.server.v1_8_R3.DedicatedServer.init(DedicatedServer.java:267) [patched.jar:git-PaperSpigot-443]
	at net.minecraft.server.v1_8_R3.MinecraftServer.run(MinecraftServer.java:563) [patched.jar:git-PaperSpigot-443]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
Caused by: java.lang.ClassNotFoundException: com.sk89q.worldguard.protection.flags.registry.FlagConflictException
	at java.net.URLClassLoader.findClass(URLClassLoader.java:382) ~[?:1.8.0_232]
	at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:102) ~[patched.jar:git-PaperSpigot-443]
	at org.bukkit.plugin.java.PluginClassLoader.findClass(PluginClassLoader.java:87) ~[patched.jar:git-PaperSpigot-443]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418) ~[?:1.8.0_232]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351) ~[?:1.8.0_232]
	... 16 more
[22:04:19] [Server thread/INFO]: [ExtraContexts] Disabling ExtraContexts v2.0-SNAPSHOT

Try using WorldGuard 7 as it can't find a class from WorldGuard, meaning it does use a different API.
And v7 of WorldGuard had their API path changed a bit.

I thought WorldGuard 7 wasn't available for 1.8.8

I don't know. I don't use 1.8.8 and from what I know do the devs of WorldGuard suggest to always update your server, which I support.

I use 1.8.8 because I hate anything upwards of it. Is there any other solution?

I guess it's time to move on from 1.8.8, so I'm closing this issue

repo: LuckPerms/ExtraContexts


text:
ScrollIndicatorView.setOnItemSelectListener无效

代码如下：
int selectColorId = R.color.color_1eb7d2;
int unSelectColorId = R.color.color_434343;
int colorIndicat = Color.parseColor("#1eb7d2");
    indicator.setScrollBar(new ColorBar(context, colorIndicat, 10));
    indicator.setOnTransitionListener(new OnTransitionTextListener().setColorId(context, selectColorId, unSelectColorId));

    indicator.setOnItemSelectListener(new Indicator.OnItemSelectedListener() {
        @Override
        public void onItemSelected(View view, int i, int i1) {
            //这里无反应？
        }
    });

如果你是使用了indicatorviewpager,那就要用indicatorviewpager来设置切换监听

好的，可以了

source: gharchive/issue

repo: LuckyJayce/ViewPagerIndicator

license_type: permissive

license_source: github-api


text:
间谍过家家无法追番

部署环境（windows / docker）
docker
问题描述
第二季第一集开始没法追了，之前都没问题，但第二季开始发布组标题里都开始用26集对应第二季第一集，完全乱掉了，而且还带了个season 2，搜索词也不知道怎么改....请问这种情况如何处理？另外搜素的时候并不会搜E26而是E1，我不太明白，明明TVDB上是S02E01。
[[Skymoon-Raws] 间谍过家家 第2期 / SPY×FAMILY Season 2 - 26 [ViuTV][WEB-DL][1080p][AVC AAC][繁体外挂]
https://mikanani.me/Home/Episode/234c31e6a73fb73156dce47280848e7328a10dd4

加个规则修正即可，晚点有空我加下

已提交，手动同步下规则，清空所有缓存后再试试

你那能搜出来吗，搜索词没变还是E01，搜不出来第26集啊，[Skymoon-Raws] 间谍过家家 第2期 / SPY×FAMILY Season 2 - 26 [ViuTV][WEB-DL][1080p][AVC AAC][繁体外挂]

搜索你可以尝试调整参数 MIN_COUNT，具体说明看文档，不建议太大，比每个站点搜索到的结果数量稍微大一点就行了
version: '3.0'
services:
   jproxy:
      image: luckypuppy514/jproxy:latest
      container_name: jproxy
      restart: unless-stopped
      environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
      - JAVA_OPTS=-Xms512m -Xmx512m
      - MIN_COUNT=调大这个值，默认是6
      ports:
      - 8117:8117
      volumes:
      - /docker/jproxy/database:/app/database

谢谢，我改成500了，但没去掉集和季啊，都是带个01的，不过我试了下其他动漫确实去掉了只是这部没有。
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [SPYxFAMILY 01], Offset: 0, Limit: 100, Categories: [5000, 5050, 5070, 124339]
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [SPY FAMILY 01], Offset: 0, Limit: 100, Categories: [5000, 5050, 5070, 124339]
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [Spy x Family Part 2 01], Offset: 0, Limit: 100, Categories: [5000, 5050, 5070, 124339]
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [SPY x FAMILY S2 01], Offset: 0, Limit: 100, Categories: [5000, 5050, 5070, 124339]
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [SPYxFAMILY S2 01], Offset: 0, Limit: 100, Categories: [5000, 5050, 5070, 124339]
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [SPY FAMILY S2 01], Offset: 0, Limit: 100, Categories: [5000, 5050, 5070, 124339]
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [SPY x FAMILY 01], Offset: 0, Limit: 100, Categories: [5000, 5050, 5070, 124339]
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [间谍过家家 01], Offset: 0, Limit: 59, Categories: [5000, 5050, 5070, 124339]
[Info] ReleaseSearchService: Searching indexer(s): [MioBT] for Term: [SPY×FAMILY 間諜家家酒 01], Offset: 0, Limit: 10, Categories: [5000, 5050, 5070, 124339]

这是第二季第一集全部的搜索日志。

500 可能不够，是几个标题累计的数量，我这边是有 PT 站，有比较规范的 S2 01 所以没问题

license: MIT


text:
Add API to manipulate tabs

Can you please add API method to menipulate tabs. Like RemoveTab() and disableTab() methods.

Sorry for my very late reply.
To remove / add or disable tabs, you can use ng-repeat.
Template:
<v-tabs class="vTabs--default" horizontal control="horizontalTabs" active="horizontalTabs.active">
  <v-tab ng-repeat="page in pages" ng-disabled="page.isDisabled" ng-bind="page.title"></v-tab>
</v-tabs>

<v-pages class="vPages--default" active="horizontalTabs.active">
  <v-page ng-repeat="page in pages">

  </v-page>
</v-pages>

Controller:
$scope.pages = [ ... ];

$scope.addPage = function (page) {
  $scope.pages.push(page);
}

$scope.removePage = function (index) {
  $scope.pages.splice(index, 1);
}

$scope.disablePage = function (index) {
  $scope.pages[index].isDisabled = true;
}

thanks. it looks good. I'll try it when i have some time.

repo: LukaszWatroba/v-tabs

license: mit

license_source: bigquery


text:
🛑 Bank of China Australia is down

In c01a893, Bank of China Australia (https://obdevp.bank-of-china.net.au/cds-au/v1/banking/products) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Bank of China Australia is back up in 71594ca.

repo: LukePrior/OpenBankingUptime


text:
🛑 Greater Bank is down

In affb8af, Greater Bank (https://public.cdr-api.greater.com.au/cds-au/v1/banking/products) was down:

HTTP code: 403
Response time: 750 ms

Resolved: Greater Bank is back up in d48f4f8.


text:
Blogging with latex

Hi, a couple of months ago i discover latex and the things you can do with it, the thing is, i would like to start a personal blog using only latex to avoid Markdown since it's doesn't have math features just like .tex files.
I'm thinking about using some kind of method of compilation to generate .html files, but how can this be superior to other formats, since I'm pretty new to latex i think this is a good place to ask.
Thanks in advance :smile:

to make an html file from latex use the htlatex command

There probably is a need for a guide on how to use static site generators in general. If anyone's interested in making some simple guide about these, I can make one about Jekyll.

authors: CarlosLoboxyz tenseoverflow yit6

repo: LukeSmithxyz/landchad

license: Unlicense


text:
Output Addresses From Capture for void* and Opaque* Struct Members

Fixes issue #683
Adds versions of DataPointerDecoderToString(), each one converting
the address from the capture file for the pointer in question,
and plumbs them in during code generation for Vulkan struct members
that are void pointers or pointers to opaque structs like platform
window handles or external memory.

CI gfxreconstruct build # 1898 running.

CI gfxreconstruct build # 1898 passed.

CI gfxreconstruct build queued with queue ID 27010.

CI gfxreconstruct build # 1905 running.

CI gfxreconstruct build queued with queue ID 27039.

CI gfxreconstruct build # 1906 running.

CI gfxreconstruct build # 1906 passed.

source: gharchive/pull-request

authors: andrew-lunarg ci-tester-lunarg

repo: LunarG/gfxreconstruct


text:
Check style on mobile

Some element my overflow on mobile. Need to make a full check

Search bar is outside the top bar on mobile

repo: Lunik/Tcloud


text:
Bug: thumbnail image resize

If you input image with clicked coordinates, I found the app throw an error. The error is caused by two masks has different size when computing IOU,.
It cause by the code in app.py:
# about line 161-165
w, h = pil_image.size
#if w > 800:
#    pil_image.thumbnail((800, 800*h/w))
#    input_image.thumbnail((800, 800*h/w))
#    coords = str(int(int(coords.split(',')[0]) * 800 / w)) + ',' + str(int(int(coords.split(',')[1]) * 800 / w))

comment thumbnail methods fix this issue but not sure I should do this.

Indeed we found it could cause error previously (@Jingkang50), we will fix it soon!

repo: Luodian/RelateAnything


text:
Asteroids blocking spawn location

Asteroids can surround the starting location or the spawn can even be on an asteroid, making the episode unplayable.
Possible solutions:

keep a small area (like 3x3) around the spawn free of all map features
make asteroids spawn more sparsely instead of in large blocks; makes map more connected while still being moving obstacles

Related: Relics are not necessarily reachable from spawns (see 2nd screenshot).
Example:

Relic node tiles not being reachable in my opinion is perfectly fine. The way to win the game now is to accrue the most energy in the game.
I am open to modifying the initial asteroid tile placements though. But i would like to avoid writing an algo to check pathability from team A to B which can slow down the env / reject maps.

Mostly fixed with #16


text:
🛑 EnderChest（末影箱-云盘） is down

In 86611ba, EnderChest（末影箱-云盘） (https://enderchest.anavi.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: EnderChest（末影箱-云盘） is back up in abd4041 after 7 minutes.

repo: LxnChan/status


text:
🛑 EnderChest（末影箱-云盘） is down

In 227de45, EnderChest（末影箱-云盘） (https://enderchest.anavi.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: EnderChest（末影箱-云盘） is back up in c66e478.


text:
🛑 EnderChest（末影箱-云盘） is down

In 9155575, EnderChest（末影箱-云盘） (https://enderchest.anavi.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: EnderChest（末影箱-云盘） is back up in c824836 after 5 minutes.


text:
🛑 Official（泠泫凝的异次元空间-主页） is down

In c8ae48c, Official（泠泫凝的异次元空间-主页） (https://lxnchan.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Official（泠泫凝的异次元空间-主页） is back up in 60a9cb4 after 31 minutes.


text:
🛑 Official（泠泫凝的异次元空间-主页） is down

In dd03461, Official（泠泫凝的异次元空间-主页） (https://lxnchan.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Official（泠泫凝的异次元空间-主页） is back up in f30b707 after 28 minutes.


text:
🛑 EnderChest（末影箱-云盘） is down

In 78ec4c8, EnderChest（末影箱-云盘） (https://enderchest.anavi.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: EnderChest（末影箱-云盘） is back up in fe7c5c3 after 5 minutes.


text:
🛑 Official（泠泫凝的异次元空间-主页） is down

In f919507, Official（泠泫凝的异次元空间-主页） (https://lxnchan.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Official（泠泫凝的异次元空间-主页） is back up in 0b7f2ad after 6 minutes.


text:
Screen tearing + intro cutscene not displayed correctly (MGS3)

So, i don't know why but i have screen tearing i don't know if it's cause by the patch or update 1.4.0 but i didn't have the issue before 1.4.0.
However i have this issue.

can you describe it better?

Okay i think i'm wrong for the screenshot. I thought the screen background for intro to be completely black. However if you look more clearly there's some brighter background around the text. I guess it's normal behaviour.
However with more research i suppose my issues is not related to MGSHDfix. It's FPS unlocker the culprit. So i'm gonna close this issue.

authors: LorenzoKy MasterDarkseid

repo: Lyall/MGSHDFix


text:
🛑 Home - Landing Page is down

In e0033d2, Home - Landing Page (https://lyrid.io/assets/images/resources/logo_transparent.png) was down:

HTTP code: 500
Response time: 137 ms

Resolved: Home - Landing Page is back up in 9ddb630.

repo: LyridInc/statuspage


text:
🛑 Blog Cyberlife is down

In 1360148, Blog Cyberlife (https://cyberlife.blog) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Blog Cyberlife is back up in 04c8cfd after 8 minutes.


text:
[Bug Report] 向面板发送api请求时出现500错误

Platform
Windows 11
Panel Version
10.1.0
Daemon Version (Optional)
4.3.0
Recurrence Probability
100%
Bug Description
向面板发送api请求时出现500错误
错误JSON:{'status': 500, 'data': "TypeError: Cannot read properties of undefined (reading 'toLowerCase')", 'time': 1726997314054}
请求API:GET /api/service/remote_service_instances
请求参数:
paramas = {
"page":int(page),
"page_size":int(pagesize),
"apikey":self.apikey,
"daemonId":self.daemonId
}

已经自行解决,故此关闭

估计是没有传递 instance_name 之类的参数，导致查询出错。

repo: MCSManager/MCSManager


text:
added custom timestamp in case of namemc block

bad code but It Works :DDDDDDDDDDDDDDDDD
Wpow

Can't merge this because of conflicts. I'll work on this in the recode.

Can't merge this because of conflicts. I'll work on this in the recode.

authors: Kqzz sneakers

repo: MCsniperPY/MCsniperPY


text:
Set requirements to more flexible version

The current requirements makes it such as installing makes it incompatible with newer pytorch or transformers version
They should be set to minimal requirements

Hey Nicolas, apologies for the late response-just did this with version 0.3.0!


text:
Inline nodes don't return parent

Describe the bug
When I am trying to get a parent of node with type inline I get nil. I am using neovim method tsnode:parent(). It works for all nodes but inline ones.
I am not sure though if the bug relates to this parser.
Code example
### Test Heading

- test list

Expected behavior
When you get a parent node of an inline element (text test list and Test Heading) you get paragraph and atx_heading nodes respectively
Actual behavior
You get nil

It does relate to the parser. The inline nodes are special, they work kind of like the script node in html, where the contents are parsed as javascript. In this grammar, the content of the inline nodes in the top level grammar are parsed as "inline markdown". This means, that there is one tree for every inline node, and the tsnode in your code is the root node of that tree.
I'm not sure what the most efficient way to get the "parent" is in neovim, i.e. the node that the "inline tree" is attached to. I guess if you have access to the top level markdown tree (let's call it tree) you could do
tree:named_node_for_range(node:range())

Thanks, this worked, though I am also not sure how efficient this is.
However, what is the reason for having separate trees? I don't think I understand.

Markdown does not have a syntax that's nice to parse, wince it's optimized for being readable to humans instead. That's why it's suggested to parse it in two passes. With tree sitter that's not really possible, but the double tree structure is my way of working around it.

Closing this as the problem seems to be solved.

authors: MDeiml sarmong

repo: MDeiml/tree-sitter-markdown


text:
Remove Haybaler output before rerunning haybaler

@colindaven yesterday Ilona needed haybaler but she wanted different rpmm and readcount limit. So first she run postprocess and then she wanted to run haybaler again but with the adjusted limits.
Because Haybaler always wants to add new samples to the existing haybaler csv files and the files with all samples already exist from the first run, nothing changes.
So I guess it would make sense to delete the haybaler output files when starting run_haybaler.sh

Ok, I'll take care of it. Thanks - I thought you were on holiday already? Enjoy it !

not yet, monday and tuesdayI had seminar and until the end of the week I do homeoffice, so I can do this too.

Ok, I'm still having quite a lot of problems testing the new env on the dev branch.
https://github.com/MHH-RCUG/Wochenende/issues/149

authors: colindaven poer-sophia

repo: MHH-RCUG/haybaler


text:
Bhbbranch2

These are mostly simple changes to the home page, but changes I think should be examined/pulled sooner rather than later, especially considering Sebastian is about to change the whole formatting probably.

It's not necessary, but I believe it will be helpful for hypothetical
visitors to our website. However, there's not much stuff on our website
yet, so it might be reasonable to consider adding more stuff on our home
page to make it worth the extra convenient access.
Benja-man
On Mon, Oct 23, 2017 at 9:48 AM, stlgolfer notifications@github.com wrote:

@stlgolfer commented on this pull request.
In views/partials/header.ejs
https://github.com/MICDSRobotics/Technomaric5190Website/pull/25#discussion_r146290810
:

@@ -49,6 +49,7 @@ a {

		Home

The title of the website, if clicked, will take you home. Do you think
this is still necessary (serious question)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/MICDSRobotics/Technomaric5190Website/pull/25#pullrequestreview-71210689,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AeEFBhEYdW_Q842hJPRhEFTc0cXUbV8Bks5svKcqgaJpZM4QAB4u
.

--
Benjamin E. Hollander-Bodie
Upper School Student
MICDS


text:
Scrolling on mobile device

When scrolling on the complex portal and you tap on the CP-viewer you can't scroll you have to 'jump' over the viewer to continue scrolling.

ok, will have a look at why

It was also not opening the bar but opening UniProt on "tapping" the protein icon.
Different issue?

i'll look at it with this issue,
c

This appears to be an Android issue as it doesn't happen on Max's iphone.

Think both these issues are fixed in MICommunity:master branch now.
It will still only scroll page when it is the background that is touched, if it is an item/glyph in the display that is the start point then that thing will be moved within the viewer.
I'm closing because I think its fixed; reopen if I'm mistaken about that...

authors: bmeldal colin-combe tschaka1904

repo: MICommunity/ComplexViewer


text:
Vagrantfile is out of date

Environment:
OS: Debian GNU/Linux 11 (bullseye)
Other: Logged into vagrantcloud
Description:
Vagrant cannot be used to build MISP
Expected Behaviour:
Running vagrant up in the misp-vagrant dir brings up the project in a Vagrant box.
Actual Behaviour:
Vagrant fails to retrieve the specified box from vagrantcloud with a 404
Build terminates and MISP cannot be used
Steps to Reproduce:
$ cd misp-vagrant
$ vagrant up
Suggested Fix
Update the Vagrantfile to build MISP using a more recent version of Ubuntu

@mikrl Feel freee to checkout my pull request and see if it helps your issue.

authors: defendable-hanspetter mikrl

repo: MISP/misp-vagrant


text:
Error when running roslaunch kimera_semantics_ros kimera_semantics.launch play_bag:=true

Hi,
When I run roslaunch kimera_semantics_ros kimera_semantics.launch play_bag:=true I get these errors:

And the result in rviz is like this:

Can you try this #61 and see if it solves the issue?

Great! It solved the issue. Thank you!

authors: ToniRV mohammad-h-b

repo: MIT-SPARK/Kimera-Semantics


text:
Add testing for individual form components frontend

Unit tests for input fields and form controls.

Will be tackled in new task moving to RTL from enzyme. Closing in favour of new issues.

repo: MLCochrane/gosyp


text:
Refer to workspace symbols in chat window

Same functionality as #88 but at a workspace level instead of document(buffer) level

Could make use of https://neovim.io/doc/user/lsp.html#vim.lsp.buf.workspace_symbol()


text:
Geolocation integrated

Fixed the Merge conflicts occurring caused due to merging #36 and #34
After the final changes the Weather App looks good and flawless.

Awesome work done by @ankitaugale23 and @JyotimoyKashyap on the solving the Geolocation problem
Closes #3

@PAOK-2001, @ankitaugale23 @JyotimoyKashshyap @yashika51 please review.

Looks good! It integrates all the changes thus far. Should get merged to work untop a stable version.
Nice work everyone.

Looks great. Great work for solving the merge conflicts.


text:
Homepage Design Improvement

Proposed Enhancements:
Hero Section:
Redesign the hero section with better alignment, font styling, and padding adjustments to make it more visually appealing.
Consider adding a background image or gradient that aligns with the theme of farm management, making the "Get Started" button more prominent.
Feature Section:
Enhance the feature list by incorporating icons for each feature (e.g., crops, livestock, performance) to add more visual clarity and interest.
Improve the typography to make it more consistent with modern design trends (e.g., bolder headings, smaller subtext).
Vision and Mission Section:
Add subtle background color changes or card-style layouts to distinguish these sections better, making the text more readable and visually separated.
Consider adding imagery or illustrations that reflect the company's vision (e.g., fields, technology, or farmers).
Call-to-Action Buttons:
Increase the size of "Sign Up" and "Sign In" buttons at the bottom for better accessibility.
Ensure button colors contrast well against the background, enhancing visibility and encouraging interaction.

Great idea ! Sure you can definitely work .
All The Best,
Make Shure To add your details in Contributing/Readme.md After Contribution

Great idea ! Sure you can definitely work .
All The Best,
Make Shure To add your details in Contributing/Readme.md After Contribution

@MOHAMMED-IQRAMUL , please review my pr. Thanks

repo: MOHAMMED-IQRAMUL/FarmRuler


text:
1.2 Data Preprocessing

Data exploration and preprocessing
As a preprocessing step, convert categorical features to numerical features, e.g., by means of a one-hot encoding, and apply a normalization to map all features between [0, 1]. Assign labels to the dataset
indicating the true loan attribution outcomes for supervised learning. Clearly define categories or classes representing loan approval or denial. Additionally, reserve 20% of the dataset for final testing and assessment of the robustness of the models.

Completato ma con forse qualche dettaglio in più che va aggiunto nel report

authors: Distii MR-NBD


text:
Iterations on completion in UI are incorrect

UI iterations show the iteration history count rather than the actual number of iterations
┆Issue is synchronized with this Asana task

history was dropped in #86, so this issue is no longer valid. There’s no sense of a “iteration” in COINSTAC’s core, although perhaps there should be.

authors: rssk swashcap

repo: MRN-Code/coinstac


text:
Each work only has two performances

Hello, in the dataset you shared in the Google Drive link, there are only two performances for each work. But some of the work mentioned each work has 13 performances for cover song identification training. Could you provide that version?

it is in the benchmark subset

repo: MTG/da-tacos


text:
Implement Launcher with auto-update feature

There is already a client launcher project which is pretty basic.
It's missing a dialog to configure the game client (resultion, sound etc.) and the auto-update feature.
We could implement auto-update compatible to the original launcher, and/or make our own (e.g. with torrents).

I would like to do this, i was thinking on using WPF and to move all the current ClientLauncher to this and the configuration to here, but i will need some more of your opinions, maybe a sketch on how it should like.
Maybe we can use Mahapps + MaterialDesign, What do you think?

Is Metro still a thing in 2019? :D
Well, I’m fine with any UI technology or style as long as the actual logic is independent from it.
Would be great if the style or images could be configurable.

Dunno just was suggesting something,yep with MVVM we can do that, all the logic is outside the UI and we can have multiple UIs using the same logic, will start working on it when i have the time then

I would be interested in doing that too. I would use Java or Kotlin for the job and JavaFx or TornadoFx as GUI frameworks.

Thanks for your interest, but honestly I would rather keep it in C# than introducing another language and more frameworks to this project.

I am fine with that too :) I think there is no launcher included right now right?

There is, but just a very basic one:
https://github.com/MUnique/OpenMU/tree/master/src/ClientLauncher

I'd like to close this issue for now. One reason is, that I'd like to keep the scope of the project a bit narrower. It never had a high priority for me and a good launcher can be a big project on its own and doesn't have to be bound to OpenMU or MU Online in general.
If you still want to develop a launcher for OpenMU, feel free to move your code to a separate repository. However, if you need assist or are missing APIs in OpenMU, feel free to open a new issue.

repo: MUnique/OpenMU


text:
Flights Page

Flight identifiers link to a plane data page
Admin: editable fields
Admin: add button

I added the flight identifiers link to the plane data page

authors: clintBock vincent-h-lee

repo: MVCK/WackyFlights


text:
[QUESTION] Excel Pivot Table

Sorry if i'm out of topic or asking the same question..
is there any function that i could generate pivot table for excel file?

I'm afraid not: https://github.com/PHPOffice/PHPExcel/issues/313

authors: patrickbrouwers yoseppiedro

repo: Maatwebsite/Laravel-Excel


text:
Add row before headers row when I use Export from view

Hello! I use 3.1 version of Laravel Excel on Laravel 5.8. with PHP 7.3.5. Can anybody advice me, is it possible to add a row of some merged cells before headers, when I use Export from view functionality? ( blade view has a table with headers and data)
Thanks!

Have you tried adding the row to your table?

Thanks. Yes, I do, and it's works. But I think there is a some kind of  package functionality to do it. May be I can put row after latest row, is it possible to get latest row number?

Adding an extra row to the table sounds like an easy enough solution to me, or do I miss something?

Thanks for your answer. Adding an extra row to the table  in the blade - the simplest way,you're right


text:
Run Queue Without Job chaining

Requirements
Please take note of our contributing guidelines: https://docs.laravel-excel.com/3.1/getting-started/contributing.html
Filling out the template is required. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
Mark the following tasks as done:

[x] Checked the codebase to ensure that your feature doesn't already exist.
[x ] Checked the pull requests to ensure that another person hasn't already submitted the feature or fix.
[ ] Adjusted the Documentation.
[ ] Added tests to ensure against regression.

Description of the Change
This adds a concern which will dispatch queued jobs without chaining.
Why Should This Be Added?
It provides a solution for two issues I ran into with chaining. (1) For extra large files being processed the size of the chain exceeded the size limits of the queue. (2) Chaining runs each job subsequently so you lose the speed gains from running concurrent jobs.
Benefits
Your processing of a file can run jobs concurrently and thus be a lot faster.
Possible Drawbacks
Because the jobs can be run concurrently the AfterImportJob is ignored.
Verification Process
I've tested it and it works well. Because it's a new concern and the limited scope in which it works it does not break anything else.
Applicable Issues
None

Debating here if the name should change to ShouldQueueWithoutChaining or QueueWithoutChaining since it could effectively replace ShouldQueue.

Can you provide some tests and a documentation update, thanks.

Ping @jonrobinson

@patrickbrouwers Yeah sorry, crazy last few weeks. Will try to take care of this soon. One caveat I'm just realizing now is that we can't specify the queue when I add this.
Ideas on how to solve that?
The only thing I can think of at the moment is adding a 4th parameter to the queue() function which is the queue name.

@jonrobinson no problem!
Perhaps you could continue this PR: https://github.com/Maatwebsite/Laravel-Excel/pull/2513 and pass those kind of queue props to the actual jobs?

@patrickbrouwers ah yes. I think that would work!

@patrickbrouwers A little late but we got it done if you want to review.

@jonrobinson no worries, sometimes things get in the way :) I'll have a look on monday!

authors: jonrobinson patrickbrouwers


text:
🛑 Immybot is down

In 9d79ad2, Immybot (https://machado.immy.bot) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Immybot is back up in bf20e59 after 16 minutes.

repo: MachadoConsulting/Upptime


text:
Future not completed

Если происходит какая-то проблема во время выполнения FinishAuthorize и возникает ошибка
TimeoutException after 0:00:40.000000: Future not completed
все данные полученные с сервера до приложения не доходят
[Token] {Amount: 10000, OrderId: 57475, Language: ru, CustomerKey: kultpohod_10, PayType: O, TerminalKey: TestSDK, Token: 3289b69e44b667c44659ae64fd644b5cc9cf2266d0cd0f881801dd9e8548417f}
[RawRequest] {"Amount":10000,"OrderId":"57475","Language":"ru","CustomerKey":"kultpohod_10","PayType":"O","TerminalKey":"TestSDK","Token":"3289b69e44b667c44659ae64fd644b5cc9cf2266d0cd0f881801dd9e8548417f"}
[RawResponse] {"Success":true,"ErrorCode":"0","TerminalKey":"TestSDK","Status":"NEW","PaymentId":"800000084910","OrderId":"57475","Amount":10000}
[Response] InitResponse(Success: true, Status: Status.newest, ErrorCode: 0, Message: null, Details: null, TerminalKey: TestSDK, Amount: 10000, OrderId: 57475, PaymentId: 800000084910, PaymentURL: null)
[Token] {PaymentId: 800000084910, CardData: tPJwNsDEwdC7pJGM5tGxFZbM01EQifwYVEiffKwrSdV+c7deKPfue14YjN+Gh4XgXJI26mZHx/xoqiUQX4q28yhjgiML+xL2A5AmvW0cDDBWsuTgiwdJMB3zJofLkVXaCovnPuxGc4tpaOo3T4e/yNum1NHLYt9wWGzxwXW00D/3Uy0yI+v09yd9QYYKh6Ykl1ua/4oqp0Z18btY7Gu1vmox6XaTZ7akmvpfXHq1r/hFydu7kCzq77jvhwDvAOmmYCyIHzufy67GDa1K5S2x1pLcx1ISE9s6eqMjKdIMg5uY9MQUeyGbFizD8MwhdjK6AxY4ctvXQ3Js1YnNVNDWBg==, TerminalKey: TestSDK, Token: d6cb6b058a98649f0108310f59a5c844292bf93125f37a42d7965741cdfc4be3}
[RawRequest] {"PaymentId":800000084910,"CardData":"tPJwNsDEwdC7pJGM5tGxFZbM01EQifwYVEiffKwrSdV+c7deKPfue14YjN+Gh4XgXJI26mZHx/xoqiUQX4q28yhjgiML+xL2A5AmvW0cDDBWsuTgiwdJMB3zJofLkVXaCovnPuxGc4tpaOo3T4e/yNum1NHLYt9wWGzxwXW00D/3Uy0yI+v09yd9QYYKh6Ykl1ua/4oqp0Z18btY7Gu1vmox6XaTZ7akmvpfXHq1r/hFydu7kCzq77jvhwDvAOmmYCyIHzufy67GDa1K5S2x1pLcx1ISE9s6eqMjKdIMg5uY9MQUeyGbFizD8MwhdjK6AxY4ctvXQ3Js1YnNVNDWBg==","TerminalKey":"TestSDK","Token":"d6cb6b058a98649f0108310f59a5c844292bf93125f37a42d7965741cdfc4be3"}
[RawResponse] {"Success":true,"ErrorCode":"0","Message":"OK","Version":"1.0.0"}
[Response] Check3DSVersionResponse(Success: true, Status: null, ErrorCode: 0, Message: OK, Details: null, Version: 1.0.0, TdsServerTransID: null, ThreeDSMethodURL: null)
[Token] {CardData: tPJwNsDEwdC7pJGM5tGxFZbM01EQifwYVEiffKwrSdV+c7deKPfue14YjN+Gh4XgXJI26mZHx/xoqiUQX4q28yhjgiML+xL2A5AmvW0cDDBWsuTgiwdJMB3zJofLkVXaCovnPuxGc4tpaOo3T4e/yNum1NHLYt9wWGzxwXW00D/3Uy0yI+v09yd9QYYKh6Ykl1ua/4oqp0Z18btY7Gu1vmox6XaTZ7akmvpfXHq1r/hFydu7kCzq77jvhwDvAOmmYCyIHzufy67GDa1K5S2x1pLcx1ISE9s6eqMjKdIMg5uY9MQUeyGbFizD8MwhdjK6AxY4ctvXQ3Js1YnNVNDWBg==, DATA: {}, PaymentId: 800000084910, TerminalKey: TestSDK, Token: d6cb6b058a98649f0108310f59a5c844292bf93125f37a42d7965741cdfc4be3}
[RawRequest] {"CardData":"tPJwNsDEwdC7pJGM5tGxFZbM01EQifwYVEiffKwrSdV+c7deKPfue14YjN+Gh4XgXJI26mZHx/xoqiUQX4q28yhjgiML+xL2A5AmvW0cDDBWsuTgiwdJMB3zJofLkVXaCovnPuxGc4tpaOo3T4e/yNum1NHLYt9wWGzxwXW00D/3Uy0yI+v09yd9QYYKh6Ykl1ua/4oqp0Z18btY7Gu1vmox6XaTZ7akmvpfXHq1r/hFydu7kCzq77jvhwDvAOmmYCyIHzufy67GDa1K5S2x1pLcx1ISE9s6eqMjKdIMg5uY9MQUeyGbFizD8MwhdjK6AxY4ctvXQ3Js1YnNVNDWBg==","DATA":{},"PaymentId":800000084910,"TerminalKey":"TestSDK","Token":"d6cb6b058a98649f0108310f59a5c844292bf93125f37a42d7965741cdfc4be3"}
[VERBOSE-2:ui_dart_state.cc(199)] Unhandled Exception: TimeoutException after 0:00:40.000000: Future not completed
[HTTP Error] TimeoutException after 0:00:40.000000: Future not completed
[RawResponse] {"Success":false,"ErrorCode":"703","Message":"Не получилось пополнить карту. Попробуйте позже","TerminalKey":"TestSDK","Status":"REJECTED","PaymentId":"800000084910","OrderId":"57475","Amount":10000}
[Response] FinishAuthorizeResponse(Success: false, Status: Status.rejected, ErrorCode: 703, Message: Не получилось пополнить карту. Попробуйте позже, Details: null, TerminalKey: TestSDK, Amount: 10000, OrderId: 57475, PaymentId: 800000084910, CardId: null, ACSUrl: null, AcsTransId: null, MD: null, PaReq: null, RebillId: null, FallbackOnTdsV1: null, TdsServerTransId: null)

Здравствуйте @angry48, можете описать ваш кейс, какая происходит проблема? Приложите минимально воспроизводимый код.
TimeoutException возникает лишь в том случае, если запрос (Future) не успевает обработаться в течении 40 секунд. Возможно нам стоит вынести сериализацию из этого метода...

Вопрос в том что бы получить данные от вашего плагина, т.к. в консоль он их пишет после сообщения о тайм-ауте

@angry48 меня больше интересует как исправить этот кейс. А чтобы его исправить его нужно как минимум воспроизвести.
Насколько я понимаю консоль он их пишет, потому-что он их завершает, но после выхода времени. А вам данные не приходят, так как там используется Completer который срабатывает в catchError быстрее чем в then...

@angry48 меня больше интересует как исправить этот кейс. А чтобы его исправить его нужно как минимум воспроизвести.
Насколько я понимаю консоль он их пишет, потому-что он их завершает, но после выхода времени. А вам данные не приходят, так как там используется Completer который срабатывает в catchError быстрее чем в then...

Hello, I have the same issue how to solve this issue?

repo: MadBrains/Tinkoff-Acquiring-SDK-Flutter


text:
Running into a weird issue, with the getting started example

I am running a simple example shared in a julia forum here,
using ExaModels, MadNLP, CUDA
function luksan_vlcek_model(
N;
T = Float64, # precision
backend = nothing, # GPU backends, e.g., CUDABackend()
kwargs... # solver options
)
c = ExaCore(T, backend)
x = variable(c, N; start = (mod(i, 2) == 1 ? -1.2 : 1.0 for i = 1:N))

constraint(
c,
3x[i+1]^3 + 2 * x[i+2] - 5 + sin(x[i+1] - x[i+2])sin(x[i+1] + x[i+2]) + 4x[i+1] -
x[i]exp(x[i] - x[i+1]) - 3 for i = 1:N-2
)
objective(c, 100 * (x[i-1]^2 - x[i])^2 + (x[i-1] - 1)^2 for i = 2:N)
return ExaModel(c; kwargs...)

end;
m = luksan_vlcek_model(10000; backend = CUDBackend())
result = madnlp(m; tol = 1e-8)
I am running into the following error,
ubuntu@gpu-cuda-server:~/julianlpcuda$ julia test_madnlp.jl
┌ Warning: ExaCore(T, backend) is deprecated. Use ExaCore(T; backend = backend) instead
└ @ ExaModels ~/.julia/packages/ExaModels/PyPin/src/nlp.jl:145
ERROR: LoadError: Scalar indexing is disallowed.
Invocation of getindex resulted in scalar indexing of a GPU array.
This is typically caused by calling an iterating implementation of a method.
Such implementations do not execute on the GPU, but very slowly on the CPU,
and therefore should be avoided.
If you want to allow scalar iteration, use allowscalar or @allowscalar
to enable scalar iteration globally or for the operations in question.
Stacktrace:
[1] error(s::String)
@ Base ./error.jl:35
[2] errorscalar(op::String)
@ GPUArraysCore ~/.julia/packages/GPUArraysCore/GMsgk/src/GPUArraysCore.jl:155
[3] _assertscalar(op::String, behavior::GPUArraysCore.ScalarIndexing)
@ GPUArraysCore ~/.julia/packages/GPUArraysCore/GMsgk/src/GPUArraysCore.jl:128
[4] assertscalar(op::String)
@ GPUArraysCore ~/.julia/packages/GPUArraysCore/GMsgk/src/GPUArraysCore.jl:116
[5] getindex
@ ~/.julia/packages/GPUArrays/OKkAu/src/host/indexing.jl:48 [inlined]
[6] macro expansion
@ ~/.julia/packages/MadNLP/RRGPv/src/matrixtools.jl:131 [inlined]
[7] macro expansion
@ ./simdloop.jl:77 [inlined]
[8] force_lower_triangular!(I::CuArray{Int32, 1, CUDA.Mem.DeviceBuffer}, J::CuArray{Int32, 1, CUDA.Mem.DeviceBuffer})
@ MadNLP ~/.julia/packages/MadNLP/RRGPv/src/matrixtools.jl:130
[9] create_kkt_system(::Type{MadNLP.SparseKKTSystem}, cb::MadNLP.SparseCallback{Float64, CuArray{Float64, 1, CUDA.Mem.DeviceBuffer}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, ExaModel{Float64, CuArray{Float64, 1, CUDA.Mem.DeviceBuffer}, ExaModelsKernelAbstractions.KAExtension{Float64, CuArray{Float64, 1, CUDA.Mem.DeviceBuffer}, Nothing, CuArray{Tuple{Int64, Int64}, 1, CUDA.Mem.DeviceBuffer}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, CUDABackend}, ExaModels.Objective{ExaModels.ObjectiveNull, ExaModels.SIMDFunction{ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(), Int64, ExaModels.Node1{typeof(abs2), ExaModels.Node2{typeof(-), ExaModels.Node1{typeof(abs2), ExaModels.Var{ExaModels.Node2{typeof(-), ExaModels.ParSource, Int64}}}, ExaModels.Var{ExaModels.ParSource}}}}, ExaModels.Node1{typeof(abs2), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.Node2{typeof(-), ExaModels.ParSource, Int64}}, Int64}}}, ExaModels.Compressor{Tuple{Int64, Int64, Int64}}, ExaModels.Compressor{NTuple{4, Int64}}}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}}, ExaModels.Constraint{ExaModels.ConstraintNull, ExaModels.SIMDFunction{ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(), Int64, ExaModels.Node2{typeof(^), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, Int64}}, ExaModels.Node2{typeof(), Int64, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, Int64}, ExaModels.Node2{typeof(), ExaModels.Node1{typeof(sin), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, ExaModels.Node1{typeof(sin), ExaModels.Node2{typeof(+), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}}}, ExaModels.Node2{typeof(), Int64, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, ExaModels.Node2{typeof(), ExaModels.Var{ExaModels.ParSource}, ExaModels.Node1{typeof(exp), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.ParSource}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}}}, Int64}, ExaModels.Compressor{NTuple{10, Int64}}, ExaModels.Compressor{NTuple{17, Int64}}}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, Int64}}, MadNLP.MakeParameter{CuArray{Float64, 1, CUDA.Mem.DeviceBuffer}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}}, MadNLP.EnforceEquality}, ind_cons::@NamedTuple{ind_eq::CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, ind_ineq::CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, ind_fixed::CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, ind_lb::CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, ind_ub::CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, ind_llb::CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, ind_uub::CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}}, linear_solver::Type{UmfpackSolver}; opt_linear_solver::MadNLP.UmfpackOptions, hessian_approximation::Type)
@ MadNLP ~/.julia/packages/MadNLP/RRGPv/src/KKT/sparse.jl:218
[10] MadNLPSolver(nlp::ExaModel{Float64, CuArray{Float64, 1, CUDA.Mem.DeviceBuffer}, ExaModelsKernelAbstractions.KAExtension{Float64, CuArray{Float64, 1, CUDA.Mem.DeviceBuffer}, Nothing, CuArray{Tuple{Int64, Int64}, 1, CUDA.Mem.DeviceBuffer}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, CUDABackend}, ExaModels.Objective{ExaModels.ObjectiveNull, ExaModels.SIMDFunction{ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(), Int64, ExaModels.Node1{typeof(abs2), ExaModels.Node2{typeof(-), ExaModels.Node1{typeof(abs2), ExaModels.Var{ExaModels.Node2{typeof(-), ExaModels.ParSource, Int64}}}, ExaModels.Var{ExaModels.ParSource}}}}, ExaModels.Node1{typeof(abs2), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.Node2{typeof(-), ExaModels.ParSource, Int64}}, Int64}}}, ExaModels.Compressor{Tuple{Int64, Int64, Int64}}, ExaModels.Compressor{NTuple{4, Int64}}}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}}, ExaModels.Constraint{ExaModels.ConstraintNull, ExaModels.SIMDFunction{ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(), Int64, ExaModels.Node2{typeof(^), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, Int64}}, ExaModels.Node2{typeof(), Int64, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, Int64}, ExaModels.Node2{typeof(), ExaModels.Node1{typeof(sin), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, ExaModels.Node1{typeof(sin), ExaModels.Node2{typeof(+), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}}}, ExaModels.Node2{typeof(), Int64, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, ExaModels.Node2{typeof(), ExaModels.Var{ExaModels.ParSource}, ExaModels.Node1{typeof(exp), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.ParSource}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}}}, Int64}, ExaModels.Compressor{NTuple{10, Int64}}, ExaModels.Compressor{NTuple{17, Int64}}}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, Int64}}; kwargs::@Kwargs{tol::Float64})
@ MadNLP ~/.julia/packages/MadNLP/RRGPv/src/IPM/IPM.jl:155
[11] MadNLPSolver
@ ~/.julia/packages/MadNLP/RRGPv/src/IPM/IPM.jl:115 [inlined]
[12] madnlp(model::ExaModel{Float64, CuArray{Float64, 1, CUDA.Mem.DeviceBuffer}, ExaModelsKernelAbstractions.KAExtension{Float64, CuArray{Float64, 1, CUDA.Mem.DeviceBuffer}, Nothing, CuArray{Tuple{Int64, Int64}, 1, CUDA.Mem.DeviceBuffer}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, CUDABackend}, ExaModels.Objective{ExaModels.ObjectiveNull, ExaModels.SIMDFunction{ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(), Int64, ExaModels.Node1{typeof(abs2), ExaModels.Node2{typeof(-), ExaModels.Node1{typeof(abs2), ExaModels.Var{ExaModels.Node2{typeof(-), ExaModels.ParSource, Int64}}}, ExaModels.Var{ExaModels.ParSource}}}}, ExaModels.Node1{typeof(abs2), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.Node2{typeof(-), ExaModels.ParSource, Int64}}, Int64}}}, ExaModels.Compressor{Tuple{Int64, Int64, Int64}}, ExaModels.Compressor{NTuple{4, Int64}}}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}}, ExaModels.Constraint{ExaModels.ConstraintNull, ExaModels.SIMDFunction{ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(-), ExaModels.Node2{typeof(+), ExaModels.Node2{typeof(), Int64, ExaModels.Node2{typeof(^), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, Int64}}, ExaModels.Node2{typeof(), Int64, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, Int64}, ExaModels.Node2{typeof(), ExaModels.Node1{typeof(sin), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, ExaModels.Node1{typeof(sin), ExaModels.Node2{typeof(+), ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}}}, ExaModels.Node2{typeof(), Int64, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}, ExaModels.Node2{typeof(), ExaModels.Var{ExaModels.ParSource}, ExaModels.Node1{typeof(exp), ExaModels.Node2{typeof(-), ExaModels.Var{ExaModels.ParSource}, ExaModels.Var{ExaModels.Node2{typeof(+), ExaModels.ParSource, Int64}}}}}}, Int64}, ExaModels.Compressor{NTuple{10, Int64}}, ExaModels.Compressor{NTuple{17, Int64}}}, CuArray{Int64, 1, CUDA.Mem.DeviceBuffer}, Int64}}; kwargs::@Kwargs{tol::Float64})
@ MadNLP ~/.julia/packages/MadNLP/RRGPv/src/IPM/solver.jl:10
[13] top-level scope
@ ~/julianlpcuda/test_madnlp.jl:24
in expression starting at /home/ubuntu/julianlpcuda/test_madnlp.jl:24
I have a VM with a GPU RTX A6000, I installed all the drivers that might be needed. Please point out in anything seems missing, that might be throwing errors
julia> CUDA.versioninfo()
CUDA runtime 12.3, artifact installation
CUDA driver 12.3
NVIDIA driver 535.161.8, originally for CUDA 12.2
CUDA libraries:

CUBLAS: 12.3.4
CURAND: 10.3.4
CUFFT: 11.0.12
CUSOLVER: 11.5.4
CUSPARSE: 12.2.0
CUPTI: 21.0.0
NVML: 12.0.0+535.161.8

Julia packages:

CUDA: 5.2.0
CUDA_Driver_jll: 0.7.0+1
CUDA_Runtime_jll: 0.11.1+0

Toolchain:

Julia: 1.10.2
LLVM: 15.0.7

1 device:
0: NVIDIA RTX A6000 (sm_86, 47.532 GiB / 47.988 GiB available)

Oops, my bad. MadNLPGPU needs to be imported. Could you retry with using MadNLPGPU?

@sshin23 , indeed thanks. It was missing madNLPGPU. It works now, there was one small typo in CUDABackend instead of CUDBackend.  other that works like a charm, I changed the N from 10000 to 100000, worked like a charm.
Also, I have some questions around using this with the usual JuMP interface, can I open a discussion around it. The docs aren't that comprehesive at the moment.


text:
🛑 Webblate is down

In 729307d, Webblate (https://weblate.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Webblate is back up in 9d8c852.

repo: Magic-Services/upptime


text:
🛑 Nitter (nitter.net) is down

In 2eb360a, Nitter (nitter.net) (https://nitter.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Nitter (nitter.net) is back up in 50be807.


text:
🛑 Nitter (nitter.net) is down

In 1cc5f25, Nitter (nitter.net) (https://nitter.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Nitter (nitter.net) is back up in bdfa758.


text:
🛑 Nitter (nitter.net) is down

In 4593383, Nitter (nitter.net) (https://nitter.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Nitter (nitter.net) is back up in 467f75a.


text:
🛑 Nextcloud is down

In 44e0c86, Nextcloud (https://nextcloud.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Nextcloud is back up in 805a269 after 10 minutes.


text:
🛑 Libreddit (libreddit.spike.codes) is down

In 0859746, Libreddit (libreddit.spike.codes) (https://libreddit.spike.codes) was down:

HTTP code: 502
Response time: 28557 ms

Resolved: Libreddit (libreddit.spike.codes) is back up in 84ca1ff after 4 hours, 8 minutes.


text:
🛑 Libreddit (libreddit.spike.codes) is down

In 13ad493, Libreddit (libreddit.spike.codes) (https://libreddit.spike.codes) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Libreddit (libreddit.spike.codes) is back up in 3e3755a after 39 minutes.


text:
🛑 Peertube (peertube.tv) is down

In 338696b, Peertube (peertube.tv) (https://tube.tchncs.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Peertube (peertube.tv) is back up in 23f57cf after 5 hours, 42 minutes.


text:
Feature: Home Page Logo

Hi Anton, I was trying to put an image between the side menu button and the site's header.

Is there a way to achieve that?
Thanks

Hi, you can try to use mark_safe
Like
from django.utils.safestring import mark_safe
MATERIAL_ADMIN_SITE = {
'HEADER':  mark_safe(' Donde comemos | Panel de ...'),
...
}

Thank you Anton, i would like to make this as a setting later so when i have some time i'll make a PR with this feature.
Its a good solution, for now.

repo: MaistrenkoAnton/django-material-admin


text:
Interface para criar pacientes e melhoria em como comorbidades são listadas

Deploy
Colocar aplicação em manutenção para rodar migrações de maneira tranquila.
rails db:migrate
rails oneoff:neighborhoods
rails oneoff:disable_no_answers
rails oneoff:inquiry_page
rails oneoff:inquiry

@pedroCervi valeu! Como comentei, o teste do Cypress parece estar quebrado em CI, porque geralmente falha, algumas vezes passa, e quando rodo manualmente ele sempre passa. Deve ser caso da ordem de como o CI está rodando.

@pedroCervi valeu! Como comentei, o teste do Cypress parece estar quebrado em CI, porque geralmente falha, algumas vezes passa, e quando rodo manualmente ele sempre passa. Deve ser caso da ordem de como o CI está rodando.

haha de boa. Nosso primeiro intermitente :heart:

authors: jmonteiro pedroCervi

repo: MakersNetwork/agenda-saude


text:
Fixed offenses goreport

This PR contains:

Fixed some offenses of gofmt
Fixed some offenses of golint

Coverage decreased (-10.4%) to 62.264% when pulling ec17d226aac2831d8e9eb6649764fa6939371fb5 on mresti:fixed_offenses_goreport into 8a9419e861ea02a452fa4744b46d700370f50a47 on ManageIQ-Exchange:master.

authors: coveralls mresti


text:
Restrict ServiceOrder deep_copy to non-cart states

Copying a ServiceOrder should be restricted to those that are not in the cart for the purpose of it becoming a new cart that can be ordered.
@miq-bot bug, services
cc: @AllenBW @imtayadeway

@miq-bot add_label bug, services

Hey I really like this pr, like REALLY really like ;-)

@jntullo Please label fine/yes or fine/no

@miq-bot add_label fine/yes

Fine backport details:
$ git log -1
commit a73e205ad471a28b1d0747ab168a149668f2ce42
Author: Greg McCullough <gmccullo@redhat.com>
Date:   Wed Mar 29 21:19:12 2017 -0400

    Merge pull request #14564 from jntullo/bug/no_duplicates_in_cart_state

    Restrict ServiceOrder deep_copy to non-cart states
    (cherry picked from commit 5ce005bb845c841ce2af65a19e985253f82a63d2)

authors: AllenBW gmcculloug jntullo simaishi

repo: ManageIQ/manageiq


text:
Rename to just currencies

Currencies are not related just to chargeback and we have renaming work in progress:
Per https://github.com/ManageIQ/manageiq-schema/pull/421 and https://github.com/ManageIQ/manageiq/pull/19350

@miq-bot assign @carbonin

@lpichler Can you please apply this change to the table rename PR? We need both changes in the same PR for them to pass specs

authors: carbonin d-m-u


text:
Non UI workers can't send email bodies

Only the UI worker had the require 'haml-rails' so emails sent from
the UI had the body, but if a non ui worker like automate sent the
email it wont have the body. The specs have the require 'haml-rails'
so they always worked.
https://bugzilla.redhat.com/show_bug.cgi?id=1209557

@gmcculloug @jrafanie @Fryguy
Please review

Looks good to me.  Regardless of what we do with the initializer in regards to requiring haml-rails only for UI and web service worker, it's good to make this dependency explicit here.

authors: jrafanie mkanoor


text:
Fixed the way link to Security Groups is being built for Cloud Provider

Fixed the way link to Security Groups is being built on a Cloud Provider summary screen, existing way of building link to list of Security Groups builds a link to security groups that belong to cloud network, when clicking on the link it jumps to cloud network controller and no longer is in ems_cloud control which makes back button on summary screen to point to cloud network summary screen instead of ems_cloud summary screen.
https://bugzilla.redhat.com/show_bug.cgi?id=1342231
@Ladas please review/test, made changes to build link in ems_cloud textual helper itself and make it go thru https://github.com/ManageIQ/manageiq/blob/master/app/helpers/textual_summary_helper.rb#L114 instead of code block in elsif here https://github.com/ManageIQ/manageiq/blob/master/app/helpers/textual_summary_helper.rb#L116

@h-kataria this works for me. :+1:
A side note, the google network manager has been merged few days ago, I think we could also safely delete the security groups link from here now. That could be a fix for all the related bugs, that will delete all links, that doesn't belong to the Manager directly.

Darga Backport details:
commit 940566f555ed2849cf9ce3d79b6c709eab2d329a
Author: Dan Clarizio <dclarizi@redhat.com>
Date:   Mon Jul 11 13:07:18 2016 -0700

    Merge pull request #9700 from h-kataria/fixed_security_groups_link_on_cloud_provider_summary

    Fixed the way link to Security Groups is being built for Cloud Provider
    (cherry picked from commit b269954cd7a3f9f7a933f3c3358116a2cb5d5e46)

authors: Ladas chessbyte h-kataria


text:
Installation process for PiWS281X is unclear

I am able to install PixelWeb as expected and load the web interface, but the installation process for the PiWS281X driver for the Raspberry Pi is not very clear. I was able to follow the install instructions at https://github.com/ManiacalLabs/BiblioPixel/wiki/PiWS281X but cannot progress any farther. Where are we importing the neopixel module? Could this be automatically detected or installed?

Nevermind, I needed to scroll down in the driver list. It wasn't very obvious that I needed to do this.

@siege9929, unfortunately browser changes made the PixelWeb UI not work as
intended and it has become very difficult to keep up with it, which is why
we've dropped support for PixelWeb entirely in the latest BiblioPixel in
favor of BiblioPixel Projects:
https://github.com/ManiacalLabs/BiblioPixel/wiki/Projects
On Fri, Nov 10, 2017 at 4:16 AM, siege9929 notifications@github.com wrote:

Closed #14 https://github.com/ManiacalLabs/PixelWeb/issues/14.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/PixelWeb/issues/14#event-1335676427, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA6a6u7UWY2eu_VsRNNQ8rHkgjPpk9YNks5s1BRzgaJpZM4QZQ0T
.

You should also point out that we have a replacement for it built into
BiblioPixel, in the form of the "remote" animation - unless I am mistaken?
On Fri, Nov 10, 2017 at 1:11 PM, Adam Haile notifications@github.com
wrote:

@siege9929, unfortunately browser changes made the PixelWeb UI not work as
intended and it has become very difficult to keep up with it, which is why
we've dropped support for PixelWeb entirely in the latest BiblioPixel in
favor of BiblioPixel Projects:
https://github.com/ManiacalLabs/BiblioPixel/wiki/Projects
On Fri, Nov 10, 2017 at 4:16 AM, siege9929 notifications@github.com
wrote:

Closed #14 https://github.com/ManiacalLabs/PixelWeb/issues/14.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/PixelWeb/issues/14#event-1335676427,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA6a6u7UWY2eu_
VsRNNQ8rHkgjPpk9YNks5s1BRzgaJpZM4QZQ0T>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/PixelWeb/issues/14#issuecomment-343457793,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPdslL66hHMs3MZBUBdDnDg86pJlvXAks5s1D1XgaJpZM4QZQ0T
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com

Yeah, @rec, I wanted to but realized it's apparently not documented. At
all. I will work on that.
On Fri, Nov 10, 2017 at 7:23 AM, Tom Swirly notifications@github.com
wrote:

You should also point out that we have a replacement for it built into
BiblioPixel, in the form of the "remote" animation - unless I am mistaken?
On Fri, Nov 10, 2017 at 1:11 PM, Adam Haile notifications@github.com
wrote:

@siege9929, unfortunately browser changes made the PixelWeb UI not work
as
intended and it has become very difficult to keep up with it, which is
why
we've dropped support for PixelWeb entirely in the latest BiblioPixel in
favor of BiblioPixel Projects:
https://github.com/ManiacalLabs/BiblioPixel/wiki/Projects
On Fri, Nov 10, 2017 at 4:16 AM, siege9929 notifications@github.com
wrote:

Closed #14 https://github.com/ManiacalLabs/PixelWeb/issues/14.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/PixelWeb/issues/14#event-1335676427,
or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AA6a6u7UWY2eu_
VsRNNQ8rHkgjPpk9YNks5s1BRzgaJpZM4QZQ0T>
.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/ManiacalLabs/PixelWeb/issues/
14#issuecomment-343457793>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAPdslL66hHMs3MZBUBdDnDg86pJlvXAks5s1D1XgaJpZM4QZQ0T>
.

--
/t
https://tom.ritchford.com https://tom.ritchford.com
https://tom.swirly.com https://tom.swirly.com
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ManiacalLabs/PixelWeb/issues/14#issuecomment-343460142,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA6a6pcfT89K215wh7oI6vaFWylYfCunks5s1EAygaJpZM4QZQ0T
.

authors: adammhaile rec siege9929

repo: ManiacalLabs/PixelWeb


text:
After become(), colors of the two Mobjects are linked

Description of bug / unexpected behavior
After calling a.become(b), where a and b are both VMobjects, their colors become linked. Changing color of a (e.g. with set_stroke also changes color of b and vice versa.
Expected behavior

After become() call, the two Mobjects should be independent and should change colors independently.
How to reproduce the issue

Code for reproducing the problem

from manim import *

class PromoScene(Scene):
    def construct(self):
        a = Circle()
        b = Square()
        self.add(a)
        self.add(b)
        b.become(a)
        b.shift(1*RIGHT)
        b.set_stroke(YELLOW, opacity=1)
        self.wait(1)

Additional media files

Images/GIFs
Result I get:

Expected:

This seems to fix the issue:
diff '--color=auto' -rubp manim.orig/mobject/types/vectorized_mobject.py manim/mobject/types/vectorized_mobject.py
--- manim.orig/mobject/types/vectorized_mobject.py	2023-12-07 18:55:34.234530207 +0100
+++ manim/mobject/types/vectorized_mobject.py	2023-12-07 18:55:39.241205514 +0100
@@ -1692,7 +1692,7 @@ class VMobject(Mobject):
                 interpolate(getattr(mobject1, attr), getattr(mobject2, attr), alpha),
             )
             if alpha == 1.0:
-                setattr(self, attr, getattr(mobject2, attr))
+                setattr(self, attr, copy.deepcopy(getattr(mobject2, attr)))

     def pointwise_become_partial(
         self,

repo: ManimCommunity/manim


text:
Configparser setup: figuring out config.py, constants.py, dirs.py, CLI arguments, and more [WIP]

Ok y'all, this is a doozy. I've been working on this and there's a few things that we need to decide as an organization. I'm going to try to make my points clearly and I'll bold the points at which I need y'all's input.
Rationale
The current repo is very badly disorganized and needs a good cleanup. One of the sources of this is the fact that there are different ways of manipulating what manim does as a whole:

constants.py sets some global variables (most of which are actually constant, but some of which are not).
config.py parses the CLI arguments, uses it to set camera_config among other things. It also initializes directories.
HOWEVER, there is also a dirs.py file that allowed you to set default output directories. config.py reads that in as well as the CLI arguments.

As a result, I think it's quite the hurdle for a user to figure out where to get or set the value of a particular variable that determines how manim works. If I want to change a directory, should I use dirs.py, or a CLI argument? Which has precedence over the other? If I want to change the resolution, should I do it in constants.py, by CLI argument, or in the CONFIG of my Scene objects?
The main purpose of this PR is to provide a single default source of global truth for configuring how manim works. (And, in the event that there is more than one possibility to set the value of a particular variable, the precedence between those possibilities should be very clear and documented.)
The proposal
The main way to do this is as follows. This PR makes it so that there is one single place to write/determine/set how manim works, and one single place to read/check/get those configurations once they are in place.

Write: The user can now use an optional manim.cfg file to tweak the default behavior. Note this is a file that the user can have on their machine without touching the manim codebase at all. We will also ship a default config file so the user doesn't need to have such a file, but can have one if they want it.
Read: once all configuration variables, directories, and CLI arguments have been parsed/processed, there is one single place where all of the configuration lives in for the rest of the execution: the global config dictionary that can now be imported by doing from .config import config (if within the library codebase) or by from manim import config (if importing the library as end user).

The constants.py file still exists, but as much as possible, it should not contain configuration variables, only constants. (more on this later).
How it works
I want to explain the main workflow of how this works. For this, note that there are two different ways of using manim: importing it as a library (to have access to Scene, Mobjects and so on), and as a  command line script (to actually render a video).
If being imported as a library, this is what's going to happen. The user will type from manim import * at the top of their file. This executes the contents of __init__.py, which in turn imports/executes config.py before anything else. config.py defines and exports the config dictionary by parsing the manim.cfg file. This config will now contain all configuration needed for the end user (and indeed for internal purposes as well). Finally, config.py will also setup some directories (more on this later). (Note that this is a very odd way of using manim, like for example if you open a python interpreter and type import manim. Importantly, this will also be the case during testing. In most cases, manim will be used in the other way, in the next paragraph.)
If being used from the command line, for example as python -m manim ... or as manim ... or as manimcm ..., the file that gets executed first is __main__.py. This file also imports/executes config.py as the first order of business. In this case, config.py will recognize it's being used from the command line and, after parsing manim.cfg first, it will also parse the CLI arguments. The CLI arguments will override the default settings defined in manim.cfg. At the end, the global config dictionary will contain all configuration that correctly corresponds to the defaults in the .cfg file as well as the CLI arguments.
The result
When manim is being used as a library, there is no visible change other than the fact that some imports of the type from manim.constants import SOME_VAR and then using SOME_VAR will become import manim.config as config and then using config['SOME_VAR'], because some variables (that weren't constants) have been moved from constants.py into the config dictionary. More on this later (see discussion points).
When manim is being used from the command line to actually generate scenes, the changes are as follows. All the command line arguments are still in place. BUT, now the user may set the defaults by using their own manim.cfg file. For example, the -p (or --preview) flag is turned off by default so if the user wants the movie to play after it's rendered, currently they need to always specify -p. After this PR, the user can create a new manim.cfg file with the line PREVIEW = TRUE. If they do so, running manim without the -p flag will still show the video once it's rendered. This has the advantage that if a user needs a particularly long CLI command with lots of flags to render their scenes, they can just dump all of those flags into the manim.cfg file and just run manim myfile.py. The manim.cfg file currently allows to set default values for each command line argument.
The discussion points
I'm just going to dump a bunch of issues here in no particular order. I'll do my best to be brief and to point exactly what needs to be answered/discussed/decided in bold.

The main problem here is that we are still conflating constants along with configuration variables, in the following way. The PIXEL_WIDTH (previously called DEFAULT_PIXEL_WIDTH) variable can be set in command line via the -l, -m, -e, -r flags. So it is not a constant, and it should live inside config, not in constants.py. This PR makes it so. Now, there are other values, for example FRAME_WIDTH, that directly depend on the value of PIXEL_WIDTH, thus they are also not constant. HOWEVER, the configparser library that parses .cfg files does not support arithmetic operations. So right now there is no easy way to only set PIXEL_WIDTH once and have FRAME_WIDTH and related variables update their values as well. Right now, in this PR this is being done in the constants.py file: it is loading the config dictionary, which contains PIXEL_WIDTH and defines the other variables accordingly. I very much don't think this should be merged as is, but I wanted to ask what is the best way to solve this, knowing that this cannot happen in the .cfg file? My suggestion is that this happens inside config.py, with a special function that defines those variables such as FRAME_WIDTH once PIXEL_WIDTH is set. However, this means that the user can set only the latter and the former will always be tied to it in the same hard-coded way. EDIT: I think a good example to fix this issue is to consider the question, where do we define TOP? Currently, it is defined in constants.py, with the line TOP = FRAME_Y_RADIUS * UP. Now, I think UP is a true constant and it should stay in constants.py. But FRAME_Y_RADIUS depends on FRAME_HEIGHT, which is not constant and is set by CLI argument in config.py. If we adhere to the strict view that only true constants must remain in constants.py, then TOP must go elsewhere.

Due to the above (some configuration variables are being loaded into constants.py), I converted all configs and constants to ALL_CAPS. Accordingly, the CONFIG dictionary of Scenes and Mobjects were also turned to ALL_CAPS. I think this is ugly as hell and hope this changes in the future. Fixing the issue of constants vs config variables should make this go away.

For the problem of importing config.py before anything else, see #26. I think we are in the clear here.

The current version does not work with python -m manim ... (see definition of prog in config.py). This is because it is actually very difficult to determine if the library is being imported or run from the command line (at least from the config.py file). I need suggestions for how to fix this.

This is a pretty big change so if there is anything that you can think of, please bring it up here.

Currently, all of the keys in SceneFileWriter.CONFIG are keys of the global config dict. Does SceneFileWriter really need a copy of each? Pinging @PgBiel here who is working on attrs.

Yes, this has been tested and renders scenes well. I have by no means ran an exhaustive test suite of all constants/configs/CLI flags yet.

List of changes
I'll list some of the minor changes made that are not big-picture issues. Please comment on these too if you have anything to say.

start_at_animation_number is now FROM_ANIMATION_NUMBER. Similarly, end_at_animation_number is now UPTO_ANIMATION_NUMBER. These are shorter and have the same meaning. (I don't like the ALL_CAPS, but that's a different issue touched upon above.)
dirs.py has been eliminated. Instead of dirs.video_dir, now you have to do config['VIDEO_DIR']. This will require changing from dirs import video_dir to from config import config and using config['VIDEO_DIR']. If we don't want to have to load the whole global config just for the one directory name, we can package the directories in a separate dict, also defined in config.py and load it as from config import dirs.
input_file_path has changed to INPUT_FILE, and file_name has changed to OUTPUT_FILE. The original names were just confusing.
The default configuration file is now packaged with the rest of the code, as seen in in setup.py.
DEFAULT_PIXEL_WIDTH, DEFAULT_PIXEL_HEIGHT, and DEFAULT_FRAME_RATE have been changed to PIXEL_WIDTH, PIXEL_HEIGHT, and FRAME_RATE. The reason is that once the config is read and the CLI arguments parsed, they are no longer a 'default' value, but possibly a value set by the user, so the names were misleading. The new names are also shorter.
PRODUCTION_QUALITY_CAMERA_CONFIG is now just the default config['CAMERA_CONFIG']. Also, note that config['CAMERA_CONFIG'] is changed by the *-quality flags (low-quality, medium-quality, high-quality) and by the --resolution flag.
The scene_names CLI argument is now --scene_names for easier parsing.
Changed open_video_upon_completion to PREVIEW so it has the same name as its corresponding CLI flag. It is also way shorter.
Removed the ignore_waits option which was never used and was set to the value of args.preview.
Most CLI flags have been changed to have no default value. For example, -p was by default False, but will now default to None. This is done that we can easily determine whether the user actually specified this flag by comparing it to None. If the flag is None, we read the default value from the manim.cfg file instead. Importantly, this is a subtle change in the code (see comments inside _parse_cli() in config.py if you are interested.
The way everything is setup right now, passing only the -s flag will also write a movie (since WRITE_TO_MOVIE is True by default in manim.cfg). See #41.

List of standing or future issues
While working on this, I realized there is a number of other things that I would also like to change, but I'm not sure if they should be part of this PR or a separate one.

I think there are a bunch of variables/constants that have DEFAULT_ in the name but that should not have it.
The output directories are being created during initialization (when config.py is read). I think the directories should be created at the last possible minute. If I run manim and it crashes before writing the scene, the directories will be created but empty.

PS
Mostly for my sanity: this interacts with #65, #81, #77 so I'll get back to those when this is merged.

After more thought, I have a proposal that would fix points 1, 2, and 3 under "The Discussion Points" above.
In the original code base, config.py sets a different dictionary for camera_config, file_writer_config, and the rest of configurations are put in constants.py. In the current PR, I put the camera_config and file_writer_config as sub-dictionaries of the new config dictionary. I was being a bit conservative about this, but now I'm proposing that we make full use of those.
I propose that we leave inside constants.py only those variables X such that the answer to the following question is "no": Would the user expect X to change from project to project? If the user has two entirely different projects for which they are using manim, and they would expect X to have the exact same value in both projects, then X should go in constants.py, and everything else should go in the config dict. For example, for X=PIXEL_WIDTH the answer is "yes" (as the user may be using different frame sizes for different projects), and therefore it should go in config. For DEFAULT_MOBJECT_TO_EDGE_BUFFER the answer is "no" because even if the user needs buffers of different sizes for their two projects, this variable defines the default buffer, not the buffer that the user will need every time. A true default should be the same across projects, so this goes in constants.py. This solves 1) above because both PIXEL_WIDTH and TOP could change from project to project, as they both depend on the frame size and its geometry.
Another reason why I was reluctant to put TOP inside the config dict is because it would be awkward to have to do config.top. However, this is where the camera_config comes in handy. I suggest that we put all of the parameters relating to the geometry of the frame inside a frame_config global object, or it could even be named frame, and be imported as from config import frame. Then the user can just use frame.top (or frame['top'] if it's a dict). I think frame.widthis much more pleasing than importingPIXEL_WIDTHinto the local scope, as it's currently done by the use offrom manim import *`.
So, to sum up (and I do apologize for the literal walls of text in this PR), I'm suggesting that on top of the current PR, we take out (many) more variables out of constants.py into different objects/dicts that group them semantically. Concretely, I propose that we use the existing camera_config but expand it to contain all variables relating to the geometry of the frame/scene (and perhaps rename it to just frame), and use file_writer_config to contain all of the variables relating to writing files. In particular, we should move all of TEX_USE_CTEX, VIDEO_DIR, MEDIA_DIR to the file_writer_config (as the user could expect it to change from one project to another).
Please let me know if this makes sense, as this will involve quite a bit more refactoring and it will most likely break old code.

My remarks so far before I go to sleep

HOWEVER, the configparser library that parses .cfg files does not support arithmetic operations.

Alternatives:

Allow eval() of inputs;
Have the config file be read as a .py file (and, therefore, require this format). Could be better for customizability and a few other factors, but... this idea is debatable

Due to the above (some configuration variables are being loaded into constants.py), I converted all configs and constants to ALL_CAPS. Accordingly, the CONFIG dictionary of Scenes and Mobjects were also turned to ALL_CAPS. I think this is ugly as hell and hope this changes in the future. Fixing the issue of constants vs config variables should make this go away.

Please, please, please have the config params be in lower (snake) case...

Currently, all of the keys in SceneFileWriter.CONFIG are keys of the global config dict. Does SceneFileWriter really need a copy of each? Pinging @PgBiel here who is working on attrs.

To be used with attributes yes. However, we do not need that, of course. We can just have the config dict be stored in some shape-free dictionary or something... This is, if the config types and whatnot are specified somewhere else (E.g. in some sort of Config class or w/e). Otherwise, we should use attributes in our favor, as they allow us to document each type and name.

@PgBiel

Allow eval() of inputs;

I think eval() should be our last resort.

Have the config file be read as a .py file (and, therefore, require this format). Could be better for customizability and a few other factors, but... this idea is debatable

Yes, there are libraries whose configuration files are just plain .py files. However I'm still not sure we need the full power of that yet.

Please, please, please have the config params be in lower (snake) case...

Yes! My latest comment would achieve this, but it comes with the price of breaking changes (or DeprecationWarnings).

Have the config file be read as a .py file (and, therefore, require this format). Could be better for customizability and a few other factors, but... this idea is debatable

Yes, there are libraries whose configuration files are just plain .py files. However I'm still not sure we need the full power of that yet.

I really like the idea of using .py files for custom configuration. It offers a lot of space to expand if need be and could be used by any extensions to manim as well.

Extensions/addons are actually a compelling argument.
In that case, the structure would probably look like this:

have one constants.py file (with ALL_CAPS, truly constant values),
have one master config.py which contains all the logic for default configuration,
before returning, the config.py could also load other user-defined or addon-defined configuration files to override the defafults.
before returning, the config.py could also parse CLI arguments, if called from the command line, to override the defaults.

This seems achievable. However, we still have the problem that it is very difficult to detect when manim has been called from the command line (see discussion point 4 in the OP).

I really like the idea of using .py files for custom configuration. It offers a lot of space to expand if need be and could be used by any extensions to manim as well.
IMO it makes more sense if it's a .cfg file. If we want that the user to be able to create his own config without touching the manim codebase at all, a .py is a bad idea as it will certainly confuse some people who won't understand what file to run - why - where.
I mean, put yourself in the mind of a python beginner; you would way better understand the config system with a .cfg than with a .py.

To solve the problem of the arithmetic operations,

have one master config.py which contains all the logic for default configuration,
before returning, the config.py could also load other user-defined or addon-defined configuration files to override the defaults.
before returning, the config.py could also parse CLI arguments, if called from the command line, to override the defaults.

That is the best idea. In addition, we wouldn't be too far from the actual functioning.
And a config.py will be the place to handle when arguments miss (i.e not specified in the args or in the config file, due to a user mistake)

On the problem of moving the arithmetic operations from constants.py to config.py:

It should leave constants.py not because of the arithmetic, but because it depends on the user defined value FRAME_WIDTH.
I'm more and more convinced it should just go on config.py. After all, this is currently the file that parses user input (through CLI arguments or through the .cfg file).
My initial hesitation was because the config.py is already a bit bloated as it is, and I didn't want to add even more specific logic. HOWEVER, I think the fix is to have a FrameConfig class in config.py, which processes/parses/sets all the frame and camera configurations. That way all this logic will be encapsulated in a single class. Again, only one source of truth, as opposed to this logic being strewn around the config.py file. Then, config.py can export a FrameConfig object, or just the __dict__ of it.

And a config.py will be the place to handle when arguments miss (i.e not specified in the args or in the config file, due to a user mistake)

Small clarification: this will never happen, because there will always be a .cfg file shipped with manim. If the user doesn't specify a CLI argument or a .cfg file, there will be a library-wide .cfg file to set defaults.

OK I just figured out how to solve problem 4) above. It's hacky, but it will work.
Also, a lot of the constant/config variables are only ever used by scene_file_writer.py. I'm thinking another thing we can do is group all of those into a single dict that is then just passed directly to scene_file_writer.py instead of putting them into the global dict. No need to expose them to the user since the user never really needs them.

OK I heard y'all loud and clear and just pushed some changes. Let me summarize:

After the latest commit, even more variables have been taken from constants.py and put into config.py. Now constants only contains variables that will never change. Now constants are ALL_CAPS while configuration variables (the keys in the global config dict are snake_case).

I realized that the vast majority of config variables were related to output/writing/files and only ever used internally. I can't think of a reason why the user would ever touch those variables when writing a Scene. Therefore, I split the config variables into two global dictionaries: config, meant to store stuff the user will use, and file_writer_config, meant to be used internally by manim when writing output. Both are global dicts so the user can access the latter too if required, but now the dict manim.config contains only stuff that the user is more likely to need when writing Scenes. I think file_writer_config is an ugly name though, and I'm open to alternatives.

The file extract_scene.py has been copy-pasted onto __main__.py, since that was basically what it was. All other things that  __main__.py was doing other than execute extract_scene.main have moved to config.py.

The CONFIG dictionaries of a couple of classes have been removed, since they were only ever using the variables found in the global file_writer_config and the instances of those classes never needed their own copy. This should affect the move to attr/dataclasses @PgBiel.

This all now works when being called as manim ..., manimcm ..., or python -m manim .... The latter is a hack, but it works @eulertour.

I tested this and it seems to be working!

I think this is ready for a more thorough review, so I'm taking away the "draft" label.

The build is failing 😕. But besides that, the arguments are parsed incorrectly for me if I run it with manim ... or manimcm ... (python -m manim ... works).

I also noticed that the -l and --low_quality flags aren't working anymore. I didn't test the other quality flags, but if this one isn't working I suspect the others are broken as well.

I also noticed that the -l and --low_quality flags aren't working anymore. I didn't test the other quality flags, but if this one isn't working I suspect the others are broken as well.

Yep, I currently fixed it on my local repo, but currently struggling with the build failing...

Phew. Pretty sure I just fixed all standing issues. @eulertour now both python -m manim and manim work on my local.

OK so tests pass on linux and OSX, but not on Windows. The problem is still a ffmpeg problem, here is the relevant code:
        if file_writer_config['write_to_movie']:
>           self.writing_process.stdin.write(frame.tostring())
E           BrokenPipeError: [Errno 32] Broken pipe
manim\scene\scene_file_writer.py:315: BrokenPipeError

FAILED tests/test_sample_scenes.py::test_scenes - BrokenPipeError: [Errno 32]...

The -o flag seems to be doing something where it outputs the video relative to the resolution directory, e.g. manim example_scenes/basic.py SquareToCircle -plo ./vid.mp4 writes to  /path/to/pwd/media/videos/basic/480p15/./vid.mp4.
However, this also happens on master, so I've opened a new issue for it (#136).

Before merging this, we must make sure it's backwards compatible. This requires at least to return all those variables that were removed from constants.py...

The builds now consistently pass on linux and OSX, but consistently fail on Windows, with either a OSError: invalid argument, or a BrokenPipeError. This seems to be documented here, though I can't find a fix yet.

constants.TEX_TEMPLATE isn't an actual constant and also needs to be moved out of there. It being in there but not actually constant also seemingly causes issues with my multiprocessing attempts.
On another note, with the big tex change recently some more of the code in this PR has gone stale and there'll be more conflicts. I'd advise wrapping this up quickly since this PR is now 2 weeks old, and so is some of the stale code.

Everything here LGTM as soon as the merge conflicts are fixed.

what about my suggestions? Do you agree with them?

Yeah, your suggestions look good too.

Looks like I spoke too soon. Now all files are being written as .mp4, e.g. media/videos/basic/480p15/.mp4.

@PgBiel all your changes have been added as of the latest commit.
@eulertour I can't replicate that behavior. What is the exact command you are using?

@eulertour I was able to replicate it and fix it. Also fixed merge conflicts.

Linux builds passed, and 2/3 OSX builds passed. The one that failed was due to brew taking too long to download/install things and the build timed out. (We should probably set the timeout to a larger value since we are dealing with brew in each build, but that's a separate issue.)

Since write_to_movie and save_last_frame don't use this logic, running with -pls causes the last frame to be displayed and the video to be played immediately afterward. Additionally, the video is generated even when -s is passed, which means the flag doesn't save time anymore.

The message Ignoring --media_dir, since both --tex_dir and --video_dir were passed. is printed no matter what. I actually wouldn't mind removing the message entirely. It's technically wrong anyway since the user might have specified a --tex_dir and --video_dir which are underneath the --media_dir.

Since write_to_movie and save_last_frame don't use this logic, running with -pls causes the last frame to be displayed and the video to be played immediately afterward. Additionally, the video is generated even when -s is passed, which means the flag doesn't save time anymore.

Yes, that logic is invalidated by moving to the .cfg file, and I forgot to raise the question of whether we want -s to invalidate the default behavior of writing a movie. Is this what we want? If so, I can add this change and document it as well.

The message Ignoring --media_dir, since both --tex_dir and --video_dir were passed. is printed no matter what. I actually wouldn't mind removing the message entirely. It's technically wrong anyway since the user might have specified a --tex_dir and --video_dir which are underneath the --media_dir.

Again, I forgot to raise this for discussion. I was leaving this for discussion when resolving #66. However, I also vote for scrapping this logic as well as the message for now in this PR.

I forgot to raise the question of whether we want -s to invalidate the default behavior of writing a movie. Is this what we want?

Yes, the purpose of this option is to save time over rendering each frame of the video.

Just pushed some changes: the -s flag should now work, and the Ignoring ... message is gone.

There are a few other changes that could be made to the CLI flags. For example, the -w flag is now basically obsolete. However, I suggest that we deal with those in other issues/PRs and merge this ASAP. Many other PRs/issues are being held up by the .cfg structure specifically.

Latest travis build passes on Linux/OSX, and the Windows builds will be made optional by #133. Are we ready to merge? @eulertour @PgBiel

The -s option is still slow. 😕

The -s option is still slow.

Can you please clarify what you mean? Here I'm copying the timeing of using the -s flag at 4k resolution:
$ time manim -ks basic.py SquareToCircle
<omitted manim output>
real	0m3.138s
user	0m3.311s
sys	0m0.320s

$ time manim -k basic.py SquareToCircle
<omitted manim output>
real	0m21.378s
user	0m33.739s
sys	0m9.617s

--media_dir is also leaving an empty directory.

Yes, it does. This is point number 2 under "List of standing or future issues" all the way back on the original post of this PR. It is my impression that this was always the case in 3b1b manim (tho I may be wrong?). I think the fix here is to make the file writer lazy and create the directories only at the last possible minute. Is this something we want to implement on this PR or leave for later? Like I said, I'm trying to merge this ASAP as so many other issues are being held up. I can try to make the file writer lazy right after this is merged tho.

Could you please be more specific? I don't know how a function would help
here since __main__.py is importing config.py, and there is no way of
sending information to the imported module. If by global variable you mean
that __main__.py could export a variable that then config.py would
read: I'd hesitate to do that because in that case each module would be
importing the other one and I'm not sure that's necessary.
The current way is very hacky and ugly but it works and it doesn't involve
circular imports.
On Wed, Jun 17, 2020, 8:42 AM Pg Biel notifications@github.com wrote:

@PgBiel commented on this pull request.
In manim/config.py
https://github.com/ManimCommunity/manim/pull/98#discussion_r441514010:

if filename and not os.access(filename, os.R_OK):

   # custom template not available, fallback to default

   logger.warning(

       f"Custom TeX template {filename} not found or not readable. "

       "Falling back to the default template."

   )

   filename = ""

if filename:

   # still having a filename -> use the file

   constants.TEX_TEMPLATE = TexTemplateFromFile(filename=filename)

else:

   # use the default template

   constants.TEX_TEMPLATE = TexTemplate()

+def _from_command_line():

"""Determine if manim was called from the command line."""

We can probably let the main.py module signal this by a function or
global variable or something like that. That might be the best way to go
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ManimCommunity/manim/pull/98#discussion_r441514010,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAILYAHYF3LF37UCHVISV33RXC2ZVANCNFSM4NMGRN7A
.

we could create a file in utils or something with a function called set_is_main or set_main, which sets the variable is_main that would be exported by this file

Leaving the --media_dir empty is probably fine if we open a follow-up issue. As for -s being slow I mean it's slower that it is on the master branch, which leads me to believe that it's still generating video but then only displaying the last frame.
Whatever you decide regarding the two dictionaries is probably fine by me, I just wanted you to be aware.

Thanks everyone for the comments and reviews. It seems that the core changes to the config system are not subject for debate anymore so in the interest of merging this, I'll fork the current standing discussions into separate issues on their own. Now we are just waiting for #33 to merge, after which I'll update this branch and merge it ASAP.

The problem with the slow rendering is caused because the Scenes are being initialized incorrectly.
https://github.com/ManimCommunity/manim/blob/b6603037f248c24324c6ab10b4bee95904923bb8/manim/__main__.py#L155
Compare to master:
https://github.com/ManimCommunity/manim/blob/4b6492b0e7e7e4ae7e35938662571ad765027f3c/manim/extract_scene.py#L176
The tests are still failing after the update; they aren't reading the config variables correctly. One error I got was NameError: name \'FRAME_WIDTH\' is not defined.
But you can't get that far without patching the testing code because it's currently reading the wrong path and won't tell you what path it's failing to read since the error is caught and another one is thrown in its place:
https://github.com/ManimCommunity/manim/blob/b6603037f248c24324c6ab10b4bee95904923bb8/tests/testing_utils.py#L57-L63
The scene data shouldn't be loaded this way. Instead we should just attempt to load the file and let the exception be thrown if it fails.

Actually even the tests that don't run into errors loading config variables are failing from another error: fixture 'get_config_test' not found. It seems like the tests are causing more problems than they're solving here, so if the other problems are fixed I'd be fine ignoring them.

Actually even the tests that don't run into errors loading config variables are failing from another error: fixture 'get_config_test' not found. It seems like the tests are causing more problems than they're solving here, so if the other problems are fixed I'd be fine ignoring them.

This is a very easy fix, get_config_test is a pytest fixture that is now deprecated. To me, the tests are working fine, they are just not updated yet. We can ignore them if you want, but then I don’t get the point of having tests if we ignore them every time they fail

The scene data shouldn't be loaded this way. Instead we should just attempt to load the file and let the exception be thrown if it fails.

I designed that to be used by pytest, and it appears that it is the correct way to do it when one wants to catch a custom exception (see https://docs.pytest.org/en/stable/assert.html).
If we do what you're suggesting, we won't be able to show that "x has not pre-rendered data blahblah".

I see three different comments here.

The change from SceneClass(**scene_kwargs) to SceneClass() is intentional and necessary. This is because the scene_kwargs were passing around values that can now be read through the global config. Also, I don't see why this would cause the rendering to be slower.

The constant FRAME_WIDTH has been deprecated and is now config['frame_width']. I just caught and changed two instances of the former that I missed.

The fixture get_config_test has been deprecated, as @huguesdevimeux pointed out. Similarly to **scene_kwargs, this was being used to get some test-specific config values to the scenes to be tested. These are now specified in tests/manim.cfg. I just caught and changed some instances that I missed.

** Also, importantly, I can't believe I failed to say this: the command pytest is meant to be ran from within the tests/ directory, not from the root directory. This is because of how the config files work in a cascading way, so pytest must be ran from within the appropriate directory to read the tests/manim.cfg file. ** @eulertour perhaps this interacts with point 1.?

@huguesdevimeux

To me, the tests are working fine, they are just not updated yet. We can ignore them if you want, but then I don’t get the point of having tests if we ignore them every time they fail

Since this PR has already been blocking development for weeks, we've been developing without any tests up to this point for better or for worse, and adding the tests are causing more problems to solve, I'd be fine with it in this instance. I do think all of the test-related issues should be fixed eventually.

I designed that to be used by pytest, and it appears that it is the correct way to do it when one wants to catch a custom exception (see https://docs.pytest.org/en/stable/assert.html).

The page you linked is describing how to write assertions about raised exceptions, but in load_data() we need only raise an exception if the can't be loaded. There's no need to use a custom exception and in this case it works against us since we can't see the file that's failing to load.

If we do what you're suggesting, we won't be able to show that "x has not pre-rendered data blahblah".

This is true, but we will see No such file or directory: '<attempted file>' which is more informative for debugging.
@leotrs

The change from SceneClass(**scene_kwargs) to SceneClass() is intentional and necessary. This is because the scene_kwargs were passing around values that can now be read through the global config.

Gotcha, that's fine.

Also, I don't see why this would cause the rendering to be slower.

It's basically this snippet https://github.com/ManimCommunity/manim/blob/4b6492b0e7e7e4ae7e35938662571ad765027f3c/manim/scene/scene.py#L682-L686
scene.py checks that instance variable in order to determine whether or not to skip to the end of an animation and since it wasn't being set on the instance it was no longer skipping when -s was passed.
Points 2 and 3 are fine though I don't think the config files are causing the problem with the tests, at least not from what I've seen so far.

Since this PR has already been blocking development for weeks, we've been developing without any tests up to this point for better or for worse, and adding the tests are causing more problems to solve, I'd be fine with it in this instance. I do think all of the test-related issues should be fixed eventually.

Alright, as you wish.

This is true, but we will see No such file or directory: '<attempted file>' which is more informative for debugging.

I see, you are right. thank you very much for this comment.
maybe @leotrs can quickly fix this in this PR ?

I actually wanted to add something related to the cascading config files: I don't think config files from the directory where we start manim should be considered. Instead we should only use the global config, one in the home directory, and one in the directory where the script is located.
The reasoning is that it doesn't make much sense for a Scene to render differently depending on the place where it's run.

Fully agreed with you there RE the cascading files.

authors: Aathish04 PgBiel XorUnison eulertour huguesdevimeux leotrs