Comments on: Bad face in screen pane - what a pain!
When you run Rebol/view 2.7 on some versions of Linux, you might hit this error message:
User error: Bad face in screen pane
That's got to be one of the most annoying error messages ever created. It happens when the graphics init sequence fails for any reason. Most of the time, what it really should be reporting is:
System error: Cannot open default X11 screen font (courier 11)
If your system doesn't have that font size installed, you'll run into the error, and there's not much you can do about it.
I like to use Rebol as a tool on a variety of Linux systems, so I made a small fix today to check for a range of courier font sizes from 10-15. I suppose if all those fail, it should just try to get the font info from any font that is installed on your system.
Now, I just need to figure out a way to publish the fix, sooner not later, and maybe there are a few other critical Rebol 2 bugs that need to be merged in there? Please let me know.
Hi Carl, nice to see that like us, you also still rely a lot on Rebol2.7 for daily work! ;-)
If you could either raise the internal Rebol stack size value, or provide a way at user-level to set it, that should help avoid some memory corruptions (NONE values appearing randomly in blocks) we see occuring in big codebases with very deeply nested calls.
Removing some nested call levels or reducing the functions frame size by diminishing local symbols number, is used as workaround for now, but it's insufficient. It doesn't seem to be GC-related, as running with recycle/off doesn't cure it. The errors Rebol return are random ("past the series end", "stack overflow", or errors related to those random NONE popping up in blocks). This is my biggest problem with 2.7 right now.
Another annoying, but easily avoidable issue in 188.8.131.52.1, is with CALL/OUTPUT when the output buffer size is not big enough (like: call/output cmd out: ""), it often enters an infinite loop. Pre-allocating the output buffers avoids the issue. It's a regression from 2.7.6 and it's a Windows-only issue AFAICT.
Hope you can do something about that.
Happy Holidays, nice to hear from you. I use REBOL 2 regularly, but not for heavy-duty stuff.
This probably is not a bug. I did just recently replaced my office GNU/Linux computer, and installed 64-bit opensuse. REBOL would not run. Messages suggested missing 32-bit libraries so I installed 32-bit opensuse and all was well. But I worry that as time passes and R3 languishes, we could get to a point where REBOL is effectively not available anymore.
So I am wondering if making a 64-bit version is just a matter of recompiling with appropriate switch settings, so that the REBOL web site could have available the appropriate versions of REBOL to run well into the future.
I also recall a bit of a struggle getting R2 running on a Windows 8 tablet that was just an experiment and I forget the final outcome. It was an office computer that broke shortly after purchase and is gone now; I never would buy one for myself.
In the category of fun information, we use REBOL on AIX at work. I was sad to see that disappear from the REBOL site. But we are decommissioning that computer soon so it's not an issue for me.
Welcome Back Carl! Hope you find more time soon to spend around here. |
The error should say
Creator error: Palm Face.
Wow - Hi, happy holidays Carl! If you'd like to keep up R2 and ensure it's future-proof for all the desktop, mobile, and web OSs in the foreseeable future, an Emscripten port with /View running on WebGL would be well worth the effort. If you could be convinced to produce such a port, there are a few in the community who are capable of helping technically, and a few who are willing to give money to pay for the work. I can't imagine anything that would make a better holiday for your ever lovin Rebol crowd :)|
Hello Doc, Steven, Arnold, and Nick. It's great to hear from you, and thanks for the quick replies - it really helps keep the energy going.
Here's the list I built from your comments:
Not too difficult:
Rebol stack size value (creates random NONE values in large blocks)
allocation of CALL/OUTPUT buffer (regression from 2.7.6 on Windows)
Could be more difficult:
64 bit Linux version (can I get someone to test it?)
Emscripten version (with WebGL for view)
I've heard that Rebol 3 is running with Encripten, was it a complicated project?
PS: Doc, do you have a short example script to show the NONE problem?|
Hi Carl, good to see you tending a maintenance release of Rebol2, as it is still in use (notably as the engine behind Red, which is the reason I have it installed).
But if things had played out differently, we could have ported Red to Rebol3. Most of the work for that has been done already (by me). So people could be writing Rebol-like Red code on their Raspberry pi, compiling it and producing cross platform executables from that pi to Windows, Mac, Linux, APK for Android... really spreading.
So...as we approach 12-Dec-2014, two years from the open sourcing, Rebol3 needs a maintainer. The way the chips have fallen is that Atronix has by default become the maintainers and distributors of the binaries, so those are the versions people are installing. But their agenda is different (like Saphirion's) and so stable core maintenance of Rebol3 pulling what is *agreed on* out of the repositories should be done...along with a migration of tickets out of CureCode.
I know I am a broken record on this issue but I hope that two years of guru meditation has led to realizing that the torch of maintenance and repository management for day-to-day affairs must be passed.
I would not waste time with an emscripten build of Rebol2, there are several details that have been tricky with Rebol3 and the better thing is to just empower the release of that code.
Hi Carl, we're always excited to hear about you.
I personally didn't hit a Must Fix, but I can speak about wishes:
- Unicode support
- Port to some other platforms like Android
RT could possibly deliver this kind of improvements thru a SDK to purchase in order to cover costs.|
Main R2 annoyances for me are:
call/wait needing an open console to work (partial workaround is to precede the call with prin " ^H" which at least preserves current cursor position).
call/output requiring "initialisation" via printing to console and a call/show.
>> unique/skip [1 "A" 1 "B"] 2
== [1 "A"]
For the call issues I should have added, on Windows.|
I work in a nominally Windows-only installation, but I am allowed to intercept a computer from the recycling stream and put Linux on it, for fun, experimenting, etc. So I could test a 64-bit REBOL, but the testing would be limited to a few distributions, and limited by 1) my understanding of REBOL, and 2) the lack of any sort of "test suite," although I would be happy to try to develop one, limited again by my rather shallow understanding of REBOL, and 3) the fact that I probably will be retired in about 18 months. But within those limits, I would be happy to help. Note again that I personally do not need a 64-bit version. I am just worried that hardware advances might pass REBOL by, leaving it a footnote in computer history when it should be leading the way. |
Hi Carl, nice hear word from you. Only two questions.
1) How much good where the grapes this year, it was a good vintage?
2) After 25 years of bloated business software development, I started learning Rebol/view last year, and now I don't want to use anymore other languages, I found in Rebol what I wanted for years, the "light" that illuminates the darkness of other languages. Now I am so worry, because R3 not seems to be available, and we need updated versions of R2 and, if possible, for mobile devices. I personally would like to develop commercial software in R2 or R3 view, but can't find the right path. If your have some time to steal from wine, help us please.
Josephd - well, it is a tricky situation. We all wanted more advanced, more powerfull version of R2 and hence R3 project emerged. Async networking, extensions, rewritten and faster gfx engine, etc. OTOH some parts of R3 were not on par with R2.
But - with the work of Saphirion and Atronix, R3 now has general library interface, much more powerfull than R2, CALL, and some other fixes and improvements. And R3 GUI was ported to Linux too.
Of course, there is only a basic work done in terms of Android, but R3 is open source after all.
While not trying to steal the thunder from both the R2 and R3, there is also a young project called Red ... which is a bit different aproach, but still Rebol like language and definitely worth to follow.
Rebol and Red community lives in terms of Altme REBOL4 world, Stack Overflow 2 channels (red-development-team, rebol-and-red) and also via the Google groups or Rebolforum ...
To remain in the scope of the initial offer, I would vote for DocKimbel's request.|
I would vote twice for DocKimbel & Steven requests. But what I really would like is persistence, my software need to manage database tables with large amount of fields. I tryed first with odbc and then Nenad's library for mysql, but don't feel it enough.
I think increasing the maximum word count limit to something over 100000 would be appreciated by a few of us.
This limit has cropped up as a problem a few times through the years across quite a few projects, AFAICT it should be very easy to fix.
I think you never got around to including the Fix Cyphre sent you concerning the transparency of any draw element which follows space characters. If spaces are at the end of the text string, it affects any following drawn element. note that this even affects the text itself, since each first letter after spaces is more "bold".
Carl, I cannot make a short code example to show the issue, so I sent you an email with a reduced Red codebase that exhibits the problem.
Anyway, increasing the stack size should be a good-enough workaround, I don't ask for more.
I would also second Max's proposition for having higher limit for symbols table size, we are also reaching this limit.
In a nutshell, I would like to see both stack size and word count limit be user-settable, preferably from command-line (though other options are fine too).
For the CALL/OUTPUT issue, this is how to reproduce it using Rebol 184.108.40.206.1:
call/output "dir" s: ""
Sorry, It was me, just messed up the name field in the above comment.|
here is a simple example of the text rendering corrupting the color transparency... in the following, all circles and letter "A" should be drawn with the same pen and fill.
note that the key here is the use of the Vectorial mode, which is really necessary for most real-world uses of text in draw blocks (required to follow transforms)
just run this in the R2 console:
myfont: make face/font [size: 30]
view layout compose/deep [
box 200x200 effect [
circle 100x40 20
text 70x80 "A A A " vectorial
circle 100x160 20
just remove the vectorial text rendering mode and you will see how it should render.
notice how each space darkens the next thing drawn such that the second and third are progressively darker.
Carl; I'll gladly test 64bit GNU/Linux cuts of 2.7. Gladly. bwtiffin at the gmail|
Ok Doc, thanks for the details. I'll bump up the stack size and word table, and give a command line option for that. And that call line will help me track down that problem, so many more thanks on that.
Hi Maxim my friend, can you find out if Cyphre sent me a fix for that? Perhaps he did, and if so, it's probably already merged. And... I've not forgotten about native nodes, of your favorit variety. They remain on the top of my mind. (Also, I've been sending you direct emails, but no reply!?)
Ashley: I see your suggestion also, and will investigate that. (PS, are you the Ashley of RebGUI fame??)
Josephd: glad to hear your Rebol experience was good! I agree with your statements. I'm also very tired of the bloat. And, for the grapes this year, due to California drought, I had to pick them early, but now in the French oak barrel, it tastes like a nice French vintage! What do you think? Is that a good thing? (Probably depends on your home country.)
GregP: thank you for the input, but I'll need to say Rebol 2 will never support Unicode like Rebol 3. That was a big and complicated project... especially to make it so compact. The future is in Rebol 3... so let's just make it work as well as Rebol 2 in areas we need it.
Fork: thanks much for your help and ideas. I think you're one of my inspirations... because I know the level of your vision, and it is grand.
Also, just to say Hi to Pekr, and also Brian T, I will keep you in mind for 64 bit, when it builds/runs successfully. (It did in 2002... but no one wanted 64 bit back then.)
Also good to see Google still keeping up with Rebol. From here when I Google Bad face in screen pane this blog comes up #2. A good thing. But then, maybe Google knows my preference for Rebol, so it's not an accurate result. I wonder what other Rebolers see from Google on that?
I'd be very happy if R2 runs on 64 bit. And willing to test of course! I can test core, view and command.
Hope you are doing well - I miss your deep insights.
If it was a dry summer I think your grapes would have an higher alcoholic degree, at the cost of less production. I think it would be a good wine, taste it for me!
Here in Mallorca was also a dry season, about four months without rain, I have read that harvest had so difficult selection of grapes, but the quality is qualifyed "extra". So would have less, but better bottles!
I also wanted to test Rebol 2.7 64 bit on debian .
Open block ssl port . Not work in non-blocking mode
port: make port! tcp://220.127.116.11:80
probe dt [attempt [open/no-wait/binary port]] ;0:00:00.000036
port: make port! ssl://18.104.22.168:80
probe dt [attempt [open/no-wait/binary port]] ;0:00:03
For me, this blog came up #3 on Google, but #1 on DuckDuckGo. (My computer is also tainted with many Rebol searches.)
For requests, I'd like to see the ability of Rebol to direct its output to stdout and stderr for use in applications that are calling Rebol scripts.
I'm calling a R2 View script from a Windows program. There doesn't seem to be any way to return output, via stdout or stderr, directly to the calling program. R2 Core can direct to stdout with a bit of effort, but R2 View can't.
In answer to your question, yes. :)
It is always great to hear from you Carl! Please appear more frequently on this blog and share your ideas.
I use R2 daily and used it for some mid-size projects mostly via Cheyenne and some R2/View scripts.
My biggest issue was always 22.214.171.124.1's CALL problem that Doc is already stated. Most of the time R2 hangs if there is no open console and the string buffer is not initialized before using /output.
Second, encapped executables cannot take any argument if there is "C" character, because in that case it switches to CGI mode.
For example: myscript.exe --config-file "my.cfg" ; doesn't work because of "C" in config-file.
I'm not sure if this happens on all versions. It appeared on Windows for R2/View for me.
Third; there is no way to set a DB column value to NULL in RT drivers.
db: first p: open odbc://test
val: "test" ;this is ok
val: none ;error
val: "NULL" ;inserts a string not a real NULL
insert db ["insert into table (a) values (?)" val]
It would be really nice if NONE values treated as NULL.
Last, when I search for "Bad face in screen pane" the first page is full of Rebol related sites (rebolforum, rebol.org, rebol.com)
Andreas has done the most work with Emscripten R3 /Core porting. I sent him a note asking him to chime in here. Cyphre and Shixin have both expressed interest in porting View to WebGL.
I can raise at least a few thousand dollars to help make an R2 porting effort worth while. If you're interested and potentially available, but need more money to consider it, please let me know.
An Emscripten/WebGL port of R2 would allow existing R2 scripts, GUI and all, to run unaltered, directly in any mainstream browser, on any operating system, including iPhone and iPad, Android tablets and phones, Windows phones, WebOS, Gaming Consoles, and all sorts of other new devices yet to come - anything that has a modern browser. And of course, it would allow Rebol scripts, GUI and graphic layouts to run as part (or all) of "web pages" intended for browsing. What a wonderful way to build the world wide web. Such a release would also demonstrate Rebol's portable design, and make a genuine benefit of it's small file size.
To me this is a thoroughly exciting prospect.
Carl, if you have the interest and availability, I would do anything necessary to make that port a reality.
Nick has proposed that supporters of an R2 Emscripten/WebGL port make their views known here. I support this idea and any idea that will keep Rebol going.
If funds are helpful, I can make a small contribution. Of course, small contributions can add up so I hope others will feel the same way.
Rebol remains the most exciting and intriguing language ever devised.
Also, I would like to get View running on my android tablet.
As for putting my money where my mouth is, I am approaching the Time Of Fixed Income, so maybe I could sneak a hundred dollars out of my personal "black budget," but that would be about it.
I Agree with HostileFork about keeping REBOL repository up-to-date. Why not make a fork of the repository and manage it? Call it FreeRebol. New source code (pull requests) should be submitted to that FreeRebol. Just don't keep waiting on Mr. Sassenrath.
And I don't blame anything on Mr. Sassenrath. On the contrary, he kindly released the code of R3 to the public. Maybe he could also have the courtesy to mention the Community Mantained FreeRebol on HIS rebol.com page.
But IMHO, 1) Mr. Sassenrath does not seems to want to actively manage the github:rebol repository; 2) Community should accept the gift of R3 source code and continue from there.
Hi, Carl. Nice to hear from you. I am attracted by Rebol's elegancy and expressiveness at first sight, and really admire your talent in designing such a wonderful language. But when I decide to learn more, I am frustrated by the documents on Rebol.com (especially the documents for R3): Many of them seem to be unfinished, with confusing descriptions and few examples. I think a beautiful language with a clear and detailed manual will attract many new users, who are experts in other fields but are newbies in computer science.|
Re an Emscripten port: assuming that R2's approach to portability is similar to R3's, a /Core port should be relatively straightforward, comparable in effort to porting to a new platform with a different compiler (i.e. figuring out the few nags that are due to compiler differences) and a different "console" (i.e. writing a slighty different REPL frontend).
After that, we can proceed to a /View port. That is most likely a _significantly_ more involved effort. Current estimates for R3 vary between 2 to 4 months to first prototypes of the compositor, draw dialect, and event handling. These estimates may differ widely for R2, depending on R2's internal architecture. The previous effort of porting R2's to AGG could serve as one reference point -- the /View port to Emscripten is probably 4-5 times the scope of that.
DocKimbel provided a snapshot of Red that reliably hit the "stack bug" (thanks!) and I found some time over the weekend to debug it. Took a while - a fairly nasty bug that would affect any deeply nested Rebol program.
Bug: Recycle has a few "side blocks" it uses to keep unreferenced values alive. Those blocks are allowed to auto-expand. Unfortunately, there must be some C pointers into it, so the expansion creates dangling REBVAL references. Of course, you don't know they're dangling until much later. I guess block size = 64 isn't big enough to run all possible Rebol programs?
The fix is just to init it larger. I'll do the same for some of the other related GC bookkeeping blocks, and also the word table. Later, it may be worthwhile adding a command line arg to specify the size.
And just wanted to mention, it's good to hear from so many of you. I'll come back later and reply to some of the other questions and suggestions.
Good to know the bug could be handled. Almost cannot wait for the new executables appearing on the site.
Perhaps also an AltMe version for Android or iOS?|
>> unique/skip [1 "A" 1 "B"] 2
== [1 "A"]
This defect has bummed me out man times.
Carl, all the best to you and the family for 2015, and to all REBOLers world wide.|
Poke check... Emscripten/WebGL, is there any chance you may consider it? |
On AltME Marco reminded me of a little issue that I had to deal with many times, requiring to restart Rebol to be sure:
"Is there a way to reset the internal state(s) of R2 (clearing all new words and objects) so that it will be in the same state as if it were just started?"
A SYSTEM-RESET command. I know it could be hard because theoretically you can redefine pretty much everything. |
Happy new year to Carl and to all of you, Rebol Community! ;-)
I've been away for a while: I'm very glad to see some movement has been happening around that good old rustproof Rebol2! I use it daily, a lot in combination with Dock's PostgreSQL driver.
I had encountered this error:
"** User Error: Bad face in screen pane!"
once, but that was my stupid and entire fault: I was accidentally trying to run a rebol script which had a few GUI features, using a rebol/core interpreter... :-s
Another issue that I have sometimes faced with Rebol 2 has also probably something to do with font matters on GNU/Linux. Let me try to find out some code which was not running as expected; if I remember correctly, it was about some texts written in DRAW blocks.
Nice to see some work on REBOL 2.x
I still use it often.
Speaking of fonts in Linux.... Draw can be used in some faces in Linux. But what about input faces, like say, the field? In my Linux distribution, it seems that not even the font size of field text can be changed, let alone the font.
It doesn't seem to conform to the write once use anywhere idea.
I've missed something have I? Is there a method to change the faces of all fonts in Linux?
It's wonderful to hear from you again, and yes, we still use REBOL all the time, and it would be wonderful with some fixes to REBOL 2.
I'm getting the sense that REBOL 3 and Red are both getting ready take off, and move REBOL to greater heights in the next decade. There's so much potential, we are not yet taking advantage of.
Hi Carl, hope this reply isn't too late...
I need you to relax the requirement of the Needs header so it doesn't trigger an error for anything other than the version tuple. This is needed to be able to make a Rebol 3 style module system for Rebol 2. It's OK to have it be the same version restriction when providing a tuple value, but for other values it shouldn't be restricted - let the runtime code do whatever it wants with that header.
I don't mean this as a criticism, but you originally were going to do this for me in the 2.7.6 release and it must have fallen through the cracks. The R2/Forward project has been blocked since 2009 waiting for this.
Aside from that, pretty much +1 to some of the suggestions above. Aside from R2/Forward, I mostly just use Rebol 2 for compiling Red - I use Rebol 3 for the rest. Since I don't really work on Windows now, I no longer need it to access old proprietary datatypes in SQL Server (which was my only use for it for 2 years). I'm still interested in Rebol 3 first, Red second, R2/Forward third, and Rebol 2 without R2/Forward not at all. I'm not interested in any changes to Rebol 2 that don't promote people switching to Rebol 3, but that's just me.
Nice to hear from you though :)
As I sit here at work, I just thought that maybe I should add a comment, somewhat related to the above comment. This probably is a "but that's just me" comment, but my interest in R3 is "not so much at this time" and my interest in R2 is "very interested." That is because I feel like R3 still is a bit of a moving target while R2 is more stable. I like stable. I use COBOL.
At this time I am writing about 200 small and very similar REBOL programs to check some fields in an SQL Server database for a big conversion project. I am using REBOL because this project is a one-time project that must be done now, and I don't have time to purchase a big Microsoft development system (Visual Studio, C#, Visual Basic, etc.) and go through the learning process to get to the point of being able to use it. I am not doing anything fancy, just basic "data processing," and now that I am getting handier with REBOL I am finding it a perfect tool; fast, easy, and free (as in beer). I would hate to see it go away.
Interestingly off-topic, I work for a place that has as a motto "Quality service at an affordable price," but we would be quite willing to spend what it takes to get everyone set up with a Microsoft development environment, and would turn away from something like REBOL that is free (as in beer) but unfamiliar.
regarding view bug, I think Cyphre had already sent a fix, but it never got merge/released.
so, when can we expect a release? I have some advanced apps I'd really like to re-encap to fix this/these bugs (yes the linux issue is annoying for me too).
woudn't mind paying for an update... I mean its not like the SDK cost a fortune for the all the years I've been using it.
It would also be nice to have a new OSX version which has a version of draw which works properly (fonts, mainly IIRC).
I second the idea of paying for an update. If it's not a terribly large price (like the historical price of $250), I would even pay in advance. If it's a lot, then I would have to get the office to pay and the "advance" concept wouldn't fly. We have new management and they are not as stingy as the previous regime. |
There has also been some talk on AltME to have #(..) constructions to lead to a error. Just as behaviour in R3 and other related languages. In this way freeing up this syntax to be used somehow. (The fine details are beyond my knowledge/time limits). |
Big question now is when will you find the time to implement these changes and provide them to the world?
Time is passing, I think Carl is working quietly, and will surprise us with a new shining R3 full of updated things. I hope it so much...|
Not to lose sight of the main point of this posting, I would re-state the need for 64-bit R2, if it's just a matter of recompiling with appropriate switches. I was at a SUSE Linux (not Opensuse) presentation yesterday and they said that their current version is 64-bit only. They did say that 32-bit applications could be run in some emulation mode, but I tried that on my office Opensuse computer without success. Of course just because I can't do it doesn't mean it can't be done. |
Another issue I like to see being fixed is that like on Windows, the Rebol console would default to the current folder, not the root.|
Most of the people who are in the flower business and the delivery of flowers at leat would say it and admit that this is a bit different than it looks like. And to be honest no one wants to say how things will look like in the future in this niche at least. Also more and more people would say that this is az true as it gets. So no more for me and for them.This is what separates them from the others. And Even KSD Games and https://www.console-world.eu gaming have talked about it in the recent months|
Many thanks for this wonderful data here, definitely!
I want to inform you that whenever http://www.buytramadol.co/ and I speak together they inform me whenever your dose is altered or that your breathing cans slow or cease when you begin using this medication. Never consider tramadol in greater portions, or for longer than approved. Don't crush, bust, or open a long-discharge product. Digest it full to avoid experience of a potentially lethal dose.
Seizures (convulsions) have happened in a few people taking this medication. Tramadol could be prone to cause a seizure if you should be acquiring specific medicines such as muscle relaxers antidepressants , narcotic, or medicine for sickness and vomiting, or for those who have a history of head injury or seizures, a metabolic disorder|
Fonts work in my Linux distribution (Tahrpup 6.0), for fields and text, etc. same as they do in Windows. Just write say, field font-size 22 font-name "Ubuntu". But, first, be sure that the named font, "Ubuntu" in this case, is actually installed to the Linux Operating System using the Linux distribution's font manager.
I guess the problem appears because it is assumed that the Helevtica font
The problem of not being able to resize fonts might be caused by the default font named in REBOL'S VID for say FIELD, is "helvetica". If the Helvetica font is not installed to the Linux Operating System, then there will be font issues in REBOL.
The fixed-fonts from www.1001freefonts.com I installed to Tahrpup 6 worked with REBOL. Another font source might be http://www.unifont.org/fontguide
The Linux font problems might arise because Rebol Technologies might be assuming that Helevtica is included in all operating systems - which it is not. Maybe including a font specified in the VID in the REBOL View release might avoid the confusion. Or at least a note in the readme file.
There is a readme file with the release?
Or a friendly get started on the right foot tutorial?
+1 for the 64bit support.
I've stopped using Rebol for sysadmin work a few years ago because people started to migrate to 64bit and it went against the principles to install 100MB ia32-libs just to be able to run a 0.005MB script with the 0.5MB Rebol/Core :)
I guess fixing fonts on Mac in Rebol/View is hopeless, but I'm still amazed it still runs on the latest OS version.
Hi, it would be nice to have a 64bit windows rebol/view
I'm still using rebol for datas analysis, it allows to get result with a few code lines eb=ven if sometimes it's a bit long time to get the analysis done. Long time ago i used rebcodes, it was nice a more efficient but it disappeared. So if it is not to much work, it would be nice to put it back
Another annoying detail: when Rebol/core or Rebol/view starts in a terminal, it erases the screen. Some information from the terminal which was written before is lost. This is a little frustrating sometimes. I guess it should be quite easy to fix.|
Post a Comment:
You can post a comment here. Keep it on-topic.