profile
viewpoint

paul/cloudwatch_scheduler 17

Use Cloudwatch Events to kick off recurring SQS ActiveJob jobs

paul/dm-tokyotyrant-adapter 15

An adapter for the TokyoTyrant network interface on the TokyoCabinet database engine

paul/datapathy 14

A stupid-simple ORM that provides the minimum neccessary api, and stays out of your way

paul/dm-s3-adapter 6

An adapter for using Amazon's S3 with DataMapper

paul/dm-lite 4

A simplified DataMapper for me to try out ideas

paul/blog.theamazingrando.com 3

Posts for my blog

paul/dm-adapters 3

Some experimental http-ish adapters for datamapper

paul/dm-echo-adapter 3

A DataMapper Adapter that wraps another adapter, and prints the args and return values to STDOUT

paul/blog 2

My Blog

pull request commentHydraCG/Specifications

Allow returns/expects to be expressed in terms of a media type

I've changed the approach with this issue this time. This time I've dropped the resource specification and I didn't got towards request specification neither. All I did was a slight modification of returnsHeader and expectsHeader so it is possible to provide possible header values. This way it would be possible to describe an expected resource to be any of provided Content-Type header values for upload or possible Content-Type serializations of the resource.

alien-mcl

comment created time in 2 days

issue openedhttprb/http

Ruby 3 Ractor support?

Ruby 3 support Ractor to archive concurrency, Ractor can not access instance variables of classes/modules.

When I want to use Ractor with http, I found http is using access instance variables of classes, for example:

require 'http'

ractors = []
url = 'http://httpbin.org/ip'
10.times do
  ractors << Ractor.new(url) { |u| HTTP.get u }
end
ractors.map(&:take)

This snippet will raise error http-4.4.1/lib/http/chainable.rb:221:indefault_options': can not access instance variables of classes/modules from non-main Ractors (Ractor::IsolationError), becausehttpusingdefault_options` as class instance variable.

Is it possible to make it support Ractor?

created time in 2 days

issue openeddry-rb/dry-transaction

Ruby 3.0.0 - ArgumentError: wrong number of arguments (given 2, expected 1)

Describe the bug

I'm trying to use dry-transaction with Ruby 3.0.0. I tried to use examples from docs:

require "dry/transaction"

class CreateUser
  include Dry::Transaction

  step :validate
  step :create

  private

  def validate(input)
    # returns Success(valid_data) or Failure(validation)
  end

  def create(input)
    # returns Success(user)
  end
end

When I try to initialize CreateUser I receive the following error:

