Wait, why is the unroll() necessary?  A string is a 1D array of characters, it shouldn't even be possible to unroll it seeing as unrolling is for multidimensional arrays...

So yeah, I is comfuzed.

No, I'm not talking about a single array of characters, it's lines of text, so a 1D array of 1D strings, which can be unrolled.

Oh, I think you slightly misunderstood the domain of NTML; it's not conveniently aliased markup like Markdown or Wikitext, but instead more like HTML or BBCode.

I did restore NTML's wiki page a while back, so anyone who wants to can download the old, hopefully still working, version of the tech demo. NTML and the handler script are in dire need of updating to be cleaner and easier to extend in the future.

Ah, my bad. My simple parser is a simple markdown-like syntax so I could write game dialogue easily, I hate writing escapable tags. I realized all that fancy text markup stuff is just a gimmick in the end and all I really need is basically one markup piece: emphasis. That and perhaps recoloring quoted text.

Saying: "Well he *said* he was going to get :the keys:."
Would be easier than: "Well he <i>said</i> he was going to <shaky>get</shaky> <color="yellow">the keys</color>"
Even if it was at reduced freedom, still 10x better to understand. (you might have differing tags, etc. but any *TML system would be similar.

Ah, that makes more sense.  I think what threw me was in your original post, you said "Did you know you can unroll strings?"  I guess I just glossed right over the actual example since I was hung up on "wait a minute, you can't unroll a string, it's 1D".  Kind of put me in a trance I guess.  So yeah, my bad.

Hey, out of curiosity, is Link prone to crashing Sphere?  Lately Spectacles has started causing random Sphere crashes, but the only major change I've made recently is the addition of Link, so...

Hey, out of curiosity, is Link prone to crashing Sphere?  Lately Spectacles has started causing random Sphere crashes, but the only major change I've made recently is the addition of Link, so...

What version? I know 1.6 crashes on things like windowstyles.

1.5.  I tried 1.6 a while back but it was too unstable so I was forced to go back to 1.5.  It's been rock-solid for me so far, but something I changed recently is causing engine crashes, so I'm trying to narrow it down.  It's times like this I wish Sphere had a debugger...

And I'm not using windowstyles so that's not it.

Hmm, it'd be hard to tell where exactly 1.5 is failing if it's Link, because that's purely a JS thing. Link should be stable even though it's still in development, the only thing I can foresee is that creating new link contexts each time could be the culprit:

Code: (javascript) [Select]

// this:
for (var i = 0; i < 1000; ++i) Link(array).filter().map().whatever().each();

// versus this:
var l = Link(array).filter().map().whatever();
for (var i = 0; i < 1000; ++i) l.each();

The top code may use more memory more frequently than the bottom code. What it *might* be is Sphere running out of JS memory in certain spikes, even if it's GC'ing it perfectly. It could be that at some moments it doesn't GC in time and breaches the max memory. What kind of crashes are you experiencing? Crash to desktop or is there an actual error message?

Edit:
I'm having the hardest time trying to implement a string .split method in this lazy format. The issue I'm having is splitting the last word. Take this example: "Hi how are you?".split(" "). It should split into the 4 words: "Hi" "how" "are" "you?", but once Link sees the '?' it stops execution at that point since it reached the end of the road. I only get back the first 3 of the 4 words. In a lazy context there is no easy way of detecting the end of the road. I could run the first n-1 items, then on the last item, item n, run a special condition saying you reached the end, and split there. But that's great until you start filtering things out. Then the true end position has changed, it might no longer be at the end of the originating array. I'll have to rethink my lazy strategy to account for this inconvenience.

I might even have to rewrite the entire library.

It's a hard crash to desktop.  No error message, Windows just suddenly throws up a crash dialog and closes it out.  I'm wondering if it is a memory breach as you said, since I do create a lot of Link contexts.  Nothing as extreme as your 1000-iteration loop, but I create a new Link context every time a battle unit requests a turn forecast, among other things.  Seeing as this often happens many times per ATB cycle (enemy AIs do it a ton and a new forecast is taken every time a different attack is selected in the menu)...

How much memory does Sphere allocate to JS anyway?  From what I've read around the forums I get the impression it's not a whole lot.

According to the dev log in the internal docs, scripts get 256k of memory.

Wow, that's tight.  I was expecting a couple MB at least, 256k is insane.

Consider, though, that the size of every engine defined object is only a few tens of bytes at most on the script side. In fact, strings may be handled similarly.

Also, Lord English, don't create a lot of on-the-fly anonymous functions in Sphere. They are notorious for consuming a lot of memory and sadly Vanilla Sphere's JS doesn't do any smart caching on them. This is also true for any nested functions (which should ideally be cached, but aren't).

Code: (javascript) [Select]

Link(array).where(function(i) { return i %2 == 0; }).each();

// versus:
var f = function(i) { i%2 == 0; };
Link(array).where(f).each(); // later on.

So, about my Link.split method, I don't think it's possible. Link only looks at the current state each iteration. I don't know how libraries like Lazy do it. They must have some cheap method of peaking ahead... Or they truly aren't lazy. Or .split is relegated to very specific use cases and break otherwise. I could do a lazy-evaluated split statement, but it can only be run as the first thing in a series of steps.

So, this is possible: Link(string).split(" ").filter().each();
But this is not: Link(string).filter().split(" ").each();

Very interesting: I just checked the Windows event viewer after Spectacles crashed again, and it's a segfault.  That's not the interesting part, though, THIS is:

Faulting application name: engine.exe, version: 1.5.0.0, time stamp: 0x487de926
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00000000
Faulting process id: 0x1940
Faulting application start time: 0x01cf424eb43b96a6
Faulting application path: C:\Sphere1.5\engine.exe
Faulting module path: unknown
Report Id: f3a6c5b5-ae41-11e3-826c-a088692e88a2
Faulting package full name:
Faulting package-relative application ID:

...it's a null pointer dereference.  Now I'm not sure what's causing the issue, as I'm pretty sure I may have dug up an honest-to-goodness, legitimate engine bug.

I'd be interested in seeing a stack trace of this. Bear in mind, I've found bugs in libJS 1.5 before, so it might not really be fixable.

The crash report in the event viewer doesn't have a stack trace.  Would I be able to get one by running the engine under the VS debugger or do I need a debug build of Sphere for it to be useful?  Because I don't have a copy of VC++ 6.0 handy anymore to do that...

A true release build has stripped symbols, and its stacktrace is completely useless, unless VC has symbolification like Xcode does and a symbol file is available.

By default, VC does generate symbol files (.pdb) even in release mode--to make diagnosing release mode-only bugs easier I assume--but they aren't included with Sphere at any rate.  Oh well.