System/?
[1/7] from: ptretter:charter at: 29-Sep-2000 9:35
Where can I find all the refinements or path values and what is the best way
to probe them.
Paul Tretter
[2/7] from: jeff::rebol::net at: 30-Sep-2000 6:46
> Where can I find all the refinements or path values and what is the best way
> to probe them.
>
> Paul Tretter
With the newest experimental versions of REBOL you can just
do:
PROBE SYSTEM
and a huge pile (~64k) of source code will fly by. That's
information overload, so to see what words are at each
level of the system object you can do the following:
probe first system
[self version build product components words license options
user script console ports network schemes error standard view
stats locale]
then
probe first system/ports ;-for instance
[self input output echo serial]
Bo made a script to help people navigate the system object:
http://rebol.org/script/browse-system.r
A view version would be neat.
-jeff
[3/7] from: larry:ecotope at: 30-Sep-2000 13:05
Hi Jeff
You wrote:
> PROBE SYSTEM
>
> and a huge pile (~64k) of source code will fly by
The size with Windows versions seems to be larger. I used the following line
of code:
>> write %probe-sys.txt mold system
Core 2.4.37.3.1 produces a file of size 218 kB.
View 0.10.34.3.1 produces a file of 656 kB.
That is for view without the demo-object loaded (i.e., I set start-view?:
off in the user.r file), if the demo-object is loaded (default start-up)
there is an out of memory error.
Cheers
-Larry
[4/7] from: rebol:techscribe at: 27-Oct-2000 12:32
Hi guys,
sorry to bring this up, but it is a practical problem right now. I have
as much as convinced a client that we should implement the GUI interface
of his application in REBOL/View instead of using HTML. This decision
would cause us to replace PERL and HTML by REBOL/View. My problem is that
we must also launch programs that provide special services, such as
paging. As soon as I say that this part of the functionality will have to
be handled by /Command or PERL, the customer (this one happens to be a
PERL hacker himself) snaps back at me saying, well then lets do all of it
in PERL. Forget /View.
I could imagine that this may be an attitude that comes up frequently,
and that may stand in the way of REBOL's acceptance by the scripting
community. How much work would it be for you guys to release a /Command
/View combo? Single executable that includes /Command as well as /View
functionality. Once /View has stabilized to the point where there is a
/View stable release, the /Command /View combo (/System ?) could be
launched as an upgrade for /Command users who require GUI functionality.
What do you think?
Elan
[5/7] from: petr:krenzelok:trz:cz at: 27-Oct-2000 22:00
----- Original Message -----
From: Elan <[rebol--techscribe--com]>
To: <[ally-list--rebol--com]>
Sent: Friday, October 27, 2000 9:32 PM
Subject: [ALLY] /System
> Hi guys,
> sorry to bring this up, but it is a practical problem right now. I have
<<quoted lines omitted: 6>>
> PERL hacker himself) snaps back at me saying, well then lets do all of it
> in PERL. Forget /View.
I of course don't know the kind of application, but if you are on the
server, you can use CGI, or what about using javascript in browser? Does it
allow to start apps? And if not, what about some kind of mime type
registered to browser to launch the related app?
Of course I don't know if any of above would work ...
Then there's another solution - let's implement some "standard" C based app
(gate), listening to rebol on one side, launching commands on the other
side. IIRC such solution was provided some year or more ago on rebol ml.
Launching of externall apps is matter of one or few lines of code in Delhpi
e.g., or not?
and btw: what's bad with external environment launching the app? Unix land
is full of utils sending output one to many others, so what ;-)
btw: does perl have any default gui environment? Or do Perl users use
tcl/tk?
> I could imagine that this may be an attitude that comes up frequently,
> and that may stand in the way of REBOL's acceptance by the scripting
<<quoted lines omitted: 4>>
> launched as an upgrade for /Command users who require GUI functionality.
> What do you think?
Elan - no way - if we will go that way - we are doomed. Who will handle all
that variants? What if I want another component? There is only one way -
proven already very well in computing - to have a kernel /Core, and dynamic
loadable components (libraries, devices, call it whatever). Only that way
makes sense and I know RT knows that's the way to go. Carl likes modularity,
as he created AmigaOS. I think RT just don't have the time to abstract the
solution nowadays, as it would require to isolate components internally and
set some kind of APIs. But having just /Core and being able to buy just
components I need is so cool - even for RT, as it allows them to ask for
more money that way .... if someone is going to buy /Oracle, you can bet the
company can afford some hundreds of dollars price, because the company owns
Oracle based server :-) Having everything in one .exe is limiting everybody
...
Cheers,
-pekr-
[6/7] from: al:bri:xtra at: 28-Oct-2000 9:09
pekr wrote:
> Then there's another solution - let's implement some "standard" C based
app (gate), listening to rebol on one side, launching commands on the other
side. IIRC such solution was provided some year or more ago on rebol ml.
> Launching of external apps is matter of one or few lines of code in Delphi
e.g., or not?
You could try this (which works for me):
#include <iostream>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <dos.h>
int main() {
FILE *pF;
while (!0) {
if (pF = fopen ("Command.bat", "rt")) {
fclose (pF);
system ("Command.bat");
system ("erase Command.bat");
}
_sleep (1);
}
return 0;
}
// End.
I hope that helps!
Andrew Martin
ICQ: 26227169
http://members.nbci.com/AndrewMartin/
[7/7] from: brett:codeconscious at: 29-Oct-2000 16:33
Hi Elan,
It is great that your client is interested in using View as the GUI. But
View does not exist as a product. I assume you will not be implementing
anything on a beta that can expire. More than that I'd caution you on
spending paid development time on a product that does not exist even if you
think (or have been led to believe) that it will shortly.
If you customer is already "snapping" at you to use Perl, you would probably
save yourself an immense amount of grief by just going with Perl or whatever
and waiting 'till next time, rather than living on the bleeding edge.
Brett.
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted