Rebol pdf

It is attractive because it gives Africa the flexibility to try out different policies rather than coercing the continent into a certain direction. What creates China's soft power in Africa is a system which bases its legitimacy on the improvement of living conditions of the people, rather than on the spread of an ideology, even if this ideology comes in the name of democracy or human rights.

China and Africa Author : David H. Native Pragmatism Author : Scott L. Can Rebol do this? Ask Question. Asked 10 years, 8 months ago. Active 10 years, 8 months ago. Viewed times. How do I resend this cookie along with the next request. Improve this question. Justin Morgan Rebnoob Rebnoob 1 1 silver badge 4 4 bronze badges. In the future, you probably want to post several separate questions when they span across topic areas like this!

Add a comment. Active Oldest Votes. Can the parse function do everything that RegEx can? Improve this answer. Community Bot 1 1 1 silver badge. That really helps! Thanks for the answer Hostile Fork!

Big fan of your blog! Updated RE:sessions. I don't want to see my friends and colleagues burn out, when it was probably the enjoyment and passion that solving problems with software can bring which led them here to begin with. Every moving part in your system is a potential point of failure. Reduce the moving parts and reliability increases. Whether it's the OS you run on we now have more of those than ever, between Linux distros and mobile platforms always trying to outdo each other , extra packages or commercial tools, FOSS libraries, environments, [?

And if any of them break your code, or your system, even in the name of improvements or bug fixes, you may find yourself running just to stay in the same place. Many of those pieces are touted as the solution to reliability problems, but a lot of them just push problems around, or target problems you don't have. Don't solve problems you don't have. That adds complexity, and now you really have a problem.

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 , 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 work on a more general diagramming subsystem for Red.

It's really exciting, and we'll talk more about that in a future blog post. Since our last blog post we've logged over fixes and features into Red itself. Some of these are small, but important, others are headline-worthy; some are deep voodoo and some visible to every Reducer what we call Red users. For example, most people use the console the REPL , so the fixes and improvements there are easy to see.

This could happen if you printed output in a tight loop. The results would only show up at the termination of the loop, when the system could breathe again. That's been addressed, but wasn't easy and still isn't perfect. Red is still single threaded, so there's no separate UI thread pros and cons there. We make these tradeoffs every day, and need feedback from users and real world scenarios to help find the right balance. Less obvious are things like improvements to parse , which not everyone uses.

Or how fmod works across platforms, and edge cases for lexical forms e. NaN valid? The latter is particularly important, because Red is a data language first. JSON is so widely used that we felt the time spent, and the tradeoffs made, were worth it.

It also nicely shows one of Red's strengths. Profiling showed that the codec spent a lot of time in its unescape function. No external compiler needed, no need to use C, and the code is inlined so it's all in context.

Should your JSON be malformed, you'll also get nicer error information now. As always, Red gives you options. Some features cross the boundary of what's visible. A huge amount of work went into D2D support on Windows. D2D is Direct2D, the hardware-accelerated backend for vector graphics on Windows. For users, nothing should change as all the details are hidden. But the rendering behavior is not exactly the same. We try to work around that, but sometimes users have to make adjustments as well; we know because DiaGrammar is written in Red and uses the draw dialect heavily.

It's an important step forward, but comes at a cost. Time marches on and we need to look forward. It hasn't been merged into the main branch yet, but we expect that to happen soon. The higher level API is still being designed. At the highest level, these details will all be hidden from users. Another big "feature" came from vazub: NetBSD support. The core team has to focus on what stands to help the project overall, with regard to users and visibility.

Community support for lesser known platforms is key. If you're on one of those platforms, be or find a champion. We'll help all we can, but that's what Open Source is for. Thanks for this contribution vazub! We also have some new Python primers up, thanks to GalenIvanov. Start at Coming-to-Red-from-Python. Information like this is enormously important.

Red is quite different from other languages, and learning any new language can be hard. We're used to a set of functionality and behaviors, which sometimes makes the syntax the easiest part to learn. Just knowing what things are called is a learning curve. Red doesn't use the same names, because we and Carl when he designed Rebol took a more holistic view. That's a hard sell though.

We feel the pain. A user who found Red posted a video as they tried to do some basic things. We learned a lot from watching it. Where other languages required you to import a networking library, it's already built into Red. When they were looking for request or http. It's obvious to us, but not to the rest of the world. So these new primers are very exciting. We'll get there though. The world moves fast, and software projects are often judged by their velocity.

We even judge ourselves that way, and have to be reminded to stay the course, our course, rather than imitating others. Red's flexibility also comes into play.

Where other languages may limit how you can express solutions, we don't. It's so flexible that people can do crazy things or perform advanced tricks which end up being logged as bugs and wishes.

Sometimes we say No a lot of times in fact , but we also try to keep an open mind. We have to ask " Should that be allowed? It has to evolve, but not breaking the format is fundamental. And while code is expected to change, once people depend on a function or library it causes them pain if we break compatibility.

We don't want to do that, though sometimes we will for the greater good and the long view. There are technical bandages we can patch over things, but it's a big issue that doesn't have a single solution. Not just for us, but for all software development. We'll talk more about this in the future as well. The compiler was wrongly generating code for loading a even though size?

Given that a was a float type, its value was pushed onto the x87 FPU stack, but never popped. That stack has a 7 slots limit. Running the loop 5 times was enough to leave only 2 slots free.

When the big float expression is encountered in dtoa library, it requires 3 free slots on the FPU stack, which fails and results in producing a NaN value, which wreaks havoc in the rest of the code. Here is a sum up if you missed them. 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 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.

To define a subroutine, you need to declare a local variable with the subroutine! You can then invoke the subroutine by calling its name from anywhere in the function body but after the subroutine own definition. This second example is more complete. It shows how subroutines can be combined and how values can be returned from a subroutine:. Support for getting a subroutine address and dispatching dynamically on it is planned to be added in the future something akin computed GOTO.

More examples of subroutines can be found in the new lexer code, like in the load-date function. The size of a literal array can now only be retrieved using the size? A notable addition is the support for binary arrays. Those arrays can be used to store byte-oriented tables or embed arbitray binary data into the source code. For example:. It is now possible to group the type declaration for local variables and function arguments.

Note that the compiler supports those features through code expansion at compile time, so that error reports could show each argument or variable having its own type declaration. Integer division handling at low-level has notorious shortcomings with different handling for each edge case depending on the hardware platform. Intel IA architecture tends to handle those cases in a slightly safer way, while ARM architecture produces erroneous results silently typically for the following two cases:.

This makes it difficult to produce code that will behave the same on both architectures when integer divisions are used. Such extra checkings for ARM are produced only in debug compilation mode.

In release mode, priority is given to performance, no runtime exception will occur in such cases on ARM as the overhead is significant. So, be sure to check your code on ARM platform thoroughly in debug mode before releasing it. This is not a perfect solution, but at least, it makes it possible to detect those cases through testing in debug mode. Cross-referenced aliased fields in structs defined in same context are now allowed.

The reference documentation is available there. This new lexer is available in Red's auto-builds since June. December 31, Winding Down. Another quarter, another blog post. Seems almost rushed after the previous drought. 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. A quote from the above article says it this way: "Complexity is less the issue than inconsistency in an environment.

Complexity Considerations: Part 2 Complexity doesn't come only in the form McCabe is famous for, the decision points in a piece of code, but in how many pieces there are and how often they change either by choice or necessity.

Less Philosophy, More Red. Having a debugger in Red has been a request of many users for a long time, even since the Rebol era. We have tackled this feature from a larger perspective, considering general instrumentation of the interpreter note: not the compiler , extending it with an event system and user-provided event handlers, similar to how parse and lexer tracing operate today. This approach allows us to build more than just a debugger, though it was a lot of work to design and we expect it will be refined once people start using it in earnest.

It's a brave new world, with a lot of tooling possibilities. It's important to note that this is not magic. Because it operates as the interpreter evaluates values and expressions, including functions, it can't see into the future.

In order to get a complete trace, you have to evaluate everything. That means we'll see tools which silently collect data, like a profiler does, which can later be viewed and analyzed, perhaps up to the point where an error occurred. This is an important aspect, and plays once again into the power of Red as data. Your event handlers can easily collect data into any structure or model you like. And because event handlers can filter events, you can tailor them for specific needs.

It should even be possible to build interpreter level DTrace -like tools in the future. We also hope to build higher level observability and monitoring tools, based on eventing systems, in the future, but those are long term projects. For example, here's a simple logging function:. A simple profiler that we will improve over time especially on the accuracy aspects. A simple tracer.

The current evaluation steps are quite low-level, but hiiamboris has already built an extended version , operating at the expression level that will soon be integrated into the master branch. Full docs are here. Boy, I really thought this was was going to be easy, or at least not too hard. I couldn't have been more wrong. When I did my format experiments, I imagined at least some of the code would be useful, requiring polish and more work of course, providing a foundation to work from.

It turns out that I missed a key aspect, and my approach was just one of many possible. Then it sat idle for a while, and I asked Boris to take it over to get it into production. He identified the key missing piece, which would have limited its usefulness until we eventually had to address it. Better now than later. He also made a strong case for a different approach to the core masked-number and I told him to run with it. That led to a lot of design chat about one aspect, which is as yet undecided.

It's not a fight to the death, but there has definitely been some sparring. The missing piece I've alluded to is Localization L10N. As an American who has never had to develop software requiring Internationalization I18N , I've been blissfully ignorant of all the aspects that come into play when Globalization G11N becomes part of the process. The first two we inherited from Rebol's design, the latter was added when designed the currency!

Thinking of locale data in a system catalog of some kind is easy enough, but how to actually apply it and not apply it when necessary is a different story entirely. And I mean entirely. Format forced us to start down this path, and is a guinea pig feature that will guide future plans for all future L10N work. But keep my complexity rant in mind. While we want to make it as easy as possible for Reducers to write globally aware apps, if you don't need it, don't do it.

We don't yet know if we can make it so magical that you can write your app ignoring that for the most part, and then flip a switch, or simply include local data, and have it work.

Don't get your hopes up. There's a lot that can go wrong with that approach. This led to broad and deep dives into unicode. While they cover far more than we need, and is overly complex in many cases or just doesn't match our aesthetic sense for Red , the data they have there is enormously valuable, and we deeply appreciate it being available.

We just draw the line around a smaller scope than they do, and no committees are involved where people fight to get their own bits included. Well, we do that too, to some extent.

What Boris managed to do was identify the key elements needed for our work, and then wrote tools using Red of course to extract and reformat the data for use in Red. I can't stress how much work this was.

Truly a heroic and mostly thankless effort most people will never know about. In order to test masked number formatting, and give others an easy way to play, Boris created a Playground App and I can't tell you how important that was. You see, a particular piece of behavior came up while I was playing with it and got unexpected results. Unexpected to me, but Boris confirmed it was by design. I will just say here that it's about a significant digits mode, and let you play with the app from there.

Named formats will be available, but everything will likely boil down to wrappers around masks, which should cover almost any need. Next up is date formatting.

So you may have localized dates for some things, but if you use RFC dates or HTTP cookie dates, they must not be affected by any locale settings. Well, easy if the masks make sense. If you look at printf and some other mask syntax, it can be quite obscure. By trying to cram things into a limited syntax, people end up using whatever low ASCII letters might be left over for some elements.

We hope to avoid that. Our main choices are what Boris termed the stuttering format. Think in terms of " progressing in a hesitant or irregular way. I prefer to call this a symbolic format, where the letters map to date elements. This, of course, isn't perfect. Context is required.

We don't want to be case sensitive, or use other letters randomly to avoid that conflict.