profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/CoffeeFlux/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

CoffeeFlux/Aegisub 1

Cross-platform advanced subtitle editor

CoffeeFlux/Aegisub-Motion 1

Lua plugin for Aegisub auto4 that parses motion tracking data and applies it to selected subtitles.

CoffeeFlux/Fushigi-Tools 1

Translation tools for ふしぎ電車, a weird old doujin denpa nukige

CoffeeFlux/aegisite 0

Aegisub's website

CoffeeFlux/aspnetcore 0

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.

CoffeeFlux/build-libcurl-windows 0

Batch script to download and build libcurl (using Visual Studio compiler)

pull request commentdotnet/runtime

[Mono] Prevent race condition using volatile variable and early return

I think I added that comment about it being potentially racey? In addition to Alex's comment about how to properly fix this using atomics, I don't think this potential race is much of a problem in practice. Unless you have a real scenario impacted by this, I doubt it meets the servicing bar for 5.0.

gAlfonso-bit

comment created time in 6 days

issue commentAegisub/Aegisub

Release new stable (3.4.0)

The TSTools branch should be merged in fairly soon - just a few remaining things to take care of. Further development should happen in this repo.

CoffeeFlux

comment created time in 14 days

issue commentTypesettingTools/Aegisub

meson: patch ffms2 to disable audio gap filling

It does, unfortunately. This bug is a huge show-stopper for a lot of people, especially because it's not something they're likely to notice until they've already timed a large portion of the episode.

On certain videos the ffms2 gap-filling code overcorrects and the video timing will be subtly off, and it will get worse the longer the video plays. This means at playback the timing seems fine at first but progressively decays until it can be off by multiple seconds.

I'll also take a look at your PR in the next couple days—sorry for the delay, I've been out of town.

CoffeeFlux

comment created time in 16 days

create barnchCoffeeFlux/puppeteer_test

branch : master

created branch time in 24 days

created repositoryCoffeeFlux/puppeteer_test

created time in 24 days

pull request commentdotnet/runtime

Expose cross-platform helpers for Vector64, Vector128, and Vector256

I'm no longer at Microsoft, but I suspect @imhameed can help you out with intrinsics!

tannergooding

comment created time in 25 days

issue commentdotnet/runtime

iOS Simulator test runs don't find simulator

Not sure; I no longer have the laptop where it was happening. Should be safe to close.

CoffeeFlux

comment created time in a month

issue closeddotnet/runtime

iOS Simulator test runs don't find simulator

Title. Multiple simulators are installed via XCode, including the latest. Running the XCode project manually works fine.

Log:

