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 - kosh

Pages 1 2 3 4 5
#16
newLISP and the O.S. / Re: mingw64 build patch
April 12, 2015, 06:02:49 AM
I also confirmed this IO problem.


Code Select
$ newlisp64.exe -n
> (setf str (string (dup {X} 2049) {HELLO}))
[text]XXXX...<repeat 2049 times>HELLO[/text]
> (println str)
XXXX...<repeat 2049 times>


It seems that cause internal output function `my_vasprintf` (in nl-filesys.c, called from varPrintf)



`vasprintf` has been implemented in mingw64 in stdio.h (but mingw32 yet).

then, It could be fixed in this way:


Code Select
/* newlisp.h */
#ifdef WINDOWS
#ifndef __MINGW64__ /* macros depends on mingw implementation */
# define MY_VASPRINTF
# define vasprintf my_vasprintf
#endif
...
#endif


Regards.
#17
newLISP and the O.S. / Re: mingw64 build patch
April 02, 2015, 08:10:36 AM
> but only for IPv4. Perhaps IPv6 is not supported in the tdm version of mingw gcc? Hve not looked into it yet.



Maybe, It because you use variable `defaultIn` without zero-initialization.



https://github.com/kosh04/newlisp/compare/feature/mingw-w64#diff-ab3071b4db4911dec3a809c84f1a5cbfL159">https://github.com/kosh04/newlisp/compa ... 1a5cbfL159">https://github.com/kosh04/newlisp/compare/feature/mingw-w64#diff-ab3071b4db4911dec3a809c84f1a5cbfL159



initDefaultInAddr() in nl-sock.c
Code Select
-defaultIn = allocMemory(defaultInLen);
+defaultIn = callocMemory(defaultInLen);
#18
newLISP and the O.S. / Re: mingw64 build patch
March 19, 2015, 01:31:43 PM
Lutz, you have completed the setup of new Windows machine?



As an aside, http://tdm-gcc.tdragon.net/">http://tdm-gcc.tdragon.net/ provide "TDM32 Packages". so it works on 32-bit Windows XP.

Of course, a generated newlisp.exe runs on 64-bit Windows.
#19
newLISP and the O.S. / Re: screenshot in Win7
February 19, 2015, 05:18:54 AM
Try translate to newLISP:


Code Select
(import "user32" "GetDC")       ; HDC GetDC(HWND hWnd);
(import "user32" "ReleaseDC")   ; int ReleaseDC(HWND hWnd, HDC hDC);
(import "gdi32" "GetPixel")     ; COLORREF GetPixel(HDC hdc, int nXPos, int nYPos);

(define (get-pixel point)
  (letn ((h (GetDC 0))
         (color (GetPixel h (first point) (last point))))
    (ReleaseDC h)
    color))

(print (map get-pixel '((1 10)
                        (20 3)
                        (640 480)
                        (0 0))))
;;-> (0 4144700 14548991 0)
#20
newLISP and the O.S. / Re: mingw64 build patch
February 18, 2015, 12:43:04 PM
makefile_mingwLLP64_utf8 is here:


Code Select
# makefile for newLISP v. 10.x.x on MinGW-w64 with UTF-8 support

OBJS = newlisp.o nl-symbol.o nl-math.o nl-list.o nl-liststr.o nl-string.o nl-filesys.o nl-sock.o
nl-import.o nl-xml-json.o nl-web.o nl-matrix.o nl-debug.o pcre.o nl-utf8.o win-util.o win-path.o

CFLAGS = -Wall -Wno-uninitialized -Wno-long-long -O1 -g
CPPFLAGS = -DWIN_64 -DSUPPORT_UTF8
#CPPFLAGS = -DWIN_32 -NEWLISP64 -DSUPPORT_UTF8
LDLIBS = -lws2_32

CC = gcc
STRIP = strip

default: newlisp.exe

newlisp.exe: $(OBJS)
$(CC) $(LDFLAGS) $^ $(LDLIBS) -o $@
$(STRIP) $@

newlisp.dll: LDFLAGS += -static-libgcc -Wl,--enable-stdcall-fixup
newlisp.dll: $(OBJS) win-dll.o win-dll.def
$(CC) -shared $(LDFLAGS) $^ $(LDLIBS) -o $@

$(OBJS): primes.h protos.h newlisp.h makefile_mingwLLP64_utf8


