[Flightgear-devel] FlightGear website on wiki

2010-10-10 Thread Gijs de Rooy

Hi,

last week, James dropped the idea of moving our website (partly) over to the 
wiki. So far I have discussed
this with a couple of people, all of which have different opinions. Therefore, 
I would like to ask anyone that 
cares about our website to reply.

I think we all agree that our current website cannot continue like it does 
right now. We've had multiple discussions
in the past, even leading to some test website (like the ones by Pete), but 
none of them led to something.

I have listed a couple of pro's and con's (IMO, and based on a small IRC 
duscission) below. This list is dynamic, 
as pro's can become con's and vice versa.

+ Easy to update: wiki articles can be edited by all people, in stead of just a 
single man (Curt :P). As we have
seen in the past (and even till today), our website is often out of date. A 
good example of this is the CVS/Git
page, which hasn't been updated since May (!), and still does not contain any 
useful info if I want to use Git.
 Of course we don't want some of our important pages (main page, download 
etc.) to be edited by just anyone
with a wiki account. Luckily, we can add usergroups at the wiki and assign 
permissions to them. Thus, important
pages can be locked (on the edit part) for the ordinary users. We've been doing 
this with all Newsletters, which
can be edited only by wiki-admins after their publicication. We could create 
various groups, and people can be
within multiple groups at once.
+ Easy to link to detailed documentation: rather than providing an external 
link, we can add internal links to
each word (okay, that's a little too much). If a text mentions $FG_ROOT, we can 
make that word link to the wiki-
article about it. This will decrease the amount of useless questions at the 
forum (which are replied by a link to
the wiki), which is meant for special, personalised help and discussions.
+ Download page: since the wiki already contains quite some information per 
aircraft, it could be used to auto-
generate a more detailed aircraft download page. Each aircraft on that page can 
link to the aircraft's private page
(if existing) and thus provide manuals, status info etc. immediately to the 
user, even before downloading the aircraft.
As we've had quite some complaints from people that are disappointed after 
dowloading. The wiki can provde various
screenshots per aircraft (eg. interior, exterior), so users can 
see-what-they-get.
+ Publicity of the wiki: new FG users will be immediately aware of the 
existence of a wiki, and therefore be 
stimulated to start developing themselves. This will again decrease the 
useless questions at the forum.

- Less attractive layout: currently the FlightGear wiki doesn't really look 
like a website. This could be solved 
though by creating/adding a different style/layout.
- Less open system: for example, it will be harder to implement additional 
features (gallery's, search engines) 
etc. However, the alternative is a CMS system, which isn't much opener...

- Not much examples: of a complete wiki website about projects like ours. This 
could be a pro as well, as it will
allow us to be renewed and different.

 

Jester (IIRC) mentioned that it is important to check whether pages are cached 
at the wiki, so they won't have
to be pulled from the database each time. If so, we should enable cache. A 
possible other solution is to have a
static frontpage, which could be nice in various ways, other than the cache...

I look forward to receiving your ideas/opinions/questions! When the list grow, 
we might benefit from setting up a
wiki article to collect ideas/opinions.



Cheers,
Gijs  --
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear website on wiki

2010-10-10 Thread Vivian Meazza
Gijs,

 

This sounds like a worthwhile proposal. Why not set up the wiki page etc. so
that we can compare and come up with an informed decision, rather than some
pre-formed opinions. (4 FG Developers - 5 opinions. One will change their
mind :-))

 

Vivian

 

-Original Message-
From: Gijs de Rooy [mailto:gijsr...@hotmail.com] 
Sent: 10 October 2010 11:07
To: FlightGear Development list
Subject: [Flightgear-devel] FlightGear website on wiki

 

Hi,

last week, James dropped the idea of moving our http://www.flightgear.org/
website (partly) over to the wiki http://wiki.flightgear.org/ . So far I
have discussed
this with a couple of people, all of which have different opinions.
Therefore, I would like to ask anyone that 
cares about our website to reply.

I think we all agree that our current website cannot continue like it does
right now. We've had multiple discussions
in the past, even leading to some test website (like the ones by Pete), but
none of them led to something.

I have listed a couple of pro's and con's (IMO, and based on a small IRC
duscission) below. This list is dynamic, 
as pro's can become con's and vice versa.

+ Easy to update: wiki articles can be edited by all people, in stead of
just a single man (Curt :P). As we have
seen in the past (and even till today), our website is often out of date. A
good example of this is the CVS/Git http://flightgear.org/cvs.html 
page, which hasn't been updated since May (!), and still does not contain
any useful info if I want to use Git.
 Of course we don't want some of our important pages (main page,
download etc.) to be edited by just anyone
with a wiki account. Luckily, we can add usergroups at the wiki and assign
permissions to them. Thus, important
pages can be locked (on the edit part) for the ordinary users. We've been
doing this with all Newsletters, which
can be edited only by wiki-admins after their publicication. We could create
various groups, and people can be
within multiple groups at once.
+ Easy to link to detailed documentation: rather than providing an external
link, we can add internal links to
each word (okay, that's a little too much). If a text mentions $FG_ROOT, we
can make that word link to the wiki-
http://wiki.flightgear.org/index.php/$FG_ROOT 
article about it. This will decrease the amount of useless questions at
the forum (which are replied by a link to
the wiki), which is meant for special, personalised help and discussions.
+ Download page: since the wiki already contains quite some information per
aircraft, it could be used to auto-
generate a more detailed aircraft download page. Each aircraft on that page
can link to the aircraft's private page
(if existing) and thus provide manuals, status info etc. immediately to the
user, even before downloading the aircraft.
As we've had quite some complaints from people that are disappointed after
dowloading. The wiki can provde various
screenshots per aircraft (eg. interior, exterior), so users can
see-what-they-get.
+ Publicity of the wiki: new FG users will be immediately aware of the
existence of a wiki, and therefore be 
stimulated to start developing themselves. This will again decrease the
useless questions at the forum.

- Less attractive layout: currently the FlightGear wiki doesn't really look
like a website. This could be solved 
though by creating/adding a different style/layout.
- Less open system: for example, it will be harder to implement additional
features (gallery's, search engines) 
etc. However, the alternative is a CMS system, which isn't much opener...
- Not much examples: of a complete wiki website about projects like ours.
This could be a pro as well, as it will
allow us to be renewed and different.
 
Jester (IIRC) mentioned that it is important to check whether pages are
cached at the wiki, so they won't have
to be pulled from the database each time. If so, we should enable cache. A
possible other solution is to have a
static frontpage, which could be nice in various ways, other than the
cache...

I look forward to receiving your ideas/opinions/questions! When the list
grow, we might benefit from setting up a
wiki article to collect ideas/opinions.

Cheers,
Gijs

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear website on wiki

2010-10-10 Thread Heiko Schulz
Hi,
I like this idea as well!
A good and fantastic simulation project as FlightGear needs a better 
represantion on the web if we want to be as successfull as we are now. 
The only thing I fear is: that it will be another useless discussion, without 
any resultat
CheersHeiko
still in work: http://www.hoerbird.net/galerie.html

But already done: http://www.hoerbird.net/reisen.html

--- Gijs de Rooy gijsr...@hotmail.com schrieb am So, 10.10.2010:

Von: Gijs de Rooy gijsr...@hotmail.com
Betreff: [Flightgear-devel] FlightGear website on wiki
An: FlightGear Development list flightgear-devel@lists.sourceforge.net
Datum: Sonntag, 10. Oktober, 2010 12:06 Uhr





 
Hi,

last week, James dropped the idea of moving our website (partly) over to the 
wiki. So far I have discussed
this with a couple of people, all of which have different opinions. Therefore, 
I would like to ask anyone that 
cares about our website to reply.

I think we all agree that our current website cannot continue like it does 
right now. We've had multiple discussions
in the past, even leading to some test website (like the ones by Pete), but 
none of them led to something.

I have listed a couple of pro's and con's (IMO, and based on a small IRC 
duscission) below. This list is dynamic, 
as pro's can become con's and vice versa.

+ Easy to update: wiki articles can be edited by all people, in stead of just a 
single man (Curt :P). As we have
seen in the past (and even till today), our website is often out of date. A 
good example of this is the CVS/Git
page, which hasn't been updated since May (!), and still does not contain any 
useful info if I want to use Git.
 Of course we don't want some of our important pages (main page, download 
etc.) to be edited by just anyone
with a wiki account. Luckily, we can add usergroups at the wiki and assign 
permissions to them. Thus, important
pages can be locked (on the edit part) for the ordinary users. We've been doing 
this with all Newsletters, which
can be edited only by wiki-admins after their publicication. We could create 
various groups, and people can be
within multiple groups at once.
+ Easy to link to detailed documentation: rather than providing an external 
link, we can add internal links to
each word (okay, that's a little too much). If a text mentions $FG_ROOT, we can 
make that word link to the wiki-
article about it. This will decrease the amount of useless questions at the 
forum (which are replied by a link to
the wiki), which is meant for special, personalised help and discussions.
+ Download page: since the wiki already contains quite some information per 
aircraft, it could be used to auto-
generate a more detailed aircraft download page. Each aircraft on that page can 
link to the aircraft's private page
(if existing) and thus provide manuals, status info etc. immediately to the 
user, even before downloading the aircraft.
As we've had quite some complaints from people that are disappointed after 
dowloading. The wiki can provde various
screenshots per aircraft (eg. interior, exterior), so users can 
see-what-they-get.
+ Publicity of the wiki: new FG users will be immediately aware of the 
existence of a wiki, and therefore be 
stimulated to start developing themselves. This will again decrease the 
useless questions at the forum.

- Less attractive layout: currently the FlightGear wiki doesn't really look 
like a website. This could be solved 
though by creating/adding a different style/layout.
- Less open system: for example, it will be harder to implement additional 
features (gallery's, search engines) 
etc. However, the alternative is a CMS system, which isn't much opener...

- Not much examples: of a complete wiki website about projects like ours. This 
could be a pro as well, as it will
allow us to be renewed and different.

 

Jester (IIRC) mentioned that it is important to check whether pages are cached 
at the wiki, so they won't have
to be pulled from the database each time. If so, we should enable cache. A 
possible other solution is to have a
static frontpage, which could be nice in various ways, other than the cache...

I look forward to receiving your ideas/opinions/questions! When the list grow, 
we might benefit from setting up a
wiki article to collect ideas/opinions.



Cheers,
Gijs  

-Integrierter Anhang folgt-

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
-Integrierter Anhang folgt-

___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel



Re: [Flightgear-devel] FlightGear website on wiki

2010-10-10 Thread Martin Spott
Gijs de Rooy wrote:

 - Less open system: for example, it will be harder to implement
 additional features (gallery's, search engines) etc. However, the
 alternative is a CMS system, which isn't much opener...

I'm uncertain about how to read this final conclusion.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear website on wiki

2010-10-10 Thread Gijs de Rooy

Hey!

 Torsten wrote:

 From time to time, I notices some abuse by inserted spam into our wiki pages. 
 Great care must be taken, our 
 home page is locked for the everybody group.

Of course. Additionally I will look for some more anti-spam measures that we 
could install at the wiki.

 The layout/design is editable and with some knowledge, the skin may be 
 replaced (you did this before, did you?)

There are quite some skins available on the web (also GNU GPL ones), that we 
can choose from. Just like I did with 
the forum, it is possible to addapt an pre-existing skin slightly (or less 
slightly) and add our own logo/images to the
header for example.

Then, of course it is also important that the content looks nice. The main page 
as it is know exists of some very simple
(colored) tables. We could easily replace the tablecolors with some rounder 
bars for example. That will be similar to the
difference between the English and Dutch Wikipedia.
 

 Heiko wrote:

 The only thing I fear is: that it will be another useless discussion, without 
 any resultat

If we don't start the discussion we won't have any result at all. And given the 
fact that we were able to go through quite
some updates the past year(s) (move to Gitorious, moving wiki and forum over 
to a new server, slightly updated forum
layout and a different structure), I am hopefull. :)

 Scott wrote:

 I'd like to throw in WordPress as perhaps a better website content system 
 than Wiki.

It is good to look at alternatives. However, I don't really see the advantage 
of WordPress over the wiki. In the end, only 
a couple of pages will be static. Most of the content at our current website 
is documentation(-related) anyway...
I might be wrong, so I'm open to other's opinions ;)

 Martin wrote:
 
 Gijs wrote:
 
  - Less open system: for example, it will be harder to implement
  additional features (gallery's, search engines) etc. However, the
  alternative is a CMS system, which isn't much opener...
 
 I'm uncertain about how to read this final conclusion.

I agree that I didn't explain it very well. What I meant is that with an 
ordinary HTML website, you have quick,
full control over everything. Adding certain things is usually just a matter of 
uploading some files and adding 
some code. With CMS/Wiki, this involves installing addons. There are no addons 
for everything; and additionally
certain thing can easily interfer with eachother. Therefore, it might be hard 
to add those features easily...
Question is: are there really (that many) features that we cannot install 
easily on a wiki/CMS?

I have requested the wiki admin to install a couple of addons. When that's 
done, I will set some example pages
up, so we can see how it looks and feels.

Thanks for sharing all of your thoughts so far!

Cheers,
Gijs 
  --
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear website on wiki

2010-10-10 Thread Martin Spott
Hi Gijs,

Gijs de Rooy wrote:

 Question is: are there really (that many) features that we cannot
 install easily on a wiki/CMS?

The most prominent item that comes into my mind is what is probably
well-decribed as dynamic content (choose a better term, if you like).
Being the technical maintainer of another Wiki instance, the item which
I'd consider to be most-needed is the ability just to drop some P*
script programming language code into the page and let this program
code render whatever fits my needs.

Just as one among other obvious examples: Most of us certainly know,
that editing tables in *Wiki is a major PITA (TM). I'd like to drop
some P* code into the page which is capable of operating on top of a
database handle and does the formatting of the DB query result
(obviously accompagnied by some caching mechanism).

Or, as a FG-related example, think of the aircraft download page:
Wouldn't it be nice just to let some programming code hook onto
whichever repository you like and have the download page generated on
the fly (caching applies here as well).

In general, with a 'sophisticated' website I'd like to have the ability
to drop some scripting code into whichever place on a website I like to
do whatever I like. According to my knowledge this is not going to work
with *Wiki. I _guess_ it's possible with systems of the Drupal-league,
certainly with Django and comparable (or bigger) systems.
The latter ones, on the other hand, require more programming to get
even the core setup running    ;-)


Nevertheless I agree with the forementioned opinion that the biggest
obstacle on the way to a better (TM) website might not be a technical
one.

Best regards,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FlightGear website on wiki

2010-10-10 Thread Gene Buckle
On Sun, 10 Oct 2010, Torsten Dreyer wrote:


 From time to time, I notices some abuse by inserted spam into our wiki pages. 
 Great care must be taken, our home page is locked for the everybody group.

If you're using the Wikimedia engine, you can install a plug-in that will 
require accounts to be validated before posting access can be granted. 
Part of the sign-up process requires the user enter a biographical 
description that can require a specific number of words before they can 
submit the request.  This would go a long way towards discouraging 
spammers and would give the admin something to help decide whether or not 
to enable the account.

g.



-- 
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project

ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 3D clouds flat instead of fluffy

2010-10-10 Thread Arnt Karlsen
On Sat, 9 Oct 2010 14:10:58 -0400, Gary wrote in message 
aanlktikrukm+kk2runqqklqcwymy1vjpuvi79n715...@mail.gmail.com:

 On Fri, Oct 8, 2010 at 12:38 PM, Arnt Karlsen a...@c2i.net wrote:
  On Fri, 8 Oct 2010 00:16:40 -0400, Gary wrote in message
  aanlktikcpogneb+aonmfgddctnkftfsyqv6evl+9g...@mail.gmail.com:
 
  Can anyone help with a 3D cloud issue? The clouds now display as
  identical flat gray panels instead of their usual realistic
  appearance. This has persisted for (guessing) 6-8 weeks now. Here
  are a couple screen shots to illustrate the problem-
 
  http://img96.imageshack.us/img96/1671/3dclouds1.jpg
  http://img836.imageshack.us/img836/8100/3dclouds2.jpg
 
  FlightGear and SimgGear are Gitorious 'next' branch, fgdata is
  Gitorious 'master'. ASUS A8V Deluxe motherboard, AMD Athlon 64 X2
  4200+ CPU, 2G memory. Video card is ATI Radeon 9700 Pro AGP. OS is
  Slackware64 Linux, kernel 2.6.35.5, X.org open source video driver
  (not the ATI proprietary one) using KMS.
 
  ..which one, ati, radeon or radeonhd???
  With a 9700 Pro, you should be using ati or radeon.
  (If you are, try radeonhd to see how that works, it
  _should_ fail.)
 
  ..ati is a wrapper for radeon, mach64 and
  r128, X should pick the right one for your card,
  but sometimes the automagic fails.
 Hmm. It loads both ati and radeon modules, then the log output is
 tagged RADEON(0). So it must be using the radeon driver. They don't
 exactly make it easy to tell :-) It's not radeonhd, my card is pre-HD.
 
 
  ..you posted picture links, how about your log links?
 Good point. X server log:
 http://www.mediafire.com/?21cfo1sb4v6h694

..I find a line '(**) RADEON(0): Option AccelDFS 1',
which I suspect may correspond to an option line in your
/etc/X11/xorg.conf (Option AccelDFS 1), try comment 
it out and see what happens.

..http://dri.freedesktop.org/wiki/ATIRadeon says Option 
AccelDFS should be # 1/0 On for PCIE, off for AGP,
http://www.x.org/wiki/radeon suggests there are changes
in e.g. DFS that now stall things that used to work.

..http://www.free3d.org/ for X tweak benchmarks. ;o)

..your X log is taken after a FG run?
Anything in dmesg output?

 FlightGear console output:
 http://www.mediafire.com/?w49t2gc4iihu6gg


-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Build failed in Hudson: FlightGear-next-mac #230

2010-10-10 Thread geneb
See http://flightgear.simpits.org:8080/job/FlightGear-next-mac/230/

--
Started by user geneb
Building remotely on MacPro
Checkout:FlightGear-next-mac / 
http://flightgear.simpits.org:8080/job/FlightGear-next-mac/ws/ - 
hudson.remoting.chan...@b46c4c:MacPro
Using strategy: Default
Last Built Revision: Revision b9f2f432b3c6894b4bc39d9a6176443f1ee6f1a2 
(origin/next)
Checkout:FlightGear-next-mac / 
http://flightgear.simpits.org:8080/job/FlightGear-next-mac/ws/ - 
hudson.remoting.localchan...@2d2acaf5
GitAPI created
Fetching changes from the remote Git repository
Fetching upstream changes from http://git.gitorious.org/fg/flightgear.git
[FlightGear-next-mac] $ git fetch -t http://git.gitorious.org/fg/flightgear.git 
+refs/heads/*:refs/remotes/origin/*
[FlightGear-next-mac] $ git ls-tree HEAD
[FlightGear-next-mac] $ git tag -l next
[FlightGear-next-mac] $ git rev-parse origin/next
Commencing build of Revision b9f2f432b3c6894b4bc39d9a6176443f1ee6f1a2 
(origin/next)
GitAPI created
Checking out Revision b9f2f432b3c6894b4bc39d9a6176443f1ee6f1a2 (origin/next)
[FlightGear-next-mac] $ git checkout -f b9f2f432b3c6894b4bc39d9a6176443f1ee6f1a2
[FlightGear-next-mac] $ git tag -a -f -m Hudson Build #230 
hudson-FlightGear-next-mac-230
Recording changes in branch origin/next
[FlightGear-next-mac] $ git whatchanged --no-abbrev -M --pretty=raw 
b9f2f432b3c6894b4bc39d9a6176443f1ee6f1a2..b9f2f432b3c6894b4bc39d9a6176443f1ee6f1a2
ERROR: Failed to copy artifacts from Simgear-next-mac with filter: dist/**
hudson.util.IOException2: hudson.util.IOException2: Failed to extract 
/var/lib/hudson/jobs/Simgear-next-mac/builds/2010-10-07_11-14-20/archive/dist/**
at hudson.FilePath.copyRecursiveTo(FilePath.java:1474)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1399)
at 
hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:170)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at 
hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:601)
at hudson.model.Build$RunnerImpl.build(Build.java:174)
at hudson.model.Build$RunnerImpl.doRun(Build.java:138)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416)
at hudson.model.Run.run(Run.java:1280)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:137)
Caused by: java.util.concurrent.ExecutionException: hudson.util.IOException2: 
Failed to extract 
/var/lib/hudson/jobs/Simgear-next-mac/builds/2010-10-07_11-14-20/archive/dist/**
at hudson.remoting.Channel$2.adapt(Channel.java:663)
at hudson.remoting.Channel$2.adapt(Channel.java:658)
at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1472)
... 11 more
Caused by: hudson.util.IOException2: Failed to extract 
/var/lib/hudson/jobs/Simgear-next-mac/builds/2010-10-07_11-14-20/archive/dist/**
at hudson.FilePath.readFromTar(FilePath.java:1577)
at hudson.FilePath.access$100(FilePath.java:159)
at hudson.FilePath$32.invoke(FilePath.java:1463)
at hudson.FilePath$32.invoke(FilePath.java:1460)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1899)
at hudson.remoting.UserRequest.perform(UserRequest.java:114)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at hudson.remoting.Engine$1$1.run(Engine.java:58)
at java.lang.Thread.run(Thread.java:637)
Caused by: java.util.zip.ZipException: incomplete dynamic bit lengths tree
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:147)
at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:92)
at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257)
at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223)
at 
hudson.org.apache.tools.tar.TarInputStream.read(TarInputStream.java:345)
at java.io.FilterInputStream.read(FilterInputStream.java:90)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:999)
at hudson.util.IOUtils.copy(IOUtils.java:33)
at hudson.FilePath.readFromTar(FilePath.java:1565)
... 14 more



[Flightgear-devel] [patch] Improved Nasal access to airport information

2010-10-10 Thread Stuart Buchanan
Hi All,

I've been working on a small patch to change the existing global Nasal
function airportinfo() to return more than one result.

With this patch, and optional argument allows the caller to specify
the number of nearest airports to return. E.g. airportinfo(10),
returns the nearest 10 airports, and airportinfo(55.5, -3, 10) returns
the 10 nearest airports to lat 55.5M, lon 3W.

This changes the return values of this function from a hash containing
a single airport to a vector of hashes, so requires a very
straightforward update to all
Nasal calls to airportinfo(). Previously one would call

var airport = airportinfo();

After this patch, this must be changed to

var airport = airportinfo()[0];

I'm happy to make this change to the dozen or so instances in fgdata
(I have commit permissions to fgdata but not the flightgear source),
assuming people approve of the change. I'm away on business this week,
so it would probably best wait until next weekend unless someone is
particularly keen to patch fgdata as well.

My original motivation for this change is to create a Nasal-driven
dialog displaying the local airport frequencies, something previously
provided by ATCDCL, and which hasn't yet been replaced. Unfortunately
I only noticed that frequency information isn't distributing through
the FGAirport object after writing the patch below!

The patch is available from http://www.nanjika.co.uk/flightgear/airport.patch

Comments etc. very welcome as always.

-Stuart

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] [patch] Improved Nasal access to airport information

2010-10-10 Thread Torsten Dreyer
  Am 10.10.10 18:06, schrieb Stuart Buchanan:
 Hi All,

 I've been working on a small patch to change the existing global Nasal
 function airportinfo() to return more than one result.

 With this patch, and optional argument allows the caller to specify
 the number of nearest airports to return. E.g. airportinfo(10),
 returns the nearest 10 airports, and airportinfo(55.5, -3, 10) returns
 the 10 nearest airports to lat 55.5M, lon 3W.

 This changes the return values of this function from a hash containing
 a single airport to a vector of hashes, so requires a very
 straightforward update to all
 Nasal calls to airportinfo(). Previously one would call

 var airport = airportinfo();

 After this patch, this must be changed to

 var airport = airportinfo()[0];

 I'm happy to make this change to the dozen or so instances in fgdata
 (I have commit permissions to fgdata but not the flightgear source),
 assuming people approve of the change. I'm away on business this week,
 so it would probably best wait until next weekend unless someone is
 particularly keen to patch fgdata as well.

 My original motivation for this change is to create a Nasal-driven
 dialog displaying the local airport frequencies, something previously
 provided by ATCDCL, and which hasn't yet been replaced. Unfortunately
 I only noticed that frequency information isn't distributing through
 the FGAirport object after writing the patch below!

 The patch is available from http://www.nanjika.co.uk/flightgear/airport.patch

 Comments etc. very welcome as always.


Sounds like a good idea. I am working on an extended METAR system 
allowing to fetch METAR data for an arbitrary number of stations. This 
will allow lateral (not only timed) interpolation of weather. Looks like 
these two systems might be a perfect fit.

Torsten


--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] FG hangs on startup when nearby airport

2010-10-10 Thread Martin Spott
Torsten Dreyer wrote:

 Here is the relevant code: from src/FDM/fdm_shell.cxx

Indeed, commenting the if (globals-get_scenery[...] clause makes
FlightGear skip the infinite loop. Thanks a lot for getting me started
into investigations.

For the purpose of Scenery development - and probably other, even more
obscure tasks - having an option to pre-set the old behaviour via some
command line flag would be much appreciated.

Cheers,
Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


[Flightgear-devel] Automatic runway selection broken by weather interpolation

2010-10-10 Thread Stuart Buchanan
Hi Guys,

I think I've found a bug in the new weather environment code.

I started up at Austin Bergstrom International (KAUS), a fairly large
Texas airport with runways 17L/R, 35L/R. The METAR had wind of 9 knots
at 190 degrees.

 I would expect FG to start on runway 17. Instead it starts on 35L.
Looking at the Global Weather dialog immediately after startup shows
the wind passing through 260 degrees as it veers around to 190. I
suspect that when the runways selection code is run, the wind is still
at 0 heading, causing runway 35L to be chosen.

Given this and the previously reported problem with pressure settings
(which still changes too slowly IMO - the pressure is often still
changing after I've set the altimeter) I think we need to be
explicitly setting the environment on initialization, rather than
relying on the interpolation XML to interpolate to the current METAR
or config.

-Stuart

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] 3D clouds flat instead of fluffy

2010-10-10 Thread Gary Carvell
On Sun, Oct 10, 2010 at 11:57 AM, Arnt Karlsen a...@c2i.net wrote:
 On Sat, 9 Oct 2010 14:10:58 -0400, Gary wrote in message
 aanlktikrukm+kk2runqqklqcwymy1vjpuvi79n715...@mail.gmail.com:

 On Fri, Oct 8, 2010 at 12:38 PM, Arnt Karlsen a...@c2i.net wrote:
  On Fri, 8 Oct 2010 00:16:40 -0400, Gary wrote in message
  aanlktikcpogneb+aonmfgddctnkftfsyqv6evl+9g...@mail.gmail.com:
 
  Can anyone help with a 3D cloud issue? The clouds now display as
  identical flat gray panels instead of their usual realistic
  appearance. This has persisted for (guessing) 6-8 weeks now. Here
  are a couple screen shots to illustrate the problem-
 
  http://img96.imageshack.us/img96/1671/3dclouds1.jpg
  http://img836.imageshack.us/img836/8100/3dclouds2.jpg
 
  FlightGear and SimgGear are Gitorious 'next' branch, fgdata is
  Gitorious 'master'. ASUS A8V Deluxe motherboard, AMD Athlon 64 X2
  4200+ CPU, 2G memory. Video card is ATI Radeon 9700 Pro AGP. OS is
  Slackware64 Linux, kernel 2.6.35.5, X.org open source video driver
  (not the ATI proprietary one) using KMS.
 
  ..which one, ati, radeon or radeonhd???
  With a 9700 Pro, you should be using ati or radeon.
  (If you are, try radeonhd to see how that works, it
  _should_ fail.)
 
  ..ati is a wrapper for radeon, mach64 and
  r128, X should pick the right one for your card,
  but sometimes the automagic fails.
 Hmm. It loads both ati and radeon modules, then the log output is
 tagged RADEON(0). So it must be using the radeon driver. They don't
 exactly make it easy to tell :-) It's not radeonhd, my card is pre-HD.

 
  ..you posted picture links, how about your log links?
 Good point. X server log:
 http://www.mediafire.com/?21cfo1sb4v6h694

 ..I find a line '(**) RADEON(0): Option AccelDFS 1',
 which I suspect may correspond to an option line in your
 /etc/X11/xorg.conf (Option AccelDFS 1), try comment
 it out and see what happens.
Correct. I set it to 0, didn't seem to change anything. Xorg.0.log
echoed the config line but there was no other diff from the previous
log.


 ..http://dri.freedesktop.org/wiki/ATIRadeon says Option
 AccelDFS should be # 1/0 On for PCIE, off for AGP,
 http://www.x.org/wiki/radeon suggests there are changes
 in e.g. DFS that now stall things that used to work.

 ..http://www.free3d.org/ for X tweak benchmarks. ;o)

 ..your X log is taken after a FG run?
No, but I checked it again just now after running FG and nothing had been added.

 Anything in dmesg output?
No, nothing there either.

Again, I appreciate you taking a look. You've given me good some ideas
for further research, namely, looking at the KMS radeon driver sources
for authoritative info on the different driver options. My config file
hadn't been updated for a while and some of the options weren't even
recognized any more.

My other idea is to grovel through the FG code that loads/executes
shaders, and look for something that indicates whether they worked or
not - just plug in some calls to printf(), and try to see what's
happening in there.


 FlightGear console output:
 http://www.mediafire.com/?w49t2gc4iihu6gg


 --
 ..med vennlig hilsen = with Kind Regards from Arnt... ;o)
 ...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three:
  best case, worst case, and just in case.

 --
 Beautiful is writing same markup. Internet Explorer 9 supports
 standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
 Spend less time writing and  rewriting code and more time creating great
 experiences on the web. Be a part of the beta today.
 http://p.sf.net/sfu/beautyoftheweb
 ___
 Flightgear-devel mailing list
 Flightgear-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/flightgear-devel


--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel