text:
May I ask how much GPU graphics MEMORY is required for the operation of this program?

Hello, I'm sorry to bother you. May I ask how much GPU graphics memory is required for the operation of this program? I encountered the following error while using my GTX 3060 graphics card with 6G graphics memory: RuntimeError:CUDA out of memory. Tried to allocate 1.12 GiB(GPU 0: 6.00 GiB total capacity; 10.48 GiB already allocated. 0 bytes free; 11.05 GIB reserved in total by PyTorch). Should I switch to a server with huge graphics memory to run this code?

I deployed that experiment on A40 and it took about 30+GB

authors: fukeryester haha-lisa


text:
XSS in url

Hey!
I found out today that dalfox only finds xss in params... not in urls paths.
Like https://example.com/index.html<script>alert()</script>
or maybe like https://example.com/index.html'onerror=alert()'//
Can you find a way to do that?

Hi @SAGEof6iixPATHS
First, Thank you for submit Issue :D
Is there an example of response if it is not detected?
Dalfox is also scanning for path-based xss.

I am seeing this error when I add a potential vulnerable path...
My command: dalfox url "http://path.com/path/path/path" -b https://snak3.xss.ht
[signal SIGSEGV: segmentation violation code=0x1 addr=0x60 pc=0x5da2d4]

goroutine 37 [running]:
net/url.(*URL).Query(0xc000f9e4b0)
        /usr/local/go/src/net/url/url.go:1130 +0x14
github.com/hahwul/dalfox/v2/pkg/scanning.ParameterAnalysis.func6(0xc0016fc000, 0xc000192650)
        /root/go/pkg/mod/github.com/hahwul/dalfox/v2@v2.4.8/pkg/scanning/scan.go:1142 +0x8a
github.com/PuerkitoBio/goquery.(*Selection).Each(0xc000195a70, 0xc0007e9530)
        /root/go/pkg/mod/github.com/!puerkito!bio/goquery@v1.7.1/iteration.go:10 +0x46
github.com/hahwul/dalfox/v2/pkg/scanning.ParameterAnalysis({_, _}, {{0x0, 0x0}, {0x0, 0x0}, {0x1b914d8, 0x0, 0x0}, {0x0, ...}, ...}, ...)
        /root/go/pkg/mod/github.com/hahwul/dalfox/v2@v2.4.8/pkg/scanning/scan.go:1138 +0x9d6
github.com/hahwul/dalfox/v2/pkg/scanning.Scan.func3()
        /root/go/pkg/mod/github.com/hahwul/dalfox/v2@v2.4.8/pkg/scanning/scan.go:148 +0xdf
created by github.com/hahwul/dalfox/v2/pkg/scanning.Scan
        /root/go/pkg/mod/github.com/hahwul/dalfox/v2@v2.4.8/pkg/scanning/scan.go:146 +0x1105

I tried on phpvulnweb by acunetix but that works well, it ends the script after it scans all the possible ways...

@SAGEof6iixPATHS
Well, there's an error in the url package of golang. Is it the same problem with the latest version?

your version: v2.4.8
latest version: v2.5.3

You can update it yourself and use it, but just in case, I'll share the docker command!
docker run -it hahwul/dalfox:v2.5.3 /app/dalfox url "http://path.com/path/path/path" -b https://snak3.xss.ht

source: gharchive/issue

repo: hahwul/dalfox

license: MIT

license_type: permissive

license_source: github-api


text:
Type declarations

I'm installing this package on my repo but I have realized that it doesn't have type declarations:

Cannot find module 'goatcounter-nextjs' or its corresponding type declarations

Do you prefer to migrate it to TS or create a type declaration file?

I am planning to migrate to Typescript soon. I published the typescript branch. Will test it soon and merge it with main.

I have published 1.0.1 with Typescript.

Yeah!
Thank you!!

authors: haideralipunjabi jorgemasta

repo: haideralipunjabi/next-goatcounter


text:
Is it possible to print information to assist in development?

from abaqus_noGUI import *
print("Hello world")
exit("Error")
I successfully installed the code abqpy and tried to develop it, but I ran into a problem, that is, when my program was running, I always wanted it to print some tips for me, so that I could better grasp the running status of the program. These tips may be very important in the case of difficult debugging.
But I don't know why, maybe because of the 2.7 kernel of abaqus and python3 of abqpy. In short, the program printing was ignored, the second line above did not play any role, and the third line reported the error TypeError:' str' object is not callable.
I developed abaqus on the ide of pycharm. In abaqus software, I can use python2 version of print to print, but now I don't know how to print after using abqpy. I look forward to anyone's help. Very grateful.

I don't find any way to do this

I found out that you can use restore sys.stdout to force to print messages to the terminal, i.e.,
import sys

from abaqus import *

sys.stdout = sys.__stdout__
print("Hello, world!")

Thank you for your prompt response.
It worked, but not completely.
I am using your abqpy for ABAQUS secondary development in PyCharm.
When I run the code by typing "python mycode.py" in the command line terminal, the information I want to output is printed in the command line terminal.
However, when I use PyCharm to run the code, the information to be output is not printed in the PyCharm console.
I have also done some research recently. When I start the Abaqus process from PyCharm, Abaqus defaults to taking over the output stream, and there is no simple way to redirect this output stream back to PyCharm easily. I might just have to accept this fact.
Thank you again for your answer, and I look forward to hearing if you have any better ideas.

I just tested the code in PyCharm, and it works fine for me.

Thank you for your response. I have carefully reviewed my code and discovered a very interesting phenomenon.
In another program that I wrote and imported into my code, there was an output like this:
print('the result is ', resultant_force[0], resultant_force[1], resultant_force[2])
where resultant_force is a 1x3 array.
Surprisingly, this output was causing my issue, as it was the reason why there was no output after running my code.
If I simply modify it to: print('the result is ', resultant_force), without changing anything else, it outputs: ('the result is ', array([51.7550154759483, -0.0659758502744336, 28.8125464945722], 'd'))
If I modify it to: print('the result is ' + str(resultant_force[0]) + ' ' + str(resultant_force[1]) + ' ' + str(resultant_force[2])), it outputs: the result is 51.7550154759 -0.0659758502744 28.8125464946
Note that in this case, there are no parentheses. Both of these methods work effectively, and at the same time, all my other prints output normally, whereas previously, there was no output from my manual prints in the PyCharm console.
I tried to strip it down to a simple test, that is, only test the relevant code and strip away all irrelevant parts. Unfortunately, it might be because it did not enter the Abaqus kernel, print('the result is ', resultant_force[0], resultant_force[1], resultant_force[2]) outputs:('the resultant_force integrated by inp is ', 51.7550154759483, -0.0659758502744336, 28.8125464945722)
So at this time, it again had no issues and could output normally.
Therefore, my solution was to modify my print expression to one of the above that could output normally.
It might be related to Python 2's tuple printing, but strangely, it did not throw an error, it just did not output anything. Moreover, my stripped-down code part did not have this issue. I originally wanted to replicate my problem with simple code, but due to time constraints, I decided not to.
Thank you again for your response. Your development of adqpy has been very useful to me.
Regards

authors: haiiliin studyhardhardhard

repo: haiiliin/abqpy


text:
Table name generator creates long table names

When using the table helpers the table name is generated by contatenating various strings. Unfortunately even with short names for the various fields this can easily create table names which are longer than the 48 character maximum - giving the following error on Create(): Column family names shouldn't be more than 48 characters long.
Happens here:
https://github.com/hailocab/gocassa/blob/02f233ec3d3e1d0fd18d88929f286cbf8a4bc80d/keyspace.go#L97-L100
t: k.table(fmt.Sprintf("%s_multiTimeSeries_%s_%s_%s_%s", name, indexField, timeField, idField, bucketSize.String()), row, m, Keys{
	PartitionKeys:     []string{indexField, bucketFieldName},
	ClusteringColumns: []string{timeField, idField},
}).(*t),

