Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Is Rebol code smaler?

 [1/13] from: rebolinth:nodep:dds:nl at: 17-Nov-2002 22:51


Hiya All, Im wondering, when i roam through the codes from ie. the "Library" at reboltech or looking into example of rebol It amazes me again and again that I still see traces of "C". And im pointing out here the fact of "effective programming. I read once in the list (or a book) that someone said "First think befor you program when using rebol" and thats a fact. Still i see sometimes source codes popping by that are the size of an equal C program, I cant emagine that should be the cause ;-) Even when i look at examples from the RT themself i see purly C routines copied to Rebol (Take i.e. list-dir) Its an awful code, not even rebol-like! So why is it? how come so? Rebol is language to me that should make code smaler!!! even 2x 3x smaler that original other languaes, but its not always!! I just build some routines in "TCL" that code is smaller then the Rebol-version (i've not finisched yet, still!!! im thinking twise befor coding a routine in Rebol, because I know it can be done effective and compact!!) The days of one-lines is long gone :-) But i take it with me when im programming! Make it small fast and compact (assembly freakoff:-) Anyway.. The question remains: Why isnt rebol code smaler? Anyone? (R)egards, Norman

 [2/13] from: tim:johnsons-web at: 17-Nov-2002 13:32


* Rebolinth <[Rebolinth--nodep--dds--nl]> [021117 13:11]:
> Hiya All, > Im wondering, when i roam through the codes from ie. the "Library"
<<quoted lines omitted: 7>>
> Even when i look at examples from the RT themself i see purly C routines > copied to Rebol (Take i.e. list-dir) Its an awful code, not even rebol-like!
Hmmm! Taking list-dir as an example: (I've programmed in "C" for 12 years) It would take some overhead (including memory allocation) just to get a list of files in a directory into a a char** array. Although traversing the array could be just done using prefixed ++. One could write a "C" that would look like rebol and be as compact (but Hey isn't the rebol interpret written in Ansi C?), but a lot of overhead would be applied to libraries somewhere. But come to think of it, what's with s: make string! 0 ; insted of s: copy "" ;?????
> So why is it? how come so? Rebol is language to me that should make code > smaler!!! even 2x 3x smaler that original other languaes, but its not always!!
I've moved anything to I do that is not high-performance targeted to rebol from "C". Believe me, I've saved a lot of code, not to mention ever larger amounts of time in code maintenance and upload time and resources.
> I just build some routines in "TCL" that code is smaller then the Rebol-version > (i've not finisched yet, still!!! im thinking twise befor coding a routine in > Rebol, because I know it can be done effective and compact!!)
Also, in "C", you cannot "roll your own control structures", although the preprocessor can enable you to sort of pretend to it a bit. But, I believe that you can do so also in TCL, because control structures and just functions just as is so in REBOL.
> The days of one-lines is long gone :-) But i take it with me when im > programming! Make it small fast and compact (assembly freakoff:-)
There should be a rebol compiler or a system to translate rebol code into an Ansi C "dialect", which could then be compiled.
> Anyway.. The question remains: Why isnt rebol code smaler? > > Anyone?
Grab the fire extinguisher! Seriously, good to hear your input! :-) -tim- -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [3/13] from: gchiu:compkarori at: 18-Nov-2002 11:54


On Sun, 17 Nov 2002 22:51:11 +0100 Rebolinth <[Rebolinth--nodep--dds--nl]> wrote:
>Anyway.. The question remains: Why isnt rebol code >smaler? >
Hi Norman, Unrelated to this, I wonder why rebol memory footprints are so large. With an encapped view application, they are about 12mb and over though the exe file is only 5-600kbs. On the Amiga, there used to be a run time re-enterant library that cut down the size of the Amiga executables. I wonder if something similar can be done for Encap. -- Graham Chiu

 [4/13] from: greggirwin:mindspring at: 17-Nov-2002 22:01


