Author Topic: Lisp in Basic  (Read 226991 times)

0 Members and 3 Guests are viewing this topic.

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #870 on: September 27, 2014, 02:54:30 PM »
No Rob,

Your new exe behaves as badly as the previous one. Once loaded, javaw keeps hanging in memory irrespective of how you quit newlisp. You can even:

1. abstain from starting to calc the magic squares (i.e. from pushing the go! button);

2. close the graphics window by its [X] button thereby getting access to your newlisp console input/output; and

3. then you can type (exit) in the console in an attempt to quit the entire process.

Nonetheless, even if your console closes on this command, javaw still persists in memory eating resources and making the magic.exe file undeletable from the disk. (NB item 2 above is the exact situation that I showed how to cope with in my earlier Non Blocking Console example)

This mess breaks the fundamental rules of Windows programming:

1. Any GUI process must be killable completely by destroying its main window (Alt+F4 press or [X] click or DestroyWindow()) so that javaw must unload once its main window closes; and

2. Every console or shell process on an NT platform must be killable cleanly and completely (i.e. killing also all dependent processes, whether CUI or GUI, such as javaw in our case) once the shell or process console window is closed with a [X] button click or exit command.

So your NL/JAPI executables are breaking both of these rules simultaneously, and this isn't your fault. This is the unpardonnable fault of NewLISP and Java for Windows developers who don't know their whereabouts on the platform they are claiming compatibility with. >:(

jack

  • Guest
Re: Lisp in Basic
« Reply #871 on: September 27, 2014, 03:42:24 PM »
hello RobbeK,
have you tried the gui server of newlisp?
there are a number of examples in the demo folder, goto help/open demo folder.

JRS

  • Guest
Re: Lisp in Basic
« Reply #872 on: September 27, 2014, 04:02:40 PM »
Rob,

If the CERN ROOT graphics API and GUI builder fits for the type of stuff you do, there is a Lisp interface library that comes with the package.

As popular as Lisp seems to be, you would think they would have GUI figured out by now.  :-[

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #873 on: September 27, 2014, 07:01:40 PM »
Hey guys,

nanoscheme does 64-bit integer calc. (wink-wink John)

Proceeding straight over to flonums. :)

.

JRS

  • Guest
Re: Lisp in Basic
« Reply #874 on: September 27, 2014, 07:35:32 PM »
Cool Mike.

Is source to your creation going to be made available?


Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #875 on: September 27, 2014, 07:56:58 PM »
http://www.oxygenbasic.org/forum/index.php?topic=1147.msg11587#msg11587

Currently it's still in its C form. It'll be easier to translate it to Oxygen all in one piece with all these minute improvements already in place.

JRS

  • Guest
Re: Lisp in Basic
« Reply #876 on: September 27, 2014, 08:51:10 PM »
We all can be thankful that you stayed the Scheme path and didn't cheat and use other Lisp varieties like Rob:P

Sooner or later Rob will catch on to our scheme.  ::)

Q. Am I sounding like a Lisp programmer yet?

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #877 on: September 27, 2014, 11:04:14 PM »
A. No, not yet. You should be consing and memoizing more often. You should also abstain from subs and functions and stick to lambdas and closures.

Good night!


RobbeK

  • Guest
Re: Lisp in Basic
« Reply #878 on: September 28, 2014, 12:42:29 AM »
Morning, Jack , John , Mike ...

OK, the problem is there with all progrs running Japi, be it as a static lib or dynamic.
I tested : FB , STALIN and some others ..  it does not remove its Java launcher on exit.  -- On the web similar behaviour is mentioned concerning Eclipse , Minecraft applications and others.
Under NewLISP it is even worse (as Mike mentioned)....
From what I read it seems the Java code misses     exit(0)   to make the launcher not resident....   

