newLISP Development Release v.10.6.3
newLISP Development Release v.10.6.3
This development release adds new functionality to existing functions and fixes bugs.
Files and release notes: http://www.newlisp.org/downloads
Thanks to everybody participating in this release. Special thanks to Kosh, who did most of the work for the Windows 64-bit release.
Files and release notes: http://www.newlisp.org/downloads
Thanks to everybody participating in this release. Special thanks to Kosh, who did most of the work for the Windows 64-bit release.
Re: newLISP Development Release v.10.6.3
Hello,
Thanks Lutz for the ongoing development.
Unfourtunatly my Norton Internet Security delete the windows installers because it reports WS.Reputation.1
But Virustotal scans without problem:
https://www.virustotal.com/de/file/590f ... 436374630/
https://www.virustotal.com/de/file/2c9b ... 436374825/
I will report a false positiv.
Regards
Thanks Lutz for the ongoing development.
Unfourtunatly my Norton Internet Security delete the windows installers because it reports WS.Reputation.1
But Virustotal scans without problem:
https://www.virustotal.com/de/file/590f ... 436374630/
https://www.virustotal.com/de/file/2c9b ... 436374825/
I will report a false positiv.
Regards
Hans-Peter
Re: newLISP Development Release v.10.6.3
Hello,
In my regular testing against my neobook demo app, I get a error with commands which get imported into the newlsip.dll (32 bit). They now throw a access violation in my (Turtle3:run).
Until 10.602 all run without problems.
I noticed a different DLL-size from 10602 to 10603:
301.568 Bytes
286.734 Bytes
Any changes how Dll-callbacks were done?
The following command throws the violation:
(hpwImageTextOut "RImage1" "Dragon Fractal" "380" "70" "Times" "12" "clWhite" "clNavy")
> hpwImageTextOut
(lambda (nbpara1 nbpara2 nbpara3 nbpara4 nbpara5 nbpara6 nbpara7 nbpara8) (hpwImageExec
"" "9" nbpara1 nbpara2 nbpara3 nbpara4 nbpara5 nbpara6 nbpara7 nbpara8))
> hpwImageExec
hpwImageExec@2D814CC
hpwImageExec is the imported command from the neobook dll.
Regards
In my regular testing against my neobook demo app, I get a error with commands which get imported into the newlsip.dll (32 bit). They now throw a access violation in my (Turtle3:run).
Until 10.602 all run without problems.
I noticed a different DLL-size from 10602 to 10603:
301.568 Bytes
286.734 Bytes
Any changes how Dll-callbacks were done?
The following command throws the violation:
(hpwImageTextOut "RImage1" "Dragon Fractal" "380" "70" "Times" "12" "clWhite" "clNavy")
> hpwImageTextOut
(lambda (nbpara1 nbpara2 nbpara3 nbpara4 nbpara5 nbpara6 nbpara7 nbpara8) (hpwImageExec
"" "9" nbpara1 nbpara2 nbpara3 nbpara4 nbpara5 nbpara6 nbpara7 nbpara8))
> hpwImageExec
hpwImageExec@2D814CC
hpwImageExec is the imported command from the neobook dll.
Regards
Hans-Peter
Re: newLISP Development Release v.10.6.3
Thanks, Lutz! Thanks, kosh[04]!Lutz wrote:This development release adds new functionality to existing functions and fixes bugs. [...] Special thanks to Kosh, who did most of the work for the Windows 64-bit release.
(λx. x x) (λx. x x)
Re: newLISP Development Release v.10.6.3
Since the new development v.10.6.3, a newer development systems with GCC version 4.9.2 from the TDM system is used and running on Windows 7. Before v.10.6.3, Windows newLISP development was on Windows XP. It was time to move on to Windows 7 as a minimum, to take advantage of 64-bit Windows.
This is how simple ffi and extended ffi 'import' and 'callback' are tested:
newlisp-10.6.3/qa-specifif-tests/qa-libffi : simple and extended ffi for callbacks and imports
newlisp-10.6.3/qa-specifif-tests/qa-libc-libffi : extended ffi only and using system libraries
newlisp-10.6.3/examples/opengl-demo.lsp : simple ffi and callback 32-bit only
newlisp-10.6.3/examples/opengl-demo-ffi.lsp : extended ffi and callback 32-bit and 64-bit (UNIX only)
specifically for Windows 32-bit, great example how to work with various Windows DLLs:
newlisp-10.6.3/examples/win32demo.lsp : simple ffi only and with callbacks
When importing self compiled libs on Windows and using the simple ffi, try importing with “cdecl”. See these changes in the qa-libffi file from v10.6.2 to v10.6.3. Try also the extended ffi, present on all Windows versions and all shipped installers for OSX and Linux. Also, the extended ffi does not need to specify “cdecl” versus using the default stdcall on Windows.
This is how simple ffi and extended ffi 'import' and 'callback' are tested:
newlisp-10.6.3/qa-specifif-tests/qa-libffi : simple and extended ffi for callbacks and imports
newlisp-10.6.3/qa-specifif-tests/qa-libc-libffi : extended ffi only and using system libraries
newlisp-10.6.3/examples/opengl-demo.lsp : simple ffi and callback 32-bit only
newlisp-10.6.3/examples/opengl-demo-ffi.lsp : extended ffi and callback 32-bit and 64-bit (UNIX only)
specifically for Windows 32-bit, great example how to work with various Windows DLLs:
newlisp-10.6.3/examples/win32demo.lsp : simple ffi only and with callbacks
When importing self compiled libs on Windows and using the simple ffi, try importing with “cdecl”. See these changes in the qa-libffi file from v10.6.2 to v10.6.3. Try also the extended ffi, present on all Windows versions and all shipped installers for OSX and Linux. Also, the extended ffi does not need to specify “cdecl” versus using the default stdcall on Windows.
Re: newLISP Development Release v.10.6.3
Hello,
The exported function hpwImageExec is compiled with stdcall-option.
It has worked for years now with the newlisp.dll
I have also other exported functions with stdcall which still works with 10603.
I have to further investigate where the access vioaltion occurs.
Regards
The exported function hpwImageExec is compiled with stdcall-option.
It has worked for years now with the newlisp.dll
I have also other exported functions with stdcall which still works with 10603.
I have to further investigate where the access vioaltion occurs.
Regards
Hans-Peter
Re: newLISP Development Release v.10.6.3
Hello,
The only difference I see between the working and non-working calls,
are the fact that the working calls are exported from the DLL which loads the newlisp.dll
The non-working (they do there work/drawing but the boolean-return seems to throw the access violation) are in a DLL which is loaded in the main-app parralel to the newlisp-caller DLL.
Not sure if that can make a difference now.
Edit:
There is a second working command in the DLL: hpwImageCmdList
It return a 1 for result=True
> hpwImageCmdList
hpwImageCmdList@376ECEC
> hpwImageExec
hpwImageExec@37714CC
Here the delphi function which throw the access violation:
Regards
The only difference I see between the working and non-working calls,
are the fact that the working calls are exported from the DLL which loads the newlisp.dll
The non-working (they do there work/drawing but the boolean-return seems to throw the access violation) are in a DLL which is loaded in the main-app parralel to the newlisp-caller DLL.
Not sure if that can make a difference now.
Edit:
There is a second working command in the DLL: hpwImageCmdList
It return a 1 for result=True
> hpwImageCmdList
hpwImageCmdList@376ECEC
> hpwImageExec
hpwImageExec@37714CC
Here the delphi function which throw the access violation:
Code: Select all
FUNCTION hpwImageExec( password,cmdid,Params0,Params1,Params2,Params3,Params4,Params5,Params6,Params7,Params8,Params9 : PChar ) : BOOLEAN; stdcall;
VAR
IDNum : Integer;
BEGIN
Result := FALSE;
IF ExtPasswordcheck(password) Then
BEGIN
IDNum := StrToInt(cmdid);
{ Examine the Action string to determine which Plug-In command to execute... }
CASE IDNum OF
1 : Result := CreateImageControl( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7 );
2 : Result := RemoveImageControl( Params0, FALSE );
3 : Result := ImageDrawLine( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7 );
4 : Result := ImageDrawLines( Params0, Params1, Params2, Params3, Params4, Params5 );
5 : Result := ImageFillRect( Params0, Params1, Params2, Params3, Params4, Params5 );
6 : Result := ImageRectangle( Params0, Params1, Params2, Params3, Params4, Params5, Params6 );
7 : Result := ImageFrameRect( Params0, Params1, Params2, Params3, Params4, Params5 );
8 : Result := ImagePixels( Params0, Params1, Params2, Params3);
9 : Result := ImageTextOut( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7);
10 : Result := ImageTextOutAngle( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7, Params8);
11 : Result := ImageFloodFill( Params0, Params1, Params2, Params3);
13 : Result := ImageColorSwap( Params0, Params1, Params2, Params3, Params4, Params5, Params6);
15 : Result := ImageLoadFromFile( Params0, Params1, Params2, Params3, Params4, Params5);
16 : Result := ImageSaveToFile( Params0, Params1, Params2, Params3, Params4, Params5);
17 : Result := ImageSize( Params0, Params1, Params2);
18 : Result := ImageScaleFromFile( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7);
19 : Result := ImageFileTurn( Params0, Params1, Params2);
20 : Result := ImageLoadFromExe( Params0, Params1, Params2, Params3, Params4, Params5);
21 : Result := ImageLoadFromMimeStream( Params0, Params1, Params2, Params3, Params4, Params5);
22 : Result := ImageSaveToMimeStream( Params0, Params1, Params2, Params3, Params4, Params5);
27 : Result := ImageCopyFromClip( Params0, Params1, Params2, Params3, Params4);
28 : Result := ImageCopyToClip( Params0, Params1, Params2, Params3, Params4 );
29 : Result := ImageScaleFromClip( Params0, Params1, Params2, Params3, Params4, Params5, Params6 );
30 : Result := ImageToClip( Params0, Params1, Params2);
31 : Result := ImageToRTF( Params0, Params1, Params2, Params3, Params4, Params5);
32 : Result := ImageNViewLibSetLanguage( Params0, Params1);
33 : Result := ImageNViewLibLoad( Params0, Params1, Params2, Params3, Params4, Params5);
34 : Result := ImageNViewLibImageSize( Params0, Params1, Params2, Params3);
40 : Result := ImageLoadFromWMF( Params0, Params1, Params2, Params3, Params4, Params5);
70 : Result := ImageSetAlign( Params0, Params1);
71 : Result := ImageSetPos( Params0, Params1, Params2);
72 : Result := ImageSetSize( Params0, Params1, Params2);
73 : Result := ImageMove( Params0, Params1, Params2);
74 : Result := ImageSetCursor( Params0, Params1, Params2);
75 : Result := ImageSetHint( Params0, Params1, Params2);
76 : Result := ImageDragAndDrop( Params0, Params1, Params2, Params3, Params4);
77 : Result := ImageCheckHotspot( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7 );
78 : Result := ImageSetCheckDrop( Params0, Params1, Params2, Params3, Params4 );
79 : Result := ImageSetDragImage( Params0, Params1, Params2, Params3, Params4, Params5 );
80 : Result := ImageSetActions( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7 );
81 : Result := ImageGetPixel( Params0, Params1, Params2, Params3);
82 : Result := ImageGetColor( Params0, Params1, Params2, Params3, Params4);
83 : Result := ImageCompare( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7, Params8);
84 : Result := ImageFind( Params0, Params1, Params2, Params3, Params4, Params5);
90 : Result := CreateScrollBarControl( Params0, Params1, Params2 );
91 : Result := RemoveScrollBarControl( Params0, FALSE );
92 : Result := ScrollbarSetParams( Params0, Params1, Params2, Params3);
93 : Result := ScrollbarSmallChange( Params0, Params1);
94 : Result := ScrollbarLargeChange( Params0, Params1);
95 : Result := ScrollbarPageSize( Params0, Params1);
100 : Result := ActivatePopup( Params0, Params1, Params2);
101 : Result := SetPopupItem( Params0, Params1, Params2);
102 : Result := ImageLoadCursor( Params0, Params1);
103 : Result := ImageLoadCursorBitmap( Params0, Params1, Params2, Params3, Params4);
104 : Result := ImageLoadFromFileEx( Params0, Params1, Params2, Params3, Params4, Params5);
105 : Result := ImageFileOpenPictureBox( Params0, Params1, Params2, Params3, Params4, Params5);
106 : Result := ImageLoadStamp( Params0, Params1, Params2, Params3);
107 : Result := ImageStampConfig( Params0, Params1, Params2, Params3, Params4, Params5, Params6);
108 : Result := ImageBitBlt( Params0, Params1, Params2, Params3, Params4, Params5);
109 : Result := ImageDrawShadow( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7, Params8);
110 : Result := ImageFontBox( Params0, Params1, Params2, Params3, Params4, Params5, Params6, Params7, Params8);
111 : Result := ImageColorBox( Params0, Params1, Params2);
112 : Result := ImageGetRectArea( Params0, Params1);
113 : Result := ImageConvToHSL( Params0, Params1, Params2, Params3);
114 : Result := ImageColorCircle( Params0, Params1, Params2, Params3, Params4);
115 : Result := ImageStampUpdateBuffer( Params0);
116 : Result := ImageGetBoundery( Params0, Params1, Params2, Params3, Params4, Params5, Params6);
117 : Result := ImageStamp( Params0, Params1, Params2);
ELSE Result := FALSE;
END;
END;
END;
Regards
Hans-Peter
Re: newLISP Development Release v.10.6.3
Hello,
Looking with the dependency walker at both DLL, I noticed that 10603 has the WEP-entry point as the first entry where it was the last in 10602.
And there is a new newLispLibConsole.
What to do with it in DLL?
Regards
Looking with the dependency walker at both DLL, I noticed that 10603 has the WEP-entry point as the first entry where it was the last in 10602.
And there is a new newLispLibConsole.
What to do with it in DLL?
Regards
Hans-Peter
Re: newLISP Development Release v.10.6.3
Hello,
I finally figured it out:
DLL < 10603 were tolerant when calling the function with less parameter than defined.
FUNCTION hpwImageExec( password,cmdid,Params0,Params1,Params2,Params3,Params4,Params5,Params6,Params7,Params8,Params9 : PChar ) : BOOLEAN; stdcall;
So adding an empty param solves the exception:
(hpwImageExec "" "3" "RImage1" "0" "0" "100" "100" "clRed" "" "psSolid" "2" "")
Regards
I finally figured it out:
DLL < 10603 were tolerant when calling the function with less parameter than defined.
FUNCTION hpwImageExec( password,cmdid,Params0,Params1,Params2,Params3,Params4,Params5,Params6,Params7,Params8,Params9 : PChar ) : BOOLEAN; stdcall;
So adding an empty param solves the exception:
(hpwImageExec "" "3" "RImage1" "0" "0" "100" "100" "clRed" "" "psSolid" "2" "")
Regards
Hans-Peter
Re: newLISP Development Release v.10.6.3
And mail from symantec:
Upon further analysis and investigation we have verified your submission and, as such, the detection(s) for the following file(s) will be removed from our products:
D57CA6F8688BE2661ECCDCEA2EB24C8D - newlisp_10603_win_gs_163.exe
The updated detection(s) will be distributed in the next set of virus definitions, available via LiveUpdate or from our website at http://securityresponse.symantec.com/av ... nload.html
Please note that whitelisting can take up to 24 hours to take effect.
Upon further analysis and investigation we have verified your submission and, as such, the detection(s) for the following file(s) will be removed from our products:
E99D50886F30187F7ABA3E14A07C6292 - newlisp_10603_win64_gs_163.exe
The updated detection(s) will be distributed in the next set of virus definitions, available via LiveUpdate or from our website at http://securityresponse.symantec.com/av ... nload.html
Please note that whitelisting can take up to 24 hours to take effect.
Hans-Peter
Re: newLISP Development Release v.10.6.3
Thanks Hans-Peter for bringing this to Symantec's attention.
Re: newLISP Development Release v.10.6.3
Hello,
In CodePatters chapter 24 you can read:
Regards
In CodePatters chapter 24 you can read:
Is it right? I see no newlisp.dll in system32.Only on MS Windows, the installer comes with a precompiled newlisp.dll and will install it in the WINDOWS\system32\ directory (since v.10.3.3) and in the Program Files/newlisp/ directory.
Regards
Hans-Peter
Re: newLISP Development Release v.10.6.3
Only installs in the newLISP program directory.
Corrected here: http://www.newlisp.org/downloads/CodePa ... tml#toc-24
and here: http://www.newlisp.org/downloads/develo ... tml#toc-24
Corrected here: http://www.newlisp.org/downloads/CodePa ... tml#toc-24
and here: http://www.newlisp.org/downloads/develo ... tml#toc-24
Re: newLISP Development Release v.10.6.3
I noticed that just below that section, in the "Registering callbacks" section.
and...
The ostype string being compared should be changed to "windows".
-- xytroxon
Code: Select all
(set 'LIBRARY (if (= ostype "Win32") "newlisp.dll" "newlisp.dylib"))
Code: Select all
(set 'CALLTYPE (if (= ostype "Win32") "stdcall" "cdecl"))
-- xytroxon
"Many computers can print only capital letters, so we shall not use lowercase letters."
-- Let's Talk Lisp (c) 1976
-- Let's Talk Lisp (c) 1976
Re: newLISP Development Release v.10.6.3
This was already changed: http://www.newlisp.org/downloads/develo ... terns.html showing 10.6.3 in the title page.
Perhaps you where looking in the version for 10.6.2 in the main download directory. It also has a current date, but does not have the "Win32" -> "Windows" update. I will keep both versions updated till the next stable release, but in a version sensitive manner.
Perhaps you where looking in the version for 10.6.2 in the main download directory. It also has a current date, but does not have the "Win32" -> "Windows" update. I will keep both versions updated till the next stable release, but in a version sensitive manner.
Re: newLISP Development Release v.10.6.3
Lutz, Thanks for applying my patch.
I found some other compile problems.
1. configure-alt: still `os_type` is set to WIN_32/64
2. newlisp.h: _WIN32_WINNT could not set correctly
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.
I found some other compile problems.
1. configure-alt: still `os_type` is set to WIN_32/64
Code: Select all
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}"
Code: Select all
$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:\dev\newlisp/nl-sock.c:677: undefined reference to `getaddrinfo'
c:\dev\newlisp/nl-sock.c:682: undefined reference to `freeaddrinfo'
...
make: *** [default] Error 1
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.
Re: newLISP Development Release v.10.6.3
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.
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.
Re: newLISP Development Release v.10.6.3
Hello, Lutz.
For Stable Release,
line 2965 in newlisp_manual v10.6.3
For Stable Release,
line 2965 in newlisp_manual v10.6.3
line 3029to itself, elready existing contexts like MAIN do not require quoting.</p>
↓
to itself, already existing contexts like MAIN do not require quoting.</p>
line 25350<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 25353<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 27178operating system. On MS Windows systems the environment vatiable <tt>TEMP</tt>
↓
operating system. On MS Windows systems the environment variable <tt>TEMP</tt>
line 27179<h4>syntax: (trace <em>true</em>)<br/>
↓
<h4>syntax: (trace <em>int-device</em>)<br/>
line 27199syntax: (trace <em>int-device</em>)<br/>
↓
syntax: (trace <em>true</em>)<br/>
Regards,<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
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: newLISP Development Release v.10.6.3
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.Lutz wrote: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.
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 all
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
Code: Select all
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"
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
-
- Posts: 228
- Joined: Mon Jun 02, 2014 1:40 am
- Location: Melbourne, Australia
Re: newLISP Development Release v.10.6.3
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.
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.
Re: newLISP Development Release v.10.6.3
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 it could be useful to see the history of code portions when fixing bugs.
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 it could be useful to see the history of code portions when fixing bugs.
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: newLISP Development Release v.10.6.3
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.
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
-
- Posts: 608
- Joined: Mon Feb 05, 2007 1:04 am
- Location: Abbotsford, BC
- Contact:
Re: newLISP Development Release v.10.6.3
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.
Cavemen in bearskins invaded the ivory towers of Artificial Intelligence. Nine months later, they left with a baby named newLISP. The women of the ivory towers wept and wailed. "Abomination!" they cried.
Re: newLISP Development Release v.10.6.3
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/
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/