ryan@kenshin:~/git/runtime$ ./dotnet.sh build src/libraries/System.Threading.Timer/tests/ /t:test /p:targetos=iOSSimulator /p:targetarchitecture=x64
Microsoft (R) Build Engine version 16.10.0-preview-21126-01+6819f7ab0 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  System.Security.Principal.Windows -> /Users/ryan/git/runtime/artifacts/bin/System.Security.Principal.Windows/ref/netstandard2.0-Debug/System.Security.Principal.Windows.dll
  System.Security.AccessControl -> /Users/ryan/git/runtime/artifacts/bin/System.Security.AccessControl/ref/netstandard2.0-Debug/System.Security.AccessControl.dll
  Microsoft.Win32.Registry -> /Users/ryan/git/runtime/artifacts/bin/Microsoft.Win32.Registry/ref/netstandard2.0-Debug/Microsoft.Win32.Registry.dll
  System.Runtime -> /Users/ryan/git/runtime/artifacts/bin/System.Runtime/ref/net6.0-Debug/System.Runtime.dll
  System.Security.Principal -> /Users/ryan/git/runtime/artifacts/bin/System.Security.Principal/ref/net6.0-Debug/System.Security.Principal.dll
  System.Runtime.Extensions -> /Users/ryan/git/runtime/artifacts/bin/System.Runtime.Extensions/ref/net6.0-Debug/System.Runtime.Extensions.dll
  System.Collections -> /Users/ryan/git/runtime/artifacts/bin/System.Collections/ref/net6.0-Debug/System.Collections.dll
  System.ComponentModel -> /Users/ryan/git/runtime/artifacts/bin/System.ComponentModel/ref/net6.0-Debug/System.ComponentModel.dll
  Microsoft.Win32.Primitives -> /Users/ryan/git/runtime/artifacts/bin/Microsoft.Win32.Primitives/ref/net6.0-Debug/Microsoft.Win32.Primitives.dll
  System.ObjectModel -> /Users/ryan/git/runtime/artifacts/bin/System.ObjectModel/ref/net6.0-Debug/System.ObjectModel.dll
  System.Runtime.InteropServices -> /Users/ryan/git/runtime/artifacts/bin/System.Runtime.InteropServices/ref/net6.0-Debug/System.Runtime.InteropServices.dll
  System.Collections.NonGeneric -> /Users/ryan/git/runtime/artifacts/bin/System.Collections.NonGeneric/ref/net6.0-Debug/System.Collections.NonGeneric.dll
  System.Memory -> /Users/ryan/git/runtime/artifacts/bin/System.Memory/ref/net6.0-Debug/System.Memory.dll
  System.ComponentModel.Primitives -> /Users/ryan/git/runtime/artifacts/bin/System.ComponentModel.Primitives/ref/net6.0-Debug/System.ComponentModel.Primitives.dll
  System.Net.Primitives -> /Users/ryan/git/runtime/artifacts/bin/System.Net.Primitives/ref/net6.0-Debug/System.Net.Primitives.dll
  System.Collections.Specialized -> /Users/ryan/git/runtime/artifacts/bin/System.Collections.Specialized/ref/net6.0-Debug/System.Collections.Specialized.dll
  System.Net.WebSockets -> /Users/ryan/git/runtime/artifacts/bin/System.Net.WebSockets/ref/net6.0-Debug/System.Net.WebSockets.dll
  System.Security.Claims -> /Users/ryan/git/runtime/artifacts/bin/System.Security.Claims/ref/net6.0-Debug/System.Security.Claims.dll
  System.Security.Principal.Windows -> /Users/ryan/git/runtime/artifacts/bin/System.Security.Principal.Windows/ref/net6.0-Debug/System.Security.Principal.Windows.dll
  System.Security.AccessControl -> /Users/ryan/git/runtime/artifacts/bin/System.Security.AccessControl/ref/net6.0-Debug/System.Security.AccessControl.dll
  TestUtilities -> /Users/ryan/git/runtime/artifacts/bin/TestUtilities/net6.0-Debug/TestUtilities.dll
  System.Threading.Timer.Tests -> /Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/System.Threading.Timer.Tests.dll
  System.Threading.Timer.Tests -> /Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/publish/
  Running: xcrun --sdk iphonesimulator --show-sdk-path
  Using working directory: /Users/ryan/git/runtime/src/libraries/System.Threading.Timer/tests
  Running: cmake -S. -BSystem.Threading.Timer.Tests -GXcode -DCMAKE_SYSTEM_NAME=iOS -DCMAKE_OSX_DEPLOYMENT_TARGET=10.1
  Using working directory: /Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/AppBundle/
  Running: xcodebuild ONLY_ACTIVE_ARCH=YES -allowProvisioningUpdates DEVELOPMENT_TEAM= -arch x86_64 -sdk iphonesimulator -configuration Release
  Using working directory: /Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/AppBundle/System.Threading.Timer.Tests
  
  APP size: 40 Mb.
  
  Xcode: /Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/AppBundle/System.Threading.Timer.Tests/System.Threading.Timer.Tests.xcodeproj
  App: /Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/AppBundle/System.Threading.Timer.Tests/Release-iphonesimulator/System.Threading.Timer.Tests.app
  XHarness command issued: apple test --app=/Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/AppBundle/System.Threading.Timer.Tests/Release-iphonesimulator/System.Threading.Timer.Tests.app --targets=ios-simulator-64 --xcode=/Applications/Xcode.app/Contents/Developer/../.. --output-directory=/Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/AppBundle/xharness-output
  info: Preparing run for ios-simulator-64
  info: Getting app bundle information..
  info: Starting application 'System.Threading.Timer.Tests' on ios-simulator-64
  fail: Failed to find suitable device for target ios-simulator-64
        Please make sure suitable Simulator is installed in Xcode
  XHarness exit code: 81 (DEVICE_NOT_FOUND)
  XHarness artifacts: /Users/ryan/git/runtime/artifacts/bin/System.Threading.Timer.Tests/net6.0-Debug/iossimulator-x64/AppBundle/xharness-output
