NexPro

nexpro

How to Integrate Next.js with Electron Using React Server Components

A Deterministic Address for an EVM Multi-Chain Proxy

Understanding sync.Cond in Go: A Guide for Beginner's

গো-তে sync.Cond বোঝা: শিক্ষানবিসদের জন্য একটি নির্দেশিকা৷

sync.Cond in Go verstehen: Ein Leitfaden für Anfänger

Comprender sync.Cond in Go: una guía para principiantes

Comprendre sync.Cond in Go : un guide pour les débutants

Go में sync.Cond को समझना: शुरुआती लोगों के लिए एक गाइड

Goのsync.Condを理解する:初心者向けガイド

Go의 sync.Cond 이해: 초보자를 위한 가이드

Compreendendo o sync.Cond in Go: um guia para iniciantes

Понимание sync.Cond в Go: руководство для начинающих

Go'da Sync.Cond'u Anlamak: Yeni Başlayanlar İçin Bir Kılavuz

Tìm hiểu về sync.Cond in Go: Hướng dẫn dành cho người mới bắt đầu

理解 Go 中的 sync.Cond：初学者指南

In nearly all of my recent explorations of Generative AI, I've come to realize how important prompts are. That hasn't necessarily translated me into writing better prompts all the time, but being aware of the problem is at least one step towards correcting it, right? One of the things that I thought would help me personally would be to have a tool to quickly compare and contrast different prompts. Obviously, I could just open up multiple tabs in a browser, but I really wanted something more direct and simplified for my purposes. With that in mind, let me share what I've built. Prompt Tester Prompt Tester is my incredibly imaginatively named tool to... um... test prompts. It begins with one prompt: The idea is that you enter your initial prompt, and then click one or more times to add more prompts. When ready, you can then just click "Generate Results": Before showing some example results, let me talk a bit about how it was built. The Code The backend is an simple Node.js server that handles throwing up the static HTML and responding to the front-end API requests. Once again, I thank Todd Sharp for sharing his initial code with me. Here's the boring simple handling portion: incredibly async function handler(req, res) {
	console.log('Entered handler.', req.method, req.url);

	if(req.method === 'GET' && req.url.indexOf('favicon.ico') === -1) {
		res.writeHead(200, { 'Content-Type':'text/html' });
		res.write(fs.readFileSync('./demo.html'));
		res.end();
	} else if(req.method === 'POST' && req.url === '/api') {

		let body = '';
		req.on('data', chunk => {
			body += chunk.toString();
		});

		req.on('end', async () => {
			body = JSON.parse(body);
			console.log('BODY:\n', JSON.stringify(body, null, '\t'));

			let result = await callGemini(body.prompt);
			res.writeHead(200, { 'Content-Type':'application/json' });
			res.write(JSON.stringify(result));
			res.end();

		});

	}

}

const server = http.createServer(handler);
server.listen(3000);
console.log('Listening on port 3000'); And the part which just passes the prompt off to Google's . In theory, this could be changed to ChatGPT or any other service. callGemini Gemini API const MODEL_NAME = "gemini-pro";
const API_KEY = process.env.GOOGLE_AI_KEY;

const genAI = new GoogleGenerativeAI(API_KEY);
const model = genAI.getGenerativeModel({ model: MODEL_NAME });

async function callGemini(text) {

	const generationConfig = {
		temperature: 0.9,
		topK: 1,
		topP: 1,
		maxOutputTokens: 2048,
	};

	const safetySettings = [
		{ category: HarmCategory.HARM_CATEGORY_HARASSMENT, threshold: HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE, },
		{ category: HarmCategory.HARM_CATEGORY_HATE_SPEECH,	threshold: HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE, },
		{ category: HarmCategory.HARM_CATEGORY_SEXUALLY_EXPLICIT, threshold: HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE, },
		{ category: HarmCategory.HARM_CATEGORY_DANGEROUS_CONTENT, threshold: HarmBlockThreshold.BLOCK_MEDIUM_AND_ABOVE, },
	];

	const parts = [
    	{text},
  	];

	const result = await model.generateContent({
		contents: [{ role: "user", parts }],
		generationConfig,
		safetySettings,
	});

	try {

		if(result.response.promptFeedback && result.response.promptFeedback.blockReason) {

			return { error: `Blocked for ${result.response.promptFeedback.blockReason}` };
		}
		const response = result.response.candidates[0].content.parts[0].text;
		return { response };
	} catch(e) {
		// better handling
		return {
			error:e.message
		}
	}
	
} I'm proud to say that I'm now, finally, doing some basic error handling and trying to expose to the user (me) why a prompt was blocked. The front end is relatively simple. I used for the core CSS (again, thank you Todd) and some vanilla JavaScript to handle adding new prompts and making the calls. Here's the HTML (minus the inline CSS): Milligram <h1>Prompt Tester</h1>

<p>
This tool helps you see the result of multiple prompts at the same time. The idea is to use similar prompts with different phrasing 
to see how it impacts the result.
</p>

<div id="prompts">
</div>

<template id="promptRow">
<div class="row">
	<div class="column column-33"><textarea placeholder="Enter your prompt."></textarea></div>
	<div class="column column-67 result"></div>
</div>
<hr>
</template>


<div class="float-right">
<button id="addPrompt">Add Prompt</button> <button id="generateResults">Generate Results</button>
</div> And then the JavaScript. Notice I used above to handle the prompt layout. This is the first time I've used that tag, and it was relatively easy. <template> let $template, $prompts, $addPromptsBtn, $generateResultsBtn;
let promptCount = 0;

document.addEventListener('DOMContentLoaded', init, false);
async function init() {
	
	$addPromptsBtn = document.querySelector('#addPrompt');
	$addPromptsBtn.addEventListener('click',  addPrompt, false);
	$generateResultsBtn = document.querySelector('#generateResults')
	$generateResultsBtn.addEventListener('click',  generateResults, false);
	$template = document.querySelector('#promptRow');
	$prompts = document.querySelector('#prompts');

	addPrompt();
}

function addPrompt() {
	promptCount++;
	const newPrompt = $template.content.cloneNode(true);
	$prompts.append(newPrompt);
}

async function generateResults() {
	// disable add prompt and generate
	$addPromptsBtn.setAttribute('disabled', 'disabled');
	$generateResultsBtn.setAttribute('disabled', 'disabled');

	let $results = document.querySelectorAll('div.result');
	// clear any previous results
	$results.forEach(r => r.innerHTML = '');

	/*
	gather prompts from the inputs
	*/
	let prompts = [];
	let $fields = document.querySelectorAll('#prompts textarea');
	for(f of $fields) prompts.push(f.value);

	let promises = [];
	for(p of prompts) promises.push(getResult(p));
	let results = await Promise.all(promises);

	// assign results to result area for each, handle errors - later
	// there's a one to one correspondance between our array of results and the result div
	for(let i=0;i<results.length;i++) {
		if(results[i].response) $results[i].innerHTML = marked.parse(results[i].response);
		else if(results[i].error) $results[i].innerHTML = `<strong>Error with Prompt: </strong> ${results[i].error}`;
	}

	$addPromptsBtn.removeAttribute('disabled');
	$generateResultsBtn.removeAttribute('disabled');

}

