profile
viewpoint
Xavier Noria fxn Freelance Barcelona https://hashref.com Everlasting student · Rails Core · Ruby Hero · Freelance · Life lover

FooBarWidget/mizuho 72

Documentation formatting tool. Converts Asciidoc input into nicely formatted HTML.

fxn/math-with-regexps 43

Math with regexps for fun

fxn/monochrome-theme.el 29

Monochrome theme for Emacs 24

fxn/sudoku 23

A fairly simple Sudoku solver written in C

barcelonapm/Acme-PM-Barcelona 10

Talks and projects by Barcelona.pm

fxn/algorithm-combinatorics 5

Efficient generation of combinatorial sequences

fxn/spinal-top 5

top(1) for when your server needs that extra push over the cliff

fxn/net-fluidinfo 4

Perl interface to Fluidinfo

push eventrails/rails

Xavier Noria

commit sha b4ddcb266e7c142c9b4dd0688b149412ed008374

Revise docs/comments for the debug gem

view details

push time in 31 minutes

push eventrails/rails

Xavier Noria

commit sha e6b286f9baca7c6c97c90288acdd563c40d5103f

Revise docs/comments for the debug gem

view details

push time in 31 minutes

create barnchrails/rails

branch : iterate-debug-warning

created branch time in 43 minutes

issue commentdoorkeeper-gem/doorkeeper

Unable to use a custom STI OAuthApplication class

This smells like a stale class object is alive.

Which version of Rails are you using? Seems to be using the classic autoloader, right? Is the application autoloading anything during initialization?

hmcfletch

comment created time in 16 hours

issue closedfxn/vim-monochrome

background=light

In the era of dark modes I'm one of those crazy folks that do:

  set background=light

and use a white/white-ish terminal.

Unfortunately this great colorscheme is not quite useable on a light background.

Would it be possible to have it support light mode as well?

closed time in 16 hours

lloeki

issue commentfxn/vim-monochrome

background=light

