r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[SDK]

Janko
15-Jun-2009
[1407]
I have a application that is spread over around 15 files.. I use 
>>do %file<< to "include" them now. Now I am making a encapped version 
of app. do still tries to do the .r files but they don't exist when 
single exe is created so I get errors. I tried naming all files when 
doing encap but it behved the same. I read about prebol and understand 
that I have to  #include the files but I suppose that won't work

when developing and executing from it directly with >>rebol mainfile.r<< 
because it will need to be prereboled each time? 


Is there a way to make a script that I can encap and run directly 
via .r files? If there is no other way I was thinking about making 
>>either encap [ #include %file.r ] [ do %file.r ]<< but it's not 
the most elegant solution .. Is there any better?
Henrik
15-Jun-2009
[1408]
I simply use two separate files, one for #include, the other for 
'do.
Janko
15-Jun-2009
[1409]
but then you have to make code changes on two files?
Henrik
15-Jun-2009
[1410x3]
I find it to be far less cumbersome than trying to come up with fancy 
methods of using a single file for do and #include. Especially if 
you are using multi-level includes.
With that I mean, if you create your own libraries that are preprocessed 
or 'do'ed separately and then included or 'do'ed in the main file.
Be sure that you don't do much else but includes in those files. 
This will make sure that after a while, working on your project, 
both files will get steady and no more changes occur, and then you 
won't see there are two different files.
Janko
15-Jun-2009
[1413x2]
yes, I have multi level do-s a file does app-specific lib file which 
do-es more generic libs etc .. hm I will think about it..
I don't like duplicating code.. then I can have one bug in one file 
and another in other and I always have to check if I updated them 
both etc.. winMerge and tools like this would help but anyway
Henrik
15-Jun-2009
[1415]
I know what you mean, but in this case, I find it easy to make an 
exception.
Janko
15-Jun-2009
[1416]
thanks for explaining it to me.. so I know what options are there.
Henrik
15-Jun-2009
[1417]
In the build system I use now for my projects, there are two separate 
files. The one I use for development is the 'do, and the one my customer 
gets is the #included version. Then I have a make-file, that builds 
the project and puts it where it needs to be (local webserver), counts 
up the build version. I can build it whenever I want and there are 
no hiccups.


My earlier attempts at a build system was by trying to be fancy, 
i.e. build with as few keypresses as possible. It never worked as 
well as this one.
Janko
15-Jun-2009
[1418x2]
yes, many times simplest solution is the best.. and usage shows what 
works
I will try few ways of doing it too
Sunanda
15-Jun-2009
[1420]
Would this one line in your start up help?
   if not encap [#include: : do]
Janko
15-Jun-2009
[1421]
interesting.. I will try if it works
Graham
15-Jun-2009
[1422x2]
why not create a target source file and run that?
enface source.r -t target.r -o target.exe
and that gives you the pre-reboled version as target.r
Janko
15-Jun-2009
[1424]
but then I have to encap everty time I make a change :)
Graham
15-Jun-2009
[1425x2]
no .. you can use pre-rebol ....
encap uses prerebol
Janko
15-Jun-2009
[1427]
ok .. encap or prerebol every time I make a change .. I could automate 
it so that when I want to text-run app I have some batch file that 
prerebols it and runs it instead of just runs it
Graham
15-Jun-2009
[1428]
Also look at cheyenne.r
Janko
15-Jun-2009
[1429]
that could work since rebol doesn't give me line number on error 
so it doesn't matter that I am editing different thing than running 
(in terms of file/line num)
Graham
15-Jun-2009
[1430x2]
I use a .cmd file myself ... to build my sources and then run them.
But doc has set up cheyenne.r so that you can either run it , or 
use it in encap.
Janko
15-Jun-2009
[1432]
I will look at cheyenne.r , thanks
Ladislav
15-Jun-2009
[1433x4]
Janko: re your #include question: you should try INCLUDE, seriously
it solves exactly your problem
you always can do: INCLUDE %file, which is an equivalent of DO %file, 
except for the fact, that it includes everything needed
...and if you want to just save the file, you use INCLUDE/LINK %my-input.r 
%preprocessed-output.r
Ashley
15-Jun-2009
[1437]
Sunanda, the "#include: :do" suggestion won't work as #include is 
an issue! not a word! ... I like the line of thought though.
Ladislav
15-Jun-2009
[1438]
#include: :do surely isn't possible, it would be possible only if 
we used the *include* alternative
Janko
15-Jun-2009
[1439]
Ladislav: I will try your include
Sunanda
15-Jun-2009
[1440]
Thanks, Ashley.....

    loop 100 [print "I should test my ideas before publishing them."]
Oldes
15-Jun-2009
[1441x2]
It would not work for me anyway as I use other PREBOL syntax as well. 
Personally I like the issues for such a syntax. I use PREBOL for 
single projects scripts and 'require spec in the script's header 
for other scripts/projects which are required for the single script/project.
The difference between the 'require and the script's #include is, 
that in the header I use only projects/script name and or version 
and not relative path as one has to do with the #include.
Ladislav
15-Jun-2009
[1443]
...as one has to do with #include...
 - it depends...
Oldes
15-Jun-2009
[1444]
In R3 I should probably replace it with modules. Your include.r enables 
that?
Ladislav
15-Jun-2009
[1445x2]
Carl wrote, that R3 modules don't support include at this time, check 
the http://www.rebol.net/wiki/Inclusion_Methodsand http://www.rebol.net/wiki/INCLUDE_documentation
texts
(maybe you find what you need)
Oldes
15-Jun-2009
[1447x2]
I have what I need :) I'm just not sure why the #include should be 
replaced. BTW.. I have one own addition into PREBOL - #include-block 
(which includes data as a block as it's with #include-binary)
(I mean the usage of issues for preprocessing directives)
Ladislav
15-Jun-2009
[1449]
undestood
Oldes
15-Jun-2009
[1450]
Also my preprocessor adds comments based on script headers so if 
I include foreign script, the name of the author is present. Like 
for example here: http://box.lebeda.ws/~hmm/rebol/gif_latest.r
Ladislav
15-Jun-2009
[1451]
the headers: yes, that looks like making sense in case the file is 
meant to be published as text
BenBran
12-Aug-2009
[1452]
Anybody know a workaround for this?

from rebcmdview.exe and/or old desktop:

REBOL []
print length? read/lines http://www.google.com	;; works
print length? read/lines http://www.rebol.com	;; works
print length? read/lines https://www.google.com	;; works
halt

11
242
11

encapsulate (encmdface.exe) above and run the exe:

11
242
** Access Error: Invalid port spec: https://www.google.com
** Near: print length? read/lines https://www.google.com
halt
** Press enter to quit...

happens on any https page
Graham
12-Aug-2009
[1453x2]
Yes, check to see if https is installed.
Unless you downloaded the very latest 2.7.6 sdk, you will have that 
issue.  Easy to fix though.
BenBran
12-Aug-2009
[1455x2]
I received this via email. ...rebol-sdk-cmd-z2l7np..... Is there 
another place to download the latest?
I'll send a message to Rebol.  I have 2.5.6. Thx.