Hello, Ruby developers!Whether you are a seasoned Ruby developer or just getting started, mastering the debugger will save you time and frustration when tracking down bugs. At RubyMine, weve spent years building debugging tools for Ruby. In this blog series, were sharing some of the insights weve gained along the way.In this post, well take a closer look at the internal workings of byebug and the debug gem, comparing their unique approaches, strengths, and limitations. Well also break down the architecture of the RubyMine debugger to see how it works. Finally, well conduct an experiment to test the performance of these debuggers and find out which one comes out on top.This is the third post in a series inspired by Demystifying Debuggers, a talk by Dmitry Pogrebnoy, RubyMine Team Lead, presented at EuRuKo 2024, RubyKaigi 2025 and RubyConf Africa 2025. In this post, we go deeper into how Ruby debuggers work under the hood and share insights about Ruby debuggers.If you havent seen the earlier posts yet, we recommend starting there:Mastering Ruby Debugging: From puts to Professional ToolsInside Ruby Debuggers: TracePoint, Instruction Sequence, and CRuby APIPrefer watching? You can also check out the original talk here: Dmitry Pogrebnoy, Demystifying DebuggerLets dive into the internals!Is the debugger an essential tool for Ruby developers?Before we jump into how debuggers work, lets take a step back and ask: How often do Ruby developers actually use a debugger? The answer might surprise you.The need for and reliance on a debugger can vary greatly depending on the programming language and framework youre using. Its also influenced by the preferences of the developer community and the specific needs of the domain. Some developers might use a debugger all the time, while others might prefer different tools or methods for troubleshooting. Some of these tools were covered in the first post in the series.Unfortunately, there arent any reliable public stats on how often Ruby developers use debuggers overall. But thanks to anonymous usage data from RubyMine users, we can still get a rough sense of how common debugger usage is in real-world projects.The pie chart below shows how often RubyMine users run their code using a debugger compared to other types of run configurations. These numbers come from anonymous usage stats collected in RubyMine 2025.1.As we can see, almost every third run in RubyMine is a debugger run. This demonstrates just how essential and fundamental the debugger has become for professional Ruby developers. Thats why the RubyMine team tries to provide the smoothest possible debugger experience that will enhance your efforts in investigating problems.How do Ruby debuggers work internally?In the previous section, we covered the main building blocks of Ruby debuggers. Now its time to see how these components are applied in real-world tools. In this section, well start with the byebug gem, then move on to the debug gem, and finally take a look at the RubyMine debugger. Lets begin with byebug!Simplified model of the byebug debuggerbyebug is a simple Ruby debugger. It provides essential features like breakpoints, basic stepping, and variable inspection. By default, it offers a command-line interface (CLI) for debugging, but theres also an option to install and configure a plugin for GUI support in code editors.To start a debugging session with byebug, you typically need to modify your projects source code by inserting byebug statements, or run commands manually in the terminal, which require some adjustments to your project setup, especially when working with Rails applications.Lets take a look at the simplified model of how byebug works. This code in the model should be executed before any code of the application that we are going to debug.breakpoints = [] # list of breakpointstracepoints = [] # contains a single tracepoint for each event type# For every type of tracepoint eventtracepoints << TracePoint.trace(:line) do |tp| breakpoint = breakpoints.find do |b| tp.path == b.path && tp.lineno == b.lineno end if breakpoint handle_breakpoint(breakpoint) endend# Ordinal code execution# ...Lets examine how this works. At its core, byebug maintains two important lists one for storing breakpoints set by the user throughout the debugging session, and another for tracepoints. TracePoint is a instrumentation technology in Ruby that works by intercepting specific runtime events such as method calls, line executions, or exception raises and executing custom code when these events occur. Take a look at our previous blog post for more details.byebug has one TracePoint for each type of event it tracks one for line events, one for call events, and so on. Each TracePoint in the list follows a similar pattern. When a trace event occurs at runtime, the corresponding TracePoint is triggered, and byebug checks whether theres a breakpoint set at that location by comparing file paths and line numbers. If a breakpoint is found, byebug pauses program execution and hands control to the developer, who can then inspect variables, step through code, evaluate expressions, or perform other debugger actions. If no breakpoint is found, execution simply continues until the next trace event, where the same process is repeated. This is how byebug detects breakpoints and stops at them during runtime.It is a simple yet effective approach that works well and allows developers to debug their code. However, it comes with one major drawback performance.With each event emitted during program execution, byebug has to perform breakpoint checks even when theres only a single breakpoint set in the entire application. This means that if you place just one breakpoint somewhere in your code, the debugger will still check for breakpoint matches on every single trace event. Its like having a security guard check every room in a building when you only need to monitor one specific door.Consequently, these constant checks add significant computational overhead when running code with byebug. Our performance tests show that applications can run more than 20 times slower under byebug compared to normal execution. This performance impact makes byebug challenging to use with complex real-world Rails applications, where execution time really matters. Fortunately, more modern debugging solutions have found ways to address this limitation.Performant debug gem and TracePoint improvementOur next tool is the debug gem a debugger designed for modern Ruby versions starting from 2.7. It provides CLI by default, but you can also set it up with a plugin to get GUI in code editors.Just like byebug, the debug gem requires you to modify your code by adding binding.break statements to start a debugging session. Alternatively, you can run it manually from the terminal, which may require some additional project configuration, especially in Rails applications.The debug gem completely solves the significant performance limitation described in the previous section. Before we start with the debug gem, lets take a look at the main feature that helped to overcome the performance problem.The magic behind the strong performance of the debug gem is related to the TracePoint update that was released in Ruby 2.6 back in 2018.This improvement added a key feature TracePoints could now be targeted to specific lines of code or specific instruction sequences. No more checking for breakpoints on every event. Instead, TracePoints would only trigger exactly where breakpoints were set, solving the performance problem.Lets look at a practical example of how this feature works.def say_hello = puts "Hello Ruby developers!"def say_goodbye = puts "Goodbye Ruby developers!"iseq = RubyVM::InstructionSequence.of(method(:say_hello))trace = TracePoint.new(:call) do |tp| puts "Calling method '#{tp.method_id}'"endtrace.enable(target: iseq)say_hellosay_goodbye# => Calling method 'say_hello'# => Hello Ruby developers!# => Goodbye Ruby developers!Here we have two methods say_hello and say_goodbye. The key change is that were targeting our TracePoint specifically to the instruction sequence of the first method only.Looking at the output in the comments, we can see how powerful and precise targeted TracePoints are. The TracePoint is triggered only for say_hello but is completely ignored for say_goodbye exactly what we needed. This level of control is a major improvement over the old approach where TracePoints would fire for every method indiscriminately.This example demonstrates a simplified version of how the debug gem uses TracePoint under the hood. Unlike byebug, which maintains a general-purpose list of TracePoints and checks every single trace event against all breakpoints, the debug gem takes a more efficient and targeted approach. It creates a dedicated TracePoint for each individual breakpoint and binds it directly to the corresponding location in the code either a specific line or an instruction sequence.This means the TracePoint will only trigger when that exact location is executed, eliminating the need for constant runtime checks across unrelated code paths. As a result, the debug gem introduces significantly less overhead and performs much better in practice. This difference becomes especially noticeable in large Ruby codebases or performance-sensitive environments, where byebugs frequent event scanning can lead to substantial slowdowns.Despite its significant advantages, this TracePoint improvement wasnt backported to Ruby versions before 2.6. As a result, the debug gem only supports Ruby 2.7 and newer versions where additional fixes for the TracePoint improvement were released. This circumstance leaves projects running on older Ruby versions without access to this powerful debugging tool, even though they might still need advanced debugging capabilities for investigating complex issues.Starting with Ruby 3.1, the debug gem is bundled as the default debugger. Its an excellent starting point for many Ruby developers especially those who havent yet explored more advanced tools like the RubyMine debugger to meet their growing need for a better debugging experience and more powerful capabilities.How is the RubyMine debugger structured?As weve seen, both popular open-source Ruby debuggers have their limitations. Byebug suffers from performance issues that make it impractical for large applications, while the debug gem doesnt support Ruby versions before 2.7. This can be frustrating for professional developers who need reliable debugging capabilities across different Ruby versions. The RubyMine debugger solves these problems by supporting Ruby versions from 2.3 onwards, covering practically any Ruby version your application might use.One significant benefit that sets the RubyMine debugger apart is that it doesnt have any performance issues and maintains excellent speed even on older Ruby versions. This feature makes the RubyMine debugger the go-to debugging tool for professional Ruby developers, regardless of their projects specific requirements.Another advantage is a straightforward debugging experience, with all features available immediately after setup. Theres no need to modify your project configuration, install and configure extra plugins, or manage terminal commands to start debugging. It works even with production size Rails applications and lets you focus on solving problems rather than setting up tools.In addition, the RubyMine debugger offers smart stepping a feature that lets you step into a specific method when there are multiple calls on the same line. Instead of always entering the first call, it highlights all available options so you can choose the one you want. Its especially useful for debugging chained or complex expressions a level of control that other Ruby debuggers dont offer.The RubyMine debugger provides versatile debugging capabilities and a productivity-focused debugger experience. If you havent tried the RubyMine debugger yet, its definitely worth a chance.Lets take a closer look at the architecture of the RubyMine debugger and how its built to be such a powerful tool.General RubyMine debugger architectureThis is a high-level architecture of the RubyMine debugger.Lets examine the diagram to understand how the RubyMine debugger works internally. The architecture consists of three main parts that work together to provide a smooth debugging experience.The first component is the debase gem the core backend of the RubyMine debugger. Written as a C extension, it handles all low-level operations like retrieving execution contexts, managing stack frames, and manipulating instruction sequences. This backend is responsible for direct interaction with Ruby internals, which makes it a convenient and efficient interface for other debugger components.The second part is the ruby-debug-ide gem, which serves as the internal debugger frontend. This critical piece manages the communication between RubyMine and the backend by establishing and maintaining their connection. It handles the message protocol and processes commands coming from RubyMine. Additionally, its responsible for creating readable text representations of Ruby objects that developers will see in the RubyMine debugger Tool Window.Finally, theres RubyMine itself. Its primary role is to provide a smooth and productive debugging experience. Most of the debugger features that enhance developer productivity like smart stepping, inline-debugger values, and frames and breakpoints management are mainly implemented at this level. The IDE also handles communication with the debugger frontend by sending commands and processing responses.Having three separate parts with clear interfaces between them brings several key benefits. This modular structure significantly reduces the overall system complexity, making it easier to maintain and less prone to bugs. Each component can be developed independently and at its own pace, which streamlines development and makes maintenance more efficient.The real RubyMine debugger architectureThe architecture weve discussed is a simplified view of the RubyMine debugger. While it helps you understand the core concepts, the real-world implementation has additional layers of complexity. Lets dive deeper and explore how the actual system is structured.Instead of a single branch of debugger gems, there are two separate branches of debugger gems a top branch and a bottom branch each specified for different Ruby versions.The top branch supports Ruby versions 2.3 through 2.7. These gems use several clever low-level hacks to achieve high performance without the TracePoint improvements we discussed earlier. While these hacks work effectively, they make the gems harder to maintain and extend. Still, this approach ensures excellent debugging capabilities for legacy Ruby applications.The challenges of maintaining and extending the top branch gems led to the creation of the bottom branch of gems. This branch is designed specifically for modern Ruby and ensures a smooth debugging experience with Ruby versions 3.0 and onwards. Unlike the top branch, these gems dont rely on low-level hacks. Instead, they leverage modern Ruby APIs and the improved TracePoint mechanism, resulting in a cleaner and more maintainable codebase. This approach not only simplifies the implementation but also makes it easier to add new features and support new Ruby versions.Having two separate branches for different Ruby versions helps us keep the RubyMine debugger maintainable and performant. It lets us support legacy versions while steadily raising the quality bar and reliability of the debugging experience for modern Ruby.Which debugger is the most performant?Before we dive into performance, lets quickly recap what weve covered so far. We began with an in-depth look at how the byebug debugger works internally and where it falls short. Then, we examined how the debug gem takes a different approach to overcome those limitations. Finally, we explored the architecture of the RubyMine Debugger and the advantages it brings to the table.Now, its time to ask the big practical question: which of these debuggers performs best?Rather than guess, lets put these debuggers to the test with a straightforward benchmarking experiment.def fib(n) raise if n < 0 # place a breakpoint on this line return n if n < 2 fib(n - 1) + fib(n - 2)endrequire 'benchmark'TOTAL_RUNS = 100total_time = TOTAL_RUNS.times.sum do Benchmark.realtime { fib(40) }endputs "Avg real time elapsed: #{total_time/TOTAL_RUNS}"We use the Fibonacci method with an added condition specifically to set a breakpoint. Although the breakpoint is never hit, it allows us to measure how simply having a breakpoint in place can impact the performance of each debugger. To run the experiment, we used the benchmark gem and averaged the execution time over 100 runs to get stable, meaningful results.Lets state the Ruby debugger and Ruby versions for that experiment to get reproducible results.Ruby 2.6.10Ruby 3.4.2byebug 11.1.3debug gem 1.10.0RubyMine debugger ruby-debug-ide 2.3.24 debase 2.3.15RubyMine debugger ruby-debug-ide 3.0.2 debase 3.0.2For this experiment, well use the latest available versions of Ruby and debugger gems at the time of writing. We define two test groups based on Ruby versions they support. One for Ruby 2.6.10, representing older versions, and one for Ruby 3.4.2, representing modern versions. The Ruby 2.6.10 group includes byebug. The Ruby 3.4.2 group features the debug gem. The RubyMine debugger is included in both groups, but it uses different gem versions optimized for the respective Ruby version.Lets run the benchmark and see how each debugger performs.Ruby 2.6.10Ruby 3.4.2Original run17.7 sec15.8 secbyebug529.1 secdebug gem15.8 secRubyMine debugger17.7 sec15.8 secLets first examine the results for the older Ruby version. The most striking observation is the performance of byebug. The benchmark shows it runs about 30 times slower than the original code without any debugger attached a significant performance hit that makes it impractical for debugging complex applications.On the other hand, the RubyMine debugger shows no noticeable performance impact on older Ruby versions. This means that for applications running on older Ruby versions, particularly production applications, the RubyMine debugger stands out as the only practical option for effective debugging. While having limited choices isnt ideal, this is the reality when working with older Ruby versions.Looking at a modern Ruby version group, the situation is much better. Both the RubyMine debugger and debug gem show excellent performance with no noticeable slowdown. This gives developers the freedom to choose either tool based on their specific needs and preferences. The availability of multiple performant debuggers empowers Ruby developers to choose the best tool for their situation and makes the Ruby debugging ecosystem stronger.Overall, the RubyMine debugger delivers consistently high performance across both old and new Ruby versions, while byebug significantly slows down execution and is impractical for complex applications. On newer Ruby versions, the debug gem matches RubyMine in speed, giving developers an open-source alternative.ConclusionDebugging is a practical skill for every Ruby developer, and understanding the inner workings of Ruby debuggers can help you recognize each debuggers limitations, choose the right tool for your needs, and avoid common pitfalls. In this post, weve examined the internal mechanics of Ruby debuggers like byebug, the debug gem, and the RubyMine debugger, highlighting the advantages and downsides of their approaches.Byebug and the debug gem both offer basic debugging features like breakpoints, stepping, and variable inspection. The debug gem delivers significantly better performance than byebug, but it only supports Ruby versions 2.7 and newer. Byebug, on the other hand, works with older Ruby versions but tends to be much slower especially in larger projects.The RubyMine debugger stands out by combining the best of both worlds. It supports a wide range of Ruby versions, delivers strong performance across all of them, and offers a smooth, reliable debugging experience even in complex Rails applications. On top of the basic features, RubyMine includes advanced capabilities like smart stepping, inline variable values, and more. You can explore the full set of features in the RubyMine debugging documentation.We hope this post has helped clarify how Ruby debuggers work internally and provided useful insights for improving your debugging workflow.Happy coding, and may your bugs be rare and simple to squash!The RubyMine team

