Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (736)
Games in Android Showcase (223)
games submitted by our members
Games in WIP (813)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Can we have a better code integration?  (Read 4333 times)
0 Members and 1 Guest are viewing this topic.
Offline Java Cool Dude

Senior Devvie




Java forever


« Posted 2004-01-26 15:04:51 »

I've been hanging out other forums where you can display code in a fancy way such as high-lighting keywords, brackets etc..
So shall we get something better for our forums?
Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #1 - Posted 2004-01-26 17:10:46 »

Yea... that would be really nice. Pasted code looks always a bit... hmm... trashed? :>

However, generating good formatting takes a fair amout of cpu power... for a whole board at least.

Right now the board doesn't have a lot of bottlenecks and I'm really glad that it's that relyable, therefore I'm not sure if it's really a good idea to change that. Maybe something half external, wich isn't directly integrated?

弾幕 ☆ @mahonnaiseblog
Offline Jens

Senior Devvie




Java for games!


« Reply #2 - Posted 2004-02-01 09:02:12 »

Don't know if the CPU power is really a problem, because most of the time users spend reading and not writing. And after all only a fraction of all forum posts contains code.

Xith3D Getting Started Guide (PDF,HTML,Source)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #3 - Posted 2004-02-01 12:54:10 »

Quote
Don't know if the CPU power is really a problem, because most of the time users spend reading and not writing. And after all only a fraction of all forum posts contains code.


Ah, but you under-estimate the gross incompetence of the majority of all forum-software authors. Really, 95% of it is rubbish, and burns performance.

E.g. last time I looked, it was normal for many of them to use 15 SQL queries to generate each page. Stupid, stupid, stupid.

OTOH, most boards just use a more powerful server when it gets slow, and it's such a commodity market it's barely worth anyone writing a really good one - and there's so many many features that users want these days that it's potentially a mammoth task to do it in-house, so we (nearly) all put up with it Smiley.

malloc will be first against the wall when the revolution comes...
Offline Jens

Senior Devvie




Java for games!


« Reply #4 - Posted 2004-02-01 16:42:24 »

Are you sure this forum is database driven? I think YaBB uses text files. But hey, this means 0 SQL queries instead of 15.  Grin

Xith3D Getting Started Guide (PDF,HTML,Source)
Offline Evil-Devil

Senior Devvie


Medals: 3


Fir Tree Master


« Reply #5 - Posted 2004-09-07 06:32:19 »

15 queries ain't that much. Last year i wrote a "small" forum application and it takes 5 queries at first time run to display the index page. 3 queries are used to gazer user and board informationen and check with security settings.
the rest two are needed to gazer all boards and the navigationbar.
But back to topic, in thus big board applications, 15 queries might be less...but the more horrible is the code.
I looked at a php board and the layout templates. They are really huge, mine only contains of 1000 line html code Wink With some lesser functions Grin
The colored parsing might be moderated, even with some regular expressions. Give it a try.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2004-09-07 07:57:00 »

Quote
15 queries ain't that much.


15 is approximately 14 too many. Usually, each query has a *large* constant overhead (compared to e.g. fetching a few strings), and so 15 queries to fetch X amount of data can easily be 10 times slower than 1 query to fetch exactly the same data.

Sure, shoehorning into a single query sometimes makes hard-to-read SQL statements - but not normally for something as simple as a forum - and so you might perhaps aim for 2 or 3 queries instead. But definitely not double-digits. Unless you've profiled and are sure there's no penalty (unlikely when using free databases...)

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #7 - Posted 2004-09-07 07:58:15 »

Quote
Are you sure this forum is database driven? I think YaBB uses text files. But hey, this means 0 SQL queries instead of 15.  Grin


Even worse Tongue. I know that all the others use DBs (PhpBB, Invision, Discus, Gossamer, etc), and I thought YaBB did too; guess I must have assumed rather than checked?

malloc will be first against the wall when the revolution comes...
Offline Evil-Devil

Senior Devvie


Medals: 3


Fir Tree Master


« Reply #8 - Posted 2004-09-07 08:48:58 »

Quote

Sure, shoehorning into a single query sometimes makes hard-to-read SQL statements - but not normally for something as simple as a forum - and so you might perhaps aim for 2 or 3 queries instead.

2-3 Queries? Might be possible if its a really simple forum.
q1: get user rights
q2: read boards/threads/posts/user (inner joins)
q3: additional read for the navigation
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2004-09-07 09:20:03 »

Quote

2-3 Queries? Might be possible if its a really simple forum.
q1: get user rights
q2: read boards/threads/posts/user (inner joins)
q3: additional read for the navigation


Most stuff that forums end up going to double-digit queries for falls into two categories:

1. They aren't confident enough to do complex joins, or are afraid of maintaining them (they can look quite scary to newbies), and so go for doing something in many queries that could have been done just as well in one

2. Stuff that *should not* be pulled directly from the DB, e.g "number of registered users". It's more than sufficient for this stuff to be cached in-memory and updated every hour; there's no good reason for putting it into a query and adding unnecessary load on the DB. No-one really needs to know *to the millisecond* how many users are registered on the board Grin. Ditto any generally static  navigation - it should be read from DB on startup, then cached.

Of course, as previously noted, if you have server-power to spare, you don't care. If you can afford serious horsepower, you don't care.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Evil-Devil

Senior Devvie


Medals: 3


Fir Tree Master


« Reply #10 - Posted 2004-09-07 09:24:41 »

how will you cache the navigation?
I don't know any sql command for that. Only a view might fit that.
Else it might be cached directly in the application, this way i haven't thought yet.
@serverpower: hmm, i don't use lame mysql. MS SQL and Oracle are really powerfull DBS.

