@richie see above https://chat.stackexchange.com/transcript/message/53835279#53835279 we have already 12 adverb derived functions without counting overloads of non-function+adverb derivatives like "for". How many more do you want? What's missing?
@yiyus lambdas in x,y,z are common in some contexts, rare in others. for example, when writing for a limited audience of k experts i prefer very short names and very compact code. when writing as part of a larger team with a large and complex code-base, i will use longer descriptive names (for the functions, not the locals) and an explicit argument list. and in that case i will adopt a style of short lines with at most a single assignment -- a:...
@ktye one or more recursive combinators, as developed by john earnest and i and presented in his vector paper of a few years ago.
regarding how to map single symbolic characters to useful array ops, matters get simpler when designing a purely concatenative language on the model of Joy, or the even simpler language False. if you have any interest in this topic you can study the assignments i make in the two false-like languages F and G here: nsl.com/k/f/f.htm, especially section 9.
@ngn tring to port ngn/k to macos with nostdlib. now get only one test case left. n:#1:"t.k";(0<n)&n<10000000. which gives 'mmap1 error. i looked at the implementation of 1: what's the two-step mmap for? i don't i have enough knowledge to debug this...
maybe two-phase freeing could work. first: decrement the refcount, test for 0, and reclaim ordinary memory, second: unmap it if it was a file.
in addition, allocations are not allowed beween the two steps (this is asserted in debug mode)
the purpose is to make memory access more sequential - the refcount is in the header, so better deal with it first instead "going back" after the vector's data is processed
oops.. ignore the above - that was about the two-step free()
@ksi the two-step mmap() works like this: the first call to mmap allocates memory for the array + 1 additional page. the additional page is for the header. even though the header is just 16 bytes, it must take a whole page, because mmap() can only work on page-aligned addresses.
the second mmap() puts the file content within the memory allocated by the first mmap(), leaving out the first page
did i explain it well enough? i'm not good at this.. i'll try to draw a diagram
| | | | | |
| hdr|content,content,content.. |
\_____/
1 page=4096 bytes
^ ^
| |
| second mmap is MAP_FIXED at this address
| and it puts file content there
|
first mmap returns this address as MAP_ANONYMOUS memory
@ngn i think i got you, so we should expect the second mmap() return the same pointer as ZP+p, if the file is correctly mapped to that chunk of memory. so, error probably means the file is mapped to somewhere else or maybe error happened.
@ksi i'm not sure what you mean. could you rephrase the question?
the first mmap makes sure there's enough room for header+content. the second mmap "fills in" the actual content. i don't think i can get away with a single mmap.
@ngn okay i will look more into this. another strange thing is when i change the optimization flag from O0 to O3, three more json parser test cases fails, although i manually checked and found the results are correct.
@ktye I'd get rid of the overloads and promote function take and function drop to a bonafide adverb called filter instead of using overloads of # and _ which are verbs