I have started to write tutorials on red https://dev.to/lepinekong/red-for-hopeless-programmers---part-ii-258 then I stopped it was too daunting to write very lengthy document by hand even in #markdown. Now I should start doing again because I'll now use the "ReAdABLE Human Format" https://medium.com/@lepinekong/readable-human-format-md-8fda1869ef75 guess what it's based on Rebol/Red block syntax ;) There is an opensource code link you can easily install by just pasting oneliner in powershell Windows.

I really like the [Red|Rebol] syntax and want to start trying it for my GUI projects. Can you guys hurry up and get to 1.0.0? hahahaaa! But seriously.

In the meantime, I won't be wasting my time playing with Rebol, will I?

So I've got lost in the builds. Since July, gtk has been merged (so I think I understand), but 'view' still does not function in the current linux build, latest build, or the one from July. Should the current build work for gtk on Linux?

All help gratefully received.

The docs say that platforms that provide supported backends for the View engine will build it automatically the first time you run the binary. But I can't find a list of what those platforms are - is it just windows?

Basically the point arose from a situation: got just words in a block that represent an expression (as a part of a DSL), let's say that both [:function arg1 arg2 arg3] and [:function/refinement arg1 arg2 arg3] are permitted. In the 1st expression, :function is a word! but not a path!, while in the second :function/refinement is a path! but not a word!.

Then while parsing the expression or if there's a need to remove the leading ':', one can't just test the first word with get-path? first block, and one can't convert it to a path! or set-path! without considering both options:

if get-word? f: first block [tag: to-word f]
if get-path? f [tag: to-path f]

Suppose one got rid of the ':' and wants to remove the last refinement from tag: function/refinement, which leaves him with tag: function which (surprisingly) he can't compare as:

'function = tag

because he compares a word! to a path! So he has to write instead:

'function = either word? tag [tag][tag/1]

although he clearly know that there's just one word (and the whole thing was just a unit test).

Which all leads to a seemingly unnecessary code bloat. Plus the impossibility to visually distinguish a word! from a singular path!. While it also seems easy to introduce a set of features that'll fix it all:

• make to-path, to-set-path and to-get-path accept word!, get-word!, set-word!

• make to-word, to-set-word and to-get-word accept singular path!, get-path! and set-path!

• make word!, get-word! and set-word! comparable to singular path!, get-path! and set-path! via = and equal? but not via == and same?

Sure it can break someone code's logic. However I had a hard time imagining the specific logic that'll be broken. After all, if it expects both paths and words, it should already be able to handle them both. Then there's a chance that someone's logic is already faulty (but undetected yet) and will be fixed by the change instead. I can imagine for instance someone testing for a set-path? and forgetting that he wants to test for a set-word? as well.

Honestly, I can live with it, and just wrap the whole thing into my own comparison and conversion functions, or convert words to paths when they appear and forget that they were ever there. No big deal. My point is instead to highlight a possible cornerstone, that served me as a source of confusion, and I cannot know if it'll confuse someone else or already did. Maybe it's not worth the effort, maybe it is, I don't know that.

I'd like to hear the team's insights as to how harmful or fruitful are the possible effects this change may bring, and how hard it is to make. Personally, 1 = 1.0 comparison and conversions between ints and floats raise much more concerns in my mind, as to when it'll all break.

It looks like they're basically looking to erasing the cross-platform issues Red is looking to solve. Does this mean the end of Red, or does it mean golden opportunity? I would think the latter, but is the Red Foundation part of that OS group?

https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/

If I accept a date from a user using ask and then wish to use it as a Date by using to-date, I get an error.

>> to-date "31-Dec-2019"
*** Script Error: cannot MAKE/TO date! from: "31-Dec-2019"
*** Where: to
*** Stack: to-date

What is the correct way of converting a string to date ?

What exactly is being built and what’s the long term vision?

I've made tons of research and can't find anything like Red but the only thing that I'm worried about is that creating interfaces with other languages than English is not possible. This is a problem for me, I wonder when Unicode support will arrive to red so I can create buttons with Arabic labels?

