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