newLISP Development Release v.10.6.3

[kosh]

Lutz, Thanks for applying my patch.



I found some other compile problems.



1. configure-alt: still `os_type` is set to WIN_32/64

Code Select Expand

diff --git a/configure-alt b/configure-alt
index 1994097..d1bfb73 100755
--- a/configure-alt
+++ b/configure-alt
@@ -70,8 +70,8 @@ case `uname` in
  SunOS) true ${os_type:=SUNOS} ;;
  AIX) true ${os_type:=AIX} ;;
  OSF1) true ${os_type:=TRU64} ;;
- MINGW32_*) true ${os_type:=WIN_32} ;;
- MINGW64_*) true ${os_type:=WIN_64} ;;
+ MINGW*) true ${os_type:=WINDOWS} ;;
  OS/2) true ${os_type:=OS2} ;;
  *)
  echo Could not discover your OS platform use one of the following commands:
@@ -100,7 +100,7 @@ elif [ ${os_type} = TRU64 ] ; then
  DEFAULT_CC="${TRU64_CC}"
  DEFAULT_CFLAGS="${TRU64_CFLAGS}"
  DEFAULT_LDFLAGS="${TRU64_LDFLAGS}"
-elif [ ${os_type} = WIN_32 ] ; then
+elif [ ${os_type} = WINDOWS ] ; then
  DEFAULT_CC="${WIN32_CC}"
  DEFAULT_CFLAGS="${WIN32_CFLAGS}"
  DEFAULT_LDFLAGS="${WIN32_LDFLAGS}"


2. newlisp.h: _WIN32_WINNT could not set correctly

Code Select Expand

