So let me get this straight, you wrote a C program to convert LISP code into BBCode code. What next, writing a Python interpreter in LISP in C to convert BBCode to Python in Python?
Name:
Anonymous2007-12-28 1:29
This actually isn't a bad idea
Name:
Anonymous2007-12-28 4:22
>>1
You're the man. Not a malloc in sight. Truly Enlightened C is winrar.
>>7
There are no mallocs only because he uses arbitrarily-sized buffers to hold the input and tag stack. And he didn't even make MAX_NESTING large enough to handle the total possible number of tags that MAX_POST_SIZE might contain. Not very enlightened.
peh, it'd be even faster to do in PERL with a couple regex's.
>>7
Hard-on for purely stack-allocated memory? I hope your fucking overly revered stack fucking overflows when you shit some nice large arrays on it because you were too fucking pussy to dynamically allocate them on the heap.
fuck.. excuse me in too stoned (defun bbcodeify (sexp) (cond ((atom sexp) sexp) ((listp sexp) (format nil "[~a]~{~a~^ ~}[~a]" (car sexp) (mapcar #'bbcodeify (cdr sexp)) (car sexp)))))
* (bbcodeify '(i (b this is bold and italic) and this just italic))
"[I][B]THIS IS BOLD AND ITALIC[B] AND THIS JUST ITALIC[I]"
Name:
Anonymous2007-12-28 12:44
>>11
DO IT IN PERL WITH A COUPLE OF REGEX THEN YOU ALL-TALK-BUT-CANT-WALK FAGGOT!!!!!
Name:
Anonymous2007-12-28 13:49
>>11 Hard-on for purely stack-allocated memory? I hope your fucking overly revered stack fucking overflows when you shit some nice large arrays on it because you were too fucking pussy to dynamically allocate them on the heap.
No, I have a hard-on for static arrays. I don't care much where the data is stored. I prefer global arrays, though. There is really little reason to use local variables. Multithreading, perhaps.
Name:
Anonymous2007-12-28 13:50
this thread is hilarious
Name:
Anonymous2007-12-28 15:40
OP here >>10
Only these two? I forgot more, intentionally.
(eg # or rem or br)
That's why I put that comment there.
Left it as an exercise to the reader :P
>>11 Hard-on for purely stack-allocated memory? I hope your fucking overly revered stack fucking overflows when you shit some nice large arrays on it because you were too fucking pussy to dynamically allocate them on the heap.
Too much of a fucking pussy?
Are you right on your mind you fucking moron?
Not only it would make the size of my code 3x bigger, do you want such snippet to eat 10MB from your memory because the programmer wasn't a pussy?
You're a moron, what I could have done is to read input in chunks, less than what it takes for my static stack to fill, parse, print on stdout and repeat.
No fucking need for (re)allocations.
>>12
Release code?
Do you see a licence there? Or my name? Or some makefile?
(why the fuck would anyone put a licence on that anyway)
What I wanted to do is write something that works in C in < 10 minutes, post it on /prog/ and see what code Anon would post.
(like your lisp snippet)
Your lisp snippet however takes the expression as a list, my snip takes it from stdin, there are advantages to my snip. (not that it would take a lot of code to change yours to do that)
>>15
Actually I see more reasons to use a local object than threads :P
C:\>gcc.exe foo.c -o a
foo.c:2:19: stdio.h: No such file or directory
foo.c:3:20: string.h: No such file or directory
foo.c:19: error: parse error before "size_t"
foo.c:19: warning: no semicolon at end of struct or union
foo.c:21: warning: data definition has no type or storage class
foo.c:23: error: parse error before '*' token
foo.c:24: error: parse error before '*' token
foo.c:25: error: parse error before '*' token
foo.c: In function `main':
foo.c:36: error: `size_t' undeclared (first use in this function)
foo.c:36: error: (Each undeclared identifier is reported only once
foo.c:36: error: for each function it appears in.)
foo.c:36: error: parse error before "n"
foo.c:50: error: `stack' undeclared (first use in this function)
foo.c:53: error: `stdin' undeclared (first use in this function)
foo.c:65: error: `NULL' undeclared (first use in this function)
foo.c:66: error: `stdout' undeclared (first use in this function)
foo.c:71: error: `n' undeclared (first use in this function)
foo.c:74: error: `stderr' undeclared (first use in this function)
C:\>
lol
Name:
Anonymous2007-12-28 17:31
>>21
Since you don't have stdio and string, what do you expect?
I bet you don't have the libc either.
Name:
Anonymous2007-12-28 17:40
module Language.BBCode.Parser
(parseBBCode)
where
import Language.BBCode
import Text.ParserCombinators.Parsec
bbcode = many (bbcodeElement <|> bbcodeText)
bbcodeElement = do element <- try bbcodeOpenElement
content <- bbcode
bbcodeCloseElement element
return (Element element content)
bbcodeOpenElement = do char '['
s <- many1 (oneOf "abcdefghijklmnopqrstuvwxyz_#*")
char ']'
return s
bbcodeCloseElement s = string ("[/" ++ s ++ "]")
bbcodeText = many1 (noneOf "[") >>= return . Text
parseBBCode bb = case parse bbcode "" bb of
Left e -> error $ show e
Right bs -> bs
>>24
I know, read my post: Your lisp snippet however takes the expression as a list, my snip takes it from stdin, there are advantages to my snip. (not that it would take a lot of code to change yours to do that)
Of course it doesn't. By the time any part of the compiler that cares about giving out warnings even gets to it, the preprocessor has already replaced all the #define'd macros.
Name:
Anonymous2007-12-29 1:10
OP here, the prototypes where left because I firstly implemented them as functions, also >>55 got it right.
>>65,66
Why, of course he can -- he's one of the undead, I think he uses OpenBSD.
Name:
Anonymous2007-12-31 3:32
~$ echo 'aids (b bolded (i (o bold o i) bold ita)(b double bold)(spoiler spoilered(b bold too)))(b this took me entirely too long(spoiler especially since I had to compile perl 5.10)(u and I now hate you for making me do it))' | /usr/local/bin/perl510 -p -ne 's/\(([boiu]|spoiler|code|br)\s(([^()]+|(?R))*)\)/\[$1\]$2\[\/$1\]/ while m/[()]/;'
aids [b]bolded [i][o]bold o i[/o] bold ita[/i][b]double bold[/b][spoiler]spoilered[b]bold too[/b][/spoiler][/b][b]this took me entirely too long[spoiler]especially since I had to compile perl 5.10[/spoiler][u]and I now hate you for making me do it[/u][/b]
aids bolded bold o i bold itadouble boldspoileredbold toothis took me entirely too longespecially since I had to compile perl 5.10and I now hate you for making me do it
Name:
Anonymous2007-12-31 11:07
EXPERT BBCODE SYSTEM (that supports parentheses by using
the FORCED INDENTATION OF CODE)
$ cat bbsexpr.pl
#!/usr/bin/perl -p0
0while(s#\(([^\s()]+)\s?(((\(\s)|((?<=\s)\))|[^()]+|(?R))*)\)#\[$1]$2\[/$1]#s);s/\( /(/g;s/ \)/)/g;
$ cat test
(b (i (o (u EXPERT BBCODE SYSTEM)) ( that supports parentheses by using
the (sup FORCED INDENTATION OF CODE) )))
$ cat test | perl bbsexpr.pl
[b][i][o][u]EXPERT BBCODE SYSTEM[/u][/o] (that supports parentheses by using
the [sup]FORCED INDENTATION OF CODE[/sup])[/i][/b]
>>76
Input file syntax is ugly. It breaks the "input op output" scheme that reads and combines easily. < test perl bbsexpr.pl is better but still confusing and unclean.
Name:
Anonymous2008-01-01 1:14
>>76
Considering that that's the exact same instruction written slightly differently, I'd say you're a faggot.
Name:
Anonymous2008-01-01 2:25
>>78
Considering you're a faggot, I'd say you're a faggot.
Name:
Anonymous2008-01-01 2:50
>>78
Uhm, I wouldn't say they're exactly the same. >>76's method doesn't have to fork-exec cat, which in itself is quite an expensive process.
There is still ``piping'' however (redirection boils down to a call to dup2, with stdin/stdout being duplicated to the file descriptor instead of a pipe)
Name:
Anonymous2008-01-01 7:08
>>74
What? I thought cat file.txt|less was the way to go. Sometimes I get so excited, I run less file.txt|less.