Dec 2007
AltME? AltWHAT?
It's always a joy to see newcomers to the REBOL
language. You may be one of them and if so,
welcome! We don't serve any
beverages or ask you to sit in a comfy chair, but we
hope you'll come to enjoy the language as much as we
do. Unfortunately there are separated pockets of
users in different places, mainly shaped by the
communication form and ease of access. There isn't
really one universally accepted place to hang out.
But these places are where there is some action.
Read
More...
|
MacOSX Terminal Trouble
27-Dec-2007 15:09 Filed in: REBOL
Beginners | MacOSX
MacOSX Tiger doesn't have the best terminal
implementation: It consumes a lot of CPU just by
outputting text on screen on slower Macs. While it
has since been upgraded significantly for Leopard
(still CPU intensive, but not nearly as much), you
may still be using Tiger on a slower, older Mac.
My MacMini PPC G4 1.25 Ghz is therefore eating a considerable amount of CPU, about 10-20%, when REBOL is doing nothing but displaying the network wait indicator in the terminal window! This is for example the case, when you are using Rugby as a server, or when REBOL/Services is running.
Fortunately this can be turned off with:
And then REBOL goes really quiet and less CPU hungry.
This also eliminates network access output to the console, if you want to control better what is displayed when a network resource is accessed from REBOL.
Enjoy!
My MacMini PPC G4 1.25 Ghz is therefore eating a considerable amount of CPU, about 10-20%, when REBOL is doing nothing but displaying the network wait indicator in the terminal window! This is for example the case, when you are using Rugby as a server, or when REBOL/Services is running.
Fortunately this can be turned off with:
system/options/quiet: true
And then REBOL goes really quiet and less CPU hungry.
This also eliminates network access output to the console, if you want to control better what is displayed when a network resource is accessed from REBOL.
Enjoy!
R3 on Linux
19-Dec-2007 13:19 Filed in: REBOL 3
In the first porting effort, R3 is now running on
Syllable Server, which is based
on the Linux kernel. No graphics on the Linux
version yet. The same goes for the OSX version,
which is also not yet running graphics, but
things are moving quietly along. The process
will of course be documented for future porting
efforts to other OS'es.
LIST-VIEW for RebGUI and VID3?
Every now and then I get the question whether
LIST-VIEW will be available for RebGUI. As I'm a VID
person, there's little chance I'll ever get to do a
RebGUI version. I know only little about RebGUI and
so it would take even longer for me to figure out the
inner workings of RebGUI to do a port.
Therefore, if you are a RebGUI developer/user and really want LIST-VIEW there, I will support a port of it! In fact, I will go so far as to answering questions you may have about the inner workings of LIST-VIEW. Nice, eh?
Some requirements would be that the VID version and RebGUI version remain in sync. So if I make some changes for the VID version, they can get in the RebGUI version as well without too much fuss.
Perhaps this can be done by building LIST-VIEW for each GUI system with a simple build script, but we'll get to that.
LIST-VIEW is a large, monolithic beast, with currently over 100 kb of code, of which about 20% of it is not used at all. This is currently more than the entire of VID3's source code (excluding styles) and is of course unacceptable. Furthermore the graphics system in VID3 is quite different from that used in VID and the mechanisms of drawing the list can't be done without a rewrite.
Therefore there will not be a straight port of LIST-VIEW for VID3. Instead, the VID3 team will work on a very capable list view style that won't do everything that LIST-VIEW can, but instead have essential features, be faster, smaller and be easy to expand with more features. Furthermore some data processing features like filters and sorting are likely to be moved outside of the style. The final result will hopefully be better than the current LIST-VIEW.
Therefore, if you are a RebGUI developer/user and really want LIST-VIEW there, I will support a port of it! In fact, I will go so far as to answering questions you may have about the inner workings of LIST-VIEW. Nice, eh?
Some requirements would be that the VID version and RebGUI version remain in sync. So if I make some changes for the VID version, they can get in the RebGUI version as well without too much fuss.
Perhaps this can be done by building LIST-VIEW for each GUI system with a simple build script, but we'll get to that.
LIST-VIEW for VID3
LIST-VIEW is a large, monolithic beast, with currently over 100 kb of code, of which about 20% of it is not used at all. This is currently more than the entire of VID3's source code (excluding styles) and is of course unacceptable. Furthermore the graphics system in VID3 is quite different from that used in VID and the mechanisms of drawing the list can't be done without a rewrite.
Therefore there will not be a straight port of LIST-VIEW for VID3. Instead, the VID3 team will work on a very capable list view style that won't do everything that LIST-VIEW can, but instead have essential features, be faster, smaller and be easy to expand with more features. Furthermore some data processing features like filters and sorting are likely to be moved outside of the style. The final result will hopefully be better than the current LIST-VIEW.
System/Words
02-Dec-2007 08:14 Filed in: REBOL
Beginners
Ever needed to create a function that has a
refinement with the same name as an existing word or
function in REBOL?
All words are stored in SYSTEM/WORDS, so if you need to, you can access every function or data using that path:
So if you have a function with a refinement called FALSE, the normal FALSE word inside the function will be overridden with the state of the refinement. To access it again, use SYSTEM/WORDS/FALSE:
Outside the function, FALSE behaves like normal. Enjoy!
All words are stored in SYSTEM/WORDS, so if you need to, you can access every function or data using that path:
>> system/words/now
== 2-Dec-2007/8:12:36+1:00
So if you have a function with a refinement called FALSE, the normal FALSE word inside the function will be overridden with the state of the refinement. To access it again, use SYSTEM/WORDS/FALSE:
test: func [a b /false] [
a + b ; exciting, but irrelevant stuff happens here.
; this function should return false when /false is used
either false [system/words/false][true]
]
Outside the function, FALSE behaves like normal. Enjoy!