async function getResult(p) {
	console.log('get result for',p);
	// quick return on empty prompt
	if(p.trim() === '') return { response:'<strong>Enter a prompt.</strong>' };
	let req = await fetch('/api', { method:'POST', body: JSON.stringify({prompt:p.trim()})});
	let result = await req.json();
	return result;
} I that's all pretty simple DOM manipulation and API calling, but definitely let me know in a comment below if something doesn't make sense. Notice I fire off all my API calls at once and wait for them to finish. think Promise.all Also, note I use the library. The results from Google typically have Markdown, and this helps render them nicely in my little web app. marked All of this isn't terribly interesting I think, but let's look at some testing. As I said, I the style of prompt was important. Having it presented directly to me in a tool went a of a long way to reinforcing that. knew heck Sample Result - Gravity Let's start with a simple idea - explaining gravity but for different age groups. Because of the large size of the results, I'm going to use a bit of CSS here to help keep things sane. Prompt: explain gravity to me but make it appropriate for a child in 1st grade Gravity is a superpower that our planet has! It's like an invisible force that makes everything on Earth stay on the ground. Imagine you have a ball in your hand. When you drop it, what happens? It falls down, right? That's because of gravity. Gravity pulls the ball towards the center of the Earth, and so it falls to the ground. Gravity is also what keeps us on the ground. It's what keeps our feet planted firmly on the Earth and prevents us from floating away! Gravity is a very important force. It keeps everything in place and helps things work the way they do. Without gravity, we would all be floating around in space, and things would be very chaotic! Here's a fun way to think about gravity: imagine that the Earth is a giant magnet, and everything on Earth is made of metal. The magnet pulls the metal objects towards it, and that's what keeps them on the ground. Gravity is a very important and interesting force. It's one of the things that makes our planet such a unique and special place to live! Prompt: explain gravity to me but make it appropriate for a child in 7th grade Imagine you're playing with a ball. You toss it up in the air, and it comes back down to you. This is because of gravity. Gravity is a force that pulls things toward each other. It's what keeps you on the ground and what makes things fall down. The amount of gravity between two objects depends on their mass. The more mass an object has, the stronger its gravity is. That's why things like planets and stars have more gravity than things like people and cars. Gravity is also what keeps the planets in orbit around the sun. The sun's gravity is much stronger than the Earth's, so it pulls the Earth towards it. This keeps the Earth moving in a circle around the sun. Gravity is a very important force in our universe. It keeps things in place and makes things move. Without gravity, the planets would fly off into space, and we would all float away. Here are some fun facts about gravity: Gravity is responsible for the tides. The moon's gravity pulls on Earth's oceans, causing them to rise and fall. Gravity is the reason why we have an atmosphere. Without gravity, the air would just float away into space. Gravity is what makes it possible for us to walk. When we walk, our feet push against the ground, and the ground pushes back. This is what propels us forward. Gravity is the reason why we don't float away into space. Earth's gravity pulls us towards its center, keeping us on the ground. Note the typo in the prompt below. Gemini handled it just fine. Prompt: explain gravity to me but make it appropriate for a college-aged student Gravity: The Force of Attraction Gravity is a fundamental force in the universe responsible for keeping celestial bodies, such as planets, moons, and stars, in motion. It is also what keeps us firmly planted to the ground and allows objects to fall when dropped. Newton's Law of Universal Gravitation: The law of universal gravitation states that every object in the universe attracts every other object with a force proportional to the product of their masses and inversely proportional to the square of the distance between them. Mathematically, it can be expressed as: F = Gm1m2/r^2 Where: F is the gravitational force between two objects. G is the gravitational constant (6.674 × 10^-11 N m^2/kg^2). m1 and m2 are the masses of the two objects. r is the distance between the centers of the two objects. Significance of Gravity: The gravitational pull of larger celestial bodies keeps smaller ones revolving around them. For example, Earth's gravity keeps the moon in orbit, while Sun's gravity keeps Earth and other planets in their respective orbits. Keeps Celestial Bodies in Orbit: Gravity between the Earth and the moon causes ocean tides. As the moon orbits Earth, its gravitational pull creates a bulge in the ocean's water on the side facing the moon. Another bulge forms on the opposite side of Earth due to the inertial forces. As the Earth rotates, these bulges move across the planet's surface, resulting in high and low tides. Responsible for Tides: Gravity pulls objects towards Earth's center, preventing them from floating away. This phenomenon allows us to walk, stand, and interact with our environment. Keeps Objects on Earth: Gravity plays a crucial role in the formation of stars and galaxies. The gravitational collapse of massive clouds of gas and dust leads to the creation of new stars. Similarly, the gravitational pull of galaxies keeps them bound together, preventing them from dispersing. Formation of Stars and Galaxies: Albert Einstein's general relativity theory provides a more comprehensive understanding of gravity. It explains that gravity is not a force but rather a curvature of spacetime caused by the presence of mass or energy. This curvature affects the motion of objects, causing them to follow curved paths rather than straight lines. Relativity Theory: In conclusion, gravity is a fundamental force responsible for keeping celestial bodies in motion, tides, and the behavior of objects on Earth. It is a complex phenomenon that has been studied extensively over the centuries, and it continues to fascinate scientists and researchers to this day. Sample Result - Pets For my second test, I started with a basic prompt and then a better version that asked for specific types of details: (Quick editorial note - the tabular data below is a bit messy, but was messy in the original output.) not Prompt: why are cats so much better than dogs? Cats and dogs are both popular pets, and there is no definitive answer to the question of which one is better. Both cats and dogs have their own unique set of advantages and disadvantages, and the best pet for you will depend on your individual needs and preferences. Some people prefer cats because they are generally more independent than dogs. Cats are typically happy to entertain themselves, and they don't need to be walked or taken outside for exercise. This can be a big advantage for people who live in apartments or who have busy schedules. Cats are also known for being clean and tidy animals. They groom themselves regularly, and they typically use the litter box without any problems. This can be a big advantage for people who don't want to deal with the mess and smell of a dog. Of course, there are also some disadvantages to having a cat. Cats can be more expensive than dogs, and they can be more difficult to train. Cats are also more likely to scratch furniture and other household items. Ultimately, the decision of whether to get a cat or a dog is a personal one. There is no right or wrong answer, and the best pet for you will depend on your individual needs and preferences. Here is a table summarizing the key differences between cats and dogs: Characteristic Cat Dog Independence More independent Less independent Exercise needs Does not need to be walked or taken outside Needs to be walked or taken outside Cleanliness Cleans itself regularly Needs to be bathed regularly Training Can be difficult to train Easier to train Scratching May scratch furniture and other household items Does not typically scratch furniture Cost More expensive Less expensive Prompt: why are cats so much better than dogs? explain with a bulleted list of reasons that cover emotional well being and financial aspects Emotional well-being: Independence: Cats are more independent than dogs, which can be a good thing for people who want a pet that doesn't require a lot of attention. Low maintenance: Cats are generally lower maintenance than dogs. They don't need to be walked or groomed as often, and they can be left alone for longer periods of time. Quiet: Cats are generally quieter than dogs, which can be ideal for people who live in apartments or have noise-sensitive neighbors. Therapeutic: Studies have shown that cats can have a calming effect on humans, and they can help to reduce stress and anxiety. Financial aspects: Lower cost: Cats are generally less expensive to own than dogs. They eat less food, they need fewer vet visits, and they don't require as much grooming. Easier to travel with: Cats are easier to travel with than dogs. They can be transported in a carrier, and they don't need to be walked or exercised while you're away. Longer lifespan: Cats have a longer lifespan than dogs, on average. This means that you can enjoy your cat's companionship for many years to come. Sample Result - Chain of Thought Prompting The following test came from an presentation from AWS re:Invent: . I found a lot of great advice from this session, including a good overview of Chain of Thought prompting, where the idea is you provide information about the steps used to solve a problem to help the GenAI engine better solve a prompt. excellent AWS re:Invent 2023 - Prompt engineering best practices for LLMs on Amazon Bedrock (AIM377) Now, the example given in that presentation went like so: Q: Roger has 5 tennis balls. he buys 2 more cans of tennis balls. Each 
can has 3 tennis balls. How many tennis balls does he have now?

A: The answer is 11.

Q. The cafeteria had 23 apples. If they used 20 to make lunch and 
bought 6 more, how many apples do they have? In the presentation, the model in use incorrectly returned 27. In my test, it worked correctly, but I absolutely saw issues with math back when I built my last November. generative AI blackjack advice demo As I said, Gemini handled it fine: But in Prompt Tester, I tried the suggested CoT prompt: A: The answer is 9. Q: Roger has 5 tennis balls. he buys 2 more cans of tennis balls. Each 
can has 3 tennis balls. How many tennis balls does he have now?

A: Roger started with 5 balls. 2 cans of 3 tennis balls each is 6 
tennis balls. 5 + 6 = 11. The answer is 11.

Q. The cafeteria had 23 apples. If they used 20 to make lunch and 
bought 6 more, how many apples do they have? And the result was improved, showing how it got to the answer: A: The cafeteria had 23 apples. They used 20 apples for lunch, which 
means they have 3 apples left. They then bought 6 more apples, so 
they now have a total of 3 + 6 = 9 apples.

The answer is 9. The difference is pretty significant. The Code If this seems useful to you at all, feel free to grab the code from here: . As I mentioned, it shouldn't be that difficult to add or some such and use a different service. If you do, let me know! https://github.com/cfjedimaster/ai-testingzone/tree/main/prompt_tester callChatGPT