[20] pry(main)> CreateUser.new
ArgumentError: wrong number of arguments (given 2, expected 1)
from /Users/mateuszurbanski/.gem/ruby/3.0.0/gems/dry-transaction-0.13.0/lib/dry/transaction/instance_methods.rb:84:in `resolve_operation'

created time in 2 days

release dry-rb/dry-struct

v1.4.0

released time in 3 days

created tagdry-rb/dry-struct

tagv1.4.0

Typed struct and value objects

created time in 3 days

fork ahoward/ngrok-tunnel

Ngrok-tunnel gem is a simple ruby wrapper for ngrok http://ngrok.com

fork in 3 days

push eventdry-rb/dry-struct

dry-bot

commit sha 509e5d780d6d8e9a4338f435087a736bcc7170e3

[devtools] sync

view details

push time in 3 days

push eventdry-rb/dry-struct

Nikita Shilnikov

commit sha 364303bd9a848f30ba38d0e8aeea599cbe26cc57

Set release date

view details

push time in 3 days

fork ahoward/NoHarm

Do No Harm software license - A licence for using software for good

fork in 4 days

push eventHydraCG/Specifications

Travis

commit sha 709bd0c62333bdd2773ad2646c64b6e5388bafd8

Update to efdd52a733eb4bb3585669df6a148f28590e9f0b.

view details

push time in 5 days

push eventHydraCG/Specifications

alien-mcl

commit sha 044bc02e74a022511e602e8a00a644aa7af065dd

Added stanrad JSON-LD context to RFC-7807 to Hydra vocabulary hoping to resolve #178.

view details

alien-mcl

commit sha 2d3817757b923f798f5681cebaa2c7ff4de64bf3

Merge branch 'master' of https://github.com/HydraCG/Specifications into issue/178_Make_hydra_error_compatible_with_RFC_7807

view details

alien-mcl

commit sha 1283cb906610156a6dd3485c4328e184a395c48d

Few editorial changes after code review

view details

alien-mcl

commit sha 3c867bc549860a49a640abc3aba8cd82b02f57d7

Remapped error context to more generic terms

view details

alien-mcl

commit sha 7afdef955cfc2496b2b19f7dae575269719b172c

Mapped status back to hydra:statusCode and few other changes in the spec.

view details

alien-mcl

commit sha e325d5f74bb21e02ab630572a4aa01527a4e9326

Reworded few more sentences

view details

alien-mcl

commit sha 3533bfb30425acdba5113debfab0cf288b51e9db

Fix for JSON-LD 1.0

view details

Karol Szczepański

commit sha efdd52a733eb4bb3585669df6a148f28590e9f0b

Merge pull request #218 from alien-mcl/issue/178_Make_hydra_error_compatible_with_RFC_7807 #178 Make hydra:error compatible with RFC 7807

view details

push time in 5 days

issue closedHydraCG/Specifications

Make hydra:error compatible with RFC 7807

As discussed in #39, it would be useful if hydra:error responses were compatible with RFC 7807. Defining a @context for application/problem+json that defines "instance": "@id" should achieve what @RubenVerborgh is after, I believe.

closed time in 5 days

asbjornu

PR merged HydraCG/Specifications

#178 Make hydra:error compatible with RFC 7807

Summary

Changes are covering new standard JSON-LD context that maps RFC-7807 specific JSON properties to Hydra vocabulary.

More details

This pull-request should resolve issue #718 by introducing two new things:

  • standard JSON-LD context that maps RFC-7807 JSON properties to Hydra core vocabulary
  • errorCode term that is required to make that output of that standard JSON-LD context a hydra:Error resource

It may still valid to drop the second change - the only drawback would be the resulting resource would've been a hydra:Status which makes the hydra:Error itself somehow obsolete (which is not that bad after all).

+53 -2

2 comments

3 changed files

alien-mcl

pr closed time in 5 days

issue commentHydraCG/Specifications

State more explicitely that hydra:return etc. are just hints

I think this is covered in the spec now (section 4.2 Documenting a Web API):

Keep in mind that operations specified in an ApiDocumentation may fail at runtime as either resources or the ApiDocumentation itself have changed since they have been retrieved. Also operation details like returns or possibleStatus may vary at runtime, which means client SHOULD verify received payloads at runtime.

How do you feel about it?

lanthaler

comment created time in 5 days

pull request commenthttprb/http

resolve #642 - Add Pattern Matching

Regarding CodeClimate I can reduce one of the methods out, but the other class not as easily. Granted my opinion is 20 methods / class is a bit arbitrary, but will defer to standards of the repo.

baweaver

comment created time in 5 days

pull request commenthttprb/http

resolve #642 - Add Pattern Matching

It appears that Ruby core uses a similar hack to get around old versions:

https://github.com/ruby/ruby/commit/f9696ca6cbfe827b7ce7199e511fa7431f9333b1

baweaver

comment created time in 5 days

pull request commenthttprb/http

resolve #642 - Add Pattern Matching

The only way I can get around "invalid" syntax that doesn't exist until 2.7 that I can think of or get to work is unfortunately very hacky:

if RUBY_VERSION >= '2.7'
  eval <<~RUBY
    [1,2,3] in [1, *]
  RUBY
end

Would love to implement this for newer versions of Ruby but can't think of anything better than that hack for the moment

baweaver

comment created time in 5 days

Pull request review commenthttprb/http

resolve #642 - Add Pattern Matching

 def coerce(object)      private +    # Underscored version of HTTP Header keys for+    # Pattern Matching+    #+    # @return [Hash[String, Symbol]]+    def underscored_keys_mapping+      Hash[keys.map { |k| [k, k.tr('A-Z-', 'a-z_').to_sym] }]+    end

This may be unnecessary if an alternate method is available that does the same.

baweaver

comment created time in 5 days

pull request commenthttprb/http

resolve #642 - Add Pattern Matching

It appears that conditional gating for Ruby 2.7+ isn't isolating these specs. I'll have to follow up with an additional commit some time tomorrow when I have time to address that.

baweaver

comment created time in 5 days

PR opened httprb/http

resolve #642 - Add Pattern Matching

Resolves feature request #642 requesting the addition of Pattern Matching hooks for Ruby 2.7+ by introducing to_h, deconstruct, and deconstruct_keys to core classes.

This change also addresses spec changes by gating pattern matching specs on Ruby 2.7+ to prevent failures in older versions. All specs have also been given a pattern matching spec matching their implementation to demonstrate potential usages.

While demonstrational usages could dive into nested classes that are in HTTP this was avoided to keep tests isolated from eachother.

+678 -0

0 comment

25 changed files

pr created time in 5 days

issue openedhttprb/http

[Feature] Pattern Matching extensions

I'd like to propose adding pattern matching to some of the core classes of http, primarily deconstruct_keys, to allow for matching against things like Responses and Requests.

Consider:

response in {
  status: 200..299,
  body: /Header I want/
}

case response
in { status: 200..299, body: } then Success(body)
in { status: 300.., body: } then Failure(body)
else Failure('unknown')
end

This is just a theoretical example and may not be 100% accurate to the API, but I wanted to run things by the core team before implementing this as it ends up being a decent amount of additional code.

It should be noted that adding the interfaces (deconstruct and deconstruct_keys) will be backward compatible, but testing it with pattern matching will not be.

created time in 5 days

issue commentHydraCG/Specifications

Describe how hydra:apiDocumentation can be used to associate information to concepts defined in other vocabularies

I think the idea is the payload may contain concepts (i.e. returned resource is of some type), but there is no more information regarding that type and client should consult the API documentation to possibly discover more. Currently there is no requirement to use API documentation at all except the part of the spec I've pointed

lanthaler

comment created time in 6 days

issue commenthttprb/http

Header key with underscore being converted to a dash

Works perfectly! Thank you!

kroe761

comment created time in 6 days

issue commenthttprb/http

Header key with underscore being converted to a dash

There's a monkeypatch here:

https://github.com/httprb/http/issues/337#issuecomment-550412661

Otherwise #576 is a more permanent but unreleased fix.

kroe761

comment created time in 6 days

issue commenthttprb/http

Header key with underscore being converted to a dash

I'm completely confused. Are you saying that my code should have resulted in 'app_token' in the request? If not, what should I have done differently to fix my code?

kroe761

comment created time in 6 days

issue closedhttprb/http

Header key with underscore being converted to a dash

I am trying to create a POST request that contains the key app_token in the header. My code

HTTP.headers({:app_token => "some-guid-token"})
         .post("https://service.mycompany.net/",
                     json: { key: "value"})

However, when I make my call, I am notified that app_token was not proved. Looking at the req in HTTP::Client.request, I see that the header has been converted to App-Token. This is causing my request to fail. Is there a workaround? We are using version 4.4.1.

closed time in 6 days

kroe761

issue commenthttprb/http

Header key with underscore being converted to a dash

Dup of: #337, #576

kroe761

comment created time in 6 days

issue openedhttprb/http

Header key with underscore being converted to a dash

I am trying to create a POST request that contains the key app_token in the header. My code

HTTP.headers({:app_token => "some-guid-token"})
         .post("https://service.mycompany.net/",
                     json: { key: "value"})

However, when I make my call, I am notified that app_token was not proved. Looking at the req in HTTP::Client.request, I see that the header has been converted to App-Token. This is causing my request to fail. Is there a workaround? We are using version 4.4.1.

created time in 6 days

push eventdry-rb/dry-struct

dry-bot

commit sha 8ebc96fd829365ba30abcafd93d3d1ccbfa87dc9

[devtools] sync

view details

push time in 6 days

push eventdry-rb/dry-struct

Nikita Shilnikov

commit sha 051f85c0fc591d030bdbe62eaceea4ea514a6217

Update changelog.yml

view details

push time in 6 days

more