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

DerGuteMoritz/clj-oauth2 81

OAuth 2.0 implementation for Clojure

DerGuteMoritz/activerecord-lazy-attributes 15

An ActiveRecord extension which allows attributes to be lazy loaded

ckeen/pastiche 13

An awful pasting application written in CHICKEN Scheme

DerGuteMoritz/eff-the-finder 12

Eff finds things right from your command line. Also, it's quite extensible!

DerGuteMoritz/axeml 7

An SXML-like library for contructing Nokogiri documents

DerGuteMoritz/althor880-activerecord-activesalesforce-adapter 2

An ActiveRecord adapter for the Salesforce.com API

DerGuteMoritz/bus-scheme 1

a Scheme written in Ruby, but implemented on the bus!

DerGuteMoritz/calendar_date_select 1

A popular and flexible JavaScript DatePicker for RubyOnRails (and others)

DerGuteMoritz/chicken-portaudio 1

Chicken Scheme bindings to PortAudio

delete branch bevuta/react-native-sqlite-2

delete branch : salus-adjust-podspec

delete time in 5 days

create barnchbevuta/react-native-sqlite-2

branch : salus-adjust-podspec

created branch time in 5 days

issue commentstumpwm/stumpwm

Odd interaction with some drop-down menu elements in Chromium-based web browsers

Moments later I found https://bugs.chromium.org/p/chromium/issues/detail?id=713746 which suggests passing --disable-features=SendMouseLeaveEvents as a workaround. So far it looks like this indeed also does the trick for stumpwm :crossed_fingers: Not sure what exactly the consequences are of this flag, though.

2kays

comment created time in 12 days

issue commentstumpwm/stumpwm

Odd interaction with some drop-down menu elements in Chromium-based web browsers

I experience the exact same issue. During research I came across https://www.reddit.com/r/archlinux/comments/mqgyg5/problem_with_chromium_and_css_dropdown_hover_menus/ which sounds pretty much like the same issue but caused by fluxbox WM in that case. The post goes on to suggest --enable-features=UseOzonePlatform as a workaround but unfortunately, that doesn't seem to fix it for stumpwm.

2kays

comment created time in 12 days

push eventbevuta/react-native-sqlite-2

Moritz Heidkamp

commit sha 36f092602ffd6215d014e46c2bc7838e3f2c8c53

chore(dep): update websql to 2.0.3 This update contains a pretty significant bug fix. See https://github.com/nolanlawson/node-websql/commit/5afb08307484b0bcbf53f1b4123da41d78200ec6 for details.

view details

push time in 17 days

PR opened craftzdog/react-native-sqlite-2

chore(dep): update websql to 2.0.3

This update contains a pretty significant bug fix. See https://github.com/nolanlawson/node-websql/commit/5afb08307484b0bcbf53f1b4123da41d78200ec6 for details.

+42 -44

0 comment

1 changed file

pr created time in 17 days

create barnchbevuta/react-native-sqlite-2

branch : bump-websql

created branch time in 17 days

pull request commentnolanlawson/node-websql

Explicitly roll back transaction on failed commit

Heh, looks like a bit of a blind spot in the coverage reporter there! Anyway, thanks a lot for merging this so swiftly :bow:

DerGuteMoritz

comment created time in 17 days

pull request commentnolanlawson/node-websql

Explicitly roll back transaction on failed commit

Hey @nolanlawson, thanks for the feedback! I looked into it, turned out to be complaining about the (typeof results !== "undefined") check in someError which I just left in there from the old implementation but turned out to be unnecessary since it'll always be called with a non-undefined value here. Then I also realized that extracting someError had become unnecessary after I made some final changes (it used to be called in more than one place in a previous version of the patch). I undid that change now so that the diff is a bit tighter. However, the coverage report is still complaining about commitError never being truthy now. I played around a little with making that happen but couldn't come up with anything. Do you happen to have an idea about that? Or perhaps node-sqlite3 just always translates commit errors into an error result set instead of passing an error to the callback for some reason? Even if this were the case, I would tend to leave that check in place, though, possibly with a comment explaining the coverage situation. WDYT?

DerGuteMoritz

comment created time in 20 days

push eventbevuta/node-websql

Moritz Heidkamp

commit sha 6364a3a60a51cd55e59cd0d9a8fa8715b92ed694

