IRC Networks
Irc Logs Stats
Start date: 2007-09-27 02:48:27
Last update: 2008-10-24 20:19:38
Channels: 41
Logged Lines: 6230436
Size: 1982.48 MB
Powered by
Channel Info
Network: freenodeChannel: #php |
Search in www.irclog.org
Log from #php at freenode 2006-08-01
Pages: < Prev
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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
Next >
[20:31]<lzygv_z>No, that's coming from major nerds :-)
[20:31]<crgguggu>print_r, that really makes no sense that it becomes inneficient with "lots of code"
[20:31]<cznff9q>Emacs users, probably.
[20:31]<wrvve>afternoon everyone
[20:31]<crgguggu>print_r, even major nerds can be majorly wrong
[20:31]<tjufgg>inefficient in what way?
[20:31]<afnwnffyjvv>I agree with Crell42 :p
[20:31]<crgguggu>Crell42, then yo'ure ignorant
[20:32]<tjufgg>Measuring productivity is difficult
[20:32]<lzygv_z>Well, they say it's more convenient for small scriptlets that don't include many includes.
[20:32]<wrvve>anyone have experience with preg_match_callback?
[20:32]<afnwnffyjvv>I don't need a command to save my file with every character upside-down and in reverse order
[20:32]<mzwpv1m>Crell42: no. but you could use http. you could put the php scripts on various servers on the network running apache. the main program can then open the various php pages on these apache servers, get the results from the scripts, and use them.
[20:32]<lzygv_z>Hehe, this is turning into a #editor-debate.
[20:33]<mzwpv1m>Crell42: is that a normal or even good way to do things?
[20:33]<tjufgg>Dr1ft3d: Welcome to the wonderful world of web services.
[20:33]<cznff9q>That would be a waste unless the scripts are on another server.
[20:33]<tjufgg>Perfectly normal.
[20:33]<mzwpv1m>Crell42: they are
[20:33]<mzwpv1m>Crell42: they might be on a few servers
[20:33]<cznff9q>Then that could work.
[20:33]<cznff9q>You're then using HTTP as an RPC mechanism, which is not uncommon.
[20:33]<cznff9q>What's on each end, who cares.
[20:34]<cznff9q>The only reason not to would be if you wanted to use Java and RMI on both ends.
[20:34]<mzwpv1m>Crell42: how well? this is what i've thought of. the other dev says we should use tomcat, run java servlets on tomcat, use a java lib called hessian, and one called hivemind to run these servlets.
[20:34]<tjufgg>wtf
[20:34]<tjufgg>OVERKILL
[20:35]<tjufgg>If at all possible kick said dev in the face with a soccer clean. And then have him explain what his solution offers over say a simple REST based service.
[20:35]<tjufgg>cleat*
[20:36]<jlnzrvyvn>hi all, I realise some of this is ubuntu specifc but im setting up a server, 2 questions, is there any good reason to have php4 and php5 installed? why does phppgadmin think that php has no postgresql support (using pg 8.1)
[20:36]<jlnzrvyvn>I realise the second one is edging on OT
[20:36]<mzwpv1m>hmm well how fast will me method be?
[20:37]<tjufgg>operative: Depends on the nature of your system, php-pgsql probably isn't installed
[20:37]<mzwpv1m>how much faster will it work than his? spped if of the utmost importance
[20:37]<mzwpv1m>speed even
[20:37]<tjufgg>Dr1ft3d: Well REST would take considerably less setup and programming time
[20:37]<jlnzrvyvn>Touqen: odd, that doesn't seem to be in the repo's
[20:38]<tjufgg>And there is less overhead from java
[20:38]<mzwpv1m>Touqen: REST?
[20:38]<tjufgg>php5-pgsql
[20:39]<mzwpv1m>Touqen: how will that help?
[20:39]<tjufgg>How will what help?
[20:39]<cznff9q>REST = XML as a delivery mechanism between processes, with the particular XML format defined by the actual task at hand rather than a generic format like XML-RPC or SOAP.
[20:40]<mzwpv1m>will be faster than calling various php pages across the network?
[20:40]<cznff9q>Technically a web browser can be seen as a REST client, with XHTML as the particular format.
[20:40]<cznff9q>Lunch time.
[20:40]<cznff9q>REST is how you would be calling said pages.
[20:40]<sgnncnz>any docs :D ?
[20:40]<wjlllrws>google,com
[20:40]<tjufgg>REST is just a way of implementing a web service
[20:40]<tjufgg>You are still calling these pages across the network.
[20:41]<tjufgg>The only overhead is how much network latency you have and how latent the responding server is.
[20:41]<mzwpv1m>Touqen: ok thanks, i'll look into it
[20:42]<taake>Seems that people in general are more found of mysql then xml.. Mysql is also faster on large searches, so I think I've found my solution :)
[20:42]<cznff9q>Odds are your network latency will be slower than any other part of the system.
[20:42]<cznff9q>As I said, XML is bad for random-seek.
[20:42]<wjlllrws>TAAKE: o.O XML should be even considered for a data storage...
[20:43]<wjlllrws>s/should/shouldn't
[20:43]<taake>should'nt?
[20:43]<taake>yeah
[20:43]<mzwpv1m>Crell42: alright. so there'll still be latency over a 1gbit network?
[20:43]<cznff9q>Sure it can, if your records are complex and structured trees and your search mechanism is by file name.
[20:44]<cznff9q>In that case, XML can be great.
[20:44]<wjlllrws>Crell42: You're kidding, right?
[20:44]<cznff9q>Dr1ft3d: There's always network latency.
[20:44]<cznff9q>Ever hear of DocBook?
[20:44]<wjlllrws>yes, I did
[20:44]<mzwpv1m>Crell42: Alright sure. but java servlets running in tomcat is a bad idea?
[20:44]<cznff9q>or XHTML? :-)
[20:44]<wjlllrws>Crel: so?
[20:45]<tjufgg>Dr1ft3d: It really depends on your needs. If you need something fairly heavy-weight then use it. If not, don't.
[20:45]<cznff9q>So those are examples of XML files being used as a storage mechanism.
[20:45]<cznff9q>The main advantage of servlets over PHP is that they're memory resident.
[20:45]<cznff9q>That means they take up a lot more memory, but are only compiled/interpreted once.
[20:45]<cznff9q>For most tasks, PHP JIT complies fast enough that you don't notice anyway.
[20:46]<cznff9q>If you have a room full of Java programmers and no PHP folks, though, then you'll get better performance out of servlets. :-) Same the other way around.
[20:46]<wg2svzrgm>what command do i send that displays php's version info?
[20:46]<snfmrnc>phpinfo();
[20:46]<mzwpv1m>ok thanks for your help.
[20:46]<mzwpv1m>i see.
[20:46]<tjufgg>java compilers with hotspot though will reoptimize java bytecode for frequently use functions
[20:47]<wjlllrws>Crell42: I am not talking about storage of couple of bytes, but rather few and more megabytes of information with seek / insert / delete functionality
[20:47]<cznff9q>Who said bytes?
[20:48]<cznff9q>Random-seek INTO an XML file is much slower than into a MySQL table.
[20:48]<wjlllrws>no... Really?
[20:48]<taake>So a good practise would be to make it a flat filesystem, with just metadata stored in mysql right.. Learning every day :)
[20:48]<wjlllrws>TAAKE: "sqlite"
[20:49]<cznff9q>But if you can seek via file/path name to a record that is itself big and complex, and is primarily read-based, then XML can be a win because it can handle tree-based data better.
[20:49]<cznff9q>As always, depends on the task at hand.
[20:49]<cznff9q>And I'm going to eat lunch.
[20:49]<wjlllrws>Crell42: And parsing XML nodes still isn't faster than accessing SQL server.
[20:49]<taake>Wolfpaws: I'm only familiar with mysql and xml.. + my isp provides me with the phpmyadmin which I think is quite a handy tool
[20:49]<tjufgg>ex@pat54-33.pratt.edu] has quit ["Leaving"]
[20:50]<tjufgg>stupid right click
[20:50]<wjlllrws>lol
[20:50]<ndf>Putty can be a b*tch, yeah.
[20:50]<ndf>Well, putty or something with the same stupid idea of right click equals paste.
[20:51]<wjlllrws>TAAKE: I didn't say XML was junk... It's fantastic for sharing information, but not as replacement for database.
[20:51]<djjjjjp>hi, guys, what does this line mean $abc=array();
[20:51]<tjufgg>Horray for options