/Users/ryan/git/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Threading.Timer.Tests'. [/Users/ryan/git/runtime/src/libraries/System.Threading.Timer/tests/System.Threading.Timer.Tests.csproj]

Build FAILED.

/Users/ryan/git/runtime/eng/testing/tests.targets(117,5): error : One or more tests failed while running tests from 'System.Threading.Timer.Tests'. [/Users/ryan/git/runtime/src/libraries/System.Threading.Timer/tests/System.Threading.Timer.Tests.csproj]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:31.45

closed time in a month

CoffeeFlux

create barnchCoffeeFlux/blazor-size-script

branch : master

created branch time in a month

created repositoryCoffeeFlux/blazor-size-script

created time in a month

push eventdotnet/runtime

Ryan Lucia

commit sha 3b3099f00add243f7ee453e7fd6975a00a9871ed

Remove CoffeeFlux from CODEOWNERS (#54696)

view details

push time in a month

PR merged dotnet/runtime

Reviewers
Remove CoffeeFlux from CODEOWNERS area-Meta

It's been fun!

+7 -9

2 comments

1 changed file

CoffeeFlux

pr closed time in a month

PR opened dotnet/runtime

Reviewers
Remove CoffeeFlux from CODEOWNERS

It's been fun!

+7 -9

0 comment

1 changed file

pr created time in a month

create barnchCoffeeFlux/runtime

branch : remove-codeowner

created branch time in a month

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentmono/mono

Start a dedicated thread for MERP crash reporting

 summarizer_supervisor_end (SummarizerSupervisorState *state) } #endif +/**+ *+ * Why a summarizer leader thread?+ *+ * The issue is that we set up signal handlers globally for all sorts of+ * process-wide problems: sigsegv, sigterm, etc.  Which means that if a thread+ * is created outside of the control of Mono, our signal handlers may still run+ * on those threads.  But one of the things we need to do is interact with our+ * thread state machinery, enumerate managed threads, etc - things that are+ * generally not possible to do from an unattached thread.  We have a choice:+ * we can either attach in the signal handler or we can punt the crash data+ * collection to a thread that we know is already running and is in a healthy+ * state.  Attaching in a signal handler is unlikely to work (attaching is not+ * async signal safe).  So instead we initialize a crash report leader thread+ * at startup, and ask it to collect the crash report on our behalf.+ * + *+ * The order of operations is:+ * - at startup:+ *   - main thread starts leader thread+ *   - leader thread starts, toggles leader_running and waits for begin_crash_report+ * - to report a crash:+ *   - mono_threads_summarize gates the crashes so only one thread originates a crash report at a time+ *   - originating thread writes its info to the leader and posts to begin_crash_report.+ *   - leader wakes up, copies the originator data, starts collecting a crash report+ *   - leader and originator coordinate via leader_commanded and the response_fds to collect a crash report+ *   - orignator returns to mono_threads_summarize, unblocks the next crash originator, if any, and then returns (which sends off the crash report in some way).+ */++typedef struct _MonoSummarizerOriginator {+	/* in data */+	SummarizerGlobalState *state;+	MonoNativeThreadId originator_tid;+	MonoContext *originator_ctx;+	gchar *working_mem; /* in-data: memory for the summary report and its size */+	size_t provided_size;+	gchar **out; /* pointer into working_mem containing the output string */+	/* in data - set after the originator dumps itself, while leader is waiting for all threads */+	MonoThreadSummary *originator_summary;+	/* out data */+	/* index of originator thread in list of threads collected by the leader */+	int originator_index;+} MonoSummarizerOriginator;+++typedef struct _MonoSummarizerLeader {+	MonoNativeThreadId leader_tid;+	int32_t leader_running; /* only atomic reads */+	MonoSemType begin_crash_report;+	/* originator cant post commands to the leader */+	MonoSemType leader_commanded;+	int leader_command;+	/* pipe to communicate back from the summarizer leader to the originator */+	int response_fds[2];+	/* Only one orignator at a time, gated by mono_threads_summarize tickets */+	MonoSummarizerOriginator originator;+} MonoSummarizerLeader;++static MonoSummarizerLeader summarizer_leader_data;++/* Commands from crash originator to the crash leader */+enum LeaderCommand {+	LEADER_COMMAND_ZERO = 0, /* not used */+	LEADER_COMMAND_CANCEL = -1,+	LEADER_COMMAND_PROCEED_TO_SUSPEND = 1,+	LEADER_COMMAND_PROCEED_TO_TERM = 2,+};++/* Responses from the crash leader to the crash originator */+enum LeaderResponse {+	LEADER_RESPONSE_IDS_COLLECTED = 1,+	LEADER_RESPONSE_THREADS_SUSPENDED = 2,+	LEADER_RESPONSE_STACKS_WALKED = 3,+};++#undef LEADER_DEBUG

