Comments are closed

cJass on the Google Code.
Our BugTracker (recommend to post bugreports and features request there).
Beta tester notes.

all times are GMT +03:00
Latest posts

Pages: 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

posted at 08/02/10 07:59
Mooglefrooglian

Bug with the anti bj:
if chatGroup != PD[pid].AlienChatGroup then
DisplayTextToForce(chatGroup.ScannedPeople, chatGroup.Prefix + " " + name + chatGroup.ParsedString)
else
//Hay, they be aliens!
if PD[pid].Cerebrate then
name = "|cff440000Cerebrate:|r "
endif
DisplayTextToForce(chatGroup.ScannedPeople, chatGroup.Prefix + " " + name + chatGroup.ParsedString)
endif
Raises an error of missing an end block: with some creative digging, I found that it compiled to:
if chatGroup!=PlayerData[pid].AlienChatGroup then
if IsPlayerInForce(GetLocalPlayer(),chatGroup.ScannedPeople) then
call DisplayTextToPlayer(GetLocalPlayer(),0.,0.,chatGroup.Prefix+" "+name+chatGroup.ParsedString)
else
if PlayerData[pid].Cerebrate then
set name="|cff440000Cerebrate:|r "
endif
if IsPlayerInForce(GetLocalPlayer(),chatGroup.ScannedPeople) then
call DisplayTextToPlayer(GetLocalPlayer(),0.,0.,chatGroup.Prefix+" "+name+chatGroup.ParsedString)
endif
endif
That anti bj in the second line is converted to an if with no end block.
Commenting out
#include "cj_antibj_base.j"
Fixed the problem.
If we could get a fix, it would be great please.
Fixed. It was not antibj bug - it was bug with combination jass style and c style block.
~ADOLF

posted at 08/02/10 01:55
Van Damm

I've suggested ADOLF to switch to cjass-only blocks, dropping support of plain jass syntax and leaving a compile-time flag, that turns on old behavior (compiling all map in cjass). He said he'd think about it.

posted at 08/02/10 01:46
Nestharus

b) forbid using old syntax if statements without then, ie:
if (true)
doSomething()
endif
will give a syntax error
>Stop trying to merge them, otherwise we go into all of these ambiguities. Each line in a c jass block needs to be treated as pure cjass.

posted at 08/02/10 00:45
Van Damm

There are two ways of solving the "single statement if" problem:
a) allow single statement ifs to be only single-lined, ie:
<div class="code">if (true) doSomething()</div>
will translate to
<div class="code">if (true) then
&nbsp;&nbsp;doSomething()
endif</div>
but
<div class="code">if (true)
doSomething()</div>
will translate to
<div class="code">if (true) then
endif
doSomething()</div>
b) forbid using old syntax if statements without then, ie:
<div class="code">if (true)
&nbsp;&nbsp;doSomething()
endif</div>
will give a syntax error
~VD

posted at 08/02/10 00:21
Dark Dragon

@ VD: wtf is with that underscores?
yeah, duno in jass u even cant declare func or var starting or ending with underscores...

anyway this ifs could just be compiled to:
if (expr);
now u dont need to check is it in same or next line...
that what u write as syntax error should actually be possible and its actually the main reason why we would like single lined ifs...
if (u != null) KillUnit(u)
Greets and if possible plz fix that last bug with anonym funcs, thanks!
~DD

posted at 08/02/10 00:04
Nestharus

Single line block statements are a part of C : |... the { } signifies multi line block and no { } signifies single line...
And all the arguments against it are wrong.... trying to do endif etc.. that's not a part of C is it? Remember, making this better would require it to be in a language block... JASS should be the only language allowed that isn't in a language block, and vJASS as it's really an extension to plain old JASS.
if (expr) // syntax error
that shouldn't be a syntax error because you can't do if then endif in cJASS anyways... : |
Stop trying to merge them, otherwise we go into all of these ambiguities. Each line in a c jass block needs to be treated as pure cjass.

posted at 07/02/10 23:57
Van Damm

wtf is with that underscores?

posted at 07/02/10 23:55
ADOLF

Maybe:
if (expr) // syntax error
____action()
// without endif
?

posted at 07/02/10 20:58
Sebra