How to Test Multiple Variations of Generative AI Prompts

জেনারেটিভ এআই প্রম্পটগুলির একাধিক বৈচিত্র কীভাবে পরীক্ষা করবেন

So testen Sie mehrere Variationen generativer KI-Eingabeaufforderungen

Cómo probar múltiples variaciones de indicaciones de IA generativa

Comment tester plusieurs variantes d'invites d'IA générative

जेनरेटिव एआई प्रॉम्प्ट के एकाधिक विविधताओं का परीक्षण कैसे करें

生成 AI プロンプトの複数のバリエーションをテストする方法

Generative AI 프롬프트의 다양한 변형을 테스트하는 방법

Como testar múltiplas variações de prompts de IA generativos

Как протестировать несколько вариантов подсказок генеративного ИИ

Üretken Yapay Zeka İstemlerinin Çoklu Varyasyonlarını Test Etme

Cách kiểm tra nhiều biến thể của lời nhắc AI sáng tạo

如何测试生成式 AI 提示的多种变体

This paper is available on arxiv under CC 4.0 license. Authors: (1) Eleonora Alei, ETH Zurich, Institute for Particle Physics & Astrophysics & National Center of Competence in Research PlanetS; (2) Björn S. Konrad, ETH Zurich, Institute for Particle Physics & Astrophysics & National Center of Competence in Research PlanetS; (3) Daniel Angerhausen, ETH Zurich, Institute for Particle Physics & Astrophysics, National Center of Competence in Research PlanetS & Blue Marble Space Institute of Science; (4) John Lee Grenfell, Department of Extrasolar Planets and Atmospheres (EPA), Institute for Planetary Research (PF), German Aerospace Centre (DLR) (5) Paul Mollière, Max-Planck-Institut für Astronomie; (6) Sascha P. Quanz, ETH Zurich, Institute for Particle Physics & Astrophysics & National Center of Competence in Research PlanetS; (7) Sarah Rugheimer, Department of Physics, University of Oxford; (8) Fabian Wunderlich, Department of Extrasolar Planets and Atmospheres (EPA), Institute for Planetary Research (PF), German Aerospace Centre (DLR); (9) LIFE collaboration, www.life-space-mission.com. Table of Links Abstract & Introduction Methods Results Discussion Conclusions Next Steps & References Appendix A: Scattering of terrestrial exoplanets Appendix B: Corner Plots Appendix C: Bayes’ factor analysis: other epochs Appendix D: Cloudy scenarios: additional figures 2. Methods We start by discussing the details of the input spectra that were used in this study (Section 2.1). We then discuss the updates on the Bayesian retrieval routine (Section 2.2). We describe the assumptions that our model takes into account and the main potential source of systematic errors in the retrievals in Section 2.3. 2.1. Input spectra and scenarios We consider spectra corresponding to four different evolutionary epochs of Earth: the prebiotic Earth (3.9 Ga), the Earth shortly after the Great Oxygenation Event (2.0 Ga), the Neoproterozoic Oxygenation Event (0.8 Ga), and Modern Earth. All considered Earth spectra were produced by Rugheimer & Kaltenegger (2018). These self-consistent spectra were produced using a 1D convective-radiative transfer model loosely coupled with a 1D climate model and a 1D photochemistry model. The authors accounted for the thermal chemistry and the photochemistry of more than 55 species. The atmospheres were modeled up to 10−4 bar and split into 100 layers. The radiative forcing of clouds is included by adjusting the surface albedo of the planet. The results of the photochemistry-climate-radiative model were then fed to a line-by-line radiative transfer model to produce emission spectra. The line lists and the pressure broadening coefficients were from to the HITRAN 2016 database (Gordon et al. 2017). Surface scattering was included in the calculations, assuming 70% ocean, 2% coast, and 28% land. In some scenarios, a partial cloud coverage was directly included in the calculation of the emission spectrum. In these cloudy cases, the authors assumed a 60% cloud coverage (split into 40% water clouds at 1 km altitude, 40% water clouds at 6 km altitude, and 20% ice clouds at 12 km altitude) consistent with an averaged Earth cloud model. Aerosol was not included in the calculation. The model has been validated from the visual to the mid-infrared wavelength ranges with observations of Earth (Kaltenegger et al. 2007; Kaltenegger & Traub 2009; Rugheimer et al. 2013). For further details, we refer the reader to Rugheimer & Kaltenegger (2018). For each epoch, we consider both clear sky and cloudy sky spectra, which yields a total of 8 scenarios. We assigned every modeled scenario an identifier and a specific color, as listed in Table 1. We will use these identifiers throughout the remainder of the paper. We simulate observations with LIFE via the LIFEsim tool (see Paper II for a description of the simulator). LIFEsim estimates the wavelength-dependent S/N considering all major astrophysical noise sources (stellar leakage, local zodiacal dust emission, and exo-zodiacal dust emission). We consider an Earth-sized planet on a 1 AU orbit around a Sun-like star at 10 pc distance. For our baseline analyses we assumed the nominal simulation parameters for LIFEsim as summarized in Table 2 (see Paper I and Paper II for details). We consider an exo-zodi level of 3 times the local zodiacal dust density, based on the results from the HOSTS survey (Ertel et al. 2020). 2.2. Updates on the Bayesian retrieval framework We denote the input spectra from Section 2.1 as the "true spectra." To simulate a LIFE-like observation of these targets, we run LIFEsim on the true spectra, thus obtaining simulated "observed spectra." We then perform a retrieval on the observed spectra using petitRADTRANS (Mollière et al. 2019) as "forward model" in the retrieval routine, and the Bayesian sampler model pyMultiNest (Buchner et al. 2014) as "parameter estimation routine" (cf. Paper III). The theoretical 1D atmospheric model petitRADTRANS (Mollière et al. 2019) applies the radiative transfer equation to calculate spectra corresponding to a set of parameters. These parameters describe the bulk parameters (planetary mass and radius), the pressure-temperature (P-T) structure (approximated by a fourth-order polynomial), and the chemical composition of the atmosphere. Our Bayesian retrieval framework recursively draws combinations of parameters from a set of "priors" that describe the "a priori" probability distribution of each parameter (listed in Table 3) and uses the forward model to compute the corresponding spectra. Then, the Bayesian framework tests how well these calculated spectra fit the observed one using a "likelihood" function (see Eq. (3) in Paper III). In order to sample the prior space efficiently, our retrieval relies on the parameter estimation routine pyMultiNest (Buchner et al. 2014), which is based on MultiNest (Feroz et al. 2009). This routine applies the Nested Sampling algorithm (Skilling 2006) to fit the theoretical spectral model to the observed spectrum, and thereby yields estimates and uncertainties for the model parameters. These estimates are the "posterior probability distributions" (or "posteriors"). The posteriors contain the information on which combinations of model parameters best describe the observed spectrum. For more details about the Bayesian retrieval framework, we refer the reader to Paper III. In our previous work, we argued that effects of scattering on simulated mid-infrared spectra are negligible at the considered resolutions and LIFEsim noise patterns. In that study, we had to be particularly mindful of the computing time. The version of petitRADTRANS used in Paper III only allowed to calculate spectra at R = 1000, which were subsequently binned down to the resolution of the input spectrum (R = 35 − 100 in Paper III). Calculating a spectrum at R = 1000 excluding scattering required ≈ 0.5 seconds, whereas including scattering required ≈ 18 seconds. Since millions of spectra have to be calculated for a single Bayesian retrieval, including scattering was prohibitive with respect to the computing time, especially when considering a large grid of retrieval runs. Recent updates to petitRADTRANS have enabled us to compute spectra at any resolution, provided a grid of correlated-k tables at that resolution is available. These tables can be produced with petitRADTRANS by binning down the R = 1000 opacity tables. We compiled a correlated-k opacity database for R = 50 and used it to produce spectra directly at this resolution. This reduces the computation time per spectrum significantly and allows us to compute emission spectra in ≈ 0.04 seconds when excluding scattering, and in ≈ 0.5 seconds when including scattering. This reduction in computing time allows us to include scattering in the theoretical spectral model. Other updates on petitRADTRANS were performed. The treatment of collision-induced absorption (CIA) was modified by updating the interpolation of the CIA tables, originally in FORTRAN, to Python. Minor variations in the interpolation options (log-linear compared to nearest neighbor in Paper III) make the new model not directly comparable with its previous version. However, at Earth-like conditions, the differences in the CIA signature on the spectrum remain negligible. Also, the CIA features impact mostly the short wavelengths (λ < 6 µm), where the LIFEsim noise is large. Furthermore, the treatment of scattering was updated. Originally implemented in petitRADTRANS only for gaseous planets (see Mollière et al. 2019), it was adapted to include the scattering by a rocky surface. More information on the new implementation of scattering can be found in Appendix A, as well as the petitRADTRANS documentation[3] . This new version of petitRADTRANS is available in the main GitLab repository[4] . Using the updated retrieval framework, we run retrievals for the eight different spectra introduced in Section 2.1. We retrieve the same parameters as in Paper III and leave most prior distributions unchanged. An exhaustive list of the parameters and priors used, and the corresponding expected values for the different epochs, are listed in Table 3. Most priors are represented by a boxcar function (hereafter "uniform" priors): every value is equally probable if within a certain range. Two notable exceptions are the priors for the planetary radius Rpl and the logarithm of the planetary mass log10(Mpl), whose priors are Gaussian. The prior we assumed on Rpl is based on the radius estimate expected from observing a terrestrial planet with LIFE during its search phase (see Paper II for details). The log10(Mpl) prior was inferred from Rpl using the statistical mass-radius relation presented in Chen & Kipping (2016) (see Paper III for details). 2.3. Assumptions and discrepancies When performing retrievals, we are limited by the maximum number of parameters retrieved in a reasonable computing time. For this reason, we need to make a few simplifications: 1. As in Paper III, we parameterize the P-T profile in the retrieval by a fourth order polynomial. Table 2: Simulation parameters used in LIFEsim for the baseline analyses. 2. We assume the abundances of the considered species to be independent of altitude. 3. Our retrieval framework does not model clouds for any of the considered scenarios. This is a strong simplification for the cases where we retrieve cloudy input spectra. However, this retrieval approach allows us to investigate the biases on the results obtained when retrieving a cloudy spectrum assuming a cloud-free atmosphere. The addition of a cloud model to our retrieval framework will be tackled in a future study 4. A surface reflectance of 0.1 is assumed for all the wavelength range. This is a common value for water-rich habitable terrestrial planets, dominated by the low IR reflectance of oceans and ice. In contrast, Rugheimer & Kaltenegger (2018) used P-T profiles that were self-consistently calculated by their climatephotochemistry model to generate the input spectra. The chemical abundance profiles were also altitude-dependent and calculated self-consistently by the climate-photochemistry model. In order to compare the results of the retrievals with the input, we approximate the input P-T and abundance profiles to calculate expected values of the parameters considered in the retrievals. Regarding the thermal structure of the atmosphere, we determine the expected values of the polynomial coefficients (a4, a3, a2, a1, a0) listed in Table 3 by fitting a fourth-order polynomial to the self-consistent P-T profiles. As for the abundances, we assume the weighted means over the pressure grid of the altitude-dependent abundance profiles. This is sensible, since the denser layers of the atmosphere (which corresponds to higher pressures) are generally the ones that contribute more to the spectrum. The expected values for the considered species are listed in Table 3 as well. For what concerns the surface reflectance, Rugheimer & Kaltenegger (2018) considered a wavelength-dependent reflectance. However, the reflectance still averaged to 0.1 in the wavelength range of interest. We would therefore not expect large variations due to this parameter. There are also differences between the opacity tables that the two models use. We used the default set of opacities for petitRADTRANS as presented in Mollière et al. (2019). We added the N2O opacity from the ExoMol database (Chubb et al. 2021). The CIA opacities are taken from the HITRAN database. Details and reference papers corresponding to the opacity linelists are shown in Tables 4 and 5. In contrast, the input spectra were calculated using HITRAN 2016 opacities (Rugheimer & Kaltenegger 2018). Differences in line-lists and broadening coefficients are therefore to be expected and may cause biases in the results. Due to these differences in the atmospheric models, we would imagine to find some small discrepancies between the spectra that were published in Rugheimer & Kaltenegger (2018) and the ones that our framework can calculate. We will discuss this particular aspect in Section 4.4. [3] https://petitradtrans.readthedocs.io [4] https://gitlab.com/mauricemolli/petitRADTRANS This paper is available on under CC 4.0 license. arxiv

