profile
viewpoint

felixge/cakephp-authsome 125

Auth for people who hate the Auth component

felixge/debuggable-scraps 79

MIT licensed code without warranty ; )

felixge/couchdb-benchmarks 10

some benchmark scripts for testing CouchDB performance

felixge/can 5

Nothing to see here yet.

felixge/commander.js 5

node.js command-line interfaces made easy

felixge/ack 3

A replacement for grep for programmers

felixge/berlinjs.org 3

The official BerlinJS website

felixge/depmake 3

A collection of bash functions and conventions for creating applications that can bundle all their code and dependencies inside a tar file.

felixge/cakephp 2

CakePHP: The Rapid Development Framework for PHP - Official Repository

startednihey/react-clipboard.js

started time in 11 hours

startedVividCortex/ewma

started time in 13 hours

starteddarold/pgFormatter

started time in 4 days

push eventfelixge/dump

Felix Geisendörfer

commit sha 292ca82f1beeb91791745dc3452e93ac0f683820

Fix code to handle empty result set Reported by PavelBisse on Twitter [1]. [1] https://twitter.com/PavelBisse/status/1262712001094135809

view details

push time in 7 days

push eventfelixge/dump

Felix Geisendörfer

commit sha 131b944300173b1354a7b07ab87940a74be04773

postgres-json-orm example for tomas

view details

push time in 7 days

pull request commentjackc/pgproto3

fix: AuthenticationMD5Password AuthType

Thanks @jackc and no worries. I'm deeply grateful for your work on all your PostgreSQL packages.

felixge

comment created time in 8 days

pull request commentjackc/pgproto3

fix: AuthenticationMD5Password AuthType

@kensaggy yeah, I just added this to the bottom of my go.mod to use my fork. This approach means you don't need to rewrite the import paths in your own code.

// see https://github.com/jackc/pgproto3/pull/1
replace github.com/jackc/pgproto3/v2 => github.com/felixge/pgproto3/v2 v2.0.0-rc3.0.20190908152906-a90ef7ed5b85
felixge

comment created time in 8 days

pull request commentjackc/pgproto3

fix: AuthenticationMD5Password AuthType

(funny enough like @felixge I am also building a PostgresSQL proxy based on pgproto3 :))

Building custom PG proxies is fun, isn't it : )? Mine is a little gateway that serves fake catalog tables that make clients think the proxy has lots of "databases", which are really just gateways into different servers. Saves users from maintaining tons of connections bookmarks in their clients.

What is your proxy doing?

felixge

comment created time in 8 days

startedtravisjeffery/jocko

started time in 8 days

startedpowa-team/pg_stat_kcache

started time in 14 days

PR opened powa-team/pg_stat_kcache

Fix typo
+1 -1

0 comment

1 changed file

pr created time in 14 days

push eventfelixge/pg_stat_kcache

Felix Geisendörfer

commit sha bafd4bf586091ab660b754ca2363f0da838bf858

Fix typo

view details

push time in 14 days

fork felixge/pg_stat_kcache

Gather statistics about physical disk access and CPU consumption done by backends.

fork in 14 days

startedsphawes/index

started time in 15 days

PR opened jackc/pgx

Fix typo in readme
+1 -1

0 comment

1 changed file

pr created time in a month

push eventfelixge/pgx

Felix Geisendörfer

commit sha 23a4edc0d73e95f775e46cb840260326b4a141e1

Fix typo in readme

view details

push time in a month

startedpeterbourgon/ff

started time in a month

startedBurntSushi/ripgrep

started time in a month

startedlfittl/pg_query

started time in 2 months

pull request commentfelixge/node-sandboxed-module

added filename argument to source transformer

@helloIAmPau thx, done!

$ npm owner add boemianrapsodi sandboxed-module
+ boemianrapsodi (sandboxed-module)
helloIAmPau

comment created time in 2 months

MemberEvent

pull request commentfelixge/node-sandboxed-module

added filename argument to source transformer

What's you NPM username?

helloIAmPau

comment created time in 2 months

pull request commentfelixge/node-sandboxed-module

added filename argument to source transformer

Thanks!

I'm not actively maintaining any of my NPM modules these days anymore, so I merged your PR without reviewing it carefully.

