text:
added goroutines example

What does this PR do?
Adding an example of using goroutines
Motivation
The issue #4
Additional Notes
This example is up to date and tested

@esendjer thanks for working on this! Much appreciated.
Could you please review your Go code and make sure that:

where PyObjects are returned from calling Python C-API functions, there's proper Python memory handling in place? (i.e. .DecRef() objects where needed)
where Python C-API functions are called there's Python error handling in place (i.e. check python3.PyErr_Occurred() if needed)

For example for fooModule := python3.PyImport_ImportModule(nameModule):

If you look at the docs for PyImport_ImportModule it says "Return value: New reference.". So you need something like defer fooModule.Decref() after error checking. Otherwise you might have a memory leak. Decref only after error checking, otherwise the result is undefined.
regarding errors the doc for this function says: " Return a new reference to the imported module, or NULL with an exception set on failure.". So it might make sense to check for both. You can check for the exception with python3.PyErr_Occurred() (and print error messages with python3.PyErr_Print(), etc).

(If you need more explanation on the memory handling, I wrote a blogpost here).
Let me know when done and I'll continue to review. Thanks!

@christian-korneck thanks for your points and advice.
I've tried to improve the PR according to your comment and hope it was successful. Could you please have a look at this?
Thanks!

	fooModule := python3.PyImport_ImportModule(nameModule)
	defer fooModule.DecRef()
	if python3.PyErr_Occurred() != nil {

a PyObject shouldn't get decref'ed before you know for sure that you actually got a PyObject that needs decref'ing.

Got it. Thanks. I'll fix this.

In the last commit, I decided to stop using defer somePyObject.DecRef() because sometimes it caused randomly panic on my tests on a call Py_Finalize(). It happens not for each running but it's like 50/50 - sometimes there is panic, sometimes there is not.
If I understood well it happens because so is the logic of working Py_FinalizeEx/Py_Finalize. According to the article https://docs.python.org/3/c-api/init.html#c.Py_FinalizeEx: The destruction of modules and objects in modules is done in random order.
I'm not sure but maybe panic happens when Py_Finalize try to destroy an object which was removed by a defer statement. but one more time - I'm not sure, not sure at all. that my suggestion is correct or near to be true.
Instead applying defer somePyObject.DecRef() I moved a call DecRef() for python objects under if statements, where checks error, such as:
nameModule := "foo"
	fooModule := python3.PyImport_ImportModule(nameModule)
	if fooModule == nil && python3.PyErr_Occurred() != nil {
		err = errors.New("Error importing the python module")
		fooModule.DecRef()
		return
	}

Sorry for lots of attention and some mistakes, I'm just a beginner 😔

Sorry for lots of attention and some mistakes, I'm just a beginner 😔

@esendjer no worries, that's okay.

I'm not sure, not sure at all that my suggestion is correct

The main challenge of this task is to get everything "correct" and being relatively certain about it. This requires understanding of how memory management with the CPython C-API works, amongst other things (GIL, etc).
If you want to move on with this task (I highly encourage you to do so, there's lots to learn), I would suggest that you take the time and familiarize yourself with this topic area. For example you could start by using the blogpost/tutorial that I've mentioned above as a first tutorial, then write a few programs, etc and make sure you understand them and are able to debug them. You will likely need to consult other docs, etc as well (docs and examples are usually for C but translate well into Go).
If you have any specific questions feel free to ask. (Also stackoverflow, etc are good places if you stick to C, if that's an option for you).
For this PR: I'll continue to review if/when you're confident that your code is "correct". Also just to say, there's no rush. I don't think anyone else is working on this. Take your time. (However, I could also understand if this doesn't work for you - feel free to close the PR in that case).

Thanks a ton for your explanation and your article, and sorry for missing some important points from it.
As I see now, my issue was in that I tried to decrement the reference count for the limit after that the reference of it had already been stolen by PyTuple_SetItem, and I had to do nothing with the limit there because a new owner is caring about it, and when I tried to call DecRef for the limit directly the result became undefined and it caused to panic.
I've fixed this issue, turned back using defer for decrementing reference counts, and this time did it in the right way. Now, this example works well for all my test cases.

Thanks. Before I review it, could you go over it, check for the usual things and improve the code if needed?
(Keep in mind that this is an example others might be blindly trusting and building their own code on top. It doesn't need to be perfect, but also shouldn't promote any 'no gos').

[x] correctness: python error handling and memory management
[ ] correctness: GIL locking
[ ] is the code as idiomatic as possible?
[ ] does it lint?
[ ] would it make sense to have tests? (don't think it's a must have here, but you decide)
[ ] check for other relevant things mentioned here (not all of these are relevant for such a simple "cli tool")

Thank you. I'll continue working on this point-by-point. And thanks a lot for the useful links.
I'm a bit confused about the 2nd point - correctness: GIL locking. I'm sure that working with the GIL in the right way and there aren't gaps in acquiring or releasing the GIL in the code. There are a few places where the code works with the GIL:
	// Initialize the Python interpreter and
	// since version 3.7 it also creates the GIL explicitly by calling PyEval_InitThreads()
	// so you don’t have to call PyEval_InitThreads() yourself anymore
	python3.Py_Initialize() // <-- create the GIL, the GIL is locked by the main thread

	// ... Following is importing of Python module
	// and declaration of variables, getting attributes
	// and others action of creating/defining of PyObject

	// Save the current state and release the GIL
	// so that goroutines can acquire it
	state := python3.PyEval_SaveThread() // <-- release the GIL, the GIL is unlocked for using by goroutines

	// the 1st goroutine
	go func() {
		_gstate := python3.PyGILState_Ensure() // <-- acquire the GIL, the GIL is locked by the 1st goroutine
		// ... call python code
		python3.PyGILState_Release(_gstate) // <-- release the GIL, the GIL is unlocked for using by others
		// ...
	}()

	// the 2nd goroutine
	go func() {
		_gstate := python3.PyGILState_Ensure() // <-- acquire the GIL, the GIL is locked by the 2nd goroutine
		// ... call python code
		python3.PyGILState_Release(_gstate) // <-- release the GIL, the GIL is unlocked for using by others
		// ...
	}()

	// Restore the state and lock the GIL
	python3.PyEval_RestoreThread(state) // <-- acquire the GIL, the GIL is locked by the main thread

Here I follow the next pattern of embedding Python code:

Save the state and lock the GIL.
Do Python.
Restore the state and unlock the GIL.

And for each locking here is releasing, in the end, the lock is returned to the main thread
Unfortunately, I have no idea how yet I can be sure more of the correctness of the GIL locking/unlocking. I think I can add some checks with PyGILState_Check() before doing python, but in this case, it looks unnecessarily. If you have some advice about this I'll thankful for sharing them.

confused about the 2nd point - correctness: GIL locking.

this was just meant in a very generic way. The code must not have bugs or flaws in that aspect (as it's supposed to be  an example for it). I haven't really looked at your code yet and it's not meant as critic of something specific.

Thanks! Now, this point is clear to me.

I went through the checklist and tried to cover so many points as possible.

:heavy_check_mark: correctness: python error handling and memory management
:heavy_check_mark: correctness: correctness: GIL locking
:heavy_check_mark: is the code as idiomatic as possible?
:heavy_check_mark: does it lint?
The output of linters:===[ Linter #0 - go vet ]===
+ go vet ./...
Exit code: 0
===[ Linter #1 - go fmt ]===
+ go fmt ./...
Exit code: 0
===[ Linter #2 - golint ]===
+ golint ./...
Exit code: 0
===[ Linter #3 - errcheck ]===
+ errcheck ./...
Exit code: 0
===[ Linter #4 - staticcheck ]===
+ staticcheck ./...
Exit code: 0

:white_check_mark: would it make sense to have tests? (don't think it's a must have here, but you decide)
There is only one main function here, that doesn't take any parameters or args from stdin, and I'm not sure that it makes sense to do some tests.
:white_check_mark: check for other relevant things mentioned here (not all of these are relevant for such a simple "cli tool")
Some not quite well things here are, such as errors.New(…) instead modelling them, but I believe this is ok for the example.

Thanks for this. Just as a quick heads up: I'm currently a bit slow to respond, but will look at this PR soon.

there are also have some problems when the go-routine is scheduled to another thread，see this page: https://studygolang.com/articles/12822.
I think you should add  runtime.LockOSThread() in each go-routine in your example !!!
thx。

@esendjer I'm getting closer to being able to review this (partly because of #9 ). Could you please add runtime.LockOSThread() or describe why you didn't add it?

hi team,
I have a program where I want to DecRef a PyObject(the return value of python methods) in a go routine. The code inside go routine looks something like this:
`func MyFunc(request Request, requestBuilderFunc *python3.PyObject, pyTuple *python3.PyObject) *python3.PyObject
{
runtime.LockOSThread()
defer wg.Done()
defer runtime.GC()
defer debug.FreeOSMemory()
_gstate := python3.PyGILState_Ensure()
python3.PyTuple_SetItem(pyTuple, 0, python3.PyByteArray_FromStringAndSize(request.getRequestProtobytes()))
python3.PyTuple_SetItem(pyTuple, 1, python3.PyUnicode_FromString(request.getRequestType()))
python3.PyTuple_SetItem(pyTuple, 2, python3.PyUnicode_FromString(request.getRequestType()+"_"+strconv.Itoa(request.getRequestRCLID())))
// var resultant_dict *python3.PyObject
resultant_dict_from_proto := requestBuilderFunc.CallMethodArgs("from_proto_obj", pyTuple)
defer resultant_dict_from_proto.DecRef()
resultant_dict := requestBuilderFunc.CallMethodArgs("create_request_dict", resultant_dict_from_proto)
defer resultant_dict.DecRef()
resultant_dict_enriched := requestBuilderFunc.CallMethodArgs("enrich_request", resultant_dict)
defer resultant_dict_enriched.DecRef()
requestBuilderFunc.CallMethodArgs("create_request_temp_table", resultant_dict_enriched)
python3.PyGILState_Release(_gstate)
fmt.Println("Request Builder Ends")
return resultant_dict_enriched
}`

@jshiwam and everyone -  just to do some housekeeping: I don't think this PR discussion is the best place for your comment. Why? Well it's a question about a specific code problem that you're having and not really concret feedback or suggestions about the PR that @esendjer is crafting.
We're relatively liberal about allowing usage questions as issues here, even if they have little or nothing to do with this project (which is just a thin Go wrapper around the CPython C-API), but are often really CPython C-API usage questions. But issues and PRs should still stay on topic.
As we're seeing usage questions from time to time, I have now enabled Github Discussions, with a "Usage Discussion" section:
https://github.com/go-python/cpy3/discussions
I hope this allows us to:

focus issues to bug, enhancement, question discussions around specific to this project (i.e. bugs in this Go library, not the CPython C-API)
allow any kind of broad discussion how to achieve specific things using this library alongside the CPython C-API in Github Discussions

@jshiwam That's why I've redacted your above comment and moved your full question to Github Discussions and posted a first reply to it:
https://github.com/go-python/cpy3/discussions/16#discussion-4144358

@christian-korneck @esendjer  if no one is working on this PR then I can take this up and finish it, as these examples are really important for people who use this wrapper lib.

Hi @christian-korneck sorry for the delayed response, had been busy recently. I have made the final changes in this code. According to my understanding only using runtime.LockOSThread() had to be called inside the goroutines. Also would I have to create a new PR? because the changes are in my fork.

Here please check it out.
https://github.com/go-python/cpy3/pull/21/files

authors: christian-korneck esendjer jshiwam liam-lian


text:
redis: can't marshal map[string]interface {} (consider implementing encoding.BinaryMarshaler

func (p *InstService) SetProcMeta(instID uint, procMeta map[string]interface{}) error {
return p.Redis.GetRedis().HMSet(p.Redis.SetPrefixKey(fmt.Sprintf("inst:workflow:%v", instID)), procMeta).Err()
}
居然报:redis: can't marshal map[string]interface {} (consider implementing encoding.BinaryMarshaler
简直是巨坑， 不能用这个库，

interface{} 稍微复杂一点 就 can't marshal

source: gharchive/issue

repo: go-redis/redis

license_type: permissive

license_source: bigquery


text:
Struct references in operation parameter objects are generated as struct fields instead of pointers.

Spec:
'/order':
  post:
    tags: ['order']
    operationId: 'postOrder'
    summary: 'Creates a new Order.'
    parameters:
      - name: 'order'
        in: 'body'
        required: true
        schema: { '$ref': '#/definitions/OrderPlacement' }

Generated handler looks like this:
// PostOrderHandlerFunc turns a function with the right signature into a post order handler
type PostOrderHandlerFunc func(PostOrderParams, *models.Principal) (*models.Result, error)

func (fn PostOrderHandlerFunc) Handle(params PostOrderParams, principal *models.Principal) (*models.Result, error) {
  return fn(params, principal)
}

And the generated parameter object looks like this:
// PostOrderParams contains all the bound params for the post order operation
// typically these are obtained from a http.Request
type PostOrderParams struct {
  // info about the order to place, along with payment authorization token.
  Order models.OrderPlacement
}

I think either:

The Order field should be a pointer or...
The PostOrderParams in the handler signature should be a pointer.

ah here it's actually expected.
To get a pointer here the spec should read:
'/order':
  post:
    tags: ['order']
    operationId: 'postOrder'
    summary: 'Creates a new Order.'
    parameters:
      - name: 'order'
        in: 'body'
        required: true
        schema: { '$ref': '#/definitions/OrderPlacement' }

authors: casualjim chakrit

repo: go-swagger/go-swagger

license_source: github-api


text:
Definieren von verschiedenen Lastprofilen

Definieren, welche Lastprofile später auf dem Cluster ausgeführt werden

HiBench-Workloads könnten unverändert als eigene Lastprofile übernommen werden

Für Transitionssystem wurden als Lastprofile genommen:

randomtextwriter (Textdaten schreiben)
wordcount (Text analysieren)
dfsioe/dfsioePre (große Menge Daten schreiben/lesen)
pi (kleine Berechnungen)
randomwriter/teragen (Binärdaten schreiben)
pentomino (große Berechnungen)
sort (Textdaten sortieren)
terasort (Binärdaten sortieren)
teravalidate (Binärdaten validieren)
testmapredsort (Textdaten validieren)
fail (Fehlgeschlagene operationen)
sleep (Warten auf weitere Daten...)

license: MIT


text:
Texture Importing issue

Operating system or device, Godot version, GPU Model and driver (if graphics related):
windows, nvidia, f9eec5c
Issue description:
godot imports textures very slowly. when you put like 4 textures in the folder and go back to the editor, it will import them like 5 minutes (other tools and editors on my PC do it much quicker)
and when i tried using 8x4k texture it imported it (very slowly) fine. it even generated a thumbnail for it. but when i assigned it to a shader, editor started reimport (for 3d i assume) and crashed.
this is not caused by the shader, because it may be just a single uniform declaration and nothing else.
it is caused by reimport for 3d
UPD: as soon as i select the texture, it appears on the mesh (when using standard shader for example) but after this, editor starts reimport and crashes. seems strange now, after i've noticed that texture is applyed to the mesh first.
UPD2: tried to reimport the texture with '3D' preset manually. editor just does not respond forever after displaying '(Re)Importing' dialog.
UPD3: downscaled texture in image editor to 4x2k and it works, but reimporting on assigning to shader takes much more then initial import.

Have you tried unticking etc2 in project settings? You don't need it if you're not making stuff for mobile platforms...

Would it be possible for you to run with a debugger and supply us with a backtrace of the crash?

@Zireael07 yeah it helped. is it unfinished feature? but it is enabled bu default in new projects.

It is finished, and I don't know why it's enabled by default, given that 3.0 is unlikely to be used on mobile platforms since it's OpenGL 3.0...

Sounds like mobile dev will neef to cope with this in 3.0... but @reduz planned to do this reimport in a thread

Yeah, reimport needs to be moved to a thread.. but for now it needs general
testing. Just disable etc2 in the importer for now if not doing mobile
On Sep 2, 2017 10:52 AM, "Marc" notifications@github.com wrote:

Sounds like mobile dev will neef to cope with this in 3.0... but @reduz
https://github.com/reduz planned to do this reimport in a thread
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/10880#issuecomment-326745230,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2729J_WXOPE34Ng1rOD_yDWV-owcks5seV2AgaJpZM4PK1G9
.

authors: Zireael07 Zylann curly-brace hpvb reduz

repo: godotengine/godot


text:
Containers don't resort themselves properly when elements inside are removed

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Propably since forever.
Issue description:
A while ago I made this report https://github.com/godotengine/godot/issues/10207, thinking that the problem was only with ScrollContainers, but with the help of @manokara, we found out that the problem lies with Containers in general.
Here's the true issue: Containers take into account the removed elements when auto resorting.

@reduz, as the archived bug before this one was tagged "hero wanted", could you consider tagging this one it as well? As it affects not just ScrollContainers, but all Containers in general.

This seems fixed in master.

@DualMatrix Just tested, still occurs.
But now reflecting a little more on it, I think this behaviour is fine. It would be quite the annoyance to have a Container with a certain size shrink itself when removing elements.

Closing then as a "feature" :)

authors: DualMatrix YeldhamDev akien-mga


text:
FileSystem cache error when importing an OBJ file

Godot 3.0 beta 1
Windows 10 64 bits
I opened a project, dropped an OBJ file in it, and I got an error popup telling me that Godot could not write to the filesystem cache.
Then the file showed up in this state:

And the log:
ERROR: _parse_material_library: Condition ' !f ' is true. returned: ERR_CANT_OPEN
   At: editor\import\resource_importer_obj.cpp:47
Warning: Ambient light for material 'None' is ignored in PBR
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
current material library ship_gridmap_h.mtl has 1
current material None has 1
Added surface :None
ERROR: Node::set_name: Condition ' name == "" ' is true.
   At: scene\main\node.cpp:1142
node: Scene Root
node: MeshInstance
node: Cube.009_Cube.012
node: Cube.008_Cube.011
node: Cube.007_Cube.010
node: Cube.006_Cube.007
node: Cube.005_Cube.006
node: Cube.004_Cube.005
node: Cube.003
node: Cube.002_Cube.004
node: Cube.001_Cube.002
node: Cube_Cube.001
SAVING TO: res://.import/ship_gridmap_h.obj-4a529b2cabbf432dc4cf5b6d82791159.scn
ERROR: FileAccessWindows::close: Condition ' rename_error ' is true.
   At: drivers\windows\file_access_windows.cpp:139

The OBJ:
ship_gridmap_h.zip
Reimporting seems to restore a correct state, the OBJ is fine.

I got this one too

I tried to reproduce this issue on Godot master, unsuccessfully.
I'll find and build a version from December 4th 2017, next..

I could not reproduced the issue with about 20-30 attempts at various manipulations, on commit  a31735ad3608c9ec3a93db3ba294a7ad096fe453 (from December 4th 2017).
My hunch is that this issue is related to a Windows service temporarily taking the file after the copy happens? Maybe the anti-virus? Maybe the user's HD has a few weak bits? At this time, though, I'm afraid I'm not sure how to proceed...

This looks like it happened once and was never reproduced again, so it should be fine to close it (also it's similar to #6393).

authors: KoBeWi Overblob Zylann glaforte


text:
each time you remove/delete the photos. +1 increase to my spam threshold. it's growing, and it's growing fast. leave one thread up with the photos, and spam will not ensue. ty

you're too slow, not me


text:
Unable to move KinematicBody2D when "Sync to Physics" is enabled

Godot version:
f1970e1
Issue description:
When enabling Sync to Physics in a KinematicBody2D, I'm unable to make it move, either by using the move_and_slide_* methods, or by simply dragging it in the editor.

Still happening to me on 12290c172a6dd3763670d36039fbac8198e711f5, Windows 10, GTX 1060.
It seems like setting position in script is also ignored.
In the attached project it happens only to "player" scene. Setting the position while running is done by left click.
minimal_kinematic_character.zip
I don't know if this helps.

Is this really a fix? Or this a regression? Enabling sync to physics with beta 6 at least causes the same things to happen in my project as described here.

authors: Sslaxx TheNeverK YeldhamDev


text:
Add color status and gutters for VCS

Case:
If the project is under Git, SVN or other VCS
Proposal:

Add color highlight for changed and new files in project file tree.

Mark gutters in code editor by color of Git diff for added/changed/deleted lines.
Be able to see a Git diff for these line.

Both are really convenient features and I'm missing them so much in Godot Editor.
How it's done in different editors:
VS Code

IntelliJ IDEA

I think this is not necessarily related to Git, because in Visual Studio I can see the same "modification marks" in a project that does not use Git. They are very useful to quickly jump back to the place you modified files.
Basically, the editor just highlights modified lines that were not saved, changes their color when they are, and keeps that information until the file is closed.
This is even more useful with full-scale overview scrollbars such as code minimaps.

@Zylann Remember that scripts are saved every time you run the project, so ths usefulness of this would be limited when you're iterating on a script.

Agreeing with Calinou. If the prompts/highlights go away as soon as you save the file then this way of implementation without any VCS communication wouldn't work. The time in which this feature would be useful would be incredibly short for people who just instinctively like to save after an arbitrary amount of edits.

Well, I personally save compulsively so I kind of agree that the "modified but not saved" state of modification marks is not often useful in my case, but they are not going away because they stay until the script is not closed: the "modified and saved" marks are the ones I find useful, at least in my own usage. Both exist and it's still handy even if they don't relate to VCS.

@Zylann Yes a VCS API would be required for a proper implementation. The non-VCS behaviour is beneficial too and I think having both would be a treat rather than any one of them

@Zylann in the example you provided (QtCreator), the marks stay even after saving. So, at which point do they go away?

@jahd2602 I know you're asking about Qt Creator, but for reference, in Visual Studio Code, they go away when you stage changes using git add.

@Calinou Good to know. But what about vcs-less files?
I am asking because a possible course of action could be:

Start implementing marker that goes away on save: the code simply compares the current buffer with the saved one
Implement marker that persists even after saving (keep it until...?)
Integrate with VCS a la VSCode

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.
The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.
If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!
Note: In this case, it may be better to open in the https://github.com/godotengine/godot-git-plugin repository

authors: Calinou IronicallySerious Zylann clayjohn jahd2602 wyrmling


text:
Inspector contents goes over its size

Godot version:

3.2.dev 62c9af407
OS/device including version:

Kubuntu 19.04
Issue description:

Inspector contents goes over its panel size.
and resize panel won't help to fit in again.
Steps to reproduce:

make Inspector and Scene dock side by side
select node

Minimal reproduction project:

Is this also a regression from #28952?

authors: akien-mga volzhs


text:
Godot application does not show up in taskbar on Linux Mint

When running Godot on Linux Mint 17.3 (Cinnamon desktop), the application doesn't show up in the taskbar. No entry is added for Godot.
This means that if the window is minimized, it cannot be made visible again via the taskbar, which is a bit annoying.

Bug seen with Godot 2.0-beta.

Maybe there are some hints missing when creating the X11 window, so Cinnamon's taskbar doesn't consider the window for showing it up there.
I cannot confirm if the bug also exists in other Linux distributions or with other desktop environments (gnome, unity, kde...)

This has been brought up on the Facebook group a couple times, but not yet on this repo apparently :) See:

https://www.facebook.com/groups/godotengine/permalink/713127188823878/
https://www.facebook.com/groups/godotengine/permalink/722886857847911/

To sum up and not force people to use an evil social network ;), the bug seems to be https://github.com/linuxmint/Cinnamon/issues/4986 and should hopefully be fixed next time your distro updates Cinnamon.

The actual fix is https://github.com/linuxmint/Cinnamon/pull/5022 if you want to backport it for yourself, or notify your distro and ask them for a bugfix update.

I indeed avoid "evil social networks" :-).
Thanks for pointing me to the fix.

BTW, I can confirm it works just fine on KDE plasma.

authors: akien-mga bojidar-bg oxben


text:
[TRACKER] Command line-related issues

This issue tracks bugs related to command line support in Godot.
Bugs
Command-line argument handling

[ ] https://github.com/godotengine/godot/issues/17778

Command-line debugger

[ ] https://github.com/godotengine/godot/issues/19775
[ ] https://github.com/godotengine/godot/issues/32693
[ ] https://github.com/godotengine/godot/issues/32713
[ ] https://github.com/godotengine/godot/issues/50170
[ ] https://github.com/godotengine/godot/issues/51387

Pull requests

[ ] https://github.com/godotengine/godot/pull/36252
[ ] https://github.com/godotengine/godot/pull/40627
[ ] https://github.com/godotengine/godot/pull/44594
[ ] https://github.com/godotengine/godot/pull/51028

I think it's worth mentioning #49362, although I am not sure what's going to happen to it. In general, an issue I found was that the CLI tool was not just executing a tool, but actually initializing the editor.

authors: Calinou hinlopen


text:
Material distance fade is based on depth, not distance from the camera

Godot version
3.3.3
System information
Windows 7
Issue description
The spatial material distance fade is dependent on the facing angle of the camera, not the distance of the object. I believe this is because the distance fade is going on the depth rather than the distance:

This can be an issue in particular if distance fade is used to obscure objects from the player unless very close to them, as the distance of visibility changes drastically depending on the angle it's viewed from.
Steps to reproduce
Set the distance fade on a spatial material, rotate the camera and observe it become less faded the closer to the edge of the screen and more faded the closer to the center of the screen.
Minimal reproduction project
No response

Thanks for adding as a milestone, and great to see there is a solution! Can materials be extended in their current form so I can get them to work like this until there's an engine fix? I'm not sure how embedded material definitions are and how much they can be modified, or if it would currently require a custom build (something I've never been able to do successfully :/ )

This will be addressed by https://github.com/godotengine/godot/pull/50294 once it's fixed.

Can materials be extended in their current form so I can get them to work like this until there's an engine fix?

No, you need to define a ShaderMaterial. You can convert a SpatialMaterial to a ShaderMaterial by using the toolbox icon in the inspector.

Is this fixed for 3.4 RC?

Is this fixed for 3.4 RC?

No, see my above comment. This will only be fixed in 3.5 or later.

Did this make it to 3.5?

Did this make it to 3.5?

No, it's too late for this change to make it to 3.5. You can create your own custom editor and export template binaries if you need this change in a project.

Was this added to 3.5? I thought it was and just remembered it'll be its 1-year anniversary soon 🥹

Could this planned to be backported to 3.6? It'll be it's 1-year anniversary soon! 🥹

Could this planned to be added to 3.6? It'll be it's 1-year anniversary soon! 🥹

https://github.com/godotengine/godot/pull/50294 needs to be reviewed and merged first. There are some concerns about orthogonal cameras which should be addressed in some way.

Could this planned to be added to 3.6? It'll be it's 1-year anniversary soon! 🥹

#50294 needs to be reviewed and merged first. There are some concerns about orthogonal cameras which should be addressed in some way.

The merge seems blocked for the last 3 months?

authors: Calinou elvisish


text:
Modified built-in resources are not saved in inheritted scenes if parent is open.

Godot version
4.0.dev.custom_build.249c60e9d/ 3.4.2.stable.official
System information
Ubuntu 20.04
Issue description
possibly related: #27243, #55964,  #7984
If scene B inherits from scene A, and A has a sub-resource, when both are open, if changes to the sub-resource are updated and saved in B, then the changes to the sub-resource are applied to A in the editor, but are not actually saved until A is saved(which is not communicated by the * on the tab).
This can(and has!) lead to a lot of lost work if working on shaders or animations, for example.
Steps to reproduce

Create a scene A with some sort of built-in sub-resource, then create a inherited Scene B from A.
Keep both scenes open.
Modify the sub-resource in scene B and save only scene B.
Scene A will now display modified sub-resource.
Quit and reload the project without saving A.
Scene A and B will now have the unmodified resource.

Minimal reproduction project
subresource_bug.zip

Editing foreign resources is no longer possible, so this is resolved.

authors: FreegleBarr KoBeWi


text:
3D editor, ctrl remains pressed after closing (ctrl s) Save Scene As... window

Godot version
v3.5.beta2.official [7a4f9dfb1], v3.4.4.stable.official [419e713a2]
System information
Windows 10
Issue description
In the 3D editor. The ctrl key remains pressed,
after closing a window, that was opened with a ctrl shortcut.
For example: ctrl s (Save Scene As...) or ctrl a (Create New Node)
Workaround: Press and release the ctrl key once.
It happens when the window is closed by:

pressing enter to accept the file name or the selected node
left mouse clicking on the cancel button, top right x button, or outside the window

It doesn't happen when:

the window is closed with esc
the Save Scene As... window was opened from the menu: Scene > Save Scene
the Create New Node window was opened from the Scene dock's Add Child Node button

This was discovered when the 3D editors Use Snap (Y) button,
seemed to become reversed after saving a new scene with ctrl s.
This issue doesn't seem to happen in the 2D editor.
Related issue
There's a related issue where the ctrl key remains pressed when pressing ctrl alt tab:
"Use snap" button with "snap to grid" has inverted effect #26968
The issue is closed, but KoBeWi's comment https://github.com/godotengine/godot/issues/26968#issuecomment-490516437 still applies.

I just found a way to reproduce it. Hold Control to invert snapping and press Alt + Tab. When you focus Godot again, the Control will be "stuck" until you press it again

The issue was closed as a duplicate of:
If you alt-tab off and in the editor and you drag a sprite it will act like if alt were pressed #12592
But the duplicate is only referring to the alt key remaining pressed.
The duplicate issue was closed after someone was unable to reproduce it in Linux.
The third from the last comment https://github.com/godotengine/godot/issues/12592#issuecomment-558611903 asked if it's reproducible in Windows.
I'm unable to reproduce the duplicate (alt) issue in Windows in either Godot 3.5.beta2, or 3.4.4.
But since the ctrl alt tab issue, still is reproducible:
"Use snap" button with "snap to grid" has inverted effect #26968
Then it probably should be reopened.
Steps to reproduce

Create a new scene
Click on the button: 3D Scene to add a Spatial node
Make sure that the Use Snap (Y) button is disabled (above the viewport)
In the 3d viewport, move the Spatial node by dragging the red arrow.
Observe that the node moves by decimal values. It doesn't snap (as expected).
Now press ctrl s to open the Save Scene As... window
Left mouse click on the Cancel button
In the 3d viewport, move the Spatial node by dragging the red arrow.

Expected
Dragging the red arrow shouldn't snap, because the Use Snap (Y) button is disabled.
Observed
Dragging the red arrow now snaps to integer values.
Even though, the Use Snap (Y) button is disabled.
The same thing happens in reverse if the Use Snap (Y) button was enabled,
before the ctrl s (Save Scene As...) window was opened.
Workaround
Pressing and releasing ctrl, restores the expected behavior.
Minimal reproduction project
No response

May be related to #45033

I believe I have encountered this bug. If I press Ctrl + S and release Ctrl before the save popup disappears, it will get stuck. If I wait for the popup to disappear first, it doesn't get stuck. It seems to have all the other behavior mentioned in this issue.
The reason this doesn't become apparent in 2D editor is probably because it does not have snapping like in 3D (or at least, the same snapping behavior).
This is most likely because the save popup is implemented as a borderless window and that when you switch to other windows, the previous window no longer keep track of the keys pressed (or not pressed) and thus, the keys are stuck until you "refresh" them.

I wonder if we can resolve this by sending InputEventKeys that release Ctrl and S when saving scenes.

Sounds more of a bodge than a proper fix, though

authors: Calinou atirut-w duianto vetu11


text:
Rename texture corrupts scene

Godot version
v4.0.beta.custom_build [d759210f5]
System information
Windows 11, Forward, Geforce 1660 (526.98)
Issue description
https://user-images.githubusercontent.com/10379487/205687024-69162df7-ab87-488d-90cf-809b8145d56d.mp4
This behavior repeats regardless of which node (TextureRect, Sprite2D, TileMap) uses the texture. Sometimes at the moment of renaming, Godot crashes.
Steps to reproduce

open main.tscn
rename texture

Minimal reproduction project
scene_content_corruption_test.zip

Duplicate of #69260 (same cause)

authors: KoBeWi lufog


text:
GDScript resources are not unloaded due to an extra reference

Godot version
v4.0.3.stable.official [5222a99f5], master
System information
Kubuntu 23.04
Issue description
It looks like we have an extra reference to the script somewhere, which prevents it from being freed at the right time.
See also the comment.
CC @adamscott
Steps to reproduce
const RES_PATH = "res://a.gd"
#const RES_PATH = "res://icon.svg"

var i := 0
var wr: WeakRef

func _ready() -> void:
    print("has_cached = ", ResourceLoader.has_cached(RES_PATH))

func _on_timer_timeout() -> void:
    print("===")
    if i % 2:
        print("has_cached = ", ResourceLoader.has_cached(RES_PATH))
        print("wr = ", wr.get_ref())
    else:
        var res = load(RES_PATH)
        wr = weakref(res)
        print("has_cached = ", ResourceLoader.has_cached(RES_PATH))
        print("ref count = ", res.get_reference_count())
        print("wr = ", wr.get_ref())
    i += 1

has_cached = false
===
has_cached = true
ref count = 2
wr = <GDScript#-9223372010413882237>
===
has_cached = true
wr = <GDScript#-9223372010413882237>
===
has_cached = true
ref count = 2
wr = <GDScript#-9223372010413882237>
===
has_cached = true
wr = <GDScript#-9223372010413882237>

has_cached = false
===
has_cached = true
ref count = 1
wr = <CompressedTexture2D#-9223372010380327805>
===
has_cached = false
wr = <null>
===
has_cached = true
ref count = 1
wr = <CompressedTexture2D#-9223372010162223997>
===
has_cached = false
wr = <null>

Minimal reproduction project
bug-script-ref-count.zip

It looks like we have an extra reference to the script somewhere, which prevents it from being freed at the right time.

It's by design to enable cyclic references. Each GDScript loaded has a Ref instance living here:
https://github.com/godotengine/godot/blob/e188d619227990001667821dac8bc8940076d4a9/modules/gdscript/gdscript_cache.h#L79-L81
But the garbage collection part is not yet implemented, unfortunately.

Does this mean that @unload_static doesn't really matter now: scripts aren't unloaded anyway?

It's by design to enable cyclic references. Each GDScript loaded has a Ref instance living [in the cache]

I believe we talked about this in the chat but let me register here as well for the record. The cache should not be keeping extra references to scripts. It's fine if the scripts themselves are in a cycle, since that is unavoidable (and where a cycle collector would be handy), but in the case there are no cycles the scripts should be naturally freed.
Scripts sometimes preloads scenes which can get quite heavy so keeping them in memory can ended up with a lot of used space which is not obvious where it comes from. Without the collector it's much worse because there's currently no way to unload scripts.
So this needs to be addressed. I do plan to work on this (probably next month if nobody beats me to it). I've also notice some other issues with the cache, like keeping non-compiled scripts as if they were compiled which gives another sort of problems.

The cache should not be keeping extra references to scripts.

I agree. I was the one that modified the cache to make it so that it keeps an extra reference to the script.
But the reason why references are kept in the cache is because a script reference count would drop to zero even before having the opportunity to cyclically reference itself. So if we're able to fix that issue, I'm all in to drop these references.
Maybe we could try to store the refs shallow scripts, but once a script is fully loaded, only cache the pointer (not a ref of a script).

Looking forward to any progress on this👀

authors: adamscott dalexeev jinyangcruise vnen


text:
Transform origin (translation) of Node not saved to scene file (tscn)

Godot version
3.5.1.stable
System information
Windows 11
Issue description
In my main scene, I load a sub-scene CameraController and set its transform in the main scene Node inspector.

The translation does not get saved to the tscn file (no transform property), which can be checked by reloading the project or looking at the tscn file with a text editor.
I tried setting the value directly in the tscn file, then reloading the project. Once I hit run, the tscn file is overwritten and the transform property is removed.
This happened only with this particular sub-scene, so I stripped it down to the bare-bones and it still reproduces.
Steps to reproduce

Load the repro project attached
Set the translation of the CameraController node in Main.tscn
Save the project
Reload the project
Check the translation of the CameraController node in Main.tscn.
Notice that the translation is back to 0, 0, 0.

Repeat the above with the rotation or scale property and notice that these do persist.
Minimal reproduction project
parks_repro.zip

The problem is coming from the animation player:
ERROR: Failed setting key at time 0 in Animation '' at Node '/root/EditorNode/AnimationPlayer', Track '.:zoom'. Check if property exists or the type of key is right for the property
   at: _animation_update_transforms (scene/animation/scu/../animation_player.cpp:878)

Something is incorrect in the animation, and it is failing and this is mucking up the saving. Will add more info as I get it.

Yes, zoom was removed as part of reducing to the bare minimum repro project.
Interesting! The reset_on_save checkbox explains it. I long ago removed the actual animation that affects CameraController translation, and completely forgot that the RESET animation still referenced translation.
Thanks for looking into this, and so quickly! Much appreciated :)

authors: adamlesinski lawnjelly


text:
My RigidBody2D with a Camera2D won't move if I rotate it (GDScript)

Godot version
4.0.3.stable
System information
Windows 11, gl_compatibility
Issue description
If I change the rotation_degrees of a RigidBody2D with a Camera2D, it won't move. If there's no Camera2D, the car moves successfully with a rotation.
Steps to reproduce

Add a Camera2D to a RigidBody2D car
Set cam.enabled = true
Use the directionals to move the RigidBody2D

The car rotates depending on pressed directionals

Minimal reproduction project
godot_camrotationbug.zip
Look at src/entities/AutomobileEntity.gd

Change the constant ROTATION_ENABLED at the top to true or false. The car will move if false.

This really isn't a minimal project, can you please create a minimal project that shows the issue?

Oh, but isn't that torque meant for other kind of top-down car games?

If you don't want to mess with that you can just use CharacterBody2D, it seems you're using RigidBody2D in a way it's not meant to
It's for rotating objects, it isn't the torque of an engine, torque is just the rotation equivalent of force (kinda, not really, but kinda)

@AThousandShips Well, I did try using CharacterBody2D, but I've two issues with it:

Friction. You can't slide through ice-like walls unless you check for collisions and their angles. I was able to slide with CharacterBody2D, but had to implement a very limited slide collision check.
Forces. You can't apply forces; you've to tweak the speed manually.

The game I'm trying to mimmick (SharkBite Bay), done in ActionScript 3 by some guy, uses a rigid body from a general relativity library. Also, the car doesn't move like in most common 2D top-down car games. Directionals do not increase/decrease rotation like in other games...

Look at the documentation above to see, you're not supposed to set the rotation every frame as it breaks the simulation, you need to use other means

But I've locked the rotation with ``

No, where are you getting that?

RigidBody2D.lock_rotation

If true, the body cannot rotate. Gravity and forces only apply linear movement.

[How to implement the movement system from SharkBite Bay Adventure?](https://gamedev.stackexchange.com/q/205831/172220)
[Constant rotation tween in Godot 4](https://stackoverflow.com/q/76400925/19692949)

That doesn't say you can change it freely, the following still stands:

Please also keep in mind that physics bodies manage their own transform which overwrites the ones you set.

Neither of those use RigidBody2D, the first uses CharacterBody2D and the later Node2D

I asked these questions before using RigidBody2D. Well, what can I do then? CharacterBody2D is very inflexible, for example... if you hit a wall with a very high speed, the car gets stuck on the wall due to accumulated speed. To fix this I've to manually check if the car collided in a certain angle and reset the speed in that direction, and of course this only works for rectangles. Using RigidBody2D I don't need to worry about this.

Then follow the instructions for how to rotate them, you can't set the rotation of a RigidBody like this, or use the custom integrator for rotation
This is a limitation of this type of body, as documented

I'm not sure changing anything in _integrate_forces will resolve the camera problem. When I remove the camera, the car works. So it's clearly a bug.

Have you tried? Try making a way to rotate the car that follows the proper way of doing things and see if it resolves your problem, as you are, as far as I know, not doing things correctly, and if you are you can't expect it to work correctly

I've played with state.angular_velocity = 1 in _integrate_forces and that doesn't break the camera behaviour and makes the movement work, so it may help, but I'm not entirely sure how I'd create a tweener to work with this.
I was not using Godot's built-in Tween because:

It requires a duration. There's no duration in my case.
It goes either clockwise or counterclockwise wrongly sometimes (e.g. I want to go to target angle through the fatest route: clockwise or counterclockwise).

Aside that, there is one issue with setting state.angular_velocity! Depending on how I move the car, the angle abruptly changes itself even without assigning rigidbody2d.rotation_degrees or rigidbody2d.rotation. Bug?

Use a tweeler to assign the target angle, and use angular velocity to move towards it
But this isn't a help desk, while the camera thing might be a bug, and someone will look into that. But for support questions and help please first turn to the other community channels, this is for bug reporting, I've tried to help you by pointing you in the right direction, but this isn't what this is for.

authors: AThousandShips hydroper


text:
NavigationAgent stops working when unpausing and pausing in same frame

Godot version
v4.1.beta.custom_build [a83eb16fb]
System information
Windows 11
Issue description
NavigationAgent loses its map when unpausing and then pausing in the same frame.
Steps to reproduce

Run minimal reproduction project
Press ui_up to pause game
Press ui_down to unpause, pause then unpause again at once
See that NavigationAgent stops moving since velocity_computed signal stops being called
See that the NavigationAgent's map is printed and is missing even after unpausing

Minimal reproduction project
NavigationAgentBug.zip

Would be fixed by PR https://github.com/godotengine/godot/pull/75888 adds a "true" pause mode for agents without removing the navigation map.


text:
Tileset collisions: The expanded polygon drawing tool can get stuck in a state where modifications are ignored.

Tested versions
v4.2.1.stable.official [b09f793f5]
System information
Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1070 Ti (NVIDIA; 31.0.15.3699) - Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12 Threads)
Issue description
When trying to draw collision polygons on 2D tiles, there has been two situations that put the expanded editor in a state where no further modifications are "registered": modifications will still show normally in the editor itself, but when saving and closing the editor, your last changes will be lost.
The two scenarios:

Draw a polygon of any shape.
Use the clear option.

Any further node addition / move / deletion will be ignored.
Steps to reproduce

Create a tileset atlas with a texture.
Add a physics layer.
In the tileset editor at the bottom, got to Physics > Physics Layer 0, select a tile, and select the Expand editor option:

Trigger one of the two cases:

Draw any shape. Once the shape is "closed", no more modifications will take effect. Illustrated below: I drew a triangle, and then modified it to be a square.

Use the clear option. No more modifications will take effect. Illustrated below: I cleared an existing polygon and drew a new one.

Saving has no effect.
Minimal reproduction project (MRP)
mrp_tilset_poly_editor_bug.zip

I can confirm that I am also experiencing this with version: v4.2.2.stable.mono.official [15073afe3]
for macOS

I was going to open a similar issue.
I can add a couple of points to this.
Adding/removing a polygon the first time in the expanded editor works correctly.
Any modifications after that does not work.
I have been debugging the engine and I narrowed it down to the reparenting of the expanded area.
The following code is expanding the editor
Adding the expanded editor -> https://github.com/godotengine/godot/blob/master/editor/plugins/tiles/tile_set_editor.cpp#L753
Removing the expanded editor -> https://github.com/godotengine/godot/blob/master/editor/plugins/tiles/tile_set_editor.cpp#L783
The following debug values are from removal of the expanded container, I checked there to see the original parents signal map because it looked like something was not emitted/received right.
"multiple_properties_changed' seems to be the one informing others about new polygons.

I have been trying to fix it in a nice way for the last 2 days.
If any developer can suggest a solution I can implement, I would be happy to create a pull request!
@KoBeWi maybe?

I was going to open a similar issue.
I can add a couple of points to this.
Adding/removing a polygon the first time in the expanded editor works correctly.
Any modifications after that does not work.
I have been debugging the engine and I narrowed it down to the reparenting of the expanded area.
The following code is expanding the editor
Adding the expanded editor -> https://github.com/godotengine/godot/blob/master/editor/plugins/tiles/tile_set_editor.cpp#L753
Removing the expanded editor -> https://github.com/godotengine/godot/blob/master/editor/plugins/tiles/tile_set_editor.cpp#L783
The following debug values are from removal of the expanded container, I checked there to see the original parents signal map because it looked like something was not emitted/received right.
"multiple_properties_changed' and "polygons changed" seems to be important for new polygons.

I was trying solutions similar to these
https://github.com/godotengine/godot/blob/master/editor/plugins/tiles/tile_set_atlas_source_editor.cpp#L2890
https://github.com/godotengine/godot/blob/master/editor/plugins/tiles/tile_data_editors.cpp#L883
Or this

If any developer can suggest a solution I can implement, I would be happy to create a pull request!
@KoBeWi maybe?

Reparenting does not affect signal connections.

authors: KoBeWi StylianosGakis b-basa louis-vinchon


text:
debug release does not compile

Operating system or device - Godot version:
macOS (OSX) Xcode
Issue description:

can't compile with debug_release. the error:
api_generator.cpp line 264
	if (method_bind && method_bind->get_return_type() != StringName()) {
		method_api.return_type = method_bind->get_return_type();

get_return_type() does not exist.
it's declared here:
method_bind.cpp line 208
#ifdef DEBUG_METHODS_ENABLED

	_FORCE_INLINE_ void set_return_type(const StringName &p_type) { ret_type = p_type; }
	_FORCE_INLINE_ StringName get_return_type() const { return ret_type; }

	_FORCE_INLINE_ Variant::Type get_argument_type(int p_argument) const {

		ERR_FAIL_COND_V(p_argument < -1 || p_argument > argument_count, Variant::NIL);
		return argument_types[p_argument + 1];
	}

	PropertyInfo get_argument_info(int p_argument) const;

	void set_argument_names(const Vector<StringName> &p_names);
	Vector<StringName> get_argument_names() const;
#endif

Seems like this part hasn't been touched since clang-format so it is probably not the issue.

CC @karroffel, it's in GDNative

@akien-mga @karroffel seems like this was a temporary issue. I compiled with debug worked, and than also debug_release worked. (maybe it even was a user error. Could be possible that I'm missing something...)
sorry for wasting your time


text:
Further symlink fixes

Turns out my second attempt to fix symlinks in #10883 still has issues as reported by @neikeq. So this is yet another take that fixes the problem he encountered.

I can confirm that before this PR, --doctool is broken:
$ godot-git --doctool doc/base/classes.xml
[...]
ERROR: open: Condition ' err != OK ' is true. returned: err
   At: core/io/xml_parser.cpp:487.
No Doc exists. Generating empty.
ERROR: save: Can't write doc file: doc/base/classes.xml
   At: editor/doc/doc_data.cpp:878.

The PR fixes it:
$ godot-git --doctool doc/base/classes.xml
[...]
Doc exists. Merging..

I can confirm this fixed our issue as well.

This PR caused problems #11145

source: gharchive/pull-request

authors: Geequlim akien-mga neikeq supagu


text:
Fix some enums missing its bind

godot-cpp is not compiling due to these missing binds.

Not relevant for 3.0 branch.


text:
Fixes inspector NodePaths within exported arrays. Fixes #6609 and #20…

…005.

@akien-mga Fixed typo.


text:
A couple of GDScript fixes

b24cb92: Allow the iterator in for to be redefined. This is only to avoid breaking compatibility.
67fee40: Fix issue detecting the file class type. Fix #21996

Thanks!

authors: akien-mga vnen


text:
Improving of the code readability

"goto" constructs have been removed from the code. The changes are designed to improve compactness and reduce code complexity.

There are various style issues, both with indentation and with the spacing in parentheses: https://travis-ci.org/godotengine/godot/jobs/507326203
See Code style guidelines.

I disagree that this improves code readability. Not all gotos are bad!

Quite possible. The question is subjective in its essence.

I am good either way and remain completely neutral

Closing as there's no real gain nor consensus.

authors: Yeryomin1 akien-mga reduz


text:
GDScript optimisations, internal storage changed from Map to OrderedHashMap

Changed internal storage for
constants, member_functions, subclasses, member_indices, _signals from Map O (log n) to OrderedHashMap -> O(1) and also changed the default HashMap and OrderedHashMap RELATIONSHIP from 8 to 1 to reduce collisions.
My tests show an improvement of more than 10% in speed execution for a script that makes heavy use of external class variables (when that external class has 30 variables).
You will see no improvement if you test with classes that have few variables or a few functions and you test the speed referencing those but the difference in speed should increase for more complex classes.
Pull request is against 3.1 so tests can be done against the stable version but I don't think there is a problem to be ported to mainline.

Some other things might also work faster due to the RELATIONSHIP factor modifications. So if you have a pretty big project you might want to try this pull request out to see how it goes.

This is exciting! I have a pretty complicated thread simulation that I considered to rewrite in C with GDNative, so I'll definitely try out this PR tomorrow and see what improvements there are.

I made a simple benchmark for different version of Godot with this script, it seems slightly faster than 3.1.1 stable.
extends Control
static func fibR(var n):
	if n < 2:
		return n
	return fibR(n-2) + fibR(n-1)

const N = 34

func _ready():
	var start = OS.get_ticks_msec()
	print("fib: ", fibR(N))
	print("elapsed ", (OS.get_ticks_msec() - start)/ 1000.0, " s.")
	get_tree().quit()

The script was run 10 times with each version of godot and the result is the average time.
My CPU is AMD Ryzen 7 2700X

Language
Application
Elapsed(s)

GDScript
Godot 2.1.6
3.5862

GDScript
3.0.6.stable
3.1246

GDScript
3.1.1.stable
3.5148

GDScript
3.1.2.devel.32008
3.4565

GDScript
3.2.alpha.master
3.3769

Also compared with other scripts

Language
Application
Elapsed(s)

C
GCC 7.1.1
0.048339701

Lua
LuaJIT 2.0.5
0.066031742

JavaScript
Node 12.10.0
0.096387124

Ruby
ruby 2.6.4p104
0.650580239

JavaScript
QuickJS 20190901
0.768905473

wren
wren
0.81590507

Lua
Lua 5.3.5
0.852702856

Python
Python 2.7.15
1.4405406

Python
Python 3.7.2
1.74688139

AngelScript
AngelScript 2.31.2
1.931119013

GDScript
3.0.6.stable
3.0804

JavaScript
Duktape 2.3.0
3.238362741

GDScript
3.2.alpha.master
3.371

GDScript
3.1.2.devel.32008
3.443

GDScript
3.1.1.stable
3.5157

GDScript
Godot 2.1.6
3.5432

JavaScript
Duktape 1.8.0
5.822308016

@Geequlim You won't see much improvement from this PR if your test script has a small number of functions and / or variables and if it mainly uses the stack.

@puthre  For acessing script properties I made another test
var member = 1
const CONST = 2
func method(v1, v2): pass

func test_property():
	for i in range(10000000):
		self.method(self.member, self.CONST)

Language
Application
Elapsed(s)

GDScript
3.0.6.stable
1.6047

GDScript
3.1.1.stable
1.8068

GDScript
3.1.2.devel.32008
1.8426

GDScript
3.2.alpha.master
1.7489

@Geequlim still, you only have one method, so finding it using the hashmap instead of the rbtree map makes no big difference. Try having 50 methods and call all of them.

Pull request is against 3.1 so tests can be done against the stable version but I don't think there is a problem to be ported to mainline.

That's fine for benchmarking while discussing the changes, but note that we will not merge any PR against 3.1. Changes should be made in the master branch first, and cherry-picked into 3.1 once well tested and if deemed safe enough by release maintainers.
So please mark this PR as a "Draft" to prevent it from being merged by mistake.

So please mark this PR as a "Draft" to prevent it from being merged by mistake.

How do I do that?

Closing this for 3.1 as I opened #32289  against the master.

authors: Geequlim akien-mga asheraryam puthre


text:
Added VS2013 CE solution

NOTE: run build.bat at least once before building.
It needs manual updating of the project and right now is only configured for DEBUG mode.

I'm not a VS user myself so I might be mistaken, but I get the feeling that it's a bit overkill to add IDE-specific projects files in the main source tree that will only cater to 32bit build in debug mode, for VS 2013 CE and not other versions, and need to be updated manually. From my experience in other projects, this is typically the kind of files that slowly become unusable as the main buildsystem evolves and the main devs don't take care of updating those IDE specific-files.
IIRC, there is a "vsproj" option in the scons buildsystem that could be used to generate project files for VS that would be in sync with the current buildsystem. It might not be working properly judging by recent bug reports, but maybe it would be better to fix it than workaround the issue by providing project files for every VS version currently in use?

Well, I find debugging form VS very useful, I'll add the missing RELEASE config and can maintain this project updated as long as I'm testing the engine. Others can do it also, is not that hard.
The SCons autogenerated project seemed to have some limitations as far as I read. Never get it to work though (when it worked)

As per the above arguments, I'll close this one as I don't think that it would be a good addition. We don't want to start maintaining custom project files for every possible IDE, so either we can generate them using scons, or we won't.

I know this is archived, i just want to note that i might be able to get a vsproj=yes to generate a good nmake config for scons (basically vsvarsall.bat x86 && scons etc in nmake build settings)... but will need to check.
It's the next on my to do list. It's just some info.
I'll definitely take a look at this work here and see if can get debug link stuff going properly as well, so that debuging works through the vsproj as well, so thank you for your work @ex, i think it might prove very usefull indeed after all :)  (as I'm not a debuger expert in VS yet) :)

authors: Griefchief akien-mga ex


text:
Renamed String.ord_at to unicode_at

One of the proposed renames from https://github.com/godotengine/godot/issues/16863

The changes in GDNative aren't needed since I'm removing the methods there.

The changes in GDNative aren't needed since I'm removing the methods there.

Thanks!

Thanks!

authors: Chaosus akien-mga vnen


text:
Emit changed signal from Color Picker when changed

This reverts #44895 and applies a different fix. Instead of not emitting signal it's now emitted only when color was changed.
Fixes https://github.com/godotengine/godot/pull/44895#issuecomment-757148892

Thanks!

Thanks!

Cherry-picked for 3.2.4.

Cherry-picked for 3.2.4.

authors: KoBeWi akien-mga


text:
corrected method name set_event

Fixes: #51514

Thanks!


text:
quick fix for issue #60887

This fixes #60887 although is does not fix the underlying problem that the TileSetAtlasSourceEditor does not work if it has no source. Right now there is no way to properly remove the tile_set_atlas_source of TileSetAtlasSourceEditor. I think it would be better to change TileSetAtlasSourceEditor so that the tile_set_atlas_source_id can be set to -1 to indicate that no source is selected. Since this would require a lot of functions to be changed I think it would be better if somebody else did that because this is my first issue.

What do I have to do to pass these static checks?


text:
Improve GDScript documentation generation & behavior

Rework of GDScript classes' documentation generation (docgen).
Changes:
• Removes docgen code & datastructures from gdscript_compiler.cpp and gdscript.cpp
• Docgen uses analyzer datatypes instead of less expressive runtime datatypes
• Enums return/parameter types docgen'd properly instead of being Variant or int. Fixes #71117
• Makes hyperlinks to unopened classes generate their documentation on-demand rather than show blank screen. Fixes #72406
• Signals parameter types are docgen'd correctly instead of being Variant
• Added same-line docstrings for variables/constants
• Show external class specifiers e.g. TileSet.CellNeighbor instead of CellNeighbor, OtherClass.Enum or InnerClass.Enum instead of just Enum
• ⚠ ⚠ ⚠ Remove unnecessary class specifier path, e.g. InnerClass.Enum instead of CurrentClass.InnerClass.Enum or Inner3.Enum instead of Class.Inner1.Inner2.Inner3.Enum, when documented inside Inner2⚠ ⚠ ⚠  this one might be slightly contentious ⚠ ⚠ ⚠
• Created a fairly comprehensive set of gdscript files with all/most combinations of types to make sure this works properly (linked below)
Minor changes:
• Removes unused p_scroll parameter in EditorHelp::go_to_class() and p_vscr in EditorHelp::_goto_desc()
• Removed unused DocData::EnumDoc
• Normalize docstrings in EditorHelp source code
Enums and class specifiers everywhere!
Before (boooooo):

After (yaaaaaay):

Inline docstrings!

Possibly contentious class specifier prefix elimination!

(see below for gdscript class & enum types)
Notice how we are within Doc1.IC, and therefore in the highlighted areas only relevant class specifier prefixes are shown. We don't need Doc1.IC, just IC. We don't need Doc1.IC.IE or IC.IE, just IE. We don't need Doc1.IC.IIC or Doc1.IC.IIC.IIE, just IIC or IIC.IIE.
Test files!
gdscript_docgen.zip
These are the files I used to test. They are organized as follows:

Two outer classes, Doc1 and Doc2
Doc1 and Doc2 have an inner class IC, which has an inner inner class IIC.
Each class, outer or inner, has corresponding enums, E, IE, and IIE.
Doc1 and inner classes, have methods containing all combinations of accessing classes and enums I could think of, both as parameters and return types.

As far as I can tell, every type name is as I thought it made the most sense (i.e. remove prefixes which are "obvious"), and click-linking works also.

Also, for the folks following, I updated the original post with all the things happening in this PR :)
Let me know if there are any other wants that I could include here!

Quick note regarding inline doc comments: it was bothering me when testing because it was doubling the vertical space required by variables if you decided to document it. I really do think it's worth for classes that have more than a handful of variables. And I am always available to fix any regressions :)

This is amazing! Thanks a lot!

Thanks everyone for your time, comments and support 😄 ❤

Not sure if this is relevant, but I'd like the LSP to be integrated with docgen so we can get consistent docgen behavior.

authors: YuriSizov anvilfolk atirut-w


text:
Abort on startup with a visible alert if required Vulkan features are missing

See https://github.com/godotengine/godot/issues/70013#issuecomment-1407456929.
Preview

Amazing! Does this work on mobile devices as well?

Amazing! Does this work on mobile devices as well?

It should work as alert() seems to be implemented on Android and iOS, but I haven't tested.

At least on Android alert() is not blocking https://github.com/godotengine/godot/issues/49969, so it won't actually be possible to read the dialog.

At least on Android alert() is not blocking #49969, so it won't actually be possible to read the dialog.

I just tested and it's not blocking on iOS either.
OS.alert("This is our message","Alert!")
OS.crash("Crash message")

Causes a crash before the alert is visible on screen, so I assume it would be the same in this case of the alert about required vulkan features.

Given the current situation that on mobile alert() isn't blocking, perhaps a compromise could be to simply not crash/exit on mobile. As I understand it that would leave it at a black screen once the user closes the alert message with the info, but that's fine and much better than the alternative (crash with no explanation) or current situation (black screen with no explanation).

I removed the CRASH_NOW_MSG() call, so the previous indefinite black screen behavior is restored.

I think this still needs to return ERR_CANT_CREATE otherwise it will try to continue initializing Vulkan

I think this still needs to return ERR_CANT_CREATE otherwise it will try to continue initializing Vulkan

Done :slightly_smiling_face:

Tested locally and this seems to work fine now. The popup works as expected and then falls back to the normal "failed to initialize vulkan" error which points the user to using the compatibility renderer.

Thanks!

authors: Calinou RedworkDE akien-mga clayjohn lostminds


text:
GLTF: Move unique name generation code to GLTFState

This PR moves the _gen_unique_name method from GLTFDocument into GLTFState and renames it to generate_unique_name. Without this PR, it is not possible for GLTFDocumentExtension classes to generate unique names, so it's not possible to provide the same uniqueness guarantee as GLTFDocument itself.
This PR also cleans up the code a bit, replacing the while (true) and break; code with a simple for loop. I tested it and it functions exactly the same as before, just now the code is easier to read.
Note: Per Lyuma's request, I have removed the exposing in this PR, so this PR is just moving the method and making it available to in-engine C++ code. We can expose it in a future PR.

@lyuma mentioned some comments on this

I have no strong opinion either way, but this seems to introduce an inconsistency with other similar helper methods:
String _gen_unique_animation_name(Ref<GLTFState> p_state, const String &p_name);
String _gen_unique_bone_name(Ref<GLTFState> p_state, const GLTFSkeletonIndex p_skel_i, const String &p_name);

authors: aaronfranke akien-mga fire


text:
C#: Implement proper generic type name printing for Godot Editor

The current Godot Editor Implementation fetches a class_name directly from the System.Type.Name, which does not return the full definition of a generic type (only the generic parameter count).
This PR uses an algorithm created by @ZerxZ, @TML233, and @jinsediaoying for printing the actual underlying generic type definition.
Our tests have convinced us this algorithm is capable of handling all generic use cases, see the following comparison.
This only runs under DEBUG (fallback to System.Type.Name otherwise), so it should not affect runtime performance.

Before
After

These are the actual type header definitions in the scripts
public partial class ListItemComponent<TData> : Control { /*other*/ }

public partial class ComplexCrazyListItemComponent<T1, T2, T3, T4> : ListItemComponent<(int, float, (List<Func<List<Dictionary<List<int?>, List<int?[,,]>>>, List<(List<int>, List<int[]>)?>>>, List<int[,,][,][,,,,]>))?> { /*other*/ }

public partial class Test<T> : ComplexCrazyListItemComponent<int, float, GodotObject, List<int>> { /*other*/ }

public partial class Test2 : Test<GodotObject> { /*other*/ }

Apart from the couple of while (true) that I personally am not a fan of, it looks good to me.
Maybe this should run in #if TOOLS instead of #if DEBUG?

Both #if TOOLS and #if DEBUG won't work. User projects normally retrieve the GodotSharp assembly from NuGet.org and that will be compiled with the Release configuration and no TOOLS define. Since you tested this on a custom build of the engine, that will use the package from your local NuGet repository, and I assume you built GodotSharp with the Debug configuration.
Performance-wise I think the best we can do is check Engine.IsEditorHint() and hope that the JIT optimizes this away after a couple of executions.

This should work by now.

You erased your changes by your push and resetting the branch, which closes the issue, to restore and get back to where you were use:
git reset --hard fea4f15

And then try again

Oh, I accidentally made a pushed in the middle of rebasing my PR to the latest master, will update shortly.

Superseded by https://github.com/godotengine/godot/pull/88363.

authors: AThousandShips Delsin-Yu paulloz raulsntos


text:
Expose ImporterMesh.create_shadow_mesh() to scripting

Following the suggestion in:
https://github.com/godotengine/godot-proposals/issues/8567
Tested with both an editor and a template_release build. The methods are confirmed to work as desired in the editor build.

For the record, your commit seems not to be linked to your GitHub account. See: Why are my commits linked to the wrong user? for more info.
(In this case you authored your commit with lmackay@localhost.localdomain which is obviously not a valid email for your account.)

You would also need to generate the class reference for these new exposed methods, and fill their descriptions. See https://docs.godotengine.org/en/stable/contributing/documentation/updating_the_class_reference.html#updating-class-reference-when-working-on-the-engine

Seems fine once docs are added as pointed out by Akien

@laurentmackay Can you look into addressing the above comment? If you don't have time, let us know and someone else can salvage the pull request :slightly_smiling_face:

Thanks for the feedback!
Sorry for the delay, I was running into git issues....
I have generated the required documentation. I also rebased which hopefully is not a problem.

Lots of unrelated commits show up, you probably messed up the rebase :(

authors: Calinou Zireael07 akien-mga clayjohn laurentmackay


text:
Feature Request: RelatedSearch and SpellingSuggestion

Is there any method to perform SpellingSuggestion or  RelatedSearch using this library? if not do you have any plan to implement it?

I have just added the feature. Star the repo if you feel satisfied. Stars make developers happy :smile:
Also let me know if there is any problem.
Cheers!

You rock man :+1: Thanks a lot for implementing this.

authors: aqibsaeed goferito

repo: goferito/node-bing-api

license: mit


text:
Markdown for headers does nothing

It just shows the hashes instead of making it a header.

What is your filename entension? Is it .md ?

Yes, it was the readme.md file.

Could you post the markdown source?

It was just #header, which should look like this:
#header

This issue can be closed.

You can close the issue yourself by clicking Comment and Close.

authors: Aidoboy linquize

repo: gogits/gogs


text:
bumps core GHA dependencies

Updates core GHA dependencies (checkout,setup-go) to latest stable versions

docker-publish workflow will be resolved by #204

repo: goharbor/harbor-cli


text:
Add support for --db-repository and --java-db-repository

This implements the --db-repository and --java-db-repository options to allow users to specify a custom Trivy vulnerability DB repository. This is useful for users who want to use a custom database repository, such as a private repository mirror like Artifactory or other private registries.
This adds SCANNER_TRIVY_DB_REPOSITORY and SCANNER_TRIVY_JAVA_DB_REPOSITORY environment variables as well as scanner.trivy.dbRepository and scanner.trivy.javaDBRepository helm values.
I have updated the documentation to reflect this new option, as well as one of the existing wrapper tests (feel free to change it).
This is the first step to address the issue I created on the harbor-helm repository: goharbor/harbor-helm#1821

i know that is a merged PR but , maybe we missed something, what if user want to use a private registry eg. local harbor.
You need provide somehow auth details....
@benji78

If we want to add authentication, it is much more complicated than just adding a --dbRepository option in the command being ran. I don't think using trivy registry login (previously trivy auth login) is possible. Therefore, it would require adding --username and --password (which is not recommended as the password may be exposed) or TRIVY_PASSWORD environment variable if it even is possible.
Also we would need to make sure it is working with multiple DB repositories likely coming in the next trivy release (v0.58).

The multi DB repo was enabled in 0.56
https://github.com/aquasecurity/trivy/discussions/7640

📦 Support for multiple DB repositories for vulnerability and Java DB ↻

@pkalemba I was working on multi DB repository when, looking at the tests, I realised that it should work with:
    trivy:
      extraEnvVars:
        - name: TRIVY_USERNAME
          value: USERNAME1,USERNAME2
        - name: TRIVY_PASSWORD
          value: PASSWORD1,PASSWORD2

authors: benji78 hoerup pkalemba

repo: goharbor/harbor-scanner-trivy


text:
testing: Add missing SASS (dart sass, libsass) tests

621194a3197d27e3b5909bca9b3efa6ae70da86c
cf7023cb90f70cb2189d562ad8e8e9a66e6eb46e
#12139

Yea, or as part of misc issues I guess.

repo: gohugoio/hugo


text:
Support for request logging?

Would it be feasible for Hugo to do basic request logging for the server, to aid users developing their websites?
Maybe something like:
DEBUG 2021/03/03 09:54:29 Received request: /foo/bar/index.html
DEBUG 2021/03/03 09:54:29 Received request: /img/img1.png
DEBUG 2021/03/03 09:54:29 Received request: /css/style.css
(etc)

Asking because I hit a strange problem where the rendered page (according to the log) was giving a 404, when clicking on it's corresponding rendered link.  Which AFAIK should never happen. :wink:
With Hugo seeming to not have any option to show the requests it's receiving, it was impossible to narrow down where things were going wrong.  eg "Is the link incorrect?", "Is there JS mucking with things?", etc.
Having looked through the Discourse and seen a few other people ask the same question over the years, they seem to be pointed towards this:
    https://discourse.gohugo.io/t/does-should-hugo-server-in-verbose-mode-log-http-requests-and-all-errors/8156/10
Personally, I'm surprised it's not already part of either --debug or --verbose logging, which seem like the right kind of area for figuring out what's occurring.
It's been a few years since the above Discourse thread though, so I'm wondering if it'd be feasible to add these days?  Hugo has gotten more complicated over the years, and stuff like this helps users learn it + diagnose issues (even if just eliminating things).

My 50 cents about this:

Hugo is a static site generator, we mostly care about files written to disk.
For 404 errors etc. you have pretty good support in browsers
I have never thought about this as something that I would need when using Hugo
This is the first issue (as I remember) asking for this

@moorereason No worries. :smile:
@bep There have been several people asking for variations of this, when looking through the GitHub Issues and and Discourse.  At least, to me they seem to be asking for this in one way or another. :smile:
Should I make a list for you to look through/confirm?

authors: bep justinclift


text:
WIP create: Avoid parsing/sorting of archetype front matter

Fixes #452

I will start over with this one.


text:
Add support for ESBuild asset bundling

Adds support for  ESBuild pipeline, as requested in #7321
The current implementation goes through a temporary file, because ESBuild doesn't support in-memory inputs for bundling yet. (see https://github.com/evanw/esbuild/issues/212). The temporary file isn't created with Afero, because

Hugo uses Afero 1.2.2, and Afero only supports TempFile wildcards in 1.3
This will hopefully be useless in the future anyway, when ESBuild supports in-memory inputs

Still needs documentation, but gathering feedback first.

Thanks for this, the code looks good. But since adding some API in Hugo is very hard to remove/change, we need to get the basis more or less right out of the gate, but I'm thinking out loud, please don't your time by incorporating any of the changes/things I talk about.

We have many "product name" type of functions in resources, e.g. (resources.PostCSS). Wen we add "native" JS bundling/transform support, I think we need to make it a feature that is named after "what it does", .e.g. js.Transform and js.Build.
It's unfortunate that we cannot use Hugo's virtual filesystem in the Build part of this (Transform should be fine), but I guess we have to start somewhere. I have looked at the upstream code, and it should not be hard to add an option to allow a custom filesystem implementation, but the owner of that repo needs to be convinced it's a great idea ...

@regisphilibert what do you think about the naming discussion above?

To properly answer I would need to understand the properties and attributes of both methods of the suggested js keyword.
I'm trying to write a code example, but fail to grasp what js.Transform would do (though I suspect Babel) and what attribute it would take (though I suspect of a slice of js resources)
So about the js keyword and the method you suggest:
Would js.Transform be used for Babel, and js.Build for ESBuild?
Do you have a code example of both js methods being used to reference a bundle? All I can think of is:
{{ with resources.Match "js/*.js" }}
  {{ $asset := js.Build . }}
  {{ $asset = js.Transform $assets "ES2020" }}
  <script src="{{ $asset.RelPermalink }}"></script>
{{ end }}

Where Build bundles and Transform applies the ES wished transformations...

I think the short answer would be:

js.Transform = resoures.Babel on steroids (as in: a million times faster): it converts one JS file from a format/standard/react to another. Typically used to support older browsers using newer syntax, but lots of use cases.
js.Build takes 1 input file and resolves ES module imports (node_modules and relative for now I guess) and does tree shaking (remove unused code) etc. and bundles into 1 JS file. I assume that you can do transformation in js.Build as well, but not sure.

Awesome, I get it.
Ok, this might sound a bit far fetched, but I'll just throw this out there.
For the sake of consistency with what we already have for image resources and to avoid the addition of yet another "function/keyword/shorthand" , couldn't we introduce those as methods on the resource:
{{ with resources.Get "js/index.js" }}
  {{ with .Build "ES2020" }}
    <script src="{{ .RelPermalink }}"></script>
  {{ end }}
{{ end }}

In the future we could bring other functions in alignment...

$jsAsset.Transform > resources.Babel
$jsAsset.Build
$cssAsset.Transform > resources.ToCSS/resources.PostCSS

I suspect that we've had this discussion before ...

So the image implementation supersedes the resources transformation package. I'm not sure I would have implemented it this way had I started fresh, not sure.
The beauty of the "function pipes" is that @remko can just add another function and it does not need to know anything about the surroundings (a good thing, according to Robert C. Martin
The other beauty of pipes is ... they can be piped, so $css | resources.PostCss | minify vs. $css.PostCSS.Minify.
I think that the method approach could work for "cross cut" concerns (transformations that would be applicable for most Resources, e.g. .Minify, but I'm not sure .Transform is "cross cut"?)

I don't see how this avoids "adding another" thing. If we want to make resources.Babel work like  js.Transform we could easily just call that function.

Yes I see.
The only thing I have against js is that it evokes a file extension or a media type, even though it could be used with files of a different extension (jsx etc...). Just like if we add css.Transform it could be used on scss files or else.
I like templates.Exists because it is agnostic of file extension or media type, it's just an internal concept people can rely on. So I would suggest something more aligned with this concept like:
scripts.Transform, scripts.Build?
And maybe in the future styles.Transform for CSS etc...

The only thing I have against js is that it evokes a file extension or a media type, even though it could be used with files of a different extension (jsx etc...).

It certainly belongs to "a group of media types" where application/javascript is the most common.  I don't think Transform works that fantastic as a function name, as "transformation" is what all of these functions does. So styles.ToCSS looks descriptive and good to me. For JavaScript I think we should just call the spade a space (even if there are variants, like JSX -- which is JS DSL) and say js.Transform (or maybe javascript.Transform); the little vague Transform kind of works because there are so many output variations (not just CSS).

I agree with everything said above :)

A note on the current implementation itself: the mechanism to go through a temporary file doesn't work well in watch mode it seems. The temporary file is generated in the assets/ dir (to make relative paths work), but this triggers a rebuild, which in turns creates a new temporary file, which triggers ...
If there's currently no easy way to ignore files ad-hoc in Hugo, I guess we'll have to wait for the API to change so it can get its input from memory.

A note on the current implementation itself: the mechanism to go through a temporary file doesn't work well in watch mode it seems.

If you name the temp file to match one of these, that should work:
istemp := strings.HasSuffix(ext, "~") ||
			(ext == ".swp") || // vim
			(ext == ".swx") || // vim
			(ext == ".tmp") || // generic temp file
			(ext == ".DS_Store") || // OSX Thumbnail
			baseName == "4913" || // vim
			strings.HasPrefix(ext, ".goutputstream") || // gnome
			strings.HasSuffix(ext, "jb_old___") || // intelliJ
			strings.HasSuffix(ext, "jb_tmp___") || // intelliJ
			strings.HasSuffix(ext, "jb_bak___") || // intelliJ
			strings.HasPrefix(ext, ".sb-") || // byword
			strings.HasPrefix(baseName, ".#") || // emacs
			strings.HasPrefix(baseName, "#") // emacs
		if istemp {
			continue
		}

If you name the temp file to match one of these, that should work:

Great, that works!

Given the naming discussion above, what should we name the new package? I will add a note that even if other "script types" are involved (TypeScript, JSX), the end result is (currently) always some form of JavaScript.

Is there a reason you need a "mybundle.js" parameter in javascript.Build?  If $myjs is a single file, the filename can be preserved. If you want to bundle files together (such as what Concat does), you can either pipe it into Concat first, or you can create your own bundle .js that import-s all the files you want bundled, so Build doesn't really need to support slices?

Is there a reason you need a "mybundle.js" parameter in javascript.Build? If $myjs is a single file, the filename can be preserved.

I just quickly wrote the "example" above without thinking. But we need a way to set the targetPath (with a default if not set), e.g. https://gohugo.io/hugo-pipes/scss-sass/#readout
Does the Build support TypeScript as input? If yes, we also need to consider the change in MIME types.
The thing is, if I do:
{{ $js := resources.Get "myscript.js" }}
{{ $bundle := $js | js.Build }}

I suspect there will be use cases where you would want to use both of the above, so we cannot use the same name as the only option.
This gets more obvious if this would be possible:
{{ $ts := resources.Get "myscript.ts" }}
{{ $bundle := $js | js.Build }}

What would be the extension in the end result?

@remko to conclude: If you rename the template package to match js.Build (ref the vote above), then I will merge this. There are still some API-questions that needs to be decided, but that I can ponder on my own.

Should be done.
Some notes:

I left the client in resource_transformers (because nothing changed there). It could be folded into the resource package.
I did not add a method mapping (e.g. jsBuild)
I copy-pasted resolveArgs from resources (because js.Build needs the same behavior), but didn't look at specializing it for the use or moving it to a shared function.
The ESBuild issue for in-memory input was just closed ( https://github.com/evanw/esbuild/issues/212 ). I'll wait until a release to remove the workaround with the temporary file

Thanks, I have squashed/rebased this branch into https://github.com/gohugoio/hugo/pull/7473 -- I need to do some testing/adjustments on my own before I pull it into master, but great job on this one, thanks, much appreciated!

authors: bep regisphilibert remko


text:
Theme submission: Bootstrap

Theme submission
Please make sure that you have read the theme submission guidelines before submitting a theme. The guidelines provide all relevant information and requirements that have to be fulfilled before the submission. We strongly suggest that you test your theme with the Hugo Themes Build Script before submitting the theme for review. If a submission does not meet the criteria mentioned in the README it will be closed. You may re-submit once you fix the problems with your submission. However, please note that we have limited resources and can not provide help for general web development issues. For Hugo support questions please refer to the dedicated support forum.
Please tick the relevant boxes for your theme in the checklist below:
Link to my theme repository: https://github.com/razonyang/hugo-theme-bootstrap
I made sure that...

[x] the repository contains a good README.md describing my theme
[x] an open source license has been added to LICENSE.md
[x] all metadata have been added to theme.toml
[x] screenshots have been added in the images/ folder with the required dimensions
[x] in case I'm using a customized demo via the exampleSite folder that

[x] https://example.com is set as base url in exampleSite/config.{toml, yaml, json} to avoid the abuse of unused domains
[x] I tested that my theme's demo works with the content directory of gohugoio/HugoBasicExample

[x] I tested my theme against the gohugoio/HugoBasicExample

[x] I've checked the developer tools' console in my browser for error messages

[x] in case my theme is using Hugo Pipes features like toCSS and PostCSS that I have committed the /resources directory with all generated assets, for my theme to work in the basic version of Hugo

N.B. By submitting a theme to the Hugo Themes Showcase you understand that you need to maintain your theme. If a theme demo breaks and remains broken then at some point it will be removed from the list without prior warning. If you no longer wish to maintain a theme please let us know.
New themes will usually be promoted on Hugo's official Twitter account. If you would like to be mentioned in the tweet please add your Twitter username to this submission.
Link to my Twitter account (optional): https://twitter.com/razonyang
Feel free to ask questions. We're glad to help.

Hi, how is it going?

repo: gohugoio/hugoThemes


text:
Edit description in feature specification to also reflect in BigQuery schema description.

Is your feature request related to a problem? Please describe.
When editing of current existing feature-specification description to ingest feature into Bigquery table, the changes only reflected in Feast-Core page.
Describe the solution you'd like
Edit description and trigger CI to sync entity and feature specification should also change the description in Bigquery schema description. This can eliminate manual change in the BQ schema itself if a revision of current existing feature is needed.

This makes sense @arfiadhi. It can possibly be picked up during 0.3.

thanks, looking forward to it! @woop

This feature is stale. Lets reopen if its still necessary given Feast 0.3 capabilities.

authors: arfiadhi woop

repo: gojek/feast


text:
Move storage configuration to serving deployment

This is a card for 0.3. Currently the Core service is the source of truth for subscriptions to data from Serving stores. The goal is to move this source of truth to the serving deployments, and have these deployments update their subscriptions and store configuration to Core.

#254 is meant to solve this


text:
Separate out svg and gi3d to their own repositories, and Ki Trees.  Gi exclusively contains Widgets!

A standalone SVG package, built on top of standalone GiRl #622, would be quite useful -- main other option is https://github.com/srwiley/oksvg but it is missing a fair bit of important stuff and isn't frequently updated.
It would make a lot more sense to have the SVG elements fully compartmentalized within their own standalone Ki tree, rather than being part of the overall widget scenegraph.  The parent SVGViewport just has an image that it renders to, and it doesn't need to bother about anything else except rendering straight to that image.  The gi.SVG as a widget just wraps around the SVG image, similar to bitmap.
SVG nodes do not directly process any events, so they really don't need to be in the overall tree.  The parent widget can handle any relevant events.  For example, grid exclusively processes mouse events at the level of the wrapping SVGView and uses sprites.
Likewise Gi3D can be its own separate repository, with 3D nodes in a completely separate tree.  The Embed2D node does get all events, but it wraps everything through the EmbedViewport, and other nodes only handle selection (manipulation is via additional separate manip nodes -- should put those in a separate tree too?).  In any case, Gi3D imports Gi and Gi contains the special support stuff to enable Gi3D -- mainly just separating out the impl so standard 2D users don't need to worry about it, and keeping the 3D tree separate enables the Widget only Gi.
Bottom line: Gi as a tree comprised exclusively of widgets!
Window is no longer a NodeBase -- just a standalone struct -- it doesn't have anything in common with a Widget Node -- and how about giving it a stack of Viewports which are also not nodes, but are rather things that contain widget trees and an associated image.  Each popup is a Viewport as it is now.  But having the widget trees all separated in their own Viewports makes so much more sense.
Basically, went too far in having one huge monolithic tree -- more properly encapsulated trees with their own definite node type is more sensible.  No longer necessary to constantly check which type of node it is -- just treat everything as a widget, etc.

Needed: name for SVG repo.  gsvg?  just svg?  probably just going for plain svg simplest and why not?

repo: goki/gi


text:
Something about modules and paths not working?

Parent issue: https://github.com/elastic/go-elasticsearch/issues/74
Copied from parent issue ---

Page: https://godoc.org/github.com/elastic/go-elasticsearch#Client
The link for esapi.API points to https://godoc.org/github.com/elastic/go-elasticsearch/v8/esapi#API which 404's:

This is a known defect, see #567.

authors: arnottcr jordansissel

repo: golang/gddo