The Methods in Which We're Researching Exoplanets

This paper is available on arxiv under CC 4.0 license. Authors: (1) Eleonora Alei, ETH Zurich, Institute for Particle Physics & Astrophysics & National Center of Competence in Research PlanetS; (2) Björn S. Konrad, ETH Zurich, Institute for Particle Physics & Astrophysics & National Center of Competence in Research PlanetS; (3) Daniel Angerhausen, ETH Zurich, Institute for Particle Physics & Astrophysics, National Center of Competence in Research PlanetS & Blue Marble Space Institute of Science; (4) John Lee Grenfell, Department of Extrasolar Planets and Atmospheres (EPA), Institute for Planetary Research (PF), German Aerospace Centre (DLR) (5) Paul Mollière, Max-Planck-Institut für Astronomie; (6) Sascha P. Quanz, ETH Zurich, Institute for Particle Physics & Astrophysics & National Center of Competence in Research PlanetS; (7) Sarah Rugheimer, Department of Physics, University of Oxford; (8) Fabian Wunderlich, Department of Extrasolar Planets and Atmospheres (EPA), Institute for Planetary Research (PF), German Aerospace Centre (DLR); (9) LIFE collaboration, www.life-space-mission.com. Table of Links Abstract & Introduction Methods Results Discussion Conclusions Next Steps & References Appendix A: Scattering of terrestrial exoplanets Appendix B: Corner Plots Appendix C: Bayes’ factor analysis: other epochs Appendix D: Cloudy scenarios: additional figures ABSTRACT Context. An important future goal in exoplanetology is to detect and characterize potentially habitable planets. Concepts for future space missions have already been proposed: from a large UV-Optical-Infrared space mission for studies in reflected light, to the Large Interferometer for Exoplanets (LIFE) for analyzing the thermal portion of the planetary spectrum. Using nulling interferometry, LIFE will allow us to constrain the radius and effective temperature of (terrestrial) exoplanets, as well as provide unique information about their atmospheric structure and composition. Aims. We explore the potential of LIFE in characterizing emission spectra of Earth at various stages of its evolution. This allows us (1) to test the robustness of Bayesian atmospheric retrieval frameworks when branching out from a Modern Earth scenario while still remaining in the realm of habitable (and inhabited) exoplanets, and (2) to refine the science requirements for LIFE for the detection and characterization of habitable, terrestrial exoplanets. Methods. We perform Bayesian retrievals on simulated spectra of 8 different scenarios, which correspond to cloud-free and cloudy spectra of four different epochs of the evolution of the Earth. Assuming a distance of 10 pc and a Sun-like host star, we simulate observations obtained with LIFE using its simulator LIFEsim, considering all major astrophysical noise sources. Results. With the nominal spectral resolution (R = 50) and signal-to-noise ratio (assumed to be S/N = 10 at 11.2 µm), we can identify the main spectral features of all the analyzed scenarios (most notably CO2, H2O, O3, CH4). This allows us to distinguish between inhabited and lifeless scenarios. Results suggest that particularly O3 and CH4 yield an improved abundance estimate by doubling the S/N from 10 to 20. Neglecting clouds in the retrieval still allows for a correct characterization of the atmospheric composition. However, correct cloud modeling is necessary to avoid biases in the retrieval of the correct thermal structure. Conclusions. From this analysis, we conclude that the baseline requirements for R and S/N are sufficient for LIFE to detect O3 and CH4 in the atmosphere of an Earth-like planet with an abundance of O2 of around 2% in volume mixing ratio. Doubling the S/N would allow a clearer detection of these species at lower abundances. This information is relevant in terms of the LIFE mission planning. We also conclude that cloud-free retrievals of cloudy planets can be used to characterize the atmospheric composition of terrestrial habitable planets, but not the thermal structure of the atmosphere. From the inter-model comparison performed, we deduce that differences in the opacity tables (caused by e.g. a different line wing treatment) may be an important source of systematic errors. Methods: statistical – Planets and satellites: terrestrial planets – Planets and satellites: atmospheres Keywords. 1. Introduction Temperate terrestrial exoplanets are predicted to be very abundant in our galaxy (Bryson et al. 2021). These planets are ideal candidates when searching for life beyond our Solar System. A powerful way to characterize a terrestrial exoplanet in the context of its habitability is by detecting and studying its atmosphere with the goal to constrain its surface conditions. Atmospheric spectra are influenced by many parameter and processes, such as the chemical composition, the temperature structure of the atmosphere, the presence of clouds, as well as emission and scattering from the surface. The detection and characterization of potentially habitable, rocky exoplanets is challenging with current facilities. For this reason, there is a widespread interest in the community to build new instruments for the search of life in the universe, as reported in the White Paper series in the context of the ESA “Voyage 2050” process[1] , as well as the US Astro 2020 Decadal survey (National Academies of Sciences, Engineering, and Medicine 2021). Space missions that aim at characterizing terrestrial exoplanets have been proposed, such as HabEx (Gaudi et al. 2020) and LUVOIR (Peterson et al. 2017) focusing on the reflected (visible and near-infrared) portion of the planetary spectrum, as well as LIFE (Large Interferometer for Exoplanets, Quanz et al. 2021, hereafter Paper I), which will characterize terrestrial planets in the thermal (mid-infrared), emitted portion of the planetary spectrum. Using nulling interferometry, LIFE will allow us to constrain the radius and effective temperature of (terrestrial) exoplanets, as well as provide unique information about their atmospheric structure and composition (Dannert et al. 2022; Konrad et al. 2021, hereafter Paper II and III, respectively). Due to the current lack of high-quality observational data, we must rely momentarily on simulated observations of terrestrial planets to create and improve the analyses algorithms, but also to provide scientific and technical requirements when planning a mission. This effort is currently ongoing within the LIFE Initiative and in a previous study (Paper III), we built a Bayesian retrieval routine to estimate the planetary and atmospheric parameters of a simulated Modern Earth twin at 10 pc distance as it would be observed by LIFE. In this work, we extend this exercise to other stages in the evolution of Earth’s atmosphere. Our planet has been habitable for about 4.4 billion years (see e.g. Heller et al. 2021, and references therein). In this context, we define a planet as habitable if its physical and chemical conditions would allow water, if present, to be liquid on the surface. In the prebiotic stage of Earth’s evolution, the atmosphere lacked O2 (currently about 21% of the atmospheric composition by volume). It was instead a CO2-N2-H2O-rich atmosphere, with traces of CH4 from volcanism. The early forms of life developed under a reducing environment and survived under anaerobic conditions (Olson et al. 2018, and references therein). Methanogenesis was thought to be a dominant metabolism at this stage (around 3.5 Ga), which would explain the increase in CH4 in the atmosphere (see e.g. Wolfe & Fournier 2018). Around 3 Ga, life forms that could use carbon dioxide to produce oxygen (via oxygenic photosynthesis) appeared (Marais 2000). These eventually led to a significant increase of O2 maximally up to ∼ 1% PAL[2] (see Gregory et al. 2021; Lyons et al. 2014, 2021, and references therein) around 2.33 Ga (Luo et al. 2016), during the so-called "Great Oxygenation Event" (GOE). There is also evidence pointing to a second increase in the O2 abundance (up to ∼ 10% PAL) occurred around 0.8 Ga, in the "Neoproterozoic Oxygenation Event" (NOE) (Shields-Zhou & Och 2011; Campbell & Squire 2010). The high abundance of carbon dioxide in the early Earth would have enhanced the atmospheric greenhouse effect, allowing Earth to be habitable despite the fainter solar irradiation (see e.g. Feulner 2012, and references therein). The positive feedback between the carbon-silicate cycle and the increase in irradiation would have then allowed to maintain temperatures conducent to liquid water over the last 4 Ga. The increase in irradiation from the Sun over the eons has made the weathering of CO2 more efficient, decreasing the amount of carbon dioxide in the atmosphere and thus dampening the atmospheric greenhouse effect (see e.g. Graham 2021, and references therein). The appearance of photosynthetic life forms and the onset of plate tectonics also contributed to the depletion of atmospheric CO2. Numerous processes including biology and geology have driven the wide-ranging evolution of Earth’s atmosphere during the various epochs of its development. Our modern atmosphere represents however only a small fraction of Earth’s evolutionary states. It is therefore important to simulate a suitable range of different atmospheric epochs from Earth’s history when in vestigating Earth-like atmospheres. For this study, we simulated observations obtained by LIFE starting from theoretical spectra of 4 distinct epochs of Earth’s atmospheric evolution, produced from a self-consistent 1D climate and photochemistry model coupled with a line-by-line radiative transfer model (Rugheimer & Kaltenegger 2018). The observed spectra were simulated using the LIFE noise simulator LIFEsim (for details on the simulator see Paper II). We then used the Bayesian retrieval routine presented in Paper III to characterize the different atmospheres. We aim to address the following research questions: – science-driven questions: How well could LIFE characterize atmospheres of habitable planets? Could LIFE differentiate between different atmospheres, and with what confidence? What is the impact of clouds on this assessment? What are the most promising (combinations of) detectable biosignatures? – technology- and computationally-driven questions: Is the combination of spectral resolution (R = λ/∆λ), signal to noise ratio (S/N) and wavelength range defined in Paper III still adequate for this case study? What are the caveats and limitations of the Bayesian retrieval routine? What systematics may arise when comparing two different models (e.g. in terms of differences in line lists, scattering treatment, identification of biomarkers)? We discuss how we adapted the input spectra to simulate LIFE observations and describe the grid of scenarios in Section 2. We show and describe the results in Section 3. A thorough discussion of our findings and of the potential systematic uncertainties of the retrieval routine is provided in Section 4. In Section 5 we report the main takeaway points from this study, and in Section 6 we trace an outlook of the ongoing and future studies. [1] https://www.cosmos.esa.int/web/voyage-2050 [2] Present Atmospheric Level This paper is available on under CC 4.0 license. arxiv

