Re: [Rails-core] Native support for OpenTracing

Awesome! Are you working on other OC integrations? On Tue, 19 Mar 2019 at 16.41, Jeremy Daer wrote: > And merged (targeting Rails 6.0.0.beta4) 😊 > > On Fri, Oct 26, 2018 at 7:56 PM Jeremy Daer wrote: > >> Nice! 👍 >> >> On Fri, Oct 26, 2018 at 2:51 AM 'D

Re: [Rails-core] Native support for OpenTracing

First PR is up: https://github.com/rails/rails/pull/34305 On Tue, Oct 23, 2018 at 4:33 AM Jeremy Daer wrote: > On Mon, Oct 22, 2018 at 9:56 AM 'Daniel Schierbeck' via Ruby on Rails: > Core wrote: > >> On Fri, Oct 19, 2018 at 10:15 PM Daniel Azuma wrote: &g

Re: [Rails-core] Native support for OpenTracing

On Fri, Oct 19, 2018 at 10:15 PM Daniel Azuma wrote: > Hi folks, > > Thought I'd jump in here as the engineer who has done most of the > implementation on the opencensus gem so far. Ruby support in OpenCensus is > currently a bit behind other languages—we don't yet have support for stats, > z-pag

Re: [Rails-core] Native support for OpenTracing

On Thu, Oct 18, 2018 at 9:24 PM Jeremy Daer wrote: > On Thu, Oct 18, 2018 at 2:52 AM 'Daniel Schierbeck' via Ruby on Rails: > Core wrote: > >> Looks like OpenCensus already has support for development mode UIs, >> currently only for Java and Go though: >>

Re: [Rails-core] Native support for OpenTracing

On Thu, Oct 18, 2018 at 11:26 AM Daniel Schierbeck wrote: > On Wed, Oct 17, 2018 at 7:26 PM Jeremy Daer wrote: > >> Hey Daniel, >> >> Absolutely! We're looking at OpenCensus (https://opencensus.io >> <https://opencensus.io>) >> integration

Re: [Rails-core] Native support for OpenTracing

r instrumentation. However, I keep running into ad-hoc instrumentation being brittle, which is why I'm interested in first-class support. I think the only sustainable path forward is that gems natively support some form of tracing, either through AS::N (which would need to be extracted) o

[Rails-core] Native support for OpenTracing

to hear your thoughts on this. Cheers, Daniel Schierbeck -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscr...@googl

Re: [Rails-core] Changing the way Rails renders views

this group, send email to rubyonrails-core@googlegroups.com. > Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Med venlig hilsen Daniel Schierbeck -- You received this messa

Re: [Rails-core] Changing the way Rails renders views

; >> I think you'll find that handling references to local & instance vars is >> the fly in the ointment. Method-missing doesn't cut it since it's very low >> precedence compared to a real local var. >> >> >> On Wed, May 29, 2013 at 7:41 AM, Daniel

Re: [Rails-core] Changing the way Rails renders views

mp; instance vars is > the fly in the ointment. Method-missing doesn't cut it since it's very low > precedence compared to a real local var. > > > On Wed, May 29, 2013 at 7:41 AM, Daniel Schierbeck > > > wrote: > >> Hi guys, >> >> I think

[Rails-core] Changing the way Rails renders views

Hi guys, I think this may be too daunting a task, but I'd like to propose a change to the way views are rendered in Rails. Currently, a template handler converts a template to a string containing Ruby code, which then gets evaluated in a context that has certain variables present. The code is

Re: [Rails-core] Hacking on performance?

Hi Jay, I think perusing Django's API would be a good first start. They handle things quite differently from Rack. Here's a small gist of a sample API: https://gist.github.com/1185778 Cheers, Daniel On 27/09/2011, at 01.18, Jay Levitt wrote: > @tenderlove talked at RailsConf about this being

Re: [Rails-core] Re: Performance of "delegate"

