Re: Ersatz warnings in Eclipse
On Wed, Jul 17, 2013 at 08:24:45PM +0200, Alexander Burger wrote: > I'll fix that. Thanks! Done :) I've fixed all other places too where it complained about unused variables (these were really unused ones), and have uploaded a new release. Please test again whenever you have time! ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Ersatz warnings in Eclipse
Hi Jon, > > next = Env.Next; Env.Next = 0; > > > > So here 'next' is used. > > Not really. A value (from Env.Next) is stored in 'next', but that value is > never retrieved from 'next' later. Therefor 'next' is considered useless. Ah! Cool! That's the problem. 'next' is indeed necessary, and the above assignment is correct. The bug is that this *retrieval* somehow got lost, so nested function calls with variable arguments (i.e. the '@' mechanism) will unnest properly. This bug can be produced by nesting two vararg-functions: (de f @ (g 1 2) (println (next)) ) (de g @ (println (next)) ) (f 3) PicoLisp correctly prints 1 and 3, but Ersatz gives a NullPointerException because 'Env.Next' is never restored when 'g' terminates. I'll fix that. Thanks! ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Ersatz warnings in Eclipse
Hi Alex,
> Hi Jon,
>
>> > because 'next' is in fact used (and needed!) in all those cases.
>> >
>> > How come?
>>
>> I cannot see one place where the value of 'next' is used
>> (read/retrieved).
>> Can you tell me which line?
>
> Yes, for example the one where Eclipse is complaining about:
>
>The value of the local variable next is not used ... line 1507
>
> Starting from line 1507:
>
> int next, argc, j = 0;
> Any arg, args[], av[] = null;
> if (x instanceof Cell) {
> av = new Any[6];
> do
>av = append(av, j++, x.Car.eval());
> while ((x = x.Cdr) instanceof Cell);
> }
> next = Env.Next; Env.Next = 0;
>
> So here 'next' is used.
Not really. A value (from Env.Next) is stored in 'next', but that value is
never retrieved from 'next' later. Therefor 'next' is considered useless.
/Jon
>> At the moment, I'm not sure if one should care about those "raw types".
>> Maybe someone with more up to date Java knowledge can tell? ;-)
>
> Yeah :)
>
> ?? Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Ersatz warnings in Eclipse
Hi Jon,
> > because 'next' is in fact used (and needed!) in all those cases.
> >
> > How come?
>
> I cannot see one place where the value of 'next' is used (read/retrieved).
> Can you tell me which line?
Yes, for example the one where Eclipse is complaining about:
The value of the local variable next is not used ... line 1507
Starting from line 1507:
int next, argc, j = 0;
Any arg, args[], av[] = null;
if (x instanceof Cell) {
av = new Any[6];
do
av = append(av, j++, x.Car.eval());
while ((x = x.Cdr) instanceof Cell);
}
next = Env.Next; Env.Next = 0;
So here 'next' is used.
> At the moment, I'm not sure if one should care about those "raw types".
> Maybe someone with more up to date Java knowledge can tell? ;-)
Yeah :)
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Ersatz warnings in Eclipse
Hi Alex, > Hi Jon, > > thanks for the input! > >> obtain the PicoLisp.java source for the ersatz/picolisp.jar, I did >> cd ersatz/ >> pil mkJar + >> >> I then created an empty Java project in Eclipse and imported the >> PicoLisp.java source. To avoid a NullPointerException when running my >> project, I entered "-DPID=999" into 'VM arguments' in 'Run >> Configurations'. (999 just seemed to work for now. $$ did not.) Then I >> could do simple PicoLisp stuff in the Eclipse Console. ;-) > > Great! > > >> However, Eclipse gave me 36 warnings. They may mean next to nothing for >> the Ersatz execution. Most of the warnings (23) were "The value of the >> local variable ... is not used". In case you should want to do some >> cleaning up when having some spare time, I have attached a zip file >> containing the (tab separated) warnings.txt (and the PicoLisp.java). > > OK. First I removed > >import java.nio.channels.spi.*; > > from "ersatz/sys.src", it seems indeed not necessary. > > > But I don't get the point with the messages > >The value of the local variable next is not used PicoLisp.java > /Ersatz/src line 1507 Java Problem > > because 'next' is in fact used (and needed!) in all those cases. > > How come? I cannot see one place where the value of 'next' is used (read/retrieved). Can you tell me which line? > Also, I'm not sure about those "is a raw type" messages. My Java > knowledge is rather outdated, I'm afraid. How to fix those? > > ?? Alex At the moment, I'm not sure if one should care about those "raw types". Maybe someone with more up to date Java knowledge can tell? ;-) /Jon -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Ersatz warnings in Eclipse
Hi Jon, thanks for the input! > obtain the PicoLisp.java source for the ersatz/picolisp.jar, I did > cd ersatz/ > pil mkJar + > > I then created an empty Java project in Eclipse and imported the > PicoLisp.java source. To avoid a NullPointerException when running my > project, I entered "-DPID=999" into 'VM arguments' in 'Run > Configurations'. (999 just seemed to work for now. $$ did not.) Then I > could do simple PicoLisp stuff in the Eclipse Console. ;-) Great! > However, Eclipse gave me 36 warnings. They may mean next to nothing for > the Ersatz execution. Most of the warnings (23) were "The value of the > local variable ... is not used". In case you should want to do some > cleaning up when having some spare time, I have attached a zip file > containing the (tab separated) warnings.txt (and the PicoLisp.java). OK. First I removed import java.nio.channels.spi.*; from "ersatz/sys.src", it seems indeed not necessary. But I don't get the point with the messages The value of the local variable next is not used PicoLisp.java /Ersatz/src line 1507 Java Problem because 'next' is in fact used (and needed!) in all those cases. How come? Also, I'm not sure about those "is a raw type" messages. My Java knowledge is rather outdated, I'm afraid. How to fix those? ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Ersatz warnings in Eclipse
Hi Alex, Today I got the idea that I would like to run Ersatz in Eclipse. To obtain the PicoLisp.java source for the ersatz/picolisp.jar, I did cd ersatz/ pil mkJar + I then created an empty Java project in Eclipse and imported the PicoLisp.java source. To avoid a NullPointerException when running my project, I entered "-DPID=999" into 'VM arguments' in 'Run Configurations'. (999 just seemed to work for now. $$ did not.) Then I could do simple PicoLisp stuff in the Eclipse Console. ;-) However, Eclipse gave me 36 warnings. They may mean next to nothing for the Ersatz execution. Most of the warnings (23) were "The value of the local variable ... is not used". In case you should want to do some cleaning up when having some spare time, I have attached a zip file containing the (tab separated) warnings.txt (and the PicoLisp.java). /Jon --070008000406000703070203 Content-Type: application/zip; name="ersatz-warnings.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ersatz-warnings.zip" UEsDBAoAAMt68UIQABAAZXJzYXR6LXdhcm5pbmdzL1VYDAC9muZR jZrmUfUBFABQSwMEFAAIAAgAVXnxQgAAAB0AEABlcnNhdHotd2FybmluZ3Mv UGljb0xpc3AuamF2YVVYDADHmuZR0pfmUfUBFADsfXt/20aS4P/zKWDt7piMKIaA3pZlj+3Y N96x42zsZG42452DSEiCRQI0AEqkZnyf/br6hX5Vo0nLSWYu/CUWCfSzqrq6Xl399ddRPPqw mMa76dnid19/HfXG/ehted7cpFUWvUrPhtGTabZMi0lWRU8X1UVW/e53+WxeVk30Ib1Oh4sm nw6/OtGezdLm0nyWl+aTImusR45S5NH4Mi2KbFp739Xz3Hw/TYuLYZWdT7Mx7ep3X38VPa/q tLmNvsvH5au8nkcviyar5lVG/o1635VlFb1Oi/u1LNCPvvr6d/PF2TQfR+NpWrdvor//Loqi 87xIp1HdpA0p8Kws6nKaRe+yahadRm9XdZPNhmP2tNc/sSq8baq8uHi6OD8n3b/Ki4zUKrIb 7bmr3rfpLKvn6Tijo+GV5EN/jXdVWtR5VjQh1c5WTRa9LotXWfHTe14BnpEff9+NB+S/5Aj+ 3R0p/2o/PyGN/phVdV46Wh2QioNdUs2ew2J2RuD031klp0yf9EauCbPCbyRMedkYL/vuxmg3 6btGkU/frmbwRxSmD5zoXc3Oymk0ZziaXbHfPYph9hXQ1x9EW1Bka0CxibfzTmtkMZ2Siu86 a32XT8zO+fQ4fV5kzXdVOc+qZtXb+u7lN1t9GNFXpF5n208atWkCCFLxDwG1Eke1kHq7rnrd Fd9d5rVdE552Q68qZ3PHLL9iLzrrf3N24ahMnnbWfDueqjWB6qEqedxZ9RllVHa39Hln7e8X haMuedpZ84e5XfF/Oms9rypHf+RpZ83XtQu45Gn3SIvcUZM87SbCiWu05GlnzaerzFGTPG1r YlX/a1E2mYMaPsLzbjBlzaVamfBEUndGnvp6pltQ9E02zWEv24r+2vy1+Gv11637vf7gp/f/ 5//+/dMWqyY2v7QZX7J/T5THz4tr+j/jleQbZ5T8NVlG46yuCecn/KbmpcTDOHmvleU77/dZ SsQRUuVl8SKfZrKW/hqp/Ocqb2jlN4vGVZu/F7U1mOg9EBBNXhbOzgVrzYtBNBpEjFe7dim9 V2iRDMs5ItFkuWgGkWsTs5tiCwtvKquqQZT0cRBzAIMoA1PFwSmAyUqSH2rRJ8WKcODs2bQe wN8/ZStCdVlxTf4tpmpBRnIENU+qi2v7RfTHcpadaBQ3zYpJWsEX9XlOZJvX6fLFQhvxtCRN /PA2Gw+it1k2UV+dlUQ+S4voaZWlV4PoP9PZIHqqFniaFxPy9ooRPBcH+bvrkmywszQvenL8 KRl/n8mH5AOzIYBJxaTIx7UbbyVbsO8SwGgLGiu9S0sv5kGF92jhelUHld6npT8u8iao+AEt DhJ3UPFDWpzBMKjCEa2Qg6B+TsTUoDrHtA7IlA+CyscjWoFoE1VghViMKrA8wy4QYWAFhuDz aZmGdsGwPCkJaEOnzVB9locOiuGakHIYJcUM2UW2DCOl+Ei0H1acobnK6rDmE4blSdqEUVHC kNzks8DyDMmLOguj7ITheH4zCSu+x2nuvAwrz7B7ThhzWHmG3UlehRU/FMgK41gJQ245D0QW Q+410xPDeCLD70UY9HcZdtP5fLoKq8DQOzeFaLQ8Q+8snQeW3xPlw4rvi+KB8z0Q5ad54ILZ PZRdpGFEsXska4Qi7bjtI6zG3kjQNdkSwmowVBM2VKXjsKnvMWTXWXYVVp7zayIphJVnyCaK f2D7DNvjInD4DNn1YhZWXCB6mYeV52jOi8Dyxxw69WVQ+f0R38DDSvOVHCje8K04ULzZZ4jN rtNpWHmG2GoRRsz7DK+T7DysOOfRYRx9n6F1EkYE+wypZ+UyrPgx39xvwsREhtJmNQ8b+wGX sOowsfKAYRW02jJsBR7s8hUeuGIPGGKbKowoD/b5CpwHMqmDg5ZJhVVg2L3Jm7BFdcDxG8qi DhiCP5RnYYI9Q/A0C1tXh7Eo/jisvBSuwooz7KaBcz1kyC3DUHXIcFsEt85QW4Q2zxC7DC0u 1m0ZxqEO+cItwxB1xPBa5GGtH3GhOawwF6mqMkziP9qV5eOwCnuyQhJWgaE2D2PHRwe8dGDj h7x42N5wxBB7c5kFlmeIXRTTLFBEPeZ6bxlIyMcxJ53Q8gy/4zRw1R5zntyEqmjHexxEoUrO 8T6HURNIz8d8xw3TuY4PuZ5fhgnxx1zjDVsux1yMCmQM8YijF4yygTX46r2syrBtPR4lQvBN p4GKVDxiaL4XWJrhOAy/8Ygh+N8DSx9wCE3DqCEe8SU8z8NWQDwSam9wBYbkqzx0SLEQlgMh xG1XRRpo1oi58aqeh+3UMbddzdPArT3mpqvzRRFagSH5ImsCgSosV8EwPeQmU3gVaOyKFUtl GMOOuQXrlHwCzYgjIaMHQorbsOqmCq2QCDE0tALD9m2g2SLmZqzxZSCLjLkda54GqsoxN2Rd TBeBBM5NWU2wnZLbsuZVFgqkY64NnAVW4LasUK0z5tasOlD6jneFfaP5GFiBoXk5vgw0znJz VqAZKObmrPI8TPKKuTmrLN4E12BYvs2qsL085sassggkI27KIrp8upgG4oEbs+aLQMtIzG1Z UCFMBI65KWseut64KWu8CJ0CdzxkgaS6JxxMWej65Nas8zzQ8h1ze1Y+CTNlxNyeNQ30p8Xc njUPBRG3Z12Erk5u0SJqS+CAuFHrJLA0w/BpqJeIITi0NEPvg9DiBwKUgeTDjVoElqEVuBqV B1qeYm7ZmmVNmCEm5rataXkTyN25cWsxDxWpDoT/8CbM2B8fCAdxoHcg5uat83IaKFJxA1eo ZyDm9q3xJLT8IW8/uIMjXiG4h2M+otAeuIlrPAntgRu5yByCuxAac/AsuKWLTDu4jz1RI7iP fQGp4D4EtsPncSiAG9zHkagR3MexxEdoJ0cjWSW0lyOJ9eCpHLVoD+6lxXtwLxLx4XPZl7QS 3MuBrBLcy6Gkr+BejmSV4F7keg+eizCQTcLxwm1kQMfBvSSySnAvu5L2g3vZk1WCe+GG7kAP Q8yNZaG+35ibyyBEPrDCkagQuK1xk9k4rwJjMrjNrAq0jifcYhbsU0+4wazIssCwD24tq9Li IjCQYyTsKYHmjmQkYgmuQnsQwQSBnsiE283Gl2keRhsJN5xN8yJM7U+44WxVhk5CRH2V8zC7 ZcItZ7M8TK1IuOEsnc9DnYwJt50RZSoLjlKS+leYKp9w61mVzaehAXUJN6DVTZWHqSSJMKHN Qz3tCTegVRkE/YSOi5vEp6HD4hY0Mo8wr3jCLWjj8B4Y1i+zNBDn3ILWpIEuiYSb0CCKN7CC CAULXHvcgjZNQ5kat6AFmjETbj8rgstzO2lYaW47e/gosDhD8OkosDhD7+m7wOIMuUVo6wy1 RWjrDLEPA0sztD4MhSNDaigYGU4fhTYu4r4CeSk3lM1CSZjbydKmDFwjwkyWhsY/CjsZES3C tPiEW8qmdaBtPeGmsmIxC63A2fQquMIh558XoRV46FcGvwOrCHvKLHCD4uay2SwLrSCs34HR fQm3l03yQONxwk1meTHJAgmWW83K8/NQo3zCTWfzKg/08CbcejbNiotAGT3h9rM6vw3cYrn9 LK3rMlCG5ga0tC4D8ccNaETEDZT1uAFtFuzZTg6EnzpUJj6QsSbXofHTDOM7gQzzQIQi5OeB 8ic3odVlFUhQ3IZ2XlazwBCDhFvRtgNLM0zvhJXm9rM8UHlLuPlsEhpPz41nXwWWZgj+6uvA
Re: kill without 'KILL does not work for PicoLisp processes
"interesting idea ... " Through the http server you can call any PL function, in that function you (load) stuff before doing what you need to do. >From the above it kind of follows that I use a single bootstrap/entry/routing function, so I only need to do the loads there and nowhere else. On Wed, Jul 17, 2013 at 5:23 PM, Thorsten Jolitz wrote: > Henrik Sarvell > writes: > > Hi Henrik, > > > When developing web apps I keep the code for the server and the rest > > separate and reload the rest on every request. No need for restarts at > > all that way. > > interesting idea, not sure how you actually do that, but would make > things smoother in the not so rare case of reaching a 'bad' state during > development. > > > Unless you're actually fiddling with the actual server code, then it > > can't be helped I suppose... > > I don't, so that would not be a problem. > > > On Wed, Jul 17, 2013 at 3:33 PM, Thorsten Jolitz > > wrote: > > > > > > Rowan Thorpe > > writes: > > > > >> On Wed, 17 Jul 2013 09:22:14 +0200 > > >> Thorsten Jolitz wrote: > > >> > > >> ..[snip].. I ran into this problem when experimenting with the > > >> web-framework and my app got into a bad state. When restarting > > >> then, PicoLisp tells me something like 'Port is already used', > > >> so I tried to kill the still running (*) PicoLisp processes > > >> with a simple 'kill PID', but to no avail. > > >> > > >> [* are they still running? 'ps' shows them with a '?', and I > > >> shutted them down on the command-line, so they shouldn't. But > > >> somehow they still block the port, and the more I shut down, > > >> the more are shown by 'ps'] ..[snip].. > > > > > > Sorry for asking the obvious question, but have you waited the > > > couple of minutes needed for the kernel (depending on which > > > kernel) to eventually clean orphaned ports itself? It *may* > > > actually just be the port remaining open because the owning > > > process didn't cleanly shut it?: as mentioned here > > > http://superuser.com/a/127865 > > > > > > Not obvious for me, obviously, but definitely the right question - > > no I did not wait, and I did not know I have to wait a couple of > > minutes. > > > > So thats probably the root of the problem, unrelated to PicoLisp. > > Though a bit of a hassle, since it takes away the huge advantage > > of PicoLisp's millisecond start-up time somehow, and shutting down > > a PicoLisp process and restart is not a prime option anymore if a > > couple of minutes waiting are involved. > > > > Thanks for the interesting link! > > > > > > > > -- > > cheers, > > Thorsten > > > > -- > > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > > > > > > > > -- > cheers, > Thorsten > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: kill without 'KILL does not work for PicoLisp processes
> On Wed, 17 Jul 2013 12:56:35 +0200 > Alexander Burger wrote: > > > On Wed, Jul 17, 2013 at 01:28:59PM +0300, Rowan Thorpe wrote: > > ..for such times (and for those times that you generally can't be so > > organised), there is the "sledgehammer approach" - SO_REUSEADDR > > Why "sledgehammer approach"? This is quite normal, as I see it. > > The PicoLisp network functions always set this socket option. > > ♪♫ Alex :-D I didn't mean that SO_REUSEADDR *is* a sledgehammer. I just meant that when all else fails it can be used with a decidedly sledgehammer mentality i.e. "I don't know what is killing my process and don't have time to find out right now, I just need it to start again and talk to the outside world ASAP"... -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: kill without 'KILL does not work for PicoLisp processes
On Wed, Jul 17, 2013 at 01:28:59PM +0300, Rowan Thorpe wrote: > ..for such times (and for those times that you generally can't be so > organised), there is the "sledgehammer approach" - SO_REUSEADDR Why "sledgehammer approach"? This is quite normal, as I see it. The PicoLisp network functions always set this socket option. ♪♫ Alex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: kill without 'KILL does not work for PicoLisp processes
> On Wed, 17 Jul 2013 16:14:11 +0700 > Henrik Sarvell wrote: > > When developing web apps I keep the code for the server and the rest > separate and reload the rest on every request. No need for restarts > at all that way. > > Unless you're actually fiddling with the actual server code, then it > can't be helped I suppose... ..for such times (and for those times that you generally can't be so organised), there is the "sledgehammer approach" - SO_REUSEADDR http://stackoverflow.com/questions/775638/using-so-reuseaddr-what-happens-to-previously-open-socket -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: kill without 'KILL does not work for PicoLisp processes
Henrik Sarvell writes: Hi Henrik, > When developing web apps I keep the code for the server and the rest > separate and reload the rest on every request. No need for restarts at > all that way. interesting idea, not sure how you actually do that, but would make things smoother in the not so rare case of reaching a 'bad' state during development. > Unless you're actually fiddling with the actual server code, then it > can't be helped I suppose... I don't, so that would not be a problem. > On Wed, Jul 17, 2013 at 3:33 PM, Thorsten Jolitz > wrote: > > > Rowan Thorpe > writes: > > >> On Wed, 17 Jul 2013 09:22:14 +0200 > >> Thorsten Jolitz wrote: > >> > >> ..[snip].. I ran into this problem when experimenting with the > >> web-framework and my app got into a bad state. When restarting > >> then, PicoLisp tells me something like 'Port is already used', > >> so I tried to kill the still running (*) PicoLisp processes > >> with a simple 'kill PID', but to no avail. > >> > >> [* are they still running? 'ps' shows them with a '?', and I > >> shutted them down on the command-line, so they shouldn't. But > >> somehow they still block the port, and the more I shut down, > >> the more are shown by 'ps'] ..[snip].. > > > > Sorry for asking the obvious question, but have you waited the > > couple of minutes needed for the kernel (depending on which > > kernel) to eventually clean orphaned ports itself? It *may* > > actually just be the port remaining open because the owning > > process didn't cleanly shut it?: as mentioned here > > http://superuser.com/a/127865 > > > Not obvious for me, obviously, but definitely the right question - > no I did not wait, and I did not know I have to wait a couple of > minutes. > > So thats probably the root of the problem, unrelated to PicoLisp. > Though a bit of a hassle, since it takes away the huge advantage > of PicoLisp's millisecond start-up time somehow, and shutting down > a PicoLisp process and restart is not a prime option anymore if a > couple of minutes waiting are involved. > > Thanks for the interesting link! > > > > -- > cheers, > Thorsten > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > > > -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: kill without 'KILL does not work for PicoLisp processes
When developing web apps I keep the code for the server and the rest separate and reload the rest on every request. No need for restarts at all that way. Unless you're actually fiddling with the actual server code, then it can't be helped I suppose... On Wed, Jul 17, 2013 at 3:33 PM, Thorsten Jolitz wrote: > Rowan Thorpe writes: > > >> On Wed, 17 Jul 2013 09:22:14 +0200 > >> Thorsten Jolitz wrote: > >> > >> ..[snip].. > >> I ran into this problem when experimenting with the > >> web-framework and my app got into a bad state. When restarting then, > >> PicoLisp tells me something like 'Port is already used', so I tried > >> to kill the still running (*) PicoLisp processes with a simple 'kill > >> PID', but to no avail. > >> > >> [* are they still running? 'ps' shows them with a '?', and I > >> shutted them down on the command-line, so they shouldn't. But somehow > >> they still block the port, and the more I shut down, the more are > >> shown by 'ps'] > >> ..[snip].. > > > > Sorry for asking the obvious question, but have you waited the couple of > > minutes needed for the kernel (depending on which kernel) to eventually > > clean orphaned ports itself? It *may* actually just be the port > > remaining open because the owning process didn't cleanly shut it?: as > > mentioned here http://superuser.com/a/127865 > > Not obvious for me, obviously, but definitely the right question - no I > did not wait, and I did not know I have to wait a couple of minutes. > > So thats probably the root of the problem, unrelated to PicoLisp. Though > a bit of a hassle, since it takes away the huge advantage of PicoLisp's > millisecond start-up time somehow, and shutting down a PicoLisp process > and restart is not a prime option anymore if a couple of minutes waiting > are involved. > > Thanks for the interesting link! > > -- > cheers, > Thorsten > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: kill without 'KILL does not work for PicoLisp processes
Rowan Thorpe writes: >> On Wed, 17 Jul 2013 09:22:14 +0200 >> Thorsten Jolitz wrote: >> >> ..[snip].. >> I ran into this problem when experimenting with the >> web-framework and my app got into a bad state. When restarting then, >> PicoLisp tells me something like 'Port is already used', so I tried >> to kill the still running (*) PicoLisp processes with a simple 'kill >> PID', but to no avail. >> >> [* are they still running? 'ps' shows them with a '?', and I >> shutted them down on the command-line, so they shouldn't. But somehow >> they still block the port, and the more I shut down, the more are >> shown by 'ps'] >> ..[snip].. > > Sorry for asking the obvious question, but have you waited the couple of > minutes needed for the kernel (depending on which kernel) to eventually > clean orphaned ports itself? It *may* actually just be the port > remaining open because the owning process didn't cleanly shut it?: as > mentioned here http://superuser.com/a/127865 Not obvious for me, obviously, but definitely the right question - no I did not wait, and I did not know I have to wait a couple of minutes. So thats probably the root of the problem, unrelated to PicoLisp. Though a bit of a hassle, since it takes away the huge advantage of PicoLisp's millisecond start-up time somehow, and shutting down a PicoLisp process and restart is not a prime option anymore if a couple of minutes waiting are involved. Thanks for the interesting link! -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: kill without 'KILL does not work for PicoLisp processes
> On Wed, 17 Jul 2013 09:22:14 +0200 > Thorsten Jolitz wrote: > > ..[snip].. > I ran into this problem when experimenting with the > web-framework and my app got into a bad state. When restarting then, > PicoLisp tells me something like 'Port is already used', so I tried > to kill the still running (*) PicoLisp processes with a simple 'kill > PID', but to no avail. > > [* are they still running? 'ps' shows them with a '?', and I > shutted them down on the command-line, so they shouldn't. But somehow > they still block the port, and the more I shut down, the more are > shown by 'ps'] > ..[snip].. Sorry for asking the obvious question, but have you waited the couple of minutes needed for the kernel (depending on which kernel) to eventually clean orphaned ports itself? It *may* actually just be the port remaining open because the owning process didn't cleanly shut it?: as mentioned here http://superuser.com/a/127865 -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: kill without 'KILL does not work for PicoLisp processes
Alexander Burger writes: Hi Alex, >> is it "normal" that a simple 'kill' won't kill PicoLisp processes, only >> with option 'KILL it works? > > No. > > A "normal" kill with SIGTERM (i.e. -15) should work. > > SIGKILL (i.e. -9) should be used only in extreme emergencies, because it > may cause the loss of data (resulting in a corrupted database in the > worst case)! > > > Usually a > >$ killall picolisp > > or > >$ killall pil > > should do. > > > It should be noted, however, that PicoLisp catches some signals: > >1. SIGPIPE, SIGTTIN and SIGTTOU are ignored. > >2. SIGIO is caught and handled in the 'sigio' function handler. > >3. SIGHUP is caught and handled in the '*Hup' global. > >4. SIGUSR1 and SIGUSR2 are handled in the '*Sig1' and '*Sig2' > globals. > >5. SIGALRM is used for the 'alarm' and 'abort' functions. > >6. SIGCHLD is handled internally for the management of child > processes. > >7. SIGINT is caught only in the REPL, and causes a console break. A > process running without a REPL is terminated. > >8. SIGTSTP is used in the REPL to suspend the forground PicoLisp > process. > > > The "normal" (default) signal SIGTERM causes the termination of the > running PicoLisp process with 'bye'. > > BUT: >1. If that process has still running child processes, it sends > SIGTERM recursively to all children first, and waits for them to > terminate. Then it terminates itself. > >2. During certain phases of program execution, the PicoLisp > interpreter blocks this and/or other signals. This may be in a > 'protect'ed code block, or during critical database operations. > This will only delay the handing of those interrupts (not ignore > them). > > I hope I didn't forget anything :) Guess not, that reads like an exhaustive treatment ;) Thanks for the info. I ran into this problem when experimenting with the web-framework and my app got into a bad state. When restarting then, PicoLisp tells me something like 'Port is already used', so I tried to kill the still running (*) PicoLisp processes with a simple 'kill PID', but to no avail. [* are they still running? 'ps' shows them with a '?', and I shutted them down on the command-line, so they shouldn't. But somehow they still block the port, and the more I shut down, the more are shown by 'ps'] May that be because things went wrong during debugging when some database operation failed? I have no idea ... -- cheers, Thorsten -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