Good,  (or better bad )   ...   NewLISP with its own Java (Swing) server , closes things normally.
(However (Jack) , while the server has tagged graphics , it misses pixel drawing and (AFAIK) any memory->screen mechanism making fast animations possible ....     (sigh)

So, John ... what I'm looking for is something doing fast double buffered graphics and/or uses OpenGL -- you're 100% correct the combination Windows + Lisp + Graphics is a close to disaster situation ...   (all seem focussing on Unix systems )

best , Rob

.................  copy from the www

After invoking and closing a random chosen java web start application (e.g. from http://java.sun.com/products/javawebstart/demos.html) javaws.exe stays in memory
(e.g. end of the day 10 copies of javaws.exe in Windows Task Manager)

-----------  it seems their own demo's show this behaviour (ok , it's old stuff , but  ....  )

(I think the best solution is to concentrate on Racket Scheme , which has a perfect GUI builder , OpenGL and the code compiles both under Win and Linux )


(Mike, is their a "software-way" to remove tasks ?? )
« Last Edit: September 28, 2014, 01:41:16 AM by RobbeK »

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #879 on: September 28, 2014, 04:04:59 AM »
Hi Rob,

If NL allows you to easily call Windows DLL functions then try to call ExitProcess(0) which resides in kernel32.dll. It has the same effect as exit(0) and it also closes all of the process' own dependencies gracefully. It is the preferred method of ending a Windows process. This function provides a clean process shutdown. This includes calling the entry-point function of all attached dynamic-link libraries (DLLs) with a value indicating that the process is detaching from the DLL. After all attached DLLs have executed any process termination value, this function terminates the current process.

Quote from: Win SDK Help
VOID ExitProcess(
    UINT uExitCode    // exit code for all threads 
);

Terminating a process however does not cause child processes to be terminated. So, if for some reason javaw.dll isn't used as an ordinary in-process code module but rather spawns a separate process of its own, it might stay resident as it does now. (but that would be unusual and incorrect under Windows)

If it doesn't help, a more complicated WinAPI strategy should be followed. This would involve enumerating all running processes to find the javaw process handle and applying a rougher TerminateProcess() WinAPI directly to javaw. That's effectively what the Task Manager does when I push its Kill Process button with javaw selected in its list of currently running processes:

Quote from: Win SDK Help
BOOL TerminateProcess(
    HANDLE hProcess,   // handle to the process
    UINT uExitCode    // exit code for the process 
);

I don't however know if the latter strategy is suitable for programs that have been launched without Admin privileges on Vista+ platforms.


P.S. Judging by your quotations from other people, javaw behaves like downright malware. I wonder if it is also being developed by yet another bunch of GNU GPL open-sourcers? ;)

Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #880 on: September 28, 2014, 04:49:36 AM »
Hehe, look: John's already emitted 2,000 messages! That's about 1/5th of the forum's total.

RobbeK

  • Guest
Re: Lisp in Basic
« Reply #881 on: September 28, 2014, 05:22:36 AM »
Hi Mike,

(import "kernel32.dll" "ExitProcess")

and

(ExitProcess 0)

but it doesn't kill javaw.exe  >:(


malware , yes .. a perfect definition   --- another one from the www

--------------   AD 2012



Recently, javaw.exe processes have been taking over my computer and forcing me to exit out Eclipse and other applications due to low memory errors. Note that I am not maxing out the system at all, and am I working on some basic java programs, and I have 2-3 eclipse tabs open at a time max.

I have about 40-50 of these javaw.exe processes each take up 22K-26K of RAM, which eventually eats up 70-80% of my 8GB RAM on my machine. This is extremely frustrating as I cannot do any work like this. I was wondering if anyone else has experienced this and knows how to troubleshoot this problem?

--------------------------------------  AD 2014

"javaw.exe memory usage increases constantly"

---------------------------------

No answers from Sun or Oracle ................

best Rob


Mike Lobanovsky

  • Guest
Re: Lisp in Basic
« Reply #882 on: September 28, 2014, 07:14:03 AM »
Rob,