Explicitly roll back transaction on failed commit This is a follow-up for https://github.com/nolanlawson/node-websql/pull/44 which turned out to be incomplete: SQLite doesn't always automatically roll back transactions when commit fails. The patch expands the respective test case to demonstrate this. Without the fix, the last assertion would fail since the transaction that errored out on commit before would still be active and silently re-used by the next transaction, which would then end up seeing its temporary (and inconsistent) state. The patch is based on the following recommendation from the manual[1]: > It is recommended that applications respond to the errors listed > above by explicitly issuing a ROLLBACK command. If the transaction > has already been rolled back automatically by the error response, > then the ROLLBACK command will fail with an error, but no harm is > caused by this. The "errors listed above" here refer to errors which don't automatically roll back the transaction. Irritatingly, the error used in the test case (invalid deferred fk constraints) is not listed there. The manual states this about it[2]: > Deferred foreign key constraints are not checked until the > transaction tries to COMMIT. For as long as the user has an open > transaction, the database is allowed to exist in a state that > violates any number of deferred foreign key constraints. However, > COMMIT will fail as long as foreign key constraints remain in > violation. Which hints at the fact that the transaction is not rolled back automatically. Now since the WebSQL API doesn't provide a way to gracefully recover from this situation (i.e. the transaction object is not passed into the error callback), always rolling back seems to be the most reasonable behavior in the spirit of the spec. 1: https://www.sqlite.org/lang_transaction.html#response_to_errors_within_a_transaction 2: https://www.sqlite.org/foreignkeys.html#fk_deferred

view details

push time in 20 days

delete branch bevuta/node-websql

delete branch : fix-commit-error-handling-salus-port

delete time in 21 days

create barnchbevuta/node-websql

branch : fix-commit-error-handling-salus-port

created branch time in 21 days

issue commentnolanlawson/node-websql

Transactions auto-close when queuing microtasks between executeSql() calls

@trajano Pretty sure, yes. IIRC the patch that Expo originally vendored node-websql for has since been upstreamed. We're using it with https://github.com/craftzdog/react-native-sqlite-2 rather than Expo's sqlite module which definitely works.

trajano

comment created time in 22 days

PR opened nolanlawson/node-websql

Explicitly roll back transaction on failed commit

This is a follow-up for https://github.com/nolanlawson/node-websql/pull/44 which turned out to be incomplete: SQLite doesn't always automatically roll back transactions when commit fails. The patch expands the respective test case to demonstrate this. Without the fix, the last assertion would fail since the transaction that errored out on commit before would still be active and silently re-used by the next transaction, which would then end up seeing its temporary (and inconsistent) state.

The patch is based on the following recommendation from the manual[1]:

It is recommended that applications respond to the errors listed above by explicitly issuing a ROLLBACK command. If the transaction has already been rolled back automatically by the error response, then the ROLLBACK command will fail with an error, but no harm is caused by this.

The "errors listed above" here refer to errors which don't automatically roll back the transaction. Irritatingly, the error used in the test case (invalid deferred fk constraints) is not listed there. The manual states this about it[2]:

Deferred foreign key constraints are not checked until the transaction tries to COMMIT. For as long as the user has an open transaction, the database is allowed to exist in a state that violates any number of deferred foreign key constraints. However, COMMIT will fail as long as foreign key constraints remain in violation.

Which hints at the fact that the transaction is not rolled back automatically. Now since the WebSQL API doesn't provide a way to gracefully recover from this situation (i.e. the transaction object is not passed into the error callback), always rolling back seems to be the most reasonable behavior in the spirit of the spec.

1: https://www.sqlite.org/lang_transaction.html#response_to_errors_within_a_transaction 2: https://www.sqlite.org/foreignkeys.html#fk_deferred

+49 -12

0 comment

2 changed files

pr created time in 23 days

push eventbevuta/node-websql

Moritz Heidkamp

commit sha 3fea680b25023c867d936a17f7cbf57f14fbf56d

Explicitly roll back transaction on failed commit This is a follow-up for https://github.com/nolanlawson/node-websql/pull/44 which turned out to be incomplete: SQLite doesn't always automatically roll back transactions when commit fails. The patch expands the respective test case to demonstrate this. Without the fix, the last assertion would fail since the transaction that errored out on commit before would still be active and silently re-used by the next transaction, which would then end up seeing its temporary (and inconsistent) state. The patch is based on the following recommendation from the manual[1]: > It is recommended that applications respond to the errors listed > above by explicitly issuing a ROLLBACK command. If the transaction > has already been rolled back automatically by the error response, > then the ROLLBACK command will fail with an error, but no harm is > caused by this. The "errors listed above" here refer to errors which don't automatically roll back the transaction. Irritatingly, the error used in the test case (invalid deferred fk constraints) is not listed there. The manual states this about it[2]: > Deferred foreign key constraints are not checked until the > transaction tries to COMMIT. For as long as the user has an open > transaction, the database is allowed to exist in a state that > violates any number of deferred foreign key constraints. However, > COMMIT will fail as long as foreign key constraints remain in > violation. Which hints at the fact that the transaction is not rolled back automatically. Now since the WebSQL API doesn't provide a way to gracefully recover from this situation (i.e. the transaction object is not passed into the error callback), always rolling back seems to be the most reasonable behavior in the spirit of the spec. 1: https://www.sqlite.org/lang_transaction.html#response_to_errors_within_a_transaction 2: https://www.sqlite.org/foreignkeys.html#fk_deferred

