Re: A possible way to build for windows
Thanks Alex - I'll try and do the translation to nasm and can validate it on Linux itself (without removing anything). Hey Joe ... yeah, WSL is really not an option for the use case where I'd like to share scripts that I'd like to share. Thanks for the link though - I was not aware of running "wsl" - I have always been click starting WSL and did not realize that it was so easily accessible from regular command shell! Atleast, it makes it possible for me to run my favorite "find" from a cmd shell! Regards, Kashyap On Tue, Feb 26, 2019 at 5:46 AM Joe Bogner wrote: > Hi Kashyap, > > I've been interested in a picolisp port to Windows for several years. I've > tried a number of different options. My last effort was to use > https://midipix.org/ as the POSIX layer. It worked OK but then midipix > seemed to lose steam with Windows Subsystem for Linux (WSL) coming out. > Now, I just use picolisp on WSL. > > Reading this thread, > https://www.mail-archive.com/picolisp@software-lab.de/msg08551.html, I > see that WSL isn't an option because you intend to use existing dlls. > > Have you considered hosting your DLLs in a HTTP service (e.g. golang) and > then calling them from picoLisp running on WSL? That likely would be an > easier path to integrate than rewriting the POSIX layer or porting to > Windows APIs. It also looks like piping works > https://docs.microsoft.com/en-us/windows/wsl/interop so perhaps you can > avoid HTTP altogether. > > Regards, > Joe > > > > On Sun, Feb 24, 2019 at 9:50 PM C K Kashyap wrote: > >> Hi, >> I have been considering the idea of getting picolisp to run on windows >> (without a heavy weight setup - cygwin/mingw) for a while now. What if I >> try and target nasm instead of gnu assembler? That should work. Regarding >> the POSIX dependency, I think it should be a matter of making all the >> functions (do*) NOPs. I should be able to get a 64bit picolisp calculator >> up and running. And then leisurely add the do* functions. >> >> Ofcourse, if this works, it would be a convenient way to build on mac too! >> >> Regards, >> Kashyap >> >
Re: A possible way to build for windows
Hi Kashyap, I've been interested in a picolisp port to Windows for several years. I've tried a number of different options. My last effort was to use https://midipix.org/ as the POSIX layer. It worked OK but then midipix seemed to lose steam with Windows Subsystem for Linux (WSL) coming out. Now, I just use picolisp on WSL. Reading this thread, https://www.mail-archive.com/picolisp@software-lab.de/msg08551.html, I see that WSL isn't an option because you intend to use existing dlls. Have you considered hosting your DLLs in a HTTP service (e.g. golang) and then calling them from picoLisp running on WSL? That likely would be an easier path to integrate than rewriting the POSIX layer or porting to Windows APIs. It also looks like piping works https://docs.microsoft.com/en-us/windows/wsl/interop so perhaps you can avoid HTTP altogether. Regards, Joe On Sun, Feb 24, 2019 at 9:50 PM C K Kashyap wrote: > Hi, > I have been considering the idea of getting picolisp to run on windows > (without a heavy weight setup - cygwin/mingw) for a while now. What if I > try and target nasm instead of gnu assembler? That should work. Regarding > the POSIX dependency, I think it should be a matter of making all the > functions (do*) NOPs. I should be able to get a 64bit picolisp calculator > up and running. And then leisurely add the do* functions. > > Ofcourse, if this works, it would be a convenient way to build on mac too! > > Regards, > Kashyap >
Re: A possible way to build for windows
Hi Kashyap,
> I feel pretty sure that I should be able to translate the .s into nasm
> syntax fairly mechanically. I have done similar things before. What I love
> about nasm is that there is no ceremony code :)
I see. Nice!
> @Alex - I have a follow up question about POSIX requirement - To bet the
> basic REPL up and running the POSIX requirement would be limited to getc
> from STDIN right?
Yes, plus print to stdout. You have to remove a lot of stuff though.
The REPL is now 'doLoad' -> 'loadBEX_E', which also open a file if input is not
from the TTY, and then calls 'readC_E' to read an expression, which in turn
trickles down via (Get_A) indirection to 'getStdin_A' (which you may call "getc"
but which involves the whole event machinery using the select() system call in
'waitFdCEX_A').
You can compare the full version vs. a plain getc() version if you look at
the differences between src/io.c and miniPicoLisp/src/io.c - in the latter
we have
void getStdin(void) {Chr = getc(InFile);}
as opposed to the full version in pil32 (which does the same as 'getStdin_A' in
pil64)
void getStdin(void) {
if (!InFile)
Chr = -1;
else if (InFile != InFiles[STDIN_FILENO]) {
if (InFile->ix == InFile->cnt && (InFile->ix < 0 ||
!slow(InFile,NO))) {
Chr = -1;
return;
}
if ((Chr = InFile->buf[InFile->ix++]) == '\n')
++InFile->line;
}
else if (!isCell(val(Led))) {
waitFd(NULL, STDIN_FILENO, -1);
Chr = stdinByte();
}
else {
static word dig;
if (!isNum(Line))
dig = isNum(Line = name(run(val(Led? unDig(Line) : '\n';
else if ((dig >>= 8) == 0)
dig = isNum(Line = cdr(numCell(Line)))? unDig(Line) : '\n';
Chr = dig & 0xFF;
}
}
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
