widgets & lcVCS

[LCMark]

@monte: Sorry - completely misread what you said! Looks like I screwed up the docs slightly then I'll sort out getting that patched! Thanks

[monte]

No problem.

Can I assume that if I set a custom property key or value to a string in one session that when it's retrieved in the next session `is really a string` will still be true?

[LCMark]

@monte: Yes - as long as you save in LC7+ format

Custom property values are no longer stored as only 'legacy' strings. They are stored as the ValueRef type that they were last set to:

Code: Select all

set the myIntegerProp of me to 100 + 100 -- this will save as an integer
set the myBooleanProp of me to 1 is 1 -- this will save as boolean true
set the myDataProp of me to the compress of "Hello World!" -- this will save as data
etc.

In fact, internally, custom prop values are serialized using the arrayEncode format. In 7.0 this is fully-faithful with respect internal value representations, < 7.0 this format stores things as either strings or doubles.

[monte]

Excellent.

BTW I was looking at implementing YAML <-> Array based on yaml-cpp to see if that worked better than JSON. I like the idea of multiline text blocks and a file format that doesn't have the trailing comma issues and I can't help wondering if it would be feasible to have one big file in a structured format like that. However, I ran into a road block when I realised that you can't pass arrays back and forth from lcidl externals unless I use the objective-c stuff you did which I want to avoid so it's cross platform. I'm not really sure what all that array syntax is for now unless I'm missing something. I thought it's probably better to wait to see if I can do it in LCB sometime soon.

[LCMark]

The array api in the extv1 interface is unimplementable in 7 which is we moved the obj-c type bridging into the engine.

Peter implemented a Json parser in LCB so using LCB for things is feasible if a little lacking in performance at the moment.

In terms of foreign hooks it might be good enough to wrap a c library. Native code carrying extensions do now work (although I think we still need to do some work on the sb) and callbacks to LCB from C now work reasonably well - there were merged in for DP5.

[monte]

Oooo... I don't care about the sb at this stage. Can you point me to any docs or a PR where this was discussed so I can investigate? libyaml is C and the yaml site says it's fast. I could do it all in LCB like Peter did but it needs to be super fast not just relatively quick. If I can do the array handling in a LCB library and the yaml yam input and output in C then it should be pretty quick.

[monte]

OK, I found the doc about where to include the file in the extension. Any clues about working with structs might be helpful as libyaml has a bucket load. It would be particularly nice if we could somehow import a header file and use enums etc...