The only way syntax
_if (cond)
__action()
is good, is to forbid syntax
_if (cond)
__action()
_endif
because they are too similar.
When "then" was needed it was like a "{" to wait an "endif" like "}".
One line if syntax
_if (cond) action()
is good because it has flag needed - one line.
Please do not allow coders to do such a stupid errors.
And do something to allow formatting code here.

posted at 07/02/10 17:10
Dark Dragon

ofc if user writes endif or uses {} then it will compile all actions inside but if coder writes only "if/else" then it will automaticaly add endif after next action.

if (expr)
act1()
else
act2()

currently we would need to use {} or endif...

posted at 07/02/10 16:11
Sebra

It is too easy to make a mistake.
And may be hard to find it.
Map author can write:
if bool1
_func1()
_func2()
_if bool2
__func3()
_func4()
endif
...and you will compile it wrong.
Please do not do it.
Let be two variant.
if (cond) act()
and
if (cond)
act1()
...
actn()
endif
or yet another
if (cond) {
...
}

posted at 07/02/10 14:25
Dark Dragon

if (expr) act()
compiled to:
if (expr); act(); endif

if (expr)
act1()
act2()
compiled to:
if (expr)
act1()
endif
act2()

posted at 07/02/10 14:07
Sebra

// new syntax
if (expr)
// witout endif
It is wrong syntax.
if bool1
func1()
func2()
if bool2
func3()
func4()
endif // which if are you choose???
//You can think different with author
if (expr) action
This is good. If someone do not want to write endif, he can use {}.
It must compiled to:
=======================
if bool1
func1()
endif
func2()
if bool2
func3()
func4()
endif
=======================
Or not?
~ADOLF
edit: oh yes) if () without endif must compile as if () 'next line' endif

posted at 07/02/10 12:38
ADOLF

Well, then our roadmap is:
  1. fix bug with textmacro
  2. rewrote #if (add expression || && etc)
  3. add singleline block if, while without {} :

// old syntax, only add "then"
// I'll check "endif"
if (expr)
//...
endif

// new syntax
if (expr)
// witout endif
// compile to
if (expr)
endif
// and:
if (expr) action
// compile to
if (expr)
action
endif

  1. fix another "over 9000" bugs xD
  2. update stable version
ternary operators, and all other features we add after it)

posted at 07/02/10 12:32
Dark Dragon

Thanks a lot for this update ADOLF!
funcs finaly work and there is just one remaining bug about them.

define ForGroup(g, f) = For##Group(g, f)
define ForGroup(g, f, v) = { temp = v; For##Group(g, f) }
if i use lambda funcs as argument:
ForGroup(g, lambda nothing() {})
will not compile.
anyway thanks for all ur time spent on making cJass its really awesome project and lambda funcs really help me in making my code more readable and easier to write.
Thanks!
~DD
Ok, thx;) I'll fix it asap
~ADOLF

posted at 07/02/10 11:21
Sebra

If I remember correctly aim was not to "make C on Jass".
Aim was to Jass, vJass and c-like syntax can be uses simultaneously.
About a=3+(b=2*2)
Looking at precedence in Bjarne's book you can find what "=" have lower precedence whan "*". And "?:" even lower. So your example must be...
percent = ( (a > 0 && a < 1) ? a*100 : (a > 0 && a < 100) ? a : 0 )
->if (a > 0 && a < 1) then
set percent = a*100
elseif (a > 0 && a < 100) then
percent = a
else
percent = 0
endif
But leftmost "=" is a part of "set var=" syntax, so it is out of precedence table and must be always last.

posted at 07/02/10 09:06
TheLifelessOne

Actually, you should try to stay as close to the C standard as much as is possible.

posted at 07/02/10 09:04
TheLifelessOne

Yeah, this language definately needs to become more like C. More than it already is.
Then it may become more popular.

posted at 07/02/10 01:55
Nestharus

Sry for the third comment, but something is very confusing as I had a typo : ).
->introduce protected keyword and structs within structs
: D, all fixer uppered now

posted at 07/02/10 01:54
Nestharus

Oh.. forgot to mention this, but instead of each ObjectMerger call etc having to extract the stupid files from the MPQ archive, you should auto extract all of them into a directory for processing, not just the JASS file. In this way, people can manipulate them on the fly with preprocessing stuff or they can use an exe like ObjectMerger to mess with them. You could add in soem preprocessor commands for manipulating them though.
Oh yea, introduce protected, structs and within structs. I'm also working on a pretty nifty collections framework, so when I've finished with that I can give you the code and you can put that all in as part of the standard too. They are very generic and work completely through preprocessing directives, so it wouldn't add to the map size at all.