view details

push time in 23 days

push eventbevuta/node-websql

Moritz Heidkamp

commit sha 46afde19afad5506a37eafbd4ca7f11f5fb517b4

Explicitly roll back transaction on failed commit This is a follow-up for https://github.com/nolanlawson/node-websql/pull/44 which turned out to be incomplete: SQLite doesn't always automatically roll back transactions when commit fails. The patch expands the respective test case to demonstrate this. Without the fix, the last assertion would fail since the transaction that errored out on commit before would still be active and silently re-used by the next transaction, which would then end up seeing its temporary (and inconsistent) state. The patch is based on the following recommendation from the manual[1]: > It is recommended that applications respond to the errors listed > above by explicitly issuing a ROLLBACK command. If the transaction > has already been rolled back automatically by the error response, > then the ROLLBACK command will fail with an error, but no harm is > caused by this. The "errors listed above" here refer to errors which don't automatically roll back the transaction. Irritatingly, the error used in the test case (invalid deferred fk constraints) is not listed there. The manual states this about it[2]: > Deferred foreign key constraints are not checked until the > transaction tries to COMMIT. For as long as the user has an open > transaction, the database is allowed to exist in a state that > violates any number of deferred foreign key constraints. However, > COMMIT will fail as long as foreign key constraints remain in > violation. Which hints at the fact that the transaction is not rolled back automatically. Now since the WebSQL API doesn't provide a way to gracefully recover from this situation (i.e. the transaction object is not passed into the error callback), always rolling back seems to be the most reasonable behavior in the spirit of the spec. 1: https://www.sqlite.org/lang_transaction.html#response_to_errors_within_a_transaction 2: https://www.sqlite.org/foreignkeys.html#fk_deferred

view details

push time in 23 days

push eventbevuta/node-websql

Moritz Heidkamp

commit sha 540823c66c47d69b9246152f4df13e0f1483bd00

Explicitly roll back transaction on failed commit This is a follow-up for https://github.com/nolanlawson/node-websql/pull/44 which turned out to be incomplete: SQLite doesn't always automatically roll back transactions when commit fails. The patch expands the respective test case to demonstrate this. Without the fix, the last assertion would fail since the transaction that errored out on commit before would still be active and silently re-used by the next transaction, which would then end up seeing its temporary (and inconsistent) state. The patch is based on the following recommendation from the manual[1]: > It is recommended that applications respond to the errors listed > above by explicitly issuing a ROLLBACK command. If the transaction > has already been rolled back automatically by the error response, > then the ROLLBACK command will fail with an error, but no harm is > caused by this. The "errors listed above" here refer to errors which don't automatically roll back the transaction. Irritatingly, the error used in the test case (invalid deferred fk constraints) is not listed there. The manual states this about it[2]: > Deferred foreign key constraints are not checked until the > transaction tries to COMMIT. For as long as the user has an open > transaction, the database is allowed to exist in a state that > violates any number of deferred foreign key constraints. However, > COMMIT will fail as long as foreign key constraints remain in > violation. Which hints at the fact that the transaction is not rolled back automatically. Now since the WebSQL API doesn't provide a way to gracefully recover from this situation (i.e. the transaction object is not passed into the error callback), always rolling back seems to be the most reasonable behavior in the spirit of the spec. 1: https://www.sqlite.org/lang_transaction.html#response_to_errors_within_a_transaction 2: https://www.sqlite.org/foreignkeys.html#fk_deferred

view details

push time in 23 days

create barnchbevuta/node-websql

branch : fix-commit-error-handling

created branch time in 23 days

issue commentnolanlawson/node-websql

Transactions auto-close when queuing microtasks between executeSql() calls

FWIW, we were able to make this work by patching in a way to disable the auto-commit mechanism and adding explicit commit and rollback methods to WebSQLTransaction. We also extended the test suite accordingly. @nolanlawson As far as I understand you wouldn't be interested in a PR to that effect, right?

trajano

comment created time in 23 days

startedactivej/activej

started time in 2 months

issue openedclj-commons/manifold

d/alt docstring wrong?

The docstring for d/alt says:

Values appearing earlier in the input are preferred.

I understand this to mean that the given arguments are checked from left to right (as in core.async/alt! with :priority true). However, the implementation actually randomizes the order. From https://github.com/clj-commons/manifold/pull/102 I gather that this was changed during review but the docstring wasn't adjusted accordingly.

created time in 2 months