The directory is the root one but the script is in the subdirectory.
Imagine you have
#include or do %file.red in your script and the directory wouldn't be changed somehow. Then your script wouldn't work.
Yes, I am not advocating the working of "active dir". The
Current-dir concept you find in shells is usually a static value, and you change it manually with a change-dir like command. If you run a program in a subdirectory from a shell, the current shell dir does not change. Usually, other than the current-dir you have a program-dir which is the directory where the program resides. In Red the active dir is dynamic and script dependent. So, please think like a first time user of Red, what will he probably think trying to explain the help of what-dir (when a change-dir exists too) without any further explanation?
Maybe a little change would help here: "active dir" -> "current script dir" ? "current running script dir"?
make object! [
title: none
header: none
parent: none
path: none
args: ""
]system/script (Printed out from a running script)
Hi, everyone. I'm here to express thanks to helpin.red . It's a really helpful site to guide me around the Red world as a new comer . Besides, I'm totally impressed by the 1MB size Red executable. Could someone tell me about how this was done? Or is there any doc i can find about that?
@ccmywish , I'm also new and also going through that same path. here's what started my journey: https://news.ycombinator.com/item?id=24080254 . I'm happy to share any findings, but really , it seems the truth is out there in
compiler.r and system/*.
Although I don't know how big the executable would be uncompressed.
@rebolek I wonder how big would an electron app be if compressed with same methods as Red executable?
Anyway, regarding docs: Has there been any discussion about adding a "SEE ALSO:" section to built-in function docstrings? I think it would ease language exploration by learners. And sometimes you just forget the right word. For example
case could have "SEE ALSO: switch, either". @meijeru 's specs functions categories or red-by-example's categories could be helpful with that.
This is something that is available in R2 function docs (for example see Related: in http://www.rebol.com/docs/words/wunion.html ). It would be nice to have it built-in. I believe that the whole
func dialect needs updating. Things like url! with link to documentation, default values and so on.
@kidd sorry for the delay in responding. The mailing list exists, at least I can still see it, though it's mostly dead. Only a few old Rebolers seem to use it. Editing it out of the readme makes sense. @x8x can you also remove it from https://www.red-lang.org/ ? If somebody disagrees, speak up. Since it isn't used, we shouldn't promote it as a main contact point.
1 reply
@loziniak
see-also: functionality will be done outside of doc strings, simply because we have to draw the line somewhere on what goes into code versus what is best handled as metadata and tooling. In this case, documentation and learning tools can leverage other sources, rather than using reflection. I worked on some ideas for the data organization in this area a while back, and will try to find my notes.
I agree one should not overburden docstrings. Nevertheless, all built-in functions should have not only a docstring for themselves, but preferably also for their refinements, or where applicable, for the arguments belonging to those refinements. This is NOT the case for the following:
ask /hide
read /info
register-scheme /native
stop-reactor /deep
write /info
Where has the json stuff moved? In june blog post, there is the following link to json, which does not seem to be valid anymore? https://github.com/red/red/blob/master/environment/codecs/json.red
Case sensitivity? 😲
Well, it either did not work with the June blog article right from the start, or someone renamed the file later (more probable).