On Mon, Aug 29, 2011 at 6:34 PM, matthewrudyjac...@gmail.com wrote: > On Monday, August 29, 2011 11:59:56 AM UTC+1, Daniel Schierbeck wrote: >> >> 3. `*args` contraction (we must build an array that is just GC'd) >> 4. Splatting the args back to the `__send__` >&g

[Rails-core] Re: Performance of "delegate"

Okay, I've added a pull request targeting 3-1-stable: https://github.com/rails/rails/pull/2736 Please have a look. Cheers, Daniel Schierbeck -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group

Re: [Rails-core] Re: Performance of "delegate"

The deprecation stuff is happening at https://github.com/dasch/rails/tree/delegate-deprecation Comments are welcome - the code can be tricky. On Mon, Aug 29, 2011 at 3:34 PM, Daniel Schierbeck wrote: > I've begun work on the patch against 3-1-stable, but it's not trivial. >

Re: [Rails-core] Re: Performance of "delegate"

I've begun work on the patch against 3-1-stable, but it's not trivial. For one, simply evaling target.method=(*args, &block) throws a syntax error. I'll keep working on it. On Mon, Aug 29, 2011 at 2:42 PM, Jon Leighton wrote: > On Mon, 2011-08-29 at 14:16 +0200, D

Re: [Rails-core] Re: Performance of "delegate"

aniel Schierbeck On Mon, Aug 29, 2011 at 2:42 PM, Jon Leighton wrote: > On Mon, 2011-08-29 at 14:16 +0200, Daniel Schierbeck wrote: >> @Jon: I could change the implementation to check `args.length` and >> raise ArgumentError if the result is greater than 1. But wouldn't it >&g

Re: [Rails-core] Re: Performance of "delegate"

@Jon: I could change the implementation to check `args.length` and raise ArgumentError if the result is greater than 1. But wouldn't it suffice to simply define the writer methods with only one argument? @Xavier: I think users perceive `delegate` as a shorthand for: def foo @target.foo en

[Rails-core] Re: Performance of "delegate"

@jonleighton thanks for chiming in. I really believe that the basic constructs provided by ActiveSupport should uphold the rules of OOP - if you need to delegate to a private method nothing is stopping you from going the manual route. I seem to have fixed the performance issues, although I complet

[Rails-core] Performance of "delegate"

ckwards compatibility, assuming people actually use `delegate` for such a nefarious purpose. I hope people will be interested in discussing this topic, as I think `delegate` is an important part of the "plumbing" of Rails, and deserves all the optimization we can muster. This is especial

[Rails-core] Tab-completion in Rails 3

I'd like to see tab completion introduced for the commands -- while the single-character aliases are nice, tab-completing is in my muscle memory, as I suspect it is in many others, too. I've written a very rudimentary completion script which merely completes the command name in Bash: http://gist.g

Re: [Rails-core] Default JavaScript library

I think Rails 3.1 would be the appropriate target. Daniel -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails

Re: [Rails-core] Default JavaScript library

I personally disagree. With a limit backwards compatibility, current Prototype users could have a simple command line switch to regain their old default. Furthermore, I feel that the default JS library is the least coupled piece of Rails 3 -- changing it is rather unobtrusive, as long as bindings a

Re: [Rails-core] Default JavaScript library

Xavier, I for one never use jRails -- in fact, neither do most of the rails devs i know. We do, however, use jQuery. The JavaScript helpers in Rails 2.3 were rather ugly, from a jQuery point of view, which probably explains why not that many people felt like using jRails. Daniel On Thu, May 27,

Re: [Rails-core] Re: Default JavaScript library

between different components becomes vast. Unless this is something someone wants to maintain, I suggest removing the non-default bindings from the Rails repo and putting it in a plugin. Cheers, Daniel Schierbeck On Tue, May 25, 2010 at 5:28 PM, Paul Sponagl wrote: > -/+1 > > yes -

[Rails-core] Default JavaScript library

it's still the best choice. Best regards, Daniel Schierbeck -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-c...@googlegroups.com. To unsubscribe from th

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

I can see that -- it's sad that we have this great functionality built right into Ruby, yet we're unable to take advantage of it. Well, nothing to do about that. Cheers, Daniel Schierbeck On Mon, Apr 5, 2010 at 1:23 AM, Michael Koziarski wrote: >> That seems reasonable. Perh

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

That seems reasonable. Perhaps the tainting could be moved higher up the hierarchy, the ActiveRecord itself? All getters would then return tainted strings. Would that not suffice? Cheers, Daniel Schierbeck On Sun, Apr 4, 2010 at 5:41 PM, Mike Gunderloy wrote: > NzKoz's original note o

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

That's a valid concern, but I think trying it out is the best approach -- then we'll se if any problems arise. Having a #html_safe wrapper around the tainting also yields some flexibility. Cheers, Daniel Schierbeck On Sun, Apr 4, 2010 at 5:26 PM, Jeremy Kemper wrote: > On Sun, Apr

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

erful) within Ruby itself. Should I cook up a patch for this? Cheers, Daniel Schierbeck On Sun, Apr 4, 2010 at 4:52 PM, Jeremy Kemper wrote: > On Sun, Apr 4, 2010 at 7:37 AM, Daniel Schierbeck > wrote: >> On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper wrote: >>> On S

