Re: [Wesnoth-dev] About the name of my translation ( ¿conclusion?)
On Tue, Oct 14, 2008 at 9:37 PM, John McNabb <[EMAIL PROTECTED]> wrote: > So, why can't we have three (or more) translations: Catalan, Valencian, > Valencian(RACV), Valencian(l337), Valencian(klingon), etc... I know someone who actually speaks Klingon, or at least he did as a kid, he even was guest in some TV talk show with it - I can ask if he wants to help with that last variant if we really want Wesnoth translated to it :) ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] State of UtBS and DM
On Wed, Nov 19, 2008 at 3:32 AM, John W Bjerk <[EMAIL PROTECTED]> wrote: > UTBS is the campaing i have the fondest memories of, and i applaude > efforts to fix it up to mainline standards. > Same here, it's the one campaign which made me start contribute to the game and I was quite disappointed when I read it's being removed, and quite relieved now knowing someone works on it who can make sure it will be put back :) I would help but I'm somewhat out of time right now, not even reading forums or IRC currently. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Translation process
On Mon, Nov 24, 2008 at 5:13 PM, Fabian Mueller <[EMAIL PROTECTED]> wrote: > Vladimír Slávik wrote: > > ... >> * Tool that shows colored inline per-word diff of messages to speed up >> revision of updates. Skim what's new instead of diffing and extracting >> and manual comparison of different files. It can be read-only, even >> produce output as html - primary intention is to revise what was done, >> edits to the actual text can be made aside in editor after assessing >> situation. (A bit tricky would be matching fuzzy entries together so >> that you can actually diff them. > ... > > I am not sure if I do understand your needs right. > But if you need a graphical frontend to the diff command I can recommend > the little tkdiff tool which is part of at least every debian based > distribution. > It has that colored inline per-word diff feature. > What would be nice would be something so poedit itself could show you what changed - back when I was translating I also found it annoying when a string was marked "fuzzy" but I had no idea what did change in the English text. (And going through huge diffs to find the change for each single string is rather time consuming no matter which diff program). But not sure there exists a solution. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] 1.7 design direction and the great Python shift
On Fri, Jan 2, 2009 at 5:25 PM, Mark de Wever wrote: > The Python bindings we currently use are ref counted, so if somebody > fails there the garbage collection will fail and you still have a memory > leak. > This could be solved by using different bindings, like Boost::Python (or SWIG or pyrex or ...). Ivan, is there some specific reason you use the low-level Python-C-API for this? ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] summary upload
> I noticed that someone locked the thread incorrectly claiming there was no > more to discuss. > > I think a nice feature would be popup every time the data was going to be > sent that would a remind someone that they have the feature on and let them > OK or cancel sending the data on a case by case basis. > This sounds like a good idea. Also could have a "don't ask again" checkbox so it wouldn't get annoying (and a way to turn it on again from the preferences menu). > Also of note is that some people have dial on demand networking and don't > want some app triggering phone calls, regardless of the privacy implications. > > This could also get someone in trouble. They may for example have to explain > to a security officer from their work why their computer was attempting to > connect to the Wesnoth project's server. > Sounds like legitimate arguments - Wesnoth after all is a single player game and not a web-browser, so broadcasting data without user consent is a quite different issue for it. And the note displayed when you first start is really insufficient - at least instead of a note it should be a dialog where you have to check "I agree to sending data" or something like that. But your popup idea above sounds like the best solution to me. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Sun, Feb 22, 2009 at 6:08 PM, Nils Kneuper wrote: > > Long mail cut short: > What about 1.6? Should we got for 1) or for 2)? Or does anyone of you have > even > a better idea what we should do? > Personally I vote for 2) since PythonAI is not really used and it would reduce > the (possible) security problems with it to zero (not to speak about the > positive impact on packagers with less dependencies). > I'd also say, go for 2. The current PythonAI implementation had two big design problems from the start. First, it uses the C-Python API which is very low-level and makes it hard to maintain. This means, it's not a big loss removing this version - if Python scripting is wanted, better start fresh with Boost::Python or similar. Second, no thought was spent on security when it was first implemented. Historically, when I was taking over maintenance of it for some time, I first added code to the campaign server to disallow Python scripts until someone would verify it (this is essentially the security model used by most other projects allowing Python scripting). Later someone provided us with the safe.py wrapper - but the idea was flawed from the beginning. For one, it removed a lot of the Python language features, so scripts aren't really Python any longer. And it adds a lot more maintenance burden again, apparently neither the "queue" nor the "threading" module were safe to whitelist - the original author of safe.py likely would have known that, but I did not. Casically, Python does not support sandboxing - but I think it's a feature we much should require for Wesnoth scripting. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Mon, Feb 23, 2009 at 3:40 PM, Greg Copeland wrote: > > I'm very pro-python. I'm the author of what was the start of the wail > module. Having tried to work within the confines of the existing > infrastructure, I do not see Python as a viable scripting option. Safe.py is > nothing but a headache disguised as security. In my opinion safe.py is the > single reason python scripting never went anywhere. It prevents access to > the majority of python's language features, modules, and is the single > reason why everything is low level. In short, safe.py prevents access to > what is commonly known as the python language. Until a security model or > acceptable security policy is endorsed, there exists no reason to provide > python as a scripting language. We had Python support for years without safe.py or any restrictions at all. So this can't have been the problem. It was more that the API was really low level. All it ever did was export some AI related C++ classes. And the resulting scripts were very complicated and un-pythonic. If we had had something like your wail module from the beginning, I'm sure it would have been used much more. Also, the real reason to use scripting is not to write new AIs from scratch, but to augment the existing AI, and to script WML events. Both are not possible with the current PythonAI. Give items to units, modify terrain, create new user interfaces elements, ... endless things which make scripting fun and useful. But nothing of it was possible. And this is all independent of security. > I personally would prefer for users be forced to police their own security. > In doing so we could offer a dual environment. One where safe.py is used and > requires no user interaction. The other where users are alerted to the > potential security risk and must accept or reject the risks associated with > a script. In turn this opens the door for python to actually have value and > for high level interface abstractions to be created. Unless something like > this is accepted, I do not see python as a viable solution for Wesnoth. > Yes, and the model where you can execute any WML (with or without scripts embedded) clearly is the nicer one for a game like Wesnoth. The only way to get that with Python would be some kind of sandboxing module, but it does not exist (safe.py was the best you could get in that direction). So let's hope for a nice Lua scripting interface now. Once the Python developers provide a sandbox module (or someone implements a safe Python interpreter), it should be very easy to hook this to the then proven scripting interface (with the only change that you could use Python instead of Lua to access the scripting API). ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Mon, Feb 23, 2009 at 10:50 PM, wrote: > > My point is that there has been a call out for a long time -- for > years -- that anyone wanting to make a nice API to Python for AI > purposes and then to write a nice AI can. If this API doesn't sandbox > Python, that's fine, we just wouldn't allow easily downloadable AI's > using it. > I don't think this has anything to do with the language. None of the projects to write a better C++ AI we had going on back then ever produced any results. It doesn't mean C++ is necessarily a bad language for writing AI code. It just shows that the C++ base of Wesnoth does not export an API which can be used for writing AIs which are more complex than the default one. Exporting a bad API to any language (it was only done for Python, out of all possible languages) will not magically improve this API. At least if it's a 1:1 mapping like the one the PythonAI made. Greg's wail module would have improved this, but it was hampered by the sandboxing - and at the time he joined the project sandboxing already was a requirement. > Out of all this all we have gotten is a crappy API and no decent AI's. > That is what doesn't bode well for Python. > I agree, It doesn't bode well for Python as a language to use for game scripting. But in this case, it just means the missing sandboxing makes it the wrong choice of tool in the first place. Python would be an ideal language to re-write the C++ parts of Wesnoth in my opinion. But even in a rewrite of Wesnoth in Python, it would still use WML for its data files, and still would use Lua scripting (once we have that). If at some point in the future someone writes a Python interpreter which can be sandboxed, this would need to be re-evaluated, I think then it would be the ideal choice also for scripting. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] build system evaluation (autotools/cmake/scons)
On Mon, Feb 23, 2009 at 9:21 PM, Sergey Popov wrote:
> На Mon, 23 Feb 2009 19:41:32 +0100
> Alexander Neundorf wrote:
>
>> It is a feature that cmake is no general purpose language. This discourages
>> people from turning the build scripts into real programs.
>> This can happen if you have full available,
>> it's what I saw when we tried to use it in KDE and what I heard from others.
> Build scripts *are* real programs, no matter in what programming language
> they're
> written, cmake or no. There's no value in restricting options available to
> you.
It definitely is a general purpose language, for example if you look
at the toplevel CMakeLists.txt in Wesnoth it has parts like this:
foreach(LANGFILE ${LANGS})
string(REGEX REPLACE "(.*)\\.cfg" "\\1" LANG ${LANGFILE})
if(NOT LANG STREQUAL "C")
set(DUMMY_LOCALE_DIR ${CMAKE_SOURCE_DIR}/locales/${LANG})
It's a rather easy to understand language once you are used to the
syntax of course - but still, why write an interpreter for a new
language (and force cmake users to learn it) when you could have used
an existing language?
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] possible security problems (eg with current python implementation)
On Tue, Feb 24, 2009 at 7:13 PM, Patrick Parker wrote: > I'd like to point out that security issues aren't the only problem for our > Python AI's. > There's also stands the unresolved issue with redistribution of msvcr71.dll > on Windows. > True, forgot about this, so besides the security issue and the flawed API, it was a third reason to remove it. > > Furthermore, in response to allefant, I really don't think the mailing list > is the appropriate place to be debating the numerous tradeoffs of Lua OR > Python as replacements for scripting WML [event]s, especially since (by your > own admission) you are not among our resident WML experts. You might want to > take that up in the forum, where such debates have already existed for some > time now: > > http://www.wesnoth.org/forum/viewtopic.php?f=2&t=19082 > Yes, any possible future AI or scripting additions should be discussed on the forum of course. Just was trying to clarify why I think the PythonAI failed - just generally blaming "Python" would be a bit simple-minded and not help prevent similar problems in the future. Ivanovic mentioned work on Lua scripting in the initial post of the thread - so my impression was this already is or will soon be available in SVN, I wouldn't really have suggested it otherwise :) ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] The new Mac App Store
On Fri, 2011-01-14 at 16:34 -0500, Ben Anderman wrote: > If it were put on the store for free, I would be willing to do it for > free. However, I think this is a potential revenue stream for Wesnoth > which is less problematic than iOS, since users really will be able to > get the same thing free from the website if they want to. And I don't > see any reason not to take advantage of it (the legalities aren't any > different if it's paid or free, as far as I know). If it were to cost > something (the minimum is $0.99), then I would want some amount. 10% > was only a suggestion though, and I'm open to other suggestions. > Apple also takes 30%, which seems wrong to me - in return for being so anti-open-source they would now get even more revenue from Wesnoth. A free version (and covering your extra expenses for the dev license and additional upload b/w) sounds like a better idea to me. And if the Wesnoth project is too short on money for that maybe ask for donations - but not have the donations depend on choice of download location. -- Allefant ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Research project on (end-)users participation in Free Software - Interviewees recruitment
On Thu, 2011-03-24 at 16:08 +0100, Giacomo Poderi wrote: > PARTICIPANTS > - Anyone subscribed to the -dev mailing list and who contributes (or > contributed in the past) to the furthering of the BfW project is > eligible for and welcome to participate to the interview! > Limiting to -dev list subscribers may exclude some main contributors since many things seem to be more coordinated on the forums (and IRC) than here. So well, just saying you may want to post this on the forums as well if you haven't already and if your goal is to have a possibly larger number of volunteers. (Oh, and I'd be willing to do that interview if it helps, but I'm only a minor contributor...) -- Allefant ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] OpenMP conclusions
On Thu, 2011-04-14 at 18:22 +0200, David Philippi wrote: > Am Thursday 14 April 2011 schrieb Paul Ebermann: > > This does not help on the short term, but might result in this feature > > being implemented before Wesnoth 1.10 comes out. > > There should be a very simple workaround. Use a wrapper that sets the > variable > then does an exec of the real wesnoth binary. Might be a shell script or a > binary executable, whatever works best. > If a binary can be used, then could the real wesnoth binary exec itself with the modified environment (and a command-line argument preventing execing itself again)? -- Allefant ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] OpenMP conclusions
On Thu, 2011-04-14 at 18:54 +0200, Allefant wrote:
> On Thu, 2011-04-14 at 18:22 +0200, David Philippi wrote:
> > Am Thursday 14 April 2011 schrieb Paul Ebermann:
> > > This does not help on the short term, but might result in this feature
> > > being implemented before Wesnoth 1.10 comes out.
> >
> > There should be a very simple workaround. Use a wrapper that sets the
> > variable
> > then does an exec of the real wesnoth binary. Might be a shell script or a
> > binary executable, whatever works best.
> >
>
> If a binary can be used, then could the real wesnoth binary exec itself
> with the modified environment (and a command-line argument preventing
> execing itself again)?
>
Well, guess I can answer that myself:
int main(int argc, char **argv) {
if (!getenv("OMP_WAIT_POLICY")) {
setenv("OMP_WAIT_POLICY", "PASSIVE", 1);
execv(argv[0], argv);
}
return 0;
}
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] moving to git - it's ready to happen
The git repository on SourceForge has 1.6 GB. Only the git checkout has 2.6 GB (since it has a copy of all the data files outside of .git). On Thu, Mar 28, 2013 at 2:15 PM, Andrius Štikonas wrote: > > >> > That sounds a bit much. Shouldn't that be about the size of a >> > git-svn clone of the current subversion repository (1.5 GB)? >> > Did you purge the relics from git history rewrites? > > >>a git repository should have a size similar to the subversion SERVER since it > contains all the history, not just the subversion checkout > > git-svn also has all history. So git repository should have a similar size > (currently ~1.8 GB) as git-svn clone. On the other hand subversion SERVER has > uncompressed data, so it must have much larger size. > > > > ___ > Wesnoth-dev mailing list > Wesnoth-dev@gna.org > https://mail.gna.org/listinfo/wesnoth-dev ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] make install on OS X doing something bad
Would need someone who knows where python modules should be installed to. E.g. distutils from python seem to just install to pythons library path by default: http://docs.python.org/inst/standard-install.html#SECTION00024 Which I think is what Wesnoth's custom autotools code currently copies. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Choosing a new build system
SilverTree does have a scons build (at least for unix and windows/mingw): http://silvertree.googlecode.com/svn/trunk/SConstruct So that way, everyone can have a glimpse what a build script comparable to Wesnoth would look like. What should be noted, this single script builds both game and editor without needing extra files in various subfolders, and it also does all the autotools-like checking of various stuff. However, it will need some tweaking to also work on windows/VC and OSX - not really sure how much. And as scons uses its own (compared to make, more advanced) dependency tracking algorithms, there can be no way to produce makefiles or VC or XCode project files. Myself, I can't really endorse any build system, since I'm biased to scons/WAF by my like of Python. But in another project (a library with a bit more complex build system requirements than Wesnoth), we right now maintain three build systems in parallel (autotools, cmake and scons), so I can say what my experience with it is: 1) scons/cmake are both vastly superior to autotools in maintanance work required (nobody in that project knows M4, and for windows we needed a lot of extra solutions as we don't require msys/cygwin) 2) scons and cmake both are not perfect and will from time to time require messing around with things which should have just worked, so hopes should not be *too* high 3) Maintaining more than one build system is stupid, it doubles (or in the case of that project, triples) the amount of work :P ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Choosing a new build system
On Jan 25, 2008 5:31 PM, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > > Problems with particular build scripts are also less likely to get > noticed. If you don't have someone who knows all of the build systems in use, > you have to have different people modify them for new additions and I suspect > this makes it easier to have problems in some of the build systems. Indeed. Instead of one system working good, there are multiple half-working ones (e.g. in my case, I maintain the scons build, so it's almost untested for Windows with VC and for OSX). I also just noticed, I lied about the scons build of SilverTree being a single file, the various config tests are imported from additional files: http://silvertree.googlecode.com/svn/trunk/scons/ But anyway, apparently ESR already started creating a prototype scons build for Wesnoth, so that will give a much better impression of what it looks like :) ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
