Hypothetically speaking, you should be able to determine something about the stack by examining the address of a local variable which is on the stack.
This gives a crude way of determining stack size: write a recursive function which prints the address of a local variable (and flushes that print buffer) then calls itself again. When the program crashes you can inspect the starting and ending address and look at the difference to determine the stack size. (And, unless someone got fancy, you can check that all addresses in between have the same address offset between them.) (There might be other OS-specific or compiler-specific ways of determining allocated stack size.) Once you have an idea of stack size, it should be relatively simple to put a check on stack size somewhere convenient (for example, memory allocation - since that tends to be called in a lot of places). If you've reached some threshold, have that routine (or those routines) fail with a stack out-of-bounds error. That said, some compiler optimizations might defeat this approach. If those are detected, I guess they would need to be documented (in some developer-oriented document - perhaps a README for the source). I hope this helps, -- Raul On Tue, May 17, 2016 at 1:01 AM, Henry Rich <[email protected]> wrote: > The root of the problem is that 'stack error' is unreliable. Depending on > how much execution stack each recursion uses, you may get a J crash rather > than a stack error. I am thinking about ways to fix this, but I haven't > found one yet. The simple cases you give do not crash, but if you throw in > " and ^: a few times in the recursive part, they will crash. > > In the meantime, an alternative is to prevent sources of stack error, and > this one could be pretty easily fixed by legislating it out of existence. > > My guess also is that the sentence was not an accident, and that Dan Bron > was noodling around on the fringes when he found it. If no one has ever > used verb-producing-gerund to solve an actual problem, that to me would be > license enough to put it to the sword. > > I would like to leave it that if I can't find a bulletproof fix for the > stack error problem, we will remove this source of error from ^: (and also > from }, as you mention), UNLESS someone can show cause why the current > behavior should be retained. I will take no action without a consensus from > the J community (and I don't have authority to do so anyway). > > Henry Rich > > > > On 5/15/2016 12:35 PM, Jose Mario Quintana wrote: >> >> That sentence is very interesting. How did originate? My guess is that >> it >> was not an accident. >> >> Rather than a problem I see a potential opportunity; it is a tacit >> construction and, usually, variants of self-replicating forms can be quite >> useful. The sentence f^:] 0&]`] is akin to the sentence $: 0 ; one >> should be careful about what one is asking the interpreter to accomplish. >> In my opinion, the users should be, and ultimately are, responsible for >> their actions. There are many other trouble making sentences, >> >> ($: $: $:)_ >> (>:^:6666666666666666666666666666666666666666x)0 >> ]`]}]`] >> >> etc. >> >> Why one should be focusing on this f^:] 0&]`] (and other similar >> sentences >> involving ^:) in particular? The easiest fix seems too drastic, to me at >> least, since it would imply changing not just the Dictionary entry for ^: >> (incidentally, in that entry } is referred as the "merge" adverb, which is >> news to me) but arguably also for } since the sentence ]`]}]`] also >> crashes the interpreter in a similar fashion. >> >> For an example where creating a gerund makes sense see [0]; not to mention >> [1]. >> >> For what is worth, clearly, I do not like this proposal: it would require >> changes to the dictionary; these changes would add complexity to the >> definitions; the definitions would be less consistent since they would >> introduce exceptions. Although the change would prevent certain crashes, >> which are unlikely to occur by chance, it would do so by forcing a >> limitation which might even brake some existent code. >> >> PS. After years of neglect, I am glad to see a lot of activity around the >> J Engine. I am particularly interested to experience the results of the >> Reference count update status project. >> >> References >> >> [0] [Jprogramming] conjunction in tacit verb >> >> http://www.jsoftware.com/pipermail/programming/2015-February/040994.html >> >> >> [1] [Jprogramming] applying >1 gerunds to a set of items >> >> http://www.jsoftware.com/pipermail/programming/2013-January/031234.html >> >> >> On Wed, May 11, 2016 at 10:02 PM, chris burke <[email protected]> >> wrote: >> >>> ---------- Forwarded message ---------- >>> From: Henry Rich <[email protected]> >>> Date: 8 May 2016 at 12:17 >>> Subject: In u^:v, v may not return a gerund (proposal) >>> To: [email protected] >>> >>> >>> I am working on an old problem: >>> >>> f^:] 0&]`] >>> >>> crashes, because executing ] creates a gerund, which executes to produce >>> the same gerund, etc. >>> >>> The easiest fix is to decree that in u^:v, ([x]v y) may not produce a >>> gerund. Similarly in the forms u^:[v0]`v1`v2, ([x] v1 y) may not produce >>> a >>> gerund. >>> >>> Anybody got a problem with that? I can't think of any case where >>> creating >>> a gerund makes any sense at all. >>> >>> Henry >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
