--------------------------------OpenCard --------------
- 001�Re: ANSI: delete/rename files ??? 3/31/99 omgang
- 002�Re: OODL - Timing issues 4/2/99 derobert
- 003�Re: OODL - Timing issues 4/2/99 derobert
- 004�Re: OODL - Timing issues 4/3/99 Rob
- 005�UI Prototype in HC? 4/3/99 Rob
- 006�Re: UI Prototype in HC? 4/3/99 MPOwerd
- 007�Re: UI Prototype in HC? 4/3/99 Rob
- 008�Re: UI Prototype in HC? 4/3/99 omgang
- 009�OODL - Regroup 4/3/99 omgang
- 010�Re: OODL - Timing issues 4/3/99 derobert
-
----------------------------------------------------------------
-> Folks,
>
> I'm stomped. Anyone of you know whether ANSI C has a call to rename a
> file? I'm also looking for one to delete a file. Anyone? If C has none,
> anyone know one in the ANS Pascal libraries that I could call?
I think you want
int rename(const char *oldname, const char *newname)
and
int remove(cost char *filename)
The rest is here for a referance.
Andre
STANDARD INPUT/OUTPUT <stdio.h>
_________________________________________________________________________
Filenames are limited to FILENAME_MAX characters. At most FOPEN_MAX files
may be open at a given time.
CLEARERR
void clearerr(FILE *stream)
FCLOSE
int fclose(FILE *stream)
Returns EOF if error occurs, zero otherwise.
FEOF
int feof(FILE *stream)
Returns non-zero if EOF is set.
FERROR
int ferror(FILE *stream)
Returns non-zero if error exists for 'stream'.
FFLUSH
int fflush(FILE *stream)
Returns EOF if error, zero otherwise. fflush(NULL) flushes all output
streams.
FGETC
int fgetc(FILE *stream)
Returns EOF if error.
FGETS
char *fgets(char *s, int n, FILE *stream)
Returns s, or NULL if error.
FGETPOS
int fgetpos(FILE *stream, fpos_t *ptr)
Records current position in 'stream' in '*ptr'.
FOPEN
FILE *fopen(const char *filename, const char *mode)
modes: "r" read only
"w" write; discard previous contents
"a" append
"r+" read and write
"rb" read (binary)
"wb" write (binary)
"ab" append (binary)
"r+b" read and write (binary)
FPRINTF
int fprintf(FILE *stream, const char *format, ...)
Returns number of characters printed, or negative result if error.
Conversion specification begins with '%' and ends with conversion
character. In between, there may be (in order):
flags:
'-' left justify
'+' print with sign
' ' <space> prefix with space if no sign
'0' <zero> specifies padding with leading zeros
'#' alternate output form
numbers:
n first number specifies field width
'.' period used as separator
n second number specifies precision (max characters)
m modifier (h - short, l - long, L - long double)
format characters:
d,i int; signed
o int; unsigned octal (without leading zero)
x,X int; unsigned hexadecimal
u int; unsigned
c int; single character
s char *; string
f double;
e,E double; scientific notation
g,G double; %e or %f format, depending on value
p void *; pointer
n int *; number of characters written so far
% no argument, print '%'
example:
fprintf( myFilename, "The results are %d and %6.2f\n", myInt, myReal);
FPUTC
int fputc(int c, FILE *stream)
Returns c, or EOF if error.
FPUTS
int fputs(const char *s, FILE *stream)
Returns non-negative result, or EOF if error.
FREAD
size_t fread(void *ptr, size_t size, size_t nobj, FILE *stream)
Reads from 'stream' into 'ptr' at most 'nobj' objects of size 'size'.
Returns number of objects read.
FREOPEN
FILE *freopen(const char *filename, const char *mode, FILE *stream)
Returns NULL if error.
FSCANF
int fscanf(FILE *stream, const char *format, ...)
Reads from 'stream' and assigns values through subsequent arguments which
must be pointers. Returns EOF if end of file occurs before any
conversion; otherwise it returns number of items assigned. Format string
should contain conversion specifications consisting of '%' followed by:
flag:
* suppression; ignore field
number:
n first number specifies maximum field width
width character:
h short
l long
L long double
conversion characters:
d int *
i int *; may be octal (leading 0) or hexadecimal (leading 0x)
o int *; octal integer
x int *; hexadecimal integer
c char *; characters
s char *; string of non-white characters
e,f float *; could also use 'g'
p void *; pointer
n int *; writes into arg number of characters read. Nothing read.
FSEEK
int fseek(FILE *stream, long offset, int origin)
Sets file position. Values for origin can be:
SEEK_SET beginning
SEEK_CUR current position
SEEK_END end of file
FSETPOS
int fsetpos(FILE *stream, const fpos_t *ptr)
Positions 'stream' at position recorded by fgetpos. Returns non-zero if
error.
FTELL
long ftell(FILE *stream)
Returns current position for 'stream', or -1L if error.
FWRITE
size_t fwrite(const void *ptr, size_t size, size_t nobj, FILE *stream)
Writes from 'ptr' to 'stream' 'nobj' objects of size 'size'. Returns
number of objects read.
GETC
int getc(FILE *stream)
Same as fgetc, except a macro.
GETCHAR
int getchar(void)
Equivalent to getc(stdin).
GETS
char *gets(char *s)
Returns s, or NULL if error.
PERROR
void perror(const char *s)
Prints error message 's'.
PRINTF
int printf(const char *format, ...)
Equivalent to fprintf(stdout, ...)
PUTC
int putc(int c, FILE *stream)
Same as fputc, except a macro.
PUTCHAR
int putchar(int c)
Equivalent to putc(c, stdout).
PUTS
int puts(const char *s)
Returns non-negative result, or EOF if error.
REMOVE
int remove(cost char *filename)
Returns non-zero if attempt to delete file fails.
RENAME
int rename(const char *oldname, const char *newname)
Returns non-zero if attempt to rename file fails.
REWIND
void rewind(FILE *stream)
SCANF
int scanf(const char *format, ...)
Identical to fscanf(stdin, ...)
SPRINTF
int sprintf(char *s, const char *format, ...)
Same as printf except output written to string 's'.
SSCANF
int sscanf(char *s, const char *format, ...)
Equivalent to scanf(...) except input is taken from 's'.
SETBUF
void setbuf(FILE *stream, char *buf)
If 'buf' is NULL, buffering is turned off, otherwise equivalent to 'void
setvbuf(stream, buf, _IOFBF, BUFSIZE)'.
SETVBUF
int setvbuf(FILE *stream, char *buf, int mode, size_t size)
Returns non-zero if error. A value of NULL for 'buf' allocates buffer.
modes: _IOFBF full buffering
_IOLBF line buffering
_IONBF no buffering
TMPFILE
FILE *tmpfile(void)
Returns NULL if error.
TMPNAM
char *tmpnam(char s[L_tmpnam])
tmpnam(NULL) creates unique filename. TMP_MAX different names guaranteed.
UNGETC
int ungetc(int c, FILE *stream)
pushes 'c' (converted to an unsigned char) back onto 'stream'. Returns
'c' or EOF if error.
VPRINTF
int vprintf(const char *format, va_list arg)
VFPRINTF
int vfprintf(FILE *stream, const char *format, va_list arg)
VSPRINTF
int vsprintf(char *s, const char *format, va_list arg)
-2
->Anthony,
>
> I just added further support for repeat to Velocity. As I already
>mentioned Velocity is not that speedy (you won't guess whence the name
>comes),
I might have to steal that name once I get the JITC working.
>and thus it took 11 ticks to tokenize the repeat script you sent me
Are you tokenizing by hand? I don't know how one could tokenize that slow.
I really don't; I'm not being sarcastic.
>and 83 to run it with 10 times instead of the 100000 you had in there.
What kind of tokenized language are you using?
>That's on a 5300/90.
>
> I don't want to ask what Yacc/Bison can get out of this as I know it'll be
>much faster.
That's what my interpreter uses ... and I should note that I've not yet
found a measurable tokenization time.
>
> BTW, what're you doing your tests on?
PowerBase 200, PID7v603e @ 200MHz. 48MB RAM, 96 with VM. MacOS 8.1.
Compiled by MrCpp. But I bet I can beat THAT test with a...hmmm... Mac Plus.
-3
->>Are you tokenizing by hand? I don't
know how one could tokenize that slow.
>>I really don't; I'm not being sarcastic.
>
>Anthony,
>
> hey! I already said that Velocity isn't speedy! Hello? hellllo? It's just
>a study. And maybe a little tool for whatever I find it useful. And it
>supports the complete HyperTalk syntax with a little drop-in additions (but
>the basics are already finished).
>
>>>and 83 to run it with 10 times instead of the 100000 you had in there.
>>What kind of tokenized language are you using?
>
> Hmmm... you know, at least my code was written 100% by myself and not by
>some compiler-compiler -- Sorry, don't really mean it. But please defer
>picking on me until you wrote your first own HT compiler/interpreter
>completely by hand. Ok?
The actual code executor is completely by hand. Only the tokenizer is done
with a tool. And the JITC is really driving me crazy. Ever typed in simple
functions to generate PPC instructions? With all the simplified mnemonics,
I bet there's over 300.
>
>>That's what my interpreter uses ... and I should note that I've not yet
>>found a measurable tokenization time.
>
>Of course! Yacc and the likes have been optimized to create the best code.
>Oh, one consideration: Do you already have an idea how you're best going to
>support things like "the number of card buttons" ?
Strings must be quoted or not be a keyword. Thus, buttons would be parsed
as the keyword, and the proper PPC code would be generated to TVector to
the button counter. I'm even tempted to say unquoted strings are a syntax
error. I'll at least probably spit out a warning.
>There's lots of possible
>parsing errors in there (just imagine you had a card named "buttons" and
>everything falls into place, right?). Just to show off: Velocity has
>everything needed to handle that already built-in. Just create an entity
>named "card buttons" and register it.
>
>>> BTW, what're you doing your tests on?
>>PowerBase 200, PID7v603e @ 200MHz. 48MB RAM, 96 with VM. MacOS 8.1.
>>Compiled by MrCpp. But I bet I can beat THAT test with a...hmmm... Mac Plus.
>
>Certainly not. There's a slight difference between 200, 90 and 8 MHz.
There's an even bigger difference between 80 ticks for 10 and 60 ticks for
100000. My calculations show that the difference is too big for my TI-83 to
handle <veg>.
>
>But now I'll stop whining about how bad my interpreter is (and I'll also
>stop picking on you just because I don't have anyone else to blame).
I'd suggest it's time to optimize :)
>How
>far is your JIT?
Well, most of the work is typing in PPC instructions. I've got most of that
done now, and don't plan to go to bed until I have a timetest on the @#^&#
thing.
I also plan to complain to AIM: Why the heck have a bnl (branch not less
than) and a bge (branch greater than or equal) -- they are, both
logicalally AND machine-code wise, identical.
One thing I do plan on looking into is getting the JITC closer to a real
compiler. Currently, as planned, compiled code could be saved. However,
it's pretty darn unoptimized. If I were to compile once at save time, would
I be justified if I took 5 seconds to do so? If doing so made it run 5
times faster?
-4
->If I were to compile once at save time,
would
>I be justified if I took 5 seconds to do so? If doing so made it run 5
>times faster?
Anthony,
If you can easily make compiling optional, each user can make the choice
that suits him/her best.
Rob Cozens, CCW
-5
-Happy Easter All,
Has the group discussing OC UI design considered constructing a HyperCard
prototype? Once the basics are set up, it would be something we all could
work with, evaluate, and fine tune.
Rob Cozens, CCW
-6
-<<Has the group discussing OC UI design
considered constructing a HyperCard
prototype? Once the basics are set up, it would be something we all could
work with, evaluate, and fine tune.
>>
Actually, I would rather that UI was done last. Our goal is to make
an OpenCard that can be adapted for many uses, a plugin for netscape
navigator, an xTalk for clarisworks, you name it. For that reason, the UI is
defined by the programmers using the engine, not by us.
After the xTalk engine is finished, UI should be what we focus on.
-7
->After the xTalk engine is finished, UI should be what we focus on.
Why wait? (I thought a group had already been formed to work on UI design.)
>the UI is defined by the programmers using the engine, not by us.
They have to have a starting point. Surely we're not going to say, "Here's
the OpenCard interpreter; now go write your own interface."
Rob Cozens, CCW
-8
-> Happy Easter All,
Happy Easter
> Has the group discussing OC UI design considered constructing a HyperCard
> prototype? Once the basics are set up, it would be something we all could
> work with, evaluate, and fine tune.
I don't think we have one. It is everybody's job to design the UI not the
programmers as I see it. It has been quiet here lately. Is everybody
hibernating?
Andre
-9
-I think it is time we had an IRC meeting.
Does anybody have a channel we
could use?
How does 9:00PM (GMT) next Saturday suit everybody? That's 8:00AM Sunday for
me in Melbourne and about 4:00PM Saturday in New York.
Andre
-10
->>I also plan to complain to AIM: Why the
heck have a bnl (branch not less
>>than) and a bge (branch greater than or equal) -- they are, both
>>logicalally AND machine-code wise, identical.
>
> Maybe that got in there when they were testing their quality control
>department?
They don't have one of those. Consider 8-57, PEM, "eciwx":
"EA must be a multiple of four. If not one of the following occurs:
"* A system alignment exception is generated
"* A DSI exception is generated (possible only if EAR[E]=0)
"* The results are boundedly undefined
Boundedly undefined is defined as:
"[the results are] constrained to ones that could of been achieved
by executing an arbitrary sequence of defined instructions, in
valid form, starting in the state the machine was in before
attempting to execute the given instruction." [gloassary]. Another
simular one is given on 4-4, "4.1.3.1 Definition of Boundedly
Undefined".
So, let's see here. The results can be boundedly undefined when EAR[E]=1,
and boundedly undefined can generate a DSI exception. But this contradicts
"possible only if EAR[E]=0". Grrr.. It gets worse. _One_ is allowed, and
yet boundedly undefined could also easily cause a system alignment
exception. Yet that contradicts the seperate listing of the first bullet.
WTF happens if it's not a multiple of four? Does the microprocessor blow up
>from this logical problem?
Also, they have quite a few partial references to the 64-bit version, but
they're complete only to the extent of confusing the reader.
>
>>If I were to compile once at save time, would
>>I be justified if I took 5 seconds to do so? If doing so made it run 5
>>times faster?
>
> It shouldn't be the general case, but if you're talking about some
>optimizer that post-processes the code, there's nothing against it, as long
>as it can be left out when executing "do" commands. And it should happen in
>a separate thread, which would allow writing scripts in a way that works
>around this delay when using scripts.
The idea is that all scripts would be compiled and stored in compiled form.
Source would be stored as well. Of course, do would be tokenized/compiled
as fast as possible.
>
> OTOH we could add a command for that, "optimize code". Then, our editing
>environment would call this whenever you close the script editor if you
>turned on an option. This way, scripts that need to run instantly would
>work fine (e.g. a script creates a new finder icon and gives it a script --
>that should work instantly, if maybe a bit slower, but there mustn't be a 5
>sec delay).
A script would only need be compiled once. No need to recompile. And, of
course, short scripts would be faster compiling.
--------------------------------End OpenCard--------------------