No, sorry, this is a dark theme (and I don't use Vim anymore).

lloeki

comment created time in 16 hours

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

@ko1 since the thread is long, let me highlight that full TP re-entracy is not strictly needed as far as this issue is concerned. It would suffice to honor existing TPs listening to the :class event. That is all Zeitwerk subscribes to.

fxn

comment created time in a day

push eventrails/rails

Xavier Noria

commit sha 5aeb7d1c4013cbf75aedcb9ea153f2fddcae6219

Document suggestions for debugging

view details

push time in a day

push eventrails/rails

Xavier Noria

commit sha ef7e3c46c4417167e7ac702471e537f4e8b9def8

Document suggestions for debugging

view details

push time in a day

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

Hey, just to be clear, that does not mean it would work for Zeitwerk, I don't know that a priori. Zeitwerk is based on a controlled descend in which it is able to monitor and keep track all it does in each level of depth.

Even if it was possible to have an equivalent library, I'd have to see how to ship both implementations. The metadata used to operated would be affected, sounds more fundamental than just swapping an adapter.

So, worth exploring, and that includes the possibility that the exploration concludes it is not a practical solution.

fxn

comment created time in 2 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

Another thing we suggested when we discussed this in Zeitwerk last year was for autoload to accept

This could be something interesting to explore. I believe it should unroll autoloads, not eager load. Let me explain.

Nowadays, these two examples work:

# hotel.rb
class Hotel
  include Pricing
end

# hotel/pricing.rb
module Hotel::Pricing
end
# hotel.rb
class Hotel
  def self.foo; end
end

# hotel/pricing.rb
module Hotel::Pricing
  Hotel.foo
end

If you load hotel/pricing.rb once Hotel is defined, the second example does not work. If you load hotel/pricing.rb after loading hotel.rb, the first example does not work.

I believe that enhanced autoload should basically embed what we are after: Executing code when Hotel is defined to define autoloads in the class/module object. The same we do today, only builtin/encapsulated.

fxn

comment created time in 2 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

Without having written anything, some things that come to mind off the top of my head:

  1. In order to be a substitute for TP, const_added should not be triggered for autoloads. That is not consistent with the constants API, because you'd have constants listed in #constants and for which const_defined? returns true that wouldn't have triggered the callback

  2. The fact that you would have a method dispatch all the way up to Object makes me suspect we'd need to workaround polymorphism.

  3. Performance has to be seen, since Zeitwerk only listens to class events, and only if there's an explicit namespace to monitor, otherwise the TP is disabled. This is way more strict.

  4. Other gems defining their own const_added that would cause other types of incompatibility.

However, I'd focus the discussion on TP. In my view, TP is broken and of little use due to its uncertainty. I believe the priority should be to address this. Otherwise, what is the point of having TP in the language at all?

fxn

comment created time in 2 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

Agreed @eregon. Intuitively, I am suspicious about whether const_added would end up being a good solution once you get into the details.

The contract of TP is broken. To me, this is the most important point. If you don't know if your callback is going to work because it depends on other TPs out of your control that may appear at run time, who can use TPs at all? They are not reliable!

A debugger should not have a priority on their usage. Indeed, a debugger should ideally transparently work with any program.

As I said, even if Zeitwerk is able to not use TP, it's just a side kick, the debugger is still not comparible with any program using TP.

fxn

comment created time in 2 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

Thanks @byroot. Let's see what's the feedback and I'll win some recovery days meanwhile too.

If, finally, nested TPs were totally out of the table, I am open to switch to that callback.

fxn

comment created time in 2 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

@brasic re GitHub monolith. Since there's going to be no solution in the short term either way, let me share that the current workaround is to eager load. Of course, far from ideal, but at least there's something.

fxn

comment created time in 2 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

@brasic Hey, I just had surgery and I am not in a good condition right now. Let me share quick thoughts, and may continue days later.

In principle I am not convinced about pursuing Module#const_added as a solution to this because the TP is an observer that you attach and over which you have full control. A callback is unique and global, so it needs cooperation between gems that have nothing to do with each other. Then, debug.rb would still not work with any other program that relies on TPs, the fundamental issue is still there.

To me, the natural way forward is to remove that limitation in TPs, if that is technically possible. If you define something to be called when an event happens, it should be called when that event happens.

fxn

comment created time in 2 days

push eventfxn/zeitwerk

Xavier Noria

commit sha 3987abc22bf46b2501ac8769e3956e4acdd7b33f

Revise docs about compatibility with debug.rb Thanks to @jhawthorn for reporting the docs were not correct.

view details

push time in 3 days

CommitCommentEvent

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

@st0012 it's an edge case, but if users should know about it in case it affects them, I personally believe the README should proactively warn about it. Maybe just a brief discrete section down the bottom. Zeitwerk has a section about debuggers too.

fxn

comment created time in 5 days

push eventfxn/zeitwerk

Xavier Noria

commit sha ecc3fc1706019c65c544c566b3e2ac2a287842a6

Edit link in README

view details

push time in 5 days

push eventfxn/zeitwerk

Xavier Noria

commit sha 5d3caffdca6f15c39dd2b545ee82e660c9e4033e

Revise docs about debuggers

view details

push time in 5 days

push eventrails/rails

Xavier Noria

commit sha 63d71786b222455ea6a1ab5e7a4f97bd368d9b93

More docs on having app in the autoload paths

view details

push time in 6 days

push eventrails/rails

Xavier Noria

commit sha 3f66f24f7f093158e6b75b8c7475ce76172aae7f

More docs about Zeitwerk compliance

view details

push time in 6 days

PullRequestReviewEvent

Pull request review commentrails/rails

Final touches deleting the classic autoloader

 def self.complete(_state)       # added in the hook are taken into account.       initializer :set_clear_dependencies_hook, group: :all do |app|         callback = lambda do+          # Order matters.

Heyyy!!! I was on a trip! It happens in the best families! 😀

fxn

comment created time in 7 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

Fantastic! Super that it was understood, please count on me for anything ❤️.

fxn

comment created time in 12 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

@st0012 Let me detail how that works when things load as expected:

  1. When you execute loader.setup, Zeitwerk does a first-level scan of the root directories.
  2. In that scan it finds foo.rb, and runs Object.autoload(:Foo, '/absolute/path/to/lib/foo.rb').
  3. It also notices that there is a directory called foo and enables the trace point.

All that happens in the line loader.setup.

Whe hit p Foo::Bar. This happens:

  1. Ruby performs a relative constant lookup for Foo. It sees the defined autoload and executes a require for /absolute/path/to/lib/foo.rb.
  2. Zeitwerk's thin wrapper around Kernel#require (source code) says: hey, I manage that file.
  3. The original Kernel#require is invoked, and that defines the Foo module.
  4. Therefore, right when module Foo has been interpreted, the tracepoint is triggered. We say, "Foo! That is a namespace I need to put autoloads for right now, before the rest of foo.rb is interpreted". The tracepoint callback scans the foo directory, and executes Foo.autoload(:Bar, '/absolute/path/to/lib/foo/bar.rb'). All done, continue.
  5. When the original Kernel#require returns all that has already happened, Zeitwerk does some housekeeping related to foo.rb.

At this point, we have only evaluated Foo in Foo::Bar. Now is the time for Bar:

  1. Since Foo returns a module, Ruby is able to do a constant lookup for Bar scoped by Foo.
  2. Ruby notices there is an autoload for it, and executes a require call for the configured file.
  3. The thin wrapper says again, hey, I manage that file.
  4. Delegates to the original Kernel#require.
  5. Performs housekeeping about /absolute/path/to/lib/foo/bar.rb.

Maybe that was super clear already, in that case please disregard all this :), but since there's something you consider to be odd, I wanted to link autoloading, the tracepoint, and the require calls to connect all the dots in case that helps.

fxn

comment created time in 12 days

issue commentruby/debug

The console prevents Zeitwerk from autoloading certain constants

@st0012 Guess I need to know more about the debugger to understand why is that one puzzling. Why is that different from your example "Execute with debugger but without any stepping"?

fxn

comment created time in 12 days

issue commentrails/rails

rails 6 lib folder doesn't work

@jeromedalbert that's right.

Please note that you should also ignore subdirectories that are not meant to be namespaces. For example:

Rails.autoloaders.main.ignore('lib/tasks', 'lib/assets')

Otherwise, Zeitwerk would define Tasks constant, but that is not your intention (and could potentially conflict with a genuine Tasks constant).

silva96

comment created time in 12 days

issue commentfxn/zeitwerk

Zeitwork hack on require method, which cause issue.

Haha

zw963

comment created time in 13 days

more