You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(11) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(68) |
Feb
(194) |
Mar
(75) |
Apr
(44) |
May
(48) |
Jun
(29) |
Jul
(60) |
Aug
(74) |
Sep
(12) |
Oct
(13) |
Nov
(30) |
Dec
(62) |
| 2003 |
Jan
(63) |
Feb
(28) |
Mar
(63) |
Apr
(27) |
May
(53) |
Jun
(8) |
Jul
(17) |
Aug
(2) |
Sep
(95) |
Oct
(28) |
Nov
(36) |
Dec
(24) |
| 2004 |
Jan
(92) |
Feb
(47) |
Mar
(43) |
Apr
(86) |
May
(64) |
Jun
(10) |
Jul
(4) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
(4) |
Mar
(3) |
Apr
(5) |
May
|
Jun
|
Jul
(14) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(7) |
| 2006 |
Jan
(1) |
Feb
(4) |
Mar
(14) |
Apr
(22) |
May
(51) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
(25) |
Dec
(1) |
| 2007 |
Jan
|
Feb
(7) |
Mar
(80) |
Apr
(27) |
May
(15) |
Jun
(6) |
Jul
(25) |
Aug
(1) |
Sep
(3) |
Oct
(17) |
Nov
(174) |
Dec
(176) |
| 2008 |
Jan
(355) |
Feb
(194) |
Mar
(5) |
Apr
(28) |
May
(49) |
Jun
|
Jul
(28) |
Aug
(61) |
Sep
(61) |
Oct
(49) |
Nov
(71) |
Dec
(2) |
| 2009 |
Jan
(12) |
Feb
(216) |
Mar
(299) |
Apr
(257) |
May
(324) |
Jun
(222) |
Jul
(103) |
Aug
(127) |
Sep
(72) |
Oct
(76) |
Nov
(2) |
Dec
(23) |
| 2010 |
Jan
(23) |
Feb
(11) |
Mar
(11) |
Apr
(112) |
May
(19) |
Jun
(37) |
Jul
(44) |
Aug
(25) |
Sep
(10) |
Oct
(4) |
Nov
(5) |
Dec
(25) |
| 2011 |
Jan
(44) |
Feb
(19) |
Mar
(18) |
Apr
(3) |
May
(14) |
Jun
(1) |
Jul
(22) |
Aug
(7) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(51) |
Feb
(42) |
Mar
(9) |
Apr
(9) |
May
(2) |
Jun
(29) |
Jul
(47) |
Aug
(5) |
Sep
|
Oct
(38) |
Nov
(33) |
Dec
(13) |
| 2013 |
Jan
|
Feb
(7) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(2) |
Sep
(9) |
Oct
(22) |
Nov
(18) |
Dec
(7) |
| 2014 |
Jan
(2) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
(24) |
May
|
Jun
(18) |
Jul
(10) |
Aug
(21) |
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: jderekmiller <jde...@pa...> - 2022-06-19 18:52:36
|
Colossus https://www.google.com/search?q=c...@li... |
|
From: jderekmiller <gil...@gl...> - 2020-05-20 23:28:11
|
colossus developers https://bit.ly/36itIb7 Monitor arms let you position your display (or displays) at any height or angle, and re-position… Preparing also means knowing what type of setup will be used. Will the mics be handheld or clip-on? Will you have stools? Seats? A podium? How close will the audience be to the stage? pgmcb nuagist Rexanne ovorhomboid dMenno superstructures archways infanticidal |
|
From: jderekmiller <ar...@gr...> - 2019-12-12 07:54:34
|
colossus developers http://fightfinger.xyz/4dMoqXL/expansionary/ jderekmiller relocate When you splurge on a cheese that's $20 per pound, you're going to want to keep it fresh for as long as you possibly can. But that doesn't mean you have to spend another $9 for a box of cheese papers. In fact, you can preserve cheese well with products you probably already have at home. ankles growers arbitrated stripier chestnuts hkqpt predevised punts The Holiday 'I Overdid It' Syndrome: 6 Ways to Keep Spending, Eating and Indulging in Check LearnVest stemlike lyaomoplate anticipating In all, the courses will take over 90 hours to complete, but if you've ever wanted to get serious about making your own app, there's no time like the present. determining hook-armed |
|
From: Craig L. <c_...@rp...> - 2018-01-29 11:57:01
|
good afternoon Colossus https://goo.gl/TWNf1E Craig |
|
From: emprdranathi <emp...@wo...> - 2018-01-14 20:19:22
|
Hey Colossus https://goo.gl/QG6J6d emprdranathi |
|
From: Craig L. <c_...@ha...> - 2016-04-03 08:14:39
|
Hi colossus http://followhelen.com/Dick.php?general=1u3nfd7h0pa0 Craig Lish |
|
From: madafu87 <mad...@ka...> - 2016-04-02 17:18:44
|
Hi colossus http://www.anamorphose-conseil.fr/pet.php?ride=1pxhkv3x5f8p9t |
|
From: Clemens K. <cle...@cl...> - 2016-01-21 21:28:19
|
Hi folks, I have made a new "official" build - 2016-01-21. Enjoy! All the best, -Clemens |
|
From: Clemens K. <cle...@cl...> - 2015-12-15 21:17:24
|
Hello world, I have made a new "Public Build". Please give it a try! Thx, Clemens |
|
From: David R. <dr...@ri...> - 2015-11-27 04:10:43
|
On 11/26/2015 03:08 AM, Nor...@gm... wrote: > i've a general question. i'm interested in the general stategy an AI > player has during the battle on battlelands. > > Is there anywhere a document where something like a priority list or an > algorith is given which units are attacked prefered (within the rules of > course) and which fiels are occupied depending on AI engine and/or > battle land and/or unit? > > I do not need necessarily programming code, I'm only searching for > general rules for the battles. If something is also available for the > strategic map in would be nice, but this is secondarily. Sorry, no. Here's the best I can do in a few minutes: Things that make a battle AI for Titan hard: 1. Branching factor. If you have a defending legion of 7 different skill 4 creatures entering the plains, each can visit 3+4+5+6 = 18 hexes. So there are 18*17*16*15*14*13*12 = 160392960 possible moves. (Compared to something like 40 possible moves in a typical chess position.) Just enumerating them all takes a long time. Meaningfully evaluating all the moves just for one turn in a reasonable amount of time is pretty hard. 2. Randomness. You can't say "if I do this then this will happen." You have to say "if I do this then this will happen with probability p." In combination with the branching factor, this makes a brute force tree search AI, where you try all combinations of moves and counter-moves several turns ahead and evaluate at the end, impossible. 3. Strategic concerns. The battle is not the whole game (unless it's Titan on Titan between the last 2 players). So there are other concerns besides just winning, or just damaging the opponent as much as possible. Sometimes you want to avoid summoning an angel because another battle needs it more. Sometimes you want to avoid recruiting a reinforcement because you're probably going to lose anyway and don't want to hand over more points. Often you want to flee to give fewer points, or keep the opponent from recruiting. (Note: SimpleAI doesn't really take this into account. There's a simple rule for fleeing based on the relative values of the legions -- if you have no chance, flee. Otherwise it fights as well as it can, even when that's dumb. But there's a newer AI called ExperimentalAI that has multiple objectives and switches its behavior.) Anyway, our original AI (SimpleAI) is a bunch of heuristics. The first goal is to get the entire legion on board. (And if it's not possible because of slow creatures in unfriendly terrain, at least get the better creatures on board.) Another major goal (at which we've historically been bad) is to protect the Titan. (But this is another tradeoff because the Titan is one of the stronger characters, so you want to use it, just not expose it too much.) Another one is for the attacker to press the attack to avoid a time loss. (But a time loss is better than a regular loss.) So what we do is allow each creature to independently figure out the hex it wants to move to, not taking its mobile allies into account. (Because creature moves have a much smaller branching factor than whole-legion moves. In the case above, you end up with 7*18=126 creature moves.) It's based on a lot of heuristics like wanting to get to good terrain and avoid bad terrain, wanting to close with the enemy if attacking, wanting to damage enemies and avoid damage to itself (which favors rangestriking), etc. Once each creature has figured out its 7 favorite hexes in isolation (7 because if we have 7 creatures in the legion and they all want the same hexes, one of them will have to settle for its 7th choice), we can construct legion moves with a branching factor of no more than 7 ** 7 = 823543. Then we can start evaluating those, in random order so that if we run out of time we've at least looked at a reasonable sample. When we finally pick a legion move, we then have to figure out an order of creature moves that makes it possible, but that's pretty easy. The actual evaluation function in Colossus isn't very good. There are 36 constants that you can look at in: https://github.com/cleka/colossus-titan/blob/adf5bab8826493b77387126711e4c2afbf3f83fa/Colossus/core/src/main/java/net/sf/colossus/ai/helper/BattleEvalConstants.java It's very hard to hand-tune a combination of 36 constants. In Slugathon I created a genetic algorithm to tune them -- basically each AI consists of a randomized vector of these constants, and I track game results and play a bunch of automated AI games, and the AIs that win more get to breed, and in theory after many generations you get a better AI. While it's neat, the problem is that this technique really only finds a local optimum rather than truly novel ideas; you're only changing constants, not code. Actually coming up with new heuristics takes human thinking. Another problem is that most of my test data is AI vs. AI fights, so we're tuning the AI to beat other AIs, not to beat humans (which is the real goal). -- David Ripton dr...@ri... |
|
From: Clemens K. <cle...@cl...> - 2015-11-26 09:15:51
|
Hello Norbert, I am afraid for the battles, there is no such document, only the programming code. And it is not so much oriented in "priority lists", rather on calculating points (good or bad) for certain aspects. The overall approach I would summarize as this (other developers might have a slightly different view ;-) : It generates (mostly randomly) combinations of possible "which creature could go where (in theory, based on it's reach)". For each such combination, it verifies, is there actually a sequence that all creatures could reach those places. For working ones, it evaluates a number of aspects, which results in a value for this combination, keeping the best one in mind. If there is still time, it generates a next set of combinations and does the same. When time is over, it does the combination with the best value. Examples for points to be given: - non-native creature on field that does damage (tundra): minus - non-native creature on field that causes disadvantage (bramble, sand, below slope/dune/wall): minus - native creature on field where it has advantage (bramble, dune): plus - titan in risk of being hit: minus - titan has very high power factor (e.g. 1000 points, titan power = 16): less vulnerable, reduces the titan in risk number - more-than-one against one other: plus - one-against-several: minus - battle turn number grows, and is attacker: more aggressively - defender might give minus for creatures that could reinforce being in danger And so on. Above are just examples I made up. Our different AIs mostly differ in the parameters which aspect gives which value. I don't even know whether there is a specific evaluation for "which creature to aim for most". I remember there was work ongoing to define certain primary overall "objectives" (e.g.: protect titan; strip vs. destroy; kill first creature quickly to be able to summon). There might be something to give points for being able to strike e.g. a) strongest creatures or b) native creatures, i.e. those which could reinforce. One of the AIs tries to do some kind of "genetic" approach, by generating the next set not "merely randomly" but instead by doing crossovers between some very good ones and perhaps some very bad ones from previous sets. But I am not sure whether our AIs are a good example to study (or even take as model for building an own), because generally they are considered rather weak. Even a mediocre player will more often win than loose. If you develop a good approach, let us know, perhaps we can get better AIs from it. Better yet, you are very welcome to develop your own AI and try out approaches. I am willing to guide you how to get started, or even discussions about pro or cons. > If something is also available for the strategic map in would be > nice, but this is secondarily. Some overall strategy guidelines you might find from this link: http://www.desjardins.org/titan/strategy.txt It's intended for humans, though ;-) Hope that helps, with Greetings to Good Old Germany, Clemens On 2015-11-26 10:08, Nor...@gm... wrote: > Dear developers, > > i've a general question. i'm interested in the general stategy an AI > player has during the battle on battlelands. > > Is there anywhere a document where something like a priority list or > an algorith is given which units are attacked prefered (within the > rules of course) and which fiels are occupied depending on AI engine > and/or battle land and/or unit? > > I do not need necessarily programming code, I'm only searching for > general rules for the battles. If something is also available for the > strategic map in would be nice, but this is secondarily. > > Best regards. > Norbert |
|
From: <Nor...@gm...> - 2015-11-26 08:09:02
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> </div> <div class="signature">Dear developers,</div> <div class="signature"> </div> <div class="signature">i've a general question. i'm interested in the general stategy an AI player has during the battle on battlelands.</div> <div class="signature"> </div> <div class="signature">Is there anywhere a document where something like a priority list or an algorith is given which units are attacked prefered (within the rules of course) and which fiels are occupied depending on AI engine and/or battle land and/or unit?</div> <div class="signature"> </div> <div class="signature">I do not need necessarily programming code, I'm only searching for general rules for the battles. If something is also available for the strategic map in would be nice, but this is secondarily.</div> <div class="signature"> </div> <div class="signature">Best regards.</div> <div class="signature">Norbert</div> <div class="signature"> </div> <div class="signature"> </div></div></body></html> |
|
From: Peter B. <pe...@pe...> - 2015-08-28 09:46:33
|
SnapCI goes back to JDK6: https://docs.snap-ci.com/the-ci-environment/languages/java/ CircleCI does the same: https://circleci.com/docs/environment#java and so do Drone.io and Shippable: - http://docs.drone.io/java.html - http://docs.shippable.com/languages/#java CodeShip goes back to 7 only: https://codeship.com/documentation/languages/java-and-jvm-based-languages/ And Wercker doesn't know Java: http://devcenter.wercker.com/docs/languages/index.html There are others, but we are getting rather exotic by now. Part of the problem might be a lack of an OpenJDK for Java 5. The other part is the age: even in Enterprise World I haven't seen anyone on Java 5 for a while, Java 6 is pretty much gone, Java 7 is still deemed acceptable it seems -- despite being out of public updates. Java 5 ended 6 years ago, that's a long time in IT :-) Peter On 28/08/2015 7:31 PM, Peter Becker wrote: > Travis goes back to OpenJDK 6, but not further: > http://docs.travis-ci.com/user/languages/java/ > > I'll check for some alternatives, but I JDK 5 is pretty ancient by now. > > Peter > > On 28 August 2015 7:19:33 pm AEST, Clemens Katzer > <cle...@cl...> wrote: > > > On 2015-08-28 11:07, Peter Becker wrote: > > You might want to see if you can build against an older JDK on > Travis or an equivalent service. I'm writing this on the > phone, so it's a bit tricky to check - I can do some research > on the weekend if you want me > > > yes, that would be nice. > > Thx, > Clemens > > to. Peter On 28 August 2015 3:58:32 pm AEST, Clemens Katzer > <cle...@cl...> wrote: > > On 2015-08-28 04:19, Barrie Treloar wrote: > > On 28 August 2015 at 07:07, Peter Becker > <pe...@pe... [2]> wrote: > > One note of warning: unless you compile against a > corresponding JDK > > Good point. So at least should compile it against an 1.5 > every then and now. > > nothing will stop you from picking up a method > that won't be in an earlier JDK. The result is a > NoSuchMethodException (or something like that) at > runtime. And there is plenty of innocent looking > stuff like this one, which was introduced in 1.6: > > http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty > > > [1]() > > [1] The only safe ways are to compile against the > target JDK or to use static code analysis tools. > > Every then and now against a 1.5 JRE is much easier. Could > have one in a virtual machine; or, even on main PC, it > just needs to be unpacked in some folder, right? So no > need to "officially" install with Yum. And, github has a > Jenkins, right? So one job there could do the job. Though > I would have to push more often, but then, main thing is > to ensure it before making a build that the whole wild > world will use. thanks, but... I've not used it but maven > animal sniffer plugin will throw exceptions in case like > this. > > Links: ------ [1] > http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty > [2] > https://lists.sourceforge.net/lists/listinfo/colossus-developers > [3] http://stackoverflow.com/a/4451057/552958 > > > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Colossus-developers mailing list > Col...@li... > https://lists.sourceforge.net/lists/listinfo/colossus-developers |
|
From: Peter B. <pe...@pe...> - 2015-08-28 09:31:49
|
Travis goes back to OpenJDK 6, but not further: http://docs.travis-ci.com/user/languages/java/ I'll check for some alternatives, but I JDK 5 is pretty ancient by now. Peter On 28 August 2015 7:19:33 pm AEST, Clemens Katzer <cle...@cl...> wrote: > > >On 2015-08-28 11:07, Peter Becker wrote: >> You might want to see if you can build against an older JDK on Travis >> or an equivalent service. I'm writing this on the phone, so it's a >> bit >> tricky to check - I can do some research on the weekend if you want >> me > >yes, that would be nice. > >Thx, >Clemens > >> to. >> >> Peter >> >> On 28 August 2015 3:58:32 pm AEST, Clemens Katzer >> <cle...@cl...> wrote: >> >>> On 2015-08-28 04:19, Barrie Treloar wrote: >>>> On 28 August 2015 at 07:07, Peter Becker <pe...@pe... >>>> [2]> >>>> wrote: >>>> >>>>> One note of warning: unless you compile against a corresponding >>>>> JDK >>> >>> Good point. So at least should compile it against an 1.5 every then >>> and >>> now. >>> >>>>> nothing will stop you from picking up a method that won't be in >>>>> an >>>>> earlier JDK. The result is a NoSuchMethodException (or >>>>> something >>>>> like >>>>> that) at runtime. >>>>> >>>>> And there is plenty of innocent looking stuff like this one, >>>>> which >>>>> was >>>>> introduced in 1.6: >>>> >>>> >>> >> >> >http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty >>>> [1]() >>>> >>>>> [1] >>>>> >>>>> The only safe ways are to compile against the target JDK or to >>>>> use >>>>> static code analysis tools. >>> >>> Every then and now against a 1.5 JRE is much easier. Could have one >>> in a virtual machine; or, even on main PC, it just needs to be >>> unpacked >>> in some folder, right? So no need to "officially" install with Yum. >>> >>> And, github has a Jenkins, right? So one job there could do the job. >>> Though I would have to push more often, but then, main thing is to >>> ensure it >>> before making a build that the whole wild world will use. >>> >>> thanks, but... >>> >>> I've not used it but maven animal sniffer plugin will throw >>> exceptions >>> in case like this. >> >> >> Links: >> ------ >> [1] >> >http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty >> [2] https://lists.sourceforge.net/lists/listinfo/colossus-developers >> [3] http://stackoverflow.com/a/4451057/552958 |
|
From: Clemens K. <cle...@cl...> - 2015-08-28 09:19:43
|
On 2015-08-28 11:07, Peter Becker wrote: > You might want to see if you can build against an older JDK on Travis > or an equivalent service. I'm writing this on the phone, so it's a > bit > tricky to check - I can do some research on the weekend if you want > me yes, that would be nice. Thx, Clemens > to. > > Peter > > On 28 August 2015 3:58:32 pm AEST, Clemens Katzer > <cle...@cl...> wrote: > >> On 2015-08-28 04:19, Barrie Treloar wrote: >>> On 28 August 2015 at 07:07, Peter Becker <pe...@pe... >>> [2]> >>> wrote: >>> >>>> One note of warning: unless you compile against a corresponding >>>> JDK >> >> Good point. So at least should compile it against an 1.5 every then >> and >> now. >> >>>> nothing will stop you from picking up a method that won't be in >>>> an >>>> earlier JDK. The result is a NoSuchMethodException (or >>>> something >>>> like >>>> that) at runtime. >>>> >>>> And there is plenty of innocent looking stuff like this one, >>>> which >>>> was >>>> introduced in 1.6: >>> >>> >> > > http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty >>> [1]() >>> >>>> [1] >>>> >>>> The only safe ways are to compile against the target JDK or to >>>> use >>>> static code analysis tools. >> >> Every then and now against a 1.5 JRE is much easier. Could have one >> in a virtual machine; or, even on main PC, it just needs to be >> unpacked >> in some folder, right? So no need to "officially" install with Yum. >> >> And, github has a Jenkins, right? So one job there could do the job. >> Though I would have to push more often, but then, main thing is to >> ensure it >> before making a build that the whole wild world will use. >> >> thanks, but... >> >> I've not used it but maven animal sniffer plugin will throw >> exceptions >> in case like this. > > > Links: > ------ > [1] > http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty > [2] https://lists.sourceforge.net/lists/listinfo/colossus-developers > [3] http://stackoverflow.com/a/4451057/552958 |
|
From: Peter B. <pe...@pe...> - 2015-08-28 08:07:23
|
You might want to see if you can build against an older JDK on Travis or an equivalent service. I'm writing this on the phone, so it's a bit tricky to check - I can do some research on the weekend if you want me to. Peter On 28 August 2015 3:58:32 pm AEST, Clemens Katzer <cle...@cl...> wrote: > > >On 2015-08-28 04:19, Barrie Treloar wrote: >> On 28 August 2015 at 07:07, Peter Becker <pe...@pe... [2]> >> wrote: >> >>> One note of warning: unless you compile against a corresponding JDK > >Good point. So at least should compile it against an 1.5 every then and > >now. > > >>> nothing will stop you from picking up a method that won't be in an >>> earlier JDK. The result is a NoSuchMethodException (or something >>> like >>> that) at runtime. >>> >>> And there is plenty of innocent looking stuff like this one, which >>> was >>> introduced in 1.6: >>> >> >> >http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty() >>> [1] >>> >>> The only safe ways are to compile against the target JDK or to use >>> static code analysis tools. > >Every then and now against a 1.5 JRE is much easier. Could have one >in a virtual machine; or, even on main PC, it just needs to be unpacked >in some folder, right? So no need to "officially" install with Yum. > >And, github has a Jenkins, right? So one job there could do the job. >Though I would have to push more often, but then, main thing is to >ensure it >before making a build that the whole wild world will use. > > >thanks, but... > >> I've not used it but maven animal sniffer plugin will throw >> exceptions >> in case like this. > >If somebody is willing to port this to maven - be my guest. I won't do >that >and struggle with a "dubious" (well at least badly documented) plugin >if >there are easier ways to achieve things. > >Besides, what I hear Maven is "obsolete", Cradle is "in" now... No? > > >> The documentation is not great, >> http://stackoverflow.com/a/4451057/552958 [3] should give you enough >> to get going to enforce this on the minimum jre you want to run on >> and >> allow some comfort on the jdk you want to build against. >> > >So thank you very much for your advice/suggestions, but I will try >one of the above. Probably unpack the JRE to somewhere. > > >All the best, >Clemens > > > >------------------------------------------------------------------------------ >_______________________________________________ >Colossus-developers mailing list >Col...@li... >https://lists.sourceforge.net/lists/listinfo/colossus-developers |
|
From: Peter B. <pe...@pe...> - 2015-08-28 08:05:38
|
I personally like adjusting subjects on the original threads, I tend to put a "was: ... " into the first line. But that's me who uses decent mail clients whenever I can :-) I've certainly encountered opposition. Peter On 28 August 2015 4:01:26 pm AEST, Clemens Katzer <cle...@cl...> wrote: > >BTW, about etiquette: would it be abd style to change the mail subject >to what it's now really about? >Because, it might screw up some peoples mail client, who looks at the >original header. (or something?) > >For me it makes more sense to have the right subject there; for those >whose mail client does not handle >it "old header" style, it's better, and the others, well they are not >much worse than before... > > >I guess the best way would be to start a new mail, copy-pasting the >relevant part(s) into that. > > >Thanks, >Clemens > > > >On 2015-08-28 00:37, Peter Becker wrote: >> One note of warning: unless you compile against a corresponding JDK >> nothing will stop you from picking up a method that won't be in an >> earlier JDK. The result is a NoSuchMethodException (or something like >> that) at runtime. >> >> And there is plenty of innocent looking stuff like this one, which >> was >> introduced in 1.6: >> >> >http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty() >> >> The only safe ways are to compile against the target JDK or to use >> static code analysis tools. >> >> Peter >> >> >> On 27/08/2015 3:10 PM, Clemens Katzer wrote: >>>> My java6 choked on "JComboBox<String>", isn't that new in 7? >>> Ah, right, that way. But that's only syntactic stuff. >>> >>> So, correction: No, it can't be compiled with Java 5 or 6, but it >>> can >>> be compiled to be runnable on Java 5. >>> >>> (( the funny thing is, it compiles this code happily with java 7, >>> even >>> if -source 1.7 is set (!!!) )) >>> >>> >>> [clemens@myldaptop Colossus]$ grep level build.properties >>> source.level=1.5 >>> target.level=1.5 >>> [clemens@myldaptop Colossus]$ ant clean jars >>> Buildfile: /home/clemens/p/sf/github/coti/Colossus/build.xml >>> >>> cleanjars: >>> [delete] Deleting: >>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar >>> [delete] Deleting: >>> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar >>> [delete] Deleting: >>> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar >>> >>> clean: >>> [delete] Deleting directory >>> /home/clemens/p/sf/github/coti/Colossus/build/ant >>> >>> cleanjars: >>> >>> clean: >>> >>> init: >>> [mkdir] Created dir: >>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes >>> [mkdir] Created dir: >>> /home/clemens/p/sf/github/coti/Colossus/build/ant/testresults >>> >>> compile: >>> [javac] Compiling 284 source files to >>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes >>> [javac] warning: [options] bootstrap class path not set in >>> conjunction with -source 1.5 >>> [javac] 1 warning >>> >>> compileVariants: >>> [javac] Compiling 17 source files to >>> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes >>> [javac] warning: [options] bootstrap class path not set in >>> conjunction with -source 1.5 >>> [javac] 1 warning >>> >>> jar: >>> [jar] Building jar: >>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar >>> [jar] Updating jar: >>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar >>> [jar] Updating jar: >>> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar >>> >>> webjar: >>> [jar] Building jar: >>> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar >>> >>> ccj: >>> [jar] Building jar: >>> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar >>> >>> jars: >>> >>> BUILD SUCCESSFUL >>> Total time: 8 seconds >>> [clemens@myldaptop Colossus]$ javac -version >>> javac 1.7.0_45 >>> [clemens@myldaptop Colossus]$ >>> >>> >>> >>> On 2015-08-26 23:04, Romain Dolbeau wrote: >>>> 2015-08-26 21:54 GMT+02:00 Clemens Katzer <cle...@cl... >>>> [1]>: >>>> >>>>>> The current code cannot be compiled with java 6 unfortunately. >>>>> Actually it can. The build file and the jnlp file say it needs >>>>> 1.7, >>>>> but >>>>> there's nothing in the code that won't work with Java 5. As far as >>>>> I >>>>> know, at least :) >>>> My java6 choked on "JComboBox<String>", isn't that new in 7? >>>> >>>> I haven't done any java in a long time, I could be very wrong. >>>> >>>> Cordially, >>>> >>>> -- >>>> >>>> Romain Dolbeau >>>> >>>> Links: >>>> ------ >>>> [1] mailto:cle...@cl... >>> >>> >>> >------------------------------------------------------------------------------ >>> _______________________________________________ >>> Colossus-developers mailing list >>> Col...@li... >>> https://lists.sourceforge.net/lists/listinfo/colossus-developers >> >> >> >> >------------------------------------------------------------------------------ >> _______________________________________________ >> Colossus-developers mailing list >> Col...@li... >> https://lists.sourceforge.net/lists/listinfo/colossus-developers > > >------------------------------------------------------------------------------ >_______________________________________________ >Colossus-developers mailing list >Col...@li... >https://lists.sourceforge.net/lists/listinfo/colossus-developers |
|
From: Clemens K. <cle...@cl...> - 2015-08-28 06:01:35
|
BTW, about etiquette: would it be abd style to change the mail subject to what it's now really about? Because, it might screw up some peoples mail client, who looks at the original header. (or something?) For me it makes more sense to have the right subject there; for those whose mail client does not handle it "old header" style, it's better, and the others, well they are not much worse than before... I guess the best way would be to start a new mail, copy-pasting the relevant part(s) into that. Thanks, Clemens On 2015-08-28 00:37, Peter Becker wrote: > One note of warning: unless you compile against a corresponding JDK > nothing will stop you from picking up a method that won't be in an > earlier JDK. The result is a NoSuchMethodException (or something like > that) at runtime. > > And there is plenty of innocent looking stuff like this one, which > was > introduced in 1.6: > > http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty() > > The only safe ways are to compile against the target JDK or to use > static code analysis tools. > > Peter > > > On 27/08/2015 3:10 PM, Clemens Katzer wrote: >>> My java6 choked on "JComboBox<String>", isn't that new in 7? >> Ah, right, that way. But that's only syntactic stuff. >> >> So, correction: No, it can't be compiled with Java 5 or 6, but it >> can >> be compiled to be runnable on Java 5. >> >> (( the funny thing is, it compiles this code happily with java 7, >> even >> if -source 1.7 is set (!!!) )) >> >> >> [clemens@myldaptop Colossus]$ grep level build.properties >> source.level=1.5 >> target.level=1.5 >> [clemens@myldaptop Colossus]$ ant clean jars >> Buildfile: /home/clemens/p/sf/github/coti/Colossus/build.xml >> >> cleanjars: >> [delete] Deleting: >> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar >> [delete] Deleting: >> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar >> [delete] Deleting: >> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar >> >> clean: >> [delete] Deleting directory >> /home/clemens/p/sf/github/coti/Colossus/build/ant >> >> cleanjars: >> >> clean: >> >> init: >> [mkdir] Created dir: >> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes >> [mkdir] Created dir: >> /home/clemens/p/sf/github/coti/Colossus/build/ant/testresults >> >> compile: >> [javac] Compiling 284 source files to >> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes >> [javac] warning: [options] bootstrap class path not set in >> conjunction with -source 1.5 >> [javac] 1 warning >> >> compileVariants: >> [javac] Compiling 17 source files to >> /home/clemens/p/sf/github/coti/Colossus/build/ant/classes >> [javac] warning: [options] bootstrap class path not set in >> conjunction with -source 1.5 >> [javac] 1 warning >> >> jar: >> [jar] Building jar: >> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar >> [jar] Updating jar: >> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar >> [jar] Updating jar: >> /home/clemens/p/sf/github/coti/Colossus/Colossus.jar >> >> webjar: >> [jar] Building jar: >> /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar >> >> ccj: >> [jar] Building jar: >> /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar >> >> jars: >> >> BUILD SUCCESSFUL >> Total time: 8 seconds >> [clemens@myldaptop Colossus]$ javac -version >> javac 1.7.0_45 >> [clemens@myldaptop Colossus]$ >> >> >> >> On 2015-08-26 23:04, Romain Dolbeau wrote: >>> 2015-08-26 21:54 GMT+02:00 Clemens Katzer <cle...@cl... >>> [1]>: >>> >>>>> The current code cannot be compiled with java 6 unfortunately. >>>> Actually it can. The build file and the jnlp file say it needs >>>> 1.7, >>>> but >>>> there's nothing in the code that won't work with Java 5. As far as >>>> I >>>> know, at least :) >>> My java6 choked on "JComboBox<String>", isn't that new in 7? >>> >>> I haven't done any java in a long time, I could be very wrong. >>> >>> Cordially, >>> >>> -- >>> >>> Romain Dolbeau >>> >>> Links: >>> ------ >>> [1] mailto:cle...@cl... >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Colossus-developers mailing list >> Col...@li... >> https://lists.sourceforge.net/lists/listinfo/colossus-developers > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Colossus-developers mailing list > Col...@li... > https://lists.sourceforge.net/lists/listinfo/colossus-developers |
|
From: Clemens K. <cle...@cl...> - 2015-08-28 05:58:45
|
On 2015-08-28 04:19, Barrie Treloar wrote: > On 28 August 2015 at 07:07, Peter Becker <pe...@pe... [2]> > wrote: > >> One note of warning: unless you compile against a corresponding JDK Good point. So at least should compile it against an 1.5 every then and now. >> nothing will stop you from picking up a method that won't be in an >> earlier JDK. The result is a NoSuchMethodException (or something >> like >> that) at runtime. >> >> And there is plenty of innocent looking stuff like this one, which >> was >> introduced in 1.6: >> > > http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty() >> [1] >> >> The only safe ways are to compile against the target JDK or to use >> static code analysis tools. Every then and now against a 1.5 JRE is much easier. Could have one in a virtual machine; or, even on main PC, it just needs to be unpacked in some folder, right? So no need to "officially" install with Yum. And, github has a Jenkins, right? So one job there could do the job. Though I would have to push more often, but then, main thing is to ensure it before making a build that the whole wild world will use. thanks, but... > I've not used it but maven animal sniffer plugin will throw > exceptions > in case like this. If somebody is willing to port this to maven - be my guest. I won't do that and struggle with a "dubious" (well at least badly documented) plugin if there are easier ways to achieve things. Besides, what I hear Maven is "obsolete", Cradle is "in" now... No? > The documentation is not great, > http://stackoverflow.com/a/4451057/552958 [3] should give you enough > to get going to enforce this on the minimum jre you want to run on > and > allow some comfort on the jdk you want to build against. > So thank you very much for your advice/suggestions, but I will try one of the above. Probably unpack the JRE to somewhere. All the best, Clemens |
|
From: Barrie T. <bae...@gm...> - 2015-08-28 01:19:18
|
On 28 August 2015 at 07:07, Peter Becker <pe...@pe...> wrote: > One note of warning: unless you compile against a corresponding JDK > nothing will stop you from picking up a method that won't be in an > earlier JDK. The result is a NoSuchMethodException (or something like > that) at runtime. > > And there is plenty of innocent looking stuff like this one, which was > introduced in 1.6: > http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty() > > The only safe ways are to compile against the target JDK or to use > static code analysis tools. > I've not used it but maven animal sniffer plugin will throw exceptions in case like this. The documentation is not great, http://stackoverflow.com/a/4451057/552958 should give you enough to get going to enforce this on the minimum jre you want to run on and allow some comfort on the jdk you want to build against. |
|
From: Peter B. <pe...@pe...> - 2015-08-27 22:00:54
|
One note of warning: unless you compile against a corresponding JDK nothing will stop you from picking up a method that won't be in an earlier JDK. The result is a NoSuchMethodException (or something like that) at runtime. And there is plenty of innocent looking stuff like this one, which was introduced in 1.6: http://docs.oracle.com/javase/7/docs/api/java/lang/String.html#isEmpty() The only safe ways are to compile against the target JDK or to use static code analysis tools. Peter On 27/08/2015 3:10 PM, Clemens Katzer wrote: >> My java6 choked on "JComboBox<String>", isn't that new in 7? > Ah, right, that way. But that's only syntactic stuff. > > So, correction: No, it can't be compiled with Java 5 or 6, but it can > be compiled to be runnable on Java 5. > > (( the funny thing is, it compiles this code happily with java 7, even > if -source 1.7 is set (!!!) )) > > > [clemens@myldaptop Colossus]$ grep level build.properties > source.level=1.5 > target.level=1.5 > [clemens@myldaptop Colossus]$ ant clean jars > Buildfile: /home/clemens/p/sf/github/coti/Colossus/build.xml > > cleanjars: > [delete] Deleting: > /home/clemens/p/sf/github/coti/Colossus/Colossus.jar > [delete] Deleting: > /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar > [delete] Deleting: > /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar > > clean: > [delete] Deleting directory > /home/clemens/p/sf/github/coti/Colossus/build/ant > > cleanjars: > > clean: > > init: > [mkdir] Created dir: > /home/clemens/p/sf/github/coti/Colossus/build/ant/classes > [mkdir] Created dir: > /home/clemens/p/sf/github/coti/Colossus/build/ant/testresults > > compile: > [javac] Compiling 284 source files to > /home/clemens/p/sf/github/coti/Colossus/build/ant/classes > [javac] warning: [options] bootstrap class path not set in > conjunction with -source 1.5 > [javac] 1 warning > > compileVariants: > [javac] Compiling 17 source files to > /home/clemens/p/sf/github/coti/Colossus/build/ant/classes > [javac] warning: [options] bootstrap class path not set in > conjunction with -source 1.5 > [javac] 1 warning > > jar: > [jar] Building jar: > /home/clemens/p/sf/github/coti/Colossus/Colossus.jar > [jar] Updating jar: > /home/clemens/p/sf/github/coti/Colossus/Colossus.jar > [jar] Updating jar: > /home/clemens/p/sf/github/coti/Colossus/Colossus.jar > > webjar: > [jar] Building jar: > /home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar > > ccj: > [jar] Building jar: > /home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar > > jars: > > BUILD SUCCESSFUL > Total time: 8 seconds > [clemens@myldaptop Colossus]$ javac -version > javac 1.7.0_45 > [clemens@myldaptop Colossus]$ > > > > On 2015-08-26 23:04, Romain Dolbeau wrote: >> 2015-08-26 21:54 GMT+02:00 Clemens Katzer <cle...@cl... >> [1]>: >> >>>> The current code cannot be compiled with java 6 unfortunately. >>> Actually it can. The build file and the jnlp file say it needs 1.7, >>> but >>> there's nothing in the code that won't work with Java 5. As far as >>> I >>> know, at least :) >> My java6 choked on "JComboBox<String>", isn't that new in 7? >> >> I haven't done any java in a long time, I could be very wrong. >> >> Cordially, >> >> -- >> >> Romain Dolbeau >> >> Links: >> ------ >> [1] mailto:cle...@cl... > > ------------------------------------------------------------------------------ > _______________________________________________ > Colossus-developers mailing list > Col...@li... > https://lists.sourceforge.net/lists/listinfo/colossus-developers |
|
From: Romain D. <ro...@do...> - 2015-08-27 08:57:15
|
2015-08-27 10:52 GMT+02:00 Clemens Katzer <cle...@cl...>: > Not really, except that I can't test and for example not reproduce any > user problems on my own computer then. > ( I am reluctant trying to install Java 1.5 and possibly screw up things > on my Fedora 21 ). > Best effort. As long as it compiles and work for you, target 1.5. If a user has a problem no-one can reproduce, then the user is on its own :-/ > PS: when will we stop supporting Java 5 then? When 32 bit systems are > declared illegally by some state/country and XP does not work on > 64bit?....;-) > When it stops compiling with a 1.5 target :-) But then, I'm the guy who just checked his Sun 4/330GX from 11/89 was still running, so my opinion on supporting older systems might be a bit biased :-) Cordially, -- Romain Dolbeau |
|
From: Clemens K. <cle...@cl...> - 2015-08-27 08:52:35
|
On 2015-08-27 10:17, Romain Dolbeau wrote: > 2015-08-27 7:10 GMT+02:00 Clemens Katzer <cle...@cl... > [1]>: > > > Any reason not to target 1.5 as it's possible? Not really, except that I can't test and for example not reproduce any user problems on my own computer then. ( I am reluctant trying to install Java 1.5 and possibly screw up things on my Fedora 21 ). > It would enable Colossus on older systems. Yeah, as I indicated in my previous mail (did I?) I will drop/postpone the thought of requiring a newish Java :-/ So.... as usual. When I ask on the list beforehand, it does not matter, all say "it's you who decides" but in this case I omitted that discussion and it would have been better to ask..... -Clemens PS: when will we stop supporting Java 5 then? When 32 bit systems are declared illegally by some state/country and XP does not work on 64bit?....;-) |
|
From: Clemens K. <cle...@cl...> - 2015-08-27 05:10:55
|
> My java6 choked on "JComboBox<String>", isn't that new in 7?
Ah, right, that way. But that's only syntactic stuff.
So, correction: No, it can't be compiled with Java 5 or 6, but it can
be compiled to be runnable on Java 5.
(( the funny thing is, it compiles this code happily with java 7, even
if -source 1.7 is set (!!!) ))
[clemens@myldaptop Colossus]$ grep level build.properties
source.level=1.5
target.level=1.5
[clemens@myldaptop Colossus]$ ant clean jars
Buildfile: /home/clemens/p/sf/github/coti/Colossus/build.xml
cleanjars:
[delete] Deleting:
/home/clemens/p/sf/github/coti/Colossus/Colossus.jar
[delete] Deleting:
/home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
[delete] Deleting:
/home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar
clean:
[delete] Deleting directory
/home/clemens/p/sf/github/coti/Colossus/build/ant
cleanjars:
clean:
init:
[mkdir] Created dir:
/home/clemens/p/sf/github/coti/Colossus/build/ant/classes
[mkdir] Created dir:
/home/clemens/p/sf/github/coti/Colossus/build/ant/testresults
compile:
[javac] Compiling 284 source files to
/home/clemens/p/sf/github/coti/Colossus/build/ant/classes
[javac] warning: [options] bootstrap class path not set in
conjunction with -source 1.5
[javac] 1 warning
compileVariants:
[javac] Compiling 17 source files to
/home/clemens/p/sf/github/coti/Colossus/build/ant/classes
[javac] warning: [options] bootstrap class path not set in
conjunction with -source 1.5
[javac] 1 warning
jar:
[jar] Building jar:
/home/clemens/p/sf/github/coti/Colossus/Colossus.jar
[jar] Updating jar:
/home/clemens/p/sf/github/coti/Colossus/Colossus.jar
[jar] Updating jar:
/home/clemens/p/sf/github/coti/Colossus/Colossus.jar
webjar:
[jar] Building jar:
/home/clemens/p/sf/github/coti/Colossus/ColossusWeb.jar
ccj:
[jar] Building jar:
/home/clemens/p/sf/github/coti/Colossus/CmdlineClient.jar
jars:
BUILD SUCCESSFUL
Total time: 8 seconds
[clemens@myldaptop Colossus]$ javac -version
javac 1.7.0_45
[clemens@myldaptop Colossus]$
On 2015-08-26 23:04, Romain Dolbeau wrote:
> 2015-08-26 21:54 GMT+02:00 Clemens Katzer <cle...@cl...
> [1]>:
>
>>> The current code cannot be compiled with java 6 unfortunately.
>> Actually it can. The build file and the jnlp file say it needs 1.7,
>> but
>> there's nothing in the code that won't work with Java 5. As far as
>> I
>> know, at least :)
>
> My java6 choked on "JComboBox<String>", isn't that new in 7?
>
> I haven't done any java in a long time, I could be very wrong.
>
> Cordially,
>
> --
>
> Romain Dolbeau
>
> Links:
> ------
> [1] mailto:cle...@cl...
|
|
From: Barrie T. <bae...@gm...> - 2015-08-26 21:03:08
|
On 27 August 2015 at 04:24, Romain Dolbeau <ro...@do...> wrote: > > 2015-08-26 20:10 GMT+02:00 <sp...@ao...> > >> Your recent Java 7 upgrade makes me unable to play since I do not >> have anything more than Java 6 on this older computer. Can you please post >> the old version using Java 6 on your web site again? >> > Colossus is one of the games me and my retired friends have been playing >> since we were a great deal younger. If you can't do this, please accept >> our thanks for ages of delightful playing time. >> >> > As Romain says, you can always run with an older version... forever more. But you will be stuck with any bugs that get fixed later. What systems are you running that dont allow you to install a later version of Java? |