Page 5 of 6

Re: Java Back End

PostPosted: Tue Aug 16, 2011 10:43 am
by todd.a
I took a look at the settings and it was set to display less info in the timeline so I changed that to match the old value.

As for the box on the right, it's the same on the new installation with the addition of the "done by" input.

I'm not quite sure I get the patch display issue so feel free to elaborate and if there's anything else still missing feel free to post that too.

Re: Java Back End

PostPosted: Tue Aug 16, 2011 1:56 pm
by Charles
Looks good to me now. I checked off the box regarding ticket updates and can now see that hopscc attached a patch to the ticket.

Please send me a fresh "server notes" file/update if appropriate.

Thanks.

Re: Java Back End

PostPosted: Fri Sep 16, 2011 2:31 am
by hopscc
Apologies;
Theres been a bit of a hiatus with the Java backend patches.

Please do not be alarmed.
I'm still working on them but Ive been recently distracted by the initial training, care and feeding of a new android tablet gadget my missus brought me back from foreign climes.

Normal service will resume as soon as possible.

Re: Java Back End

PostPosted: Fri Sep 16, 2011 9:41 pm
by Charles
No problems. I've been on a hiatus with compiler work as well as I've been busy building an application with Cobra and will continue to be so for the next few weeks.

Re: Java Back End

PostPosted: Wed Dec 14, 2011 6:11 am
by hopscc
Theres a new patch on the ticket:.

More cleanups
Commandline handling for Java apps
Platform dependency compiler directives
Fixups for Generics and unsupported backend Types
Indexers ( simple, wired)

more RTL support in Java
fixup tests for platform dependencies

In addition theres a tweak on techstring output to indent the items in seperate lines making a large output more readable

Re: Java Back End

PostPosted: Sat Dec 17, 2011 11:04 pm
by Charles
Thanks. Applied in changeset:2631.

-- I renamed the env var COBRA_INDENT_TECHSTRING to COBRA_TECHSTRING_SEPARATOR and use the actual value if it is present. But now I suppose we need something that interprets \n and \t, right?

-- In Tests/100-basics/070-is-and-is-not.cobra you added ".require. clr". Is that temporary?

-- I was extra careful to check that I svn added all new files, but please check and let me know if I missed anything.

Re: Java Back End

PostPosted: Sun Dec 18, 2011 1:25 am
by hopscc
In reverse order (:-)

1.OK checking now.

Initially Looks like I missed a couple of additional tests (in Tests/100-basics) in the patch
? 062-string-substitution-fmt.cobra
? 070j-is-and-is-not.cobra
I'll pass them inline below

2.
Tests/100-basics/070-is-and-is-not.cobra

The change isnt intended to be temporary - the existing test uses an Object method specific to CLR thats not available in jvm
( Object.referenceEquals). the jvm version below changes to use an added CobraImp ( CobraCoreInternal method ) instead.

(possibly that change should also be in the Cobra RTL as a nod to a portable RTL but I'm deferring that for the moment

3. re COBRA_TECHSTRING_SEPARATOR
The mod env variable I made was just a a flag to specify multiline indented items to aid/allow readability - I actually think it would be preferable to default to this but thats not what we've done so far ...
The change you made means that someone wanting just (intelligible) multiline aligned indentation is goanna have to experiment a bit to get the right sequence (',\n\t ') for aligned indented multilines.
If you want arbitrary allowance of a separator I would prefer a a different env variable that specifies and overrides the (defaulted) separator along with a env variable for simply specifying effectively ' I want want each item aligned on separate lines'

code something like:
Code: Select all
      __toStringSep = Environment.getEnvironmentVariable('COBRA_TECHSTRING_SEPARATOR') ? _
                      if( Environment.getEnvironmentVariable('COBRA_INDENT_TECHSTRING') , ',\n\t   ', ',') )
      sep = __toStringSep




Missed tests

Tests/100-basics/062c-string-substitution-fmt.cobra
Code: Select all
#.require. clr
# some simple string subst formatting tests - .Net format descriptions
namespace Test

        class Test

                def main
                        is shared

                        # formatting
                        mol as int = 42
                        assert '[mol:N]'=='42.00'
                        assert "[mol:N]"=='42.00'

                        # test some the old way without the escape syntax.
                        a=99
                        t = String.format('a = {0}[a]]', c'[')
                        assert t == r'a = [99]'
                        s10 = 'FMT:a = '+ ns'[' +'[a]]'
                        assert s10 == r'FMT:a = [99]'



Tests/100-basics/070j-is-and-is-not.cobra
Code: Select all
#.require. jvm
namespace Test

        class Test

                def main
                        is shared

                        s as String = 'aoeu'
                        assert s is s

                        t1 as String = 'ao'
                        t2 as String = 'eu'
                        if s.length==4
                                # the condition forces t to be constructed at runtime
                                t as String = t1 + t2
                        else
                                t as String = ''
                        assert s==t
                        assert not CobraImp.referenceEquals(s, t)
                        assert s is not t
                        assert t is not s

                        # for primitives like int, "is" is synonymous with "==" (and "is not" -> "<>")
                        x as int = 5
                        assert 5 is 5  # .warning. value types
                        assert x is 5  # .warning. value types
                        assert 5 is x  # .warning. value types
                        assert x == x  # TODO warning. same variable
                        y as int = 5
                        assert x is y  # .warning. value types
                        assert y is x  # .warning. value types
                        y = 6
                        assert x is not y  # .warning. value types

Re: Java Back End

PostPosted: Sat Dec 24, 2011 12:02 am
by Charles
Done. Both env var names start with COBRA_TECHSTRING_...

Re: Java Back End

PostPosted: Sat Dec 24, 2011 12:05 am
by Charles
Actually, why do these have TECHSTRING in the name? This code is in Node.cobra, not in the Cobra RTL which implements .toTechString. Also, the method in question, _toString, is used by Node.minimalString, .shallowString and .deepString. It should be COBRA_NODESTRING_..., right?

Re: Java Back End

PostPosted: Thu Dec 29, 2011 5:22 am
by hopscc
Nah.
They should be named to their function or use

They're configuration knobs for the compiler (output in this case),
noone using it/wanting to change it, knows or gives a damn or should need to do so
in what part of the compiler architecture they're actually implemented or what named part they adjust.

better would be something along the lines of
COBRA_INDENT_OUTPUT(_FLAG)?
COBRA_OUTPUT_SEPARATOR(_STRING)?

Using env variables is a bit quick and dirty and somewhat kludgy - hard to get good names and clearly inline documented.
config/properties file is a better way to go - something using the enhancement in ticket:200