profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/hyc/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.

hyc/fcrackzip 326

A braindead program for cracking encrypted ZIP archives. Forked from http://oldhome.schmorp.de/marc/fcrackzip.html

hyc/cpuminer-multi 66

Obsolete Multi-algo CPUMiner: Do not use.

hyc/BerkeleyDB 27

Unofficial repo of Oracle BerkeleyDB source

hyc/lljvm 25

Low Level Java Virtual Machine

hyc/HyperDex 22

HyperDex is a scalable, searchable key-value store

hyc/leveldb 18

clone of https://code.google.com/p/leveldb/

hyc/arc 7

The original file archiver ported from MSDOS to Unix

aido/picocoin 5

A small bitcoin client

hyc/cfengine_core 1

CFEngine Community

pull request commentopenwrt/openwrt

umbim/wwan: DHCP and static configuration coexistence, bugfixes.

I wish I did, but no. I think the major carriers in US do now.

Leo-PL

comment created time in a day

issue commentthiagotei/linux-realtek-alc287

Did not work for me :( (Lenovo Legion 7 2021)

Sounds like that'll be quite a challenge. I don't even see CS35L51 on Cirrus Logic's product pages. L41 and L45 are there though. How is he going to get data sheets for a chip that the manufacturer doesn't even list as existing?

vineet131

comment created time in 4 days

issue commentthiagotei/linux-realtek-alc287

Did not work for me :( (Lenovo Legion 7 2021)

I also tried this on my 2021 Lenovo Legion 7 with no success. Wanted to add a bit more info - my alsa-info dump is here http://alsa-project.org/db/?f=75eea5cd869e28c69bf5360a2230fabfc997dc0a

Must point out that the Nvidia GPU's audio controller is in /dev/snd/hwC0D0 and the Realtek is in /dev/snd/hwC1D0. The apply-verbs script will fail as-is because it tries to talk to hwC0D0. However, even after editing it to talk to the right controller, I didn't get any working speakers. Headphones are still fine.

vineet131

comment created time in 5 days

pull request commentopenwrt/openwrt

umbim/wwan: DHCP and static configuration coexistence, bugfixes.

I'm still running with #2759 plus my small patches (https://github.com/TDT-AG/openwrt/pull/1) and have seen no crashes. That patchset is already using dynamic interfaces so I would expect it to already show the problem if it was there. But I also have to point out I'm not running on a current vanilla OpenWRT release. I'm on TurrisOS 5.1.8 on my Turris Omnia, which I believe is based on OpenWRT 19.07.

Leo-PL

comment created time in 8 days

pull request commentopenwrt/openwrt

umbim/wwan: DHCP and static configuration coexistence, bugfixes.

I'm still running with #2759 plus my small patches (https://github.com/TDT-AG/openwrt/pull/1) and have seen no crashes. That patchset is already using dynamic interfaces so I would expect it to already show the problem if it was there. But I also have to point out I'm not running on a current vanilla OpenWRT release. I'm on TurrisOS 5.1.8 on my Turris Omnia, which I believe is based on OpenWRT 19.07.

Leo-PL

comment created time in 8 days

Pull request review commentopenwrt/openwrt

umbim/wwan: DHCP and static configuration coexistence, bugfixes.

 proto_mbim_init_config() { 	proto_config_add_string auth 	proto_config_add_string username 	proto_config_add_string password+	[ -e /proc/sys/net/ipv6 ] && proto_config_add_string ipv6

OK, fair enough

Leo-PL

comment created time in 8 days

PullRequestReviewEvent

push eventLMDB/lmdb

Kris Zyp

commit sha e2b82098fa592b20cb3ba79ddbf28f2b2a692e39

ITS#9618 fix Windows WRITEMAP flush Revert back to using standard FlushViewOfFile/FlushFileBuffers to sync data with WRITEMAP mode on Windows

view details

push time in 8 days

Pull request review commentopenwrt/openwrt

umbim/wwan: DHCP and static configuration coexistence, bugfixes.

 proto_mbim_init_config() { 	proto_config_add_string auth 	proto_config_add_string username 	proto_config_add_string password+	[ -e /proc/sys/net/ipv6 ] && proto_config_add_string ipv6

I don't see any reason to check for system support here. Just honor whatever setting the user configured, as I did in https://github.com/TDT-AG/openwrt/pull/1/commits/76c27c2c0eab6f34e633517ca2a76ef916a2d67d

Leo-PL

comment created time in 8 days

PullRequestReviewEvent

Pull request review commentopenwrt/openwrt

umbim/wwan: DHCP and static configuration coexistence, bugfixes.

 _proto_mbim_setup() { 	proto_init_update "$ifname" 1 	proto_send_update "$interface" +	[ -z "$dhcp" ] && dhcp=1+ 	[ "$pdptype" = "ipv4" -o "$pdptype" = "ipv4v6" ] && {-		if [ -z "$dhcp" -o "$dhcp" = 0 ]; then+		if [ -n "$ipv4address" ]; then

This is closer to the intent of my previous patch, looks good to me. https://github.com/TDT-AG/openwrt/pull/1/commits/cacbab1605de31470da81e46348b3346d0fc054c

Leo-PL

comment created time in 8 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commenttevador/RandomX

Benchmark fails to run on 2012 Macbook in v1.1.9 (works in v1.1.8)

Actually, just to be sure - can you test it the opposite way too? Add this change as well:

diff --git a/src/virtual_memory.cpp b/src/virtual_memory.cpp
index 117e0a2..e3cc3c8 100644
--- a/src/virtual_memory.cpp
+++ b/src/virtual_memory.cpp
@@ -36,7 +36,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #ifdef __APPLE__
 #include <mach/vm_statistics.h>
 #include <TargetConditionals.h>
-# if defined(__aarch64__) && TARGET_OS_OSX
+# ifdef TARGET_OS_OSX
 # define USE_PTHREAD_JIT_WP    1
 # include <pthread.h>
 # endif
cryptonote-social

comment created time in 13 days

push eventhyc/RandomX

Howard Chu

commit sha 03e99e6dd72224a6bda47110606f0a918a3758ef

Fix #216 - MacOS JIT privs are ARM-specific

view details

push time in 13 days

PR opened tevador/RandomX

Fix #216 - MacOS JIT privs are not ARM-specific
+2 -10

0 comment

1 changed file

pr created time in 13 days

create barnchhyc/RandomX

branch : issue216

created branch time in 13 days

issue commentLumoSQL/lumosql

port to https://github.com/erthink/libmdbx also?

@vorot93 What did I say that was abrasive? Merely stating facts - if you want to make sure your questions get answered, you have to submit them in forum that's actually tracked. That's why we have bug trackers and mailing lists.

hiqsociety

comment created time in 13 days

issue commentLumoSQL/lumosql

port to https://github.com/erthink/libmdbx also?

Obtw, to answer your question about why the freelist is sorted in reverse order: we preferentially use pages in ascending order, and it's easier to truncate one element off the end of an array than to take it off the head of the array and be forced to slide everything else down before shrinking it. You would have gotten this answer a long time ago if you had actually asked in an OpenLDAP support channel.

hiqsociety

comment created time in 13 days

issue commentLumoSQL/lumosql

port to https://github.com/erthink/libmdbx also?

Twitter is not a support channel, so in all likelihood I never saw it.

Good luck with your project.

hiqsociety

comment created time in 13 days

issue commentLumoSQL/lumosql

port to https://github.com/erthink/libmdbx also?

@AlexeyAkhunov your post says "usage of LMDB that was not envisaged by the creators" - I don't recall you have ever communicated any such issues to us. Did you submit any bug reports or send any emails to the openldap-technical mailing list?

hiqsociety

comment created time in 14 days

issue commentpython-ldap/python-ldap

[doc] Explain TLS/SSL gotchas

In OpenLDAP 2.6 (due for release in September) the fix for ITS#9157 will be released. The error message from the TLS library will be saved in the LDAP* handle and retrievable via ldap_get_option(ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, ...).

tiran

comment created time in 14 days

pull request commentopenwrt/luci

luci-proto-mbim: Add MBIM support

That doesn't appear to have anything to do with this PR at all.

luci> git grep ra_flags
modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js:                                       so = ss.taboption('ipv6-ra', cbiRichListValue, 'ra_flags', _('<abbr title="Router Advertisement">RA</abbr> Flags'),
modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js:                                               var flags = L.toArray(uci.get('dhcp', section_id, 'ra_flags'));
modules/luci-mod-network/htdocs/luci-static/resources/view/network/interfaces.js:                                               uci.set('dhcp', section_id, 'ra_flags', [ 'none' ]);
luci> 
hyc

comment created time in 14 days

pull request commentopenwrt/openwrt

umbim / wwan: bugfixes + support for non-dhcp devices

AFAICS there cannot have been any existing users, so I don't believe backward compatibility is a valid issue. Particularly for Luci there clearly were never any users before.

sch-m

comment created time in 15 days

pull request commentopenwrt/luci

luci-proto-mbim: Add MBIM support

@Leo-PL please try again with these updates.

hyc

comment created time in 15 days

push eventhyc/luci

Howard Chu

commit sha 966236f6144a2d69f12e142bd7a832bde1256942

luci-proto-mbim: add missing proto default options This change add the following missing default options. - defaulroute - peerdns - metric Same as fa702c0387dd09a43b1d447e627d118f782ac767 Signed-off-by: Howard Chu <hyc@symas.com>

view details

Howard Chu

commit sha 9667361c238d8462d0b7c000b968feeb40fe76a9

protocols: fix interface.ipv6 vs. device.ipv6 option conflict Ref: https://forum.openwrt.org/t/pppoe-disable-ipv6/92548 Same as 7d49508480446febe4ed0de929f83ea923c98324 Signed-off-by: Howard Chu <hyc@symas.com>

view details

Howard Chu

commit sha b26367a51e30e302c48fbb591e046aaba09dfa36

protocols: rename "device" option to "_modem_device" This is required to resolve clashes with the generic "option device" referring to netdev names in current netifd versions. Same as 96ee6dc8d6c9796ab67de6f313a068a4bd3bb20f Signed-off-by: Howard Chu <hyc@symas.com>

view details

Howard Chu

commit sha 52bccd62c9c714a14fcdaaa05c372bdb79879ea4

luci-proto-mbim: add APN and PIN validation Same as 114dc38dc2ce82a9f32fdc16adaa6f435ee36881 Signed-off-by: Howard Chu <hyc@symas.com>

view details

push time in 15 days

pull request commentopenwrt/luci

luci-proto-mbim: Add MBIM support

Seems related to 96ee6dc8d6c9796ab67de6f313a068a4bd3bb20f I guess I have to rebase...

hyc

comment created time in 15 days

pull request commentopenwrt/openwrt

umbim / wwan: bugfixes + support for non-dhcp devices

If @Leo-PL prefers his version of the patches, go ahead and use his. I'm currently running with https://github.com/TDT-AG/openwrt/pull/1 but I don't much care which is finally used.

sch-m

comment created time in 17 days

CommitCommentEvent