Is this actually defined elsewhere? Wouldn't you want to put the opposite of this (and then comment it) for aiding with debugging?

lambdageek

comment created time in a month

Pull request review commentmono/mono

Start a dedicated thread for MERP crash reporting

 summarizer_supervisor_end (SummarizerSupervisorState *state) } #endif +/**+ *+ * Why a summarizer leader thread?+ *+ * The issue is that we set up signal handlers globally for all sorts of+ * process-wide problems: sigsegv, sigterm, etc.  Which means that if a thread+ * is created outside of the control of Mono, our signal handlers may still run+ * on those threads.  But one of the things we need to do is interact with our+ * thread state machinery, enumerate managed threads, etc - things that are+ * generally not possible to do from an unattached thread.  We have a choice:+ * we can either attach in the signal handler or we can punt the crash data+ * collection to a thread that we know is already running and is in a healthy+ * state.  Attaching in a signal handler is unlikely to work (attaching is not+ * async signal safe).  So instead we initialize a crash report leader thread+ * at startup, and ask it to collect the crash report on our behalf.+ * + *+ * The order of operations is:+ * - at startup:+ *   - main thread starts leader thread+ *   - leader thread starts, toggles leader_running and waits for begin_crash_report+ * - to report a crash:+ *   - mono_threads_summarize gates the crashes so only one thread originates a crash report at a time+ *   - originating thread writes its info to the leader and posts to begin_crash_report.+ *   - leader wakes up, copies the originator data, starts collecting a crash report+ *   - leader and originator coordinate via leader_commanded and the response_fds to collect a crash report+ *   - orignator returns to mono_threads_summarize, unblocks the next crash originator, if any, and then returns (which sends off the crash report in some way).+ */++typedef struct _MonoSummarizerOriginator {+	/* in data */+	SummarizerGlobalState *state;+	MonoNativeThreadId originator_tid;+	MonoContext *originator_ctx;+	gchar *working_mem; /* in-data: memory for the summary report and its size */+	size_t provided_size;+	gchar **out; /* pointer into working_mem containing the output string */+	/* in data - set after the originator dumps itself, while leader is waiting for all threads */+	MonoThreadSummary *originator_summary;+	/* out data */+	/* index of originator thread in list of threads collected by the leader */+	int originator_index;+} MonoSummarizerOriginator;+++typedef struct _MonoSummarizerLeader {+	MonoNativeThreadId leader_tid;+	int32_t leader_running; /* only atomic reads */+	MonoSemType begin_crash_report;+	/* originator cant post commands to the leader */+	MonoSemType leader_commanded;+	int leader_command;+	/* pipe to communicate back from the summarizer leader to the originator */+	int response_fds[2];+	/* Only one orignator at a time, gated by mono_threads_summarize tickets */+	MonoSummarizerOriginator originator;+} MonoSummarizerLeader;++static MonoSummarizerLeader summarizer_leader_data;++/* Commands from crash originator to the crash leader */+enum LeaderCommand {+	LEADER_COMMAND_ZERO = 0, /* not used */+	LEADER_COMMAND_CANCEL = -1,+	LEADER_COMMAND_PROCEED_TO_SUSPEND = 1,+	LEADER_COMMAND_PROCEED_TO_TERM = 2,+};++/* Responses from the crash leader to the crash originator */+enum LeaderResponse {+	LEADER_RESPONSE_IDS_COLLECTED = 1,+	LEADER_RESPONSE_THREADS_SUSPENDED = 2,+	LEADER_RESPONSE_STACKS_WALKED = 3,+};++#undef LEADER_DEBUG++#ifdef LEADER_DEBUG+#define LEADER_LOG(...) g_async_safe_printf (__VA_ARGS__)+#else+#define LEADER_LOG(...) /*empty*/+#endif++/* Called by the leader to send responses to the originator */+static void+summarizer_leader_response_write (char b)+{+	int res;+	LEADER_LOG ("leader --> originator: %d\n", (int)b);+	while ((res = write (summarizer_leader_data.response_fds[1], &b, sizeof (b))) < 0 && errno == EINTR);+}++/* Called by the originator to receive (blocking) responses from the leader */+static int+summarizer_leader_response_read (void)+{+	char buf;+	int nread = 0;+	do {+		int res = read(summarizer_leader_data.response_fds[0], &buf, sizeof (buf));+		if (res < 0) {+			if (errno == EINTR)+				continue;+			else+				return -1;+		}+		nread += res;+	} while (nread < sizeof (buf));+	LEADER_LOG ("originator <---- leader : %d\n", (int)buf);+	return (int)buf;+}++/* Called by the leader to wait for a command from the crash originator */+static gboolean+summarizer_leader_wait_for_command (int *leader_command)+{+	MONO_ENTER_GC_SAFE;+	/* allow interruptions */+	while (mono_os_sem_wait (&summarizer_leader_data.leader_commanded, MONO_SEM_FLAGS_ALERTABLE) < 0);+	MONO_EXIT_GC_SAFE;+	*leader_command = summarizer_leader_data.leader_command;+	if (*leader_command == LEADER_COMMAND_CANCEL) {+		return FALSE;+	}+	return TRUE;+}+++/* Called by the originator to post commands to the leader.  Usually just to proceed to the next state */+static void+summarizer_leader_post_command (int command)+{+	summarizer_leader_data.leader_command = command;+	mono_os_sem_post (&summarizer_leader_data.leader_commanded);+}++static void+summarizer_leader_collect_thread_ids (SummarizerGlobalState *state);+static void+summarizer_leader_suspend_others (SummarizerGlobalState *state, MonoNativeThreadId originator, int originator_idx);+static void+summarizer_leader_set_originator_summary (MonoThreadSummary *orignator_summary);+static void+summarizer_state_get_index_for_thread (SummarizerGlobalState *state, MonoNativeThreadId current, int *my_index);+static void+summarizer_state_wait_and_term (MonoNativeThreadId caller_tid, SummarizerGlobalState *state, gchar **out, gchar *working_mem, size_t provided_size, MonoThreadSummary *originator_summary);+static void+summarizer_leader_adjust_tids_for_foreign_originator (void);++static void+summarizer_leader (void)+{+	MonoInternalThread *thread = mono_thread_internal_current ();+	thread->flags |= MONO_THREAD_FLAG_DONT_MANAGE;++	/*+	 * This thread must not be stopped by the profiler or the STW+	 * machinery. While collecting crashes it also violates the coop GC+	 * rules by accessing managed memory to gather crash reports.  But+	 * crash reporting has its own signal-based mechanism to interrupt the+	 * other threads, so this is okay.+	 */+	mono_thread_info_set_flags (MONO_THREAD_INFO_FLAGS_NO_GC | MONO_THREAD_INFO_FLAGS_NO_SAMPLE);++	mono_thread_set_name_constant_ignore_error (thread, "Crash Report Leader", MonoSetThreadNameFlag_None);++	mono_thread_set_state (mono_thread_internal_current (), ThreadState_Background);++	/* This thread is always in async context */+	mono_thread_info_set_is_async_context (TRUE);+	+	mono_atomic_store_i32 (&summarizer_leader_data.leader_running, 1);+	while (TRUE) {+		/*case LEADER_STATE_READY:*/ {

