# Red Published articles for Red. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## C++ libraries linking DevFeed: [C++ libraries linking]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2026-07-29T19:07:38Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [C++](), [toolchain]() Tags: [build](), [build-tools](), [c-plus-plus](), [clang](), [compilation](), [directx](), [gcc](), [libraries](), [linux](), [macos](), [msvc](), [static-linking](), [toolchain](), [windows](), [x86]() ### AI overview The Red toolchain now supports statically linking C++ libraries, including their runtime, on Windows, Linux, and macOS. It accepts libraries built with MSVC, GCC, or clang through the existing import system and compilation switch, with platform-specific prerequisites and constraints. ### Source excerpt When we introduced static linking of C libraries, the promise was simple: name a .lib or .a archive in your #import, compile with -s, and ship one self-contained executable, no DLLs riding along, nothing to install on the target machine. There was one big frontier left, and everyone saw it coming: the libraries people want most (vision, GUI, audio, machine learning) are written in C++. A C++ library is a very different animal to link: it brings global constructors, exceptions, RTTI, templates, thread-local storage, and an entire language runtime that expects to be wired up just so. Until now, that was the line where you switched back to DLLs. That line is gone. The Red toolchain now statically links C++ libraries too (their runtime included) on every platform Red targets: Windows, Linux (x86 and ARM), and macOS. The best part: nothing changes. It is the same import system and same compilation switch: red -r -s myapp.red Libraries built with MSVC, GCC or clang are all accepted, in their native object formats. What you need preinstalled ➤ Windows: for C++ libraries (or C code built against Microsoft's static runtime), install the free Visual Studio Build Tools with the "Desktop development with C++" workload. Just one installer, and Red locates everything by itself: no vcvarsall, no PATH, no environment variables. Plain C libraries still need nothing at all and that now extends to C libraries touching COM, DirectX or MediaFoundation: the GUID constants such code references ship inside the toolchain, so a fresh Windows 11 with only red-toolchain executable on it links them! ➤ Linux: the GNU runtime archives from your distribution's gcc packages (libstdc++.a, libgcc.a and friends) placed next to your library. If one is missing, the linker names exactly what it needs. ➤ macOS: nothing beyond the toolchain; the system C++ runtime binds automatically. Some constraints 32-bit libraries for now, until the 64-bit toolchain is ready. The imported surface must be C (extern "C", ## Static linking support DevFeed: [Static linking support]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2026-06-29T18:39:33Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [toolchain](), [C](), [parquet](), [MSVC](), [Claude Code](), [codex]() Tags: [agents](), [c](), [claude-code](), [codex](), [compression](), [mod-player](), [msvc](), [soundtracker](), [static-linking](), [toolchain]() ### AI overview The Red toolchain now supports statically linking C libraries, allowing Red/System programs to be distributed as single self-contained executables. The article explains the linker's handling of object formats, symbols, sections, and relocations, and demonstrates the process with the miniz compression library. ### Source excerpt We must free ourselves of the hope that the sea will ever rest. We must learn to sail in high winds. -Aristotle Onassis The coding agents revolution is taking the world by storm and we are right in the middle of it. Like most of you, we have experimented with the agent's amazing (and frustrating) capabilities, pondering the role of Red and our vision in that new world. The conclusion is (un)surprisingly clear, Red is still very relevant and will be even more so as we improve it to better work with agents. In the meantime, here are some treats, starting with expanding our toolchain to support static linking of libraries written in C, allowing you to distribute single executables with all dependencies packed inside. This work has been done with the heavy assistance of frontier models and local harnesses (Claude Code and Codex). You might expect that to be a small addition, but a static linker has to read each platform's object format, pull in just the pieces it needs, fold duplicated sections, resolve system symbols and patch relocations by hand, so there was quite a bit of machinery to put together. The reward is the result everyone wants: a single, self-contained binary, with nothing to install beside it. A simple example Let's compress some data without shipping a compression library next to our program. For something concrete we will use miniz, a small, MIT-licensed library that implements the well-known zlib and deflate APIs. It is distributed as a single `miniz.c` / `miniz.h` pair, which makes it especially convenient to compile and link. The first step is to compile miniz into a static library. There are only two things to keep in mind. Red/System currently produces 32-bit code, so the object has to be 32-bit too; and it helps to switch off a couple of compiler extras (C++ exception tables and stack canaries) that would otherwise make the object reference runtime helpers we do not need. On Windows, with MSVC: cl /c /MT /GS- /EHs-c- /GR- miniz.c lib /out:miniz.l ## Multiple monitors support DevFeed: [Multiple monitors support]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2025-04-15T09:08:00Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [GUI](), [Windows](), [Script](), [App]() Tags: [app](), [display](), [monitors](), [os](), [screen](), [script](), [view]() ### AI overview This blog entry describes Red View engine support for multiple monitors. It explains screen faces, virtual coordinates, scaling factors, monitor changes, and launching Red consoles and apps on different displays. View adjusts windows for displays with different DPI values, while Windows 7 uses a fallback API and some window-coordinate and child-window limitations remain. ### Source excerpt Here is a short blog entry just to explain the newly added multiple monitor support to View engine. Screen faces Each connected monitor gets associated with a screen face in system/view/screens list. You can check that all monitors have been detected correctly using (two monitors in this case): >> length? system/view/screens == 2 Each screen's /offset indicates the screen position using virtual screen coordinates. The main screen gets a (0, 0) offset. All other screens are positioned relatively to that, in the same virtual space. Screen sizes are also expressed in virtual coordinates. Screen's scaling factor is exposed in the /data facet as a float value. Monitors properties changes and adding/removing detection are also supported, updating the screens list. Windows present on removed monitors are automatically closed by the OS. A simple display-geometry.red script is provided to show how screen faces reflect the monitors topology in that virtual space: That script will also output the screen details in the console: >> do %tests/displays-geometry.red 1 - offset: (0, 0) size: (3840, 2160) scaling: 150% 2 - offset: (1165, 2160) size: (1480, 320) scaling: 100% NB: I am using a little 11.9inch screen below my main display for developing this specific feature, as it takes very little extra space on my desk. Red apps on multiple screens You can now launch Red consoles and apps on any display, the app will open on the screen it was launched from, using the specific scaling value of that screen. A get-current-screen function has been provided to return the current screen (where the mouse cursor is currently located). When displays have different scaling factor or DPI, View will adjust the window and its content to fit that scaling factor. This also works when dragging a View window between displays with different DPI, the window and its content will resize accordingly. On Windows, the API View requires, are not supported on pre-Windows8 platforms. So a new Windows7 compilat ## 0.6.6: Memory Management Improvements DevFeed: [0.6.6: Memory Management Improvements]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2025-03-19T16:11:00Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [Compiler]() Tags: [gc](), [improvements](), [memory](), [memory-management](), [release]() ### AI overview Red 0.6.6 introduces low-level memory-management and garbage-collection improvements. The release adds management for unused external resources such as image buffers and font handles, and replaces conservative native-stack scanning with a more precise approach supported by compiler-generated frame hints. ### Source excerpt This new milestone brings many low-level improvements to Red's memory management and garbage collecting. Most of those are long-planned additions needed to complete the internal memory model and make it robust enough for the future stable Red v1.0. First, here is a simplified overview of the Red memory model (existing parts in green color, new parts in orange, non-Red parts in blue): All Red values are stored in series. Some Red values require one or more buffers to hold their content. The values can never reference a buffer directly, but only through a node reference, to enable relocation when expanding the series buffer or when moving it around during compaction by the GC. Now let's dive into the hairy details! External resources GC The Red/View engine backends rely on external resources provided by the OS. Among those resources, some are linked to face! or font! object and require special care when those objects are not reachable anymore. So far, our GC (Garbage Collector) was not able to release such resources (images bitmap buffers and fonts handles), as unreachable Red aggregate values are seeing as simple series during the sweeping GC stage. In order to improve that, we have added an external resources manager, that will track and free unused resources, allowing now unrestricted images and fonts usage! Accurate GC The Red GC relies on allocated memory walking and native stack scanning to identify live Red values. Scanning the native stack can be challenging. The scanner used so far a conservative approach, which is simpler, but can lead to corruptions or crashes in rare cases (e.g. a floating point number being mistaken for a series or node pointer). Moreover, such approach precluded from having a nodes frame GC, as there was no way to accurately identify node pointers on the stack. This is now solved. The plan was always to make it precise when getting closer to a Red v1.0 and that's what we did in this release. In order to achieve that, several key addition ## Text-UI View backend DevFeed: [Text-UI View backend]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2024-06-11T14:02:00Z Content type: release Language: en Sources: [Red]() Topics: [Text-based user interface](), [User Interfaces](), [Red](), [Command-line interface](), [Linux](), [macOS]() Tags: [cli](), [console](), [examples](), [features](), [linux](), [macos](), [ui](), [user-interfaces]() ### AI overview Red/View now includes a usable, though incomplete, text-based user interface backend. The article outlines its supported widgets, drawing commands, keyboard and optional mouse handling, colors, timers, facets, platforms, configuration, and usage examples. ### Source excerpt Last year, qtxie worked on a toy text backend project and submitted a PR for that. After some extra additions and testing recently, it has now been merged even if it is still incomplete, it is usable enough. So, in addition to the shiny GUI backends in Red/View, now we have an old-school text-based user interfaces (TUI) backend for the View engine! The new TUI backend has currently a subset of the GUI backends features. Here is an overview: View styles: base, panel, button, check, radio, field, text, progress, rich-text, image and text-list. Draw commands: text, line, box, triangle, circle, ellipse (block-based for now). Rich-text supported in Draw. Keyboard handling: key-down and key events (which are the same event). Mouse handling: disabled by default. Use system/view/platform/mouse-event?: yes to enable it. Images support Truecolor (24-bit RGB) for image rendering if the terminal supports it, otherwise it falls back to 256 colors. Timers supported through /rate facet. Facets supported: /offset, /size, /text, /image, /color, /data, /enabled?, /visible?, /selected, /flags, /options, /pane, /rate, /para and /draw. Flags supported: password and all-over. Frames drawing using squared or rounded corners ( Limited ANSI escape codes support in /text facet, only Colors / Graphics Mode codes. Uses 256 colors for text. It should works fine on most of the terminals. Works on the big-3 platforms (Linux, macOS and Windows10/11). The pre-built CLI console binaries on our Download page now have View/VID included by default along with the TUI backend. You can use them to test and play with the TUI code examples here and in the TUI folder. To use the TUI backend in your own compiled code, you need to add the two following options in the Red header block: Needs: 'View Config: [GUI-engine: 'terminal] Here are a few examples, starting with a HelloWorld!: view [text "Hello TUI World!"] Hello TUI World! When view is invoked, an event loop is launched. In order to return back to the co ## Red in the real world DevFeed: [Red in the real world]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2024-05-27T17:37:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [XML](), [Parser](), [App](), [data-processing]() Tags: [also](), [code](), [data-processing](), [development](), [features](), [implementation](), [parsing](), [xml]() ### AI overview The article presents SmartXML, a commercial XML processor written in Red. Its author explains choosing Red to handle real-world XML data and avoid the complexity and breaking changes associated with many modern languages. ### Source excerpt We're often asked what Red can be used for, or what apps have been written in Red. Red can be used to write almost anything, but the sparse ecosystem and some missing pieces limit certain use cases. It's used a lot for in-house data processing, custom DSLs, simple GUI apps, and more. We also used it to build Redlake's DiaGrammar product. When we heard that someone had written a commercial app in Red, we thought that was great news, and we're here to tell you a little about it. Your first question is likely "What is it?" and the second "Where can I get it?". It's an XML processor, and you can find it here. The video on their site goes into detail about use cases and features, so we won't cover that here. We asked the author to talk about why they wrote SmartXML why those chose Red for the implementation. Here's what they had to say: Once I encountered the need to parse multiple XML files. I always thought that parsing tasks were very simple and that I wouldn't encounter any difficulties because there are things like XPath and XSD that, as I was told, solve all possible problems. However, I quickly realized that this was not the case, and some tools/standards only complicate life and are of little use for real-world usage. Thus, my XML parser project was born, which would allow working with real data rather than synthetic examples where XPath and XSD are truly effective. I chose Red because I was tired of the complexity of 90% of modern languages and the constant breaking changes in many of them. If you were to ask me what language I would choose to start a project with, looking back, I would still choose Red or perhaps try to use Hare (even considering that it's not yet completed) simply because I want to be sure that my solution will work in 10 or even 20 years. Initially, I thought I could finish within half a year, but the project took me many years. Nevertheless, I brought the project to completion. The main idea behind SmartXML was: 1. To make the parsing proces ## 0.6.5: Changelog DevFeed: [0.6.5: Changelog]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2024-02-19T15:22:00Z Content type: release Language: en Sources: [Red]() Topics: [changelog](), [Red](), [Instrumentation](), [Programming](), [CSV](), [debug](), [IO](), [JSON](), [tracing](), [XML]() Tags: [changelog](), [debugger](), [github](), [instrumentation](), [io](), [json](), [release](), [syntax](), [tracing](), [update](), [xml]() ### AI overview The Red 0.6.5 changelog documents a breaking syntax change and a large set of updates covering about 5,000 commits. It lists new datatypes, codecs, lexer and interpreter instrumentation, native functions, I/O improvements, runtime changes, and other language and library features. ### Source excerpt Bumping up the version number was motivated by the breaking syntax change done recently. We do not offer specific builds for a given version number anymore since we provide automatic builds (with builds history) on each new master commit. Though, the changelog for new version number changes will still be provided...and this one is pretty big as it covers about 5000 commits! Hope this will help users who might have missed some changes to catch up. 613 PRs were merged, 2415 fix commits were pushed, among which 902 are closing issues tracked on Github. The most notable new features and changes are listed below with eventual links to docs or previous blog posts describing or mentioning them: Main new features New datatypes: money!, ref!, point2D!, point3D!. New codecs: Redbin, JSON, CSV New high-performance run-time lexer with instrumentation support.(blog)(doc) Interpreter instrumentation support (debugger, tracer, profiler).(doc) New powerful APPLY native, with deep interpreter support.(blog) Dynamic refinements support.(blog) Adds compress and uncompress natives with gzib, zlib and deflate algorithms support. Adds gpio:// port with GPIO dialect for RaspberryPi.(blog) Adds TAB navigation support to View. (blog) Adds raw strings syntax support.(doc) Swaps map! and construction syntax. (blog) Hashtables are now used for fast lookups in contexts. Custom dtoa library implementation to load and form float values. Standard library and garbage collector stability vastly improved. Finished or almost finished features in branches:: Full IO ports with async support, including new IPv6! datatype.(branch) TextUI backend to View.(PR) XML codec.(PR) Other general new features or changes New natives: TRANSCODE, SCAN, AS-MONEY, ENHEX. New functions: SINGLE?, LAST?, DT, TRANSCODE-TRACE, TRACE, CLOCK, NO-REACT, DO-NO-SYNC New routines: SET-TRACE, TRACING? Extends EMPTY? to support map! values. Allows NONE as value in map!. Adds REMOVE/KEY support for removing map! entries. Adds FOREACH ## Important Change! Switching map and construction syntax. DevFeed: [Important Change! Switching map and construction syntax.]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2024-02-11T14:37:00Z Content type: opinion Language: en Sources: [Red]() Topics: [Red](), [Code](), [Script](), [Instrumentation](), [data]() Tags: [code](), [implementation](), [instrumentation](), [language](), [lexer](), [map](), [maps](), [migration](), [safety](), [switching](), [syntax]() ### AI overview The article announces that Red and Rebol3 will swap the syntactic forms used for map! values and construction syntax. It explains the evaluation behavior motivating the change, notes the resulting incompatibility with Rebol2 construction syntax, and describes tools for automatically converting scripts. ### Source excerpt Sometimes deep changes take a huge amount of code. Sometimes they take a lot of detailed explanation and consideration, leading to long discussions and people taking sides. Rarely does an important syntactic change to a language happen quickly, with universal agreement, simple implementation, and tools to help update scripts in the wild. Today is one of those rare days. Admittedly, this idea has been discussed for a long time. It would surface, people nodded their virtual heads, and it would submerge again. Today it's ready to deploy. Not only that, but Rebol3 is making the same change, so the two languages will still be compatible in this regard. What is the change? It's easy to describe. Today, map! values use this syntax: #(...) and construction syntax (sometimes called serialized form or loadable form) looks like this: #[...]. Going forward, those syntactic forms will be swapped. Why? The answer is easy. In Redbol langs, blocks do not evaluate by default, you have to do or reduce them. Parens, on the other hand, do evaluate by default. Today, maps use paren-like syntax, but they do not evaluate, while construction syntax uses block-like syntax, but does evaluate. This is a carryover from Rebol, so the major concession here is that Red and Rebol3 will no longer be compatible with Rebol2's construction syntax. If you've never heard of construction syntax, there's a nice explanation of it here. Red only supports a few values via construction syntax today, all datatype literals, true, false, none, and unset; but eventually it will support much more. If you look at the help for mold, you'll see that /all is TBD (very partially implemented for now), and that's how you create loadable, serialized, data that can safely and easily contain any value (like redbin but readable by humans). It helps avoid cases where none or true/false may load as words. This is also why construct evaluates those specific words (including also on/off/yes/no), but not others. When loading untr ## Tab Navigation DevFeed: [Tab Navigation]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2023-11-22T22:00:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [GUI](), [Code]() Tags: [gui](), [implementation](), [keyboard](), [native](), [navigation](), [tabbing](), [windows]() ### AI overview This article introduces tab navigation for Red's native GUI backends. It explains the mixed implementation, automatic forward and backward navigation, focusable flags, TAB-transparent faces, text-area behavior, and manual next/previous navigation overrides. ### Source excerpt We finally got tab navigation implemented! You might think it should have been an easy feature to add, but achieving a consistent and controllable behavior across our different native GUI backends is not that straightforward. So we opted for a mixed implementation with a general high-level navigation layer in Red and left spatial navigation handling to each backend, in order to preserve the native behavior as much as possible. Automatic navigation By default, pressing TAB key will allow you to navigate to all the GUI widgets in a window, capable of acquiring the focus. Once the last widget is reached, the next TAB press will circle back to the first focusable widget. Conversely, back-navigation can be achieved using Shift-TAB key combination, circling from first face to last one. Here is a simple example: view [ text "Name" field focus return text "Surname" field return below check "Single" check "Employed" button "Send" ] Note: check-boxes selection/unselection is done using the Space key (default on Windows). It is possible to make a face "TAB-transparent", so that TAB navigation will skip it in both directions. This is achieved by removing the focusable flag from a navigable face. For example, in the following code, clicking on the "Click me!" button will toggle the button's focusable flag on and off (using set-flag/toggle): view [ text "Name" field focus return text "Surname" field return below check "Single" check "Employed" button "Send" button "Click me!" 100 [ face/text: pick ["TAB ignore" "TAB stop"] to-logic face/flags set-flag/toggle face 'focusable ] ] In case of area face, the default behavior for TAB navigation means that tab characters cannot be input in the area. In such cases, the alternative Ctrl-TAB key combination can be used to input tab characters. In case the focusable flag is removed from an area face, then TAB key will directly produce tab characters. Here is an example: view [ text "Name" field focus return text "Surname" field return below ## Subpixel GUI DevFeed: [Subpixel GUI]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2023-08-09T13:32:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [GUI](), [floating-point](), [API](), [test]() Tags: [3d](), [4k](), [components](), [floating-point](), [gui](), [pairs](), [points](), [precision](), [scale](), [subpixel]() ### AI overview The article explains how Red/View addressed a GUI dragging glitch caused by converting integer coordinates to floating-point values on displays using scaling above 100%. It introduces point2D! and point3D! datatypes to represent decimal positions and sizes. ### Source excerpt Maybe you didn't notice, but Red/View, our GUI engine, has subpixel precision from the beginning! Unfortunately, that level of precision was not directly accessible to end users, until now. Actually, it would be more accurate to say that we had subpixel resolution only so far. The guilty part is the pair! datatype being limited to integer components only, while subpixel precison requires decimal numbers. So we have recently introduced new datatypes to cope with that. What urged us to make those changes now was a very peculiar visual glitch caused by that dissonance. That glitch happens during face dragging operations. Here is an example using our View test script: As you can see, on some positions, the face starts shaking while the mouse cursor remains still. This affects any type of face. The shaking is about ±2 pixels. It is caused by the difference in precision between the /offset facet expressed in integer numbers and the backend API, which only deals with floating point numbers. The accumulated error when converting integer->float->integer gives a 2 pixels difference. Such error happens on displays where the scaling factor is different from 100%. With the rise of 2K, 3K and 4K displays, a scaling factor > 100% has become the norm, making this glitch more frequent. You might think that this is not a big issue until you start building custom scrollbars and see your entire scrolled content shaking massively... New point datatypes In order to provide decimal positions and sizes for View faces, extending the existing pair! datatype was considered, though, the pair syntax can hardly scale up for such needs: 2343.122x54239.44 2343.122x54239.44x6309.332 2343.122x54239.44x6309.332x442.3321 2.33487e9x54239.44 2.33487e9x54239.44x9.83242e17 2.33487e9x54239.44x9.83242e17x5223.112 1.#infx1.#infx1.#inf As you can notice there, it quickly becomes difficult to read and identify the individual components. So we opted for adding a new literal form (hence a new datatype) that matc ## Dynamic Refinements and Function Application DevFeed: [Dynamic Refinements and Function Application]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2023-06-07T22:55:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [Code]() Tags: [apply](), [build](), [code](), [examples](), [functional](), [hof](), [technical]() ### AI overview This article explains Red's new apply functionality and dynamic refinements. It describes how dynamic refinement values are retrieved from context, how unused arguments are handled, and how Apply/all supplies function parameters in specification order with type-checked logic values for refinement slots. ### Source excerpt It's Time to Apply Yourself to Red Red has never had an apply function, though we knew it would come someday. In the meantime, some of us rolled our own. Gregg's was simple, neither flexible nor efficient, and just a couple lines of code. Boris made a much more capable version, but it could still only be so fast as a mezzanine. R2 had a mezz version, which suffered the same problem. All that changes now. Apply is dead! Long live Apply! It required deep work, and a lot of design effort, but we think you'll like the results, whether you're a high-level Reducer, or anxious to see how much leverage you can, um, apply, from a functional perspective. Everybody wins. If you don't know what apply is, in terms of functional languages, take a moment and read up. If you can get through the introduction there without getting dizzy, great. If your head is spinning, feel free to stop after the first section of this article and ignore the deep dive. You still get 90% of the value for most high level use cases. Gregg got so dizzy that he fell down, but was still able to help with this article. Function application is largely about composition. How you can combine functions in a concise way for maximum leverage and minimum code. The problem with its design in many languages is that it makes things harder to understand. Rather than concrete functions names, there is indirection and abstraction. It can be tricky to get right, especially in a flexible language like Red, while also maintaining as much safety as possible. You can drive fast, but still wear your seat belt. Dynamic Refinements This subtle feature is likely to see wide use, because it will reduce code and let people build more flexible functions. It's also easy to explain. Here's an example. First, how you would write it today: repend: func [ {Appends a reduced value to a series and returns the series head} series [series!] value /only "Appends a block value as a block" ][ either only [ append/only series reduce :value ][ a ## New Red binaries DevFeed: [New Red binaries]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2022-07-29T16:18:00Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [toolchain](), [Command-line interface](), [GUI](), [Compiler](), [releases]() Tags: [availability](), [binaries](), [cli](), [compiler](), [console](), [download](), [gui](), [releases]() ### AI overview Red introduces separate pre-built binaries for its GUI console, CLI console, and toolchain to reduce first-use delays. The project is temporarily dropping semantic versioning before version 1.0 and will primarily provide binaries for the latest commit. ### Source excerpt Since many years, we are offering pre-built binaries for the Red toolchain, as a more convenient way to use Red, even if it is not strictly needed, as Red can be run from its sources, the toolchain being run by a Rebol2 interpreter. As the Red REPL and toolchain are not run by the same engine, the console (REPL) used to be compiled on first run of the `red` executable (when no arguments was provided or a Red script was passed). This resulted in a significant delay on the first use of the console (both for the GUI and CLI versions). We have now decided to change that by providing separate pre-built binaries for the consoles and toolchain. This is a temporary split until Red gets self-hosted, at which point we can recombine everything into a single binary. Another change is the temporary dropping of the semantic versioning until version 1.0 and related "stable" releases, as it seems to be too confusing to some users (Red being still in alpha stage). This also will remove a tendency from some users to care more about version increments than feature availability and work being done overall. We will now be proposing only pre-built binaries for latest commit, though older binaries will still be available if that can be of any help to anyone. So the pre-built binaries now are: Red GUI : Red interpreter + View + GUI console Red CLI : Red interpreter + CLI console Red Toolchain : Encapper for Red + Red/System compiler We are also considering ways to merge the GUI and CLI consoles into a single binary which can work even if no GUI API is available, falling back on CLI mode. We will also have the console(s) act as a front-end for the toolchain, even downloading it for you in the background when needed. Though for that we need a proper asynchronous `call` function implementation. More news about this soon. In the meantime, enjoy running Red consoles almost instantly from just a click on the Download page! ## The Road To 1.0 DevFeed: [The Road To 1.0]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2022-07-14T16:41:00Z Content type: opinion Language: en Sources: [Red]() Topics: [Red](), [modules](), [Package Management](), [Concurrency](), [toolchain](), [Compiler]() Tags: [announce](), [build](), [compilation](), [concurrency](), [modular](), [package-management](), [toolchain]() ### AI overview The Red project presents an updated plan focused on completing its core language and reaching version 1.0. The plan includes upgrading the 32-bit implementation, formalizing the language specification, adding modules and package management, defining a concurrency model, and preparing a new toolchain. ### Source excerpt You cannot have missed that in the last months (and even last years), our overall progress has slowed down drastically. One of the main reasons is that we have spread our limited resources chasing different objectives while making little progress on the core language. That is not satisfying at all and would bring us most likely to a dead-end as we exhaust our funding. We have spent the last weeks discussing about how to change that. This is our updated action plan. From now on, our only focus will be to finish the core language and bring it to the much-awaited version 1.0. We need to reach that point in order to kickstart a broader adoption and provide us and our users a stable and robust foundation upon which we can build commercial products and services necessary for sustainability. Given the complexities involved in completing the language and bringing an implementation that can run on modern 64-bit platforms, we have devised a two-stage plan. Upgrade the current 32-bit Red implementation 👉 Language specification It is now time to do so in order to clean-up some semantic rules and address all possible edge cases which will help fulfill our goals of implementation robustness and stability. The process of writing down the complete language specs will result in dropping some features that we currently have that end up being problematic or inconsistent. OTOH, we might add some new features that will need to be implemented for 1.0. 👉 Modules We need a proper module system in order to be scalable. We also need to have a proper package management system which will be tied to a central repo where we can gather third-party libraries. That would also enable modular/incremental compilation (or encapping) which will be most probably supported in the self-hosted toolchain. 👉 Concurrency We need a proper model for concurrent execution in order to leverage multicore architectures. We will define one and make a prototype implementation in the 32-bit version. 👉 Toolchain Before s ## 2021 Winding Down: Software Complexity, Inconsistency, and Outsourcing DevFeed: [2021 Winding Down: Software Complexity, Inconsistency, and Outsourcing]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2021-12-31T20:23:00Z Content type: opinion Language: en Sources: [Red]() Topics: [systems](), [consistency](), [Software](), [Logging](), [coding](), [Tool]() Tags: [apis](), [article](), [blog](), [blog-post](), [complexity](), [consistency](), [developer](), [logging](), [software]() ### AI overview A Red project blog post reflects on software complexity, arguing that outsourcing simple features and accumulating libraries can create inconsistent environments. It also discusses the shift from libraries toward APIs and service-based companies, along with the associated dependency risks. ### Source excerpt Another quarter, another blog post. Seems almost rushed after the previous drought. To set the stage, I'll start with a bit of a rant about complexity. If you just want the meat of what's happening in the Red world, feel free to skip the introduction. Complexity Considerations: Part 1 I liked what the InfoWorld article, Complexity is Killing Software Developers said, which we all know, about difficult domains (voice and image recognition, etc.) being available as APIs. This lets us tackle things we couldn't in some cases. Though I imagine @dockimbel or others also used Dragon Dictate's libraries back in the 90s. What we have now is massive data to train systems like that. Those work well, allowing us to add features we otherwise couldn't with a small team. The problem I see is that the trend has become for everything to be outsourced, including simple features like logging, and those libraries have exploded. There must be graphs available to show the change. Moderately complex domains, UIs for example, have risen in number and lead to what @hiiamboris says about Brownian Movement. It's a random collection of things, not designed to work together, without a coherent vision. A quote from the above article says it this way: "Complexity is less the issue than inconsistency in an environment." It used to be that you could take a FORTRAN, COBOL, Lisp, VB, Pascal/Delphi, Access/PowerBuilder, dBase/Clipper/Paradox, or even a Java developer, drop them into a project, and they could work from a solid core, learning the team's custom bits and any commercial tools as they went. With JS leading the way, but not alone in this, a programmer can only rely on a much smaller core, relative to how many libraries are used. Because those libraries, and the choices to use a particular combination of them were not designed to work together, there is no guarantee (or perhaps hope) of consistency to leverage. It's worse if you came from a history of other tools that were based on different ## Red Team Update: DiaGrammar, Product Development, and Red Language Progress DevFeed: [Red Team Update: DiaGrammar, Product Development, and Red Language Progress]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2021-08-04T00:21:00Z Content type: opinion Language: en Sources: [Red]() Topics: [Red](), [Development](), [Open Source](), [Software]() Tags: [blog-post](), [open-source](), [product-development](), [software](), [update]() ### AI overview The Red team explains a year of team changes, its shift toward product development alongside core Red Language development, and the release and subsequent updates of DiaGrammar for Windows. The team also describes lessons from building a commercial product and reports more than 400 fixes and 100 features added to Red. ### Source excerpt It's been almost a year since our last blog post. Sorry about that. It's one of those things that falls off our radar without a person dedicated to it, and we run lean so don't have anyone filling that role right now. We know it's important, even if we have many other channels where people can get information. So here we are. Last year was a tough year all around, even for us. We were already a remote-only team, but the effect the pandemic had on the world, particularly travel, hit us too. We had some team changes, and also split our focus into product development alongside core Red Language development. This is necessary for sustainability, because people don't pay for programming languages, and they don't pay for Open Source software. There's no need to comment on the exceptions to these cases, because they are exceptions. The commercial goal, starting out, is to focus on our core strengths and knowledge, building developer-centric tools. Our first product, DiaGrammar for Windows, was released in December 2020, and we've issued a number of updates to it since then. Our thanks to Toomasv for his ingenuity and dedication in creating DiaGrammar. We are a team, but he really accepted ownership of the project and took it from an idea to a great product. Truly, there is nothing else like it on the market. We learned a lot from the process of creating a product, and will apply that experience moving forward. An important lesson is that the product itself is only half the work. As technologists, we're used to writing the code and maybe writing some docs to go with it. We don't think about outreach, marketing, payments, support, upgrade processes for users, web site issues, announcements, and more. The first time you do something is the hardest, and we're excited to improve and learn more as we update DiaGrammar and work on our next product. We'll probably announce what it will be in Q4. One thing we can say right now is that the work on DiaGrammar led to a huge amount of ## Red/System: New Features DevFeed: [Red/System: New Features]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2020-08-20T10:54:00Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [Code]() Tags: [arrays](), [atomic](), [bugfixes](), [compilation](), [exceptions](), [features](), [floating-point](), [fpu](), [ia-32](), [literal-arrays](), [math](), [new-features](), [pointers](), [red-system](), [runtime-errors](), [vfp]() ### AI overview An overview of recent Red/System features, including subroutines, atomic and stack intrinsics, FPU status access, and changes to literal arrays. ### Source excerpt In the past months, many new features were added to Red/System, the low-level dialect embedded in Red. Here is a sum up if you missed them. Subroutines During the work on the low-level parts of the new Red lexer, the need arised for intra-function factorization abilities to keep the lexer code as DRY as possible. Subroutines were introduced to solve that. They act as the GOSUB directive from Basic language. They are defined as a separate block of code inside a function's body and are called like regular functions (but without any arguments). So they are much lighter and faster than real function calls and require just one slot of stack space to store the return address. The declaration syntax is straightforward: : [] : subroutine's name (local variable). : subroutine's code (regular R/S code). To define a subroutine, you need to declare a local variable with the subroutine! datatype, then set that variable to a block of code. You can then invoke the subroutine by calling its name from anywhere in the function body (but after the subroutine own definition). Here is a first example of a fictive function processing I/O events: process: func [buf [byte-ptr!] event [integer!] return: [integer!] /local log do-error [subroutine!] ][ log: [print-line [">>" tab e "<<"]] do-error: [print-line ["** Error:" e] return 1] switch event [ EVT_OPEN [e: "OPEN" log unless connect buf [do-error]] EVT_READ [e: "READ" log unless receive buf [do-error]] EVT_WRITE [e: "WRITE" log unless send buf [do-error]] EVT_CLOSE [e: "CLOSE" log unless close buf [do-error]] default [e: "" do-error] ] 0 ] This second example is more complete. It shows how subroutines can be combined and how values can be returned from a subroutine: #enum modes! [ CONV_UPPER CONV_LOWER CONV_INVERT ] convert: func [mode [modes!] text [c-string!] return: [c-string!] /local lower? upper? alpha? do-conv [subroutine!] delta [integer!] s [c-string!] c [byte!] ][ lower?: [all [#"a" <= c c <= # ## A New Fast and Flexible Lexer DevFeed: [A New Fast and Flexible Lexer]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2020-08-03T12:06:00Z Content type: release Language: en Sources: [Red]() Topics: [Red](), [Programming language](), [Parsing](), [Instrumentation](), [API]() Tags: [callback](), [code](), [compiler](), [function](), [implementation](), [instrumentation](), [lexer](), [load](), [performance]() ### AI overview The Red programming language has introduced a new lexer written in Red/System. It is designed to load large quantities of Red values quickly and adds scanning and event-oriented instrumentation features. The article reports typical performance gains of 50 to 200 times over the previous lexer and describes benchmark tasks and known issues affecting older-version results. ### Source excerpt A programming language lexer is the part in charge of converting textual code representation into a structured memory representation. In Red, it is accomplished by the load function, which calls the lower-level transcode native. Until now, Red was relying on a lexer entirely written using the Parse dialect. Though, the parsing rules were constructed to be easily maintained and not for performance. Rewriting those rules to speed them up could have been possible, but rewriting the lexer entirely in Red/System would give the ultimate performance. It might not matter for most user scripts, but given that Red is also a data format, we need a solution for fast (near-instant) loading of huge quantities of Red values stored in files or transferred through the network. The new lexer main features are: High performance, typically 50 to 200 times faster than the older one. New scanning features: identify values and their datatypes without loading them. Instrumentation: customize the lexer's behavior at will using an event-oriented API. The reference documentation is available there. This new lexer is available in Red's auto-builds since June. Performance Vastly increased performance is the main driver for this new lexer. Here is a little benchmark to let you appreciate how far it gets. The benchmarking tasks are: 100 x compiler.r: loads 100 times compiler.r source file from memory (~126KB, so about ~12MB in total). 1M short integers: loads a string of 1 million `1` separated by a space. 1M long integers: loads a string of 1 million `123456789` separated by a space. 1M dates: loads a string of 1 million `26/12/2019/10:18:25` separated by a space. 1M characters: loads a string of 1 million `#"A"` separated by a space. 1M escaped characters: loads a string of 1 million `#"^(1234)"` separated by a space. 1M words: loads a string of 1 million `random "abcdefghijk"` separated by a space. 100K words: loads a string of 100 thousands `random "abcdefghijk"` separated by a space. And the ## GTK, fast lexer, money, deep testing, and our first commercial product DevFeed: [GTK, fast lexer, money, deep testing, and our first commercial product]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2020-03-20T19:00:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [GTK](), [Testing](), [reactive]() Tags: [automated](), [bug](), [code](), [experimental](), [floating-point](), [gui](), [identifier](), [implementation](), [money](), [operating-systems](), [reactive](), [testing]() ### AI overview A Red team update covering progress on GTK support and a fast lexer, automated view testing for GUI bugs, and new datatypes including the planned money! type for accurate financial calculations. ### Source excerpt It's been a busy start to the year for the team. Work has continued on many fronts, and we have some new team members helping us to keep the momentum going. We announced in January that GTK and the Fast Lexer were close, and they are even closer now. The hard part about making announcements is that some of this work is unpredictable and changes in scope after we do. Or the world steps in and a pandemic throws a wrench into your plans. @bitbegin has done an enormous amount of work on the GTK branch. You can check out the GTK branch to see some of what goes into supporting a new GUI system. The more features we include in Red, the more that have to be ported and maintained. Unfortunately, most operating systems and UI systems have large, complicated sets of APIs and interactions. Because GUI systems are so complex, and Red not only has to handle them, but also adds its own reactive framework, there are more places for bugs to hide. And users are involved, which is the worst part. They do nothing but cause problems. To that end, in addition to his normal deep diving and bug hunting, @hiiamboris has been working on an automated view test system, which is no small feat. @9214 has joined him on the hunt, and we will squash a good number of bugs for our next release. The fast lexer was in near-final testing when we decided that it was worth delaying its merge in order to incorporate some new lexical forms that we had planned to include. Then we looked at some old tickets related to modulo and division operators, and a couple lexing questions came up related to tag!. Suddenly the fast lexer work was back in code mode. New lexical forms usually means new datatypes, and that's the case here. New Datatypes One we've expected for some time, and thanks to @9214 it's now a reality. Money! is coming. There is a branch for it, but no need to comment at this time. There are a few features, like round still to be completed, but the bulk of the work is done. @BeardPower did some great ## Red announces preliminary Parse documentation and other planned projects for 2020 DevFeed: [Red announces preliminary Parse documentation and other planned projects for 2020]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2020-01-01T07:23:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [Parsing](), [Documentation]() Tags: [compilers](), [decoding](), [documentation](), [encoding](), [languages](), [lexer](), [parsing](), [validation]() ### AI overview Red's New Year article previews projects planned for 2020, including a new product and a robust preliminary draft of documentation for the Parse dialect. It explains Parse's uses in searching, validation, extraction, modification, language processing, and encoding and decoding data formats. ### Source excerpt Hello and happy new year, friends of Red! We have some exciting projects we've been working on that will be available this year, including a new product. Let's talk a little about what the team has been working on behind the scenes. (TL;DR: A cool new product with Red in 2020...plus, a robust preliminary draft of Parse documentation can now be previewed...CLI library...fast-lexer to merge soon...GTK on the horizon...and a new native OS calendar widget!) Documentation for Parse: Red's Language Construction Tool Our esteemed forerunner, Rebol, broke new ground with its Parse dialect, which Red has expanded on. Today, in Red, Parse has become an even more powerful built-in dialect (embedded domain-specific language) that processes input series with grammar rules in a clean and simple manner. Other language building tools exist, of course, such as Lexx and Yacc. ANTLR is a modern framework built in Java, and libraries exist for other languages, but the ease of use and power that Red's Parse offers is unique. This isn't a new feature, by any means, with the first public introduction here. Parse is easy enough to use that those basic docs have been enough, for the most part. But over time, with new users joining the Parse chat room to discuss the dialect, and it was time for full reference documentation. For the uninitiated, Parse can be used to for searching, to surface various patterns; validation, in order to confirm an input's compliance to a specification; extraction, to sift through data and aggregate values; and modification--that is, changing the input stream itself (insertion of values, removing or transforming matched input). And Parse's true power lies in language processing (compilers, interpreters, and lexical analyzers), particularly for DSLs; and encoding/decoding, to "translate" data formats from one to another. What makes Red's Parse dialect a killer feature is that you can do more than parse at the character level in strings of text. That's what every ot ## November 2019 in Review DevFeed: [November 2019 in Review]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2019-12-04T22:07:00Z Content type: opinion Language: en Sources: [Red]() Topics: [Red](), [Testing](), [GitHub](), [GTK]() Tags: [community](), [contributors](), [review](), [testing]() ### AI overview Red's November 2019 review highlights restored historic automatic builds, Red's addition to Stackshare, plans for beta testers for a new Red-built product, a proposal for standardizing series evolution, and more than 60 commits to the GTK branch. ### Source excerpt Welcome to December, friends of Red. It's an intent and focused time of year as we wind down 2019, and the core team is making important moves (sometimes literally!) to set us up for an ambitious 2020. But first, here are just a few things that happened in November. First and foremost, it's always great when community members help compile resources for use by others, and we'd like to acknowledge @rebolek for his excellent compendium of historic automatic builds: https://rebolek.com/builds/ (they weren't available for a hot minute, but now they're back). They can be useful if you're in need of a previous version for a specific project. Of course, you can always go here for Red's daily automated builds. But seeing as how we've a goal of being a self-sustaining, self-selecting group of do-ers, this spirit of providing collective resources is perfectly aligned with the Red-Lang we always want to be. From the community, to outreach: thanks to community member @loziniak, Red is now on Stackshare, so be sure to follow us there and chime in. As a repo with 4.1k GitHub stars (and infinite possibilities), Red has a lot to offer the wider community of developers and engineers, and Stackshare is a great place to help compare and contrast us with other languages. Now, a challenge! In the coming new year we'll be needing beta testers willing to lend their expertise in refining a new product built with Red. You read that right! If you think you'd like to be one of the contributors to spearhead a move into our next phase, we want YOU! Drop a line to @greggirwin to get in on the ground floor. An appreciation to @hiiamboris for his deeply thought out proposal regarding "series evolution," a framework for standardizing and testing the functions we use in Red for manipulating series. Design is hard, and we have a number of initiatives in the works taking a lot of brain power right now. Over 60 commits were made to Red's GTK branch in November, making it almost ready for "prime time." T ## Editorial: A Brief Essay on Lexical Ambiguity by G. Irwin DevFeed: [Editorial: A Brief Essay on Lexical Ambiguity by G. Irwin]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2019-11-19T23:16:00Z Content type: opinion Language: en Sources: [Red]() Topics: [Red](), [Programming]() Tags: [community](), [editorial](), [languages](), [lexer](), [syntax]() ### AI overview An editorial essay examines lexical ambiguity in Red and the trade-off between adding specialized lexical forms and preserving a language's flexibility, usability, and learnability. It argues that new lexical forms offer diminishing value and that a constrained hierarchy can help users remember rules. ### Source excerpt The original commentary was posted in Red's Gitter channel, here, by Gregg Irwin, one of our core team members, in response to various requests for the ability to create new datatypes in Red. As a writer, Red has always appealed to me because of its flexibility; but, of course, "the [lexicon] devil is in the details," as the idiom goes (okay, I edited that idiom a little, but it was too cool a link to pass up). It means the more specific we try to be, the more challenges and limitations we encounter, and we can lose some of the amazing versatility of the language. On the other hand, precision and refinement--the "exact right word at the exact right time," can powerfully enhance a language's utility. The dynamic tension between what he calls "generality and specificity, human friendliness and artifice," in the text below, can be an energetic ebb and flow that serves to strengthen our language, to make it more robust. Two quotes from community members provide some context: _____________________________ > The real problem is not number of datatypes, but the lexical syntax of the new ones. -@Oldes > ...However if something like utype! is added, nothing prevents you from (ab)using system/lexer/pre-load and reinventing whole syntax. -@Rebolek "I don't support abusing system/lexer/pre-load, and (in the long view) there will almost certainly be special cases where a new lexical form makes sense. We can't see the future, so we can't rule it out. But, and this is key, how much value does each new one add? I believe that each new lexical form adds less value, and there is a point of diminishing returns. This is not just a lexical problem for Red, but for humans. We have limited capacity to remember rules, and a constrained hierarchy helps enormously here. Think more like linguists, and less like programmers or mathematicians. In language we have words and numbers. Numbers can be represented as words, with their notation being a handy shortcut for use in the domain of mathemati ## A Deeper Dive Into the Fast-Lexer Changes DevFeed: [A Deeper Dive Into the Fast-Lexer Changes]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2019-10-30T19:18:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [Programming](), [Visual Studio Code](), [benchmarking]() Tags: [benchmarking](), [lexer](), [performance](), [programming](), [programming-languages](), [syntax](), [vscode]() ### AI overview The article explains why Red prioritized a new fast lexer. Benchmarking found the existing lexer was about 240 times slower than Rebol's, while duplicated lexer code also affected the console and VSCode plugin. The planned solution was to implement a smaller, simpler lexer in Red/System, inspired partly by research on fast parsers. ### Source excerpt What made the fast-lexer branch a priority? Several things. It started when @dockimbel looked into ticket #3606, which was impossible to fix currently, and we didn't want to give up on the auto-syncing between /text and /data facets. So he had to consider bigger options, including how to make the lexer instrumentable. It was not easy, because the current lexer is not re-entrant, so having the lexer emit events to a callback function could have caused serious problems. Digging through all Red's repos showed that the current lexer code was duplicated twice, beyond the basic lexing needed by load: once in the console code, once in the VSCode plugin, each time for syntax coloring purposes, and each one lagging behind the original implementation. Not good. @Dockimbel then considered changing the current lexer to make it instrumentable, but the changes were significant and would have made the parse rules much more complex. At the same time, @qtxie did some benchmarking, and the result showed Red's lexer was ~240 times slower than Rebol's. This is not due to parse, but rather because the high-level rules were optimized for readability, not performance. The lexer also caused delays in the VSCode plugin, because of its (lack of) performance. The high level code has served Red well, and was a showcase for parse, but loading larger data is also being used by community members, and data sizes will just keep growing. With some projects we have on the horizon, the lexer's performance became a higher priority. As planned since the beginning (the lexer used to be R/S-only during the pre-Unicode era), @dockimbel decided the best option was to not postpone the conversion of the lexer to pure R/S code any longer, by porting R3's C-based lexer to R/S. After studying Rebol's lexer in detail, he realized that the code was quite complex in some places (mostly the prescanner), and would lead to less than optimal R/S code that would be hard to maintain. Evaluating the state of the art in fa ## October 2019 In Review DevFeed: [October 2019 In Review]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2019-10-25T06:14:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [Finite-state machine](), [Compiler](), [cpu](), [Code](), [Wiki]() Tags: [code](), [compiler](), [cpu](), [documentation](), [github](), [performance](), [testing]() ### AI overview An October 2019 Red language review reports major progress on the fast-lexer branch. Benchmarks describe substantially faster loading for large word and integer inputs, while the implementation remains unfinished and still requires keyword-loading and symbol-table optimizations. The article also highlights community guides, code statistics, build archives, and development tools. ### Source excerpt Over the last few weeks the Red Lang core team drilled down to make some truly great progress on Red's fast-lexer branch--while we also gained valuable support from the contributions of Red doers and makers as they consolidate a world of useful information and resources. Fast-Lexer Benchmarks In the fast-lexer branch of Red, you can see lots of new work from Red creator @dockimbel (Nenad Rakocevic) and core teammate @qxtie. Among other fixes and optimizations, they substituted a hashtable for what had previously been a large array in context! The numbers so far: Loading 100'000 words (5 to 15 characters, 1MB file): Red (master): 19000ms. Red (fast-lexer): 150ms. Nenad's observations on further testing: "FYI, we just [ran] some simple benchmarks on the new low-level lexer for Red using 1M 10-digit integers. The new lexer completes the loading about 100 times faster than the current high-level one. Loading 1M 10-digit integers in one block: Red: 175ms; R2: 136ms; R3: 113ms. "We use a faster method than Rebol, relying on several lookup tables and a big FSM with pre-calculated transition table (while Rebol relies on a lot of code for scanning, with many branches, so bad for modern CPU with branch predictions). With an optimizing backend, Red's LOAD should in theory run 2-3 times faster than Rebol's one. (Though, we still need to optimize the symbol table loading in order to reach peak performance). Given that Rebol relies on optimized C code while Red relies on sub-optimal code from R/S compiler, that speaks volume about the efficiency of our own approach. So, Red/Pro should give us a much faster LOAD. "The lexer is not finished yet, but the hard part is done. We still need to figure out an efficient way to load keywords, like escaped character names (`^(line), ^(page), ...) and month nouns in dates." This is a huge accomplishment, and it's shaping up to make future goals even more impressive. The fast-lexer branch is a work in progress, but stay tuned: Nenad has more t ## Red community update: experimental CSV codec, GitHub milestones, and an AI toolkit discussion DevFeed: [Red community update: experimental CSV codec, GitHub milestones, and an AI toolkit discussion]() Original publisher: [Read original article]() Author: Unknown (noreply@blogger.com) Published: 2019-09-15T19:23:00Z Content type: article Language: en Sources: [Red]() Topics: [Red](), [CSV](), [data](), [Code]() Tags: [community](), [experimental](), [format](), [github](), [programming]() ### AI overview A Red community update highlights recent ticket closures, an experimental CSV codec added to nightly builds, Red reaching 4,000 GitHub stars, and a discussion about building an AI toolkit that supports configurable recognition tasks, datasets, and fine-tuning. ### Source excerpt Hello to all the great makers, doers and creative people who are using Red, helping the Red Language grow and improve! As always, there's a standing invitation for you to join us on Gitter, Telegram or Github (if you haven't already) to ask questions and tell us about your Red-powered projects. Here are some recent highlights we'd like to share with you: 1. Tickets Get Priority In the last month, our core team has closed a large number of tickets.We'd like to thank community members rgchris, giesse, and dumblob who are just a few of the passionate contributors putting Red through its paces and providing feedback as fixes and changes occur. @WArP ran the numbers for us, showing a cyclical growth pattern linking bursts of closed issues and some serious Red progress, and September's not even done yet!...: 2. CSV Codec Available Our newly updated CSV codec has been merged in the master branch and is now a part of the nightly (or automatic) build here. It is in an experimental phase, and we want your feedback. Should the standard codec only support block results, so it's as simple as possible? Or do people want and need record and column formats as well (using the load-csv/to-csv helper funcs, rather than load/as)? Including those features as standard means they're always available, rather than moving them to an extended CSV module; but the downside is added size to the base Red binary. Applause goes to @rebolek's excellent organization and his wiki on the codec, which explains the various ways in which Red can represent data matrices. He writes, "Choosing the right format depends on a lot of circumstances, for example, memory usage - column store is more efficient if you have more rows than columns. The bigger the difference, the more efficient." You can judge their efficiency here, where @rebolek has laid out the compile time, size and speed of each version, including encapping and lite. Be sure to get the latest build, and chat with everyone on Gitter to tell us what [Next page]()