posted at 07/02/10 01:48
Nestharus

a=3+(b=2*2)
is not
set b=2*2
set a=3+b
the b would be 2, the a would be 3+(b*2)
or
int a
int b
b = 2
a = 3+(b*2)
I think you wanted a = 3 + b=(2*2)
A preprocessor cannot determine how many characters to apply to a variable, so it would go for the first value. Grouping is done through ().
And for all this crap about multi ifs in ternary...
percent = (a > 0 && a < 1) ? a*100 : (a > 0 && a < 100) ? a : 0
there's a perfect example of multiple ternary operators in one line -.-...
you guys are overdoing it, just follow C Syntax... /sigh
Also I think that all lines that aren't blocks should must end with ; and that lines that don't end with that and aren't blocks should be merged with the next line.
Furthermore, blocks without { } will be treated as though they only have one line, ( ) required on boolean expressions to determine when they end, and etc... all the normal C stuff..
You're shooting for C Syntax right? Then stop trying to merge C and JASS together -.-...
Also, you should be able to extend handles.. like extend unit. When you extend a handle, it'd be like methods in vJASS structs, except instead of integers they'd take a handle type called this. Also they're create would be just the handle create. In this way, all current natives could be transferred to an OO syntax without any performance hit.
Furthermore, extends should be changed into : to follow C Synatx -.-. All cJASS should be required to be placed in C Blocks. Follow language conventions -.-. You can't just merge two languages together... it all turns messy, this is the primary reason so many people are so opposed to cJASS right now.
All preprocessor directives in cJASS should be # instead of //!... and the current ones should always require #, including define and include.
also, make define more like a normal C Define...
For further preprocessing, allow people to define their own languages. The language blocks should include a block name, which blocks they use, and the language's interpreter (exe). You should auto provide euphoria as it's part of grimoire.
Also give people access to the JASS file in an XML format... so if there are any preprocessor language blocks in the file, output the JASS file to the XML format including so that the interpreted scripts and read them in, and then convert XML back into JASS file and start on your cJASS, and from there, direct the file to vJASS... don't direct it to vJASS in the Lua file for grimoire, direct it within cJASS...
So when you think of these language blocks, think-
#external (blockname) uses [blocks] with exe {
}
For blocks that use different exes, just runt he previous blocks first... for blocks that run on the same exes, merge them so they can use the methods and data etc... For Lua, it'd just be-
#lua (blockname) uses [blocks] {
}
//! lua is a decent temporary measure as you mentioned before, but do it right.
Also I've noticed a LOT of problems with #if... sometimes when the thing is true, it'll equate to false... sometimes when it's false it'll equate to true. I've had to go through a bunch of crap when using it : p.

posted at 07/02/10 01:13
Sebra

Many ++/-- in one strings do not look better.
Such nested "?:" operators are easy to get mistake if preprocessor not used.
I think local is not needed for such forked return.
Also what can you say about:
integer a,b
a=3+(b=2*2)
->
integer a
integer b
set b=2*2
set a=3+b
Is not it a good work for preprocessor?

posted at 06/02/10 18:40
Dark Dragon

thats an nice idea on how to implement single lined ifs Sebra!
it does not require vars, funcs nor anything and is inlined ofc... there are rare cases where 2 ifs would be used in same line but i can already immagine few of them. ofc they should work if two or more are used in same line but what i wanted to say is that there will be rare cases where there will be a lot of jass lines... as this will get compiled to n_ifs^2... so more ifs in single line the much more lines, however amount of code does not matter since in truth only n_ifs are executed rest is skipped...
if you decide to implement this ADOLF it will be awesome and i think the way Sebra explained would be the best one.
int test() { return (true)? 1:0 }
that code would not work but we can always write:
int test() { return (true)? 1:0; return 0 }
if you want to make it work in returns as well then you might want to use one local, through i had hard time fixing cjass locals from "++" stuff as if i return handle i cant use ++ coz it will leak...
anyway i am most interested in lambda funcs and i hope they get fixed asap ;)
Greets!
~DD

posted at 06/02/10 14:33
Sebra

Many things from C become too complicated on Jass.

posted at 06/02/10 12:59
Nestharus

Why are people complicating it... just make it like C... this is cJASS after all -.-...

Pages: 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

[back to top]