Large Interferometer For Exoplanets (LIFE): Looking Beyond the Stars

How to Integrate React and AngularJS via Webpack Module Federation

When we think of debugging, we think of breakpoints in IDEs, stepping over, inspecting variables, etc. However, there are instances where stepping outside the conventional confines of an IDE becomes essential to track and resolve complex issues. This is where tools like DTrace come into play, offering a more nuanced and powerful approach to debugging than traditional methods. This blog post delves into the intricacies of DTrace, an innovative tool that has reshaped the landscape of and system analysis. debugging https://youtu.be/3M0AhZnVoUk?embedable=true As a side note, if you like the content of this and the other posts in this series, check out my that covers this subject. If you have friends who are learning to code, I'd appreciate a reference to my . If you want to get back to Java after a while, check out my Debugging book Java Basics book Java 8 to 21 book . DTrace Overview DTrace was first introduced by Sun Microsystems in 2004. DTrace quickly garnered attention for its groundbreaking approach to dynamic system tracing. Originally developed for Solaris, it has since been ported to various platforms, including MacOS, Windows, and Linux. DTrace stands out as a dynamic tracing framework that enables deep inspection of live systems – from operating systems to running applications. Its capacity to provide real-time insights into system and application behavior without significant performance degradation marks it as a revolutionary tool in the domain of system diagnostics and debugging. Understanding DTrace’s Capabilities DTrace, short for Dynamic Tracing, is a comprehensive toolkit for real-time system monitoring and debugging, offering an array of capabilities that span across different levels of system operation. Its versatility lies in its ability to provide insights into both high-level system performance and detailed process-level activities. System Monitoring and Analysis At its core, DTrace excels in monitoring various system-level operations. It can trace system calls, file system activities, and network operations. This enables developers and system administrators to observe the interactions between the operating system and the applications running on it. For instance, DTrace can identify which files a process accesses, monitor network requests, and even trace system calls to provide a detailed view of what's happening within the system. Process and Performance Analysis Beyond system-level monitoring, DTrace is particularly adept at dissecting individual processes. It can provide detailed information about process execution, including CPU and memory usage, helping to pinpoint performance bottlenecks or memory leaks. This granular level of detail is invaluable for performance tuning and debugging complex software issues. Customizability and Flexibility One of the most powerful aspects of DTrace is its customizability. With a scripting language based on C syntax, DTrace allows the creation of customized scripts to probe specific aspects of system behavior. This flexibility means that it can be adapted to a wide range of debugging scenarios, making it a versatile tool in a developer’s arsenal. Real-World Applications In practical terms, DTrace can be used to diagnose elusive performance issues, track down resource leaks, or understand complex interactions between different system components. For example, it can be used to determine the cause of a slow file operation, analyze the reasons behind a process crash, or understand the system impact of a new software deployment. Performance and Compatibility of DTrace A standout feature of DTrace is its ability to operate with remarkable efficiency. Despite its deep system integration, DTrace is designed to have minimal impact on overall system performance. This efficiency makes it a feasible tool for use in live production environments, where maintaining system stability and performance is crucial. Its non-intrusive nature allows developers and system administrators to conduct thorough debugging and performance analysis without the worry of significantly slowing down or disrupting the normal operation of the system. Cross-Platform Compatibility Originally developed for Solaris, DTrace has evolved into a cross-platform tool, with adaptations available for MacOS, Windows, and various . Each platform presents its own set of features and limitations. For instance, while DTrace is a native component in Solaris and MacOS, its implementation in Linux often requires a specialized build due to kernel support and licensing considerations. Linux distributions Compatibility Challenges on MacOS On MacOS, DTrace's functionality intersects with System Integrity Protection (SIP), a security feature designed to prevent potentially harmful actions. To utilize DTrace effectively, users may need to disable SIP, which should be done with caution. This process involves booting into recovery mode and executing specific commands, a step that highlights the need for a careful approach when working with such powerful system-level tools. We can disable SIP using the command: csrutil disable We can optionally use a more refined approach of enabling SIP without dtrace using the following command: csrutil enable --without dtrace Be extra careful when issuing these commands and when working on machines where dtrace is enabled. Back up your data properly! Customizability and Flexibility of DTrace A key feature that sets DTrace apart in the realm of system monitoring tools is its highly customizable nature. DTrace employs a scripting language that bears similarity to C syntax, offering users the ability to craft detailed and specific diagnostic scripts. This scripting capability allows for the creation of custom probes that can be fine-tuned to target particular aspects of system behavior, providing precise and relevant data. Adaptability to Various Scenarios The flexibility of DTrace's scripting language means it can adapt to a multitude of debugging scenarios. Whether it's tracking down memory leaks, analyzing CPU usage, or monitoring I/O operations, DTrace can be configured to provide insights tailored to the specific needs of the task. This adaptability makes it an invaluable tool for both developers and system administrators who require a dynamic approach to problem-solving. Examples of Customizable Probes Users can define probes to monitor specific system events, track the behavior of certain processes, or gather data on system resource usage. This level of customization ensures that DTrace can be an effective tool in a variety of contexts, from routine maintenance to complex troubleshooting tasks. Following in a simple hello world dtrace probe: sudo dtrace -qn 'syscall::write:entry, syscall::sendto:entry /pid == $target/ { printf("(%d) %s %s", pid, probefunc, copyinstr(arg1)); }' -p 9999 The kernel is instrumented with hooks that match various callbacks. dtrace connects to these hooks and can perform interesting tasks when these hooks are triggered. They have a naming convention, specially: . In this case the provider is a system call in both cases. We have no module, so we can leave that part blank between the colon ( ) symbols. We grab a write operation and entries. When an application writes or tries to send a packet, the following code event will trigger. provider:module:function:name : sendto These things happen frequently, which is why we restrict the process ID to the specific target with . This means the code will only trigger for the PID passed to us in the command line. The rest of the code should be simple for anyone with basic C experience; it's a printf that would list the processes and the data passed. pid == $target Real-World Applications of DTrace DTrace's diverse capabilities extend far beyond theoretical use, playing a pivotal role in resolving real-world system complexities. Its ability to provide deep insights into system operations makes it an indispensable tool in a variety of practical applications. To get a sense of how dtrace can be used, we can use the command whose output on my Mac is below: man -k dtrace bitesize.d(1m)           - analyse disk I/O size by process. Uses DTrace
cpuwalk.d(1m)            - Measure which CPUs a process runs on. Uses DTrace
creatbyproc.d(1m)        - snoop creat()s by process name. Uses DTrace
dappprof(1m)             - profile user and lib function usage. Uses DTrace
dapptrace(1m)            - trace user and library function usage. Uses DTrace
dispqlen.d(1m)           - dispatcher queue length by CPU. Uses DTrace
dtrace(1)                - dynamic tracing compiler and tracing utility
dtruss(1m)               - process syscall details. Uses DTrace
errinfo(1m)              - print errno for syscall fails. Uses DTrace
execsnoop(1m)            - snoop new process execution. Uses DTrace
fddist(1m)               - file descriptor usage distributions. Uses DTrace
filebyproc.d(1m)         - snoop opens by process name. Uses DTrace
hotspot.d(1m)            - print disk event by location. Uses DTrace
iofile.d(1m)             - I/O wait time by file and process. Uses DTrace
iofileb.d(1m)            - I/O bytes by file and process. Uses DTrace
iopattern(1m)            - print disk I/O pattern. Uses DTrace
iopending(1m)            - plot number of pending disk events. Uses DTrace
iosnoop(1m)              - snoop I/O events as they occur. Uses DTrace
iotop(1m)                - display top disk I/O events by process. Uses DTrace
kill.d(1m)               - snoop process signals as they occur. Uses DTrace
lastwords(1m)            - print syscalls before exit. Uses DTrace
loads.d(1m)              - print load averages. Uses DTrace
newproc.d(1m)            - snoop new processes. Uses DTrace
opensnoop(1m)            - snoop file opens as they occur. Uses DTrace
pathopens.d(1m)          - full pathnames opened ok count. Uses DTrace
perldtrace(1)            - Perl's support for DTrace
pidpersec.d(1m)          - print new PIDs per sec. Uses DTrace
plockstat(1)             - front-end to DTrace to print statistics about POSIX mutexes and read/write locks
priclass.d(1m)           - priority distribution by scheduling class. Uses DTrace
pridist.d(1m)            - process priority distribution. Uses DTrace
procsystime(1m)          - analyse system call times. Uses DTrace
rwbypid.d(1m)            - read/write calls by PID. Uses DTrace
rwbytype.d(1m)           - read/write bytes by vnode type. Uses DTrace
rwsnoop(1m)              - snoop read/write events. Uses DTrace
sampleproc(1m)           - sample processes on the CPUs. Uses DTrace
seeksize.d(1m)           - print disk event seek report. Uses DTrace
setuids.d(1m)            - snoop setuid calls as they occur. Uses DTrace
sigdist.d(1m)            - signal distribution by process. Uses DTrace
syscallbypid.d(1m)       - syscalls by process ID. Uses DTrace
syscallbyproc.d(1m)      - syscalls by process name. Uses DTrace
syscallbysysc.d(1m)      - syscalls by syscall. Uses DTrace
topsyscall(1m)           - top syscalls by syscall name. Uses DTrace
topsysproc(1m)           - top syscalls by process name. Uses DTrace
Tcl_CommandTraceInfo(3tcl), Tcl_TraceCommand(3tcl), Tcl_UntraceCommand(3tcl) - monitor renames and deletes of a command
bitesize.d(1m)           - analyse disk I/O size by process. Uses DTrace
cpuwalk.d(1m)            - Measure which CPUs a process runs on. Uses DTrace
creatbyproc.d(1m)        - snoop creat()s by process name. Uses DTrace
dappprof(1m)             - profile user and lib function usage. Uses DTrace
dapptrace(1m)            - trace user and library function usage. Uses DTrace
dispqlen.d(1m)           - dispatcher queue length by CPU. Uses DTrace
dtrace(1)                - dynamic tracing compiler and tracing utility
dtruss(1m)               - process syscall details. Uses DTrace
errinfo(1m)              - print errno for syscall fails. Uses DTrace
execsnoop(1m)            - snoop new process execution. Uses DTrace
fddist(1m)               - file descriptor usage distributions. Uses DTrace
filebyproc.d(1m)         - snoop opens by process name. Uses DTrace
hotspot.d(1m)            - print disk event by location. Uses DTrace
iofile.d(1m)             - I/O wait time by file and process. Uses DTrace
iofileb.d(1m)            - I/O bytes by file and process. Uses DTrace
iopattern(1m)            - print disk I/O pattern. Uses DTrace
iopending(1m)            - plot number of pending disk events. Uses DTrace
iosnoop(1m)              - snoop I/O events as they occur. Uses DTrace
iotop(1m)                - display top disk I/O events by process. Uses DTrace
kill.d(1m)               - snoop process signals as they occur. Uses DTrace
lastwords(1m)            - print syscalls before exit. Uses DTrace
loads.d(1m)              - print load averages. Uses DTrace
newproc.d(1m)            - snoop new processes. Uses DTrace
opensnoop(1m)            - snoop file opens as they occur. Uses DTrace
pathopens.d(1m)          - full pathnames opened ok count. Uses DTrace
perldtrace(1)            - Perl's support for DTrace
pidpersec.d(1m)          - print new PIDs per sec. Uses DTrace
plockstat(1)             - front-end to DTrace to print statistics about POSIX mutexes and read/write locks
priclass.d(1m)           - priority distribution by scheduling class. Uses DTrace
pridist.d(1m)            - process priority distribution. Uses DTrace
procsystime(1m)          - analyse system call times. Uses DTrace
rwbypid.d(1m)            - read/write calls by PID. Uses DTrace
rwbytype.d(1m)           - read/write bytes by vnode type. Uses DTrace
rwsnoop(1m)              - snoop read/write events. Uses DTrace
sampleproc(1m)           - sample processes on the CPUs. Uses DTrace
seeksize.d(1m)           - print disk event seek report. Uses DTrace
setuids.d(1m)            - snoop setuid calls as they occur. Uses DTrace
sigdist.d(1m)            - signal distribution by process. Uses DTrace
syscallbypid.d(1m)       - syscalls by process ID. Uses DTrace
syscallbyproc.d(1m)      - syscalls by process name. Uses DTrace
syscallbysysc.d(1m)      - syscalls by syscall. Uses DTrace
topsyscall(1m)           - top syscalls by syscall name. Uses DTrace
topsysproc(1m)           - top syscalls by process name. Uses DTrace There's a lot here; we don't need to read everything. The point is that when you run into a problem, you can just search through this list and find a tool dedicated to debugging that problem. Let’s say you're facing elevated disk write issues that are causing the performance of your application to degrade... But is it your app at fault or some other app? rwbypid.d can help you with that. It can generate a list of processes and the number of calls they have for read/write based on the process ID, as seen in the following screenshot: We can use this information to better understand IO issues in our code or even in 3rd party applications/libraries. is another tool that helps us track IO operations but with more details: iosnoop In diagnosing elusive system issues, DTrace shines by enabling detailed observation of system calls, file operations, and network activities. For instance, it can be used to uncover the root cause of unexpected system behaviors or to trace the origin of security breaches, offering a level of detail that is often unattainable with other debugging tools. Performance optimization is the main area where DTrace demonstrates its strengths. It allows administrators and developers to pinpoint performance bottlenecks, whether they lie in application code, system calls, or hardware interactions. By providing real-time data on resource usage, DTrace helps in fine-tuning systems for optimal performance. Final Words In conclusion, DTrace stands as a powerful and versatile tool in the realm of system monitoring and debugging. We've explored its broad capabilities, from in-depth system analysis to individual process tracing and its remarkable performance efficiency that allows for its use in live environments. Its cross-platform compatibility, coupled with the challenges and solutions specific to MacOS, highlights its widespread applicability. The customizability through scripting provides unmatched flexibility, adapting to a myriad of diagnostic needs. Real-world applications of DTrace in diagnosing system issues and optimizing performance underscore its practical value. DTrace's comprehensive toolkit offers an unparalleled window into the inner workings of systems, making it an invaluable asset for system administrators and developers alike. Whether it's for routine troubleshooting or complex performance tuning, DTrace provides insights and solutions that are essential in the modern computing landscape. Also published . here

