# Porting Published articles for Porting. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Crash-Safe & Copy-On-Write GEFS As The "Good Enough File-System" For OpenBSD DevFeed: [Crash-Safe & Copy-On-Write GEFS As The "Good Enough File-System" For OpenBSD]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-16T13:42:00Z Content type: article Language: en Sources: [Phoronix]() Topics: [Filesystems](), [file]() Tags: [crash](), [desktop-linux](), [file](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [porting](), [preview](), [production](), [ubuntu-benchmarks](), [ubuntu-hardware]() ### AI overview Ori Bernstein announced an early preview of GEFS, a crash-safe, snapshotting, copy-on-write file system originally developed for 9front and now being ported to OpenBSD. The OpenBSD port is not yet production-ready or submitted for inclusion in the OpenBSD tree. ### Source excerpt Ori Bernstein announced an early preview of his Good Enough File-System "GEFS" for OpenBSD. GEFS is a crash-safe, snapshotting, copy-on-write file-system that he wrote initially for 9front and now porting to OpenBSD... ## Porting a Discord Bot to Microsoft Teams with GitHub Copilot CLI DevFeed: [Porting a Discord Bot to Microsoft Teams with GitHub Copilot CLI]() Original publisher: [Read original article]() Author: Daniel Doubrovkine (dblock@dblock.org) Published: 2026-09-16T00:00:00Z Content type: article Language: en Sources: [Daniel Doubrovkine]() Topics: [GitHub Copilot CLI](), [Microsoft Teams](), [Artificial Intelligence](), [Discord](), [AdventureX 2025]() Tags: [ai](), [discord](), [github-copilot-cli](), [hackathon](), [microsoft-teams](), [porting](), [ruby](), [strava]() ### AI overview The article compares a manual 2023 port of a Strava chat bot from Slack to Discord with a 2026 port to Microsoft Teams completed with GitHub Copilot CLI. The Teams port took three days and involved authentication, app-manifest, tenant distribution, and Azure setup work. ### Source excerpt Slava (slack-strava) connects a Strava account to a chat and posts a card for every activity, complete with map, pace, and elevation, plus commands like connect, disconnect, stats, and leaderboard. In 2023 I ported Slava to Discord by hand, evening by evening over about three weeks, and it took most of that stretch to get a working bot called Strada (discord-strava). This week I ported the same app to Microsoft Teams as Strata (teams-strava) in 3 days instead of the 3 weeks the Discord port took, using time carved out during the Microsoft Global Hackathon. By "I", I mean GitHub Copilot CLI and I. The 2023 Baseline discord-strava's git history is a fair record of how long a manual port takes. The first commit, "Initial fork from slack-strava," landed July 30, 2023. "Most interactions working" was three days later. Getting install/help/error-handling polish took through August 20: 2023-07-30 23:56 Initial fork from slack-strava. 2023-08-02 23:46 Most interactions working. 2023-08-03 06:18 Remove PNG retrieval, Discord displays redirects correctly. 2023-08-03 06:26 Removed clubs. 2023-08-03 08:28 Fixed model specs. 2023-08-03 18:20 Fix API specs. 2023-08-04 19:44 Fix command specs. ... 2023-08-08 10:34 Countinously poll with 1 minute intervals. 2023-08-20 22:59 Improved install button and text. 20 commits spread across 9 evenings over roughly three weeks (there's a real job and a life in between those timestamps). All hand-typed, with GitHub Copilot's inline autocomplete helping the way it helped everyone in 2023, but no agent driving the actual porting work. The 2026 Port teams-strava's git history is a single continuous Copilot CLI session, 107 conversational turns over three calendar days, and the timestamps compress dramatically: 2026-09-14 11:05 Initial port of discord-strava to Microsoft Teams 2026-09-14 16:39 Fix local dev setup and personal-scope install handling 2026-09-14 16:43 Fix 400 error replying to personal-scope install notice 2026-09-15 08:29 Document ## Valve Confirms Half-Life: Alyx is Coming to Steam Frame Standalone, But Not in Time for Launch DevFeed: [Valve Confirms Half-Life: Alyx is Coming to Steam Frame Standalone, But Not in Time for Launch]() Original publisher: [Read original article]() Author: Scott Hayden Published: 2026-09-14T17:00:00Z Content type: news Language: en Sources: [Road to VR]() Topics: [Optimization](), [Open Source](), [pc](), [Windows]() Tags: [bug-fixes](), [gaming](), [news](), [open-source](), [optimization](), [pc](), [pc-vr-news-reviews](), [porting](), [vulkan](), [windows](), [xr-industry-news]() ### AI overview Valve is developing a standalone Steam Frame port of Half-Life: Alyx, but it will not be available at the headset's launch. Eye-tracking, foveated rendering, 16GB of VRAM, Vulkan driver work, and SteamVR work enabled the port without changing game assets, while existing Workshop content will remain compatible. ### Source excerpt The rumors are true: Valve finally confirmed it's creating a standalone port of Half-Life: Alyx (2020) for Steam Frame, although it won't be ready at launch. Valve finally announced Steam Frame's price and release date, starting at $1,060 with shipping beginning as early as September 18th. Amid the avalanche of news, Valve has also confirmed [...] The post Valve Confirms Half-Life: Alyx is Coming to Steam Frame Standalone, But Not in Time for Launch appeared first on Road to VR. ## Revenge Thriller FPS I Am Your Beast Comes To PC VR Next Week DevFeed: [Revenge Thriller FPS I Am Your Beast Comes To PC VR Next Week]() Original publisher: [Read original article]() Author: Mike Johnson Published: 2026-09-10T20:16:47Z Content type: news Language: en Sources: [UploadVR]() Topics: [Virtual reality](), [releases](), [Development]() Tags: [2026](), [launch](), [porting](), [release](), [releases](), [vr-gaming]() ### AI overview I Am Your Beast VR, a revenge thriller FPS from the Flat2VR Spark program, is scheduled to release on SteamVR on September 17. The article also describes the program and Flat2VR Studios' other VR projects. ### Source excerpt Revenge thriller I Am Your Beast VR from Flat2VR Spark hits PC VR on September 17. ## 2026 Real-Time Shading Ecosystem Survey Results DevFeed: [2026 Real-Time Shading Ecosystem Survey Results]() Original publisher: [Read original article]() Author: jphilips (jeff@khronosgroup.org) Published: 2026-07-21T13:00:00Z Content type: release Language: en Sources: [Blogs Khronos Blog]() Topics: [releases](), [shaders](), [real-time](), [Programming](), [glsl](), [GPU]() Tags: [2026](), [blog](), [debugging](), [developers](), [glsl](), [graphics](), [porting](), [real-time](), [report](), [survey]() ### AI overview Khronos reports results from a 2026 survey of more than 400 shader developers, graphics programmers, rendering engineers, and tools creators. Shader debugging and profiling were the leading reported pain point, while cross-platform shader porting also affected a majority of respondents. ### Source excerpt Khronos releases the 2026 Real-Time Shading Ecosystem Survey Report, a summary of insights from over 400 shader developers, graphics programmers, rendering engineers, and tools creators. Conducted between June 16 and July 10, 2026, the survey captures a clear picture of how the real-time shading community works today -- and where standardization efforts can deliver the greatest impact. ## GNU/Hurd development updates for Q4 2025 DevFeed: [GNU/Hurd development updates for Q4 2025]() Original publisher: [Read original article]() Published: 2026-01-02T06:07:00Z Content type: news Language: en Sources: [GNU Hurd]() Topics: [Development](), [lwIP](), [Network](), [Ethernet]() Tags: [2025](), [ethernet](), [ipv4](), [lwip](), [network](), [porting]() ### AI overview The Q4 2025 GNU/Hurd update reports progress on porting dhcpcd, including IPv4 and Ethernet support over lwIP, while noting limitations such as the lack of IPv6 and unfinished interface-change notifications. It also covers GNU Mach timeout improvements, interrupt and rumpnet fixes, and progress on SMP support. ### Source excerpt Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd developments in Q4 of 2025! Details. Joan Lledó worked on porting dhcpcd to the hurd. He also made some changes so that lwip would work with dhcpcd. In this message he writes: This is the current state of the port: Support only for IPv4. IPv6 not supported yet. It works only over lwip. First, because dhcpcd requires some definitions from headers and pfinet doesn't provide them AFAIK, but lwip provide the headers through the liblwip-dev package. Second, because both pfinet and lwip need changes in the translator in order to be fully compatible with dhcpcd, and I made the changes in lwip since I know it better. Only Ethernet is supported. This is because the Hurd doesn't define AF_LINK so dhcpcd can't get any data from the interface other thant what is returned by getifaddrs(). I'm manually providing the MAC address and hardcoding the interface type to Ethernet in the if_init function. I assume this is correct because the Hurd only supports ethernet interfaces AFAIK. dhcpcd monitors the interfaces and gets notified when there are changes in routes or network configurations. This is not working yet for the Hurd. dhcpcd implements some privilege separation by which the process spawns new processes that run as a non-privileged user. Or that's what I understood. It's not implemented for the Hurd because I've deferred this for now. Access to BPF is provided by libpcap. libpcap and liblwip-dev are dependencies for the Hurd. This has been tested only in a 32-bit Hurd. Damien Zammit worked on fixing some interrupt bugs in the acpi server. He also made some fixes for rumpnet. He also worked on adding a callwheel to GNU Mach's clock. This would make GNU Mach faster in certain ways. He writes: Timeouts are now very fast to look up, at the expense of more memory, a much shorter list is traversed rather than all of them. See [1]. Timeouts that are stopped before expiry are now faster to remove, and inserti ## Advanced techniques for porting libraries to ESP-IDF components DevFeed: [Advanced techniques for porting libraries to ESP-IDF components]() Original publisher: [Read original article]() Author: John Lee Published: 2025-11-24T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [Library](), [AWS IoT Core](), [OpenSSH](), [WebSocket](), [aio](), [CMake](), [make](), [POSIX]() Tags: [blog](), [cmake](), [compiler](), [component](), [components](), [esp-idf](), [feature-flags](), [library](), [linux](), [mqtt](), [porting](), [posix](), [ssh](), [systems](), [techniques]() ### AI overview This follow-up article presents advanced techniques for porting larger libraries, particularly those designed for Linux or POSIX systems, into reusable ESP-IDF components. It covers assessing reusable code, adapting build systems and port layers, configuration, header injection, linker wrapping, and compiler-warning management, with examples including asio, mosquitto, libssh, and libwebsockets. ### Source excerpt This article follows up on the article 'Porting a library to an ESP-IDF component' and shows some advanced tips and tricks when porting larger libraries into ESP-IDF components. ## Debugging Embedded Graphics with Wokwi and AI: Solving a Raylib Color Mapping on ESP32 DevFeed: [Debugging Embedded Graphics with Wokwi and AI: Solving a Raylib Color Mapping on ESP32]() Original publisher: [Read original article]() Author: John Lee Published: 2025-10-24T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP32](), [debugging](), [Simulation](), [Embedded Systems](), [Testing](), [Artificial Intelligence](), [Warp](), [ESP-IDF]() Tags: [ai](), [blog](), [ci-cd](), [debugging](), [embedded](), [esp-idf](), [esp32](), [esp32-s3](), [graphics](), [library](), [porting](), [practitioner](), [simulation](), [testing](), [visual-testing](), [warp](), [wokwi]() ### AI overview The article describes using Wokwi simulation and Warp's AI vision capabilities to diagnose and fix an RGB565 color-mapping bug in a Raylib port for ESP32 devices. It presents screenshot-based visual debugging, rapid iteration, and automated testing as alternatives to repeated testing on physical hardware. ### Source excerpt Learn how Wokwi simulation and AI-assisted debugging solved a subtle RGB565 color mapping bug when porting Raylib to ESP32, turning hours of hardware debugging into an efficient iterative workflow with automated visual testing. ## Porting a library to an ESP-IDF component DevFeed: [Porting a library to an ESP-IDF component]() Original publisher: [Read original article]() Author: John Lee Published: 2025-10-20T00:00:00Z Content type: tutorial Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [Library](), [Testing](), [ide](), [Code](), [Hardware](), [Template](), [GitHub]() Tags: [app](), [blog](), [build](), [build-system](), [code](), [component](), [esp-idf](), [esp-idf-component](), [esp-idf-extension-for-vs-code](), [esp32-c3](), [esp32c3](), [github](), [hardware](), [how-to](), [porting](), [repo](), [testing]() ### AI overview This tutorial explains how to port an external library into a reusable ESP-IDF component. Using tinyexpr, it covers obtaining the source code, creating a test project and component, configuring the build system, resolving compatibility issues, and testing on an ESP32-C3 board. ### Source excerpt This article shows how to port an external library into an ESP-IDF project by converting it into a reusable component. Using tinyexpr as an example, it covers obtaining the source code, creating a new project, building a component, configuring the build system, and testing on hardware. ## Porting Mobian to New Devices DevFeed: [Porting Mobian to New Devices]() Original publisher: [Read original article]() Author: Mobian team Published: 2023-03-07T00:00:00Z Content type: article Language: en Sources: [Mobian's Blog]() Topics: [Mobile](), [Linux](), [Kernel](), [Android](), [Debian]() Tags: [android](), [boot](), [compatibility](), [debian](), [drivers](), [kernel](), [linux](), [maintenance](), [porting](), [security]() ### AI overview The article explains why porting Mobian to new phones is difficult. Android-based phone kernels often differ from Mobile Linux, may be old and device-specific, and can have security and maintenance problems. Mobian therefore prefers compatible kernels and devices with good mainline support instead of relying on compatibility layers such as libhybris. ### Source excerpt As Mobian (and Mobile Linux in general) has gotten more popular, many folks have started to ask if Mobian supports their particular phone. While we wish we lived in a world where installing Mobian to a new phone model was just as easy as installing Debian to a new laptop, things are (unfortunately) much more complicated than that. But my phone runs Android, and Android runs on Linux! It is true that Android is Linux-based, but Android Linux diverged from Mobile Linux a long time ago. Android Linux images are simply incompatible with Mobile Linux, unless several compatibilty layers are installed. In addition, the Android kernel shipped by manufacturers are based on LTS kernels, and consist of millions of lines of out of tree code. Much of this code cannot be upstreamed due to code quality, and sometimes the code is of dubious legal origin. The kernel that the phone is based off of is often ancient. In some cases, current devices might ship a version of Linux 3.19 which was released in 2015 and no longer gets updates from upstream. This poses two problems for us: 1) they are full of security flaws and 2) their API is oldish and different from what current Mobile Linux environments need (both because it is old API and because it provides Android-specific API). One would be stuck with a ancient and unmaintainable kernel that one could not improve and a kernel that provides an incompatible interface to Mobile Linux. Some distributions make that tradeoff and use these compatibility layers to bridge the interface between Android kernels and Mobile Linux. One such is libhybris. They basically choose to live with a kernel that one cannot modify and improve in a significant manner. In addition, many kernels are device specific1, which in turn creates a higher maintenance burden for every phone added. Adding the compatibility layer does provide an advantage in that the distribution can port to many more phones much quicker. Mobian's ultimate goal is to erase the differences be ## Drawing custom text spans in Compose UI DevFeed: [Drawing custom text spans in Compose UI]() Original publisher: [Read original article]() Author: Saket Narayan Published: 2022-07-12T15:49:24Z Content type: tutorial Language: en Sources: [Saket Narayan]() Topics: [Compose](), [ui](), [implementation](), [Code]() Tags: [android](), [animation](), [compose](), [compose-ui](), [library](), [modifiers](), [porting](), [ui]() ### AI overview A tutorial on drawing custom text decorations in Compose UI by annotating text, calculating layout coordinates, and manually rendering animated squiggly underlines. It also demonstrates rounded-corner text backgrounds and packages the implementation as a reusable library. ### Source excerpt While exploring how text paragraphs are rendered in Compose UI, I nerd sniped myself into porting squiggly underlines from Sam Ruston's Buzzkill app. Sam's animation was implemented using TextView custom spans, but Compose UI does not offer any alternatives for them yet. While our friends at Google are prototyping text modifiers (first, second), I figured [...] The post Drawing custom text spans in Compose UI appeared first on Saket Narayan. ## 2021-05-17 Status update DevFeed: [2021-05-17 Status update]() Original publisher: [Read original article]() Author: Mobian team Published: 2021-05-17T00:00:00Z Content type: release Language: en Sources: [Mobian's Blog]() Topics: [Linux](), [Mobile](), [Debian](), [Development](), [kernels](), [maintenance](), [Tooling]() Tags: [debian](), [development](), [linux](), [maintenance](), [mobile](), [phones](), [porting](), [tooling](), [update](), [updated]() ### AI overview This Mobian status update reports progress on distribution stability and tooling, the positive reception of the Mobian Community Edition PinePhone, donations to Debian and investment in infrastructure, and official support for the Pocophone F1 and OnePlus 6 and 6T. The newly supported phones remain unsuitable as daily drivers because modem, audio, and camera functionality is not yet working. ### Source excerpt The past few months have been quieter than usual regarding Mobian development, but that's not to say we didn't make progress! Actually, even though user-visible changes are few, we kept working on improving both the stability of our distribution and our tooling, so that new developments can be better tested, and reach users faster than they used to. Mobian CE reception and outcomes The Mobian Community Edition PinePhone has been a great success for us, with of course a few hiccups, but the feedback we received so far has been extremely positive. We'd like to take this opportunity to thank Pine64 once again for allowing us to be part of this amazing journey! As you probably know, Pine64 generously donated 10$ per device to the Mobian project, which we received early last month. Out of this amount, we chose to donate 5000EUR back to the Debian project (which provides the foundation for all of our work on Mobian), and invested about the same amount into our own infrastructure (workstation, build servers...). Finally, we purchased a few additional mobile devices we considered interesting targets and started porting Mobian to those. New supported devices Let's play with Android phones! Until recently, Mobian supported only Pine64's PinePhone, PineTab and Purism's Librem 5. This is partly related to our choice of only using mainline kernels, instead of vendor-provided Android kernels: those use a number of non-standard interfaces, and require additional software, such as Halium, in order to be used with a "standard" Linux userspace. In addition, vendor kernels are generally outdated and very rarely updated to newer kernel releases, which is obviously a concern for long-term maintenance. Fortunately, our friends at postmarketOS have committed to mainlining devices for quite some time now, and by encouraging such development have reached great results so far! Based on their initiative, and more specifically thanks to @calebccff's and @Joel's work on the SDM845 kernel, we have b ## Why I migrated to the Fish Shell DevFeed: [Why I migrated to the Fish Shell]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2020-12-07T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [friendly interactive shell](), [Shell](), [Zsh](), [Bash](), [dotfiles](), [Command-line interface](), [Environment Variables](), [lazy loading](), [Scripting]() Tags: [aliases](), [bash](), [environment-variables](), [lazy-loading](), [plugins](), [porting](), [prompt](), [scripting](), [shell](), [zsh]() ### AI overview The author explains migrating dotfiles from Zsh to Fish, emphasizing Fish's startup performance, universal variables, lazy loading, and built-in features such as syntax highlighting, autosuggestions, and man-page completions. The article also notes differences from POSIX shells and describes the author's plugin setup. ### Source excerpt Back in June, I started porting my dotfiles from ZSH to Fish. Here's why. ## Porting Syzkaller to ReactOS Final Evaluation - GSoC 2020 DevFeed: [Porting Syzkaller to ReactOS Final Evaluation - GSoC 2020]() Original publisher: [Read original article]() Published: 2020-09-01T00:00:00Z Content type: opinion Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Code](), [Kernel](), [virtualization](), [x86]() Tags: [free](), [gsoc](), [kernel](), [network](), [open-source](), [os](), [porting](), [project](), [react](), [reactos](), [ssh](), [virtualization](), [win32](), [winapi](), [x86]() ### AI overview This wrap-up reports on a three-month GSoC project to port Syzkaller to ReactOS. The work produced a working ReactOS port, used existing kernel sanitizers, fixed the main executor, and added a proof of concept for fuzzing ntdll calls. Remaining work included kernel code coverage, Syzbot integration, upstreaming, and network functionality. ### Source excerpt Hello everyone, I am Suraj K Suresh, the one working on the GSoC project of "Porting Syzkaller to ReactOS". It's been 3 whole months since GSoC has begun and this is the last evaluation period. During the last 3 months, I worked on various parts of Syzkaller and getting them up and running on ReactOS and Windows with the help of my Mentors. This blog post will be a wrap-up post of the GSoC project. ## Porting Syzkaller to ReactOS - GSoC 2020 DevFeed: [Porting Syzkaller to ReactOS - GSoC 2020]() Original publisher: [Read original article]() Published: 2020-06-04T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [Kernel](), [Testing](), [Google]() Tags: [crashes](), [free](), [gsoc](), [kernel](), [linux](), [open-source](), [os](), [porting](), [react](), [reactos](), [testing](), [win32](), [winapi]() ### AI overview A ReactOS GSoC student describes porting Syzkaller, a Google coverage-guided kernel fuzzer, to ReactOS. The work includes restoring Windows x64 and x86 support, adapting required synchronization functions, and investigating a zombie executor process. ### Source excerpt Hey, I am Suraj K Suresh (@Freakston), one of the GSoC students of ReactOS. This is the first time I've applied for GSoC and my mentors for the project are Victor Perevertkin and Timo Kreuzer. My project is "Porting Syzkaller to ReactOS". The project is getting one of the most famous Linux fuzzers to fuzz ReactOS. The project will lead to improvement of the kernel codebase by detecting code crashes. ## C Portability Lessons from Old Machines DevFeed: [C Portability Lessons from Old Machines]() Original publisher: [Read original article]() Published: 2018-11-15T00:00:00Z Content type: article Language: en Sources: [Joe Nelson]() Topics: [C](), [Hardware](), [systems](), [Compiler]() Tags: [architectures](), [article](), [book](), [c](), [compiler](), [hardware](), [microcontrollers](), [pointers](), [portable](), [porting](), [systems](), [technical]() ### AI overview The article examines C portability by tracing how carefully written ANSI C using standard library functions can compile and work across systems ranging from 4-bit microcontrollers to room-sized mainframes. It uses unusual architectures, word sizes, integer representations, and pointer models to show how portable code separates the language from the environment and remains applicable to modern CPUs. ### Source excerpt 2018-11-15 In this article we'll go on a journey from 4-bit microcontrollers to room-sized mainframes and learn how porting C to each of them helped people separate the essence of the language from the environment of its birth. I've found technical manuals and videos for this article to help bring each computer to life. ## Crisp cn1lib DevFeed: [Crisp cn1lib]() Original publisher: [Read original article]() Author: Shai Almog Published: 2018-10-22T00:00:00Z Content type: release Language: en Sources: [CodeName One]() Topics: [Mobile](), [Android](), [iOS](), [Library](), [App](), [HTML](), [Extension]() Tags: [android](), [extension](), [html](), [implementation](), [ios](), [library](), [mobile](), [porting]() ### AI overview The article announces a new Crisp cn1lib that adds Crisp chat and related functionality to Codename One Android and iOS apps. It explains that the integration uses HTML rather than wrapping Crisp's native SDKs to improve portability, and notes that developers can install the library through the extension manager. ### Source excerpt Crisp powers the chat button in the bottom right portion of our site. It also handles emails and a host of other great features. One feature we didn't take advantage of is the mobile app support. To solve that we just issued a new Crisp cn1lib which we integrated into the new versions of our Android and iOS apps. You can install it yourself using the extension manager and use it with the instructions here. ## How to Write a Plugin for Craft CMS 3.x DevFeed: [How to Write a Plugin for Craft CMS 3.x]() Original publisher: [Read original article]() Author: andrew@nystudio107.com (Andrew Welch) Published: 2017-05-24T22:38:00Z Content type: tutorial Language: en Sources: [nystudio107 | Articles on modern web development.]() Topics: [Content Management System](), [PHP](), [Development]() Tags: [article](), [cms](), [craft](), [existing](), [how-to](), [insights](), [php](), [plugin](), [plugin-development](), [porting](), [writing](), [you-re]() ### AI overview A tutorial on writing plugins for Craft CMS 3.x. It explains the development process and methodologies, including how plugins extend an existing system and how Craft 3 plugins use PHP and the system's API scaffolding. ### Source excerpt Whether you're porting an existing plugin from Craft CMS 2.x or writing your first plugin for Craft 3, this article will show you how to do it ## File and URL for Better Java Mobile Compatibility DevFeed: [File and URL for Better Java Mobile Compatibility]() Original publisher: [Read original article]() Author: Shai Almog Published: 2016-10-19T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [Java](), [Mobile](), [API](), [IO]() Tags: [api](), [compatibility](), [io](), [java](), [mobile](), [porting]() ### AI overview The article introduces com.codename1.io.File and com.codename1.io.URL as drop-in replacements for java.io.File and java.net.URL to improve the portability of existing Java code to Codename One. It notes compatibility limitations, including counterintuitive API mappings and possible EDT blocking when using the synchronous API. ### Source excerpt I explained why we don't support the full Java API (and the difficulties involved) not so long ago. The logic behind this is solid. However, the utility of porting existing Java code to Codename One is also with a lot of merit. We try to strike a balance between portability, compatibility to the Java API etc. and that is a very delicate balance. To improve the situation we created two new classes: com.codename1.io.File & com.codename1.io.URL. They are meant to be drop-in replacements for java.io.File & java.net.URL to help you port existing code. ## How to: Port Native Android App to iOS (iPhone) Guide DevFeed: [How to: Port Native Android App to iOS (iPhone) Guide]() Original publisher: [Read original article]() Author: Shai Almog Published: 2016-10-11T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [Mobile](), [Tutorial](), [LineageOS](), [iOS](), [Development](), [Java]() Tags: [android](), [android-development](), [development](), [guide](), [how-to](), [ios](), [iphone](), [java](), [port](), [porting]() ### AI overview This tutorial explains how to convert a simple Android application built with the Android API into a Codename One application. It introduces differences between Android and Codename One development and describes Codename One's support for building applications for Android, iOS, Windows, and other platforms. ### Source excerpt We get contacted quite a bit about the prospect of porting applications that were already written using the Android API. In this quick tutorial we will walk you thru the paces of converting a simple Android application to a Codename One application. We will also start with some basic tips covering the differences between Android & Codename One development. How does Codename One Differ from Android Development? Codename One allows Android developers familiar with Java to instantly build native applications for Android, iOS, Windows and other platforms. ## Greenbot Android Influencers: Touchlab's Kevin Galligan and Jeff Namnum chat Android apps and iOS ports - Tanya Karsou DevFeed: [Greenbot Android Influencers: Touchlab's Kevin Galligan and Jeff Namnum chat Android apps and iOS ports - Tanya Karsou]() Original publisher: [Read original article]() Published: 2015-06-26T00:36:53Z Content type: article Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Android](), [App](), [Mobile](), [iOS]() Tags: [android](), [apps](), [blog-post](), [development](), [featured](), [ios](), [porting](), [press]() ### AI overview Touchlab highlights Greenbot's profile of Kevin Galligan and Jeff Namnum, focusing on Android app development, iOS-to-Android porting, and their participation in the Android community. The post also mentions Droidcon 2015 in New York City. ### Source excerpt Today our own Kevin & Jeff were honored with an Android Influencers profile on Greenbot. Read the full progile in our latest blog post today. ## Porting a NES emulator from Go to Nim DevFeed: [Porting a NES emulator from Go to Nim]() Original publisher: [Read original article]() Published: 2015-04-30T22:00:00Z Content type: article Language: en Sources: [Dennis Felsing]() Topics: [Emulator](), [Nim](), [Go Language](), [Programming language](), [Programming](), [JavaScript]() Tags: [c](), [emulator](), [go](), [javascript](), [nim](), [porting](), [programming](), [programming-language]() ### AI overview The article describes porting a NES emulator from Go to Nim, using SDL2 as the backend and comparing compilation, binary size, source size, CPU usage, and memory usage. It also explains compiling the Nim-generated C code to JavaScript with Emscripten. ### Source excerpt Let me get this straight. We have an emulator for 1985 hardware that was written in a pretty new language (Go), ported to a language that isn't even 1.0 (Nim), compiled to C, then compiled to JavaScript? And the damn thing actually works? That's kind of amazing. -- Summary by haberman I spent the last weeks working on NimES, a NES emulator in the Nim programming language. As I really liked fogleman's NES emulator in Go I ended up mostly porting it to Nim. The source code is so clean that it's often easier to understand the internals of the NES by reading the source code than by reading documentation about it. The choice of backend fell on SDL2 for me, contrary to GLFW + PortAudio that the Go version used. This was mainly motivated by the great portability promised by SDL2. Later we will see how porting to JavaScript and Android worked. If you're impatient and want to play a game, there's a JS demo. Comparison of Go and Nim Most Go concepts are quite trivial to translate to Nim. This made the porting process simple. Let's compare some data that I found interesting: Metric Go Nim (clang backend) Compile command go build nimble build Fresh compile time 2.1 s¹ 1.7 s Recompile time 1.5 s 0.5 s Binary size 16 MB (static) 136 KB + 1MB SDL2 Source code size² 3260 lines, 74 KB 2145 lines, 60 KB CPU usage 71 % 53 % Memory usage 79 MB 73 MB ¹ Excluding go-glfw, go-gl and portaudio, which take 17 s to compile ² Emulation code only It's nice to see Nim doing well. Even the compile time is shorter than that of Go, which is well known for its short compile times. Now that the port seems to be doing fine and should be running on all Desktop platforms, let's look into some other interesting things we can do with Nim: JavaScript port via emscripten Nim has a JavaScript backend, but I don't trust it to be stable enough for this task yet. So I opted for emscripten instead, which can compile C code into JavaScript. Since Nim outputs C code, this sounds like a perfect fit. Luckily eeeee h ## HTML5 Revisited - Touchlab DevFeed: [HTML5 Revisited - Touchlab]() Original publisher: [Read original article]() Published: 2012-07-18T23:37:41Z Content type: opinion Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [HTML5](), [Framework](), [Mobile]() Tags: [application](), [compatibility](), [framework](), [html5](), [platform](), [porting](), [thoughts]() ### AI overview This opinion revisits HTML5 as an app environment and discusses Enyo, a multi-platform port of the WebOS application framework. The author expresses interest while remaining uncertain about mobile HTML5 compatibility and unresolved fundamental problems. ### Source excerpt It looks like somebody is taking the obvious yet possibly brilliant step of porting the application framework from which apps were built to the masses. ## Interview 4: Steven Edwards DevFeed: [Interview 4: Steven Edwards]() Original publisher: [Read original article]() Published: 2006-12-06T00:00:00Z Content type: article Language: en Sources: [Front Page on ReactOS Website]() Topics: [ReactOS](), [WINE](), [Fable](), [Testing]() Tags: [compiler](), [free](), [interview](), [interviews](), [kernel](), [linux](), [open-source](), [os](), [porting](), [react](), [reactos](), [testing](), [win32](), [winapi](), [wine]() ### AI overview An interview with Steven Edwards, a ReactOS developer who discusses his work connecting ReactOS and Wine, porting Wine to the MinGW compiler, testing ReactOS, and his views on building a free Windows-like environment. ### Source excerpt Steven EdwardsInterview with Steven Edwards by Aleksey Bragin This is the fourth in a series of interviews with ReactOS developers. In a few weeks we will have a nice collection showcasing the talent of the people behind ReactOS. For several years Steven Edwards has served as a valuable liaison between Wine and ReactOS. In addition, he ha's been responsible for porting Wine to the MinGW compiler and making the resulting libraries actually work.