-= B E G I N =- Date: Fri, 21 Jun 1996 08:07:45 EST From: John Kinne Subject: Welcome to the Euphoria LISTSERV Welcome to the Euphoria LISTSERV. Contributions are archived, and retrieveable, for all eternity! Nothing is wasted or forgotten. Robert there is some information that should be kept in the archives: How did Euphoria come to be? Is it based on another work? Was it written entirely by R.C.? What language was it written in, how many source lines? Will it be ported to other platforms? Are specs being developed for Version 2? Will we be able to extend it? John -= B E G I N =- Date: Fri, 21 Jun 1996 08:12:33 EST From: John Kinne Subject: Euphoria error message I am developing a program that will be widely distributed. If the interpreter(?) discovers an error, it displays an error message telling the user that the source program is over 300 lines long, gives some hints about debugging a program, and gives instructions on how to purchase the complete edition of Euphoria. Purchasing the complete edition will not help the user I am writing my program for. Can my Euphoria program set up a control so that it can intercept error situations & display a message that would be helpful to my users? I would like to give them the number of a local helpdesk, and maybe refer them to some documentation. John Kinne -= B E G I N =- Date: Sat, 22 Jun 1996 00:26:14 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Re: Welcome to the Euphoria LISTSERV On June 21, John Kinne wrote: > How did Euphoria come to be? > Is it based on another work? > Was it written entirely by R.C.? Back in 1989 my brother Dave, who is also a software developer, bought an Atari Mega ST with a whopping 4 Mb of memory. I was very impressed and I wanted one too, but I didn't know how to justify buying one. I decided I would do some kind of long term hobby project in the compiler development area, since that is what my background is. After several months of day dreaming I finally decided -- I would design and implement a new programming language loosely based on my Master's thesis at the University of Toronto. In my Master's research I had examined John Backus' FP language. John Backus is the guy who developed the first Fortran compiler for IBM. Euphoria (it didn't have a name back then - just language 'X') took the concept of atoms and sequences from FP, but is totally different in all other respects. Also, in FP an atom can be a number or a string. I didn't like that. I thought a string should be a sequence of characters, so you could apply subscripting, appending etc. to it, just like all other sequences. The idea of slicing came from Ada. Within a few months I had a working prototype interpreter for Euphoria. I had designed it as best I could for maximum speed. I eagerly performed the first sieve benchmark test -- Euphoria was 250 times *slower* than C on the Atari. I was not particularly disappointed. I thought a Euphoria interpreter *should* be tremendously slower than compiled, optimized C code, given all the flexibility, garbage collection, subscript checking etc. Over the next 3 years I continued to add to the language and to improve the speed. Speed became something of an obsession for me. On at least 3 occasions I completely re-wrote thousands of lines of the interpreter, just to get a modest boost in performance. My full-time day job was getting very boring at the same time that Euphoria was getting more interesting. Finally a good opportunity arose and I quit my day job so I could port Euphoria to the IBM PC, finish v1.0, and release it as shareware. Since then I've been pleased with the reaction to it, and although there isn't a lot of money in it, the registration rate is steadily increasing. I'm doing some consulting work now to pay the bills but I'm as busy as ever on Euphoria (I never sleep). My wife, Junko Miura, left her job as a compiler developer a few months ago, so she could persue other interests, including Euphoria. To avoid any conflict of interest accusations, she carefully avoided doing any development work on Euphoria until now. > What language was it written in, how many source lines? Euphoria (ex.exe) is written in WATCOM C/32. It consists of just 14,000 lines. (about the same as the number of lines of Euphoria code in EUPHOR14.ZIP) There's also a bit of machine code for added performance. > Will it be ported to other platforms? I hope so. I could release the source in some manner. I haven't decided yet. > Are specs being developed for Version 2? I've got wish lists with dozens of ideas for improving things. I usually need a couple of months after a release to settle on the major features for the next release. > Will we be able to extend it? I'm investigating the possiblity of dynamic link libraries where Euphoria code could call C subroutines. Nothing is certain yet. > I am developing a program that will be widely distributed. > If the interpreter(?) discovers an error, it displays an error > message telling the user that the source program is over 300 lines Someone else brought this up just before v1.4 was released, so I didn't have time to deal with it. I think what I'll do unless someone can suggest a better idea, is to add a library routine that you can call that will establish the message to be displayed if a run-time error occurs. This would be done for v1.4a which might be out in a few weeks or so. You might call this routine more than once in your program if (say) you want to change the message based on your program having completed at least part of it's task. This routine may be helpful to those who are over 300 statements but are trying to avoid registering, but that's ok I guess :-) ----------------------------- Rob Craig Rapid Deployment Software ----------------------------- -= B E G I N =- Date: Sat, 22 Jun 1996 12:28:50 EST From: John Kinne Subject: Euphoria error msg In-Reply-To: Message of Sat, 22 Jun 1996 00:26:14 EDT >> I am developing a program that will be widely distributed. >> If the interpreter(?) discovers an error, it displays an error >> message telling the user that the source program is over 300 lines > >Someone else brought this up just before v1.4 was released, so I didn't >have time to deal with it. I think what I'll do unless someone can >suggest a better idea, is to add a library routine that you can >call that will establish the message to be displayed if a run-time >error occurs. This would be done for v1.4a which might be out in a few >weeks or so. You might call this routine more than once in your program >if (say) you want to change the message based on your program having completed >at least part of it's task. This routine may be helpful to those who are >over 300 statements but are trying to avoid registering, but that's ok I guess > :-) > Good idea, but not quite the right spin. I am developing the program in Euphoria. My version of Euphoria *is* registered. I am binding my pgm and distributing it to people who are not programmers, and have no desire to become programmers. When I bind the program, the P.D. version of Euphoria is attached to the binary. When users of my program experience an error in my program, they get the message that tells them they can insert print statements or buy the complete edition of Euphoria. Of course, they have no idea what a Euphoria programming language is, they don't want the complete edition, & it would not help them solve the problem in my program. As a Euphoria user, I could not tell that Euphoria was developed in Watcom C. (I am sure there are finger prints if I knew where to look for them.) I don't get error msgs from Watcom, if Euphoria is broke, I don't go to Watcom for support... I would prefer that Euphoria would provide something like PL/1's ON ERROR structure. The syntax is something like ON ERROR BEGIN; ... ... END; In the event of an error, the last executed ON ERROR gets control. Thanks for the consideration, John Kinne -= B E G I N =- Date: Sun, 23 Jun 1996 13:00:32 EST From: John Kinne Subject: Euphoria on a PS/2 55sx w/ 8514 display I am experimenting with a Euphoria pgm on as many platforms as I can get to. I noticed some anomalies on an 55sx w/ 8514 display: don't know if the 55sx or the 8514 was the instigator. ctrl-delete did not delete a line in ED. text colors were not displayed in ED. The menu bar was colored properly, but all text was presented in black on a gray background - no red for comments, nor green for sequences, etc. The interactive trace screen worked properly, but was presented as white text on a black background. Many other euphoria functions worked properly. Message-Id: <960623.130452.EST.JDKINNE@MIAMIU> John Kinne -= B E G I N =- Date: Sun, 23 Jun 1996 23:28:22 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Re: Euphoria on a PS/2 55sx w/ 8514 display On June 23 John Kinne said: > I am experimenting with a Euphoria pgm on as many platforms > as I can get to. I noticed some anomalies on an 55sx w/ 8514 > display: don't know if the 55sx or the 8514 was the instigator. The 8514 display is a bit weird. It doesn't follow SVGA standards. I think it is kind of obsolete now. > ctrl-delete did not delete a line in ED. Yes, I've found that some machines do not support control-delete. That's why I also allow control-d for line deletion. > text colors were not displayed in ED. The menu bar was > colored properly, but all text was presented in black on a > gray background - no red for comments, nor green for > sequences, etc. > The interactive trace screen worked properly, but was presented > as white text on a black background. video_config() must be reporting that this is a mono monitor. Both the editor and the trace screen call video_config(). ed will turn off color syntax highlighting if it believes it is working with a mono monitor. I'm not sure how the WATCOM routine that Euphoria calls is determi ning this, but the 8514 must be confusing it. Thanks for the info. I haven't run Euphoria on a machine like this before. Regards, Rob Craig Rapid Deployment Software -= B E G I N =- Date: Sun, 23 Jun 1996 23:28:25 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Euphoria error msg On June 22, John Kinne said: > I would prefer that Euphoria would provide something like PL/1's > ON ERROR structure. The syntax is something like > > ON ERROR BEGIN; > ... > ... > END; > In the event of an error, the last executed ON ERROR gets control. I don't plan on putting exception handling into the language, at least not in the forseeable future. I realize there are a few problems here for registered users. First, they currently can't control the message that pops out when an error occurs. Second, if a program they are distributing is over 300 statements there will not be any ex.err file produced. Third, even if an ex.err file is produced, from a bound or shrouded program, it is tedious (but not impossible) to relate the error back to the original source. Fourth, they can't regain control after an error happens. For the first problem, I could as I said earlier, add a library routine that would let you override the undesirable message that comes out now with your own message. For the second problem, I might be able to provide a special bind program for registered users only, that would let you choose whether an ex.err file should or should not be generated for a given program (regardless of statem ent count). I need to ensure however that registered users are not distributing thousands of copies of ex.exe in their bound programs such that it can be easily extracted and used by non-registered people to debug their >300 statement programs. I wish that I didn't have to have any limits, but people need some incentive to register. For the third problem, I could (optionally) generate from the bind program a lis ting file showing your original source code interleaved with the shrouded code. The shrouded code would have line numbers beside it so if someone reports an error out in "the field" you cou ld quickly figure out where in the real source it was failing. The fourth problem can be partially addressed today by invoking your .exe file f rom a .bat file. When a Euphoria program fails, Euphoria returns an exit code of 1 that a .bat fi le can detect using the errorlevel feature. Normally Euphoria returns a 0 errorleve l code. (I don't think this was ever documented anywhere - I'll add it.) If anyone has any further ideas on this, please post them. Thanks, Rob Craig Rapid Deployment Software -= B E G I N =- Date: Mon, 24 Jun 1996 14:07:15 -0400 From: David Alan Gay Subject: Hello everyone :) Greetings everyone. My name is David Gay, and I maintain the "A Beginner's Guide to Euphoria" web page here in Toronto, Canada. This web page is devoted to teaching those who never programmed in their life how to program in Euphoria. The location is http://www.interlog.com/~moggie/euphoria.htm. I look forward to talking to everyone participating in this listserv about Euphoria programming concepts and tips :) Long live Euphoria :} David Gay -= B E G I N =- Date: Tue, 25 Jun 1996 15:53:17 +0100 From: Marcel Kollenaar Subject: Re: Hello everyone :) Hello everyone, My name is Marcel Kollenaar. I'm working at the SLO (Institute for Curriculum Development in the Netherlands) as a technical WordPerfect administrator (macro's). An 8 month ago we installed Internet for all our employees. So I started my search on internet for an programming language that could easy manage list. I've programmed in C, used linked list but after a while the C-style syntax got too difficult for my brains. As a miracle I found Euphoria. A delight. He who read the book "The Celestian Prophesy" knows there is no miracle at all. I'm using Euphoria to build small programs to examine the WP5.1 binary documentstructures for fun. Just to be busy with an easy language. Now I'm testing/learning, with random lists (100,000 integers), sorting, writing the list to disk, reading from disk, binary searches. All this effort for trying to make an little KISS indexed sequential database program. Yesterday I installed Windows 95 on my computer, plug, switch off and pray, started Euphoria in an DOS box and it ran out of memory with my listprogram. Something it didn't under DOS where it made it's own memorybuffer on disk. Windows '95 got me some other trouble with my Shiva telephone connection from my home to the SLO. Again I'm running 3.11 and all runs well. Maybe other people have some experience with Euphoria/Win95. I'm running a Tulip Pentium de5/75, 8Mb memory. Today i'm running the Helpdesk and have a customer who needs help. Until next time ..... Greetings Marcel Kollenaar -= B E G I N =- Date: Tue, 25 Jun 1996 11:00:10 -0400 From: David Alan Gay Subject: Re: Hello everyone :) At 03:53 PM 6/25/96 +0100, you wrote: >---------------------- Information from the mail header ----------------------- >Sender: Euphoria Programming for MS-DOS >Poster: Marcel Kollenaar >Subject: Re: Hello everyone :) >------------------------------------------------------------------------------- Hi Marcel :) I ran into the same problem using Euphoria under Windows'95 for a shareware game I am writing (to be released sometime next year). I found that setting the CAUSEWAY environment variable gets rid of the out of memory trouble, but slows the program down a bit. RDS recommends also trying to remove SMARTDRV and any other TSR that may take up extended memory helps too. Hope this helps David Gay dgay@idirect.com -= B E G I N =- Date: Tue, 25 Jun 1996 10:38:10 PST Comments: MEMO 06/25/96 10:36:00 From: "David (DSSSTARS-DCUN" Subject: trapping control-c I had a question for Rob Craig on disabling the trapping the Control-C key behavior on a wait_key(). I wanted to use the key combination in my editor as a "cut" behavior. He didn't have a solution, but he suggested I contact this group. I worked out a routine that reads the keyboard buffer directly. It works like this: Buffer State Action ------------------- ------------------------------ Nothing pending Return -1 Control-C in buffer Clear buffer, return Control-C Anything else Return result of get_key() I'm posting it in case anyone else is interested in it, as well as inviting comments and suggestions. This is actually part of a larger routine that also watches the SHIFT and ALT key states, so I can catch SHIFT_LEFT_ARROW and SHIFT_RIGHT_ARROW (for selecting text) and ALT_PRESSED (for activating the menu). Because ALT and SHIFT don't generate actual key press events, I can't use wait_key(). This should perhaps CTRL-S as well, since that has an annoying behavior. I also have to massage the results from this routine because the values returned from get_key() are not unique; CTRL-M and Enter, for example, map to the same number. == CODE BEGINS HERE ================================================== -- direct read of the key buffer -- catches control-c before it can be read constant KEY_BUFFER = 1054, -- keyboard buffer; circular queue FIRST_INDEX = 1050, -- index to first key in buffer LAST_INDEX = 1052, -- index to last key in buffer CTRL_C = 03 -- control-c global function get_safe_key() -- return key currently being pressed -- return zero if no key is pressed integer key_code, scan_code -- buffer is empty is indexes point to each other if peek( FIRST_INDEX ) = peek( LAST_INDEX ) then -- nothing in the buffer return -1 end if -- get the key code and the alt key code scan_code = peek( KEY_BUFFER + peek( FIRST_INDEX ) - 29 ) key_code = peek( KEY_BUFFER + peek( FIRST_INDEX ) - 30 ) -- look for control-c if scan_code = 46 and key_code = 3 then -- clear the buffer poke( FIRST_INDEX, peek( LAST_INDEX ) ) -- return a control C return CTRL_C else -- read through the normal process return get_key() end if end function == CODE ENDS HERE ==================================================== thanks. -- david cuny -= B E G I N =- Date: Tue, 25 Jun 1996 15:16:36 -0400 From: David Alan Gay Subject: Re: trapping control-c The only method I know on how to trap the keystroke generated by Control-C is to use the DOS prompt function to remap Control-C to something else. I was faced with this problem when I used Microsoft C to write a program that basically emulated a dumb terminal connection to a mainframe. On the mainframe, Control-C was a request to go to another page. But pressing Control-C caused the program to halt. What I did was used prompt to remap Control C to something else (I believe I chose the down arrow as the new value). When the program received the down arrow key (which was really me entering Control-C at the keyboard, it sent the correct Control-C characters to the mainframe, and the mainframe sent the next page of data. Crude, but that's the only way I knew how to get around this problem. -= B E G I N =- Date: Tue, 25 Jun 1996 16:02:30 EST From: John Kinne Subject: Interface to DOS info Hello All and welcome to the list. I have been programming in Euphoria for a month or so. I am writing a program that will install network software. This is my first major DOS project: I am normally a mainframer. I would like to collect a bit of info about the DOS machines: I can get the DOS version, hard drive size, amount of conventional memory by using interrupts. From contents on the hard drive I can determine the existence of Win31. I can not find anyway to determine extended memory size (I can trap the output of the MEM command but that assumes the existence of the MEM command. The format of the output from MEM changes from one DOS release to another.) Processor (I can use P.D. SNIFF, I'd like to get it directly from inside euphoria) processor speed (I don't have anyway to get this) Manufacturer Model Thanks for any ideas, John Kinne Miami University -= B E G I N =- Date: Thu, 27 Jun 1996 03:19:49 -0400 From: David Alan Gay Subject: Re: Interface to DOS info John Kinne Thanks for work on the listserv. It is so far a lot of fun :) >I would like to collect a bit of info about the DOS machines: I can get >the DOS version, hard drive size, amount of conventional memory >by using interrupts. From contents on the hard drive I can determine the >existence of Win31. I can not find anyway to determine I know of many shareware programs that will dump the settings of your system into a text file (or can be tricked into doing so by using DOS piping commands to reroute text screen display to file). The problem with these programs is that they do not tend to be right most of the time. One computer program thought my P-90 was a 486SX. I know some Assembler programmers can get the information by reading the BIOS data somewhere, but being Assembler-illiterate, I do not know how to do that. Hope this helps David Gay -= B E G I N =- Date: Thu, 27 Jun 1996 08:46:38 EST From: John Kinne Subject: Re: Interface to DOS info >>I would like to collect a bit of info about the DOS machines: I can get >>the DOS version, hard drive size, amount of conventional memory >>by using interrupts. From contents on the hard drive I can determine the >>existence of Win31. I can not find anyway to determine > >... >I know some Assembler programmers can get the information by reading the >BIOS data somewhere, but being Assembler-illiterate, I do not know how to do >that. > >... > Yes, and the Euphoria PEEK instruction would let me read data directly from memory. Being a mainframer, I expect that DOS keeps lots of interesting data in memory - like my mainframe systems do. My mainframe systems come with logic manuals that detail what is kept in memory, and how to find it. When I took on this project I expected that reporting the model number of the machine the program is executing on would be trivial. Not so. X-Mailer: MailBook 95.01.263 I have found very generic descriptions of how DOS uses memory. But as far as I can tell, it is up to each manufacturer of each model PC to store a byte here or there that might indicate what model machine this is. Very different than the tight adherence to standards to which I am accustomed. Not to slam the technology! It is just a bit of a challenge. Thanks for the note. John Kinne -= B E G I N =- Date: Thu, 27 Jun 1996 13:58:42 EST From: John Kinne Subject: Getting the Error code How can I retrieve the error code of a DOS pgm invoked by a euphoria pgm. E.g. system("pe3test",2) ... if ErrorLevel=2 then .... I have a DOS pgm that will only communicate back to me via error code. I can do something kludgy like invoking the DOS pgm from a BAT & checking the errorlevel there - then writing a DOS file that my E-pgm can find. I am hoping for something a bit more elegant. Thanks for the help John Kinne -= B E G I N =- Date: Thu, 27 Jun 1996 21:41:13 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Re: Getting the Error code On June 27, John Kinne wrote: > How can I retrieve the error code of a DOS pgm invoked by > a euphoria pgm. E.g. Unfortunately, there is no easy way to do this at present. The WATCOM C routine that system() calls does not return a useful error code to Euphoria. > I have a DOS pgm that will only communicate back to me via error > code. I can do something kludgy like invoking the DOS pgm from > a BAT & checking the errorlevel there - then writing a DOS file > that my E-pgm can find. I am hoping for something a bit more > elegant. This is probably your best bet. I'll make a note of this problem. I don't see any "quick fix" for this one. Regards, Rob Craig Rapid Deployment Software -= B E G I N =- Date: Fri, 28 Jun 1996 12:19:43 +0100 From: Matt Sephton Organization: Tektonix Software Subject: Shrouding files... Hello all! I have been trying to shroud a file which I have written. It is a .e which is to be included in a number of programs. I want to keep the source to myself. However, the shroud seems to have completed properly, but when I execute a normal, unshrouded .ex file which calls the routine I get an error: Cd(Dd) Dd not defined. This could be that I am trying to use Global constants to let the user configure the routine from the calling .ex file which are obviously called something totally different in the shrouded .e file. Will I have to forget about making the routine user configurable? Would it be more sensible to add keys which would change these parameters as the routine is running or locate the lines in the shrouded file which the user can change (after all it is only colour, sort configuration!) Any ideas? Matt PS: Reply personally please, as I'm not actually on the mailing list yet! -- u5ms@csc.liv.ac.uk http://www.csc.liv.ac.uk/~u5ms/ -= B E G I N =- Date: Fri, 28 Jun 1996 13:53:06 +0100 From: Marcel Kollenaar Subject: Re: SET CAUSEWAY VARIABLE Hello David, > that setting the CAUSEWAY environment variable gets rid of the out of memory > trouble, but slows the program down a bit. RDS recommends also trying to > remove SMARTDRV and any other TSR that may take up extended memory helps too. On your advice I put the SET CAUSEWAY=SWAP:C:\APPL\TEMP environment var in the AUTOEXEC.BAT file and gave smartdrive only 1024 Bytes under Windows and 0 under DOS with "C:\WINDOWS\SMARTDRV.EXE 0 1024". Started the system again but I get the same "Your progr.." message. It still happens in the get.e module. What I don't understand is that the program can initialise and fill a list of 100,000 integer items in the form of {{n,n},{n,n},..}. The program can sort it with the sort.e program, I can write it to disk to a file, 1,400,000 bytes. But I can't read it from disk in the same list. Between the write and read step I make the list empty with the statement LIST = {} , so I think it will free up the memory it uses. But after a while the program exits with an error message. Marcel Kollenaar -= B E G I N =- Date: Fri, 28 Jun 1996 23:35:08 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Re: SET CAUSEWAY VARIABLE On June 28, Marcel Kollenaar wrote: > On your advice I put the SET CAUSEWAY=SWAP:C:\APPL\TEMP environment > var in the AUTOEXEC.BAT file and gave smartdrive only 1024 Bytes > under Windows and 0 under DOS with "C:\WINDOWS\SMARTDRV.EXE 0 1024". > Started the system again but I get the same "Your progr.." message. "SET CAUSEWAY=SWAP:..." will have no effect under Windows. It only matters when you are running outside Windows on pure DOS. Under Windows you will get virtual memory from the Windows system swap file. Under Windows 95, I'm not sure if SMARTDRV has any effect either. > It still happens in the get.e module. What I don't understand is > that the program can initialise and fill a list of 100,000 integer > items in the form of {{n,n},{n,n},..}. The program can sort it with > the sort.e program, I can write it to disk to a file, 1,400,000 > bytes. But I can't read it from disk in the same list. Euphoria stores integer values in 4 bytes. Each sequence has an overhead of about 20 to 24 bytes for control information (22 average). So a 2-element sequence of integers would actually consume 22 + 2*4 = 30 bytes. So 100,000 pairs would need 100000*30 = 3,000,000 bytes. For a long sequence (of length > 20 say) the overhead isn't of much concern, but for 2-element sequences the overhead exceeds the cost of storing the elements themselves. The Windows 95 operating system consumes more (virtual) memory than Win 3.1. The memory available to you would be the total RAM + a few megs of swap space minus the space consumed by the operating system, disk cache, and swapped out applications. You can get more memory under pure DOS. On a 24 Mb RAM Windows 95 system ed was able to get about 20 Mb or so before getting "out of memory". Under pure DOS the swap file will keep growing automatically if you still have free disk space. Under Windows the operating system limits the growth to some number. You can increase the swap space but eventually your application is likely to run very slowly. > Between the > write and read step I make the list empty with the statement > LIST = {} This is a valid thing to do. However if you have any other variables that are still "pointing" to the same data, it won't be freed. Sometimes you can even have a temporary intermediate expression result that you recently calculated still in memory that won't be freed right away. So you might temporarily be using more memory that it appears. Another issue is that when get() reads in your data it uses append() to build up the resulting sequence. append() sometimes has to make a whole new copy of a sequence, when there is no more room to grow. So for a moment 2 copies are in memory. Finally, make sure your numbers are integers - no fractional part and within +/- 1,000,000,000 roughly. Floating point numbers consume about 20 bytes each. I typed in this quick example of what you seem to be doing and it ran ok for me under windows 3.1 with an 8Mb RAM machine. It generated a 1.5 Mb "junk.dat" file. I will try it later on a win95 machine. Maybe you can post some of your code so we can see more precisely what you are doing. ----------- start of example ----------------------- include get.e sequence s integer fn s = rand(repeat({1000000,1000000}, 100000)) fn = open("junk.dat", "w") print(fn, s) close(fn) s = {} fn = open("junk.dat", "r") s = get(fn) if s[1] = GET_SUCCESS then s = s[2] end if ?length(s) -- should print 100000 ------------- end of example -------------------- Regards, Rob Craig Rapid Deployment Software -= B E G I N =- Date: Fri, 28 Jun 1996 23:35:11 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Re: Shrouding files... Comments: To: Matt Sephton On June 28, Matt Sephton wrote: > I have been trying to shroud a file which I have written. It is a .e > which is to be included in a number of programs. I want to keep the > source to myself. > However, the shroud seems to have completed properly, but when I execute > a normal, unshrouded .ex file which calls the routine I get an error: > Cd(Dd) Dd not defined. This could be that I am trying to use Global > constants to let the user configure the routine from the calling .ex file > which are obviously called something totally different in the shrouded .e > file. What you are trying to do is a bit unusual, but quite reasonable. You can do it, but there's a trick to it. You should: 1. declare the global constants in your matt.e file. e.g. global constant MAX = 10, MIN = 5 2. shroud matt.e to get matt2.e (say) 3. edit matt2.e to remove the line(s) that declare your global constants It will be easy to see because these global names won't be shrouded. You can also remove the first line, that has (without) warning 4. Your users should declare: global constant MAX = 999, MIN = 777 include matt2.e ... etc... Your code will then access the values of these constants as defined by your users. In your .e file, remember to put "global" in front of the declaration of any variables or routines that you want your users to call. Regards, Rob Craig Rapid Deployment Software -= B E G I N =- Date: Sun, 30 Jun 1996 02:20:05 -4 Comments: Authenticated sender is From: Robb Holmes Subject: newbie's video problem I'm new to Euphoria and new to this list. After playing with the PD version, I am very impressed with Euphoria, but I've encountered a problem that has me stymied. I run Euphoria 1.4 programs in a DOS window under Windows 95. The first time EX runs, it forces the window to full-screen mode. Alt-enter will restore the DOS session to a window, and subsequent runs of EX in that session do not maximize it. But every DOS session suffers from this problem when EX runs the first time, and it's a significant obstacle to the way I want my programs to run. Has anyone else encountered this problem, and is there a known fix? Robb Holmes ------- Robb Holmes holmesr@ilinks.net "Did God ever build a wall?" -- Duke Ellington Rude Interlude, a Duke Ellington home page: http://www.ilinks.net/~holmesr/duke. htm -= B E G I N =- Date: Sun, 30 Jun 1996 11:46:05 EDT From: Robert Craig <72614.1667@COMPUSERVE.COM> Subject: Re: newbie's video problem On June 30, Robb Holmes wrote: > I run Euphoria 1.4 programs in a DOS window under Windows 95. The > first time EX runs, it forces the window to full-screen mode. > Alt-enter will restore the DOS session to a window, and subsequent > runs of EX in that session do not maximize it. But every DOS > session suffers from this problem when EX runs the first time, and > it's a significant obstacle to the way I want my programs to run. > Has anyone else encountered this problem, and is there a known fix? Yes, this is the behaviour that I see on win95 as well. I think it happens the first time you run *any* DOS program - no?. I have always assumed there was some setting in win95 to change this behaviour, but I have not tried very hard to find it. Unfortunately I won't be able to investigate it for a couple of days - maybe someone else on this list has the answer already. I'll let you know if I find out more. Regards, Rob Craig Rapid Deployment Software