I can't see any way to continue to override this naming while continuing to use the receipe tables? Happy to submit a patch, any suggestions on approach, or am I missing something?

I think the best is to shorten table types to:

map -> m
multimap -> mm
timeseries -> ts
multitimeseries -> mts

The could be left out entirely, but I am afraid that there will be recipes with same partition keys/clustering columns combination with different characteristics.

I ran into this too last week. I thought we agreed to truncate table names when they are too long?

Yeah this would be a breaking change. I'd also suggest removing the time bucket duration - is this necessary? Separately it would be nice to be able to specify a manual name, which would also allow easier migration - I added temporary methods to override the automatic naming here

@mattheath I was trying to follow a rule which says 'no two tables with different settings should have the same name'. This is because I want to use the same table name for different query patterns - it is easy to see how "transactions_multimap_sellerid_saleid" and "transactions_multimap_customerid_saleid" refers to the same table ("transactions"), but with different ways of accessing it.
This not only makes for a warm feeling in my tummy but also allows us to add a feature later which can maintain data across tables with the same (high level, not internal) name. I did not explain this in the readme, I definitely should.

The only way we're really going to guarantee uniqueness within length constraints is to hash the names… but then we'll end up with gross table names :cry:

@obeattie We do guarantee uniqueness with the current design AFAIK, but it produces long names.

Yes, I mean that even by shortening the internal type names, it still doesn't guarantee it's short enough (given it's dependent on the user's column names). The only way to really do this within the length constraints, is to hash.

Fieldnames can be shortened with struct tags https://github.com/hailocab/gocassa/pull/75

An alternative solution is to let people name their tables however they want and have a manual way of marking tables as 'describing the same entity' in case someone wants the library to maintain data across tables.

Yeah i'd like to be able to do this. Some of our tables are exceptionally long!

Thoughts on changing the function signature for the table creators to be variadic with an optional TableOptions param?
eg.
type TableOptions struct{
	TableName string
	// ... other config options eg. high level name
}

