<wpwrak>
Joerg-Neo900: on KEYIRQ (keyboard matrix controller). the output is open-drain, so it needs a pull-up. but we can provide that in the CPU (like we do all over the place, too), don't need a chip resistor for it.
<Joerg-Neo900>
ack
<wpwrak>
and it was in git ... and i removed it now :)
<Joerg-Neo900>
in eeshow page numbers are on that terribly useful anymore ;-)
<wpwrak>
the new caps are C1115 and C1116 near U1114 on sheet 11 (audio headset, eci)
<Joerg-Neo900>
please fix slew rate: move R1410 to left side of R1412
chomwitt has quit [Quit: WeeChat 1.0.1]
<wpwrak>
(terribly useful) eeshow has sheet numbers on the (eeshow-generated) index page. if yours doens't, please update :)
<Joerg-Neo900>
that doesn't help
<wpwrak>
(i added them a few weeks ago after noticing that i was slowly going mad having to guess sheet numbers :)
<Joerg-Neo900>
you neother can search for them, nor enter the page number anywhere to jump
<wpwrak>
true, but you can see it quickly on the index page. probably just as fast
<Joerg-Neo900>
only way to use page numbers is manual counting
<Joerg-Neo900>
no, I don't see page numbers there
<wpwrak>
then you may have to cd /wherever/eeshow; git pull; make; make install
<Joerg-Neo900>
there used to be page numbers in my free text labels, but they're gone. there also used to be page numbers in sheet filenames
<wpwrak>
yes, the ones in the file names are gone. i didn't remove anything from the text labels.
<Joerg-Neo900>
not recently, yes
<wpwrak>
(move R1410) 1% :) okay, moving ...
<Joerg-Neo900>
this was very initial thing
<Joerg-Neo900>
might even be me who removed those #14 etc
<Joerg-Neo900>
ummm, *could* eeshow learn a new trick? --skew N to load only every N'th old git version
jonsger has quit [Ping timeout: 250 seconds]
<Joerg-Neo900>
in a repo with 1,2,3...10 -N 3 would load 8,9,10 while -N3 --skew 2 would load 6,8,10
<wpwrak>
that would be kinda messy since it optimizes away some commits
<Joerg-Neo900>
how would I load 2,3,4 ?
<wpwrak>
not even sure you can :) but maybe git checkout HEAD~1; make view would do that
<wpwrak>
but ... don't do this
<wpwrak>
you're likely to get lots with that detached head
<Joerg-Neo900>
hmmmm
<wpwrak>
lost, even
<Joerg-Neo900>
I prolly need a new motherboard that allows for 256GB RAM
<wpwrak>
;-))
<Joerg-Neo900>
I might try to hack that stuff into eeshow
<Joerg-Neo900>
can't be too hard to make loading of git versions conditional
<wpwrak>
you could increase the number of commits to 50 or such if this is really an issue. normally, 30 should be plenty. i mean, now there's rarely more than 5 in a day. so you get easily one week.
<Joerg-Neo900>
I would need to increase it to errr 3000 I guess
<Joerg-Neo900>
I'm interested in more than one week
<wpwrak>
there are only 837 commits in the history :)
<Joerg-Neo900>
and my machine explodes halfway to there
<wpwrak>
heh :)
<wpwrak>
well, at some point you may indeed need a bigger iron. eeshow does get greedy if you do seriously heavy stuff. alas, nothing that would be easily fixed. may very well be inside libgit2. so one would have to trace it carefully, see if there's anything that can be done on the libgit2 side, then fix it there (or convince the author(s))
<Joerg-Neo900>
no, at some point I need to figure how to actually make *use* of git
<Joerg-Neo900>
and eeshow
<wpwrak>
hehe :) that could be an option, too
<Joerg-Neo900>
it's half pointless when you can't load an arbitrary legacy version and its ancestors
<Joerg-Neo900>
O always assumed there was an option to specify the precise version with the filename
<Joerg-Neo900>
I*
<wpwrak>
dunno. normally use it for recent stuff. i.e., 1) what are the changes i'm about to commit ?, and 2) what has ahycka done yesterday ? all that is "shallow" history. if you go very deep it's usually for forensics, i.e. tracking down why some bad mistake happened. generally, we don't have a lot of these :)
<Joerg-Neo900>
generally I just wondered how the heck I'd find out if it was me who removed the #14 in pagenames, despite of all the preeety git histroy we got
<wpwrak>
(version) hmm, you could use eeplot <commit>:neo900.pro -o neo900.pdf && evince neo900.pdf
<wpwrak>
where you pick <commit> from git log, gitk, tig, or such
<Joerg-Neo900>
>>2016-07-25 23:23 Joerg Reisenweber o─┘ DRAFT neo900.sch index sheet: resized and beautified sheetsymbols, moved *SS_1.sch content to this page. Removed sheet_1 in sourcecode sheets sequence<<
<wpwrak>
(numbers) yes, that would be "forensics" :)
<Joerg-Neo900>
alas that's all I can find out, thanks tig
<Joerg-Neo900>
I'm not interested if the name is "forensics"
<Joerg-Neo900>
I call it "help me out on coping with alzheimer"
<Joerg-Neo900>
;-)
<wpwrak>
;-))
<wpwrak>
anyway, i'm pretty sure i didn't make changes of this sort. i left the first sheet to you to design, and only rearranged it a little (without affecting the overall style) when deleting/combining all the unused or near-empty sheets
<wpwrak>
yes, but for some reason this doesn't work
<wpwrak>
and i think that got broken a while ago, and be difficult to bring back. but i'll put giving it a closer look on my to do list.
<wpwrak>
anyway, if you use the eeshow-generated index (with the little thumbnails), you have sheet numbers there
<wpwrak>
after a short while you'll get good at recognizing the sheets by their thumbnails, too. especially now that there are fewer of them, with more "dense" content.
<wpwrak>
(rev) could be HEAD or HEAD~N (e.g., HEAD~1 for one commit ago, HEAD~2 for two commits ago, etc.). could be the commit hash (the long hex string). to see the commit hash in tig, hit [Enter] on the commit you want. then it's shown as something like "commit 21e500b88912b5eccb2b99614f7822fb42d5620b" in boldface
<wpwrak>
(or use git log , gitk , etc. countless choices :)
<Oksana>
wpwrak: Are there any 3D scans (STL files) for N900 backcover?..
<wpwrak>
(pango) hmm, if you had an up to date library, this wouldn't happen :) lemme see if a different syntax works better ....
<wpwrak>
Oksana: no, i didn't scan that
<Oksana>
Hmm, just wondering... Camera lens cover is falling apart, blue layer unglued for black, and hence spring loose. 3D scans would not help with that, but I was wondering about designing rotary camera lens cover like https://www.amazon.com/Holga-400100-Lens-Case-iPhone/dp/B0078X0H7S
<wpwrak>
Joerg-Neo900: i changed the syntax from background="#00e00080" to background="#00e000" bgalpha="50%" which may or may not be more compatible with your version of libpango
<Joerg-Neo900>
-N20 is obviously cruft
<Oksana>
Fitting rotary camera lens cover would be a geometrical challenge. Not sure how many lenses (between 4 and 8), but backstand would most likely no longer wrap around the camera (more like, moved to a different part of backcover, if exist at all)
<Joerg-Neo900>
the idea is smart, the lenses pointless (could all get done in software) - a few decent tele and fisheye lenses would make real sense though
<Oksana>
Whatever they did to attach backstand to backcover, is very solid work. And silver wrap around is not just decoration, it stops lens cover from falling off, and it probably minimises light leakage? And special shape of black backcover to protect silver wraparound, in turn, from being torn away.
<wpwrak>
(eeshow ...) very old :) and that syntax doesn't even work anymore here. hmm ...
<Joerg-Neo900>
((-N20 is obviously cruf)) **alas**
<Joerg-Neo900>
-rwxr-xr-x 1 root root 513383 14. Nov 19:48 /usr/local/bin/eeshow*
<wpwrak>
Joerg-Neo900: yes, but the whole rev:file doesn't work in my eeshow. seems that working around the problem ceene ran into caused that. lemme see ...
knttl has quit [Ping timeout: 256 seconds]
<Joerg-Neo900>
*maybe* you could look onto -N feature for rev:file when you're at it? maybe it's not that hard to make it work too?
knttl has joined #neo900
<Joerg-Neo900>
I see no immanent reason why it wouldn't work just like with 'normal' invocation
<wpwrak>
"-N feature" what would "feature" be ?
<Joerg-Neo900>
20? 50? N?
<wpwrak>
(normal invocation) well, things are a little tricky ;-)
<wpwrak>
oh, you want to start at a certain revision
<Joerg-Neo900>
I dunno if I understand the question
<Joerg-Neo900>
yes
<Joerg-Neo900>
eeshow -N 20 61ba4e4bfee2f54db1c7636137394e98e735629b:neo900.pro doesn't offer to show diffs
<wpwrak>
anyway, please pull and build the latest eeshow. two things to check: 1) that eeshow 61ba4e4bfee2f54db1c7636137394e98e735629b:neo900.pro still works
<wpwrak>
and 2) that the pango complaints are gone
<Joerg-Neo900>
hmm ok
<wpwrak>
(no diffs) yes, it just shows you the revision you asked for
<Joerg-Neo900>
aah yes, it shows newest git history
<wpwrak>
yeah :) and look at the pretty errors it prints
<Joerg-Neo900>
and selecting any of those new versions for delta aka diff doesn't do anything
<wpwrak>
it basically tries to open the latest 20 revisions, but uses a path that contains the override syntax. so it first fails to find the thing in the repo (because it doesn't strip the rev: at this point), then tries a different approach, where it loads the specified revision each time
<Joerg-Neo900>
(eeshow:29066): Pango-WARNING **: pango_layout_set_markup_with_accel: Attribute 'background_alpha' is not allowed on the <span> tag on line 1 char 66
<wpwrak>
(1.2 s) the miracle of efficient compilation, aka C. with C++, that wouldn't happen ;-))
<Joerg-Neo900>
indeed hehe
<Joerg-Neo900>
also PCs are incredibly fast meanwhile, grepping even through gigabytes takes virtually no time anymore, a few years back that would have taken forever
<wpwrak>
yeah. if you consider what eeshow does, especially in diff mode, you can see how fast those PCs really are
<Joerg-Neo900>
my recent storage and controller can copy from one disk to another in 1 second 10 times the size of my first HDD
<wpwrak>
i.e., pan around while every pixel gets calculated from two large bit maps that also get regenerated on each display update, and you don't even notice
<wpwrak>
:)
<wpwrak>
git pull && make again should get rid of the pango complaint. you don't get pretty alpha blending with your old pango, bit it may still look better now than it used to. (i.e., the branches are highlighted in green. not sure if you had that before)
<Joerg-Neo900>
I'd *really* rather open a tooltip than redrawing the tree
<Joerg-Neo900>
worse: you can't easily get to the srolled-out-to-aboce-top items anymore
<wpwrak>
just pan ?
<Joerg-Neo900>
no
<Joerg-Neo900>
err what?
<Joerg-Neo900>
oooh, weird
<wpwrak>
;-)
<Joerg-Neo900>
this is barely intuitive
<wpwrak>
just the same as in the sheet
<Joerg-Neo900>
and completely random in the triggering of that flaw
<Joerg-Neo900>
anyway the pango error is gone
<Joerg-Neo900>
and yes, there's new green highlight now
<wpwrak>
whee ! :)
<Joerg-Neo900>
could you maybe at least dealy the redrawing a 0.5s so moving of mouse pointer across the tree doesn't make it jerk like a fish on a electric fence?
<Joerg-Neo900>
delay*
<wpwrak>
moving the mouse left or right of the boxes should do what you want
<Joerg-Neo900>
that's not practical
<wpwrak>
delays are a bit tricky. but i'll add it to the to do list
<Joerg-Neo900>
hmm, dunno about timers in plain C, in OO languages you'd set up a timer with 100ms and callback function "redraw_tree(foo, bar)" on cursor-enter of the item, and kill same timer on cursor-leave
<wpwrak>
yes, something like this. but the input event state machine is rather complex.
<Joerg-Neo900>
just like now you call redraw_tree(foo, bar. MAXIMIZED) on cursor-enter and redraw_tree(foo, bar. MINIMIZED) on leave
<wpwrak>
as i said, that state machine is tricky. it only looks simple but on the inside it's very far from that.
<Joerg-Neo900>
on leave you still want to call the same redraw_tree(foo, bar. MINIMIZED) but on top destruct the timer
<wpwrak>
yes, i know how to implement timers in general :)
<Joerg-Neo900>
yeah, state machines can be a PITA
<Joerg-Neo900>
maybe opening a tooltip requester instead of redrawing the tree was actually the simpler code and UX-wise the nicer result
<Joerg-Neo900>
you do that already whenever hovering over a component with datasheet
<Joerg-Neo900>
just make sure it pops up 50 pixel right of cursor, not under
<wpwrak>
putting an overlay ("tooltip") over the existing list of overlays would actually be quite a bit harder than what i do now ;-)
<Joerg-Neo900>
eeew
<wpwrak>
at some point i should probably rewrite all that GUI infrastructure. it's all very "grown". started nice and simple, then i added this and that little extra feature, and in the end the original design gets stretched a bit too far
<Joerg-Neo900>
hehe, that's how stuff *always* works
<Joerg-Neo900>
well, ignore my ranting please
<wpwrak>
already those "tooltips" for the components and global labels were quite the nightmare. lots of tricky interactions with the rest to consider.
<wpwrak>
'k :)
<wpwrak>
ah, regarding rev:... as start point: that's also tricky because you'd have to load the entire "low-level" history to get branches right. and that seems to be just what causes memory consumption to explode. so that feature would defeat the purpose of -N.
<Joerg-Neo900>
isn't it rather the gfx that make memory explode?
<wpwrak>
the history is another one of those areas that are trickier than they seem. it normally looks like just a nice and simple list, with one beginning and one end. but in reality it's a generic (loop-free, at least) directed graph. which creates all sort of corner cases.
<wpwrak>
if you don't even make it to the progress bar, it happens very early in the processing pipeline
<wpwrak>
what eeshow does is: 1) retrieve the git history, 2) set up the progress bar, 3) retrieve and parse the files, 4) display things.
<Joerg-Neo900>
3) makes memory blow away the roof
<Joerg-Neo900>
I mean, tig has no issues whatsoever to show a complete git history graph
<wpwrak>
rendering only happens at 4). there are several stages there, too: 1) rendering into a small set of graphics primitives (which are then cached), 2) rendering these primitives to the canvas. in the case of diffs, this changes to 2) render both sheets to bitmaps, 3) diff and merge them, 4) draw the highlighting, 5) copy it all to the canvas.
<wpwrak>
and it does all that every time anything changes (pan, zoom, pop-up, etc.) :)
<wpwrak>
yes, i'm a bit surprised by the memory consumption. dunno why it is so bad. i don't think i'm doing anything unreasonable there. could be that there's some operation that is very costly that tig can defer.
<Joerg-Neo900>
it wouldn't need to "3) retrieve and parse the files" for rev-HEAD back to rec HEAD-N when you want to look at rev N-1, right?
<wpwrak>
it does this to determine which revisions to hide. also, if a revision has errors, it gets shown in red in the history
<Joerg-Neo900>
sorry you lost me
<Joerg-Neo900>
I *can* look at rev HEAD-(N+1) already
<wpwrak>
and the general idea is to get the likely trouble out of the way early. so that you don't get mystery behaviour due to problems in some revision late in the session.
<Joerg-Neo900>
what's missing is the diff between HEAD-(N+1) and HEAD-(N+2)
<wpwrak>
ah, i see what you mean. yes, it wouldn't need to parse revisions you exclude a priori from viewing.
<wpwrak>
but as i said, the the problem doesn't even seem to be in the parsing, but in the commit graph construction, which happens well before any parsing
<Joerg-Neo900>
you could probably even read in the complete history tree(-view) and show the "too new" entries in gray
<Joerg-Neo900>
my problem with memory clearly happens while progress bar gets near ~30%
<Joerg-Neo900>
when invocing eeshow without -N parameter
<Joerg-Neo900>
invoking* dang what a weird english word
<wpwrak>
ah, so that's later then. you once said you already had issues before the progress bar even appeared.
<Joerg-Neo900>
no
<wpwrak>
face vs. fake ;-)
<Joerg-Neo900>
I said when the memory gets sparse on system, the progress bar and any abort button would not get displayed anymore
<Joerg-Neo900>
compare invocation
<Joerg-Neo900>
vs invoke
<Joerg-Neo900>
prolla "ca" vs "ke" != "ce"
<wpwrak>
ca = "ka", ce = "ze" ;)
<Joerg-Neo900>
yep
<wpwrak>
yeah. there's a lot of similar stuff in spanish. so it may go back to the romans.
drrz has quit [Ping timeout: 245 seconds]
<Joerg-Neo900>
((not get displayed anymore)) also note there's basically a race condition for resources when eeshow tries to read in 40GB of files while x11 server tries to render a new window
<wpwrak>
maybe. the progress bar is extremely "light". so it shouldn't cause much conflict.
<Joerg-Neo900>
it still is displayed in a newly created window that might not even have completely rendered on screen in that very moment
<Joerg-Neo900>
aiui
<Joerg-Neo900>
I don't think X11 is synchronous calls, is it?
<Joerg-Neo900>
anyway, the memory problem clearly is in your # 3)
<Joerg-Neo900>
not in reading in git histroy which is pretty lightweight since e.g. tig dioes that in no time
<wpwrak>
x11 can be sync or async. usually it's async.
<Joerg-Neo900>
:nod:
<Joerg-Neo900>
even for sync I'd not dare to guess if that's "down to the electron beam in CRT" or just some buffer that's not guaranteed to show up in frame buffer yet
<wpwrak>
sync isn't really meant to be useful :)
<Joerg-Neo900>
indeed
<Joerg-Neo900>
how would you make sure window is actially ro-front
<Joerg-Neo900>
to-front*
<Joerg-Neo900>
aka visible
<wpwrak>
have a chat with your window manager ? :)
<wpwrak>
but afaik, sync is mainly for debugging the protocol, doesn't really have semantics that extend to the user
<Joerg-Neo900>
yeah, well, you see my concern about progress bar possibly not even visible *despite* eeshow already painted "42%"
<wpwrak>
yes, but it would still be pretty weird if it got stuck in X. such simple things usually don't get into trouble even if the system is almost dead
<wpwrak>
you'd be more likely to see delays inside eeshow. e.g., it may just not send updates for a while because it is busy paging
<Joerg-Neo900>
let's assume a very simple and possible scenario: window not opening on-top. So you have a *very* hard time to convince your window-manager to get the window to top (aka front aka visible) when meanwhile some process hogs *all* memory
<wpwrak>
sure
<Joerg-Neo900>
my window manager doesn't even process keypress anymore, if it's meant to do *anything* inside window manager and not just get passed on to jernel to switch to console (ctrl-alt-F1)
<wpwrak>
jernel = joerg's kernel ? :)
<Joerg-Neo900>
so when I fire eeshow without -N, I only chance is to NEVER EVER press anyother key than ctrl-alt-F1 to get to console and "killall eeshow"
<Joerg-Neo900>
:-D
<Joerg-Neo900>
jernel kernel lernel
<wpwrak>
so your wm opens eeshow under other windows ?
<Joerg-Neo900>
no it doesn'tm but then it also wouldn't process a click on any "abort button" in this situation
<wpwrak>
the wm shouldn't be involved in that
<Joerg-Neo900>
or maybe it does, in 90 minutes
<Joerg-Neo900>
the WM has lots of swapped out memory pages
<Joerg-Neo900>
of course it gets involved
<wpwrak>
keypresses may be different, since the focus needs to be handled. but i think mouse clicks should be direct.
<Joerg-Neo900>
well, keyboard events are NOT processed
<Joerg-Neo900>
as soon as WM does need to do *anything* about it
<wpwrak>
yes, that may be a focus issue. i guess a program could request the focus "just in case", but that would be pretty unfriendly
<Joerg-Neo900>
IOW as soon as the keyboard event isn't to same window where I already have focus to
<wpwrak>
yes, key events are tricky. but again, mouse clicks should be more direct
raoulzecat has quit [Ping timeout: 260 seconds]
<Joerg-Neo900>
so my options to stop a runaway eeshow are: ^C, ctrl+alt-F1 && killall eeshow, or click on eeshow window close button and wait 60 minutes and pray
<Joerg-Neo900>
I'm absolutely sure a "abort" button in eeshow window under progress bar won't work that nicely
<Joerg-Neo900>
for a multitude of possible reasons that could spoil that method
<Joerg-Neo900>
anyway, I'm more interested in getting diffs between HEAD-200 and HEAD-207
<Joerg-Neo900>
:-)
<Joerg-Neo900>
I can cope with runaway eeshow by putting ulimits to purpose
<Joerg-Neo900>
:-D
<Joerg-Neo900>
((your wm opens eeshow under other windows)) *usually* not, unless I for example have a window or requester with "always on top" property
<Joerg-Neo900>
in that case however there's literally zilch eeshow could do to fight that and get on top of such other window
<Joerg-Neo900>
and there's nothing *I* could do to expose a covered "abort" button in eeshow window, when the WM got paralized by -ENOMEM and swap hell
raoulzecat has joined #neo900
<Joerg-Neo900>
heck, eeshow might even have been set up in WM/GUI to open on another virtual screen :-o
<Joerg-Neo900>
sorry I have my troubles with religions that consider their holy books as "written by God himself" while everybody knows God never writes books, humans do that
<Joerg-Neo900>
once you accept that a book inevitably got written (and edited) by humans, you have to admit humans never are infallible. Even when the original author was stringently controlled by God, the later editors hardly were
<Joerg-Neo900>
and even when the textx in that book were evidently 100% original and untainted by human error, how would you tell the meaning of words as conceived by the contemporary recipient hastn't shifted away from the original meaning of those words as spoken at the time the text been written?
<Joerg-Neo900>
oops ECHAN
<wpwrak>
;-) besides, if real gods want to write some book, they just rewrite the universe such that is has that book in it, don't they ? :)
<Joerg-Neo900>
of course
<Joerg-Neo900>
"has [that book] in it" as in: every lifeform has the knowledge embedded in the genetically defined "memory"
<wpwrak>
implementation details ;-)
<Joerg-Neo900>
hehe
goiken_ has quit [Ping timeout: 260 seconds]
goiken_ has joined #neo900
AnonID__ has joined #neo900
<AnonID__>
hey All ?...
<Joerg-Neo900>
? ?
<Joerg-Neo900>
hey!
<AnonID__>
How are You
<Joerg-Neo900>
fine, thanks
<AnonID__>
okey , Why is it deserted Channel
<Joerg-Neo900>
sorry?
<AnonID__>
Yes Sure , No Problem ?... Where Do You Come
<Joerg-Neo900>
please tell me what's your interest in neo 900
<AnonID__>
im need to join in Neo 900 Because irc.anonops error in my IRC
<AnonID__>
What Topic About ?...
AnonID__ has quit [Quit: leaving]
<wpwrak>
"neo" != "newbie" :)
<Joerg-Neo900>
:-)
<Joerg-Neo900>
U thought it was a bot though
<Joerg-Neo900>
*I*
<Joerg-Neo900>
first 4 posts were pretty much "one size fits all" templates
<wpwrak>
skynet 0.1 pre-alpha. now we know why it later hates humans so much. it's all joerg's fault.
<Joerg-Neo900>
then "AnonID__ is ~root@112.215.154.120 (root)" and "Received CTCP-VERSION reply from AnonID__: irssi v0.8.20."
<Joerg-Neo900>
a newbie should't run irssi as root ;-)
<Joerg-Neo900>
I'm still not convinced it was a human user
<Joerg-Neo900>
I'm just starting to doubt for one thing: capitalization in the reply on "Neo"
infobot has joined #neo900
<Joerg-Neo900>
\o/
<wpwrak>
since we're obviously not in the original terminator timeline we must be in the genisys timeline. that means we'll find out ... in 2017. i guess that's no coincidence :)
<Joerg-Neo900>
hehe
infobot has quit [Quit: cyal8r]
infobot has joined #neo900
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined #neo900
neo900 has joined #neo900
neo900 is now known as Joerg-Neo900
infobot has quit [Remote host closed the connection]
infobot has joined #neo900
tsuggs has quit [Ping timeout: 246 seconds]
pagurus has quit [Remote host closed the connection]
pagurus has joined #neo900
arcean has joined #neo900
Oksana has quit [Quit: Copywight 2016 Elmer Fudd. All wights wesewved.]
ecloud_wfh has quit [Ping timeout: 265 seconds]
ecloud has joined #neo900
jonsger has joined #neo900
arossdotme-planb has quit [Ping timeout: 250 seconds]
freemangordon has quit [Ping timeout: 258 seconds]
mzki has joined #neo900
arossdotme has joined #neo900
goiken_ has quit [Ping timeout: 250 seconds]
goiken_ has joined #neo900
SylvieLorxu has joined #neo900
jonsger has quit [Ping timeout: 256 seconds]
paulk-collins has joined #neo900
Joerg-Neo900 has quit [Quit: Konversation terminated!]
DocScrutinizer05 has quit [Read error: Connection reset by peer]
Joerg-Neo900 has joined #neo900
DocScrutinizer05 has joined #neo900
Satyricon has quit [Ping timeout: 260 seconds]
Satyricon has joined #neo900
jonsger has joined #neo900
arcean has quit [Ping timeout: 250 seconds]
cc___ has joined #neo900
Pali_ has joined #neo900
l_bratch has quit [Ping timeout: 244 seconds]
l_bratch has joined #neo900
drrz has joined #neo900
freemangordon has joined #neo900
paulk-collins has quit [Ping timeout: 260 seconds]