newlispfanclub.alh.net

Thanks Hartrock, fixed here:
http://www.newlisp.org/downloads/develo ... nprogress/ 2015-09-11 16:19

Try to boil down the code to the least amount needed to produce the error. Back-tracing does not help here.

extend is destructive append is not. Many things in newLISP can be done in either a destructive or non-destructive manner and destructive functions are marked with an ! in the reference. http://www.newlisp.org/downloads/newlisp_manual.html#destructive Most destructive functions - like extend too - ...

After doing a few more benchmarks, I stay with append, which is faster when appending more than a few strings. In the save case you have at least about 30 strings of about 72 characters each. extend does a realloc() on each string, while append allocates memory in bigger chunks.

save strings longer than 2047 will now be broken up in portions of up to 72 characters delimited by normal quotes "..." and escaped for unprintable characters. For example{ (set 'str (dup "Part of \000 a long string with more than 2047 chars. " 45)) produces using save : (set 'str (append "Part of ...

In Hartrock’s example the \000 characters are still in sb but text in [text],[/text] tags does not escape characters, so \000 is not shown, although part of sb . Right now in 10.6.4 (in progress) base64 encoding is used for strings > 2047 characters and containing the [/text] tag when using save . I...

see here: http://www.newlisp.org/downloads/develo ... nprogress/

The distinction of shorter or bigger-equal than 2048 is done for speed. The internal string representation is the same. What differs is the method used for reading strings from source. For strings shorter than 2048 limited by “” or {}, allocated buffers or the stack and one read() is used. On output...

In v10.6.4 the manual entry has been changed to constant.

Note, that changes to an expansion macro definition only affect future loaded code, not already read and expanded code.

Ps: don't delete bug posts.

Yes, the TDM-GCC 32/64 toolset, it also seems to use MinGW but is easier to install and compiles both: 32-bit and 64-bit executables and DLLs with less problems. The GCC used seems to be a 32-bit executable, not 64-bit as earlier stated. The installation comes with both 32-bit and 64-bit libraries. ...

For patterns, which don’t address UTF8 characters as a single character, working with to without the PCRE_UTF8 flag 2048 or “u” will not make a difference, but the flag is needed when looking at multibyte sequences as UTF8 characters: > (set 'utf8str "我能吞下玻璃而不伤身体。") "我能吞下玻璃而不伤身体。" > (regex "(.)(.)(....

The options PCRE_NOTBOL 128, PCRE_NOTEOL 256 and PCRE_NOTEMPTY 1024 now work:

http://www.newlisp.org/downloads/develo ... nprogress/

Ps: updated again: 2015-08-09 16:32

Ps: see also post in newS section of forum about the significance of the PCRE_UTF8 option (--> Ted Walther)

The “ERR: invalid UTF8 string” error is only thrown by newLISP when a string finishes before a multibyte UTF8 character has finished. All other regex errors are generated when the PCRE lib regex call comes back with an error and messages like "offset 0 unknown option bit(s) set" which are generated ...

Even on UTF8 enabled newLISP, regex and other regex enabled functions will still allow searching for raw octets or combinations of octets: > (set 'str "我能吞下玻璃而不伤身体。") "我能吞下玻璃而不伤身体。" > (unpack (dup "b" (length str)) str) (230 136 145 232 131 189 229 144 158 228 184 139 231 142 187 231 146 131 232 128...

Thanks Hartrock, the change was fine, but we can even go a step further, never changing list optimization when using pop on a list:
http://www.newlisp.org/downloads/develo ... nprogress/

... although the change is small, it still needs a lot of testing.

You could try to avoid regular expressions in the send&print function, either by using find without the regex option number or by using simple string comparisons when the search is at the beginning or at the end: > (set 'str "PING : abcdefgh\n") "PING : abcdefgh\n" > (= (last str) "\n") true > (= "P...

> (set 'a "foo\rb" 'b "barn\n") "barn\n" > (regex "\\r|\\n$" a 32) ("\r" 3 1) > (regex {\r|\n$} a 32) ("\r" 3 1) > (regex "\\r|\\n$" b 32) ("\n" 4 1) > (regex {\r|\n$} b 32) ("\n" 4 1) > (regex "\\r|\\n$" a 0) ("\r" 3 1) > (regex "\\r|\\n$" b 0) ("\n" 4 1) > (regex {\r|\n$} a) ("\r" 3 1) > (regex {...

pop with index undoes last element optimization, FIFO push on last position after this is then slow because it has to walk through the whole list to find the last element but reestablishes last element optimization after.

Talking about performance: when a list gets extended at the end, the last cell address is stored in cell->aux of the envelope cell as an optimization. When accessing the last cell in a list, newLISP checks first if the list is in an optimized status by looking at cell->aux. For that reason a FIFO pu...

This was broken when introducing list-mode for parameters in development 10.6.3. Now fixed in: http://www.newlisp.org/downloads/develo ... nprogress/

You are making the point that push is an exception to the rule: flag 0, -1 on empty lists as errors. pop and everything else do flag this as error but push doesn't. There is a frequent code pattern used where you build lists or queues by always push ing to the end using the -1 index to build queues ...

Up to version 9.2.11 when indexing lists, indices too big would pick the last element and indices to small or to negative would pick the first element in a list. For empty lists the result would be nil in a consistent fashion, e.g for pop , nth , first , last etc.. In programming practice this often...

The installer and configure script will use /usr/local/bin , which will be writable by the user in OSX 10.11. The configure-alt script already uses that directory. Changes are also completely compatible with older versions of OSX, as /usr/local/ always existed and always has been used by third party...

check out: http://www.newlisp.org/downloads/develo ... nprogress/ 2015-07-24 02:12

now always four members in list mode: header, content, http response line, status code

Trying to accomodate your observations but maintaining compatibility with earlier versions: Not in list mode : As in earlier versions delete/get/put/post -url always return a string. This string is either the content returned by the server or an error string starting with "ERR: " followed either by ...