If you're interested in helping with this module going forward, I'm happy to add you on NPM/GitHub as a contributor.

helloIAmPau

comment created time in 2 months

push eventfelixge/node-sandboxed-module

Pasquale Boemio

commit sha 3317772f787b3109e6f7805cdde74e8bebd6efb5

added filename argument to source transformer

view details

Felix Geisendörfer

commit sha 07ed11d52e709e3d19bf2b6cfbf44579f6efdea5

Merge pull request #69 from helloIAmPau/adding_filename_argument_to_source_transformer added filename argument to source transformer

view details

push time in 2 months

PR merged felixge/node-sandboxed-module

added filename argument to source transformer

Hello @felixge, in this PR I start passing the source filename as the second argument of the sourceTransformer callbacks. It can be helpful for cases in which you have to decide to either parse or not the source code based on the file extension.

Moreover, I added a new makefile rule running the tests into a docker container configured ad-hoc for testing purposes (your test environment is not compatible anymore with the current LTS version of node and with OSX systems).

Hope you enjoy the changes :)

+311 -16

0 comment

5 changed files

helloIAmPau

pr closed time in 2 months

push eventfelixge/go-multierror

Felix Geisendörfer

commit sha 5617f62be43512770302a928710fc7e1105ccb47

add Unwrap dealing with pointer values This was breaking before 0c3d827a1e5a371fa426299e398ef78ad3554679 was added.

view details

push time in 2 months

push eventfelixge/go-multierror

Felix Geisendörfer

commit sha 9b44b21f121fb1f033eded9b035d48a957e9df41

add test case for Unwrap + Errorf

view details

push time in 2 months

push eventfelixge/go-multierror

Mitchell Hashimoto

commit sha 58e4f1897fb08fd76f5fd4e81e2c6c5dddb59899

Support Go 1.13 errors.As/Is/Unwrap functionality The primary mechanism that enables this functionality is making `Unwrap` on the top-level Error return a new "chain" structure that uses state to keep track of the current error. The chain implements errors.Is/As so that it compares to that current underlying error. And it implements Unwrap to move on to the next error. A well-formed program using errors.Is/As/Unwrap exclusively will behave correctly with go-multierror in this case without dropping any errors. Direct comparisons such as `Unwrap() == myErr` will not work because we wrap in a chain. The user has to do `errors.Is(err, myErr)` which is the right thing to do anyways. When Unwrap is called on a top-level *Error, we create a shallow copy of the errors so that you can continue using *Error (modifying it, potentially in-place). There is a slight cost to this but it felt weird that calling Unwrap would share the same underlying data and cause potential data races. I think this is unlikely, but its also very unlikely the performance cost of the shallow copy of errors will matter either. Thanks to @felixge on Twitter for pushing me to do this, showing some examples on how it could be done, and providing feedback to this PR.

view details

Mitchell Hashimoto

commit sha 38eaa6a9544695191bf72cc827463e22ecfa24a1

Unwrap: one error can be returned directly

view details

Mitchell Hashimoto

commit sha 22c4e2b73e0d1850bd91dc756c66c237fe04b1f9

implement chain by just wrapping a slice Thanks to @rogpeppe on Twitter for pointing out we don't need a struct to take care of accounting and can instead just continue to reslice and wrap []error.

view details

Mitchell Hashimoto

commit sha 0c3d827a1e5a371fa426299e398ef78ad3554679

Address feedback

view details

Felix Geisendörfer

commit sha 19cff121b89c27ee263fce343d482838a6e1f717

test for edge case

view details

push time in 2 months

pull request commenthashicorp/go-multierror

Support Go 1.13 errors.As/Is/Unwrap functionality

Still thinking through edge cases. Here is a test case for one of them that might be worth including (the implementation already passes it):

diff --git a/multierror_test.go b/multierror_test.go
index 789230e..972c52d 100644
--- a/multierror_test.go
+++ b/multierror_test.go
@@ -2,6 +2,7 @@ package multierror
 
 import (
 	"errors"
+	"fmt"
 	"reflect"
 	"testing"
 )
@@ -121,6 +122,18 @@ func TestErrorIs(t *testing.T) {
 		}
 	})
 
