| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
Comments:
<0> Ox41464b, thanks, that was what I needed.
<1> yeah, never mind the fact that I gave you the name of the function
<2> so anyone care to share the meaning of "<?" ... TML made it sound like something vital
<3> howard... err.. thats not for you, file_get_contents() is for you
<4> Artnez: It's the signifier for "processing instruction" in numerous systems, including SGML and XML
<2> TML: I see, thanks.
<4> Artnez: <?(some identifier to tell which system to process this block) (a block) ?>
<4> So <?php ... ?>, or <?xml ... ?>, or <?python ... ?>
<2> ah, understood
<2> i should have rtfm more carefully
<5> when you print_r($some_array);
<5> what the fark does Resource ID #4 mean?
<1> it means it contains a resource id.
<5> which means/
<1> probably a file handle, or something similar.
<6> does php have pointers like c?
<7> callipygous: which means something that cannot be easily represented with primitive data types. like a database connection handler
<1> no
<6> oh okay
<5> okay, but why do I get retarded line numbers
<5> Parse error: syntax error, unexpected ')', expecting ';' in /Users/callipygous/work/ANTA/site/admin.php on line 30
<5> the error isn't on line 30
<4> callipygous: Yes it is.
<1> callipygous: because you don't understand what a parse error is
<4> callipygous: It's not a parse error until the parser reaches line 30.
<1> callipygous: parse errors indicate where language parsing fails. not where you screwed up.
<8> heh
<9> there's no spellchecker in php :)
<1> luu: there are bindings to aspell and pspell
<1> :)
<9> err.. thats kinda not what I meant
<9> :P
<5> i understand
<1> ok, so what did you mean?
<5> except
<5> why would the parse error occur BEFORE the actual error?
<1> callipygous: I doubt that it did.
<9> I meant its only those semi-cool programmers that use like c/c++ and such that need compilers to do spellchecking for them :P
<9> we just get a parse error and need to figure out the bugs on our own
<9> so we're kewl
<1> luu: compilers do not spell check
<5> well the problem is around line 50
<9> yes they do, now shhhhh
<5> but its saying it coccured line 30
<1> callipygous: show me the code.
<9> callipygous when looking for parse errors, always look up. don't look down. you can deal with those parse errors later
<4> luu: Which C compiler are you using that has a spellchecker?
<1> luu: and no, they do not. a symbol either exists, or it doesn't. it's not like a compiler is going to try to guess what you mean.
<5> luu, look up?
<7> callipygous: yes, the prob is before line 30
<9> callipygous yes.
<1> *on or before line 30
<7> most probably before
<1> without the code, nobody can confirm that
<5> nope, its after line 30
<7> callipygous: show us the code
<5> ok
<5> but ive pretty much fixed it
<7> you're still having that line 30 parse error right? show it.
<1> aparently the code is too top secret
<1> heh
<5> deadroot, no, im not
<5> i fixed it, the problem was at line 53
<1> mazzanet: again? that'd be the third time this week
<5> but I pastebin'd it before I fixed it
<5> http://pastebin.com/574543
<10> if isset($_POST) isn't true, does that mean there was nothing posted or there aren't any posted variables with value?
<8> OH MY GAWD!
<4> callipygous: Something's wrong with your OS if that reported a parse error at line 30.
<5> isn't any posted ( or its supposed to)
<5> TML, something is wrong with somethign
<1> raar: an empty array will return true through isset()
<10> ah alright, thanks!
<5> this is why ive been complaining, yep
<5> nothing on line 30
<7> very weird
<4> callipygous: Right, and I told you *which* something is at fault: The OS
<1> callipygous: I'd be tempted to say you're not even looking at the right file.
<5> caffinated, i know I am
<5> TML, okay, but how?
<5> i mean, what part of the OS.. it was error reporting fine last thursday
<7> callipygous: what was the problem that you fixed at 53?
<7> the mysql_results?
<4> callipygous: I would guess that you're throwing it mixed line endings, but that's a wild, wild guess.
<5> deadroot, yeah
<5> hmm possibly!
<5> I just checked
<5> usually I'd create a file using 'touch'
<5> but sometimes I use this mac os finder replacement, 'path finder
<5> i just looked in vim, and the filetype is "mac"
<5> not my usual unix
<7> i doubt that is the cause
<5> it shouldn't be
<4> Actually, it is
<7> it is?
<4> At least, it's certainly going to cause problems with counting line numbers
<5> wouldn't doubt it
<4> That may not be the *only* problem, but that *would* throw off your OS' ability to count lines.
<7> why would php ask the OS how many lines is it?
<4> deadroot: Who else would PHP ask? The developer?
<7> how about itself?
<4> deadroot: And what facility do you think it uses? You think the PHP team re-wrote their own fopen() and fread(), or do you suppose the used the ones provided by, oh, let's see, the *OS*?
<7> okay
<8> I'd say the php team
<4> Jymmm: For once, you'd be wrong
<8> Sometimes, they aint the sharpest tool in the shed.
<2> blasphemy!
<8> Reality
<11> does anyone know of a php script that would parse through a css file and invert all the hex values?
<5> I would say - ask them
<7> but it's kinda silly for the OS to be thrown off by line counting errors
<7> there's only three types of line endings
<4> deadroot: And each OS only supports its own
<8> deadroot: and M$ onlt knows it's own
<5> then... umm
<4> deadroot: With the slight exception that Windows line endings happen to *contain* Unix line endings.
<5> if I'm using filetype "mac" on a mac, shouldn't my OS know its own filetype?
<8> deadroot: Becasue it's been told to.
<5> unix filetypes work fine with php
<4> deadroot: Because the editor wrote their own facilities overtop the OS ones that provide that feature.
<7> TML: and PHP does not do that?
<4> deadroot: No, why would it?
<4> deadroot: PHP isn't an editor.
<4> It doesn't *care* what line its on.
<7> to ensure that the line endings are correct, so that it can report the correct lines to the programmer to debug?
<4> deadroot: The amount of code required to provide something like that is disproportionate with the benefit.
<4> You're talking about roughly 30% of the source code in a given editor for something like that.
<4> The amount of overhead on the parser ALONE would invalidate the concept.
<12> I just compiled php-5.1.2 on RHEL4.
<4> And given that the number of people who edit files in a format OTHER than that belonging to their OS is so miniscule, it's just not worthwhile endeavor.
<7> okay
<12> ./configure --prefix=/usr/local/php-5.1.2 --with-mysql=/usr/lib/mysql
<12> make
<12> 'make test' reported three failures:
<4> hxu: That's wrong.
<4> --with-mysql=/usr/lib/mysql is almost certainly wrong
<12> Bug #16069 [ext/iconv/tests/bug16069.phpt]
<12> iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
<12> Bug #35785 (SimpleXML memory read error) [ext/simplexml/tests/bug35785.phpt]
<12> TML: What is wrong?
<4> hxu: Unless you have /usr/lib/mysql/lib/mysql/libmysqlclient.so, "--with-mysql=/usr/lib/mysql" is wrong.
<4> hxu: --with-mysql=$somepath looks for $somepath/include/mysql.h and $somepath/lib/libmysqlclient.so
<4> I don't understand why no one can grasp this concept
<12> TML: My mysql.h is in /usr/include/mysql.
<2> TML: just out of interest: http://www.php.net/%7Ederick/meeting-notes.html#remove-support-for-and-script-language-php-and-add-php-var
<2> "We kill "<%" but keep "<?"."
<4> hxu: You're right, it looks for ($somepath/include/mysql.h | $somepath/include/mysql/mysql.h )
<12> TML: My libmysqlclient.a is in /usr/lib/mysql.
Return to
#php
or
Go to some related
logs:
#bind
centos free(): invalid next size (fast)
#web
cant create mcop directory
#physics
firestarter pptp help
#css
#ai
rsync -e ssh -ax
#ai
|
|