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

shichuan/javascript-patterns 9124

JavaScript Patterns

shichuan/bpbs 17

just an experiment for people who try to combine boilerplate with bootstrap

shichuan/soundofhtml5 9

Sound of HTML5 - Visual Experiments of HTML5 Audio

shichuan/todomvc 8

MV* Todo apps for Backbone.js, JavaScriptMVC, Ember.js, Dojo, Spine.js, YUILibrary, Knockout.js and more

shichuan/jquery-back-to-top 7

A jQuery plugin which displays a 'back to top' tag when scrolling down the page

shichuan/omniauth-kaixin 3

omniauth for kaixin001 (working!)

shichuan/jQuery-Preload-CSS-Images 2

A solution that automates the age-old task of preloading images in web applications.

shichuan/social-share-button 2

Helper for add social share feature in your Rails app. Twitter, Facebook, Weibo, Douban, QQ ...

shichuan/gemfile 1

a bad ass collection of Ruby gems for starting a project

shichuan/omniauth-douban 1

omniauth for douban.com (working!)

Pull request review commentcapistrano/capistrano

Allow access to SCM::Plugin instance from deploy scripts

 def install(plugin, load_hooks: true, load_immediately: false)             plugin.set_defaults           end         end+        @scm_plugin = plugin if provides_scm?(plugin)+        plugin       end +      attr_reader :scm_plugin

Hm. Looking at this some more I'm inclined to ask how common and supported a use case it is to use multiple repository types.

While this may in fact be possible, it seems like there hasn't been much effort elsewhere in the codebase to support it. For example, all repository types share the setting name :branch. Also the configure_scm method and all of SCMResolver seems to only support a single SCM.

And if support is shaky at best, I think it's reasonable to consider adding that support out of scope for this PR.

mvastola

comment created time in 2 hours

Pull request review commentcapistrano/capistrano

Allow access to SCM::Plugin instance from deploy scripts

 def install(plugin, load_hooks: true, load_immediately: false)             plugin.set_defaults           end         end+        @scm_plugin = plugin if provides_scm?(plugin)+        plugin       end +      attr_reader :scm_plugin

Oh, I didn't realize that was possible.

Hrm. I did consider making this accessible for all plugins though. The reason why I didn't just do that was twofold:

  • using an array can easily become confusing (even if we limit it to scm plugins) because you basically have to run #detect on it every time you want to access something
  • the obvious solution to that would be something like a hash, there is no straight-forward mechanism (that I know of) to get a plugin's name.

Maybe the better solution in this case would be to add an optional as argument so you can do, for instance install_plugin Capistrano::SCM::Git, as: :git, and that will define a git method that returns the plugin?

Let me know what you think.

