Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Cyril

#1
newLISP and the O.S. / exec in newlisp 10.7.1/Windows
February 17, 2017, 10:29:34 AM
Seems like exec in newlisp 10.7.1/Windows opens it's second argument in text (as opposed to binary) mode. Test:
(exec "od -b" "hellornworldrn")
Output with newlisp 10.6.2
0000000 150 145 154 154 157 015 012 167 157 162 154 144 015 012
Output with newlisp 10.7.1
0000000 150 145 154 154 157 015 015 012 167 157 162 154 144 015 015 012
I suppose this is a side effect of the change to a newer MinGW. But still confusing - "binary mode everywhere" policy was consistent so far.
#2
newLISP newS / newlisp.vim 1.37
June 02, 2013, 12:36:22 PM
I have updated my newlisp.vim syntax highlighter; new in this version:



* all the changes made by Lutz during the last two years are adopted.



* some typos introduced by Lutz are removed (some vimscript keywords was erroneously recognized as newlisp functions because of a silly formatting error).



* $count built-in variable is recognized.



* bigint constant affix L is recognized.



* non-change: I was falsely assuming that +.9 syntax was always here, and recognize it as valid; so no need to change here (and I can pretend I've stolen the time machine from Guido).



* string delimiters (quotes and brackets) color is reverted to be the same as the string content; if you like the previous style better, put the following line in your .vimrc:



hi link newlispStringDelimiter String Delimiter



Downloadable from the usual locations (http://www.vim.org/scripts/script.php?script_id=2067">one, http://slobin.ru/vim/syntax/newlisp.vim">two). I believe the highlighter is ready for 10.5.1 newlisp release.
#3
Aha, now it works. (checking other everyday scripts collected over the years) Seems OK. Thank you!
#4
The exec behaviour in win32 was changed somewhere between 10.4.5 and 10.5.0 (sorry, I haven't followed the development releases). In 10.5.0, it replaces "n" line endings with "rn" in the executed process stdin, in all previous versions it wasn't (my pet script I found broken by this is dated back to 2008). Of course my script is trivial to fix, but I believe the old behaivour was more consistent: newlisp never does silent line-ending conversion. I believe the change should be reverted, or, if the new behaviour is official and final, it should be at least documented. Short examples:


newLISP v.10.4.5 on Win32 IPv4/6 libffi, execute 'newlisp -h' for more info.

> (exec "od -bc" "hellonworldn")
0000000 150 145 154 154 157 012 167 157 162 154 144 012
          h   e   l   l   o  n   w   o   r   l   d  n
0000014
true


newLISP v.10.5.0 32-bit on Win32 IPv4/6 libffi, options: newlisp -h

> (exec "od -bc" "hellonworldn")
0000000 150 145 154 154 157 015 012 167 157 162 154 144 015 012
          h   e   l   l   o  r  n   w   o   r   l   d  r  n
0000016
true


And yes, I am still a newlisp user! :-) And I am going to update the newlisp.vim for the new bigint syntax (and some other minor things) in a few days.
#5
newLISP newS / Re: newLISP development release v.10.3.5
November 12, 2011, 12:37:30 PM
Quote from: "Lutz"So now we are back where it always has been, and I think it is more convenient for most users.

That's good. In fact I haven't upgraded from 10.3.2 because of previous behavior (I strongly dislike system directories pollution). Now I'll try to be up to the current release again. :-)
#6
Hmm... I've also forgotten to mark read-buffer as deprecated in my newlisp.vim highliter. But, reading the manual, I conclude that read-buffer was deprecated together with write-buffer. I believe that either both should be marked or both should not. Or do I misunderstand something?
#7
newLISP newS / newlisp.vim 1.35
April 15, 2011, 12:11:23 AM
I've just realized that I haven't visited this forum for a half-year now. I am still using newLISP, just feeling less social about it. ;-) And now is the time for a new version of the syntax highlighter for the Vim text editor. This version is highly experimental, testing and feedback is highly appreciated. User-visible changes:



* String delimiters ("quotes", {braces}, and [text]tokens[/text]) are highlighted in different color than the string content.



* Bracketed symbols [like this] are highlighted in boldface; no other symbols are highlighted in boldface anymore (the newlispSymbolSpecial group is gone).



* Errors highlighting is drastically changed. The newLISP itself allows tokens to touch without  a separator, this leads to very strange code in some cases. For example, 019 is two tokens, not one (digit nine may not occur in octal literal, so it starts a fresh new number). Similarly, one[two] is one single token, but [one]two are two (check this with your newLISP interpreter!). I believe that using this feature in the real code leads to confusion, therefore the adjacent tokens are marked as errors (to be precise, the second of two adjacent tokens is marked as error, this should give you a clue why there are two and not one!). You can see some corner case examples http://slobin.pp.ru/newlisp/errors.lsp.html">here.



Downloadable from the usual locations (http://www.vim.org/scripts/script.php?script_id=2067">one, http://slobin.pp.ru/vim/syntax/newlisp.vim">two). And again, this is an experimental version, please test it before using in production!
#8
newLISP newS / Re: newlisp.vim 1.32
October 07, 2010, 12:46:38 PM
As planned, release 1.33, got in sync with newLISP 10.2.16. In particular:



* functions 'date-list', 'date-parse' and 'net-ipv' are added,



* function 'parse-date' is marked as deprecated,



* functions 'error-number' and 'error-text' are marked as obsolete,



BTW, 'error-number' is still mentioned in Code Patterns, and 'error-text' in xmlrpc.cgi example.



* "deprecated" and "obsolete" sections are separated; now "deprecated" are functions that are still in executable, and "obsolete" are that aren't. By default both types are displayed the same way (in "TODO" color), but you can override this in your .vimrc, for example:



hi link newlispDeprecated newlispSymbol



* NOT DONE: in his deleted comment Lutz have enlightened me about the [bracketed symbol] syntax. I have no clue about it before, and need some time to rethink some corner cases (like [(] ). So DON'T expect this been fixed soon (at least, not this week). Sorry.



Downloadable from usual locations (http://www.vim.org/scripts/script.php?script_id=2067">one, http://slobin.pp.ru/vim/syntax/newlisp.vim">two). Probably no new releases before newLISP 10.3.



P.S. And I don't claim it is compatible with Vim 6.x anymore. No, I haven't broke anything intentionally, I just don't care. ;-)
#9
newLISP newS / newlisp.vim 1.32 (and 1.33!)
October 06, 2010, 07:53:16 PM
Another release of the newLISP syntax highlighter for the Vim text editor. A subtle bug was fixed: an unbalanced parentheses inside the font highlighting (italic or monospace) inside documenting comments was breaking the Vim built-in paren matching. Example:



;; Unbalanced paren (



was OK, but



;; Unbalanced paren '('



was not. Now the later is OK too. Downloadable from usual locations (http://www.vim.org/scripts/script.php?script_id=2067">one, http://slobin.pp.ru/vim/syntax/newlisp.vim">two). It will be helpful if someone will test this and report bugs (if any), because I am going to release the 1.33 version real soon now (next 24 hours or so), including all the new stuff from newLISP 10.2.16, in hope it will be the final release before newLISP 10.3. Thanks in advance!



If someone want to know the technical details: the Vim is very smart in parentheses matching job, it promptly skips the parentheses inside strings and comments. But strings and comments may have different syntax in different languages, so the definition is "any highlighting class whose name contains 'string' or 'comment'". In the previous versions of my highlighter, both plain comments and documenting comments does contain the word 'comment' in its name, but highlighted font sections inside doc comments was not. Now they are properly renamed.
#10
I have found this funny regexp http://www.kite-language.org/article/something-fun-to-try/">here, guess what it matches? Or check it with newLISP:
(for (i 1 100)
  (unless (regex {^1?$|^(11+?)1+$} (dup "1" i))
    (print i " ")))

Astonishing! ;-)
#11
newLISP and the O.S. / Re: Benchmarking newLISP
September 23, 2010, 06:42:18 AM
Quote from: "xytroxon"I upgraded over the summer...


I am in upgrade just now! This is probably the very last message I write from the my old box. So...


3.25 ; Windows XP at Intel Pentium III, 800 MHz - Cyril

And the result from the my new box will be in a few hours! ;-)



Update:


0.55 ; Windows XP at AMD Phenom II X2 545, 3 GHz - Cyril
#12
Quote from: "Lutz"In the next version an addtional "process creation flags" -parameter can be used on Windows versions of newLISP.


My problem was not wrong parameters, but the return value. What is the "pid" returned, and how can one use it? In Linux, it can be passed to wait-pid, but in Win32 there is no such function, and WaitForSingleObject system call accepts process handle instead. My example was written with the single goal to obtain this process handle.


Quote from: "Lutz"While coding this, the following details in run-and-wait.lsp caught my attention: Shouldn't the size for STARTUPINFO si be 72? I believe the total structure size including the si.cb field should be taken? In any case having it bigger probably doesn't make a difference;si. cb now as sizeof(STARTUPINFO).


sizeof(STARTUPINFO) is 68 on my system, and (pack "ld n64" 68) seems to be 68 bytes in total (4 bytes for si.cb and 64 zeros).


#include <stdio.h>
#include <windows.h>

int main(void)
{
  printf("%dn", sizeof(STARTUPINFO));
}



Have I miscalculated something?


Quote from: "Lutz"As flags you specify 32 or 0x00000020 for dwCreationFlags, couldn't find that flag on this page:



http://msdn.microsoft.com/en-us/library">http://msdn.microsoft.com/en-us/library ... 85%29.aspx



but found 0x00000200 (512) for CREATE_NEW_PROCESS_GROUP. If this is what you meant, we could take this as the default value or just leave it as zero.


I have modeled my code after http://www.chami.com/tips/delphi/122096D.html">this example, and 32 was intended to mean NORMAL_PRIORITY_CLASS. But now I see (from http://msdn.microsoft.com/en-us/library/ms682425%28VS.85%29.aspx">this msdn page) that this is the default, and yes, therefore this parameter may be safely replaced to zero. Thanks, I'll do this (for the sake of simplicity).


Quote from: "Lutz"ps: also on my system XP running in VirtualBox on Mac OS X, there is no difference running the old or new '!' function, althoigh others are observing this. No additional command shell, except for the one running the calling newLISP instance, is created no matter what function or flags.


I do close the initial command shell (by standard trick of using FreeConsole imported from kernel32) at the very first lines of my script, and then ! re-creates it. Try this example:


(import "kernel32" "FreeConsole")
(FreeConsole)

(sleep 5000) ; no console window while sleeping

(! "notepad.exe") ; two windows are created: cmd.exe and notepad.exe

(exit)

This is the problem I try to avoid.
#13
Anything else we might add? / Re: Programmer's Day
September 13, 2010, 06:37:58 AM
Thanks, Lutz! I'm going to celebrate, now! (Hm... Picking my newlisp T-shirt... It's a bit cold outside, but... OK, I'll wear it, nevertheless! :-)
#14
Thanks, HPW! The solutions from the thread you mentioned aren't applicable to my problem directly, but they have inspired me to read the source, and to write some newlisp code based on them. Here it is:


(import "kernel32" "CreateProcessA")
(import "kernel32" "WaitForSingleObject")
(import "kernel32" "CloseHandle")

(define (run-and-wait command-line , si pi ph th)
    (setq si (pack "ld n64" 68))
    (setq pi (pack "n16"))
    (CreateProcessA 0 command-line 0 0 0 32 0 0 si pi)
    (map set '(ph th) (unpack "ld ld" pi))
    (WaitForSingleObject ph 0xFFFFFFFF)
    (CloseHandle ph)
    (CloseHandle th))

(run-and-wait "notepad.exe")

(exit)


The function run-and-wait runs a command and wait for it to finish, just like built-in (! "notepad.exe") but not creating an additional console window.
#15
Is it possible to run an external program (ex. notepad.exe) from newlisp on Win32, not opening a console window, and wait for it to finish? Both (! "notepad.exe") and (exec "notepad.exe") run cmd.exe first and therefore create a console window. On the other hand, (process "notepad.exe") runs notepad.exe directly, and doesn't wait for notepad to finish. And there is no wait-pid in Win32. Can I have both, please?