func (k *k) TimeSeriesTable(name, timeField, idField string, bucketSize time.Duration, row interface{}, opts ...TableOptions) TimeSeriesTable {
	options := mergeTableOptions(opts...)

	// Construct a CQL table name if not provided
	if options.TableName == "" {
		options.TableName = fmt.Sprintf("%s_timeSeries_%s_%s_%s", name, timeField, idField, bucketSize.String())
	}

	// previous behaviour
	return &timeSeriesT{
		t: k.table(options.TableName, row, m, Keys{
		//...
	}
}

Opened a PR for the above (#82) with some sample code for discussion

This can be worked around with #85

:+1:

authors: crufter mattheath obeattie

repo: hailocab/gocassa

license: mit

license_source: bigquery


text:
Adding a blank custom query in general preferences stops the window from being closed

There is a small bug in the preferences window where adding an item with mandatory fields blocks the window from being closed unless those fields are then filled in.
Steps to reproduce:

Open the General section of preferences.
Click the + button under Custom Query Shortcuts.
Without filling in the form, move to another preferences section (e.g. Window).
Try to close the preferences window.

Actual Behaviour:
An Invalid shortcut error popup appears, even though returning to the General section shows that the previously added custom query form has been closed. The preferences window cannot now be closed without either resetting all off the section's options to default, or right-clicking the tray icon and restarting Hain.
Expected Behaviour:
Preferences window should close without any settings being changed.

Never mind, realised this a duplicate of #231.

repo: hainproject/hain


text:
Build breakage with osxcross

I built just fine using osxcross until two weeks ago - now I am getting this:
PATH=/home/rpolzer/src/osxcross-sdk/bin:/home/rpolzer/perl5/bin:/home/rpolzer/src/update-sway/out/bin:/home/rpolzer/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin CGO_ENABLED=1 CC=o64-clang CXX=o64-clang++ MACOSX_DEPLOYMENT_TARGET=10.13 go build -o packaging/AAAAXY.app/Contents/MacOS/aaaaxy-darwin-amd64 -tags=embed,ebitensinglethread -gcflags=all=-dwarf=false -ldflags=all=-s -ldflags=all=-w -a -trimpath -buildmode=pie
# github.com/hajimehoshi/ebiten/v2/internal/graphicsdriver/metal/mtl
Undefined symbols for architecture x86_64:
  "___isOSVersionAtLeast", referenced from:
      _Device_MakeLibrary in _x003.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

No idea yet why - right now looking what it takes to update osxcross.

FYI, using the 11.3 SDK.

Maybe https://github.com/hajimehoshi/ebiten/commit/7409f01b17b95abb17ea4b07f9099e81102aee32 ?

Yes, that is it:
int main() {
	if (@available(macOS 10.14, iOS 12.0, *)) {
		return 1;
	}
	return 0;
}

yields
~/src/osxcross-sdk-orig/bin/o64-clang -o foo foo.m
Undefined symbols for architecture x86_64:
  "___isOSVersionAtLeast", referenced from:
      _main in foo-1f6af0.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Filed https://github.com/tpoechtrager/osxcross/issues/346
This means I must now at least temporary make 10.14 a minimum requirement of my game. Kinda sad that this is just because of a compiler bug.

Oddly setting MACOSX_DEPLOYMENT_TARGET=10.14 works around the upstream build, but doesn't work with Ebiten. Wonder if anything overrides that.

From strace:
182159 execve("/home/rpolzer/src/osxcross-sdk/bin/o64-clang", ["/home/rpolzer/src/osxcross-sdk/bin/o64-clang", "-I", "/home/rpolzer/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.3.2/internal/graphicsdriver/metal/mtl", "-fPIC", "-arch", "x86_64", "-m64", "-pthread", "-fno-caret-diagnostics", "-Qunused-arguments", "-fmessage-length=0", "-fdebug-prefix-map=/tmp/go-build3962898579/b117=/tmp/go-build", "-gno-record-gcc-switches", "-fno-common", "-I", "/tmp/go-build3962898579/b117/", "-g", "-O2", "-mmacosx-version-min=10.12", "-fdebug-prefix-map=/home/rpolzer/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.3.2=/_/github.com/hajimehoshi/ebiten/v2@v2.3.2", "-o", "/tmp/go-build3962898579/b117/_x003.o", "-c", "mtl_darwin.m"], 0xc000776dc0 /* 83 vars */) = 0

So it looks like something's overriding my flags to 10.12.0.

internal/graphicsdriver/metal/mtl/mtl_darwin.go:// #cgo !ios CFLAGS: -mmacosx-version-min=10.12

WHY, JUST, WHY... this breaks my environment variable overrides :(
Looks like I need to go back to patching Ebiten... :(

Hm... there doesn't seem to be a great way to fix this. Can you maybe add a build tag condition to these lines that is something like !ebitennomacosxversionmin that allows me to provide my own?

Hm... there doesn't seem to be a great way to fix this. Can you maybe add a build tag condition to these lines that is something like !ebitennomacosxversionmin that allows me to provide my own?

My understanding is that macOS 10.14 is the must due to the version of Metal. Do you really want to specify -mmacosx-version-min=10.12?

I don't want to specify 10.12 anywhere - you are doing that.
$ git grep macosx-version-min
internal/graphicsdriver/metal/ca/ca_darwin.go:// #cgo !ios CFLAGS: -mmacosx-version-min=10.12
internal/graphicsdriver/metal/graphics_darwin.go:// #cgo !ios CFLAGS: -mmacosx-version-min=10.12
internal/graphicsdriver/metal/mtl/mtl_darwin.go:// #cgo !ios CFLAGS: -mmacosx-version-min=10.12
internal/graphicsdriver/metal/ns/ns_darwin.go:// #cgo !ios CFLAGS: -mmacosx-version-min=10.12

Ah I see. I'll try to fix

FYI after this change you no longer need @available in the first place.

So was this issue fixed? I think the error message says ___isOSVersionAtLeast so there is still an issue, but I am not sure

Specifying the min version as 10.14 "fixes" the issue by simply no longer using the ___isOSVersionAtLeast symbol.
So the toolchain bug remains, but it's no longer being triggered.

OK, there seems nothing I can do more for this issue. Let me close this.

authors: divVerent hajimehoshi

repo: hajimehoshi/ebiten


text:
Crashing after updating to Ebitengine v2.3.x (but work using v.2.2.x)

I tried to update my project to use the newest 2.3.x version of Ebiten, however I am getting the following error which crashes out before it can fully load the window, when trying to run on Windows 10:
directx: ID3D12Device::CreateCommittedResource failed: The parameter is incorrect.
The weird thing is that the new version works against the older code in the main branch, but I've got a lot of new features I've been working in a feature branch off to the side where it is failing only with the newer versions (raycast_collision).
Reproduce steps:

Clone and checkout raycast_collision branch
https://github.com/harbdog/raycaster-go/tree/raycast_collision
Download modules: go mod download
Run to verify works against previous version of Ebiten: go run raycast.go
Exit the game by holding CTRL key to unlock mouse from window to close it.
Update Ebiten: go get github.com/hajimehoshi/ebiten/v2@v2.3.2
Run again to see error: go run raycast.go

Thanks. Could you tell me your graphics card?

And, what about other Ebitengine applications (e.g. Ebitengine examples?)

I couldn't reproduce the issue on Parallels so far.

The weird thing is that the new version works against the older code in the main branch

So your main branch works with v2.3.2, but your raycast_collision branch does not, right? Would it be possible to detect which commit was culprit by git bisect?

Graphics card is Geforce RTX 3080 on latest drivers, I'll give it a try in the examples and then after that start going through git commits to help narrow down

As expected no issues with the ebitengine examples

Ok so git bisect narrowed down the first bad to this commit:
https://github.com/harbdog/raycaster-go/commit/6e4aa60fd9328d1ff1c6e39c968829035c2ec6d2

I got ebitengine to not crash by reducing that large sprite sheet size to half (9600x150).
However, a couple new behaviors I noticed with the newer version v2.3.2 (over previous v2.2.7) is that the first several seconds of rendering the game there is a huge hit in FPS/TPS before it smooths out. This video shows what is being experienced:
https://www.youtube.com/watch?v=OB4NICQl37Y
Additionally when I left click to trigger the "projectile" to fire, which is the sprite that comes from the very large sheet in question, it causes massive slowdown until it finally is removed. So it sounds like some regression in handling sub images of very large sprites possibly?

The main difference I can tell as far as ebitengine is concerned was the addition of an extremely large sprite sheet (2.2MB, 19200x300), which I was planning to optimize by making it smaller anyway so will give that a try.

Yeah, I think that's the cause. What was the exact error message by the way? Is the error message still only directx: ID3D12Device::CreateCommittedResource failed: The parameter is incorrect.? If so, I'd have to make the message more user-friendly...

Additionally when I left click to trigger the "projectile" to fire, which is the sprite that comes from the very large sheet in question, it causes massive slowdown until it finally is removed.

My guess is that separating the images increased the number of draw calls. You can confirm this with -tags=ebitendebug.
Do you really need whole the image at one time? Would it be possible to edit your sprite sheet so that only necessary part are on one sheet?

The main difference I can tell as far as ebitengine is concerned was the addition of an extremely large sprite sheet (2.2MB, 19200x300), which I was planning to optimize by making it smaller anyway so will give that a try.

Yeah, I think that's the cause. What was the exact error message by the way? Is the error message still only directx: ID3D12Device::CreateCommittedResource failed: The parameter is incorrect.? If so, I'd have to make the message more user-friendly...

yes that's the only error I got

Additionally when I left click to trigger the "projectile" to fire, which is the sprite that comes from the very large sheet in question, it causes massive slowdown until it finally is removed.

My guess is that separating the images increased the number of draw calls. You can confirm this with -tags=ebitendebug.
Do you really need whole the image at one time? Would it be possible to edit your sprite sheet so that only necessary part are on one sheet?

I could (and should anyway) optimize the sprite used as a projectile, it's only that big because that's the exact size it was from the resource I obtained it from (opengameart.org). But it's in a sheet because it's an animated sprite with multiple frames.
When the animated sprite is loaded from a sheet I pre-generate each frame using subImage and store each in an index array for looping the animation.
https://github.com/harbdog/raycaster-go/blob/raycast_collision/engine/model/sprite.go#L230

Similar performance issues are experienced even after cropping the 19200x300 image (48 frames) down to 1200x150 (only 6 frames). Would you like a separate issue for the performance problems aside from the original crash bug?

Yes, thanks!

My guess is that separating the images increased the number of draw calls. You can confirm this with -tags=ebitendebug.

So have you executed your game with this build tag?

Here's the log from the crash scenario with ebitendebug build flag:
crash_ebitendebug_2.3.2.log

Thanks!

crash_ebitendebug_2.3.2.log

Hmm? Were you trying to create a big image (19200px)? This log doesn't say so.

OK so my current guess is that too many (about 279!) internal textures were created. This is unusual. I'll take a look at your program later.

In your program, you create many new images and call DrawImage on that. Do you really need to create a new image for each Sprite? (e.g. https://github.com/harbdog/raycaster-go/blob/526d9c27d46bcb81fa40f35efbae70b7b8a68781/engine/raycaster/Sprite.go#L36-L37)? Would it be possible to use the given image without creating a new image?

Opened #2112 for the performance issues so we can continue the discussion over there on that aspect

Thanks!

Setting the environment variable to force opengl resolves crashing issue as well, so crash appears specific to directx on windows
set EBITEN_GRAPHICS_LIBRARY=opengl
raycaster-go.exe

Could you try the latest Ebitengine? The situation might be changed.

@hajimehoshi still getting the same crash with directx even on ebitengine v2.3.5, still works just fine when forcing opengl mode with EBITEN_GRAPHICS_LIBRARY=opengl
The original branch I reported on from my project no longer exists, so I'll update the reproduce steps accordingly from the specific commit SHA it is reproducible with when using that large image sheet.

Thanks.
So probably this is a restriction in the number and size of Direct textures, and there might be nothing we can do... 🤔

I also tried updating to main branch, it gives a bit more in terms of errors in case it helps:
go get github.com/hajimehoshi/ebiten/v2@main

go run raycast.go
...
panic: atlas: the image being put on an atlas is too big: width: 19200, height: 300

goroutine 885 [running]:
github.com/hajimehoshi/ebiten/v2/internal/atlas.(*Image).allocate(0xc005732ec0, 0x1)
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/atlas/image.go:750 +0x2a5
github.com/hajimehoshi/ebiten/v2/internal/atlas.(*Image).replacePixels(0xc005732ec0, {0xc003fdc000, 0x15f9000, 0x15f9000}, {0x0, 0x0, 0x0})
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/atlas/image.go:517 +0xc7
github.com/hajimehoshi/ebiten/v2/internal/atlas.(*Image).ReplacePixels(0x100000000000000, {0xc003fdc000, 0x30, 0x40}, {0x0, 0x40, 0xc00059ac00})
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/atlas/image.go:503 +0xfc
github.com/hajimehoshi/ebiten/v2/internal/buffered.(*Image).ReplacePixels(0x4f6780, {0xc003fdc000, 0x4b00, 0x12c}, 0xc0000b9d48, 0x4f6c25, 0xc00006ca50, 0x0)
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/buffered/image.go:148 +0x22a
github.com/hajimehoshi/ebiten/v2/internal/buffered.(*Image).ReplacePixels.func1()
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/buffered/image.go:140 +0x39
github.com/hajimehoshi/ebiten/v2/internal/buffered.tryAddDelayedCommand.func1()
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/buffered/command.go:76 +0x1b
github.com/hajimehoshi/ebiten/v2/internal/buffered.flushDelayedCommands()
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/buffered/command.go:35 +0x44
github.com/hajimehoshi/ebiten/v2/internal/buffered.BeginFrame({0x696ff8, 0xc000120f00})
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/buffered/image.go:41 +0x39
github.com/hajimehoshi/ebiten/v2/internal/ui.(*context).updateFrameImpl(0xc005732000, {0x696ff8, 0xc000120f00}, 0x1, 0x4090000000000000, 0x4088000000000000, 0xc000e3fe90)
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/ui/context.go:96 +0xcb
github.com/hajimehoshi/ebiten/v2/internal/ui.(*context).updateFrame(0xc00572e048, {0x696ff8, 0xc000120f00}, 0xc0003d20c0, 0xc0057340b8, 0xc0001b1860)
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/ui/context.go:65 +0x8e
github.com/hajimehoshi/ebiten/v2/internal/ui.(*userInterfaceImpl).loop(0x871640)
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/ui/ui_glfw.go:1116 +0x23c
github.com/hajimehoshi/ebiten/v2/internal/ui.(*userInterfaceImpl).Run.func1()
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/ui/run_notsinglethread.go:46 +0x13d
created by github.com/hajimehoshi/ebiten/v2/internal/ui.(*userInterfaceImpl).Run
        C:/Users/harbd/go/pkg/mod/github.com/hajimehoshi/ebiten/v2@v2.4.0-alpha.7.0.20220624164240-0eb2f7642274/internal/ui/run_notsinglethread.go:33 +0x1fd
exit status 2

Yeah, I guess that the image size exceeded the maximum of the texture size.

Understood, might be a good idea to add something in the doc about the directx specific limitation, but I'll go ahead and close this since there appears to be nothing you can do.

In general, 19200px width image is too big, whichever you use DirectX or not. If you create one texture atlas, I recommend extending the heights more instead of the width to make the imager closer to a square.

authors: hajimehoshi harbdog


text:
chore(main): release 0.14.8

:robot: I have created a release beep boop
0.14.8 (2024-02-28)
Bug Fixes

SearchBar: search bar doesn't recognize the hashtag character (#321) (d543942)
TopBar: center the right side items (f654392)
TopBar: search bar cannot be centered in the top bar (becdcc4)
ts error (e3de0b0)
VideoCard: bug fixes (#316) (1790d3a)
VideoCard: bug fixes (#316) (#318) (562c766)
VideoCard: ensure clicking on bangumi name or avatar goes to the right page (7adb17c)
VideoCard: fix double page open on author's name click (#315) (e185098)
搜索框用中文输入法输入单词回车不应该直接触发搜索 #334 (18e6689)

Style Changes

TopBar: adjust style (5af83fa)

CI

changelog: update ci (f8f2776)
release: trigger workflow only on push to main branch (8d6d179)
release: update ci (edd243c)
release: update ci (28bd6a1)
release: update ci (e847901)

Miscellaneous

chore:  (a50e617)
chore:  (0700b27)
chore:  (88d879d)
update ci (cdf5889)
update version number (f9499be)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/hakadao/BewlyBewly/releases/tag/v0.14.8 :sunflower:

source: gharchive/pull-request

repo: hakadao/BewlyBewly


text:
Implement settings

Implement the settings dialog in the footer.

No part of #59


text:
Ghost 3.0 下，文章详情页面，点了搜索按钮以后，底部文章和头图会“跳”动一下

原因是点击了搜索页面以后，会把 body 加上一个 postion:fixed 的 style。这个 style 会影响底部的布局。但是加上这个 style 是为了兼容点击搜索按钮以后，弹出的遮罩层屏蔽底层滚动。

在头部 HOME、ARCHIVES、LINKS、CONTACT 标签页面，点击搜索按钮，底部文章和头图都会跳动一下。原因如上，和加入了 postion:fixed 的 style 有关。

如果不加入 postion:fixed，会导致 Safari 上出现问题。即 #32 的问题。

在 pr #34 中彻底解决了这个问题~

repo: halfrost/Yasuko


text:
build/run are restarted endlessly

When I create a component (without pushing the code), the run script is already started. It obviously can't succeed, but it keeps being restarted endlessly. I don't think run should be started automatically at the very beginning.
When I push a source code with a syntax error, same happens with the build script: it can't succeed, but it keeps being restarted endlessly. I think that if the build script fails, it usually doesn't make sense to restart it; instead, build failure should be reported to the user.
I don't quite understand why the supervisord-based architecture was chosen, but when hal is used (and IMHO Halkyon without hal doesn't make sense), the lifecycle can be controlled by hal and supervisord becomes a rather useless nuisance.

The reason why things are restarted all the time is so we don't need to do so from a client. The operator should take care of starting the app if/when it's ready. It could certainly be done in a more subtle way but this hasn't been high up on the list of priorities. Restarting the process until it works has been the easiest way to get the functionality we need so far… 😄
More specifically, we do need a way to auto-start apps without client intervention for several reasons: first, I believe most of the logic should be put in the operator and not shelled out to clients and I believe it's up to the operator to take care of the app lifecycle and second, we need to auto-restart apps after a link has been created resulting in the application's pod being destroyed and re-created with new environment variables. Without this auto-restart, this would mean a previously running app would need to be started again via user action, which would be sub-par UX, imo.

authors: Ladicek metacosm

repo: halkyonio/operator


text:
Mathchups Global and top 1000 are identical

The Top 1000 section of the matchups template is updating its contents from matchups_global rather than matchups_top_1000

Any update on this? The gap between global and top 100 would be nice to have a midpoint for.

authors: Procdox Skwuruhl

repo: halvnykterist/rating-update


text:
⚠ ClamAV has degraded performance

In 918ce5b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 77 ms

Resolved: ClamAV performance has improved in 6451907.

repo: hamboneZA/caffeine


text:
Database

Cleans up the interface to DB - now you just do an "adduser" as a dict with each key representing column name and value representing the corresponding data for that column.

This change is

Thanks!

repo: hamir/islam-buddy


text:
Make item drops configurable

Configuration options to add:

Whether blocks spawn item drops when first chopped
Whether the original block's item drops should only spawn when the chopped block is destroyed
Whether chopped logs spawn item drops when chopped
Whether chopped logs spawn item drops when destroyed

In all cases, item drops will be determined by loot tables.
Things this would enable:

Chopping could produce wood chips items instead of log items
Dropping a log item on first chop is a little awkward; it might be preferable to drop it when the chopped block is destroyed

Wait, the logs dropping from the first chop is intended?
I honestly thought that was a bug and was just coming to report it.
That definitely needs to be changed, it feels wrong on so many levels to tap a log with an axe and get it while the block is still technically there, just changed.

I agree, it's disturbing! However, right now the chopped blocks have no memory of what kind of block they used to be (this is why a weird generic texture is used), so there's no reliable way to say what items they should drop. Making this possible is a big priority. The main reason I'd add the option "Whether blocks spawn item drops when first chopped" is to preserve original mod behavior.

Ohhhh I see! Also, on the topic of the generic texture, I'm not sure if it's possible, but once the block can remember what it was, it would make a lot of sense to use the Stripped variant of whatever wood you're cutting (or a fallback texture if a stripped variant can't be located)

authors: IdrisQe hammertater

repo: hammertater/treechop


text:
minor wording change in documentation

besides this being clearer, I believe the previous wording was not grammatically correct.

Ah, I suppose so. Too bad this came too late for the previous merge, but I know how that goes sometimes.

No problem, I did give my approval to the other PR, so I take responsibility for the overlook.

authors: Xymph waldyrious

repo: hamstar/Wikimate


text:
Update scalafmt-core to 3.4.3

Updates org.scalameta:scalafmt-core from 3.1.2 to 3.4.3.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta", artifactId = "scalafmt-core" } ]

labels: library-update, early-semver-minor, semver-spec-minor, commit-count:1

Closed by #106

repo: hanabix/passport


text:
memory

Hi.
I am trying to split a big (5Gb) parquet file into small ones using "--skip" and "--limit"
Skip 5 million and write 6-th, skip 6 million and write 7-th.
However during skipping "parquet-tools cat" start consuming all my memory, reaching 128Gb it goes to swap and eventually killed.
Can you check the memory usage during "--skip"
Ramil
.

yeah it seems an issue from parquet-go that use excessive memory with skip, I need some time to troubleshoot the issue.
FYI -limit is not an issue, it's problem from --skip

Filed ticket to parquet-go https://github.com/xitongsys/parquet-go/issues/545

try v1.19.5, it has a hardcoded page size for SkipRows, I will come up with a cli parameter to make this configurable (https://github.com/hangxie/parquet-tools/issues/221)

authors: RamilNurtdinov hangxie

repo: hangxie/parquet-tools


text:
Questions on the attention mask, and whether to accept the last element of guess_results when all guess_tokens are accepted

It was mentioned in https://github.com/hao-ai-lab/LookaheadDecoding/issues/14 that yellow 7 can see orange1-4, green 5 and red 6. However, as I have thought it was orange 4, green 5, red 6 and yellow 7 that form a 4-gram, and orange 1-3 is irrelevant here so they should be masked, or am I misunderstanding something?
On a different question, if all guess_tokens matches guess_results[0:-1], then should the Lookahead step also accept the last element guess_results[-1]? (since this is a complete sentence)
Many thanks for the help

it was orange 4, green 5, red 6 and yellow 7 that form a 4-gram,

yes, but orange 1-3 is another 3-gram before this 4-gram, so they should also be taken by yellow7 so that yellow7 attends to a complete sentence.

should the Lookahead step also accept the last element guess_results[-1]?

I think this possibly works as well. But conceptually, the guess_results are just used to verify the guess_tokens. The tokens to be accepted should be chosen from "verified guess tokens", not the "tokens used for verification"

yes, but orange 1-3 is another 3-gram before this 4-gram, so they should also be taken by yellow7 so that yellow7 attends to a complete sentence.

But I do not see how orange 1-4 should have any connections at all. They are part of different 4-grams, and orange 1-3 is not a 3-gram at all if I am not mistaken.

N-gram are those across the different colours

I speculate that since the author assign each token with a specific number in blog figure 5, that number stands for the token's "expected position index" within the context

I see tokens in orange 1-4 do not form a coherent phrase

I see that as the decoding process goes on, orange 1-4 gradually form a coherent phrase, for example when steps=15:

Thank you very much for the response.
I still have trouble understand why orange 1-4 should have connections. I guess this is because we use causal mask in the first context decoding step (where a conventional triangular mask is used so that orange tokens can see their preceding tokens), is this the reason?
If so, why not do the same for green 1-5 and red 1-5 so that they can also see their preceding tokens (so six lower triangles in mask as opposed to the current three under the orange tokens)?

orange 1-4 are "guessed" to be 4-grams, but the "collected 4-gram" are indeed generated in an autoregressive pattern. And if you

do the same for green 1-5 and red 1-5

they would be no autoregressive pattern within the whole decoding process, and the probability of "n-gram-guess-is-right" might decrease. (ps. just a personal guess here:-))
Besides, there should not be six lower triangles in masks. For example, green 5 can not attend to orange 1-4 and green 1-4 at the same time.

I think I can slowly grasp what is happening here now. We need that blue 0 and orange 1-4 to build connections so that their corresponding 4 grams (five collected 4-grams in this case) are all relevant to the prompt context. Otherwise, some of the 4-grams are useless as they almost have no connections to the prompt context (even though there coherent 4-grams), so this can lead to better acceptance rate.
I guess this is the reason why we want the blue 0 and orange 1-4 to form a sentence :)

repo: hao-ai-lab/LookaheadDecoding


text:
ValueError: Unicode strings with encoding declaration are not supported.

When using this commit and all subsequent commits, I encounter the following error while loading URDF files:
File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/envs/sapien_env.py", line 318, in __init__
    obs, _ = self.reset(seed=2022, options=dict(reconfigure=True))
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/envs/sapien_env.py", line 728, in reset
    self._reconfigure(options)
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/envs/sapien_env.py", line 587, in _reconfigure
    self._load_agent(options)
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/envs/sapien_env.py", line 370, in _load_agent
    agent: BaseAgent = agent_cls(
  File "/home/sichengh/24summer/MultiGraspDex/multi_grasp_dex/robots/xarm6_allegro_left.py", line 88, in __init__
    super().__init__(scene, control_freq, control_mode, agent_idx)
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/agents/base_agent.py", line 101, in __init__
    self.set_control_mode()
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/agents/base_agent.py", line 220, in set_control_mode
    self.controllers[control_mode] = CombinedController(
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/agents/controllers/base_controller.py", line 202, in __init__
    self.controllers[uid] = config.controller_cls(
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/agents/controllers/base_controller.py", line 64, in __init__
    self._initialize_joints()
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/agents/controllers/pd_ee_pose.py", line 45, in _initialize_joints
    self.kinematics = Kinematics(
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/agents/controllers/utils/kinematics.py", line 50, in __init__
    self._setup_gpu()
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/mani_skill/agents/controllers/utils/kinematics.py", line 82, in _setup_gpu
    self.pk_chain = pk.build_serial_chain_from_urdf(
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/pytorch_kinematics/urdf.py", line 135, in build_serial_chain_from_urdf
    urdf_chain = build_chain_from_urdf(data)
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/pytorch_kinematics/urdf.py", line 94, in build_chain_from_urdf
    robot = URDF.from_xml_string(data)
  File "/home/sichengh/anaconda3/envs/dex/lib/python3.9/site-packages/pytorch_kinematics/urdf_parser_py/xml_reflection/core.py", line 615, in from_xml_string
    node = etree.fromstring(xml_string)
  File "src/lxml/etree.pyx", line 3307, in lxml.etree.fromstring
  File "src/lxml/parser.pxi", line 1984, in lxml.etree._parseMemoryDocument
ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.

The URDF file in question is the same as referenced in this issue. When I switch to this commit, the issue does not occur, and ManiSkill loads the URDF file correctly.
I noticed that the latest commits include updates to the inverse kinematics in the controller. However, this error is preventing me from using the latest code. Could you please look into this issue? Thank you!

A fix for this now is to replace the top line in your URDF that says <?xml version="1.0" encoding="utf-8"?>  with <?xml version="1.0" ?> and remove the encoding attribute

repo: haosulab/ManiSkill


text:
Make inline resource storage use a better column type

The inline resource storage type should use a longvarchar (ie text on postgres, varchar(max) on mssql, long on oracle, etc)

Hello, I have a question about the mapping
//hapi-fhir-sql-migrate/src/main/java/ca/uhn/fhir/jpa/migrate/taskdef/ColumnTypeToDriverTypeToSqlType.java
		setColumnType(ColumnTypeEnum.TEXT, DriverTypeEnum.ORACLE_12C, "long");

The LONG datatype is deprecated by Oracle since LOB datatypes made their appearance, and Oracle suggests using CLOBs instead lf LONGs and BLOBs instead of LONG RAWs (because LONGs have many limitations, the most dangerous and bug-prone of which is that you can have only one LONG column for each table, while you can have as many LOBs as you want).
What is the reasoning behind using the LONG datatype instead? Is there a discussion about this somewhere? I only recently took interest in the hapi-fhir project, so I apologize for asking maybe obvious questions.
Thank you.

authors: jamesagnew stmsat

repo: hapifhir/hapi-fhir


text:
Satsuki in prefix

Satsuki is now stored in the prefix, removing the need to manually install it.

Tested on Linux and working as expected.

authors: marysaka roblabla


text:
你论文里的argoverse实验数据写错了

应该是trailer是30+的iou，你写到BUS上了

没问题吧？

repo: happytianhao/TaDe


text:
Failed downloading: Download with retry

When trying to download from a single creator, I'm seeing the following:

Is there any way to add a skip or something, that will continue the download and skip the current post if there's an error as shown above? Thanks.

https://github.com/hareku/fanbox-dl/releases/tag/v0.24.0 provides skip-on-error flag.

authors: VamsiKrishnaThigulla hareku

repo: hareku/fanbox-dl


text:
is it normal to see "WARN  Lighthouse failed to run performance audits for "/business", adding back to queue."

Details
I have set a fixed list of urls in my config, and I often get this warning, for all the urls provided
 WARN  Lighthouse failed to run performance audits for "/business", adding back to queue.
I was using Puppeteer to authenticate the app, and just a single worker, and often I see the LH fail and then requeue, about 3/4 times before a result is available, it takes quite some time. I thought this was odd, so I tried the same against some bbc.com pages and found I got the same (without the Puppeteer hook).
Is this normal?

Hi @Dale-777, thanks for the issue.
The logic for a route to be requeued relates to the Lighthouse report not having any performance data. I noticed when updating Lighthouse to the latest version that the results were a lot more flaky.
I don't really have a solution besides the requeuing as it seems to be an upstream issue with Lighthouse, I can only hope they will fix it on their end in an upcoming release.

@harlan-zw might you know the last stable version of lighthouse that worked for you without flake? I will roll back to that and retry (this is my first try with unlighthouse, thanks for the awesome work).

Before 0.11.0 should be more stable

repo: harlan-zw/unlighthouse


text:
Doc review chaos 3443

Doc review for CHAOS 3443

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://659e3a4c89a086ad54d9aafe--harness-developer.netlify.app

authors: SmritiSatya bot-gitexp-user

repo: harness/developer-hub


text:
move repolisting from fixed issues to new features and enhancements

Thanks for contributing to the Harness Developer Hub! Our code owners will review your submission.
Description

Please describe your changes: __________________________________
Jira/GitHub Issue numbers (if any): ______________________________
Preview links/images (Internal contributors only): __________________

PR lifecycle
We aim to merge PRs within one week or less, but delays happen sometimes.
If your PR is open longer than two weeks without any human activity, please tag a code owner in a comment.
PRs must meet these requirements to be merged:

[ ] Successful preview build.
[ ] Code owner review.
[ ] No merge conflicts.
[ ] Release notes/new features docs: Feature/version released to at least one prod environment.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


text:
gitlab.nvim: Failed to parse JSON from /users/me endpoint, got: '404 page not found'

Prerequsities

[x] The "Troubleshooting" section of the README did not help ( i didnt found a Troubleshooting section in the README)
[x] I've installed the required dependencies
[x] I'm on the latest version of the plugin

Bug Description
So im using a self hosted instance of gitlab and the /users/me doenst exists. But i know my user ID. Can i curcumvent and just hardcode somewhere my userID instead of sending that request?
Reproduction Steps

Check out the feature branch
Open Neovim
:lua require("gitlab").review()
get gitlab.nvim: Failed to parse JSON from /users/me endpoint, got: '404 page not found'

Hey @Otterpatsch,
Thanks for using this plugin. The 404 from the users/me endpoint indicates that you do not have the latest Go binary installed and running; I don't think this has anything to do with you using a self-hosted Gitlab instance. The 404 response is coming from the Go server. I'd try the following first and let me know if this solves things:

Recompile the Go binary: :lua require("gitlab.server").build(true)
Quit all your running Neovim instances
Reopen Neovim and run the review command.

Secondly, the Go binary should be re-compiled whenever you update the plugin. It's possible you're missing this required line from your plugin configuration (with Lazy):
build = function () require("gitlab.server").build(true) end, -- with lazy...
-- or with packer...
run = function() require("gitlab.server").build(true) end,

Finally, I'll make sure to update the Go server to respond to 404s with more helpful error messages, and I'll update the issue template to ask people to check :h gitlab.nvim.troubleshooting in the future, since the Readme has been modified since this template was first created.
Does this help?

It seems i had to also kick of a Update/Refresh via Lazy to rerun the build. NOw everthing works like a charm again

authors: Otterpatsch harrisoncramer


text:
Title: HelperBird chrome extension enhancement [UI]

Which pre-existing extension will you be working on?
A Full set of tools for Chrome Extension to be implemented. This includes a lot of features such as Dyslexia Mode, Full Immersive Reader, Text to Speech, Voice Typing, Word Prediction, Screenshot, Color Blindness, Reading List, Bookmarks
Describe your enhancement/improvement
Need a new UI with more clear icon design and better UI interaction
Add any other context or screenshots about the enhancement here.
No response

I want to work under this issue under JWOC


text:
[BUG] Potential bugs on vm-dhcp-controller

Describe the bug

Potential bugs on vm-dhcp-controller, please double check and optimze in future releases.

The EventListener blocks on select {}, but (c *Controller) Run may fail when  !cache.WaitForCacheSync(stopCh, c.informer.HasSynced); if it happens, it blocks

The context in (a *Agent) Run(), is not passed to later procssing, the program can only be terminated forcely without early termination.

func (e *EventHandler) EventListener() (err error) {
...
	controller := NewController(queue, indexer, informer, e.poolRef, e.dhcpAllocator, e.poolCache)
	stop := make(chan struct{})
	defer close(stop)
	go controller.Run(1, stop)

	select {}
}

func (c *Controller) Run(workers int, stopCh chan struct{}) {
	defer runtime.HandleCrash()

	defer c.queue.ShutDown()
	logrus.Infof("(ippool.Run) starting IPPool controller")

	go c.informer.Run(stopCh)
	if !cache.WaitForCacheSync(stopCh, c.informer.HasSynced) {
		logrus.Errorf("(ippool.Run) timed out waiting for caches to sync")

		return
	}

	for i := 0; i < workers; i++ {
		go wait.Until(c.runWorker, time.Second, stopCh)
	}

	<-stopCh
	logrus.Infof("(ippool.Run) stopping IPPool controller")
}

func (a *Agent) Run() error {
	logrus.Infof("monitor ippool %s", a.poolRef.String())

	eg, egctx := errgroup.WithContext(a.ctx)

..
	eg.Go(func() error {
		select {
		case <-egctx.Done():
			return nil
		default:
			// initialize the ippoolEventListener handler
			if err := a.ippoolEventHandler.Init(); err != nil {
				logrus.Fatal(err)
			}
			return a.ippoolEventHandler.EventListener()
		}
	})

	if err := eg.Wait(); err != nil {
		logrus.Fatal(err)
	}

	return nil
}

The name := fmt.Sprintf("%s-%s-agent", ipPool.Namespace, ipPool.Name) may over 63 chars. (discussed before)

The ippool-register will try to create a POD at any change of the ip-pool status, should status.AgentPodRef be helpful to check if the POD exists first, avoid un-necessary API call to create and get an IsAlreadyExists error.

If the agent POD's namespace & name may change (not confirmed), then the status.AgentPodRef can also be used to delete previous POD and re-create the new one.
	ctlnetworkv1.RegisterIPPoolStatusHandler(
		ctx,
		ippools,
		networkv1.Registered,
		"ippool-register",
		handler.DeployAgent,
	)

func (h *Handler) DeployAgent(ipPool *networkv1.IPPool, status networkv1.IPPoolStatus) (networkv1.IPPoolStatus, error) {
	agent := prepareAgentPod(ipPool, h.noDHCP, h.agentNamespace, clusterNetwork, h.agentServiceAccountName, h.agentImage)

	agentPod, err := h.podClient.Create(agent)
	if err != nil {
		if apierrors.IsAlreadyExists(err) {
			return status, nil
		}

	status.AgentPodRef = &networkv1.PodReference{
		Namespace: agentPod.Namespace,
		Name:      agentPod.Name,
	}

The sequence question: the BuildCache and Allocate are running in parallel, and they are not using a high level control like networkv1.CacheReady

func (h *Handler) BuildCache(ipPool *networkv1.IPPool, status networkv1.IPPoolStatus) (networkv1.IPPoolStatus, error) {
...
h.cacheAllocator.AddMAC(ipPool.Spec.NetworkName, mac, ip)
...

func (h *Handler) Allocate(vmNetCfg *networkv1.VirtualMachineNetworkConfig, status networkv1.VirtualMachineNetworkConfigStatus) (networkv1.VirtualMachineNetworkConfigStatus, error) {
...
exists, err := h.cacheAllocator.HasMAC(nc.NetworkName, nc.MACAddress)
...
		// Recover IP from status (resume from paused state)
		if oIP, err := findIPAddressFromNetworkConfigStatusByMACAddress(vmNetCfg.Status.NetworkConfig, nc.MACAddress); err == nil {
			dIP = oIP
		}

		ip, err := h.ipAllocator.AllocateIP(nc.NetworkName, dIP)
		if err != nil {
			return status, err
		}

		if err := h.cacheAllocator.AddMAC(nc.NetworkName, nc.MACAddress, ip); err != nil {
			return status, err
		}
...

To Reproduce
Steps to reproduce the behavior:

Go to '...'

Expected behavior

Support bundle

Environment

Harvester ISO version:  v1.3.0 master-head
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630):

Additional context
Add any other context about the problem here.
Observed when reviewing PR: https://github.com/harvester/harvester/pull/4960

Validation Issue:
@starbops
From, https://github.com/harvester/vm-dhcp-controller/pull/19#issue-2114780175 , for:

╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065/vm-dhcp-controller on main✔
╰─± kubectl get network-attachment-definitions -A
NAMESPACE   NAME                                                              AGE
default     dhcp900                                                           3h22m
default     fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n   2m41s
default     test                                                              6d1h
default     test-net                                                          22h
default     vlan104                                                           3d21h
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065/vm-dhcp-controller on main✔
╰─± cat ../ippool.yaml
apiVersion: network.harvesterhci.io/v1alpha1
kind: IPPool
metadata:
  namespace: default
  name: fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n
spec:
  ipv4Config:
    serverIP: 192.168.30.200
    cidr: 192.168.30.1/24
    pool:
      start: 192.168.30.2
      end: 192.168.30.250
    router: 192.168.30.1
    leaseTime: 300
  networkName: default/fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065/vm-dhcp-controller on main✔
╰─± kubectl create -f ../ippool.yaml
The IPPool "fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n" is invalid:
* spec.networkName: Too long: may not be longer than 64
* <nil>: Invalid value: "null": some validation rules were not checked because the object was invalid; correct the existing errors to complete validation
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065/vm-dhcp-controller on main✔
╰─± kubectl describe network-attachment-definitions/fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n | yq
Error: bad file '-': yaml: line 7: mapping values are not allowed in this context
╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065/vm-dhcp-controller on main✔
╰─± kubectl get network-attachment-definitions/fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n -o yaml | yq
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
  annotations:
    network.harvesterhci.io/route: '{"mode":"auto","connectivity":"DHCP failed"}'
  creationTimestamp: "2024-03-05T23:05:06Z"
  finalizers:
    - wrangler.cattle.io/harvester-network-nad-controller
    - wrangler.cattle.io/harvester-network-manager-nad-controller
  generation: 1
  labels:
    network.harvesterhci.io/clusternetwork: cn-dhcptest
    network.harvesterhci.io/ready: "true"
    network.harvesterhci.io/type: L2VlanNetwork
    network.harvesterhci.io/vlan-id: "30"
  name: fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n
  namespace: default
  resourceVersion: "1672667"
  uid: 00d2713c-9fc0-48bc-8a0f-5c8630d0d418
spec:
  config: '{"cniVersion":"0.3.1","name":"fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n","type":"bridge","bridge":"cn-dhcptest-br","promiscMode":true,"vlan":30,"ipam":{}}'

It seems to not create even though the spec.networkName is valid via kubectl get network-attachment-definitions -A.

@starbops
Still noticing this as an issue on:

v1.3.0-rc4
0.3.0 chart version with v0.3.0 tags on the images

╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ kubectl create -f ippool.yaml
The IPPool "fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n" is invalid:
* spec.networkName: Too long: may not be longer than 64
* <nil>: Invalid value: "null": some validation rules were not checked because the object was invalid; correct the existing errors to complete validation

@starbops Still noticing this as an issue on:

v1.3.0-rc4
0.3.0 chart version with v0.3.0 tags on the images

╭─mike at suse-workstation-team-harvester in ~/Projects/test-5065
╰─○ kubectl create -f ippool.yaml
The IPPool "fi6cx9ca1kt1faq80k3ro9cowyumyjb67qdmg8fb9ydmz27rbk5btlg2m5avv3n" is invalid:
* spec.networkName: Too long: may not be longer than 64
* <nil>: Invalid value: "null": some validation rules were not checked because the object was invalid; correct the existing errors to complete validation

The bug fix harvester/vm-dhcp-controller#19 has been completely shadowed by the enhancement harvester/vm-dhcp-controller#18, so it becomes unnecessary to validate this one. I suggest we skip this one since #5065 has been closed. Now the .spec.networkName cannot longer than 64 characters.
Thanks!
cc @irishgordo

Sounds good @starbops  I'll go ahead and close this one out then :+1: :smile:

authors: irishgordo starbops w13915984028

repo: harvester/harvester


text:
[backport v1.0]  fix 2615, cease alert VirtOperatorDown

IMPORTANT: Please do not create a Pull Request without creating an issue first.
Problem:

[backport v1.0]
VirtOperatorDown alert comes up in Harvester v1.0 and master-head.
master-head PR: https://github.com/harvester/harvester/pull/2616
Solution:

Add proper label to let prometheus monitor the related POD and cease alert.
Related Issue:
https://github.com/harvester/harvester/issues/2615
Test plan:

Per issue.

keep v1.0 unchanged now. alertmanager is not released in v1.0.


text:
vote - time field with value of 00:00 should not be null

this vote's time is 00:00

http://www.knesset.gov.il/vote/heb/Vote_Res_Map.asp?vote_id_t=23567

but in dataservice, we get vote_time = null

http://online.knesset.gov.il/WsinternetSps/KnessetDataService/VotesData.svc/View_vote_rslts_hdr_Approved(23567)

looking at another vote on that day, you can see time of 00:01

http://online.knesset.gov.il/WsinternetSps/KnessetDataService/VotesData.svc/View_vote_rslts_hdr_Approved(23568)

the python dataservice library handles this internally at the Vote object, see https://github.com/hasadna/knesset-data/blob/master/python/knesset_data/dataservice/votes.py#L9

Record of email correspondence with Knesset:
Sent: Feb 7, 2016 | From: @OriHoch

התחלנו להשתמש בממשק הנתונים החדש, יש עם הממשק בעיות רבות שמקשות לעבוד איתו באופן שוטף, להלן כמה מהן:
(link to this issue)

Sent: Feb 8, 2016 | From: Deputy Director of the Information Departmnet (סגן מנהל חטיבת המידע)

אנחנו מטפלים ברשימת הבקשות (תקלות) שציינת.

Sent: Feb 14, 2016 | From: Deputy Director of the Information Departmnet (סגן מנהל חטיבת המידע)

תקלה אחזור נתוני הצבעות

            - תיאור התקלה:  Vote – time field with value of 00:00 should not be null

            - מצורפת דוגמה מתאריך 09/02/2016

            - במידה ועדיין נראה לכם שיש תקלה, בבקשה לצרף דוגמה לדרך שביקשתם את שליפת הנתונים

            - קישור:

http://online.knesset.gov.il/WsinternetSps/KnessetDataService/VotesData.svc/View_vote_rslts_hdr_Approved?$top=20&$orderby=knesset_num desc,vote_date desc

Sent: Feb 14, 2016 | From: @OriHoch

כל הפרטים נמצאים בקישורים ששלחתי
נראה שבתשובתכם התעלמתם לחלוטין מכל מה שכתוב בקישורים ששלחתי. אני יכול לחזור ולכתוב פה מה שכתוב שן אבל נראה לי קצת חסר טעם
בקישורים הנ"ל מופיעים כל הפרטים כולל כתובות מדויקות ותיאור של התקלות
אם עדיין לא ברור אשמח להוסיף מידע נוסף

Sent: Feb 14, 2016 | From: @OriHoch

רק שיהיה ברור - כל התקלות שתוארו במייל המקורי עדיין קיימות.

Knesset was notified today that we are still waiting for an answer
The following description was sent regarding this bug:
נתוני הצבעות מסויימות מראות שעה שגויה

Sent: Mar 6, 2016 | From: @OriHoch  To: Knesset Contact

יש הרבה באגים חמורים נוספים שעדיין לא החזרתם לנו תשובה לגביהם:

(link to this bug)

Issue moved to hasadna/knesset-data-python #7 via ZenHub

repo: hasadna/knesset-data


text:
Removing texts part6

Description
Removed from pointTypeToDescription - Notice - I did import { t } from 'i18next'. because I used it in an object, not react component.
DELETED texts.ts!

@amabelleS please consider this change https://github.com/hasadna/open-bus-map-search/pull/321

authors: NoamGaash amabelleS

repo: hasadna/open-bus-map-search


text:
プラグイン基底クラスの作成

inputs/outputs/scenes内の各ファイルのクラスでイベント時にon_*という同じメソッドを呼んでいるので、これらの基底となるクラスを作る

+1

新プラグインインターフェイスで実施

authors: hasegaw mzsm

repo: hasegaw/IkaLog


text:
Incompatible Geth error messages

Problem
We are encountering error codes which are different from what we expect in a Geth implementation. Please provide a mapping of Hedera error codes to those of Ethereum Geth.
Solution
Need your help to resolve the issue.
Alternatives
No response

you could use this in the meanwhile:
https://github.com/hashgraph/hedera-json-rpc-relay/blob/main/packages/relay/src/lib/errors/JsonRpcError.ts

Also, is it possible for you to provide the error docs with its descriptions for GETH to map against?

@AlfredoG87 : We rely on these error messages mapping to react to RPC errors & decide how the transactions should be handled. So if any of these error messages are different & not covered, we will need to add them, its mostly based on Geth error messages. It would be awesome, if you could provide a list of the differences

Thanks @simsonraj
Currently our custom error messages are as defined is the JsonRpcError.ts file AlfredoG87 mentioned above
Let us know if that covers all the possibilities as it provides the codes and error messages.

I'm also curious do you ever support non GEth execution clients?
Hedera uses the Besu EVM client and a custom relay. Even if we didn't have a custom relay the GETH errors would differ from other client errors.

We do support non-Geth clients, I took a look at the error messages, we can include these in our custom support, We may need some help in the future to Map 1:1 with the error categories we have with the error messages Relay returns. But I think it can be done

Hi @simsonraj, what kind of errors would you need to handle coming from Hedera relay? Because we were looking at the errors you are handling and some of them are mempool related which the relay does not throw. These errors are thrown by both Geth and Hedera

NonceTooLow
NonceTooHigh
InsufficientEth which might be INSUFFICIENT_ACCOUNT_BALANCE

Given said that, we agree, as you mention, it would be best to add a Hedera-specific regexes to detect the errors that come from the relay. We can help with further error mapping if needed.

Hi @simsonraj, closing this given there is not action item on the relay. Feel free to reopen if support from the relay side is needed.

repo: hashgraph/hedera-json-rpc-relay


text:
[Snyk] Upgrade @hashgraph/sdk from 2.38.0 to 2.39.0

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @hashgraph/sdk from 2.38.0 to 2.39.0.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released a month ago, on 2023-12-05.

The recommended version fixes:

Severity
Issue
PriorityScore (*)
Exploit Maturity

Cross-site Request Forgery (CSRF) SNYK-JS-AXIOS-6032459
462/1000  Why? Proof of Concept exploit, CVSS 7.1
Proof of Concept

Improper Input Validation SNYK-JS-FOLLOWREDIRECTS-6141137
462/1000  Why? Proof of Concept exploit, CVSS 7.1
Proof of Concept

Regular Expression Denial of Service (ReDoS) SNYK-JS-AXIOS-6124857
462/1000  Why? Proof of Concept exploit, CVSS 7.1
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Release notes

Package name: @hashgraph/sdk

2.39.0 - 2023-12-05What's Changed

Release new cryptography package version by @ ochikov in #2041
Release new proto package beta version by @ ochikov in #2040
New web proxy for nodeAccountId 3 by @ svetoslav-nikol0v in #2051
Update dependencies and apply new linter rules by @ ochikov in #2043

Full Changelog: v2.38.0...v2.39.0

2.38.0 - 2023-11-21

    from @hashgraph/sdk GitHub release notes

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (cae6daa) 77.83% compared to head (c344d89) 77.83%.

:exclamation: Current head c344d89 differs from pull request most recent head 6ea1381. Consider uploading reports for the commit 6ea1381 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2009   +/-   ##
=======================================
  Coverage   77.83%   77.83%
=======================================
  Files          40       40
  Lines        3086     3086
  Branches      625      625
=======================================
  Hits         2402     2402
  Misses        479      479
  Partials      205      205

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter swirlds-automation


text:
Add functionality to remove allowance for all serials in AccountAllowanceDeleteTX

Problem
Based on the ERC standard that the SDK follows, users can:

approve allowance for all serials of a given NFT collection, then remove allowance for all serials of the NFT collection
approve allowance for individual NFT serial, then remove allowance for individual NFT serial

The current implementation of the SDK does not allow users to remove allowance for all serials of an NFT collection. Thus, this has to be added
Some additional context
Solution
When the field approved_for_all inside the NftAllowance proto object is set to false  in CryptoApproveAllowanceTransactionBody (in SDKs case: AccountAllowanceApproveTransaction) we revoke the token for the spender for which we have previously allocated approve_for_all allowance. The SDK has to support this functionality which is explained in HIP-336
Alternatives
No response

Fixed by #1349

authors: dikel petreze

repo: hashgraph/hedera-sdk-java