Then there is only one way out, which is to use TerminateProcess() on javaw.exe. I will give you some OxygenBasic code below (not tested though, it's my immediate port from FBSL!) that will loop to find the Java process and kill it. You will have to translate it to NL if it supports C/O2 style structures/UDT's, or you will have to compile it as an O2 executable and launch your NL/JAPI apps from a batch (.BAT) file wherein the first line should shell out to your NL/JAPI exe, and the second should run this O2 proggy. It will be killing Java automatically once your NL/JAPI app terminates.

Code: [Select]
! Function CreateToolhelp32Snapshot LIB "kernel32" (DWORD dwFlags, th32ProcessID) As DWORD
! Function Process32First LIB "kernel32" (DWORD hSnapshot, lppe) As Long
! Function Process32Next LIB "kernel32" (DWORD hSnapshot, lppe) As Long
! Function OpenProcess LIB "kernel32" (DWORD dwDesiredAccess, bInheritHandle, dwProcessId) As DWORD
! Sub TerminateProcess LIB "kernel32" (DWORD hProcess, uExitCode)
! Sub CloseHandle LIB "kernel32" (DWORD hObject)

Type PROCESSENTRY32
  DWORD dwSize
  DWORD cntUsage
  DWORD th32ProcessID
  DWORD th32DefaultHeapID
  DWORD th32ModuleID
  DWORD cntThreads
  DWORD th32ParentProcessID
  Long pcPriClassBase
  DWORD dwFlags
  Char szExeFile[260]
End Type

Const TH32CS_SNAPALL = 0xF
Const PROCESS_TERMINATE = 0x1

Dim lppe As PROCESSENTRY32
Dim As DWORD hproc, hsnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPALL, 0)
Dim As Long success

If hsnapshot Then
    lppe.dwSize = SizeOf(lppe)
    success = Process32First(hSnapshot, @lppe)
    While success
        If RTrim(lppe.szExeFile) = "javaw.exe" Then
           hproc = OpenProcess(PROCESS_TERMINATE, 0, lppe.th32ProcessID)
           TerminateProcess(hproc, 0)
           CloseHandle(hproc)
           Exit While
        End If
        success = Process32Next(hsnapshot, @lppe)
    Wend
    CloseHandle(hsnapshot)
End If

End


This script has just shot dead that hateful javaw.exe process left over from your recent magic4b.exe. :D

P.S. DO NOT try to use the EnumProcesses() WinAPI as many would suggest out there -- this WinAPI is hosted in different DLL's on different platforms, so your code won't be platform independent then.

RobbeK

  • Guest
Re: Lisp in Basic
« Reply #883 on: September 28, 2014, 10:18:46 AM »
Thank you so much Mike  --  the only other solution was to throw away BigLoo and the STALIN compiler (starting up the TaskManager after every run, is doing things wrong imho - even if this works)  , Japi being their only interface under Windows.  (same for GCL in fact )

Yes, NL has C structures to interface with foreign (C) functions (and unlike some Common Lisps , it uses c-strings ).  I'll add it to the system naming it (exit0) or something like ...

...  thanks again  :)

Been toying with the Guiserver.jar that comes with the NL distribution,  here at first sight , I do not see any problems  -- (the console nicely outputs it shuts down the server )

However, now it seems it gives problem under the OpenJava (or GNUJava or whatever ) on Linux .... ::)   never mind ...

(it has a more modern look/feel , even with some themes and the graphics are tagged )


best, Rob



.

JRS

  • Guest
Re: Lisp in Basic
« Reply #884 on: September 28, 2014, 10:23:22 AM »
Quote from: Rob
So, John ... what I'm looking for is something doing fast double buffered graphics and/or uses OpenGL -- you're 100% correct the combination Windows + Lisp + Graphics is a close to disaster situation ...   (all seem focussing on Unix systems )

If the folks at CERN, NASA, ... thought Windows was a better OS to use for their research, they would be using it but their not. Don't forget that buying commercial business software isn't just about code but getting paid and hooking you on the solution as long as they can bleed you. (vendor lock-in) It won't be long before the concept of selling software seems absurd. Profit should be made on services provided and custom adaptations of the norm.
« Last Edit: September 28, 2014, 12:59:28 PM by John »