Advanced Debugging Techniques: Revisiting DTrace for Troubleshooting

FlutBuffers in 2024: Can We Recreate Old Success? Performance Optimization Takes Center Stage!

Redux has gained immense popularity for managing application state in a predictable and maintainable manner. This comprehensive guide walks through the process of implementing Redux in an iOS app, empowering developers to build scalable and efficient applications. From understanding core principles to practical implementation, this guide serves as a robust resource for adopting Redux in iOS development : the core principles - single source of truth, state immutability, and unidirectional data flow, where: Understanding Redux Architecture Store: Define the single source of truth for the application state Actions: Describe events that trigger state changes by reducer and trigger middleware Reducers: Pure functions that handle actions and update the state Middlewares: Interaction with services and side effects and the result of a new action . Create a new iOS project. Initialize the project structure, including folders Core, Flow, MW, Store, Services, where: Setting Up the Project Core for the basic architecture components and all additional general utilities Flow for UI components Views and their Service something like Controller/Presenter/View Model MW for Middlewares, DTO’s Store for Actions, Reducers, State Service for all components that are connected to the outside world something like File Manager/DB/Network/… . At first make protocol for actions and at the same time include reducer. Define actions that represent events triggering state changes. Organize actions into separate files based on functionality. Defining Actions Implementing Reducers. Create reducers that handle actions and update the state immutably. Combine reducers to manage different parts of the state protocol Action {
    associatedtype StateType: Equatable
    func reduce(_ state: inout StateType)
} enum MainAction: Action {
    case user(UserAction)
    
    func reduce(_ state: inout MainState) {
        switch self {
        case let .user(action): action.reduce(&state)
        }
    }
} enum UserAction: Action {
    case getUserData
    case receiveUser(UserModel)
    
    func reduce(_ state: inout MainState) {
        switch self {
        case .getUserData: state.user = .loading
        case let .receiveUser(model): state.user = .result(model)
        }
    }
} . Make base elements and protocol for Middleware. Implement middleware to manage asynchronous actions. And create DTO with mapping to State model Managing Asynchronous Operations struct Box<Act> where Act: Action {
    let run: (@escaping (Act) -> Void) -> Void
    
    init(_ run: @escaping (@escaping (Act) -> Void) -> Void) {
        self.run = run
    }
}