I'd consider just putting a normal comment instead of leaving an artifact of the previous state machine design.

lambdageek

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentdotnet/runtime

[mono] Add accessors m_method_is_final and m_method_is_abstract

 method_is_reabstracted (MonoMethod *method) 	/* only on interfaces */ 	/* method is marked "final abstract" */ 	/* FIXME: we need some other way to detect reabstracted methods.  "final" is an incidental detail of the spec. */-	return method->flags & METHOD_ATTRIBUTE_FINAL && method->flags & METHOD_ATTRIBUTE_ABSTRACT;+	return m_method_is_final (method) && m_method_is_abstract (method);

Right, sorry, meant method is NULL. It's early 🙂

lambdageek

comment created time in a month

PullRequestReviewEvent

Pull request review commentdotnet/runtime

[mono] Add accessors m_method_is_final and m_method_is_abstract

 method_is_reabstracted (MonoMethod *method) 	/* only on interfaces */ 	/* method is marked "final abstract" */ 	/* FIXME: we need some other way to detect reabstracted methods.  "final" is an incidental detail of the spec. */-	return method->flags & METHOD_ATTRIBUTE_FINAL && method->flags & METHOD_ATTRIBUTE_ABSTRACT;+	return m_method_is_final (method) && m_method_is_abstract (method);