Space Adventure Cobra - The Awakening- Launch Trailer | Xbox France

A Soros-backed advocacy group staged a rally in Baltimore supporting accused MS-13 member and human trafficker Kilmar Abrego Garcia. By yourNEWS Media Newsroom A far-left nonprofit partially bankrolled

New research finds civilians thwarted more than one-third of active shooter incidents since 2014, far higher than FBI figures suggest. By yourNEWS Media Newsroom The FBI has significantly underreported

By Blessing Nweke A district judge in Utah has ruled that the states Republican-controlled Legislature must redraw its congressional districts, declaring that it unconstitutionally repealed a

My mothers cousin Henrietta (not her real name), up until that point a solid Democrat, was approaching her Chicago polling place in 1980 when she was greeted by her Democratic precinct worker. Sorry,

According to the legend recorded in the sagas, Erik the Red was exiled from Iceland for three years for killing another man in a fight. He used the time to explore the rugged island of Greenland. When he was able to return, he convinced other Vikings to join him in settling on the new island, and he became the chief of Greenland. Does archaeology support this account of the settlement of Greenland?Erik the Red: A Legend is BornErik the Red, by Arngrimur Jonsson, 1688. Source: Wikimedia CommonsAround 950 CE, Thorvald Asvaldson welcomed a son named Erik into the world. Red-headed Erik was born in Norway during the reign of Haakon the Good. However, when Thorvald killed another Viking, his punishment was exile, and the family migrated to Drangar in northwest Iceland, which was first settled in 874.By the time Thorvald and his family arrived in Iceland, competition for land had grown stiff. But Erik carved a path for himself by marrying well. He wed a local woman named Thjodhild Jorundardottir. They moved to Haukadale and started a family. Erik would have many children, including Leif Erikson, Thorvald, Thorstein, and Freydis. It is not clear if Thjodhild was the mother of all of Eriks children.Statue of Erik the Red searching for the next adventure. Source: Eirksstadir Living Museum, Bardalur, IcelandLife in Iceland proved far from quiet and pastoral. The troubles began with a landslide that decimated the farm of Valthjof, Erik, and Thjodhilds neighbor. Eriks slaves were accused of intentionally starting the landslide. Valthjofs relative Eyjolf took revenge by murdering Eriks slaves, and Erik retaliated by murdering Eyjolf. He then moved away to another settlement in Iceland, but trouble found Erik once more.Erik moved to an island in west Iceland, and as he was establishing himself, he asked a man named Thorgest to keep his setstokkr that his family had brought with them from Norway. These were ornamental pillars with significant religious value. When Erik finished building his new home, he went to retrieve his pillars, but Thorgest refused to return them, so Erik stole them back. Thorgest and his men pursued Erik, and in the resulting fight, Erik killed Thorgests sons and some other men. This led to a feud between the two men, with both keeping a large number of allies around them. When the problem was eventually resolved at the local Thing gathering in 982 CE, Erik and his allies were banished from Iceland for three years.Aerial view of Norse ruins along the coast of Greenland. Source: UNESCOErik, joined by some of his exiled associates, took to the sea and found a place he had heard of before but never seen: the worlds largest island. It was reportedly discovered almost a century earlier by the Viking Gunnbjorn Ulfsson, who was blown off course off the coast of Iceland. Only a few years before Erik, in the 970s, the outlaw Snaebjorn Galti Homlsteinsson also reportedly tried to settle on Greenland with a group of settlers. However, he was reportedly killed by another settler in a land dispute and the colony imploded due to internal strife.This new place had an extreme environment with some 75% of it covered in ice and less than 25% of the land inhabitable. According to the sagas, in 985 CE, Erik returned to Iceland and convinced some three hundred Vikings to migrate to this new place called Greenland. He apparently chose the name as a marketing ploy to sell the new settlement.Settling InHorses walking through the dramatic environs of Greenland. Source: UNESCOOnce Erik had gathered his party, 25 ships set sail, but eleven sank en route. Once in Greenland, the newcomers established two settlements on the islands southern coast, named the Eastern and Western Settlements. According to the sagas, Erik settled in the Eastern Settlement. The Norse established farms near freshwater sources, where they would be able to farm and raise livestock in the desolate environment.Unlike Iceland, Greenland had been settled before the Vikings arrived. According to the sagas, the first Viking settlers found traces of previous dwellings, boats, and artifacts when they arrived. These belonged to the Dorset people, a Paleo-Eskimo culture that lived across Canada and Greenland from around 500 BCE to the 14th century in the northwest of the island. While the Vikings must have encountered the Dorset people, DNA studies show no evidence of genetic mixing, so intermarriage, between the Dorset people and the Norse, though this is based on a limited mtDNA study of the remains of 16 Dorset people.Qassiarsuk: Home of Erik the Red?Norse ruins in Qassiarsuk, widely believed to be Brattahli. Source: The Mariners Museum, Newport News, VirginiaAccording to the sagas, Erik the Red chose prime farmland in western Eriksfjord for his home. Eriks farm came to be known as Brattahli, meaning steep slope. As the leader of the colonists, Erik held great authority. As such, Brattahli became a place of significance and power in the new Norse world. The sagas also cite Brattahli as the location of one of the first churches in Greenland, following Thjodhilds conversion to Christianity. But how much of the sagas can be believed?Plan of the ruins of Qassiarsuk. Source: National Museum of Denmark, CopenhagenAs habitable land was limited in Greenland, curious explorers began poking around Eriksfjord in the 19th century CE. They found human bones and cloth fragments, but nothing more. Then, in 1926, Danish scholars Poul Nrlund and Aage Roussell uncovered a trapezoid-shaped coffin in Qassiarsuk. When they opened the coffin, it was empty. They continued digging and eventually found a body and a stone with a runic inscription. They had proof that the Vikings had been in Qassiarsuk, but the grave was just the beginning of their discoveries.In 1932, archaeologists led by Poul Nrlund, with the aid of the National Museum of Denmark and Swedish archaeologist Mrten Stenberger, traveled to Greenland. In Eriksfjord, they found ruins of turf and stone and conducted large-scale excavations at the village of Qassiarsuk. Structures consistent with Norse architectural designs emerged from the earth. Initial excavations at Qassiarsuk revealed multiple farms and 18 structures, including dwellings, barns, storehouses, and a church. The site is believed by many to be the legendary Brattahli of the sagas and potentially the home of Erik the Red, though some skepticism remains.Missing StructuresNorse church ruins in Greenland, Source: UNESCOExcavations at Qassiarsuk recovered a whetstone engraved with Thors hammer, suggesting that some of the Norse Greenlanders maintained connections with the Norse pantheon of Viking Age Scandinavia. However, Nrlund and Stenberger also found ruins of a church in Qassiarsuk. This church dates from after the 10th century, suggesting that it is not associated with the story of Erik the Red. Considering the important role that the Greenlandic conversion to Christianity plays in his saga, could there really have been a Brattahli without Thjodhildes Church?Norse ruins in Greenland. Source: UNESCODuring the 1932 excavations at Qassiarsuk, Nrlund uncovered turf and stone walls that he interpreted as structures for temporary visitors, along with tent rings and hearths. This evidence has suggested to some archaeologists that there may have been a possible assembly or Althing site at Qassiarsuk. Written sources record lawmen living at Brattahli, suggesting that it could also have functioned as an assembly site.Animal RemainsArtifacts recovered from a Norse settlement in Greenland. Source: UNESCODuring the 1932 excavations, archaeologists also found a midden or trash deposit filled with animal bones. Greenland was different from medieval Scandinavia in many respects, including its wildlife. In Greenland, walruses, harp seals, and harbor seals frequented the waters. Seal bones are abundant at excavations of Norse farms in Greenland. Middens also contain the bones of caribou, showing that they were hunted as well.Bones of cattle, sheep, and goats attest to the presence of other animals used for dairy products and wool. Chemical analysis shows that the Norse adopted a more marine-based diet over time. Additional analysis has revealed that marine protein was consumed more in the Eastern Settlement than in the Western Settlement.The Vikings also encountered large herds of walrus in Disko Bay. Hunting walrus proved a lucrative enterprise for the Norse, who were invested in the European ivory trade. However, archaeologists are not convinced that the pursuit of walrus was a primary factor in the Norse settlement of Greenland. Rather, research has indicated that at the peak of Norse settlement in Greenland exports of walrus ivory to Europe were high, suggesting that it may have been an unexpected but lucrative market for the settlers.Thjodhildes Church and a Killer EpidemicBurials excavated from a cemetery in Greenland. Source: National Museum of Denmark, CopenhagenIn 1003 CE, a new wave of immigrants arrived in Greenland. They brought much to the island, including a wave of powerful germs. Erik the Red succumbed to an epidemic that ravaged Norse Greenland just as a new millennium dawned. As a pioneering explorer, colonist, murderer, and leader, he is remembered as one of the last of the legendary Vikings. His place of rest remains a mystery.In 1961, the construction of a school hostel in Qassiarsuk encountered human skulls. The bones were sent to a lab, where analysis confirmed that they were from the period of Norse colonization. Excavations began in earnest, and archaeologists and physical anthropologists excavated a small turf church and a burial ground. They excavated 155 burials around the churchyard.Reconstruction of Thjordhildes Church, Greenland. Source: Visit GreenlandAn analysis of the skeletal remains showed that men and women had been segregated, with the women buried in the northern section of the churchyard and the men buried in the southern section of the churchyard. Archaeologists tested nine of the skeletons using radiocarbon dating. The bodies dated to c. 1000-1100/1200 CE. Several aspects of this discovery intrigued those familiar with the saga version of Erik the Red. It looked as if Thjodhildes church had been found at last. If so, could archaeologists expect to find Erik the Red nearby?The Death of Viking GreenlandNorse ruins in Greenland, Source: UNESCOIn the early 1400s CE, Greenland witnessed the wedding of Sigrid Bjornsdottir and Thorstein Olafsson, the burning of a witch at the stake, and the disappearance of the Vikings from the island. Scholars have proposed many theories to explain the Norse vanishing act in Greenland. Most explanations look outside of Greenland to external catalysts. There was a volcanic eruption in the 13th century that cooled the climate, and increased sea ice and ocean storms.Progressive sea level rise may also have changed life in Greenland. Around the same time, European nations opened trade routes with sub-Saharan Africa, where elephants added unprecedented competition to the ivory market. And then there was the plague, which decimated Greenlands European trade partners.Photo of Native Greenlanders taken in 1903. Source: National Library of NorwayWhile any or all of these explanations may have spurred the Viking abandonment of Greenland, scholars remain divided as to whether there was a single dramatic event, a mass exodus, or a gradual population decline. The decline of the Vikings did not leave Greenland unpopulated, as the Thule people migrated into the area and are the ancestors of modern-day native Greenlanders.

Best robot vacuum deal: Save 50% on Shark AI Ultra SAVE $302: As of Aug. 26, the Shark AI Ultra Voice Control Robot Vacuum with Matrix Clean Navigation is down to just $297.99 at Amazon — that’s 50% off its usual $599.99 list price. Finding a good robot vacuum that’s worth the price tag feels like russian roulette, but this half-price bargain...

Best Kindle deal: Save $20 on Kindle at Amazon SAVE $20: As of Aug. 26, Amazon's Kindle (16GB) is on sale for $89.99. This is 18% off its list price of $109.99, saving you $20. Labor Day sales are building some momentum, and Amazon's offering includes some genuinely great deals this year. If you've had a Kindle on your shopping list for some time,...

Best Apple deal: Save $50 on Apple Magic Keyboard SAVE $50: As of Aug. 26, the Apple Magic Keyboard is on sale for $199 at Amazon. That's a 20% saving on the list price. If you’ve been waiting to level up your iPad setup, now’s the time. The Apple Magic Keyboard is back on sale at Amazon, bringing the price down to $199. It’s the easiest way to...