I replied to a 'commits@' email a couple of days back. Maybe that goes
nowhere?
Copying and pasting here:
1. In Chrome tools, goto settings (via three vertical dots in top right)
and make sure 'Enable custom formatters' is checked under Console settings.
[image: devtools_XML_example_1.png]
2. back in the console, copy and paste the following code:
var xmlStyles = {
'element': {'style':'color:blue'},
'text': {'style':'color:green'},
'processing-instruction': {'style':'color:orange'},
'comment': {'style':'color:grey'},
'attribute' : {'style':'color:purple'},
'default': {'style':'color:black'}
}
function getLevelIndentation(level){
return level * 10 + "px";
}
window.devtoolsFormatters = [{
header: function(obj, config){
if ((config && config.xmlFormat) || (XML && obj instanceof XML)) {
var kind = config? config.kind: obj.nodeKind();
var atts = xmlStyles[kind] || xmlStyles['default'];
var name;
if (kind == 'element') {
var childCount = obj.getChildrenArray().length;
if (childCount) {
name = '<'+obj.name().toString()+ '>('+childCount+')';
} else {
name = '<'+obj.name().toString()+ '/>';
}
} else {
name = '('+ kind+')';
}
var display = 'XML '+name;;
var isAttribute = (kind == 'attribute')
if (isAttribute) display += ' '+obj.name
().toString()+'="'+obj.getValue()+'"';
return ["div", atts, display]
}
return null;
},
hasBody: function(){
return true;
},
body: function(obj, config){
var level = config !== undefined ? config.level : 1;
switch(obj.nodeKind()) {
case 'element':
var children = obj.getChildrenArray();
children = children.map(function(child){
var kind = child.nodeKind();
var atts = xmlStyles[kind];
child = ["object", {
object: child,
config: {
kind: kind,
xmlFormat: true,
level: level + 1
}
}];
return ["div", {style: "margin-left: " + getLevelIndentation(level)}, child]
})
var atts = obj.getAttributeArray();
if (atts.length) {
atts = atts.map(
function(att){
return ["div", {style: xmlStyles['attribute'].style+";margin-left: " +
getLevelIndentation(level)}, 'XML (attribute) ' + att.name
().toString()+'="'+att.getValue()+'"']
}
)
children = atts.concat(children);
}
break;
case 'processing-instruction':
case 'comment':
return ["div", {style: "margin-left: " + getLevelIndentation(level)},
obj.toXMLString()];
break;
default:
return ["div", {style: "margin-left: " + getLevelIndentation(level)},
obj.getValue()];
break;
}
return ["div", {}].concat(children);
}
}]
3. Try the following:
XML.ignoreComments=false
XML.ignoreProcessingInstructions=false
var xml = new XML('<test><?processingInstruction ?><!--and a
comment-->something<child withAttribute="childAttributeValue">child
text</child></test>');
xml (and press enter)
You should be able to inspect the xml in a custom way:
[image: devtools_XML_example_2.png]
On Wed, Dec 11, 2019 at 12:00 PM Harbs <[email protected]> wrote:
> I’m not sure what enhancement you’re referring to.
>
> If you can get similar memory requirements some other way, I don’t mind
> reverting what I did.
>
> I made so many small tweaks, that I’m not totally sure exactly what made
> the differences (besides the obvious).
>
> It might be worth comparing back to your string references to see the
> differences.
>
> > On Dec 11, 2019, at 12:45 AM, Greg Dove <[email protected]> wrote:
> >
> > 'I don’t think subclassing effects language conformity. Am I wrong?'
> >
> > I guess it depends what each of us thinks of as 'language'. Because XML
> is
> > an as3 core type, I think of it as part of language. Another way to think
> > of it is whether or not it would work the same in AVMPlus (which is
> > 'bare-bones' as3 types, and which I use for testing sometimes locally).
> > The change can certainly break certain patterns that may have been used.
> > One of them I can think of is not that unusual, such as:
> > switch(obj.constructor) {
> > case XML:
> >
> > break;
> > case SomethingElse:
> >
> > break;
> >
> > }
> > The above would potentially no longer work the same.
> >
> > It's more the case that if something can work the same, I feel like it
> > should, to keep things as consistent and reliable as possible. That
> > certainly is what clients are telling me they are looking for when
> porting
> > a legacy app, and it is one of the biggest credibility challenges that
> > Royale has to address in terms of gaining acceptance with a new user :
> > 'Does it really work the same?'
> > We often say that for porting to Royale, the business logic should remain
> > the same and the majority of the work is in the views. I don't know how
> > many you've worked on, but I've worked on 4 large codebases now. If I
> > reflect on the past year, the majority of my effort and biggest issues
> were
> > actually with problems related to business logic, probably AMF related
> with
> > Carlos and XML for another recent client. The view stuff has been
> > relatively easy (there absolutely are things to improve in this area
> still,
> > but the problems have been 'minor' by comparison). So please forgive me
> if
> > I tend to be a little resistant to anything that might make business
> logic
> > stuff work less often than it otherwise could, I am only focusing on
> what I
> > think is best for Royale.
> >
> > Where subclassing helps is that the browser tools group instances by
> class,
> > so this way, you get (most of) elements, text and attributes grouped
> > separately
> >
> > Did you try the dev tools enhancement that I posted elsewhere? I'm pretty
> > sure that objective can be achieved without any changes to the Royale
> > classes, and you can even have color coding for the different XML
> nodeKinds
> > etc. I think we could probably do that support for any _ROYALE_CLASS_INFO
> > instance providing custom inspection or even separation of private
> members
> > from public etc to avoid visual clutter in the browser tools. At least I
> > know it can be done in Chrome. I think it might be supported in some
> other
> > browsers, but did not try that yet. We could probably make debugging/dev
> > support a whole lot nicer in general with external stuff like this.
> >
> >
> > On Wed, Dec 11, 2019 at 11:17 AM Harbs <[email protected]> wrote:
> >
> >> The subclass approach prevents the need to keep a record of the node
> type
> >> for the vast majority on nodes.
> >>
> >> I no longer have clear data on how much that helped for memory, but I
> >> think it helped somewhat.
> >>
> >> Feel free to do more investigation into that.
> >>
> >> I don’t think subclassing effects language conformity. Am I wrong? Where
> >> subclassing helps is that the browser tools group instances by class, so
> >> this way, you get (most of) elements, text and attributes grouped
> >> separately.
> >>
> >> Thanks,
> >> Harbs
> >>
> >>> On Dec 10, 2019, at 11:56 PM, Greg Dove <[email protected]> wrote:
> >>>
> >>> That does sound like a great improvement, Harbs. Congrats on the
> massive
> >>> memory improvements!
> >>>
> >>> If the 'subclass' approach for attributes and text was not the main
> basis
> >>> for achieving the improvements, do you consider that we can avoid those
> >>> subclasses and restore the more conforming actionscript 3
> implementation?
> >>>
> >>> If that change with subclasses was for ease of debugging only, then I'd
> >> be
> >>> keen to find better ways to make debugging easier as I mentioned
> >> elsewhere,
> >>> keeping language conformance for what is a core as3 type, and therefore
> >>> keeping the best chance of what we have working with all legacy code.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Dec 11, 2019 at 1:55 AM Harbs <[email protected]> wrote:
> >>>
> >>>> One thing to keep in mind with XML:
> >>>>
> >>>> If you keep even a single node (element or attribute) in memory, that
> >> will
> >>>> retain your entire tree.
> >>>>
> >>>> Make sure you use copy() (or setParent(null)) to get rid of parent
> >>>> references for leaf nodes that might be kept.
> >>>>
> >>>> HTH,
> >>>> Harbs
> >>>>
> >>>>> On Dec 10, 2019, at 1:14 PM, Piotr Zarzycki <
> [email protected]
> >>>
> >>>> wrote:
> >>>>>
> >>>>> Hi Harbs,
> >>>>>
> >>>>> Great work! We are using in our app XML - didn't check earlier memory
> >>>>> consumption, but it looks like really good improvement.
> >>>>>
> >>>>> Thanks,
> >>>>> Piotr
> >>>>>
> >>>>> wt., 10 gru 2019 o 11:04 Harbs <[email protected]> napisał(a):
> >>>>>
> >>>>>> I just added code like this to the constructor:
> >>>>>>
> >>>>>> if(!_class_initialized)
> >>>>>> {
> >>>>>> Object.defineProperty(XML.prototype,"0",
> >>>>>> {
> >>>>>> "get": function():XML{return this as
> >>>> XML},
> >>>>>> "set": function():void{},
> >>>>>> enumerable: true,
> >>>>>> configurable: true
> >>>>>> }
> >>>>>> );
> >>>>>> _class_initialized = true;
> >>>>>> }
> >>>>>>
> >>>>>> where _class_initialized is a static boolean.
> >>>>>>
> >>>>>> This sliced the memory requirements for XML instances in roughly
> half!
> >>>>>>
> >>>>>> Not totally thrilled with the conditional code in the constructor,
> >> but I
> >>>>>> don’t have any better ideas at the moment.
> >>>>>>
> >>>>>> Between the improvements I’ve made to XML and aggressive work on
> >>>> removing
> >>>>>> extraneous object references (particularly XML), I’ve reduced the
> >> memory
> >>>>>> footprint of my app for a particularly complex document from about
> >> 155MB
> >>>>>> down to 103MB.
> >>>>>>
> >>>>>> The memory impact of using XML went from about 75MB down to 22MB.
> >>>> (That’s
> >>>>>> for well over 100,000 nodes kept in memory.)
> >>>>>>
> >>>>>> Not bad for a few days work… ;-)
> >>>>>>
> >>>>>> Harbs
> >>>>>>
> >>>>>>> On Dec 9, 2019, at 7:19 PM, Greg Dove <[email protected]> wrote:
> >>>>>>>
> >>>>>>> btw I am still happy to look into the possibility of doing a first
> >> time
> >>>>>>> 'get' access for the Class itself on its package that runs static
> >> code,
> >>>>>> but
> >>>>>>> as Alex pointed out, it could have issues with the minified
> version,
> >> so
> >>>>>> it
> >>>>>>> is more at 'investigate' rather than 'solution' stage. I have not
> >>>>>>> prioritized this for now...
> >>>>>>>
> >>>>>>>
> >>>>>>> On Tue, Dec 10, 2019 at 6:13 AM Greg Dove <[email protected]>
> >> wrote:
> >>>>>>>
> >>>>>>>> This might be a good candidate for getting the static
> initialization
> >>>>>> code
> >>>>>>>> block working (it is currently not in js).
> >>>>>>>>
> >>>>>>>> We discussed that recently in another thread.
> >>>>>>>>
> >>>>>>>> public class MyClass{
> >>>>>>>>
> >>>>>>>> {//static init block
> >>>>>>>> COMPILE::JS{
> >>>>>>>> Object.defineProperty(MyClass.prototype,"0",
> >>>>>>>> {
> >>>>>>>> "get": function(){return this},
> >>>>>>>> "set": function(){},
> >>>>>>>> enumerable: true,
> >>>>>>>> configurable: true
> >>>>>>>> }
> >>>>>>>> );
> >>>>>>>> }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> public function MyClass (){
> >>>>>>>>
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> On Tue, Dec 10, 2019 at 6:00 AM Alex Harui
> <[email protected]
> >>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Did you try:
> >>>>>>>>>
> >>>>>>>>> function get 0():XML { return this; }
> >>>>>>>>> function set 0(value:XML) {}
> >>>>>>>>>
> >>>>>>>>> Within a COMPILE::JS, I think the variables:
> >>>>>>>>>
> >>>>>>>>> this["constructor"]
> >>>>>>>>> this["__proto__"]
> >>>>>>>>>
> >>>>>>>>> are available.
> >>>>>>>>>
> >>>>>>>>> HTH,
> >>>>>>>>> -Alex
> >>>>>>>>>
> >>>>>>>>> On 12/9/19, 8:27 AM, "Harbs" <[email protected]> wrote:
> >>>>>>>>>
> >>>>>>>>> In my question to minimize memory requirements in XML, I’d like
> to
> >>>>>>>>> optimize the zero index accessor.
> >>>>>>>>>
> >>>>>>>>> Right now, we have Object.defineProperty in the XML constructor.
> >>>> The
> >>>>>>>>> byproduct of that is we have a function defined on every single
> >>>>>> instance of
> >>>>>>>>> XML. Ideally that should be on the prototype object. This should
> >>>>>>>>> drastically reduce the memory requirements for instantiating XML.
> >>>>>>>>>
> >>>>>>>>> In JS, that’s pretty easy to do:
> >>>>>>>>>
> >>>>>>>>> Object.defineProperty(thePrototype,"0",
> >>>>>>>>> {
> >>>>>>>>> "get": function(){return this},
> >>>>>>>>> "set": function(){},
> >>>>>>>>> enumerable: true,
> >>>>>>>>> configurable: true
> >>>>>>>>> }
> >>>>>>>>> );
> >>>>>>>>>
> >>>>>>>>> I’m struggling with how to do it in AS3. How can we get a
> >> reference
> >>>>>>>>> to the prototype outside the constructor or have the compiler
> >>>> construct
> >>>>>>>>> this kind of function automatically?
> >>>>>>>>>
> >>>>>>>>> Thoughts?
> >>>>>>>>> Harbs
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Piotr Zarzycki
> >>>>>
> >>>>> Patreon: *https://www.patreon.com/piotrzarzycki
> >>>>> <https://www.patreon.com/piotrzarzycki>*
> >>>>
> >>>>
> >>
> >>
>
>