extension Box {
    static func throwTask(
        _ run: @escaping (@escaping (Act) -> Void) async throws -> Void,
        catchError: @escaping (@escaping (Act) -> Void, Error) -> Void = { _, _ in }
    ) -> Self {
        Self { dispatcher in
            Task {
                do {
                    try await run(dispatcher)
                } catch {
                    catchError(dispatcher, error)
                }
            }
        }
    }
}

extension Box {
    static var zero: Self { Self { _ in }}
    
    static func +=(lhs: inout Self, rhs: Self) {
        let tmp = lhs
        lhs = Self { dispatcher in
            tmp.run(dispatcher)
            rhs.run(dispatcher)
        }
    }
} protocol Middleware {
    associatedtype Act where Act: Action
    func run(state: Act.StateType, action: Act) -> Box<Act>
}

extension Middleware {
    var asAnyMiddleware: AnyMiddleware<Act> {
        AnyMiddleware(self.run(state:action:))
    }
} struct AnyMiddleware<Act>: Middleware where Act: Action {
    private let runer: (Act.StateType, Act) -> Box<Act>
    
    init(_ run: @escaping (Act.StateType, Act) -> Box<Act>) {
        self.runer = run
    }
    
    func run(state: Act.StateType, action: Act) -> Box<Act> {
        runer(state, action)
    }
} struct UserMW: Middleware {
    private let net: UserNetProvider
    
    init(net: UserNetProvider) {
        self.net = net
    }
    
    func run(state: MainState, action: MainAction) -> Box<MainAction> {
        switch action {
        case let .user(userAction): return handleUser(state: state.user, action: userAction)
        default: return .zero
        }
    }
    
    func handleUser(state: ModelWrapper<UserModel>, action: UserAction) -> Box<MainAction> {
        switch action {
        case .getUserData: return Box.throwTask { dispatcher in
            let userDTO: UserDTO = try await net.getUserData()
            dispatcher(.user(.receiveUser(userDTO.convert)))
        } catchError: { dispatcher, error in
            // Handle error
        }
        default: return .zero
        }
    }
} struct UserDTO: Decodable {
    let name: String
    let age: Int
    
    var convert: UserModel {
        UserModel(name: name, age: age)
    }
} . Create State and Model wrapper for implementing all states. Create a store to manage the application state. Define the initial state and configure the store. Implementing the Store Of course Store implementation is very simple without corner cases enum ModelWrapper<Model> where Model: Equatable {
    case initialize
    case loading
    case error(Error)
    case result(Model)
}

