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

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