Is there a scenario where method->flags is NULL?

lambdageek

comment created time in a month

PullRequestReviewEvent

issue commentdotnet/runtime

System.IO.Path.GetFileName doesn't work in client-side Blazor wasm

Quoting from Jan:

All APIs on System.IO.Path and elsewhere follow the rules of the OS that the program is running on. I do not think it would make sense to add an overload that activates some other OS simulator to all these APIs.

We do not intend to add a Browser-specific workaround for this. Given we've had this come up multiple times, it's probably worth improving the documentation around the change. I'll leave this issue open for now until we decide how to handle that aspect.

cc: @lewing

julienGrd

comment created time in a month

issue commentdotnet/runtime

[mono][wasm] print the stack trace when exception.

I'm not clear on what the actual request is here, but typically we should be printing the stack trace. If you have a specific repro where the exception handling doesn't do what you expect, please open a new issue.

srxqds

comment created time in a month

issue closeddotnet/runtime

TimeZoneInfo.GetSystemTimeZones produces unexpected results in Blazor WASM for .NET 5

Describe the bug

When using TimeZoneInfo.GetSystemTimeZones method in Blazor WASM on .NET 5, I am getting a strange list returned.

image

  • The list is much shorter than I would expect, and appears to be missing many time zones. I even show, in my example, my current time zone, which is missing from the list.
  • The display names are not very good and not something I would want to show an end user.

Is there any other method to return all available time zones that I am not aware of?

To Reproduce

Use TimeZoneInfo.GetSystemTimeZones inside of a Blazor WASM page with .NET 5.

closed time in a month

andersme