+	t.Run("with errBar wrapped by fmt.Errorf", func(t *testing.T) {
+		err := &Error{Errors: []error{
+			errors.New("foo"),
+			fmt.Errorf("errorf: %w", errBar),
+			errors.New("baz"),
+		}}
+
+		if !errors.Is(err, errBar) {
+			t.Fatal("should be true")
+		}
+	})
+
 	t.Run("without errBar", func(t *testing.T) {
 		err := &Error{Errors: []error{
 			errors.New("foo"),
@@ -152,6 +165,22 @@ func TestErrorAs(t *testing.T) {
 		}
 	})
 
+	t.Run("with the value wrapped by fmt.Errorf", func(t *testing.T) {
+		err := &Error{Errors: []error{
+			errors.New("foo"),
+			fmt.Errorf("errorf: %w", match),
+			errors.New("baz"),
+		}}
+
+		var target *nestedError
+		if !errors.As(err, &target) {
+			t.Fatal("should be true")
+		}
+		if target == nil {
+			t.Fatal("target should not be nil")
+		}
+	})
+
 	t.Run("without the value", func(t *testing.T) {
 		err := &Error{Errors: []error{
 			errors.New("foo"),

mitchellh

comment created time in 2 months

Pull request review commenthashicorp/go-multierror

Support Go 1.13 errors.As/Is/Unwrap functionality

 func (e *Error) Unwrap() error { // the wrapped error here but we can't do that if we want to properly // get access to all the errors. Instead, users are recommended to use // Is/As to get the correct error type out.-type chain struct {-	idx    int-	errors []error-}+type chain []error  // Error implements the error interface-func (e *chain) Error() string {-	return e.current().Error()+func (e chain) Error() string {+	return e[0].Error() }  // Unwrap implements errors.Unwrap by returning the next error in the // chain or nil if there are no more errors.-func (e *chain) Unwrap() error {-	next := e.idx + 1-	if len(e.errors) <= next {+func (e chain) Unwrap() error {+	if len(e) == 1 { 		return nil 	} -	return &chain{idx: next, errors: e.errors}+	return chain(e[1:]) }  // As implements errors.As by attempting to map to the current value.-func (e *chain) As(target interface{}) bool {-	return errors.As(e.current(), target)+func (e chain) As(target interface{}) bool {+	return errors.As(e[0], target) }  // Is implements errors.Is by comparing the current value directly.-func (e *chain) Is(target error) bool {-	return e.current() == target-}--func (e *chain) current() error {-	return e.errors[e.idx]+func (e chain) Is(target error) bool {+	return e[0] == target

Agreed. I made the same comment here: https://github.com/hashicorp/go-multierror/pull/35#discussion_r401053061

mitchellh

comment created time in 2 months

Pull request review commenthashicorp/go-multierror

Support Go 1.13 errors.As/Is/Unwrap functionality

 func (e *Error) GoString() string { func (e *Error) WrappedErrors() []error { 	return e.Errors }++// Unwrap returns an error from Error (or nil if there are no errors).+// This error returned will further support Unwrap to get the next error,+// etc. The order will match the order of Errors in the multierror.Error+// at the time of calling.+//+// The resulting error supports errors.As/Is/Unwrap so you can continue+// to use the stdlib errors package to introspect further.+//+// This will perform a shallow copy of the errors slice. Any errors appended+// to this error after calling Unwrap will not be available until a new+// Unwrap is called on the multierror.Error.+func (e *Error) Unwrap() error {+	// If we have no errors then we do nothing+	if e == nil || len(e.Errors) == 0 {+		return nil+	}++	// Shallow copy the slice+	errs := make([]error, len(e.Errors))+	copy(errs, e.Errors)++	return &chain{errors: errs}+}++// chain implements the interfaces necessary for errors.Is/As/Unwrap to+// work in a deterministic way with multierror. A chain tracks a list of+// errors while accounting for the current represented error. This lets+// Is/As be meaningful.+//+// Unwrap returns the next error. In the cleanest form, Unwrap would return+// the wrapped error here but we can't do that if we want to properly+// get access to all the errors. Instead, users are recommended to use+// Is/As to get the correct error type out.+type chain struct {+	idx    int+	errors []error+}++// Error implements the error interface+func (e *chain) Error() string {+	return e.current().Error()+}++// Unwrap implements errors.Unwrap by returning the next error in the+// chain or nil if there are no more errors.+func (e *chain) Unwrap() error {+	next := e.idx + 1+	if len(e.errors) <= next {+		return nil+	}++	return &chain{idx: next, errors: e.errors}+}++// As implements errors.As by attempting to map to the current value.+func (e *chain) As(target interface{}) bool {+	return errors.As(e.current(), target)+}++// Is implements errors.Is by comparing the current value directly.+func (e *chain) Is(target error) bool {+	return e.current() == target

The Go docs for errors.Is say:

An error is considered to match a target if it is equal to that target or if it implements a method Is(error) bool such that Is(target) returns true.

IMO it is therefor reasonable to expect that same logic is used for errors wrapped by go-multierror, i.e. if a wrapped error implements Is(error) bool, then that method should be called to determine equality rather than a simple == check.

This should fix it:

	return errors.Is(e.current(), target)
mitchellh

comment created time in 2 months

fork felixge/go-multierror

A Go (golang) package for representing a list of errors as a single error.

fork in 2 months

startedhashicorp/go-multierror

started time in 2 months

startedbouk/monkey

started time in 3 months

starteddanistefanovic/build-your-own-x

started time in 3 months

issue commentnodejs/node

Repeated socket data events can block timers, etc

@bnoordhuis ok, fair enough. I understand you didn't intend the 32 event count to become a scheduler, but for better or worse, that's the emergent behavior of it.

I also understand that the node core is probably more concerned with e.g. http req/s throughput performance than tail latencies since there are available workarounds.

That being said, tail latencies are important for microservice architectures where a single user request may trigger many internal requests. Even when those are parallelized, a single latency outlier will slow down everything else.

Anyway, I think microservices are mistake in most cases, and I'm also not using node or node-mysql these days, so I'm unlikely to send a patch. However, I appreciate your responses and hopefully somebody else will feel inspired to tackle this in the node core at some point. If it's feasible, it'd be nice to see node I/O scheduling to be more tail-latency friendly under high concurrency.

logidelic

comment created time in 3 months

issue commentmysqljs/mysql

Driver blocking node event loop

@logidelic any sort of attempt to implement user-land scheduling will be a tradeoff between latency and throughput.

That being said, I suspect your proposal will have a higher overhead than mine (as every callback gets deferred, even if the event loop hasn't be blocked much), and also seems to allow unbound memory usage which might could cause significant issues for people dealing with very large query results.

dgottlie

comment created time in 3 months

startederthalion/postgres-bcc

started time in 3 months

issue commentnodejs/node

Repeated socket data events can block timers, etc

From the linked issue I infer that mysqljs consumes data in "fire hose" mode and doesn't apply back-pressure.

Yes, that's currently the case, and I also agree that node-mysql could use stream.pause(), setImmediate, and stream.resume() as shown here to mitigate the problem.

I just think that's it's a kludge to have to coerce the I/O scheduling from user-land like this. IMO it'd be much better if the count circuit breaker in libuv could be controlled on a per-socket level, e.g. stream.setEventLimit(). This should not decrease latency for existing code, and is probably far more efficient than the workaround outlined above.

Anyway, I don't have a horse in this race, so I'm not expecting any changes. I just found this to be an interesting issue, and hope my suggestions might be useful.

logidelic

comment created time in 3 months

issue commentmysqljs/mysql

Driver blocking node event loop

@logidelic I replied to the node thread. I think node has a scheduling problem and the suggested workaround seems unreasonable for many scenarios, including node-mysql. Let’s see the discussion continues

dgottlie

comment created time in 3 months

issue commentnodejs/node

Repeated socket data events can block timers, etc

@bnoordhuis the rules for async programming make sense. But I still don’t understand how that justifies the current scheduling behavior? Why 32 events?

If my callback computes something for 1ms, do you call that “blocking”? Where is the threshold? It hardly is worth moving 1ms of computation into a worker from an overhead perspective. What are you suggesting in that case? Accept up to 32ms time delays for a single socket? It might be 320ms for 10 sockets right?

logidelic

comment created time in 3 months

more