ENIGMA Forums

General fluff => Announcements => Topic started by: Josh @ Dreamland on October 21, 2009, 07:38:22 pm

Title: Progress
Post by: Josh @ Dreamland on October 21, 2009, 07:38:22 pm
I have successfully implemented 90% of everything, and am working on the rest of the ten percent as I attempt to parse system headers.

Let me tell you, I'm surprised. Those coders managed to write headers that have attitude. These things are sentient, angry source codes, and they don't like new parsers. Honestly, the things are some sort of intelligent. They have to be.

Code: [Select]
Including file from features.h
Including file from sys/cdefs.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
...Repeats past max SMF character limit...
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Including file from sys/cdefs.h
Including file from features.h
Parse time: 1340 milliseconds

Line 330, position 25: Failed to include sys/cdefs.h: File not found
Macros (44):
  _ATFILE_SOURCE: 1
  _BSD_SOURCE: 1
  _FEATURES_H: 1
  _ISOC99_SOURCE: 1
  _LARGEFILE64_SOURCE: 1
  _LARGEFILE_SOURCE: 1
  _POSIX_C_SOURCE: 200112L
  _POSIX_SOURCE: 1
  _SVID_SOURCE: 1
  _SYS_CDEFS_H: 1
  _XOPEN_SOURCE: 600
  _XOPEN_SOURCE_EXTENDED: 1
  __FAVOR_BSD: 1
  __GLIBC_HAVE_LONG_LONG: 1
  __GLIBC_MINOR__: 9
  __GLIBC_PREREQ(maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min): \
        ((__GLIBC__ << 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
  __GLIBC__: 2
  __GNUC_PREREQ(maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min,maj,min): 0
  __GNU_LIBRARY__: 6
  __KERNEL_STRICT_NAMES: #endif
  __STDC_IEC_559_COMPLEX__: 1
  __STDC_IEC_559__: 1
  __STDC_ISO_10646__: 200009L
  __USE_ANSI: 1
  __USE_ATFILE: 1
  __USE_BSD: 1
  __USE_FILE_OFFSET64: 1
  __USE_FORTIFY_LEVEL: 0
  __USE_GNU: 1
  __USE_ISOC95: 1
  __USE_ISOC99: 1
  __USE_LARGEFILE: 1
  __USE_LARGEFILE64: 1
  __USE_MISC: 1
  __USE_POSIX: 1
  __USE_POSIX199309: 1
  __USE_POSIX199506: 1
  __USE_POSIX2: 1
  __USE_REENTRANT: 1
  __USE_SVID: 1
  __USE_UNIX98: 1
  __USE_XOPEN: 1
  __USE_XOPEN2K: 1
  __USE_XOPEN_EXTENDED: 1

Variables:auto:   Serves as typename
bool:   Serves as typename
char:   Serves as typename
const:   Serves as typename
double:   Serves as typename
float:   Serves as typename
int:   Serves as typename
long:   Serves as typename
register:   Serves as typename
short:   Serves as typename
signed:   Serves as typename
static:   Serves as typename
unsigned:   Serves as typename
volatile:   Serves as typename

The best I can make of that output is that somewhere along the line, I had too many files open.
...Fixed. Now it loops forever like... like it should, I suppose.

I know the error is because I forgot to share my macro function implementation with the expression evaluator, and will fix that next. I just thought I'd share the O___o moment and the news that the basics are al(most)l working.
Title: Re: Progress
Post by: Micah on October 22, 2009, 05:28:44 pm
Using a recursive descent parser or lex and yacc would have been incredibly faster and easier to write and more memory-efficient, not to mention you wouldn't have errors like that.
Title: Re: Progress
Post by: Josh @ Dreamland on October 22, 2009, 07:03:55 pm
For the fifteenth time, go for it. Show us all how fast and easy it is to write. Outdo me.

Quote
<JoshDreamland>   Out of curiosity, what parser generator was GCC made in?
<segher>   none
<segher>   both C and C++ use a hand-written parser
<segher>   dunno about fortran and ada
<segher>   (much) older versions of GCC used a bison parser
<segher>   the hand-written parser is much smaller and faster than the old bison parser; more importantly though, it allows for much better diagnostics on errors
...
<segher>   oh, bison is nice for small parsers
<segher>   then again, most jobs i need small parsers for i would do in perl or haskell :-)

Why don't you write it in Perl or Haskell, also?
Title: Re: Progress
Post by: Micah on October 22, 2009, 07:15:58 pm
I'm actually writing a lexer and parser in Haskell at the moment. :P And the lexer was 17 lines, and very easily modifiable and simple.

And the problem with your citation of gcc's handwritten parser is that I'm sure they used a recursive descent parser (which is a lot like writing a grammar actually, only it's real code), while yours is just a mash.

I'll just drop this now, because I don't feel like writing a parser for ENIGMA, and yours will probably work just fine.
Title: Re: Progress
Post by: Josh @ Dreamland on October 22, 2009, 07:31:07 pm
So, you've dropped the yacc idea and any resulting simplicity and have moved on to wanting a recursive descent model. My original syntax checker resembled one, actually; It had a file full of inline'd functions that would each do simple error checking. Examples being must_follow_operator(), and expect_semicolon(). I hated it, and later scrapped the entire thing, mostly because it's nice to see all the code (or at least a lot of it) in one place.

Also, I later realized how much simpler it is if you do such checking only when necessary, especially for GML. Since a semicolon is almost never expected, it made no sense to skip one each time.
Title: Re: Progress
Post by: RetroX on October 22, 2009, 07:41:24 pm
I made an expression parser ("2   +    2" returns 4, etc.) in ~500 lines.  At first, I added a clock() to see how fast it was.  Even if I execute twenty very long expressions, I still can't get the milliseconds counter to go above zero with the limitations of a long double and clock().
Title: Re: Progress
Post by: Micah on October 22, 2009, 07:59:18 pm
So, you've dropped the yacc idea and any resulting simplicity and have moved on to wanting a recursive descent model.
Actually, I didn't drop the yacc idea. I was just saying that there are researched ways to write a handmade parser that work very well.

RetroX: I'm interested in seeing how you did that.
Title: Re: Progress
Post by: Josh @ Dreamland on October 22, 2009, 08:03:02 pm
Clock() isn't accurate enough on Linux.
Title: Re: Progress
Post by: IsmAvatar on October 22, 2009, 08:41:20 pm
use time(0) rather than clock(). clock tends to only update once every few seconds on unix. I noticed this when I seeded my random number generator with it and noticed that it would repeatedly generate the same sequence for a while.
Title: Re: Progress
Post by: Micah on October 22, 2009, 09:36:51 pm
Speaking of seeding random numbers, on OSX Tiger (I don't know about this any other versions), you can move the mouse into the lower right corner to go into a screensaver. If there are multiple computers with synchronized clocks, you can move the mouse into the lower right corner at the same time on each of them, and if you are using the slideshow screensaver and the same set of images, it will show them in the same order forever. :D
Title: Re: Progress
Post by: RetroX on October 23, 2009, 04:20:02 pm
Clock() isn't accurate enough on Linux.
Yes, it is.  If you have the right kernel settings.
Title: Re: Progress
Post by: Micah on October 23, 2009, 06:08:01 pm
Not everyone does, so do you really think it's a good idea to write production code that needs Clock() to be that accurate?

I don't know why you have to defend every single thing about Linux, especially when it's questionable whether they're criticisms or not.
Title: Re: Progress
Post by: RetroX on October 24, 2009, 11:09:12 am
Not everyone does, so do you really think it's a good idea to write production code that needs Clock() to be that accurate?

I don't know why you have to defend every single thing about Linux, especially when it's questionable whether they're criticisms or not.
The kernel and shell themselves will work properly by default with clock().  If it doesn't work in Ubuntu, it's Ubuntu.  I hate how people use Ubuntu for making complains about GNU/Linux in general.  It modifies everything.
Title: Re: Progress
Post by: Game_boy on October 24, 2009, 12:24:05 pm
Ubuntu is how most people will see Linux when they try it, and how most people will be running and reviewing Linux applications. It may not be the fault of the kernel programmers but they need to share some responsibility for fixing it in Ubuntu [if it needs to be fixed] by communicating with their kernel developers or issuing a patch to reverse/mitigate the change Ubuntu makes.

For example, the NT kernel by itself is lightweight, portable and designed well. But the vast majority of users only see it in Windows, and would assume it is slow, bloated and locked-in to x86. So it is irrelevant how good the kernel is or how it's meant to function.
Title: Re: Progress
Post by: Josh @ Dreamland on October 24, 2009, 12:27:14 pm
I'm currently on Ubuntu myself, as it's the only distro I can boot with my card, as stated. Can't wait 'til my Fedora-oriented clock()-based FPS regulator stops working.
Title: Re: Progress
Post by: skarik on October 26, 2009, 09:58:30 am
So that means R4 will definitely have a Linux version, right? I'd love it if there were, as I'm totally stuck on Ubuntu, and the only things I can get working with WINE are Portal and Far Cry 2.

And what the hell is that error up there?
Title: Re: Progress
Post by: Josh @ Dreamland on October 26, 2009, 08:06:00 pm
That error was extinguished a long time ago. Now I'm moving on to complete support for the rest of the language. (The little bit I have not yet implemented)

Also, yes, definitely a Linux version, as that's the operating system I'm on. I will, however, boot into Windows to make sure DLLs work.
Title: Re: Progress
Post by: skarik on October 27, 2009, 12:07:37 am
That's absolutely awesome.

Well, I'm wondering if I could tell the Game Design Club at my high school that I found a free alternative to Game Maker or what? Should I wait?
Title: Re: Progress
Post by: Josh @ Dreamland on October 27, 2009, 07:55:08 am
Just for a little bit.
Title: Re: Progress
Post by: RetroX on October 27, 2009, 02:22:53 pm
Just entirely curious, what is the point of DLLs?  I mean, it's useful in Linux/UNIX to have libraries so that you don't have to have twenty copies because twenty programs that use it, but why would you care in Windows, since they're always included, anyways?
Title: Re: Progress
Post by: luiscubal on October 27, 2009, 03:16:56 pm
DLLs are a practical way to split your executable into multiple files.
Title: Re: Progress
Post by: RetroX on October 27, 2009, 03:40:57 pm
DLLs are a practical way to split your executable into multiple files.
The point of which is...?
Title: Re: Progress
Post by: Josh @ Dreamland on October 27, 2009, 04:22:31 pm
What he meant by that was, DLLs are a practical way to use code you don't understand that runs fast in GM. In ENIGMA, the only point to having them is because people are set in their 39Dll-loving ways.
Title: Re: Progress
Post by: luiscubal on October 27, 2009, 05:45:50 pm
If you release an update, for example, you can just change the modified DLLs, rather than the whole thing!
Title: Re: Progress
Post by: Josh @ Dreamland on October 27, 2009, 07:29:58 pm
Code isn't supposed to be all that big. If you want small updates, make your resources external, not your code.
Title: Re: Progress
Post by: skarik on October 27, 2009, 10:14:03 pm
Quote
In ENIGMA, the only point to having them is because people are set in their 39Dll-loving ways.
Or because it's easier to copy and paste GML that somebody already made instead of manually handling the function pointers.
Though, I think that reason has nothing to do with the reason that somebody originally gave.

Anyhow, I checked with my 'superiors,' and it looks like the Game Design Club will be using Enigma at some point over here!
Title: Re: Progress
Post by: notachair on October 27, 2009, 11:32:32 pm
Quote
In ENIGMA, the only point to having them is because people are set in their 39Dll-loving ways.
Or because it's easier to copy and paste GML that somebody already made instead of manually handling the function pointers.
Though, I think that reason has nothing to do with the reason that somebody originally gave.

Anyhow, I checked with my 'superiors,' and it looks like the Game Design Club will be using Enigma at some point over here!
I don't think this is a good time to make such a recommendation...
Title: Re: Progress
Post by: Josh @ Dreamland on October 28, 2009, 04:13:45 pm
NONSENSE! MAHAHAHAHHAHAHAHAHAHAHA *filinaeny goes off daep edn*
Title: Re: Progress
Post by: Rusky on October 28, 2009, 09:43:44 pm
Code isn't supposed to be all that big. If you want small updates, make your resources external, not your code.
What the crap? Why isn't code supposed to be big? Ever seen the Linux kernel you all love so much?

DLL's are great. They're used for the same reason in Windows as in UNIX, although with GM games the libraries are included with all the programs anyway. But even in that situation, they still offer advantages. If you already have code written in another language that you want to port to GM, you can just write a layer for GM compatibility.

In ENIGMA, you could of course just statically link it, but static linking is ugly. Dynamic linking means updates to just the library (which do make sense, especially if it's a third party library) can be made without redistributing the entire thing. Dynamic linking also lets you interface with code written in tons of languages, not just the one you're writing the main program in.
Title: Re: Progress
Post by: luiscubal on October 29, 2009, 06:24:27 am
Also, DLLs mean you can use LGPL code in your closed source library, which static libraries do not allow.
Title: Re: Progress
Post by: Josh @ Dreamland on October 29, 2009, 07:30:47 am
Rusky--

You're comparing the size of an OS to the size of a game. How the hell often do you need to update a GM sized game?

There's no doubt DLLs are good in other cases. It's why most people are content to use SDL's ten DLLs instead of statically linking. But, ENIGMA is designed to be all-in-one, like GM. (Although GM does include a DLL in its actual runner, you can't see it, so it looks less messy).

Which reminds me, you say static linking is ugly... Static linking produces one standalone executable. I always liked my games to be standalone; means I can just drag one item over without fear of missing a DLL. Dave used to send me projects of his in all sorts of different libraries. First SDL, then Ogre... There were others I can't remember. Each time, I'd need him to send five different DLLs until it worked. He'd send two he could remember at a time, but it's still not very convenient.

Ideally, yes, it's good to be able to update large projects without having to redownload all the compiled code. A whole damn operating system is a great example of that, as I can scarcely think of one operating without it.

They are also useful in extensibility, such as Pidgin's plug-ins.

How many GM games honestly require DLLs for that purpose? GM would not make it that hard to do, actually, but I've never seen an instance where that was even implemented, much less required. Not to mention, one in every two hundred million people on the GMC knows any DLL-ready language. So having a well-used plugin system is unlikely.

At its prime, in a community full even moderately capable C++ programmers working on things other than games, are DLLs useful? Oh, certainly. In a community full of developers who rival companies like Valve (who externalize everything), are DLLs useful? Yes. On a forum whose immediate intended population has twenty people that know C++ and are willing to contribute code to everyone that does not, are DLLs all that useful? No more than static linking.

Luis--
Those who develop specifically for ENIGMA can bear that in mind for later. For now, all GM DLLs can be assumed to be closed source and of course are not static, which is basically the only reason external_define() exists. A lot of the better GM DLLs are open source anyway, if only poorly so. Like 39Dll. Source is included, no license.
Title: Re: Progress
Post by: Rusky on October 29, 2009, 08:03:09 am
There's still third party libraries like Ultimate3D or 39DLL that can give updates without needing recompilation, no matter how all-in-one your tool is.
Title: Re: Progress
Post by: Josh @ Dreamland on October 29, 2009, 02:30:58 pm
Funny how both you named are no longer under development, last I checked.
Title: Re: Progress
Post by: RetroX on October 29, 2009, 03:20:03 pm
What the crap? Why isn't code supposed to be big? Ever seen the Linux kernel you all love so much?
I think you forgot that you were talking to Josh and not me.

pages hate me
Title: Re: Progress
Post by: score_under on October 29, 2009, 03:31:28 pm
DLL/SO support would be very useful, and not only because on Linux most of a program resides in the SO files it links to.
It would, for example, allow you to use the Scintilla library without having to hack all the code into your project. It also means less compile time.

However, 39DLL is a piece of crap and I've even had people ask me how to load it in a C++ project. I have to explain every time that it's just Winsock API calls wrapped for Game Maker.
Title: Re: Progress
Post by: luiscubal on October 29, 2009, 05:35:17 pm
I really don't think you could use the Scintilla library on Linux since it is based on GTK+.
Title: Re: Progress
Post by: Josh @ Dreamland on October 29, 2009, 07:33:38 pm
;_________; ?

And yes, but that's true for static linking as well. Assuming that's an easy option with Scintilla. Can't really think why a game would want a Scintilla interface...
Title: Re: Progress
Post by: Rusky on October 29, 2009, 08:38:51 pm
For a script console with syntax highlighting.
Title: Re: Progress
Post by: Josh @ Dreamland on October 30, 2009, 05:36:48 am
Mmm, to run with execute_string(), assuming I ever feel like implementing it?
Or maybe they'll include GCC with their game like ENIGMA does, who knows?
Title: Re: Progress
Post by: Rusky on October 31, 2009, 04:51:19 pm
Or maybe they'll embed another scripting language like Lua or Python. Both of which would use DLL's.
Title: Re: Progress
Post by: kkg on November 02, 2009, 08:04:48 am
Sounds like this'll be a project to keep an eye on. I might wait till R4 comes out before I check it out though, as I've seen some posts already saying that some mainly used functions (eg collision) are not entirely implemented yet.

and I lol at the posts because im a 39dll whoooore. Any recommendations for networking systems (ignore my attempts to be technical :( ) that are cross platform? I'd like to think that I'm not restricted to Win32/64 :(

Anyway, the hard work looks like it's paying off, I shall check back in a few days! ^.^

btw Josh, i'm Consoft at the GMC if you remember me from all those years ago when you posted that D&D Online LIB that i made some cheap ass platform example for :P haha
Title: Re: Progress
Post by: Josh @ Dreamland on November 02, 2009, 09:07:57 pm
Yes, I do remember you. You were the one that helped answer questions on that topic I since stopped supervising. Wow, that was a long time ago.
I hope at some point to implement a system for updating variables that comes across as easily as that library did.

And yes, waiting for R4 would be a good idea, I believe.