ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Picolisp latest found at http://www.software-lab.de/down.html | check also http://www.picolisp.com for more information
gfdsm has quit [Ping timeout: 276 seconds]
karswell_ has quit [Read error: Connection reset by peer]
karswell_ has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
rob_w has joined #picolisp
karswell_ has quit [Remote host closed the connection]
karswell_ has joined #picolisp
<tankf33der> kernel 2.6 failed too
<tankf33der> owl linux with atomic
<tankf33der> but this works everywhere
mtsd has joined #picolisp
<Regenaxer> yeah, coroutines need no locking and syncing
<Regenaxer> But what's wrong with the other one
<tankf33der> but inc!> do the same sync-release
<Regenaxer> yes, but there is no other process to wait for?
<Regenaxer> Perhaps the other creates a deadlock somewhere?
<tankf33der> how it works on kernel 4.16 :/
<Regenaxer> no idea
<Regenaxer> I see one problem with the other one
<tankf33der> where?
<Regenaxer> might explain why it takes so long sometimes
<Regenaxer> It does (dbSync) and then (collect 'key '+Bucket)
<Regenaxer> collect is expensive
<tankf33der> ok
<Regenaxer> fetches all objects while the db is locked
<Regenaxer> You don't need (dbSync) and (rollback) here
<Regenaxer> it just *read*s the database
<tankf33der> on 4.16 it prints line every 2sec for hours
<Regenaxer> Sync is only needed for modifications
<tankf33der> T
<Regenaxer> I took them out, now it is blinding fast!
<Regenaxer> Always zero seconds :)
<tankf33der> i tried it yesterday, will try again
<Regenaxer> You tried without dbSync?
<tankf33der> iirc it still didnt print lines
<Regenaxer> Strange
<tankf33der> and it should be fast, third process wait 2sec on every loop
<tankf33der> shouldnt
<Regenaxer> true
<tankf33der> rosetta has different version of it
<Regenaxer> What is different?
<tankf33der> function process
<tankf33der> vs.
<tankf33der> unless (fork)
<Regenaxer> Strange! Seems I wrote that, but I don't remember at all!
<tankf33der> atomic.l is copy from you rosettacode.l file
<tankf33der> both yours
<Regenaxer> This line is missing:
<Regenaxer> (call 'rm "-f" "buckets.db") # Remove old DB (if any)
<Regenaxer> So it creates more and more objects
<Regenaxer> I have here what I wrote in rosetta back then
<Regenaxer> It is identical, just the (call 'rm "-f" "buckets.db")
<tankf33der> i modify it to pool-tmp
<Regenaxer> Ah, ok!
<beneroth> pool tmp is nice
<Regenaxer> yes, this is good
<Regenaxer> But I really wonder why I put (dbSync) around the printing
<Regenaxer> Perhaps to get the whole DB locked
<beneroth> but (seed (usec)) is probably better than (seed *Pid), no? because *Pid might be guessable (with OS access)
<Regenaxer> So that a consistent state is read
<Regenaxer> makes sense
<Regenaxer> Otherwise the data are modified while the list is read
<Regenaxer> and the sum may differ
<Regenaxer> Hi beneroth
<Regenaxer> yes, but this is not a security issue here
<beneroth> hi Regenaxer, hello tankf33der :)
<beneroth> T
<tankf33der> seed is not problem
<Regenaxer> Just for the test data
<tankf33der> problem why it doesnt print lines
<tankf33der> or prints with 20min gap
<Regenaxer> Here it prints
<beneroth> whats best practice for read transactions? (dbSync) + (rollback) ? but rollback wipes, not desired in every case. (dbSync) + (commit) might also be suboptimal, no?
<beneroth> (I'm off-topic)
<Regenaxer> might be fine, as no data are modified
<Regenaxer> Except here I *never* locked before reading
<beneroth> reading a single external symbol is atomic, no? or only reading a single block?
<Regenaxer> no, the whole symbol, all its blocks
<beneroth> ok, thx.
<beneroth> then I got it right.
<Regenaxer> What I don't understand now is why it does not wait for 2000 msec
<Regenaxer> How can that be?
karswell_ has quit [Remote host closed the connection]
karswell_ has joined #picolisp
<Regenaxer> afp
<Regenaxer> ret
<Regenaxer> Hmm, something must be wrong
<Regenaxer> I reduced it to:
<Regenaxer> (pool (tmp "db"))
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (dbSync)
<Regenaxer> (commit 'upd) ) )
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (println (inc (0)))
<Regenaxer> (wait 2000) ) )
<Regenaxer> (wait)
<Regenaxer>
<Regenaxer> And: The (wait 2000) does *not* wait!
<Regenaxer> On Intel/AMD
<Regenaxer> On Arm64 Android it waits
<Regenaxer> f***
<Regenaxer> If I remove the 'upd it waits
<Regenaxer> So the wait seems interrupted by the IPC
<tankf33der> and i reduce it to this
<Regenaxer> The (dbSync) can also be removed
<Regenaxer> (pool (tmp "db"))
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (commit 'upd) ) )
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (println (inc (0)))
<Regenaxer> (wait 2000) ) )
<Regenaxer> (wait)
<tankf33der> if comment wait 1000 it becomes crazy
<Regenaxer> hmm
<Regenaxer> As I say, it seems the (wait 2000) stops waiting
<Regenaxer> when a 'tell' message arrives
<tankf33der> something like that.
<Regenaxer> Or even this:
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (tell '+ 3 4) ) )
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (println (inc (0)))
<Regenaxer> (wait 2000) ) )
<Regenaxer> (wait)
<Regenaxer> It is definitely tell -> wait
<Regenaxer> (commit 'upd) triggers a 'tell' to all other processes
<Regenaxer> But why only x86 ?
<Regenaxer> I try ppc64 too
<Regenaxer> and arm64 on qemu too
<tankf33der> last code prints digit every 2sec
<tankf33der> what you see?
<tankf33der> fallen digits ?
<Regenaxer> very fast incrementing
<tankf33der> no
<tankf33der> not here
<Regenaxer> does not wait 2 secs
<tankf33der> wait here
<tankf33der> :/
<Regenaxer> So it is not the CPU
<Regenaxer> hmm
<tankf33der> kernel 2.6 wait 2secs
<tankf33der> archlinux 4.16 dont wait
<Regenaxer> Arm64 on qemu is also too fast
<Regenaxer> I can't think it is the kernel
<Regenaxer> but also not CPU
<tankf33der> cygwin waits.
<Regenaxer> Seems I have to debug this :(
<Regenaxer> tankf33der, good that you found that!
<tankf33der> openbsd wait.
<tankf33der> Regenaxer: :)
<beneroth> sincerely thanks to you two
<tankf33der> hpux, parisc wait!
<Regenaxer> hmm
<Regenaxer> So it cannot be the pure logic on the asm level
<tankf33der> it prints digits out of pil
<Regenaxer> I tried 3 Intel machines with Debian and they all don't wait
<Regenaxer> Debian/Arm64 in qemu also does not wait
<Regenaxer> So for me it looks like all Debian systems don't wait
<tankf33der> and centos
<tankf33der> ooops
<tankf33der> and archlinux 4.16
<Regenaxer> they all don't wait?
<tankf33der> they print out of pil!
<Regenaxer> All Linux? But Android is Linux too
<Regenaxer> print out of pil?
<tankf33der> this is centos
<tankf33der> pil32
<tankf33der> pil64 waits on centos
<tankf33der> the same pil32 on hpux
<tankf33der> cant repeat on pil64 on centos
<tankf33der> if i close pil, forks killed.
<Regenaxer> yes, this is correct, if parent terminates it sends kill to children
<tankf33der> its no
<tankf33der> its not on pil32
<tankf33der> i kill it manually
<Regenaxer> Perhaps it takes time?
<Regenaxer> The first loop is extremely busy
<Regenaxer> btw, a better use case is
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (println (- (time) (swap (0) (time))) (inc (0)))
<Regenaxer> (wait 2000) ) )
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (tell '+ 3 4) ) )
<Regenaxer> (wait)
<Regenaxer> cause the second loop creates very many tell's
<tankf33der> its not busy, os must kill it immediatly
<Regenaxer> better if the first one is already running then perhaps
<Regenaxer> How do you mean that?
<tankf33der> when i close pil, forks must be killed
<tankf33der> i assume this
<tankf33der> right?
<Regenaxer> no
<tankf33der> hm
<Regenaxer> The parent kills the children
<Regenaxer> waits for them
<tankf33der> ok
<tankf33der> so
<Regenaxer> But the tell loop is very busy
<tankf33der> centos 3.10 kernel, both pils wait.
<Regenaxer> can be seen with 'top'
<Regenaxer> hmm
<Regenaxer> This version works:
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (println (- (time) (swap (0) (time))) (inc (0)))
<Regenaxer> (wait 2000) ) )
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (wait 200)
<Regenaxer> (tell '+ 3 4) ) )
<Regenaxer> (wait)
<Regenaxer> The problem must be too many tell's
<tankf33der> archlinux, kernel 4.16, both pils dont wait.
<Regenaxer> They queue up in the parent
<beneroth> buffer size?
<beneroth> size vs number of messages ?
<Regenaxer> even this works:
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (println (- (time) (swap (0) (time))) (inc (0)))
<Regenaxer> (wait 2000) ) )
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (wait 20)
<Regenaxer> (tell '+ 3 4) ) )
<Regenaxer> (wait)
<Regenaxer> Not the buffer size
<Regenaxer> the kernel increases the buffer
<Regenaxer> it grows
<Regenaxer> But it should deliver all messages in the (wait 2000)
<tankf33der> above centos and archlinux both pils waits!
<tankf33der> centos selinux disabled.
<Regenaxer> I think it is not a matter of the OS
<Regenaxer> or CPU
<Regenaxer> It is some race condition
<Regenaxer> One process sending very rapidly messages
<Regenaxer> What happens with the parent and the other child then?
<Regenaxer> Seems I must look at the asm sources to see where it might go wrong
<Regenaxer> tankf33der: pil32 was *always* correct?
<tankf33der> for what versions
<tankf33der> first or second ?
<Regenaxer> it differs?
<tankf33der> yeap
<tankf33der> 12:18 <tankf33der> archlinux, kernel 4.16, both pils dont wait.
<tankf33der> for first version
<Regenaxer> I mean without (wait 20)
<Regenaxer> ah
<tankf33der> first
<Regenaxer> both means 32 and 64
<tankf33der> second ^^^^
<tankf33der> first version on centos both pils wait
<tankf33der> first version on archlinux both pils dont wait
<Regenaxer> hmm
<tankf33der> second version centos and archlinux both pils waits!
<Regenaxer> so it is a heisenbug (race condition)
<tankf33der> first version works on cygwin, hpux, openbsd-pil64
<Regenaxer> ok, thanks
<Regenaxer> Perhaps this is not even a bug
<Regenaxer> This works too:
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (println (- (time) (swap (0) (time))) (inc (0)))
<Regenaxer> (wait 2000) ) )
<Regenaxer> (unless (fork)
<Regenaxer> (loop
<Regenaxer> (wait 1)
<Regenaxer> (tell '+ 3 4) ) )
<Regenaxer> (wait)
<tankf33der> let me check then
<tankf33der> will be loop-tell-wait-v3.l
<Regenaxer> here it is just 'z'
<Regenaxer> always modified
<Regenaxer> I have 3 aliase on all my machines:
<Regenaxer> alias x='./pil x +'
<Regenaxer> alias y='./pil y +'
<Regenaxer> alias z='./pil z +'
<Regenaxer> So I just type 'x' or 'z' in bash :)
<tankf33der> centos and archlinux both pils waits on -v3.l file
<Regenaxer> means they work correct?
<tankf33der> just waits
<tankf33der> waits = 2 secs
<Regenaxer> ok
<Regenaxer> So what we know is: One process keeps IPC and the parent very busy
<Regenaxer> Still I don't understand why the wait does not wait
<Regenaxer> I must receive some event
<Regenaxer> an error perhaps?
<tankf33der> unknown
<tankf33der> maybe richard stevens knowns ? :/
<Regenaxer> no, in pil
<Regenaxer> Some pipe error or so which is not correctly handled
<tankf33der> pil64 only?
<tankf33der> right
<Regenaxer> You said you saw in pil32 too
<tankf33der> yea, archlinux
<Regenaxer> Both should have the same logic here
<tankf33der> ok
<Regenaxer> ok
<tankf33der> maybe it possible repeat on raw C first ?
<Regenaxer> How? Stand-alone C program?
<tankf33der> yea
<Regenaxer> it needs all IPC from pil
<Regenaxer> long waitFd(any ex, int fd, long ms)
<Regenaxer> this function and a lot of related funs
<Regenaxer> So quite a big job ;)
<Regenaxer> I think I found it
<tankf33der> :)
<Regenaxer> Not happy
<tankf33der> its ok
<Regenaxer> nope
<tankf33der> what you found ?
<Regenaxer> hard to explain
<tankf33der> is patch ready ?
<Regenaxer> haha! I don't even know what to do yet
<tankf33der> but you found it
<Regenaxer> It is the select() system call
<Regenaxer> well ...
<Regenaxer> man 2 select
<Regenaxer> it says in Linux: "On Linux, select() modifies timeout to reflect the amount of time not slept"
<Regenaxer> I'm using this value
<Regenaxer> ever since, in pil32 and pil64
<Regenaxer> But it seems not correct
<Regenaxer> too big
<Regenaxer> 600 msec
<Regenaxer> if the processes are very busy
<Regenaxer> So the 2000 ms are very quickly gone
<Regenaxer> decremented a few thousand times per second with too high values
<Regenaxer> in @src64/io.l is:
<Regenaxer> ? (= *TargetOS "Linux") # Linux?
<Regenaxer> ld A (L -V) # Seconds not slept
<Regenaxer> ld E A
<Regenaxer> mul 1000 # Calculate milliseconds
<Regenaxer> div 1000 # Calculate milliseconds
<Regenaxer> ld A (L -IV) # Microseconds not slept
<Regenaxer> add A E # Milliseconds not slept
<tankf33der> eh
<Regenaxer> in pil32 :
<Regenaxer> #ifdef __linux__
<Regenaxer> t -= tv.tv_sec*1000 + tv.tv_usec/1000;
<Regenaxer> #else
<Regenaxer> That's why it works on Android!
<Regenaxer> *TargetOS is not "Linux" but "Android"
<Regenaxer> So this value seems too high:
<Regenaxer> ld A (L -IV) # Microseconds not slept
<Regenaxer> If I force it to the non-Linux select() behavior, the sleep times are much longer
<Regenaxer> 3 or 4 secs
<Regenaxer> 50088 1
<Regenaxer> 3 4
<Regenaxer> 4 2
<Regenaxer> 4 3
<Regenaxer> 4 5
<Regenaxer> 4 6
<Regenaxer> 4 7
<Regenaxer> 3 8
<Regenaxer> because the process is so busy processing the stream of 'tell' messages
<tankf33der> hm
<Regenaxer> Depends on things like how many cores perhaps
<Regenaxer> This code example is kind of extreme, normally not happening in real world
<Regenaxer> But it shows the problem
<Regenaxer> OK, so I better abandon this special Linux behavior
<Regenaxer> I always thought it is a big advantage, as it avoids two time system calls per select() call
<Regenaxer> But if it is soooo inaccurate ...:(
karswell_ has quit [Remote host closed the connection]
karswell_ has joined #picolisp
<tankf33der> i will test different linuxes when released
<Regenaxer> *If* I change it this way, then all OSes are the same
<Regenaxer> at the moment only Linux is treated specially
<tankf33der> thats why i will test only linuxes
<Regenaxer> yeah
<Regenaxer> OK, did it
<Regenaxer> I hope this is a good idea
<Regenaxer> Changed also in pil32, can you check that too? (I have no 32~bit system corrintly)
<tankf33der> i will check
<Regenaxer> Thanks!
<Regenaxer> Here all seems to work so far
<Regenaxer> both on Android and Debian
<beneroth> interesting. deep issue.
<Regenaxer> indeed
<Regenaxer> it is an extreme case
<beneroth> thanks Regenaxer for looking into this :) you are so quick!
<Regenaxer> total stress test for pil ipc
<Regenaxer> I'm a bit unhappy
<beneroth> so whats the bad taste of the change?
<beneroth> overhead, extra calls?
<Regenaxer> I thought this was a good feature of select() in Linux
<Regenaxer> yes, to gettimeofday calls needed
<Regenaxer> for each select
<beneroth> how is this feature then used normally, if one can't trust it the way you used it, I wonder...
<Regenaxer> But most surprising is that the returned values are too high
<beneroth> underflow?
<Regenaxer> Not sure
<Regenaxer> The difference of two gettimeofday calls is fine
<Regenaxer> I think in this test case select() *never* slept at all
<Regenaxer> because the other process was bombarding it with so many messages
<Regenaxer> but it did not return zero
<Regenaxer> or near zero
<tankf33der> what about atomic.l now
<tankf33der> both archlinux and centos doesnt print
<tankf33der> as i remember some of them print yesterday
<Regenaxer> hmm, another problem then?
<Regenaxer> On Debian, if (dbSync) is commented, it works
<beneroth> On Linux, select() also modifies timeout if the call is interrupted by a signal handler (i.e., the EINTR error return). This is not permitted by POSIX.1-2001. The Linux pselect() system call has the same behavior, but the glibc wrapper hides this behavior by internally copying the timeout to a local variable and passing that variable to the system call.
<tankf33der> 09:57 <tankf33der> archlinux pil32 and pil64 works
<tankf33der> 09:57 <tankf33der> centos 7 pil32 and pil64 no output.
<Regenaxer> if not, it prints only one line
<tankf33der> it was yesterday
<tankf33der> so now no printing at all
<tankf33der> both centos and archlinux
<Regenaxer> I think we must put (wait 1) into the tasks
<Regenaxer> otherwise the IPC gets overloaded
<tankf33der> no output
<Regenaxer> Can you change the rosettacode solution to this?
<tankf33der> ah this one
<Regenaxer> I inserted 2 (wait 1)s
<tankf33der> done
<tankf33der> all works
<Regenaxer> Cool!
<Regenaxer> But centos and archlinux have no output?
<tankf33der> testing rest linuxes
<tankf33der> now have
<tankf33der> every two secs
<tankf33der> as should be
<Regenaxer> with (wait 1) ?
<tankf33der> with two (wait 1)
<Regenaxer> ok
<tankf33der> i will update rosettacode too
<Regenaxer> Thanks!!
<tankf33der> actually replace.
<Regenaxer> yeah, also with tmp ?
<Regenaxer> ah, I have without tmp
<Regenaxer> Please change to your (tmp ..) version
<tankf33der> ok
<tankf33der> testing first
<Regenaxer> good
mtsd has quit [Remote host closed the connection]
<tankf33der> Regenaxer:
<tankf33der> updated too, automagically ?
<Regenaxer> yes, built each time I make a release
<tankf33der> ok
<tankf33der> all tested, issue closed.
<tankf33der> test report
<Regenaxer> Perfect! Thanks :)
<tankf33der> beneroth: todays diff:
rob_w has quit [Remote host closed the connection]
<beneroth> tankf33der, nice
<tankf33der> openbsd both pils works too.
<tankf33der> i'm finished.
<beneroth> thanks tankf33der !
sriram has joined #picolisp
<sriram> I was trying to run "A minimal example" code from https://picolisp.com/wiki/?canvasDrawing
<sriram> but get a blank screen
<sriram> ./pil draw2Rects.l +
<beneroth> you got httpGate running?
<beneroth> as mentioned in the note at the end of the example?
<sriram> i never have httpgate running ...just connect directly to 8080
<sriram> oh sorry did not see
<beneroth> httpGate should be in the bin/ dir within picolisp dir
<sriram> i dont seem to have it...must build it i think
<beneroth> if it isn't, you need to build it first: cd src; make all;
<beneroth> yeah
<beneroth> it is C code.
<sriram> thanks a lot! will build and run and update
<sriram> you with result :)
<beneroth> you're welcome :) good luck and have fun :)
<sriram> thanks! :)
<Regenaxer> It is just (cd src; make gate)
<Regenaxer> not all, as it would overwrite ../bin/picolisp
<Regenaxer> Hi sriram! :)
<Regenaxer> And you do not need httpGate just to test it locally
<Regenaxer> only pil misc/canvas.l -main -go +
<Regenaxer> then browser on localhost:8080
<Regenaxer> Hmm, so the text in the wiki is wrong
<Regenaxer> Should better be "Then point your browser to http://localhost:8080" :)
<Regenaxer> I fix it
orivej has joined #picolisp
alexshendi has joined #picolisp
<Regenaxer> done :)
<Regenaxer> Srini, what do you think? Would it make sense if I include lib/pdfPage.l and misc/pdfPage.l into the standard PicoLisp distribution?
<Regenaxer> Or is it too specialized?
<tankf33der> of course include
<tankf33der> like stress.l
<Regenaxer> OK, I do
<Regenaxer> I wanted to hear sriram's opinion, as he delved deeply into it :)
* beneroth votes for include, too
<sriram> hi Regenaxer...I think it would be useful
<sriram> by the way no go function in the minimal canvas application
<beneroth> what could be bad about including it? unless it's something very specific (as maybe dBase.l is by todays standards - you excluded it a while ago)
<sriram> Yes...I have delved rather deeply :)
<tankf33der> like misc/rcsim.l
<Regenaxer> OK, thanks to all! I include them now
<beneroth> thanks to you for providing it!
<sriram> but that notwithstanding, I think there are some very nice and useful learning points in that code..so useful to include
<Regenaxer> Well, a 'go' function is quasi-standard, yes
<sriram> (beneroth ...thanks...i finally built httpgate, I did not build earlier because I had compile issues, but after downloading a few devel.i686 packages I built it...same issue thouh)
<sriram> yes.. I did wrap the server call in go() but that did not change the outcome
<Regenaxer> JS enabled in browser?
<Regenaxer> btw, released with 2 new files
<beneroth> which browser? you can probably open an web developer console in the browser by pressing F12. Maybe you see any error messages from the browser there in the JS console?
<sriram> hmm..checking for js
<sriram> beneroth..chrome
<Regenaxer> Ah! I know!
<Regenaxer> Sorry, does indeed not work with 8080
<Regenaxer> Because of "same server policy"
<sriram> js is allowed
<sriram> ah so do i need httpgate then?
<Regenaxer> Let me write a fix
<Regenaxer> no
<Regenaxer> A also have no httpGate on my tablet
<beneroth> sriram, Regenaxer develops solely on his Android tablet, this days ^^
<Regenaxer> Needs a redirect so that JS starts in the same session
<Regenaxer> Moment
<beneroth> that solution is nicer generally anyway
<sriram> beneroth....that seems a great way! can do anywhere then....traveling etc
<Regenaxer> works here now
<sriram> i must learn two things to do that acceptably ...1. penti 2. vip
<Regenaxer> I update the wiki
<sriram> thanks..i will watch it
<beneroth> yeah I already use penti for writting emails on the tablet. but not proficient enough for doing coding, not trying much recently though (no reason, just not enough time for it now)
<Regenaxer> I fixed the wiki minimal example
<sriram> yes, it is quite amazing thatthe test and the fix and the wiki update all done through tablet..... proof of concept that it is possible efficiently :)
<Regenaxer> The larger example should be fine, as it works after a button press
<sriram> thanks Regenaxer, I will pick it up and retry
<Regenaxer> ok :)
<Regenaxer> I did not notice, cause when I wrote this article I did on my notebook (in ancient times ;) which has httpGate
<sriram> works perfectly now...thanks
<Regenaxer> :)
<Regenaxer> Sorry, must go now. Back very late
<sriram> thanks again :) will continue with it now...
<Regenaxer> ok :)
<Regenaxer> bye
<sriram> bye
<beneroth> have a good evening Regenaxer :)
<tankf33der> Regenaxer: sent mail, check when return.
clacke[m] has quit [Remote host closed the connection]
fwirt[m] has quit [Remote host closed the connection]
alexshendi has quit [Read error: Connection reset by peer]
fwirt[m] has joined #picolisp
clacke[m] has joined #picolisp
grp has joined #picolisp
orivej has quit [Remote host closed the connection]
orivej has joined #picolisp
beneroth has quit [Ping timeout: 264 seconds]
beneroth has joined #picolisp
<Regenaxer> ret
<beneroth> welcome back :)
<Regenaxer> :)
<Regenaxer> Was at the airport. Heavy thunderstorms all the way, and traffic jam because everybody panics
<beneroth> floods, too?
<beneroth> here its raining now. but not really a thunderstorm
<beneroth> we've got here a bit sun and rain every afternoon
<Regenaxer> The autobahn was not flooded, but a few cm water in some places
<Regenaxer> The last weeks vere fine, above 30 C each day and a small thunderstorm in the evenings, so not too dry
<Regenaxer> Tomorrow supposed to be hot again
<beneroth> I prefer the cooler temperatures. running around in shorts already.
<beneroth> I like the rain, cleans the air :)
<beneroth> less pollen in the air then
<Regenaxer> Very true
karswell_ has quit [Read error: No route to host]
alexshendi has joined #picolisp
clacke[m] has quit [Remote host closed the connection]
fwirt[m] has quit [Remote host closed the connection]
fwirt[m] has joined #picolisp
clacke[m] has joined #picolisp
grp has quit [Quit: box shutting down...]
fwirt[m] has quit [Remote host closed the connection]
clacke[m] has quit [Remote host closed the connection]
fwirt[m] has joined #picolisp
clacke[m] has joined #picolisp