This makefile can also make DLL file:
Code Select
make -f makefile_mingwLLP64_utf8 newlisp.dll

---

Unfortunatly, new newlisp-10.6.3.tgz compile with errors:
Code Select
gcc -Wall -Wno-uninitialized -Wno-long-long -O1 -g -DWIN_64 -DSUPPORT_UTF8  -c -o nl-sock.o nl-sock.c
In file included from nl-sock.c:29:0:

C:/MinGW64/x86_64-w64-mingw32/include/ws2tcpip.h:160:1: error: size of unnamed array is negative

 C_ASSERT(sizeof(IN_PKTINFO)==8);

 ^

C:/MinGW64/x86_64-w64-mingw32/include/ws2tcpip.h:167:1: error: size of unnamed array is negative

 C_ASSERT(sizeof(IN6_PKTINFO)==20);

 ^

make: *** [nl-sock.o] Error 1


in nl-sock.c: `#define UINTP uintptr_t` is not ineffective. I recommend to use push_macro/pop_macro, or include newlisp.h after ws2tcpip.h if you don't rename the type name UINT.



---

I hope the value ostype be always "Win32".

This value should not be distinguished by 32/64 bit as well as in other platform. To determine the 64-bit platform can use sys-info.
#21
newLISP and the O.S. / Re: mingw64 build patch
February 16, 2015, 11:48:44 AM
Thanks Lutz for merge patch.



I found a missing code in newlisp.h (newlisp-10.6.3.tgz)


Code Select
#undef NEWLISP64
#if defined(_LP64) || defined(_WIN64)
#define NEWLISP64
#endif


and qa-specific-tests/qa-local-domain (for `make testall`)
Code Select
diff --git a/qa-specific-tests/qa-local-domain b/qa-specific-tests/qa-local-domain
index caa5901..49b41f7 100755
--- a/qa-specific-tests/qa-local-domain
+++ b/qa-specific-tests/qa-local-domain
@@ -6,6 +6,10 @@
 (println)
 (println "Testing UNIX local domain sockets")
 