extension ModelWrapper: Equatable {
    private var equatabeValue: String {
        return switch self {
        case .initialize: "initialize \(String(describing: Model.self))"
        case .loading: "loading \(String(describing: Model.self))"
        case let .error(error): error.localizedDescription
        case let .result(model): String(describing: model)
        }
    }
    
    static func == (lhs: ModelWrapper<Model>, rhs: ModelWrapper<Model>) -> Bool {
        lhs.equatabeValue == rhs.equatabeValue
    }
} struct MainState: Equatable {
    public internal(set) var user: ModelWrapper<UserModel> = .initialize
} struct UserModel: Equatable {
    let name: String
    let age: Int
} actor Store<Act> where Act: Action {
    nonisolated var statePublisher: AnyPublisher<Act.StateType, Never> {
        stateSubject.eraseToAnyPublisher()
    }
    
    private var state: Act.StateType {
        didSet {
            stateSubject.send(state)
        }
    }
    private let stateSubject: CurrentValueSubject<Act.StateType, Never>
    
    private let middlewares: [AnyMiddleware<Act>]
    
    init(initState: Act.StateType, middlewares: [AnyMiddleware<Act>]) {
        self.state = initState
        self.stateSubject = CurrentValueSubject(initState)
        self.middlewares = middlewares
    }
    
    func dispatch(action: Act) {
        var box = Box<Act>.zero
        
        for mw in middlewares {
            box += mw.run(state: state, action: action)
        }
        
        action.reduce(&state)
        
        box.run(dispatch(action:))
    }
} . Integrate Redux with view components to read state from the store. Create simple View with ViewController and dispatch actions to trigger state updates. Connecting Components to Redux class ReduxVC<Act>: UIViewController where Act: Action {
    private let store: Store<Act>
    private var box = Set<AnyCancellable>()
    
    init(store: Store<Act>) {
        self.store = store
        super.init(nibName: nil, bundle: nil)
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    func sink<S: Equatable>(map: KeyPath<Act.StateType, S>, _ sink: @escaping (_ storeState: S) -> Void) {
        store
            .statePublisher
            .map(map)
            .removeDuplicates()
            .receive(on: DispatchQueue.main)
            .sink(receiveValue: sink)
            .store(in: &box)
    }
    
    func dispatch(_ action: Act) {
        Task { await store.dispatch(action: action) }
    }
} final class UserScreenView: UIView {
    
    private let spiner = {
        $0.isHidden = true
        $0.color = .black
        $0.translatesAutoresizingMaskIntoConstraints = false
        return $0
    }(UIActivityIndicatorView(style: .medium))
    
    private let dataView = {
        $0.isHidden = true
        $0.backgroundColor = .lightGray
        $0.clipsToBounds = true
        $0.layer.cornerRadius = 10
        $0.translatesAutoresizingMaskIntoConstraints = false
        return $0
    }(UIView())
    
    private let errorView = {
        $0.isHidden = true
        $0.backgroundColor = .lightGray
        $0.clipsToBounds = true
        $0.layer.cornerRadius = 10
        $0.translatesAutoresizingMaskIntoConstraints = false
        return $0
    }(UIView())
    
    private let nameLabel = {
        $0.font = .systemFont(ofSize: 22, weight: .regular)
        $0.textColor = .black
        $0.translatesAutoresizingMaskIntoConstraints = false
        return $0
    }(UILabel())
    
    private let ageLabel = {
        $0.font = .systemFont(ofSize: 22, weight: .regular)
        $0.textColor = .black
        $0.translatesAutoresizingMaskIntoConstraints = false
        return $0
    }(UILabel())
    
    private let errorLabel = {
        $0.font = .systemFont(ofSize: 22, weight: .regular)
        $0.textColor = .systemRed
        $0.translatesAutoresizingMaskIntoConstraints = false
        return $0
    }(UILabel())
    
    init() {
        super.init(frame: .zero)
        backgroundColor = .white
        
        addSubview(spiner)
        addSubview(dataView)
        dataView.addSubview(nameLabel)
        dataView.addSubview(ageLabel)
        addSubview(errorView)
        errorView.addSubview(errorLabel)
        
        NSLayoutConstraint.activate([
            spiner.centerXAnchor.constraint(equalTo: centerXAnchor),
            spiner.centerYAnchor.constraint(equalTo: centerYAnchor),
            spiner.heightAnchor.constraint(equalToConstant: 30),
            spiner.widthAnchor.constraint(equalToConstant: 30),
            
            dataView.centerXAnchor.constraint(equalTo: centerXAnchor),
            dataView.centerYAnchor.constraint(equalTo: centerYAnchor),
            nameLabel.leadingAnchor.constraint(equalTo: dataView.leadingAnchor, constant: 22),
            nameLabel.trailingAnchor.constraint(equalTo: dataView.trailingAnchor, constant: -22),
            nameLabel.topAnchor.constraint(equalTo: dataView.topAnchor, constant: 22),
            ageLabel.widthAnchor.constraint(equalTo: nameLabel.widthAnchor),
            ageLabel.centerXAnchor.constraint(equalTo: dataView.centerXAnchor),
            ageLabel.topAnchor.constraint(equalTo: nameLabel.bottomAnchor, constant: 22),
            ageLabel.bottomAnchor.constraint(equalTo: dataView.bottomAnchor, constant: -22),
            
            errorView.centerXAnchor.constraint(equalTo: centerXAnchor),
            errorView.centerYAnchor.constraint(equalTo: centerYAnchor),
            errorLabel.leadingAnchor.constraint(equalTo: errorView.leadingAnchor, constant: 22),
            errorLabel.trailingAnchor.constraint(equalTo: errorView.trailingAnchor, constant: -22),
            errorLabel.topAnchor.constraint(equalTo: errorView.topAnchor, constant: 22),
            errorLabel.bottomAnchor.constraint(equalTo: errorView.bottomAnchor, constant: -22)
        ])
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    func loadingData() {
        dataView.isHidden = true
        errorView.isHidden = true
        spiner.isHidden = false
        spiner.startAnimating()
    }
    
    func errorSetup(_ error: String) {
        dataView.isHidden = true
        spiner.isHidden = true
        errorView.isHidden = false
        spiner.stopAnimating()
        
        errorLabel.text = error
    }
    
    func dataSetup(_ model: UserModel) {
        dataView.isHidden = false
        spiner.isHidden = true
        errorView.isHidden = true
        spiner.stopAnimating()
        
        nameLabel.text = model.name
        ageLabel.text = String(model.age)
    }
} final class UserScreenVC: ReduxVC<MainAction> {

    let mainView = UserScreenView()
    
    override func loadView() {
        self.view = mainView
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        sink(map: \.user) { [unowned self] state in
            switch state {
            case .initialize: break
            case .loading: mainView.loadingData()
            case let .error(err): mainView.errorSetup(err.localizedDescription)
            case let .result(model): mainView.dataSetup(model)
            }
        }
        
        dispatch(.user(.getUserData))
    }
} And finally assembly all components together into SceneDelegate guard let windowScene = (scene as? UIWindowScene) else { return }

let netProvider = NetProvider()

let store = Store<MainAction>(
    initState: MainState(),
    middlewares: [
        UserMW(net: UserNetProvider(netProvider: netProvider)).asAnyMiddleware
    ]
)

window = UIWindow(frame: UIScreen.main.bounds)
window?.windowScene = windowScene
window?.rootViewController = UserScreenVC(store: store)
window?.makeKeyAndVisible() All structural folders Core, Flow, MW, Store, Services you can separate into separate elements e.g. Frameworks/Swift Packages/Libraries or something like this Conclusion: In conclusion, the adoption of Redux architecture in iOS app development offers a structured, scalable, and efficient approach to managing application state. This comprehensive guide has illuminated the core principles of Redux, emphasizing the importance of a single source of truth, state immutability, and unidirectional data flow. The step-by-step exploration of implementing Redux architecture has covered various key components

Building Testable and Maintainable iOS Apps with Redux

Stories, News & Mentions about NEXPRO

Nexpro’s Stories on HackerNoon