Hi Norman, R> Im wondering, when i roam through the codes from ie. the "Library" R> at reboltech or looking into example of rebol It amazes me again R> and again that I still see traces of "C". REBOL is written by people in C. It makes some sense that, even though they are the ones who really know how to apply REBOL well, sometimes our mind goes down a certain path whether we want it to or not. :) R> Even when i look at examples from the RT themself i see purly C routines R> copied to Rebol (Take i.e. list-dir) Its an awful code, not even rebol-like! But it is easily understood. Mind you, I'm not saying that RT wrote it that way to serve as an example but would the following really be any better? (not that it's a great example) ; Larry Palmiter map: func [fn blk args /local result][ result: copy [] repeat el blk [append/only result fn :el args] return result ] ; Gabriele Santilli mk-string: func [len [integer!] ch [char! string!]][ head insert/dup make string! len ch len ] ; RT - modified by Gregg Irwin list-dir: func [ {Prints a multi-column sorted listing of a directory.} [catch] dir [any-type!] "Directory to list or nothing" /local max cols ][ dir: sort throw-on-error [either value? 'dir [read dir][read %.]] max: add 2 first maximum-of map :length? dir none forskip dir cols: add 1 to integer! (60 / max) [ repeat i cols [prin join dir/:i mk-string max - length? dir/:i " "] print "" ] print join length? head dir " files" ] Nobody's perfect, and here on the list you sometimes see genuine coding errors in mezzanines come to light. I'm guessing that LIST-DIR has been around a long time and, since it's working, nobody has messed with it. That said, you could cook up your own version and submit it to them for use in a future release. I imagine a lot of things are that way. I know I've written plenty of code with a deadline looming, and where the most important thing is to deliver something that works. People don't care (in general) how elegant or compact your code is. R> Anyway.. The question remains: Why isnt rebol code smaler? Sometimes it is. Look at how much power is packed into the LAYOUT function! Obviously not everything is so dense in the REBOL world, but does it need to be? Hopefully, when we find things - as you did with LIST-DIR - that could be improved and made more REBOLish, we'll make note of them and improve them. Even though REBOL isn't open source, RT seems very open to including mezzanine fixes and functions from the community. -- Gregg

 [5/13] from: greggirwin:mindspring at: 17-Nov-2002 22:13


Hi Graham, GC> Unrelated to this, I wonder why rebol memory footprints GC> are so large. With an encapped view application, they are GC> about 12mb and over though the exe file is only 5-600kbs. I think (assuming you're running under Windows) that it's due to their implementation of windowing stuff (i.e. 24-bit compositing for every face), not the core interpreter and data. Maybe /Face will give us a really lightweight GUI, though I'm not holding my breath. I guess I haven't been too concerned, even though I would love for it to be lower myself; other things are more important to me. -- Gregg

 [6/13] from: petr::krenzelok::trz::cz at: 18-Nov-2002 7:44


Graham Chiu wrote:
> On Sun, 17 Nov 2002 22:51:11 +0100 > Rebolinth <[Rebolinth--nodep--dds--nl]> wrote:
<<quoted lines omitted: 5>>
> With an encapped view application, they are about 12mb and over though > the exe file is only 5-600kbs.
12MB? Eh, so we are not surely ready to run flawlesly on PDAs yet? Do you do any GUI intensive stuff in your app? -pekr-

 [7/13] from: gchiu:compkarori at: 18-Nov-2002 22:22


----- Original Message ----- From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]> To: <[rebol-list--rebol--com]>
> 12MB? Eh, so we are not surely ready to run flawlesly on PDAs yet? Do
That's not too bad as my PDA has 64Mb of ram to start with :) But I have no idea how Pocket PC 2002 copes with virtual memory, or even if it has such a beast.
> you do any GUI intensive stuff in your app?
No, just the pop ups. -- Graham Chiu

 [8/13] from: ammon:rcslv at: 18-Nov-2002 9:35


HI,
<snip> > > > > The days of one-lines is long gone :-) But i take it with me when im > > programming! Make it small fast and compact (assembly freakoff:-) > > There should be a rebol compiler or a system to translate rebol > code into an Ansi C "dialect", which could then be compiled.
</snip> This has come up several times and the reason there is no compiler is because of the dynamic nature of the language. RT is working on a compile function, but it will only really work with heavy number crunching. Anything else done in the language is too dynamic to be compiled. ;-) Enjoy!! Ammon

 [9/13] from: rebolinth:nodep:dds:nl at: 18-Nov-2002 20:40