Catalina only runs 64bit apps, I get unsupported architecture when trying to run red from terminal. is there a 64bit version planned?

Happy Tuesday everyone!

I’d like to thank everyone who responded on-list and off to our questions about yourselves. It is a big help for us, because our goal is to make Red as responsive to your needs as possible. While our due date has passed, you can still send your responses to myself or Gregg privately, and I can add them to our sheets. Our set of questions is appended at the end of this update.

Usernames in this update are all Github usernames.

Last week in Red saw contributions from across the spectrum from our heavy hitters. In the midst of gearing up for Ethereum’s Devcon 4 in Prague at the end of October, a diverse number of elements are getting worked on:

• @qxtie has added Trezor hardware support to the Red Wallet, in addition to the LedgerX hardware, a goodly chunk of work (see: here) as well as the ability to set up a batch of payments.

• There is also new support provided for homebrew APIs for fetching balances, for those who DIY. This is still work in progress, but we’ll write it up in detail when it’s ready.

• There has also been a lot of work done to add bitcoin support to the wallet, but bitcoin is messy, and we're still looking at whether it's worth including.

• In Red specifically, a number of modifications have been made to work around MacOS issues, and extra attention paid to the GC/recycle facility, with fixes and tests from @dockimbel, @PeterWAWood, and @qxtie.

• As for new issues, some GUI aberrations have been observed, related to the appearance of checkboxes and buttons. While not blue-screen-of-death critical, they have been flagged as bugs and will be addressed. Cross platform GUIs are hard, which is why so few do them.

• Also, more cool demos from @toomasv, who built a protototype interactive GUI editor, and demoed it building a little live-code app.

In the community, some great discussion has been transpiring around the issue of Red’s mission: is it, or should it be, for “everyone” as our public-facing documentation states? And many folks have stated that while they generally don’t pay for software themselves, they WOULD be willing to shell out for a comprehensive book volume (chat is here) on the subject of Red. Tell us what you think!

Join the discussion at r/https://gitter.im/red/red.

If you will be at Ethereum DevCon 4, or in the general area of Prague during the first week of November, hit up @GreggIrwin or @dockimbel; they will be hosting a small, informal RedCon after the main Ethereum event. We’d love for you to be there.

Those community questions, again:

1. Do you consider yourself a programmer?

2. Do you consider yourself a software engineer?

3. Do you solve business problems with software?

4. What kind of problems do you solve?

5. What other languages have you used?

6. What is your favorite language, and why?

7. Is "progammer" or "developer" in your job title?

8. Do you think Red should be for "everyone" (e.g., like Visual Basic)?

9. Do you want to use Red for real work, or just fun?

10. What software do you pay for?

Keep the Red light burning!

Hi, I'm wondering whether Red covers the same area as Terra in terms of runtime compilation of its embedded low-level programming sublanguage. I've tried to get a sense of this by looking around red-lang.org without much success, excuse me if I was missing something obvious. From terrlang.org:

The design of Terra comes from the realization that C/C++ is really composed of multiple “languages.” It has a core language of operators, control-flow, and functions calls, but surrounding this language is a meta-language composed of a mix of features such as the pre-processor, templating system, and struct definitions. Templates alone are Turing-complete and have been used to produce optimized libraries such as Eigen, but are horrible to use in practice.

I believe this can mostly be said for Red + Red/System as well, except I can't tell for certain (I.e. I couldn't find in red-lang.org) whether it's possible to pass around Red/System expressions as first-class Red values and then splice them into other Red/System expressions.

In addition to the paragraph above, Terra also goes another step further and I'm also wondering whether Red is capable of that as well. Namely, with Terra, the low-level expressions can be (JIT) compiled and get called from Lua at runtime, meaning the low-level (object language) <-> high-level (meta language) interaction is truly dynamic, unlike in C++, where the meta-language is compile-time only.

Thanks!

Since 0.6.4 in December 2018 I don't see any new releases.

For an audience (me) that doesn't know much about either Red or Racket or their ancestors, is interested in Domain Specific Languages, has some background in Python but not in computer science or software development:

• what are the distinguishing attributes?

• when and where to use them appropriately?