This does make me realize a way around all this though (though it's less elegant). Something like:

set :git, Capistrano::SCM::Git.new
install_plugin fetch(:git)
mvastola

comment created time in 2 hours

Pull request review commentcapistrano/capistrano

Allow access to SCM::Plugin instance from deploy scripts

 def install(plugin, load_hooks: true, load_immediately: false)             plugin.set_defaults           end         end+        @scm_plugin = plugin if provides_scm?(plugin)+        plugin       end +      attr_reader :scm_plugin

Hmm, I wonder if this should be :scm_plugins (plural) as an array? I believe the installer allows someone to install multiple SCM plugins. Or in any case, it doesn't prevent this from happening. If there were to be multiple SCM plugins installed, then a singular scm_plugin is misleading and establishes the wrong API contract.

In which case I think @scm_plugins should be initialized to an empty array, and then your code could be changed slightly:

@scm_plugins << plugin if provides_scm?(plugin)

What do you think?

mvastola

comment created time in 3 hours

PR opened capistrano/capistrano

Allow access to SCM::Plugin instance from deploy scripts

Accessible via scm_plugin method.

Summary

Provides a way to access the deployment's Capistrano::SCM::Plugin instance from within a deploy script. (via an scm_plugin method)

My use case for this was that I wanted to invoke git:check on my local machine, from which I trigger the deployment. As my local machine does not have a release role, it isn't possible to simply invoke the built-in rake task.

Short checklist

  • [x] Did you run bundle exec rubocop -a to fix linter issues?
  • [x] If relevant, did you create a test?
  • [x] Did you confirm that the RSpec tests pass?
+19 -1

0 comment

4 changed files

pr created time in 3 hours

GollumEvent
GollumEvent

pull request commentsparklemotion/nokogiri

ci: try UCRT for windows ruby-head builds

The latest MSYS2 package mingw-w64-ucrt-x86_64-libxslt-1.1.34-4 is now in the official repository and it fixes the date/time issue on UCRT64.

flavorjones

comment created time in 11 hours

issue commentsparklemotion/nokogiri

Epic: merge Nokogumbo into Nokogiri

I dug into it a little more. Safari, Firefox, and Chrome all agree with the test. html5ever agrees with Gumbo and my reading of the spec. More details here. This could be a spec bug, so I filed an issue. It's more likely I'm just missing something subtle.

flavorjones

comment created time in 12 hours

startedshichuan/javascript-patterns

started time in 21 hours

issue commentsparklemotion/nokogiri

Epic: merge Nokogumbo into Nokogiri

Everything from the "Functional Merger" section of this issue's description is done and on main.

flavorjones

comment created time in a day

delete branch sparklemotion/nokogiri

delete branch : 2204-nokogumbo-test-suite

delete time in a day

push eventsparklemotion/nokogiri

Mike Dalessio

commit sha 652ec65fd7ea39f0ed34a93db5d63951c7fa7b32

ci: submodule @stevecheckoway's fork of html5lib-tests see https://github.com/rubys/nokogumbo/issues/170#issuecomment-797616327

view details

Mike Dalessio

commit sha b2714b76bcfa6dfbb0e4c9d64a808c48a79dd5d7

ci: gumbo parser tests and add gumbo tests to the default rake task

view details

Mike Dalessio

commit sha a40cbb02557c8aaf8129691fefef0b6194065b15

add gumbo test information to CONTRIBUTING [skip ci]

view details

Mike Dalessio

commit sha 2516b5a751a495b361501ea1c1c48bd59f78ef7c

Merge pull request #2273 from sparklemotion/2204-nokogumbo-test-suite ci: nokogumbo test suite --- **What problem is this PR intended to solve?** Merge the remaining Nokogumbo tests into Nokogiri's test suite. - [x] submodule @stevecheckoway's fork of html5lib-tests (see see https://github.com/rubys/nokogumbo/issues/170#issuecomment-797616327) - [x] make sure these tests only run under CRuby - [x] gumbo tests **Have you included adequate test coverage?** Tests are the entire substance of this PR. **Does this change affect the behavior of either the C or the Java implementations?** Notably, these additional tests should only run under CRuby.

view details

push time in a day

PR merged sparklemotion/nokogiri

ci: nokogumbo test suite

What problem is this PR intended to solve?

Merge the remaining Nokogumbo tests into Nokogiri's test suite.

  • [x] submodule @stevecheckoway's fork of html5lib-tests (see see https://github.com/rubys/nokogumbo/issues/170#issuecomment-797616327)
  • [x] make sure these tests only run under CRuby
  • [x] gumbo tests

Have you included adequate test coverage?

Tests are the entire substance of this PR.

Does this change affect the behavior of either the C or the Java implementations?

Notably, these additional tests should only run under CRuby.

+138 -39

0 comment

13 changed files

flavorjones

pr closed time in a day

push eventsparklemotion/nokogiri

Mike Dalessio

commit sha a40cbb02557c8aaf8129691fefef0b6194065b15

add gumbo test information to CONTRIBUTING [skip ci]

view details

push time in a day

issue commentsparklemotion/nokogiri

[bug] valgrind errors spotted in gumbo parser

One more instance: https://github.com/sparklemotion/nokogiri/pull/2273/checks?check_run_id=2863381608#step:7:40

flavorjones

comment created time in a day

push eventsparklemotion/nokogiri

Mike Dalessio

commit sha 5374178e8e3ac09f5e0b64a50fae9953d83c0dfa

dev: don't place gumbo build artifacts under /ports for two reasons: - make it so a simple `rake clean` will cause a rebuild of gumbo, avoiding a slow `rake clobber compile` build cycle - enable us to safely cache `/ports` in CI, which should be a significant speedup

view details

Mike Dalessio

commit sha c53c07e45debe57a80d0d66d73ac1d2489427f80

ci: cache the whole /ports directory for most CI jobs we want to cache the compiled libraries when possible. however, we cache just the tarballs for some jobs: - gem packaging tests - truffleruby tests (because I'm not confident there isn't some additional compile-time configuration being injected)

view details

Mike Dalessio

commit sha 855f7c0c6597cb3467cce2695eb8fa3269d1e76b

Merge pull request #2277 from sparklemotion/flavorjones-better-ci-caching improve CI caching of compiled dependencies --- **What problem is this PR intended to solve?** Quite a bit of CI time is spent compiling our packaged dependencies (libxml2, libxslt, libiconv, zlib). For a given platform, we should be able to cache these libraries once compiled. This PR does two things: - move libgumbo out of `/ports` - caches `/ports` for most jobs that were previously caching just `/ports/archives` (which only contains the tarballs) Before/after timings for the `rake compile` job: | | before | after | |--------------|--------|-------| | linux 2.7 | 1m12s | 18s | | linux head | 1m29s | 17s | | macos head | 2m10s | 34s | | windows head | 9m47s | 1m42s |

view details

Mike Dalessio

commit sha 652ec65fd7ea39f0ed34a93db5d63951c7fa7b32

ci: submodule @stevecheckoway's fork of html5lib-tests see https://github.com/rubys/nokogumbo/issues/170#issuecomment-797616327

view details

Mike Dalessio

commit sha b2714b76bcfa6dfbb0e4c9d64a808c48a79dd5d7

ci: gumbo parser tests and add gumbo tests to the default rake task

view details

push time in a day

delete branch sparklemotion/nokogiri

delete branch : flavorjones-better-ci-caching

delete time in a day

push eventsparklemotion/nokogiri

Mike Dalessio

commit sha 5374178e8e3ac09f5e0b64a50fae9953d83c0dfa

dev: don't place gumbo build artifacts under /ports for two reasons: - make it so a simple `rake clean` will cause a rebuild of gumbo, avoiding a slow `rake clobber compile` build cycle - enable us to safely cache `/ports` in CI, which should be a significant speedup

view details

Mike Dalessio

commit sha c53c07e45debe57a80d0d66d73ac1d2489427f80

ci: cache the whole /ports directory for most CI jobs we want to cache the compiled libraries when possible. however, we cache just the tarballs for some jobs: - gem packaging tests - truffleruby tests (because I'm not confident there isn't some additional compile-time configuration being injected)

view details

Mike Dalessio

commit sha 855f7c0c6597cb3467cce2695eb8fa3269d1e76b

Merge pull request #2277 from sparklemotion/flavorjones-better-ci-caching improve CI caching of compiled dependencies --- **What problem is this PR intended to solve?** Quite a bit of CI time is spent compiling our packaged dependencies (libxml2, libxslt, libiconv, zlib). For a given platform, we should be able to cache these libraries once compiled. This PR does two things: - move libgumbo out of `/ports` - caches `/ports` for most jobs that were previously caching just `/ports/archives` (which only contains the tarballs) Before/after timings for the `rake compile` job: | | before | after | |--------------|--------|-------| | linux 2.7 | 1m12s | 18s | | linux head | 1m29s | 17s | | macos head | 2m10s | 34s | | windows head | 9m47s | 1m42s |

view details

push time in a day

PR merged sparklemotion/nokogiri

improve CI caching of compiled dependencies

What problem is this PR intended to solve?

Quite a bit of CI time is spent compiling our packaged dependencies (libxml2, libxslt, libiconv, zlib). For a given platform, we should be able to cache these libraries once compiled.

This PR does two things:

  • move libgumbo out of /ports
  • caches /ports for most jobs that were previously caching just /ports/archives (which only contains the tarballs)

I'll run CI twice on this branch and compare the timing to previous runs to make sure this is actually effective.

+19 -19

1 comment

3 changed files

flavorjones

pr closed time in a day

pull request commentsparklemotion/nokogiri

improve CI caching of compiled dependencies

Pretty compelling before/after timings for the rake compile job:

before after
linux 2.7 1m12s 18s
linux head 1m29s 17s
macos head 2m10s 34s
windows head 9m47s 1m42s
flavorjones

comment created time in a day

push eventsparklemotion/nokogiri

Mike Dalessio

commit sha 1ed629b9272a200a81037486fb0b69c23b7b6375

ci: make the GA cache platform-specific because, e.g., zlib isn't used on linux but it used on windows.

view details

Mike Dalessio

commit sha 20e2b74dbfa38666614e6178eb191911059f17be

Merge pull request #2275 from sparklemotion/flavorjones-ci-fix-ga-cache ci: make the GA cache platform-specific

view details

Mike Dalessio

commit sha 55ab36c7439806799d179c1039ba85c0f5893143

ci: ports/archives cache hit requires exact key related to 20e2b74

view details

Mike Dalessio

commit sha 1d345dc007250786a894c0dab6b4b52455246f29

ci: try UCRT for windows ruby-head builds see #2268 for context Co-authored-by: MSP-Greg <Greg.mpls@gmail.com>

view details

Mike Dalessio

commit sha 899c31979ab0fede444745449c10ad3e4bd85fee

test: formatting and wrap in describe to avoid multiple runs

view details

Mike Dalessio

commit sha 5bb0bcbd713a87c52263ea0d0a48eac20aeb9b93

handle libxslt built without date-time functionality - expose this compile-time config as Nokogiri::VERSION_INFO["libxslt"]["datetime_enabled"] - skip the assertion that depends on this behavior

view details

Mike Dalessio

commit sha 1508a661144201772d9c01de0e2cd680d7d27b91

Merge pull request #2272 from sparklemotion/flavorjones-ci-ucrt-windows-builds ci: try UCRT for windows ruby-head builds

view details

Mike Dalessio

commit sha c81bb684cc2e687892be3c16fb290565811765fe

ci: submodule @stevecheckoway's fork of html5lib-tests see https://github.com/rubys/nokogumbo/issues/170#issuecomment-797616327

view details

Mike Dalessio

commit sha de395c47b669c419e7b73d3250da0c0e904cae12

ci: gumbo parser tests and add gumbo tests to the default rake task

view details

push time in a day

PR opened sparklemotion/nokogiri

improve CI caching of compiled dependencies

What problem is this PR intended to solve?

Quite a bit of CI time is spent compiling our packaged dependencies (libxml2, libxslt, libiconv, zlib). For a given platform, we should be able to cache these libraries once compiled.

This PR does two things:

  • move libgumbo out of /ports
  • caches /ports for most jobs that were previously caching just /ports/archives (which only contains the tarballs)

I'll run CI twice on this branch and compare the timing to previous runs to make sure this is actually effective.

+19 -19

0 comment

3 changed files

pr created time in a day

push eventsparklemotion/nokogiri

Mike Dalessio

commit sha 1508a661144201772d9c01de0e2cd680d7d27b91

Merge pull request #2272 from sparklemotion/flavorjones-ci-ucrt-windows-builds ci: try UCRT for windows ruby-head builds

view details

Mike Dalessio

commit sha 5374178e8e3ac09f5e0b64a50fae9953d83c0dfa

dev: don't place gumbo build artifacts under /ports for two reasons: - make it so a simple `rake clean` will cause a rebuild of gumbo, avoiding a slow `rake clobber compile` build cycle - enable us to safely cache `/ports` in CI, which should be a significant speedup

view details

Mike Dalessio

commit sha c53c07e45debe57a80d0d66d73ac1d2489427f80

ci: cache the whole /ports directory for most CI jobs we want to cache the compiled libraries when possible. however, we cache just the tarballs for some jobs: - gem packaging tests - truffleruby tests (because I'm not confident there isn't some additional compile-time configuration being injected)

view details

push time in a day

create barnchsparklemotion/nokogiri

branch : flavorjones-better-ci-caching

created branch time in a day

delete branch sparklemotion/nokogiri

delete branch : flavorjones-ci-ucrt-windows-builds

delete time in a day

push eventsparklemotion/nokogiri

Mike Dalessio

commit sha 55ab36c7439806799d179c1039ba85c0f5893143

ci: ports/archives cache hit requires exact key related to 20e2b74

view details

Mike Dalessio

commit sha 1d345dc007250786a894c0dab6b4b52455246f29

ci: try UCRT for windows ruby-head builds see #2268 for context Co-authored-by: MSP-Greg <Greg.mpls@gmail.com>

view details

Mike Dalessio

commit sha 899c31979ab0fede444745449c10ad3e4bd85fee

test: formatting and wrap in describe to avoid multiple runs

view details

Mike Dalessio

commit sha 5bb0bcbd713a87c52263ea0d0a48eac20aeb9b93

handle libxslt built without date-time functionality - expose this compile-time config as Nokogiri::VERSION_INFO["libxslt"]["datetime_enabled"] - skip the assertion that depends on this behavior

view details

Mike Dalessio

commit sha 1508a661144201772d9c01de0e2cd680d7d27b91

Merge pull request #2272 from sparklemotion/flavorjones-ci-ucrt-windows-builds ci: try UCRT for windows ruby-head builds

view details

push time in a day

PR merged sparklemotion/nokogiri

ci: try UCRT for windows ruby-head builds

What problem is this PR intended to solve?

The 3.1.0.dev windows ruby installer uses UCRT, see #2268 for context. This gives Nokogiri and @larskanis a feedback loop.

+77 -68

7 comments

11 changed files

flavorjones

pr closed time in a day

issue openedsparklemotion/nokogiri

[bug] valgrind errors spotted in gumbo parser

Please describe the bug

A CI test run caught some memory errors in gumbo.

The build log is at https://github.com/sparklemotion/nokogiri/pull/2272/checks?check_run_id=2862967128

Here's the relevant snippet:

# Running tests with run options --seed 25442:

==489== Invalid read of size 8
==489==    at 0x8A170F4: parse_args_mark (gumbo.c:307)
==489==    by 0x490A58B: gc_mark_stacked_objects (gc.c:4737)
==489==    by 0x490A58B: gc_mark_stacked_objects_all (gc.c:4777)
==489==    by 0x490A58B: gc_marks_rest (gc.c:5653)
==489==    by 0x490AE9F: gc_marks (gc.c:5713)
==489==    by 0x490AE9F: gc_start (gc.c:6493)
==489==    by 0x490AE9F: gc_start (gc.c:6417)
==489==    by 0x490B5E2: garbage_collect (gc.c:6413)
==489==    by 0x490B5E2: gc_start_internal (gc.c:6722)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4CEED: vm_exec_core (insns.def:915)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A58F70: invoke_block (vm.c:979)
==489==    by 0x4A58F70: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A58F70: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A58F70: vm_yield (vm.c:1094)
==489==    by 0x4A58F70: rb_yield_0 (vm_eval.c:970)
==489==    by 0x4A58F70: rb_yield_1 (vm_eval.c:976)
==489==    by 0x4A58F70: rb_yield (vm_eval.c:986)
==489==    by 0x487477B: rb_ary_each (array.c:1837)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A58F70: invoke_block (vm.c:979)
==489==    by 0x4A58F70: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A58F70: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A58F70: vm_yield (vm.c:1094)
==489==    by 0x4A58F70: rb_yield_0 (vm_eval.c:970)
==489==    by 0x4A58F70: rb_yield_1 (vm_eval.c:976)
==489==    by 0x4A58F70: rb_yield (vm_eval.c:986)
==489==    by 0x487477B: rb_ary_each (array.c:1837)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A584C4: invoke_block (vm.c:979)
==489==    by 0x4A584C4: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A584C4: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A584C4: vm_yield_force_blockarg (vm.c:1110)
==489==    by 0x4A584C4: rb_yield_force_blockarg (vm_eval.c:1035)
==489==    by 0x4878FAB: rb_ary_collect (array.c:2758)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A53E8B: vm_call_method_each_type.part.135 (vm_insnhelper.c:2232)
==489==    by 0x4A5450A: vm_call_method_each_type (vm_insnhelper.c:2380)
==489==    by 0x4A5450A: vm_call_method (vm_insnhelper.c:2384)
==489==    by 0x4A5450A: vm_call_method (vm_insnhelper.c:2351)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A52BAA: invoke_block (vm.c:979)
==489==    by 0x4A52BAA: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A53889: invoke_block_from_c_proc (vm.c:1124)
==489==    by 0x4A53889: vm_invoke_proc (vm.c:1149)
==489==    by 0x4984B18: rb_proc_call (proc.c:887)
==489==    by 0x48F401C: exec_end_procs_chain (eval_jump.c:108)
==489==    by 0x48F401C: rb_exec_end_proc (eval_jump.c:125)
==489==    by 0x48F4171: ruby_finalize_0 (eval.c:124)
==489==    by 0x48F4497: ruby_cleanup (eval.c:182)
==489==    by 0x48F47C4: ruby_run_node (eval.c:303)
==489==    by 0x1090EA: main (main.c:42)
==489==  Address 0x1ffeffcce8 is on thread 1's stack
==489==  312 bytes below stack pointer
==489== 
{
   <insert_a_suppression_name_here>
   Memcheck:Addr8
   fun:parse_args_mark
   fun:gc_mark_stacked_objects
   fun:gc_mark_stacked_objects_all
   fun:gc_marks_rest
   fun:gc_marks
   fun:gc_start
   fun:gc_start
   fun:garbage_collect
   fun:gc_start_internal
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield
   fun:rb_yield_0
   fun:rb_yield_1
   fun:rb_yield
   fun:rb_ary_each
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield
   fun:rb_yield_0
   fun:rb_yield_1
   fun:rb_yield
   fun:rb_ary_each
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield_force_blockarg
   fun:rb_yield_force_blockarg
   fun:rb_ary_collect
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_call_method_each_type.part.135
   fun:vm_call_method_each_type
   fun:vm_call_method
   fun:vm_call_method
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_proc
   fun:vm_invoke_proc
   fun:rb_proc_call
   fun:exec_end_procs_chain
   fun:rb_exec_end_proc
   fun:ruby_finalize_0
   fun:ruby_cleanup
   fun:ruby_run_node
   fun:main
}
==489== Invalid read of size 8
==489==    at 0x8A170FD: parse_args_mark (gumbo.c:308)
==489==    by 0x490A58B: gc_mark_stacked_objects (gc.c:4737)
==489==    by 0x490A58B: gc_mark_stacked_objects_all (gc.c:4777)
==489==    by 0x490A58B: gc_marks_rest (gc.c:5653)
==489==    by 0x490AE9F: gc_marks (gc.c:5713)
==489==    by 0x490AE9F: gc_start (gc.c:6493)
==489==    by 0x490AE9F: gc_start (gc.c:6417)
==489==    by 0x490B5E2: garbage_collect (gc.c:6413)
==489==    by 0x490B5E2: gc_start_internal (gc.c:6722)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4CEED: vm_exec_core (insns.def:915)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A58F70: invoke_block (vm.c:979)
==489==    by 0x4A58F70: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A58F70: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A58F70: vm_yield (vm.c:1094)
==489==    by 0x4A58F70: rb_yield_0 (vm_eval.c:970)
==489==    by 0x4A58F70: rb_yield_1 (vm_eval.c:976)
==489==    by 0x4A58F70: rb_yield (vm_eval.c:986)
==489==    by 0x487477B: rb_ary_each (array.c:1837)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A58F70: invoke_block (vm.c:979)
==489==    by 0x4A58F70: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A58F70: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A58F70: vm_yield (vm.c:1094)
==489==    by 0x4A58F70: rb_yield_0 (vm_eval.c:970)
==489==    by 0x4A58F70: rb_yield_1 (vm_eval.c:976)
==489==    by 0x4A58F70: rb_yield (vm_eval.c:986)
==489==    by 0x487477B: rb_ary_each (array.c:1837)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A584C4: invoke_block (vm.c:979)
==489==    by 0x4A584C4: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A584C4: invoke_block_from_c_bh (vm.c:1049)
==489==    by 0x4A584C4: vm_yield_force_blockarg (vm.c:1110)
==489==    by 0x4A584C4: rb_yield_force_blockarg (vm_eval.c:1035)
==489==    by 0x4878FAB: rb_ary_collect (array.c:2758)
==489==    by 0x4A42198: vm_call_cfunc_with_frame (vm_insnhelper.c:1918)
==489==    by 0x4A42198: vm_call_cfunc (vm_insnhelper.c:1934)
==489==    by 0x4A53E8B: vm_call_method_each_type.part.135 (vm_insnhelper.c:2232)
==489==    by 0x4A5450A: vm_call_method_each_type (vm_insnhelper.c:2380)
==489==    by 0x4A5450A: vm_call_method (vm_insnhelper.c:2384)
==489==    by 0x4A5450A: vm_call_method (vm_insnhelper.c:2351)
==489==    by 0x4A4D962: vm_exec_core (insns.def:850)
==489==    by 0x4A51FDC: vm_exec (vm.c:1778)
==489==    by 0x4A52BAA: invoke_block (vm.c:979)
==489==    by 0x4A52BAA: invoke_iseq_block_from_c (vm.c:1031)
==489==    by 0x4A53889: invoke_block_from_c_proc (vm.c:1124)
==489==    by 0x4A53889: vm_invoke_proc (vm.c:1149)
==489==    by 0x4984B18: rb_proc_call (proc.c:887)
==489==    by 0x48F401C: exec_end_procs_chain (eval_jump.c:108)
==489==    by 0x48F401C: rb_exec_end_proc (eval_jump.c:125)
==489==    by 0x48F4171: ruby_finalize_0 (eval.c:124)
==489==    by 0x48F4497: ruby_cleanup (eval.c:182)
==489==    by 0x48F47C4: ruby_run_node (eval.c:303)
==489==    by 0x1090EA: main (main.c:42)
==489==  Address 0x1ffeffccf0 is on thread 1's stack
==489==  304 bytes below stack pointer
==489== 
{
   <insert_a_suppression_name_here>
   Memcheck:Addr8
   fun:parse_args_mark
   fun:gc_mark_stacked_objects
   fun:gc_mark_stacked_objects_all
   fun:gc_marks_rest
   fun:gc_marks
   fun:gc_start
   fun:gc_start
   fun:garbage_collect
   fun:gc_start_internal
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield
   fun:rb_yield_0
   fun:rb_yield_1
   fun:rb_yield
   fun:rb_ary_each
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield
   fun:rb_yield_0
   fun:rb_yield_1
   fun:rb_yield
   fun:rb_ary_each
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_bh
   fun:vm_yield_force_blockarg
   fun:rb_yield_force_blockarg
   fun:rb_ary_collect
   fun:vm_call_cfunc_with_frame
   fun:vm_call_cfunc
   fun:vm_call_method_each_type.part.135
   fun:vm_call_method_each_type
   fun:vm_call_method
   fun:vm_call_method
   fun:vm_exec_core
   fun:vm_exec
   fun:invoke_block
   fun:invoke_iseq_block_from_c
   fun:invoke_block_from_c_proc
   fun:vm_invoke_proc
   fun:rb_proc_call
   fun:exec_end_procs_chain
   fun:rb_exec_end_proc
   fun:ruby_finalize_0
   fun:ruby_cleanup
   fun:ruby_run_node
   fun:main
}

created time in a day

issue commentsparklemotion/nokogiri

[bug] Duplicated `lang` attribute after serialization/deserialization if `remove_namespaces!` is used

After giving it some thought, this isn't something I'm willing to spend time to fix. If you want to spend some time to describe the behavior you think Nokogiri should have in this case, and write a PR for it, I'd be happy to review.

gioele

comment created time in a day

issue closedsparklemotion/nokogiri

[bug] Duplicated `lang` attribute after serialization/deserialization if `remove_namespaces!` is used

Please describe the bug

The lang attribute is duplicated after serialization/deserialization if remove_namespaces! is used.

<html xmlns="http://www.w3.org/1999/xhtml" lang="x" lang="x" lang="x" xml:lang="x"></html>

Help us reproduce what you're seeing

Here is a reproduction script:

#!/usr/bin/env ruby

require "nokogiri"

def from_xml(str)
	parse_options = Nokogiri::XML::ParseOptions::DEFAULT_XML
	doc = Nokogiri::XML::Document.parse(str, nil, nil, parse_options)
	doc.remove_namespaces! # <<< the bug disappears if this line is commented out
	return doc
end

doc = from_xml("<html lang='x'/>")
doc_str = doc.to_xhtml; puts doc_str

doc2 = from_xml(doc_str)
doc2_str = doc2.to_xhtml; puts doc2_str

doc3 = from_xml(doc2_str)
doc3_str = doc3.to_xhtml; puts doc3_str

raise "Different serialization" unless doc_str == doc2_str

Expected behavior / Actual behavior

One would expect the document to not change after a serialization/deserialization cycle.

The reproduction script should output the following lines:

<html xmlns="http://www.w3.org/1999/xhtml" lang="x" xml:lang="x"></html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="x" xml:lang="x"></html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="x" xml:lang="x"></html>

Instead it produces this output:

<html xmlns="http://www.w3.org/1999/xhtml" lang="x" xml:lang="x"></html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="x" lang="x" xml:lang="x"></html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="x" lang="x" lang="x" xml:lang="x"></html>
Traceback (most recent call last):
./lang-test.rb:24:in `<main>': Different serialization (RuntimeError)

Environment

$ nokogiri -v
# Nokogiri (1.11.7)
    ---
    warnings: []
    nokogiri:
      version: 1.11.7
      cppflags:
      - "-I/[RBENV]/versions/2.6.2/lib/ruby/gems/2.6.0/gems/nokogiri-1.11.7-x86_64-linux/ext/nokogiri"
      - "-I/[RBENV]/versions/2.6.2/lib/ruby/gems/2.6.0/gems/nokogiri-1.11.7-x86_64-linux/ext/nokogiri/include"
      - "-I/[RBENV]/versions/2.6.2/lib/ruby/gems/2.6.0/gems/nokogiri-1.11.7-x86_64-linux/ext/nokogiri/include/libxml2"
      ldflags: []
    ruby:
      version: 2.6.2
      platform: x86_64-linux
      gem_platform: x86_64-linux
      description: ruby 2.6.2p47 (2019-03-13 revision 67232) [x86_64-linux]
      engine: ruby
    libxml:
      source: packaged
      precompiled: true
      patches:
      - 0001-Remove-script-macro-support.patch
      - 0002-Update-entities-to-remove-handling-of-ssi.patch
      - 0003-libxml2.la-is-in-top_builddir.patch
      - 0004-use-glibc-strlen.patch
      - 0005-avoid-isnan-isinf.patch
      - 0006-update-automake-files-for-arm64.patch
      - 0007-Fix-XPath-recursion-limit.patch
      libxml2_path: "/[RBENV]/versions/2.6.2/lib/ruby/gems/2.6.0/gems/nokogiri-1.11.7-x86_64-linux/ext/nokogiri"
      memory_management: ruby
      iconv_enabled: true
      compiled: 2.9.12
      loaded: 2.9.12
    libxslt:
      source: packaged
      precompiled: true
      patches:
      - 0001-update-automake-files-for-arm64.patch
      - 0002-Fix-xml2-config-check-in-configure-script.patch
      compiled: 1.1.34
      loaded: 1.1.34
    other_libraries:
      zlib: 1.2.11

closed time in a day

gioele