@large queries: they should be also readable....
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
<cfquery datasource="#Application.boardSettings.DSN#" name="qGetBoards">
            SELECT DISTINCT
                        B1.ID, B1.Name, B1.Description, B1.bCat, Count(*) -1 AS Level, B1.Threads, B1.Posts, B1.lastUser,B1.Lft, B1.Rgt,
                        B1.lastDate, B1.lastUser, B1.lastThread, B1.lastPost, Floor((B1.Rgt - B1.Lft - 1) / 2) AS Childs, B1.bActive,
                        T.Name AS ThreadName, T.ID AS ThreadID, U.Name AS UserName, U.ID AS UserID, (B1.Lft + B1.Rgt) % 2 AS LevelDiff
            FROM      <cfif Arguments.BoardID NEQ 1>BB_Boards B3, </cfif>BB_Boards B2,
                        BB_Boards B1 LEFT OUTER JOIN BB_User U ON B1.lastUser = U.ID
                        LEFT OUTER JOIN BB_Threads T ON B1.lastThread = T.ID
            WHERE      B1.Lft BETWEEN B2.Lft AND B2.Rgt
            <cfif Arguments.BoardID NEQ 1>            
                  AND            B1.Lft BETWEEN B3.Lft AND B3.Rgt
                  AND            B3.ID = <cfqueryparam cfsqltype="CF_SQL_INTEGER" value="#Arguments.BoardID#">
            </cfif>
            GROUP      BY      B1.ID, B1.Name, B1.Description, B1.bCat, B1.Lft, B1.Threads, B1.Posts,
                        B1.lastDate, B1.lastUser, B1.lastThread, B1.lastPost, B1.Rgt, B1.bActive,
                        T.Name, T.ID, U.Name, U.ID
            ORDER      BY      B1.Lft
      </cfquery>

that was my small query to gain everything important on the show board page.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2004-09-07 09:50:21 »

Quote
how will you cache the navigation?
I don't know any sql command for that. Only a view might fit that.
Else it might be cached directly in the application, this way i haven't thought yet.


I was thinking of in-application caching, which was silly because of course most boards don't HAVE an application - they are simply PHP direct to a DB. So, application-level caching moves from being "trivial" to being "mildly tricky". At the very least, you could periodically output information into a file (with access to the crontab, it's trivial; otherwise, you might have to again get cunning in order to simulate scheduled tasks) and then include that file in PHP pages...

Quote

@large queries: they should be also readable....


SQL is never particularly readable; it's one of the most unreadable languages I've ever seen Tongue (fine for toy examples, but any "real" query to a real DB tends to be impenetrable without extensive GUI support for formatting the query so that it becomes readable). For instance, debugging inner joins is always agonising if you have to do it on the unformatted plain text raw SQL query Sad.

malloc will be first against the wall when the revolution comes...
Offline Evil-Devil

Senior Devvie


Medals: 3


Fir Tree Master


« Reply #12 - Posted 2004-09-07 09:57:31 »

Php did not have an application. But Coldfusion did. The difference is that Coldfusion does cost some money Wink And it is written in Java since Version 6 Cheesy
Offline Middy

Junior Devvie




Java games rock!


« Reply #13 - Posted 2004-09-07 18:10:21 »

Java Cool Dude. Those other forums are at gamedev, you have been reported and we know who you REALY are now....

When do I get my makeMyGameAsILike() extension?
Offline Evil-Devil

Senior Devvie


Medals: 3


Fir Tree Master


« Reply #14 - Posted 2004-09-07 21:46:48 »

Quote
Java Cool Dude. Those other forums are at gamedev, you have been reported and we know who you REALY are now....

Does i have to understand this?
*confused*
oO(might be a lack of my english knowledge)
Offline DannyFromTower

Senior Newbie




Java games rock!


« Reply #15 - Posted 2004-09-08 04:02:49 »

So, as I understand it, the forum software would accept a post with a markup something like:

<java>
 bunch of code
</java>

then parse the Java code simplistically (can't know about context of code after all) and produced marked up output to store as the actual post. Of course, I've assumed a language specific markup. I'm not to sure how generic the parser/marker could be so that it decently handled php, sql, java etc. generically.
:-/
Offline cfmdobbie

Senior Devvie


Medals: 1


Who, me?


« Reply #16 - Posted 2004-09-09 14:11:41 »

Quote
I'm not to sure how generic the parser/marker could be so that it decently handled php, sql, java etc. generically.


Best to write a generic core, and implement a plugin system that would load the correct syntax-colouring system based on the content.

FWIW, I believe the GameDev forums have something like this in place already.


Note that as this site is almost entirely based around Java technology, the benefits of such a system are much diminished.  On a fragment-by-fragment basis, http://www.showsrc.com/ is handy.  Also, if you're posting links to Java source files, consider bouncing the links through showsrc as well.

Hellomynameis Charlie Dobbie.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 
cybrmynd (120 views)
2017-08-02 12:28:51

cybrmynd (144 views)
2017-08-02 12:19:43

cybrmynd (138 views)
2017-08-02 12:18:09

Sralse (154 views)
2017-07-25 17:13:48

Archive (624 views)
2017-04-27 17:45:51

buddyBro (733 views)
2017-04-05 03:38:00

CopyableCougar4 (1260 views)
2017-03-24 15:39:42

theagentd (1239 views)
2017-03-24 15:32:08

Rule (1216 views)
2017-03-19 12:43:22

Rule (1268 views)
2017-03-19 12:42:17
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!