Menu
▾
▴
clisp-devel
|
From: Reini U. <rei...@gm...> - 2017-03-19 09:42:47
|
Hi I subscribed under my latest email address, the older ones died several years ago. I resurrected some old efforts and added some new: 1. I added a github mirror from the hg repo, with bi-hourly updates. https://github.com/rurban/clisp/ I put my branches there. 2. Some minor files have still german comments. I started translating them to english as before. Progress is in my translate branch. https://github.com/rurban/clisp/commits/translate Will send a patch when ready. There’s also some minor stuff. 3. I’m in the progress to add continuous integration via travis (linux, OS X) and appveyor (Windows). This smokes every update, branches and pull requests on these 3 platforms. It also would allow automatic deployment for binary packages (deb, rpm, windows) at bintray. That’s what we do with the pony compiler. https://github.com/rurban/clisp/commits/ci https://travis-ci.org/rurban/clisp/ https://ci.appveyor.com/project/rurban/clisp/history I’m still tuning the setup a bit, so far only linux runs through. So far it’s under my account. I would be happy to transfer it to bruno or sam, if wanted. They integrate nicely with github, no idea about sourceforge. Reini Urban |
|
From: Bruno H. <br...@cl...> - 2017-03-19 10:08:49
|
Hi Reini, Great to hear from you again! > 2. Some minor files have still german comments. I started translating them to english as before. > Progress is in my translate branch. > https://github.com/rurban/clisp/commits/translate > > Will send a patch when ready. There’s also some minor stuff. This is very welcome! > 3. I’m in the progress to add continuous integration via travis (linux, OS X) and appveyor (Windows). > This smokes every update, branches and pull requests on these 3 platforms. > It also would allow automatic deployment for binary packages (deb, rpm, windows) at bintray. That’s what we do with the pony compiler. > > https://github.com/rurban/clisp/commits/ci > https://travis-ci.org/rurban/clisp/ > https://ci.appveyor.com/project/rurban/clisp/history > > I’m still tuning the setup a bit, so far only linux runs through. This is also very welcome! Note that Don Cohen is also doing continuous integration builds, but probably with a different approach (on his own machines, as far as I understood) and maybe with a different focus. > So far it’s under my account. I would be happy to transfer it to bruno or sam, if wanted. As long as you manage it, I don't want to steal it from you. I have enough work with the occasional build on other platforms (from FreeBSD to Solaris). Bruno |
|
From: Bruno H. <br...@cl...> - 2017-03-19 10:31:38
|
Hi Reini, > https://github.com/rurban/clisp/commits/ci > https://travis-ci.org/rurban/clisp/ > https://ci.appveyor.com/project/rurban/clisp/history One of your builds [1], on Linux shows the warning Warning: reserving address range 0x2b0000000000...0x2bffffffffff that contains memory mappings. clisp might crash later! followed by a memory dump. I'm putting this in my TODO list. Bruno [1] https://travis-ci.org/rurban/clisp/jobs/212644808 |
|
From: Bruno H. <br...@cl...> - 2017-03-19 10:43:48
|
Hi Reini, > 3. I’m in the progress to add continuous integration via travis (linux, OS X) and appveyor (Windows). > ... > https://github.com/rurban/clisp/commit/7b64a9b41d74460dc361e117700eee9713601ea0 Can you make the builds work on a machine that has not only MSVC but also Cygwin installed? I'm asking because nowadays my preferred way to produce native Windows binaries is by using Cygwin as a development environment, see [1], as it - does not require to manually maintain a config.h (since it's fully autoconfiguring), - does not require the complexity in makemake.in regarding backslashes vs. slashes (since the build relies on GNU make, not nmake), - does not require to regularly update win32msvc/makefile.msvc* (the last update was in 2010!) In other words, is much much simpler. But it requires Cygwin tools. Or in the future, the Microsoft WSL [2] may be reliable enough for this task as well. Bruno [1] http://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=blob;f=README.windows [2] https://msdn.microsoft.com/en-us/commandline/wsl/about |
|
From: Reini U. <rei...@gm...> - 2017-03-20 06:51:25
|
Reini Urban ru...@cp... > On Mar 19, 2017, at 11:43 AM, Bruno Haible <br...@cl...> wrote: > > Hi Reini, > >> 3. I’m in the progress to add continuous integration via travis (linux, OS X) and appveyor (Windows). >> ... >> https://github.com/rurban/clisp/commit/7b64a9b41d74460dc361e117700eee9713601ea0 > > Can you make the builds work on a machine that has not only MSVC but also > Cygwin installed? Cygwin would be nice, esp. to produce releases, but I’m not sure if Appveyor provides such an image yet. They are just a small Russian company, not so high-powered as Travis in Berlin. First I wanted to get MSVC passing, then I wanted to switch over to mingw, which is supported, and smoke with win32 and win64. Eventually add a cygwin setup in a local cache, for much easier testing, but I haven’t done this yet in other projects. I have to look around. I gave up on cygwin locally some years ago, as I could switch fully to darwin/linux and do not maintain my windows machines anymore. Only eventually I’ll have to do that, most likely to debug libsigsegv on win64. This was the latest blocker when I left. > I'm asking because nowadays my preferred way to produce native Windows binaries > is by using Cygwin as a development environment, see [1], as it > - does not require to manually maintain a config.h (since it's fully > autoconfiguring), > - does not require the complexity in makemake.in regarding backslashes vs. > slashes (since the build relies on GNU make, not nmake), > - does not require to regularly update win32msvc/makefile.msvc* (the last > update was in 2010!) Yes. I explicitly wanted to catch some errors there, on such old platforms. Apparently I found some :) > In other words, is much much simpler. But it requires Cygwin tools. Or in the > future, the Microsoft WSL [2] may be reliable enough for this task as well. > > Bruno > > [1] http://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=blob;f=README.windows > [2] https://msdn.microsoft.com/en-us/commandline/wsl/about > |
|
From: Bruno H. <br...@cl...> - 2017-03-22 06:43:34
|
Hi Reini, > Cygwin would be nice, esp. to produce releases, but I’m not sure if Appveyor provides such an > image yet. Apparently they do, in their Visual Studio 2015 pre-installed image, see https://www.appveyor.com/docs/build-environment/#mingw-msys-cygwin Can you confirm it? Thus, can we ditch the nmake-based build? > First I wanted to get MSVC passing, then I wanted to switch over to mingw, which is supported, > and smoke with win32 and win64. I usually port things in the opposite direction: first cygwin, then mingw, then MSVC. So that at each step, I have a limited set of problems to deal with, not all at once. > most likely to debug libsigsegv on win64. This was the > latest blocker when I left. Yes, libsigsegv on 64-bit Windows still does not work. Bruno |
|
From: Sam S. <sd...@gn...> - 2017-03-20 15:45:12
|
Hi Reini, and welcome back! > * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-19 10:42:37 +0100]: > > 1. I added a github mirror from the hg repo, with bi-hourly updates. > https://github.com/rurban/clisp/ Did you import the whole mercurial history into git? Thanks -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://iris.org.il http://thereligionofpeace.com http://americancensorship.org http://camera.org Live Lisp and prosper. |
|
From: Reini U. <rei...@gm...> - 2017-03-20 22:36:19
|
> On Mar 20, 2017, at 4:45 PM, Sam Steingold <sd...@gn...> wrote: > > Hi Reini, and welcome back! > >> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-19 10:42:37 +0100]: >> >> 1. I added a github mirror from the hg repo, with bi-hourly updates. >> https://github.com/rurban/clisp/ > > Did you import the whole mercurial history into git? Yes, there’s a nice bridge by Felipe Contreras, https://github.com/felipec/git-remote-hg/blob/master/git-remote-hg for read+write. I even imported the old bad commits with missing names and emails. I tried to fix them, but then the importer could not identify the old ones anymore, as the hashes changed. So I went with all the original commits. I don’t import the already closed branches, only the open ones. |
|
From: Sam S. <sd...@gn...> - 2017-03-21 19:07:24
|
Hi Reini, > * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-19 10:42:37 +0100]: > > ...(Windows)... Could you please try my patch https://sourceforge.net/p/clisp/patches/_discuss/thread/58fe6204/2688/attachment/no_dynamic_modules_cygwin.patch (see https://sourceforge.net/p/clisp/patches/46/ for context)? Thanks! -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net http://www.memritv.org http://islamexposedonline.com https://jihadwatch.org http://jij.org If a cat tells you that you lost your mind, then it is so. |
|
From: Reini U. <rei...@gm...> - 2017-03-22 09:41:02
|
> On Mar 21, 2017, at 8:07 PM, Sam Steingold <sd...@gn...> wrote: > > Hi Reini, > >> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-19 10:42:37 +0100]: >> >> ...(Windows)... > > Could you please try my patch > https://sourceforge.net/p/clisp/patches/_discuss/thread/58fe6204/2688/attachment/no_dynamic_modules_cygwin.patch > (see https://sourceforge.net/p/clisp/patches/46/ for context)? I see. Currently I’m still fighting with earlier mingw64, libsigsegv, ffcall and shell oddities. Will try later. Looks good to me. Thanks. |
|
From: Reini U. <rei...@gm...> - 2017-03-22 09:57:25
|
> On Mar 22, 2017, at 10:40 AM, Reini Urban <rei...@gm...> wrote: > > >> On Mar 21, 2017, at 8:07 PM, Sam Steingold <sd...@gn...> wrote: >> >> Hi Reini, >> >>> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-19 10:42:37 +0100]: >>> >>> ...(Windows)... >> >> Could you please try my patch >> https://sourceforge.net/p/clisp/patches/_discuss/thread/58fe6204/2688/attachment/no_dynamic_modules_cygwin.patch >> (see https://sourceforge.net/p/clisp/patches/46/ for context)? > > I see. > Currently I’m still fighting with earlier mingw64, libsigsegv, ffcall and shell oddities. > > Will try later. Looks good to me. > Thanks. Yes, your patch fixes some mingw configuration issue. Works fine, confirmed. https://ci.appveyor.com/project/rurban/clisp/build/clisp-ci-2.49.50+-78.bf7d08c (I’ve never been that far) |
|
From: Sam S. <sd...@gn...> - 2017-03-22 13:29:52
|
> * Reini Urban <ervav.heona@tznvy.pbz> [2017-03-22 10:57:16 +0100]: > >>>> ...(Windows)... >>> >>> Could you please try my patch >>> https://sourceforge.net/p/clisp/patches/_discuss/thread/58fe6204/2688/attachment/no_dynamic_modules_cygwin.patch >>> (see https://sourceforge.net/p/clisp/patches/46/ for context)? >> >> Currently I’m still fighting with earlier mingw64, libsigsegv, ffcall >> and shell oddities. >> >> Will try later. Looks good to me. > > Yes, your patch fixes some mingw configuration issue. > Works fine, confirmed. Thanks! -- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://jihadwatch.org http://memri.org http://think-israel.org http://www.memritv.org A person without flaws probably lacks strengths either. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X