HiYa Ammon, -> This has come up several times and the reason there is no compiler is -> because of the dynamic nature of the language. RT is working on a compile -> function, but it will only really work with heavy number crunching. -> Anything else done in the language is too dynamic to be compiled. ;-) Compile function??? I think its even easier to make your own compiler :-) combining the executable and script .r into one binary can be done !!!! (okay okay ..its not a compile..) The principle is easy. Have a look at FreeWrap from Tcl, they use the Virtual Zip (yes its tcl) but it compresses the code and script into 1 file (zip finaly) ( with a little excryption ) and Voila you have a standalown package that runs directly into memory :-) I was just investigating if a rewrite for Rebol is an option :-) (R)egards, Norman.

 [10/13] from: rebolinth:nodep:dds:nl at: 18-Nov-2002 20:27


Hello Tim, I agree with you on the list-dir routine :-) Its a hell of a work to get it nicely working in C ;-) But I have seen one-liners in AWK/SED that show it very nice (and sometimes tremendously cryptic too :-).. Thats what I also ment, with the list-dir example, its more the look of the code that intrests me because a lot of people still have the touch of the C / PASCAL ..etc.. like programming. This is because we still have the LOOPS inside the codes ..like for forall foreach while etc... those make the code stretch... Also variables like s: 1 or x: 1000 We cant do without them. Looking at rebol code its a lust for the eye sometimes, it so damm puzzling that my mind hooks on it direclty to see who it works, and I dont have that with Tcl C Pascal..Yes i have it with assembly too ;-) The first time i read a rebol code I was thinking => How much more simple can it become :-) Because rebol code is compact, which is not always the case finaly..intresting this is, because how compact can it become??? During some programming in Rebol I even noticed that My OWN code became so inactive from the variables in the code that I finaly only needed 2 or 3 variables to get it running..Amazing it is..Its even more amazing that when i read my code after 1 month again I didnt even understand anymore how I did that..hahaha that cryptic..hahaha.. (R)egards, Norman..

 [11/13] from: rebolinth:nodep:dds:nl at: 18-Nov-2002 20:35


Hi Graham, -> Unrelated to this, I wonder why rebol memory footprints -> are so large. With an encapped view application, they are -> about 12mb and over though the exe file is only 5-600kbs. -> -> On the Amiga, there used to be a run time re-enterant -> library that cut down the size of the Amiga executables. -> I wonder if something similar can be done for Encap. Thats not my problem :-) thats all expanded code after decompress also a lot of buffers are created, My tcl code sometimes eates over 4 MB internal memory,it all depends on internal buffer handling. Heeee even more funnier :-) Did you ever debugged the core binary? The core binary (perhpas also the other binarys use the internal rebol compress!!! have a look in the binary files you will find several finger-print of "compressed" rebol code with the command "compress". I was not able yet to figure out the "compress" for 100% but the first 3 bytes (or was it 2?) are always the same, afterwards its the trick to detect the lenght of the compressed packages and isolate it from the core binary... Perhpas someone already hacked its way into a binary and can tell us whats inside :-) (I must say!! I miss indeed detailed information now and then from the Rebol-Team in the manuals.) (R)egards, Norman.

 [12/13] from: gchiu:compkarori at: 19-Nov-2002 10:28


On Mon, 18 Nov 2002 20:35:41 +0100 Rebolinth <[Rebolinth--nodep--dds--nl]> wrote:
>Heeee even more funnier :-) Did you ever debugged the >core binary? >The core binary (perhpas also the other binarys use the >internal rebol >compress!!! have a look in the binary files you will find
Hi Norman, Yes, I was aware of this. I think RT have also mentioned this.
>(I must say!! I miss indeed detailed information now and >then >from the Rebol-Team in the manuals.)
I guess they don't want people hacking into their binaries! BTW, I'm not sure that I agree with your bulk buying scheme. But perhaps RT could consider it for developers who live in countries where the average wage is much lower. Sort of 3rd world aid :) -- Graham Chiu

 [13/13] from: ammon:rcslv at: 18-Nov-2002 22:58


Hi,
<Snip> > > The principle is easy. Have a look at FreeWrap from Tcl, they use the > Virtual Zip (yes its tcl) but it compresses the code and script into > 1 file (zip finaly) ( with a little excryption ) and Voila > you have a standalown package that runs directly into memory :-) > > I was just investigating if a rewrite for Rebol is an option :-)
If I understand your question correctly then you are looking for /Encap. It is a program that you can get from RT that will allow you to create your own executables. All you want to do is wrap your script and the interpreter into one executable file, right? /Encap does that. Enjoy!! Ammon

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted