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

hitstergtd/appengine-python-vm-runtime 0

Google Managed VMs Python Runtime

hitstergtd/appscale 0

The Open Source Implementation of Google App Engine -- Take your apps everywhere.

hitstergtd/awesome-swift 0

A collaborative list of awesome swift resources. Feel free to contribute!

hitstergtd/cloud-pubsub-samples-java 0

Cloud Pub/Sub sample applications with Java

hitstergtd/cooler_sse42_strcmp 0

strcmp() function implementation with SSE 4.2 instruction

hitstergtd/czmq 0

High-level C binding for ØMQ

hitstergtd/epibook.github.io 0

Publishes to Github Pages

hitstergtd/folding-cell 0

FoldingCell is an expanding content cell inspired by folding paper material

hitstergtd/Instagram-PHP-API 0

An easy-to-use PHP Class for accessing Instagram's API.

issue commentzeromq/libzmq

CPPZMQ V4.71 PGM/EPGM How can the subscriber get all the data from the publisher if the subscriber has low rate and may drop

There are a number of patterns described in the guide, you might be able to use one of them.

mercerme

comment created time in 4 hours

MemberEvent
MemberEvent

startedorta/specs-repo-git-scanner

started time in 14 hours

fork bluca/systemd-centos-ci

CI scripts for systemd upstream/downstream testing using the CentOS CI infrastructure

fork in a day

fork rnapier/Arduino_Boards

Board definitions for SparkFun-manufactured AVR, ARM, and ESP-based Arduino boards.

fork in 2 days

issue commentzeromq/libzmq

CPPZMQ V4.71 PGM/EPGM How can the subscriber get all the data from the publisher if the subscriber has low rate and may drop

As far as I can tell this is the intended behaviour of the PUB socket type:

When a ZMQ_PUB socket enters the mute state due to having reached the high water mark for a subscriber, then any messages that would be sent to the subscriber in question shall instead be dropped until the mute state ends.