+(when (find ostype '("Win32" "OS/2"))
+  (println "not tested on " ostype)
+  (exit))
+
 (define (listener path)
  (set 'lsock (net-listen path))
  (set 'csock (net-accept lsock))


NEWLISP64 is defined in files makefile_* in this time.

It will more better way to use predefined compiler macros.


Code Select
# check predefined macros
$ echo | gcc -m32 -dM -E - | grep WIN64

$ echo | gcc -m64 -dM -E - | grep WIN64
#define _WIN64 1
#define __WIN64 1
#define WIN64 1
#define __WIN64__ 1


Quote from: "Lutz"I wonder what the speed comparison is between the 32-bit and 64-bit versions of newLISP on Windows.


FYI, my AppVeryor's build log info is the following (mingw cross-compile on cygwin):

https://ci.appveyor.com/project/kosh04/newlisp/build/1.0.62">https://ci.appveyor.com/project/kosh04/ ... ild/1.0.62">https://ci.appveyor.com/project/kosh04/newlisp/build/1.0.62


QuoteFree plans run builds on VM instances with 1 virtual core, 1.75 GB of memory and 127 GB of disk space (Windows Azure "Small").

http://www.appveyor.com/docs/build-configuration">http://www.appveyor.com/docs/build-configuration

Code Select
# 32-bit
>>>>> total time: 14779.53999999999
>>>>> Performance ratio: 5.70 (1.0 on MacOSX 10.9, 2.3GHz Intel Core i5, newLISP v10.6.0-64-bit)

# 64-bit
>>>>> total time: 12015.73600000001
>>>>> Performance ratio: 4.64 (1.0 on MacOSX 10.9, 2.3GHz Intel Core i5, newLISP v10.6.0-64-bit)


My build environment info will be posted at a later.



Regards.
#22
newLISP and the O.S. / Re: mingw64 build patch
February 14, 2015, 11:32:20 AM
Patch files are here:

https://gist.github.com/kosh04/6a9ff701d5d6358d3ad9">https://gist.github.com/kosh04/6a9ff701d5d6358d3ad9

https://rawgit.com/kosh04/6a9ff701d5d6358d3ad9/raw/">https://rawgit.com/kosh04/6a9ff701d5d6358d3ad9/raw/



It based newlisp v.10.6.2
#23
newLISP and the O.S. / mingw64 build patch
February 14, 2015, 11:16:01 AM
Hi Lutz.



I wrote patch file for builds with MinGW-w64 gcc.

Changes are following:



- Define UINT as pointer size integer (stdint.h, uintptr_t)

- Use type conversion macros for printf (inttypes.h, PRIdPTR)

- Auto detect 64-bit memory model (LP64/LLP64) using C pre-defined macros

- nl-sock.c: bugfix non initialized var DefaultIn



Patch files can be viewed on GitHub:

https://github.com/kosh04/newlisp/compare/feature/mingw-w64">https://github.com/kosh04/newlisp/compa ... /mingw-w64">https://github.com/kosh04/newlisp/compare/feature/mingw-w64



(p.s. BBS attachment fails with message The extension diff is not allowed.)



Build and Test (`make testall`) passed under the following platform:



- Win7 Home amd64

-- TDM-GCC (mingw-w64 gcc 4.9.1)

-- MinGW gcc 4.8.1

-- cygwin32 gcc 4.9.2

-- cygwin64 gcc 4.9.2

- Mac OSX clang



However, this patch have some problems:



- stdint.h, inttypes.h headers available in ISO C99. but newLISP C source seem to C90.

- win32-path.c: an incomplete compatibility between `struct stat` and `struct _stat`.

- nl-sock.c: UINT type is name conflict in ws2tcpip.h.

  This patch provides the temporary workaround using push_macro/pop_macro.

  If you don't like this way, better to rename the UINT to another name (e.g. `typedef uintptr_t nl_int;`)



All reviews are welcome. Thanks.
#24
newLISP newS / Re: Alternative git repository
December 24, 2014, 11:01:34 PM
This repository has moved to github.

- https://github.com/kosh04/newlisp">https://github.com/kosh04/newlisp



and It has introduced continuous integration.

- https://travis-ci.org/kosh04/newlisp">https://travis-ci.org/kosh04/newlisp
#25
So, what can you actually DO with newLISP? / Re: complex arithmetics
September 18, 2014, 06:23:27 AM
There is a point to problem.


Code Select
> (constant '*2pi* (mul 3.14159265358979323846264338327950288419716939937510 2))
3.159714599e+020
> (read-expr "(mul 3.14159265358979323846264338327950288419716939937510 2)")
(mul 3.141592653589793115997963468544185161590576171875 50288419716939937510L 2)


newlisp parser reads too long a numeric value (or symbol) without no warning.

Therefore, it is better to avoid such writing.



I recommend PI defined as:
Code Select
(constant 'pi (mul 4 (atan 1)))  ; or short written 3.141592654

P.S. I tried writing a mandelbrot set. like this http://www.newlisp.org/complex.cgi">//http://www.newlisp.org/complex.cgi
Code Select
#!/usr/bin/env newlisp

(load "complex_lib.lsp")
 
(for (y -1 1.1 0.08)
  (for (x -2 1 0.04)
    (letn ((c 126)
           (z (cmplx x y))
           (a z))
      (while (and (begin
                    (setq z (cadd (cmul z z) a))
                    (< (abs (cmod z)) 2))
                  (< 32 (dec c))))
      (print (char c))))
  (println))
 
(exit)
#26
newLISP and the O.S. / Re: mingw patch
August 29, 2014, 01:40:24 AM
Quote from: "Lutz"This: http://www.newlisp.org/downloads/development/inprogress/">http://www.newlisp.org/downloads/develo ... nprogress/">http://www.newlisp.org/downloads/development/inprogress/



now should work independent of compilers and without compiler warning messages when time_t is 64-bit on 32-bit newLISP


It looks good to me :) thanks again.


Quote from: "Lutz"What version of MINGW are you running?


I used MinGW gcc 4.8.1 (latest version). MinGW-w64 installed, but not used this issue.
#27
newLISP and the O.S. / Re: mingw patch
August 27, 2014, 12:40:39 PM
Lutz, thank you for the merge my patch.

However please modified a little.


Code Select
$ wget http://www.newlisp.org/downloads/development/inprogress/newlisp-10.6.1.tgz
$ tar xf newlisp-10.6.1.tgz
$ cd newlisp-10.6.1
$ make -f makefile_mingw_utf8 CC=gcc STRIP=touch
...
$ newlisp
newLISP v.10.6.1 32-bit on Win32 IPv4/6 UTF-8, options: newlisp -h

> (date-value 1970 1 1)
210453397504   ; NG. should == 0
> (date-list (date-value 1970 1 1))
core dump.


variable 'dateValue' in calcDateValue must run bitwise operation part if on windows (line 2819-2824).

patch file here:


Code Select
diff --git a/nl-filesys.c b/nl-filesys.c
index 34d75ae..82c8327 100644
--- a/nl-filesys.c
+++ b/nl-filesys.c
@@ -2816,7 +2816,7 @@ dateValue = 367 * year - (7 * (year + ((month + 9) / 12)))/4
 dateValue = dateValue * 24 * 3600 + hour * 3600 + min * 60 + sec
             - 413319296; /* correction for 1970-1-1 */

-#ifdef NEWLISP64
+#if defined(NEWLISP64) || defined(WINDOWS)
 if(dateValue & 0x80000000)
     dateValue = dateValue | 0xFFFFFFFF00000000;
 else
#28
newLISP and the O.S. / mingw patch
August 24, 2014, 09:45:44 AM
Hi Lutz.



This patch is solves about 2 problems on MinGW compile.



1. _WIN32_WINNT macros must define before windows.h and other headers



Because of most of mingw headers (stdio.h, signal.h, ...) include _mingw.h and sdkddkver.h.

And define _WIN32_WINNT there if not defined.


Code Select
diff --git a/newlisp.h b/newlisp.h
index d7537fd..23ce42a 100644
--- a/newlisp.h
+++ b/newlisp.h
@@ -159,6 +159,16 @@ This is for 64bit large file support (LFS),
 #define _FILE_OFFSET_BITS 64
 #endif
 
+#ifdef WINDOWS
+/* NOTE:
+ * Windows XP [0x0501] end of support on 2014/04/08
+ * WIndows Vista [0x0600] support ends on 2017/04/11
+ */
+#ifndef _WIN32_WINNT
+#define _WIN32_WINNT 0x0600
+#endif
+#endif
+
 #include <signal.h>
 #include <errno.h>
 #include <stdio.h>
@@ -188,9 +198,6 @@ This is for 64bit large file support (LFS),
 #endif
 
 #ifdef WINDOWS
-#ifndef _WIN32_WINNT
-#define _WIN32_WINNT 0x0501
-#endif
 #include <windef.h>
 #include <winbase.h>
 #else


2. time_t and struct timeval bit size



Windows time_t is now a 64-bit integer by default.

Therefore sizeof(UINT) and sizeof(time_t) are not equal on 32-bit windows.

http://msdn.microsoft.com/en-us/library/1f4c8f33.aspx">//http://msdn.microsoft.com/en-us/library/1f4c8f33.aspx



And struct timeval tv.tv_sec is different type long (windows) and time_t (linux).


Code Select
diff --git a/nl-filesys.c b/nl-filesys.c
index 99a6c84..5655132 100644
--- a/nl-filesys.c
+++ b/nl-filesys.c
@@ -2454,7 +2454,7 @@ struct tm * ltm;
 char * ct;
 char * fmt;
 ssize_t offset;
-time_t tme;
+UINT tme;
 size_t size;
 
 #ifdef SUPPORT_UTF8
@@ -2474,8 +2474,8 @@ if(params == nilCell)
     }
 else
     {
-    params = getInteger(params, (UINT *)&tme);
-    t = tme;
+    params = getInteger(params, &tme);
+    t = (time_t)tme;
     
     if(params != nilCell)
         {
@@ -2524,10 +2524,12 @@ INT64 microSecTime(void)
 {
 struct timeval tv;
 struct tm * ttm;
+time_t sec;
 
 gettimeofday(&tv, NULL);
 
-ttm = localtime((time_t *)&tv.tv_sec);
+sec = tv.tv_sec;
+ttm = localtime(&sec);
 
 return (ttm->tm_hour * 3600000000LL +
        ttm->tm_min * 60000000LL + ttm->tm_sec * 1000000 +
@@ -2650,6 +2652,7 @@ UINT isdst;
 TIME_ZONE_INFORMATION timeZone;
 #endif
 ssize_t offset = 0;
+time_t sec;
 CELL * cell;
 
 gettimeofday(&tv, NULL); /* get secs and microsecs */
@@ -2681,7 +2684,8 @@ gmtoff = ltm->tm_gmtoff/60;
 GetTimeZoneInformation(&timeZone);
 #endif
 
-ttm = gmtime((time_t *)&tv.tv_sec);
+sec = tv.tv_sec;
+ttm = gmtime(&sec);
 
 cell = stuffIntegerList(
     11,
@@ -2731,10 +2735,12 @@ CELL * p_dateList(CELL * params)
 {
 struct tm *ttm;
 ssize_t timeValue;
+time_t timer;
 CELL * cell;
 
 params = getInteger(params, (UINT*)&timeValue);
-ttm = gmtime((time_t *)&timeValue);
+timer = (time_t)timeValue;
+ttm = gmtime(&timer);
 
 cell = stuffIntegerList(
     8,
@@ -2804,12 +2810,11 @@ dateValue = 367 * year - (7 * (year + ((month + 9) / 12)))/4
 dateValue = dateValue * 24 * 3600 + hour * 3600 + min * 60 + sec
             - 413319296; /* correction for 1970-1-1 */
 
-#ifdef NEWLISP64
 if(dateValue & 0x80000000)
     dateValue = dateValue | 0xFFFFFFFF00000000;
 else
-    dateValue = dateValue & 0xffffffff;
-#endif
+    dateValue = dateValue & 0x00000000ffffffff;
 
 return(dateValue);
 }

Regards.
#29
newLISP and the O.S. / crc32 bug on newlisp 32-bit
July 19, 2014, 11:17:33 PM
crc32 function may return wrong value on 32-bit machine.


Code Select
> (crc32 "hello")
907060870        ; OK
> (crc32 "HELLO")
-1052482506      ; NG [0xffffffffc1446436]
> (& (crc32 "HELLO") 0x00000000ffffffff)
3242484790       ; OK [0x00000000c144643]


This problem occurs because of difference between internal value and CELL value.



- upadte_crc function (in nl-math.c) returns unsigned 32-bit integer.

- But newlisp's printCell function treats as signed integer.



This solves the crc32 values are always treated as an 64-bit integer.


Code Select
--- nl-math.c~ 2014-06-04 11:44:59 +0900
+++ nl-math.c 2014-06-20 22:31:07 +0900
@@ -2354,9 +2354,12 @@
 {
 char * data;
 size_t len;
+unsigned int crc;
 
 params = getStringSize(params, &data, &len, TRUE);
-return(stuffInteger(update_crc(0xffffffffL, (unsigned char *)data, (int)len) ^ 0xffffffffL));
+crc = update_crc(0xffffffffL, (unsigned char *)data, (int)len) ^ 0xffffffffL;
+return(stuffInteger64(crc));
 }
#30
newLISP and the O.S. / [patch] require dlerror before dlsym
December 16, 2013, 11:11:57 AM
Hi Lutz.



I found unusual behavior when 'import' called from url.


Code Select
newLISP v.10.5.4 32-bit on BSD IPv4/6 UTF-8 libffi, options: newlisp -h

> (setq url "http://lambda.que.jp/files/x.lsp")
> (get-url url)
"(import "libc.so" "printf")n"
> (load url)

ERR: import function not found in function import : "Undefined symbol "_nss_cac
he_cycle_prevention_function""


Perhaps, you should call the dlerror() to clear error code before dlsym().



http://tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html">http://tldp.org/HOWTO/Program-Library-H ... aries.html">http://tldp.org/HOWTO/Program-Library-HOWTO/dl-libraries.html


Quote4.3. dlsym()

...

The standard solution is to call dlerror() first (to clear any error condition that may have existed), then call dlsym() to request a symbol, then call dlerror() again to see if an error occurred. A code snippet would look like this:


Code Select
dlerror(); /* clear error code */
 s = (actual_type) dlsym(handle, symbol_being_searched_for);
 if ((err = dlerror()) != NULL) {
  /* handle error, the symbol wasn't found */
 } else {
  /* symbol found, its value is in s */
 }


Patch file here:


Code Select
diff --git a/nl-import.c b/nl-import.c
index a14264f..40a1320 100644
--- a/nl-import.c
+++ b/nl-import.c
@@ -172,6 +172,8 @@ pCell = getCell(type);
 deleteList((CELL *)symbol->contents);
 symbol->contents = (UINT)pCell;

+dlerror();
+
 pCell->contents = (UINT)dlsym(hLibrary, funcName);

 if((error = (char *)dlerror()) != NULL)
Pages 1 2 3 4 5