$make -f makefile_mingw_ffi
...
gcc -m32 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 win-util.o wi
n-path.o -lws2_32 -lffi -o newlisp.exe
nl-sock.o: In function `getHostAddr':
c:devnewlisp/nl-sock.c:677: undefined reference to `getaddrinfo'
c:devnewlisp/nl-sock.c:682: undefined reference to `freeaddrinfo'
...
make: *** [default] Error 1


It happends in mingw32 only, not mingw64.



Perhaps _WIN32_WINNT was already defined (maybe 0x0500) in "win-ffi.h" in newlisp.h:114.

As a result, _WIN32_WINNT could not set in newlisp.h:170.

[Lutz]

Thanks for the configure-alt fix. It works now, but on a Windows 7 64-bit systems it also compiles a 32-bit newlisp.exe and without libffi using the TDM GCC 64 toolset.



I am not too concerned about this, as we have working Windows 32/64-bit compilations using the normal configure script and the TDM GCC 64 toolset. It can use the mingw64 to compile 32-bit newlisp.exe with libffi without any error messages. using make winall or make winall64, the executables for the Windows installers are done together with DLLs.



The configure-alt file is getting old and I wonder if it still should be included in the final 10.6.4 release? Perhaps Ted W. has some time to update the Windows portion, or we simply take the Windows portion out and use it only for Unix. It would also be nice to have a working libffi detection on many Unix platforms.

[johu]

Hello, Lutz.



For Stable Release,



line 2965 in newlisp_manual v10.6.3

to itself, elready existing contexts like MAIN do not require quoting.</p>

　　　　　↓

to itself, already existing contexts like MAIN do not require quoting.</p>

line 3029

<tt>ACTX</tt>, ot the whole funtion must be preceded by a context

　　　　　　　↓

<tt>ACTX</tt>, or the whole funtion must be preceded by a context

line 25350

<p>10.1.0 size of share objects can exceed the shared memory pagesize

　　　↓

<p>Since v.10.1.0 size of share objects can exceed the shared memory pagesize

line 25353

operating system. On MS Windows systems the environment vatiable <tt>TEMP</tt>

　　　　　　　　　　　　　　　　　　　　　　　　　　　　↓

operating system. On MS Windows systems the environment variable <tt>TEMP</tt>

line 27178

<h4>syntax: (trace true)


　　　　　　　　　　↓

<h4>syntax: (trace int-device)

line 27179

syntax: (trace int-device)


　　　　　　　　　　↓

syntax: (trace true)

line 27199

<p>In the second syntax debugger mode is switched on when when the

　　　　　　　　　　　　　　　　　　　　　　　　　　　　↓

<p>In the second syntax debugger mode is switched on when the

Regards,

[Lutz]

Many thanks, Johu. Updates are here:



http://www.newlisp.org/downloads/development/inprogress/">http://www.newlisp.org/downloads/develo ... nprogress/">http://www.newlisp.org/downloads/development/inprogress/

[TedWalther]

Thanks for the configure-alt fix. It works now, but on a Windows 7 64-bit systems it also compiles a 32-bit newlisp.exe and without libffi using the TDM GCC 64 toolset.



I am not too concerned about this, as we have working Windows 32/64-bit compilations using the normal configure script and the TDM GCC 64 toolset. It can use the mingw64 to compile 32-bit newlisp.exe with libffi without any error messages. using make winall or make winall64, the executables for the Windows installers are done together with DLLs.



The configure-alt file is getting old and I wonder if it still should be included in the final 10.6.4 release? Perhaps Ted W. has some time to update the Windows portion, or we simply take the Windows portion out and use it only for Unix. It would also be nice to have a working libffi detection on many Unix platforms.

It has been a few years, configure-alt served the purpose of getting newlisp included as a standard package on the BSD platform.  It also made it GNU compliant so it was easier to do automated testing and installs.



I really don't like having a configure-alt separate from the configure.  I'd like to bring configure-alt to feature parity with configure, and have it replace configure.  If this is acceptable, I will work on it for the 10.6.4 release.  I already have some patches to configure-alt for OpenBSD and Darwin.  I was waiting to upgrade my OpenBSD development box; now they support a new enough version of libffi that newlisp should compile and be fully featured.



I propose that once configure-alt is at feature parity with configure, then all the various makefiles get moved to a directory makefiles/



I now have also a Darwin build environment, and access to a Windows build environment.  So many things are possible that I couldn't do back when I first made configure-alt.



As more of us are becoming familiar with the codebase, Lutz, I'm wondering if you'd be ok looking into using git a bit more.  Git lets you "tag" a release; in between, this is the workflow I've had the best success with:



for a new feature or bug fix, make a branch.  Implement it.  Test it.  git merge --squash.  I think this will be helpful in bringing others up to speed on how things are done internally in newlisp, by seeing real world "how things get done in newlisp".



kosh uses git.  I use git.  Ralph, are you comfortable with git?  I know mercurial is probably the better software, but git has the strength of numbers.



One makefile patch:

Code Select Expand


diff --git a/makefile_darwinLP64_utf8_lib b/makefile_darwinLP64_utf8_lib
index b11585a..0899a60 100644
--- a/makefile_darwinLP64_utf8_lib
+++ b/makefile_darwinLP64_utf8_lib
@@ -6,16 +6,16 @@
 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 unix-lib.o
 
-CFLAGS = -m64 -Wall -O1 -c -DREADLINE -DMAC_OSX -DSUPPORT_UTF8 -DLIBRARY
+CFLAGS = -m64 -Wall -O1 -c -DREADLINE -DMAC_OSX -DNEWLISP64 -DSUPPORT_UTF8 -DFFI -DLIBRARY
 
 CC = gcc
 
 default: $(OBJS)
-       $(CC) $(OBJS) -m64 -lm -lreadline -bundle -o newlisp.dylib
+       $(CC) $(OBJS) -m64 -lm -lreadline -lffi -bundle -o newlisp.dylib
 
 .c.o:
        $(CC) $(CFLAGS) $<
 
-$(OBJS): primes.h protos.h makefile_darwinLP64_utf8_lib
+$(OBJS): newlisp.h primes.h protos.h makefile_darwinLP64_utf8_lib
 

And the patch to configure-alt:

Code Select Expand


diff --git a/configure-alt b/configure-alt
index 1e182c8..51d54b0 100755
--- a/configure-alt
+++ b/configure-alt
@@ -208,14 +208,17 @@ rm -f test-readline*
 
 # If we can't compile with ffi, and the environment variables don't
 # specify otherwise, we will disable it.
-cat > test-ffi.c <<EOF
+for cclibffi in "-lffi"; do
+       for h in "ffi.h" "ffi/ffi.h"; do
+               FFI_H=${h}
+               cat > test-ffi.c <<EOF
 /* test-ffi.c Fri Jul 10 14:57:33 PDT 2009 Ted Walther <ted@reactor-core.org>
  *
  * code for testing the compiler options to use for libffi
  */
 
 #include <stdio.h>
-#include <ffi.h>
+#include <${FFI_H}>
 
 int main(int argc, char** argv) {
        ffi_cif cif;
@@ -237,13 +240,13 @@ int main(int argc, char** argv) {
        return 0;
 }
 EOF
-for cclibffi in "-lffi"; do
-       if ${CC:-${DEFAULT_CC}} test-ffi.c ${DEFAULT_LDFLAGS} ${cclibffi} -o test-ffi 2>/dev/null ; then
-               true ${enable_ffi:=yes};
-               DEFAULT_FFIFLAGS="${cclibffi}";
-               echo "Detected ffi flags: ${cclibffi}";
-               break;
-       fi
+               if ${CC:-${DEFAULT_CC}} test-ffi.c ${DEFAULT_LDFLAGS} ${cclibffi} -o test-ffi 2>/dev/null ; then
+                       true ${enable_ffi:=yes};
+                       DEFAULT_FFIFLAGS="${cclibffi}";
+                       echo "Detected ffi flags: ${cclibffi}";
+                       break;
+               fi
+       done
 done
 true ${enable_ffi:=no};
 rm -f test-ffi*
@@ -405,6 +408,7 @@ if [ $enable_ffi = yes ] ; then
        cat >> config.h <<EOF
 /* FFI support was chosen */
 #define FFI
+#include <${FFI_H}>
 
 EOF
        echo "ffi support is enabled"


This patch accounts for the fact that on some platforms, <ffi.h> should be <ffi/ffi.h>.  Right now I only know about this affecting Darwin, but I can see it potentially affecting other BSD variants.

[rrq]

I'd be happy to learn (more) about git, and fwiw in full support for this.



And I can set you up with a remote armv7 build environment if you like.

Currently with Ubuntu 12.04 but that can be flexible.



Then there's also the Android variant(s) to hopefully be included as mainstream.

[Lutz]

No problem with using Git for configure-alt development. I can take new versions of configure-alt from there and can help testing on OSX, Windows 7, Ubuntu Linux and FreeBSD.



On the main newLISP code base I prefer development the way it has been done. Of course there is no problem do have a Git repository for all newLISP stable and development releases. There is one, Kosh maintains here: https://github.com/kosh04">https://github.com/kosh04 it could be useful to see the history of code portions when fixing bugs.

[TedWalther]

Lutz, I was requesting that you push your changes up to kosh04 git repository similar to how you do for the inprogress branch; this way we don't just see changes between releases, but get a better sense of what changes go into a particular feature or bugfix.  Then we get the benefit of the issue tracker on github also.

[TedWalther]

Lutz, another reason for suggesting git for main body of newlisp development is this: to make it easier for more people to contribute, and to make it easier for you to manage a greater number of contributors.  I've been wondering why languages like ruby on rails, or clojure, are more widely used than newlisp.  Greater mass of contributors and use cases means more resources all around for everyone.

[Lutz]

As everybody knows, I keep a tight control about what new features enter the newLISP language. If people need  more use-cases, they should write modules and import libraries when necessary. For the main newLISP executable itself, I don't want more contributors.



Having worked with most of the software version control systems like RCS, CVS, SVN besides Git and in developer teams since the late eighties in small and big companies, I am well aware what these systems can do and cannot do. For my style as mostly the sole developer they are not useful. Pushing every change to a repository is just one more thing to do, I don't need and want.



Again, if anybody wants to capture change over versions in a public Git depository that is fine, but I will not change my style of development.



For more use cases write modules, import libraries! Publish them on the Git repository, documented! and I can put them in the index at http://www.newlisp.org/modules/">http://www.newlisp.org/modules/

[rrq]

Whilst I bow to your experience in these matters, TedWalter, upon reflection I support Lutz in maintaining a practical barrier for code change. Obviously it can be done in different ways, but the way it's done certainly makes newlisp stable in respect of platform features and it's practical utility as scripting language. And I don't think this barrier plays much of a role for the uptake (or not) of newlisp, although admittedly this isn't something I've been thinking about.



Yes, the contributions it needs are more in the way of frameworks and infrastructural components supporting particular usage domains, than changes to the platform code. Maybe we should focus on the structuring, organisation and publishing of our various snippets of newlisp code, to make it easier for the casual visitor/user to pick up the required titbits for her collage.



The platform documentation is awesome, but when you want a snippet for doing your thing,  you have to seek around among modules, tips and wherever, and basically know the solution you're looking for before you can find it. Perhaps that's the egg here; a large enough user community will make enough web noise to let me find my solution by voicing my problem.

[xytroxon]

After spending a couple of hours in a time warp after an unexpected date-value function crash in a weekly archive program I run.



((( Yes, I NOW know about: http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=16&t=4725">//http://www.newlispfanclub.alh.net/forum/viewtopic.php?f=16&t=4725



(PLEASE, post about devlopment release errors in the development release thread!!!) )))



I noticed a peculiarity in the date function example in the newLISP manual:



(date 0 (now 0 -2)) -> "Thu Jan  1 00:00:00 1970"  ; Unix epoch



Which when executed on Win 7 returns -> nil



In my time zone: (now 0 -2) ->  -420



Inverting the sign to +420 gives the expected* result:



(date 0 (* (now 0 -2) -1)) -> "Thu Jan 01 00:00:00 1970"



Is this a newLISP coding error, or a devious "design feature" from the ancient UNIX/C system gods - IE C system time functions returning and needing the time zone expressed with different sign values?



-- Dr Who... er.  xytroxon



* My expected result would be:



(date 0) -> "Thu Jan 01 00:00:00 1970"

(date 0 -420) -> "Wed Dec 31 17:00:00 1969"



But then, I am not a UNIX/C system god ;o)

[Lutz]

date without offset parameter displays local time and also adjusted for daylight savings time (e.g. in California). now displays UTC (universal time) and the number of minutes your are behind (minus for west of Greenwich) or ahead (plus for east of Greenwich) of UTC.



Also, Windows cannot handle negative values before Unix epoch and returns nil and not all OS deliver a valid indication for the daylight savings time or encode it in different ways.



Ps: there is a problem with the UTC offset in now on 10.6.3 on Windows 64-bit compiles corrected in the latest 10.6.4. The UTC offset in Windows also not includes the daylight saving offset, but may in final 10.6.4, to make at least the UTC offset portable between Windows and Unix.

[kosh]

Thanks for the configure-alt fix. It works now, but on a Windows 7 64-bit systems it also compiles a 32-bit newlisp.exe and without libffi using the TDM GCC 64 toolset.



I am not too concerned about this, as we have working Windows 32/64-bit compilations using the normal configure script and the TDM GCC 64 toolset. It can use the mingw64 to compile 32-bit newlisp.exe with libffi without any error messages. using make winall or make winall64, the executables for the Windows installers are done together with DLLs.

It means that newLISP drop support on previous MinGW32 toolset, and migrate to TDM-GCC 32/64 toolset?

[Lutz]

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. The only thing I add are two libffi.a files for 32 and 64 bit to the appropiate library directories and MSYS for make and other Unix tools.