(http://api.zeromq.org/4-3:zmq-socket#toc10)

If you need more reliable delivery with fan-out, I think you need to roll your own - I'm building something like this with client/server right now, albeit with TCP and not PGM.

mercerme

comment created time in 3 days

startedwangyu-/udp2raw-tunnel

started time in 3 days

startedkroitor/asciichart

started time in 4 days

created repositorydaneden/enable-automerge-action

created time in 4 days

issue closedzeromq/czmq

zloop SIGINT

/* Send SIGINT to this program, "main exit" can't print. Reopen zloop_set_verbose line, "main exit" can print. Why? */

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <czmq.h>

int timer_cb(zloop_t* loop, int timer_id, void* args) { printf("timer_id=%d\n", timer_id); return 0; }

int main(int argc, char* argv[]) { zloop_t* loop = zloop_new(); int timer_id = zloop_timer(loop, 1000, 0, timer_cb, NULL); // zloop_set_verbose(loop, true); zloop_start(loop); printf("main exit\n"); zloop_destroy(&loop); sleep(10); return 0; }

closed time in 4 days

zhangtaozt3601

issue commentzeromq/czmq

zloop SIGINT

Right, thank you.

zhangtaozt3601

comment created time in 4 days

push eventzeromq/libzmq

Jose Santiago

commit sha 7d8b149681d614d19a988a5328cfc7de464feddf

Fix Build BSD This fixes build under BSD. Tested with OpenBSD-6.4 and FreeBSD-11.3.

view details

Luca Boccassi

commit sha b4f758da35f9396c6a6bc538e57e63128ad5f307

Merge pull request #4174 from jlsantiago0/build-fix-bsd Fix Build BSD

view details

push time in 5 days

PR merged zeromq/libzmq

Fix Build BSD

This fixes build under BSD. Tested with OpenBSD-6.4 and FreeBSD-11.3.

+2 -0

0 comment

1 changed file

jlsantiago0

pr closed time in 5 days

push eventzeromq/libzmq

Jose Santiago

commit sha e6e683731def0d2a16b2109ad95a67bf756edfba

Fix MINGW with pthread cv ZeroMQ works and MINGW and pthread conditional variables if pthread mutexes are used. POSIX conditional variables require POSIX mutexes, but ZeroMQ unconditionally uses WIN32 critital sections even when configured with pthread conditional variables. This of course does not work. This patch fixes the build so that MINGW builds do not use WIN32 critical sections and instead use POSIX mutexes when configured with pthread conditional variables. Tested with: ``` CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ ../libzmq/configure --host=x86_64-w64-mingw32 --prefix=`pwd`/stage --enable-debug --disable-Werror --enable-libunwind=no --with-cv-impl=pthread --enable-libbsd=no ``` ``` x86_64-w64-mingw32-gcc --version x86_64-w64-mingw32-gcc (GCC) 10.2.0..... ```

view details

Luca Boccassi

commit sha 895e976f5142929f16d961663cafc3da358e2038

Merge pull request #4173 from jlsantiago0/mingw-build-fix2 Fix MINGW with pthread cv

view details

push time in 5 days

PR merged zeromq/libzmq

Fix MINGW with pthread cv

ZeroMQ works with MINGW and pthread conditional variables if pthread mutexes are used. POSIX conditional variables require POSIX mutexes, but ZeroMQ unconditionally uses WIN32 critital sections even when configured with pthread conditional variables. This of course does not work. This patch fixes the build so that MINGW builds do not use WIN32 critical sections and instead use POSIX mutexes when configured with pthread conditional variables.

Tested with:

 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ ../libzmq/configure --host=x86_64-w64-mingw32 --prefix=`pwd`/stage --enable-debug --disable-Werror --enable-libunwind=no   --with-cv-impl=pthread --enable-libbsd=no
x86_64-w64-mingw32-gcc --version

   x86_64-w64-mingw32-gcc (GCC) 10.2.0.....
+1 -1

1 comment

1 changed file

jlsantiago0

pr closed time in 5 days

issue closedzeromq/libzmq

Cannot build 4.3.3 with mingw

Issue description

zeromq 4.3.3 fails to build with mingw, where zeromq 4.3.2 was fine:

tests/testutil.hpp:105:15: error: conflicting declaration of C function ‘int closesocket(int)’
  105 | #define close closesocket
      |               ^~~~~~~~~~~
In file included from tests/../src/windows.hpp:54,
                 from tests/testutil.hpp:43,
                 from tests/testutil_unity.hpp:34,
                 from tests/testutil_unity.cpp:29:
/usr/share/mingw-w64/include/winsock2.h:1005:34: note: previous declaration ‘int closesocket(SOCKET)’
 1005 |   WINSOCK_API_LINKAGE int WSAAPI closesocket(SOCKET s);
      |                                  ^~~~~~~~~~~

Everything builds fine if I delete the:

#define close closesocket

referenced above, but I don't whether this is some hack needed for other Windows compilers (e.g. MSVC). It does seem like a pretty dangerous thing to define in a header, though.

Since that define was there in 4.3.2, I am not sure why this started failing in 4.3.3: perhaps some test includes shuffled around?

(Looking at it more closely, it seems testutil.hpp has quite a bit of other Windows-related cruft that isn't needed at all since it has already included ../src/windows.hpp).

Environment

  • libzmq version 4.3.3
  • OS: Debian linux
  • $ x86_64-w64-mingw32-gcc --version x86_64-w64-mingw32-gcc (GCC) 10-posix 20200525

closed time in 5 days

jagerman

push eventzeromq/libzmq

Jose Santiago

commit sha 235654697f4ec1a4bdd83ff4328f677790cb1683

MINGW Build Fix. There is a macro that redefines claose to closesocket, but then close is later defined in unistd.h which is included in testutil_unity.cpp which then causes the regular close() prototype to be defined with the new function name closesocket which does not match the signature of the original closesocket in winsock2.h from the toolchain. We can work around this issue, by making sure that unistd.h is included before the macro is defined. HMM> Yes macro substitution is the root of evil.

view details

Luca Boccassi

commit sha 43cb2600ca45543412f5380cfb044202b01af4db

Merge pull request #4172 from jlsantiago0/mingw-build-fix1 MINGW Build Fix.

view details

push time in 5 days

PR merged zeromq/libzmq

MINGW Build Fix.

There is a macro that redefines close to closesocket, but then close is later defined in unistd.h which is included in testutil_unity.cpp which then causes the regular close() prototype to be defined with the new function name closesocket which does not match the signature of the original closesocket in winsock2.h from the toolchain.

We can work around this issue, by making sure that unistd.h is included before the macro is defined. HMM> Yes macro substitution is the root of evil.

+3 -0

1 comment

1 changed file

jlsantiago0

pr closed time in 5 days

PR opened zeromq/libzmq

Fix Build BSD

This fixes build under BSD. Tested with OpenBSD-6.4 and FreeBSD-11.3.

+2 -0

0 comment

1 changed file

pr created time in 5 days

issue commentzeromq/libzmq

Cannot build 4.3.3 with mingw

Pull request submitted #4172 .

jagerman

comment created time in 5 days

pull request commentzeromq/libzmq

Fix MINGW with pthread cv

This needs #4172 to build the tests.

jlsantiago0

comment created time in 5 days

PR opened zeromq/libzmq

Fix MINGW with pthread cv

ZeroMQ works and MINGW and pthread conditional variables if pthread mutexes are used. POSIX conditional variables require POSIX mutexes, but ZeroMQ unconditionally uses WIN32 critital sections even when configured with pthread conditional variables. This of course does not work. This patch fixes the build so that MINGW builds do not use WIN32 critical sections and instead use POSIX mutexes when configured with pthread conditional variables.

Tested with:

 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++ ../libzmq/configure --host=x86_64-w64-mingw32 --prefix=`pwd`/stage --enable-debug --disable-Werror --enable-libunwind=no   --with-cv-impl=pthread --enable-libbsd=no
x86_64-w64-mingw32-gcc --version

   x86_64-w64-mingw32-gcc (GCC) 10.2.0.....
+1 -1

0 comment

1 changed file

pr created time in 5 days

pull request commentzeromq/libzmq

MINGW Build Fix.

NOTE: This should resolve issue #4044

jlsantiago0

comment created time in 5 days

PR opened zeromq/libzmq

MINGW Build Fix.

There is a macro that redefines close to closesocket, but then close is later defined in unistd.h which is included in testutil_unity.cpp which then causes the regular close() prototype to be defined with the new function name closesocket which does not match the signature of the original closesocket in winsock2.h from the toolchain.

We can work around this issue, by making sure that unistd.h is included before the macro is defined. HMM> Yes macro substitution is the root of evil.

+3 -0

0 comment

1 changed file

pr created time in 5 days

fork tmatsuo/nodejs-bigtable

Node.js client for Google Cloud Bigtable: Google's NoSQL Big Data database service.

https://cloud.google.com/bigtable/

fork in 6 days

issue commentzeromq/czmq

zloop SIGINT

if you use verbose zsys_init will be called. That probably explains the difference.

zhangtaozt3601

comment created time in 7 days

startedF-Secure/unixkit

started time in 7 days

startedSTMicroelectronics/STBlueMS_iOS

started time in 7 days