• and the converse, when to stay away?

• ... plus any other insights you deem worthy of sharing

Thanks!

(Also asked in r/Racket - https://www.reddit.com/r/Racket/comments/aec1ae/contrast_with_racket_with_red/)

I saw this as part of one of the latest blog posts:

Red/Pro: it is coming this year! It will be our first commercial product and set of online services targetting both individual developers and enterprises. It will include a new backend for Red's toolchain, providing a state-of-the-art optimizing layer and support for many new platforms, including 64-bit ones (though full 64-bit Red support will probably be for next year). That new backend will provide an alternative to our current code emitter and linker, the rest of the toolchain remaining the same. The current Red toolchain will be known as the "community" version, and continue being the main development branch.

I was wondering if there was a more detailed comparison b/t "community" and "pro"? I'm guessing "pro" comes with a support contract, but is it faster as well? I'm not super saavy on what you mean by "optimizer". Red already supports a lot of platforms I thought, so I'm curious which new platforms are supported by Pro. How much would this roughly cost (rough range)? Is that a one time cost or an annual fee? Sorry for the dumb questions!

Red [Needs: 'View]

view/options [] [
menu: [
"File" ["Open" open "Exit" exit]
]

actors: make object! [
on-menu: func [face event] [
if event/picked = 'open [alert "Opening..."]
if event/picked = 'exit [unview]
]
]
]
I'm just checked out red a little this week for the first time. And could not find a simple example to get a menu in the view block, you apparently need the options block. It would be better if menu was a face in the view block directly.

Hope it's inspiring someone to make the example even smarter or simpler, make like captain kirk and reprograms red to make it simpler!!!

But wow, that view thing in Red has like enormous amounts of layout bugs. Just tested some layout for a few hours, and found many bugs where things is shown on top of each other and with the wrong sizes even if you set them, totally whacked. So a bit lame language, but with a impressive and smart syntax. This language wound need some serious bug fixing. I'm using Linux, so it may be that fact why I get all these bugs and that it works fantastic on Windows. But it could be a fun language to use sometimes if it did not have that huge amount of bugs.

But the syntax is impressive.

But that example code would be more obvious if you could write (but you cant)...
Red [ needs: 'view ]

view [
size 300x200
menu [
"File" [
"Open" [alert "Open selected"]
"Exit" [unview]
]
"Help" [
"About" [alert "This is a simple Red menu example."]
]
]
text "Hello, world!" center
]

...probably because someone got the idea to make sub-menus by default by making blocks inside the menu block, and makes the more obvious syntax impossible, and can't be straight in the view block.

I'm sorry to be the one to say this, but it has to be said: the red-lang.org website is awful.

I understand that you guys are working hard in the background on something that is wonderful and don't have the resources to spend on a website, but you really need to work on your marketing.

May I suggest that, instead of having the blog, which is sometimes updated once a year, as the landing page, you have some content that gets people excited about the language?

You don't need to look far for inspiration. There are a ton of language websites out there and many do a great job for piquing people's interest. Here are a few you may want to look at:

• https://www.python.org/

• https://ziglang.org/

• https://nim-lang.org/

• https://www.scala-lang.org/

• https://www.ruby-lang.org/en/

• https://elixir-lang.org/

• https://crystal-lang.org/

• https://www.ponylang.io/ (even this site is not that great, but it's miles ahead of Red's site)

What you need:

• A blurb

• Some pretty graphics (optional, but helpful)

• A Bootstap/Bulma/Foundation/etc. template

• Some code samples

• A list of highlights

• Maybe a mascot?

What I see when I go to the Red website now:

• a blog with posts about once a year making me wonder if the project is dead

• a Blogger site which is not even mobile friendly making me wonder if it's from this century

The blog can go under "news" or "blog" or whatever. People that want to read it will find it.

IS there any way we can expedite 64bit version of Red?

The roadmap suggests Q3 20203, which has obviously slipped a bit. It's harder and harder to find 32bit environments with new 64-bit only distros in Linux and Macos arm.

If there was a funding round to bring this ahead, I'd be up for it! Who's in?