Re: [Rails-core] XSS in Rails 3: "raw(...)" for EVERY SINGLE FIXED(!) STRING??!!

Just out of curiosity, couldn't you use String#tainted? to check whether the string was a literal or not? Cheers, Daniel Schierbeck On Sun, Apr 4, 2010 at 3:54 PM, Jeremy Kemper wrote: > On Sun, Apr 4, 2010 at 4:51 AM, michael.hasenst...@googlemail.com > wrote: >> Hi, >>

[Rails-core] Re: "Only get, put, and delete requests are allowed" on an XML request... why??

Hi, First of all, this is the "core" group, meant for discussions on the development and direction of Rails itself, not a help forum -- there's a dedicated group for that purpose. Second, you should issue your POST to "/things", not "/things/1". Cheers, Daniel On Thu, Sep 17, 2009 at 3:17 PM,

[Rails-core] Re: Getting version 3

nd pulling from that branch is implicitly done with the tracked remote branch, without needing specification; e.g. git checkout -tb foo some-remote/bar git commit -am "Implement awesomeness" git push # pushes to some-remote/bar Best regards, Daniel Schierbeck On Sat, Ma

[Rails-core] Re: Should Inflector do consider accented vowels while underscoring?

Perhaps an incremental solution would be better -- add support for Central European characters first and see if there's a need for a more elaborate solution. Only thing I have against this is that I believe all code should be written in English (I'm Danish myself). Cheers, Daniel On Sat, Jan 3,

[Rails-core] Re: Git repos in vendor/gems

I'm currently implementing some infrastructure for managing plugins, but if could easily support this, too. The relevant parts are in railties/lib/plugin_manager. On Nov 25, 11:27 am, Cristi Balan <[EMAIL PROTECTED]> wrote: > On 25 Nov 2008, at

[Rails-core] PluginManager: An extensible plugin management API for Rails

cleanup in .gitmodules). Subversion externals is planned. The progress will be tracked in Lighthouse[1], and the code is residing in a GitHub branch[2]. Again, all comments are welcome. Cheers, Daniel Schierbeck [1] <http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/ tickets/1436>

[Rails-core] Re: What is the documentation strategy?

Okay, i guess that's as good as it can get then -- there will be links to that from rubyonrails.org, hopefully? Cheers, Daniel On Oct 31, 3:37 pm, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > On Fri, Oct 31, 2008 at 3:03 PM, Daniel Schierbeck > > <[EMAIL

[Rails-core] Re: What is the documentation strategy?

eremy McAnally" <[EMAIL PROTECTED]> wrote: > Such ashttp://guides.rails.info?  That's all part of the docrails stuff. > > Anything other than contributing to those would be completely > redundant, in my opinion. :P > > --Jeremy > > On Thu, Oct 30, 2008 at

[Rails-core] Re: What is the documentation strategy?

t; <[EMAIL PROTECTED]> wrote: > On Thu, Oct 30, 2008 at 12:52 PM, Daniel Schierbeck > > > > <[EMAIL PROTECTED]> wrote: > > > Hi everybody > > > The recent surge in documentation effort, spurred mainly by the Rails > > Guides project, has cause

[Rails-core] What is the documentation strategy?

depth manual, akin to the ones offered by PHP and Django. The guides provide a great foundation for such a manual, essentially being a chapter each (although editing and streamlining would be necessary.) Is there a strategy on this area? Should there be? Best regards, Daniel Schie

[Rails-core] Re: Request for Review: Make it possible to prefix delegate methods

eter-and- forwardable.html> Best regards Daniel Schierbeck On Oct 12, 7:31 pm, "Andrew Kaspick" <[EMAIL PROTECTED]> wrote: > Why wouldn't you just do obj.client.name and obj.client.address if > you're looking to keep some context in the names? > > On Sa

[Rails-core] Request for Review: Make it possible to prefix delegate methods

I've submitted a patch to Lighthouse which makes it possible to prefix delegation methods, i.e.: delegate :name, :address, :to => :client, :prefix => true Which would create the methods #client_name and #client_address. It's also possible to give a custom prefix, e.g. :customer. Could I get s