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.
Forums
Java Back End
Re: Java Back End
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.
Please send me a fresh "server notes" file/update if appropriate.
Thanks.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Java Back End
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.
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.
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: Java Back End
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.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Java Back End
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
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
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: Java Back End
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.
-- 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.
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Java Back End
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.
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:
Missed tests
Tests/100-basics/062c-string-substitution-fmt.cobra
Tests/100-basics/070j-is-and-is-not.cobra
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
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Re: Java Back End
Done. Both env var names start with COBRA_TECHSTRING_...
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Java Back End
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?
- Charles
- Posts: 2515
- Location: Los Angeles, CA
Re: Java Back End
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
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
- hopscc
- Posts: 632
- Location: New Plymouth, Taranaki, New Zealand
Who is online
Users browsing this forum: No registered users and 50 guests