ChanServ changed the topic of #picolisp to: PicoLisp language | Channel Log: https://irclog.whitequark.org/picolisp/ | Check also http://www.picolisp.com for more information
rick42 has quit [Quit: ZNC - http://znc.in]
xkapastel has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #picolisp
ubLIX has quit [Quit: ubLIX]
rick42 has joined #picolisp
<rick42> hello
<rick42> had to bounce the bouncer lol
orivej has quit [Ping timeout: 252 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 244 seconds]
rcs_ has quit [Ping timeout: 272 seconds]
xkapastel has joined #picolisp
_whitelogger has joined #picolisp
<Nistur> mornin' all
<Regenaxer> Hi Nistur
<Nistur> Regenaxer: I may be using pil for a silly project finally...
<Nistur> _may_
<Regenaxer> Good idea! No project is silly enough ;)
<Nistur> I've agreed to try to port someone's PS4/XBOne/PC game to Atari Jaguar :P Which means I FINALLY have an actual project I can work on, with art and everything... so I've been setting up my Atari 1040STE to do actual development, instead of just poking around with it... I quickly realised that I am going to actually need two of them though, as I want to make tools like level editor etc, and they'd need to
<Nistur> be in colour, but colour is only low and medium resolution... but I'd want to code in high resolution... aaaaaanyway... I'm going to have to code these tools... The choices are either BASIC (urgh), C (apparently a bit buggy) m68k assembler, or... porting your m68k mac pil to TOS and using that :P
<Regenaxer> Hmm, too bad, the 68k thing is very out of date
<Regenaxer> also, parts are in assembly
<Nistur> I have no problem with assembly
<Regenaxer> ok
<Nistur> I just think for tools, it'd be ok to use a higher level language
<Nistur> so I can make them quicker
<Regenaxer> But that old pil is *very* outdated
<Nistur> I am aware of this :P
<Nistur> if I can get it running at all, then I can always look into trying to retrofit some of the missing features
<Nistur> but, to be honest, any language/toolchain I use will feel outdated and limited
<Regenaxer> If you port current pil32, assembly is not needed. But Atari is not POSIX ;)
<Regenaxer> yeah
<Nistur> I'm not using cutting edge hardware, I don't expect to be using the latest and greatest software :P
<Nistur> Getting some tools set up will be my next task. Right now I'm just trying to get the toolchain building something I can test on the jaguar... initially just on the (less than perfect) emulator...
<Nistur> but once I can do that, I want to set up a framework for tools so I can offload some of the game creation onto the original developer (who isn't a programmer and I think did the original game with a visual scripting system in Unity3D from what I can tell)
<Regenaxer> tough
<Nistur> so yes, I'll have a stab at porting pil (pil16?) to TOS. If I can get it working, I'll probably use that. If it takes too long, I'll probably end up having to use assmbler for the tools
<Regenaxer> It is already a pil32 (cell size etc)
<Nistur> ahh ok
<Nistur> I'm just trying to find it... I'm sure I had it downloaded somewhere... it's mac.tgz isn't it?
<Regenaxer> hmm, no
<Nistur> I just got it from there :P
<Regenaxer> Perfect :)
<Nistur> 'Only short numbers (30 bit) are available).'
<Regenaxer> yes
<Regenaxer> like today's miniPicoLisp
<Nistur> Regenaxer: I don't suppose you happen to recall which C compiler you used for that?
<Regenaxer> I do, it was Macintosh Programmer Workshop
<Regenaxer> The first versions though were on a Mac 512 with LightSpeed C
<Nistur> hmm ok
xkapastel has quit [Quit: Connection closed for inactivity]
<Nistur> well, pure C, which is apparently using borland C, is complaining about line 109 in pico.h :P Buuuuuut when I try to open pico.h then it munges it all into 1 line
<Regenaxer> Mac format
<Regenaxer> no linefeeds :)
<Regenaxer> Perhap it would be better to start with miniPicoLisp?
<Nistur> is miniPicoLisp likely to compile on an m68k?
<Regenaxer> yes
<Regenaxer> It is plain vanilla C
<Nistur> I will try that next then :P
<Regenaxer> good, I feel that is much better
<Regenaxer> more up to date, and about the same power as the old Mac one (minus Mac toolbox)
<Nistur> no stdint.h :P
<Regenaxer> I don't remember what it is needed for
<Regenaxer> If you comment the #inclde, what error results?
<Nistur> still has a bunch of errors, but I just picked a random file to compile first
<Nistur> I read through the Makefile now and realised that I need to build gen3m first
<Nistur> that only has 6 errors :P
<Regenaxer> ah, hmm
<Regenaxer> Perhaps not, moment
<Regenaxer> It builds 3 files ram.d rom.d sym.d
<Regenaxer> they are not in the TGZ
<Regenaxer> but I think you can build them on another machine
<freemint> Nistur sounds like much gun
<freemint> fun
<Nistur> :P
<freemint> don't you worry about efficiency on such low level hardware or do you need something interpreted anyway?
<Regenaxer> 68k is not so low-level
<Regenaxer> We used pil back then for production systems
<Regenaxer> Something like a precessor of PhotoShop
<Regenaxer> predecessor (?)
<freemint> vorgänger?
<Regenaxer> yep
<Regenaxer> There was nothing like PhotoShop in 1988
<Regenaxer> A scanner for negatives filled a whole room
<Regenaxer> and cost nearly a million DM
<freemint> On the other hand old video games (or video games in general). are generally developed to get the most out of the hardwares i am not sure how picolisp fits there
<Regenaxer> right, the lowest levels are better in asm then
<Regenaxer> usually only very few places
<Nistur> freemint: this is intended to be to make tools for the game, not the game itself
<Nistur> Regenaxer: pure C doesn't like struct definitions -_-
<Nistur> 'declaration syntax error'
<Nistur> aha
<Nistur> no
<Nistur> it's not structs
<Nistur> it's //
* Nistur starts replacing comments
<Regenaxer> oh, yeah, no ///
<Nistur> it didn't like structs either in the form typedef struct heap { struct heap* next } heap;
<Nistur> change it to typedef struct heap_t { struct heap_t* next; } heap; and it works
<Regenaxer> wow
<Regenaxer> I don't remember old C
<Nistur> :P
<Nistur> I think CELLS is also FAR too big...
<Nistur> 1024*1024*sizeof(cell)
<Regenaxer> true, on the old Mac a memory allocation chunk was limited to 32 KiB
<Nistur> I can make this work, I think :P
<Nistur> it will take a while
<Nistur> but yeah, should be able to
<Regenaxer> You can define CELLS in Makefile
<Regenaxer> -D
<Nistur> yep, I saw that
<Nistur> I will do that, but right now I'm just trying to get one file copiling :P
<Regenaxer> ok
<Nistur> once one file will compile on it's own, I'll coax the makefile
<Nistur> can't just use that one, as it's based on gcc
<Regenaxer> yes
<freemint> Nistur that explains it a little but don't the tools need to run during the game too?
<Regenaxer> hmm, how about the dynamic arrays then? Are they supported in that C?
<freemint> Nistur it would be great if you document your changes during porting and write an wiki article about the port
<Nistur> Regenaxer: Uuuuuuuuuuuuuum. I would say probably not. Is that going to cause a problem with minipil?
<Nistur> freemint: no, the tools will be things like a sprite/animation editor, a level editor, maybe stats editor etc
<Nistur> they'll output data which will get compiled into the game
<Regenaxer> Yes, miniPil is just lik pil32 in regard of these arrays
<Regenaxer> grr
<Nistur> Regenaxer: which file(s) are they in and I'll take a look quickly
<Regenaxer> The old Mac pil solved this problem by using assembly for the evaluator
<Regenaxer> most files, main, subr, flow at least
<Nistur> would it be possible to take the assembly from the mac one? Or is the architecture too different?
<Regenaxer> It is normal 68k asm
<Nistur> I meant the architecture of macPil vs miniPil
<Regenaxer> but you need the C part then too which calls it
<Regenaxer> no, different
<Regenaxer> I rewrote pil from scratch in 1999
<Regenaxer> later forked mini from that
<Regenaxer> Dynamic arrays made it possible to write the whole interpreter in C
<freemint> dynamic arrays need mmu or what is the problem on 68k
<Regenaxer> no
<Regenaxer> nothing to do with hardware
<Regenaxer> it is a compiler issue
<Regenaxer> no problem in asm, but standard C doesn't let you control the stack
<Regenaxer> An MMU is to map separate address spaces
<Nistur> well, this toolchain is copyright '92
<Regenaxer> logical vs pshysical addresses
<Regenaxer> Perhaps better use Forth?
<freemint> i thought the mmu gives you address violations too
<Nistur> if I cannot get pil to work, I will probably stick to a mixture of C and asm :P
<Regenaxer> yes, if you access addresses outside your area
<Regenaxer> but the stack thing is a logical issue
<freemint> i always thought VLA works by "if you go to far we allocate a new block and map it next to yours"
<Regenaxer> The stack entries (their sizes) are not known when C is compiled
<Regenaxer> different thing
<Regenaxer> char c[256];
<Regenaxer> this decrements the stack pointer by 256
<Regenaxer> that's all
<Regenaxer> But I need char c[x * 8 + y];
<freemint> ahh
<Regenaxer> An assembler code can calculate this, then subtract from the SP register
<Regenaxer> very efficient
<Regenaxer> no malloc() needed
<Regenaxer> which has enormous overhead
<freemint> and you can not do for ... x*8+y; char[];
<Regenaxer> how should that work?
<freemint> oh yes declarations are compile time i forgot
<Regenaxer> T
<Nistur> Regenaxer: I will look into this, I'll work on fixing up compile errors for flow.c and see what comes
<Regenaxer> anyway, C is crippled here
<Regenaxer> ok, but what would be the solution
<Regenaxer> call alloca() ?
<freemint> can you just do some platform specific inline assembly to manipulate the stack pointer?
<Regenaxer> Not sure how efficient alloca is
<Regenaxer> freemint, yes, that's what the Mac pil did
<Regenaxer> well, the whole eval in asm
<Regenaxer> I don't remember exactly
<Nistur> Regenaxer: at this point, I want it to work. I'm not too bothered by tool efficiently... if I can get alloca to work for it, then sure, if not, then I can look into seeing if I can do some inline m68k assembly for the allocation
<freemint> and hide the inline ask in a function which is unlined reserve_cells(x,y)
<Nistur> coaxing this to work seems like a lot less work than writing the tools in assembler, or even to writing them in C :P
<freemint> so VLAs are not arrays which grow at runtime but arrays of unknown size on the stack?
<Regenaxer> yes
<Regenaxer> only allocated once
<freemint> Nistur how much time did you allocate for getting pil running?
<Nistur> __attribute__ ((noreturn))
<Regenaxer> can be removed
<Nistur> ok
<Regenaxer> supresses warnings
<Nistur> for now, I'm just hacking up the code, but I guess if I can make this work, I'll start again, and replace it with a define which if building on ST, it'll evaluate to nothing
<Nistur> freemint: depends how much time I get :P The project is not time critical, This is mostly a learning thing for me, to use and develop on the ST... so *shrug*
<Regenaxer> btw, there is no backport of gcc?
<Regenaxer> we have it for most embedded systems too
<Nistur> looks like GCC 2.9.5 may run on Atari, but people still recommend Pure C
<Nistur> I may see if I can grab that later and take a look
<Regenaxer> This looks best and easiest to me
<Regenaxer> old GCC is OK
<Nistur> I'll see if I can find it then
<Nistur> right now, I need to do other things
rcs_ has joined #picolisp
freemint2 has joined #picolisp
orivej has joined #picolisp
freemint has quit [Ping timeout: 252 seconds]
freemint2 has quit [Ping timeout: 245 seconds]
freemint has joined #picolisp
freemint2 has joined #picolisp
freemint has quit [Ping timeout: 268 seconds]
freemint has joined #picolisp
freemint2 has quit [Ping timeout: 268 seconds]
rcs_ has quit [Quit: Leaving]
freemint2 has joined #picolisp
freemint has quit [Ping timeout: 244 seconds]
freemint2 has quit [Ping timeout: 245 seconds]
freemint has joined #picolisp
freemint2 has joined #picolisp
xkapastel has joined #picolisp
freemint has quit [Ping timeout: 260 seconds]
freemint has joined #picolisp
freemint2 has quit [Ping timeout: 268 seconds]
freemint2 has joined #picolisp
freemint has quit [Ping timeout: 268 seconds]
freemint has joined #picolisp
freemint2 has quit [Ping timeout: 245 seconds]
razzy`` has quit [Remote host closed the connection]
razzy`` has joined #picolisp
freemint2 has joined #picolisp
alexshendi has joined #picolisp
freemint has quit [Ping timeout: 268 seconds]
alexshendi has quit [Read error: Connection reset by peer]
ubLIX has joined #picolisp
freemint2 has quit [Read error: Connection reset by peer]
freemint2 has joined #picolisp
freemint has joined #picolisp
freemint2 has quit [Ping timeout: 268 seconds]
freemint2 has joined #picolisp
freemint has quit [Ping timeout: 252 seconds]
freemint has joined #picolisp
freemint2 has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 244 seconds]
razzy`` has quit [Ping timeout: 268 seconds]
razzy has joined #picolisp
ubLIX has quit [Quit: ubLIX]
razzy has quit [Ping timeout: 252 seconds]
razzy has joined #picolisp
<razzy> i have problem understanding why do we have recur and recurse. (propably problem on my side) i think we have implemented tail-recursion (which is harmless feature that do not confuse other people than me.) why do we have another thing, that from my limited view do the same?
<razzy> just for increased readability?
<Regenaxer> There is no tail-recursion in PicoLisp
Regenaxer has left #picolisp [#picolisp]
alexshendi has joined #picolisp
Regenaxer has joined #picolisp
<alexshendi> Hi Regenaxer!
<Regenaxer> oops
<Regenaxer> Hi alexshendi!
<Regenaxer> Tail-recursion makes sense only for a compiler
<Regenaxer> (we had this discussion here already several times)
<alexshendi> IMHO tail recursion would make sense in a tree-walking Scheme interpreter.
<Regenaxer> Tail recursion as I understand it is replacing recursion with a loop
<Regenaxer> so a compiler or runtime code modification must do it
<razzy> Regenaxer: we as me and you?
<Regenaxer> The pil philosopy is that the programmer is in control
<Regenaxer> So nothing behind the scenes
<Regenaxer> razzy, no, "we" as here in IRC
<Regenaxer> and probably also the mailing list
<razzy> i think picolisp did not grow in memory for recurrent function calls, which confused me and behaved as tail-recursion
<Regenaxer> ?
<Regenaxer> tail-recursion is just a loop
<razzy> yes.
<Regenaxer> So *do* write it as a loop
<Regenaxer> 'recur' is anonymous recursion
<razzy> tail recursion is done because you want your recurrent calls to do not waste space in memory
<Regenaxer> exactly
<razzy> *to do waste space i nmemory
<Regenaxer> space in *stack*, not in heap
<razzy> i write it right first time sorry
<Regenaxer> So it is not really wasted
<Regenaxer> just used
<Regenaxer> ok
<Regenaxer> Some things cannot be written as a loop
<Regenaxer> so you need true recursion
<razzy> yes, but picolisp do some magic that prevent memory waste. i assumed it is tail recursion
<Regenaxer> But using recursion for any kind of loop as some programming text books do is nonsense
<razzy> i will check the irc logs
<Regenaxer> Which magic do you think of?
<razzy> i like to use recursion for testing hardware and stuff. and picolisp recursion of i think fibonachi did not use memory
<razzy> which confused me, i assumed picolisp has tail-recursion
<Regenaxer> Ah, fibo is just a test case :)
<razzy> i am confused
<razzy> how is it relevant
<Regenaxer> It is a good test case for function call overhead
* razzy will look at fibo to remember more clearly
alexshendi has quit [Ping timeout: 240 seconds]
* razzy will read irc logs. razzy is working under assuption that picolisp have similiar behaviour to tail recursion. propably implemented differently
<Regenaxer> ok, but as I said it does not exist as a concept in pil
<razzy> Regenaxer: but the behaviour of tail-recursion is present in picolisp, yes? (so i do not have to test it)
<Regenaxer> The behavior is a loop, and loops exist in pil
<freemint> razzy there is tail recursion in PicoLisp
<Regenaxer> freemint, how?
<razzy> but implemented in interpretter right?
<freemint> *THERE IS NO
<Regenaxer> yep
<freemint> what i suspect you are seeing is: the heap allocations do not grow during recursion
* razzy is confuse
<Regenaxer> Let me show an example
<Regenaxer> (de f (X)
<Regenaxer> (when X
<Regenaxer> (println (val X))
<Regenaxer> (f (get X 'left))
<Regenaxer> (f (get X 'right)) ) )
<Regenaxer> This recurses, right?
<Regenaxer> Now you can replace the final (tail) recursion:
<freemint> a simple test (de Re (N) (Re N)) This is a recursive function. If PicoLisp did tail recursion it would not end and get stuck in a infinite loop but PicoLisp Crashes since it runs out of stack
<Regenaxer> (de f (X)
<Regenaxer> (while X
<Regenaxer> (println (val X))
<Regenaxer> (f (get X 'left))
<Regenaxer> (setq X (get X 'right)) ) )
<Regenaxer> Understand?
<freemint> you do not see allocations since the stack is allocated at process creation
<freemint> but the remaining stack gets smaller after every recursion
<freemint> Regenaxer is the a way to see how much stack is remaining?
<Regenaxer> Not under Unix
<Regenaxer> the stack is infinite so to say
<Regenaxer> ulimit -s unlimited
<Regenaxer> It starts to swap if running out of RAM
<freemint> regenaxer you are sorta technically right but pedagogically you are plain wrong
<razzy> freemint: wait wait wait, picolisp cannot allocate RAM for function calls?
<freemint> razzy recursion happens in the stack not in the heap of cells
<razzy> and stack is allocated pernamently? not changable?
<Regenaxer> razzy, it goes up and down
<Regenaxer> just incrementing a pointer
<Regenaxer> then decrementing upon return
<freemint> stack allocations size is changeable. In reality when a process runs out of stack the OS gives it more until a limit is reached
<freemint> (Re 5) fails because by default processes have a finite stack size
<freemint> the stack limit is changeable via system calls or comammng line utils (like ulimit)
<razzy> uff, minor heart attack avoided :]
<freemint> Does it make sense now?
<razzy> more sense
<Regenaxer> :)
<freemint> just write loops when you want loops. The reason is simple: Do not lie to the program what your true intentions are. If you intention is to loop do not tell the story by recursion.
<Regenaxer> Well said freemint!
<freemint> Regenaxer how could we look how "full" the stack is?
<freemint> Thanks
<Regenaxer> The interpreter knows internally, but there is no function at the user level
<Regenaxer> The 'stack' function only shows the segment size (and only if coroutines are running)
<Regenaxer> For coroutines the stack is no longer unlimited
<razzy> freemint: very poetic.
<razzy> recursion is hard for humans(for good reason) and therefore looked valuable to early programmers
<Regenaxer> right
<Regenaxer> Especially as early langs like Fortran did not have it
<Regenaxer> So it was chic to write everything recursive, even if not necessary
<freemint> Regenaxer all coroutines share the same ulimit?
<razzy> early is relative term. chic?
<Regenaxer> yes, so it is the *number* of coroutines which is limited by that
<Regenaxer> early = 1960s
<Regenaxer> Some algorithms are much more readable however when written recursively
<freemint> So each coroutine has a constant overhead and a stacksize. and the sum of those has to be smaller than ulimt.
<Regenaxer> Like tree traversals
<Regenaxer> freemint, yes
<Regenaxer> each coroutine has a constant stack segment size
<razzy> thx for all info
<freemint> Regenaxer more diagnostic functions about the state of the pilVM would be nice. It could include stack usage and so on
<Regenaxer> true
<Regenaxer> It is not really needed though
<razzy> hmm,. if i recurse too quickly i have segfault :]
<Regenaxer> Things like memory usage you can also get from the OS:
<Regenaxer> for P in $(pgrep picolisp); do echo "###" $P "###"; egrep "VmSize|VmData|VmStk" /proc/$P/status; done
<Regenaxer> razzy, as freemint says
<Regenaxer> stack overflow
<Regenaxer> Try ulimit
<razzy> how, why is it possible?
<razzy> i would prefer eating up RAM
<Regenaxer> yes, but so it is limited
<freemint> when you run against the stack limit it crashes. "ulimit -s unlimited" sets no upper limit which means to much recursion will kill your total systems performance
<razzy> ah,.. i see,.. would it be too costly to navigate in big stack?
<Regenaxer> With 'ulimit -s unlimited' you can get all RAM and more for stack
<Regenaxer> Stack is not costly
<Regenaxer> it is the most efficient way to allocate memory
<freemint> The size of a stack makes stack operations not more expensive stack operations areH push and pop, take one element of the stack and put a element on it. Those can be done in constant time
<freemint> *pop and push
<razzy> ah, there are no algorithms on one processor stack. my bad
<Regenaxer> and often 'sub S 1024' to get a buffer of 1 KiB
<Regenaxer> (I meant that as a generalization of 'push')
<freemint> Regenaxer small correction: it is the fastest way to allocate locally when you have a well defined deletion point.
<Regenaxer> Needs not to be locally, you can do that also at startup
<Regenaxer> but thats not typical
<freemint> It is still local but you do everything in the local scope
<Regenaxer> Depends how you define "local"
<freemint> so we can call the first local scope the "process global" scope
<Regenaxer> It must not be in one place
<freemint> oh?
<Regenaxer> at least not in asm
<Regenaxer> Higher langs restrict you
<freemint> *eye rolling*
<freemint> in ASM there is no stack
<Regenaxer> as you said: well defined deletion point
<Regenaxer> uh?
<freemint> in ASM there is just memory
<Regenaxer> Stack is *only* in ASM
<freemint> and weird relative to register operation
<Regenaxer> you control the hardware stack pointer
<freemint> ok different definitions of stack
<Regenaxer> In C or Jave the stack is hidden
<freemint> how do you define stack?
<Regenaxer> A memory controlled by a pointer
<Regenaxer> But there is also a hardware aspect
<Regenaxer> Usually one register is a special stack pointer
<Regenaxer> it is used by hardware eg during interrupts
<freemint> my attempt: a collection of data which is accessible only via pop and push (or other stack operations in forth)
<Regenaxer> ok, but definitely not only push/pop
<Regenaxer> You have whole data frames on the stack
<Regenaxer> see doc64/structures
<Regenaxer> So a stack is LIFO
<Regenaxer> but more than push/pop
<freemint> ok i think we can agree that we mean two sides of the same coin
<Regenaxer> yes, you can see the logical aspect, and the hardware aspect
<Regenaxer> You can simulate a stack even with lists
<Regenaxer> (push 'Stack 1)
<Regenaxer> But it is not a physical stack then
<Regenaxer> not the hardware aspect
<freemint> yeah
<Regenaxer> So you are right if you regard it as a general data structure
<Regenaxer> But things like (push 'Stack 1) do not apply to our discussion above
<Regenaxer> ie the ulimit thing
<freemint> are you still very much behind schedule?
<Regenaxer> ulimit -s is about the hardware stack
<Regenaxer> yes, perhaps one year
<Regenaxer> not sure
<Regenaxer> But we won't go productive end of this year as planned
<freemint> have you catched up or fallen behind?
<Regenaxer> ok so, cause many features were added
<freemint> sure way to kill any project?
<Regenaxer> I have no idea, it is all fuzzy
<razzy> hmm,.. ulimit -s makes no change, just feedback
<Regenaxer> razzy, you must give a size, or "unlimited"
<Regenaxer> freemint, so no worry, for me it is good if the project gets bigger ;)
<razzy> my bad, i feel not adequate :]
<Regenaxer> Just when we started in spring it was thought to go life sooner
<freemint> quiet machevellian
<Regenaxer> No, it is becoming a more and more useful program for the user
<freemint> oh and what kind of program it is?
<Regenaxer> Logistics
<razzy> global logistic negotiation tool?
<freemint> that is challenging
<Regenaxer> T
<freemint> I had a talk with recruiters from GLS... and i was impressed
<Regenaxer> cool
<Regenaxer> But you still have time, no?
<freemint> thousands of different digital home cooked solutions all over the globe. Privacy constraints, time zones, sending packets across time zones, routing, planning places where to put rooting places
<freemint> I still got time for details read the irc from the 25. Oktober
<freemint> I was a Karrieremesse hosted by university and walked around trying to get an idea what i am worth
<razzy> nice to hear
<freemint> i would be interested to hear some details of work on logistics but understand when you do not want.
<Regenaxer> This project is a rather specific one, for exhibition logistics
<Regenaxer> it is in fact my oldest customer
<freemint> oh interesting
<Regenaxer> We have it running now since 2002
<Regenaxer> And this year they decided they want to have it once more: new from scratch
<Regenaxer> With mobiles (tablets)
<Regenaxer> So it is a complete redesign in terms of data structures
<freemint> i see
<freemint> i guess that they came again is a good sign
<Regenaxer> yes
<Regenaxer> It was an ongoing project anyway, many small changes over the years
<freemint> what lead the to a rewrite? tablet support should be able to be done without one.
<Regenaxer> not at all
<Regenaxer> We need distributed databases, working offline, replicating in both directions
<freemint> ahh
<Regenaxer> So I make one DB per user
<Regenaxer> and 4 central DBs
<freemint> how do you deal with "merge conflicts" ?
<Regenaxer> There are never conflicts. The user switches to/from tablet work
<freemint> just one current user at all times?
<Regenaxer> So a DB may be online or offline, and "hot" on the central server or on the tablet
<Regenaxer> About 40 users
<Regenaxer> each tablet replicates to the central db and to all other tablets
<Regenaxer> That is, the whole DB is as a copy on each tablet
<Regenaxer> (without most blobs)
<Regenaxer> The blobs take up 95 percent of the space
<freemint> when two person make offline changes to the same object? and try to sync later?
<razzy> blob? data heavy single entry?
<Regenaxer> They cant
<freemint> How do you prevent that
<razzy> online lockin?
<Regenaxer> There is a central DB, and a DB per user
<freemint> razzy (doc '+Blob )
<razzy> lol
<Regenaxer> Some objects are only on the central db
<Regenaxer> they can be changed only there
<freemint> i see
<Regenaxer> The db on a tablet has other objects
<Regenaxer> they are connected
<Regenaxer> but changeable only here ore there
<freemint> i still do not grasp it but ok for today
<Regenaxer> and always replicated to all
<Regenaxer> It is indeed confusing
<Regenaxer> The user decides if he works at home or mobile
<Regenaxer> When at home, his DB can be changed by him and everybody else wih permissions
<freemint> it seems very important to get that data sync abstraction right or you can rewrite it again
<Regenaxer> But if he "releases", ie switches to the tablet
<Regenaxer> only he can change this db
<Regenaxer> on the home server it is locked and read only
<Regenaxer> yes, I never had such a complicated setup so far
<Regenaxer> All changes are queued in both directions
<Regenaxer> in case the device is offline
<Regenaxer> replicated later
<freemint> and what if the hot tablet dies? can you overwrite the hot-nes
<Regenaxer> If it breaks or gets stolen, the latest syncronized version is on the central server
<freemint> i see
<Regenaxer> Then yes, you say "deactivate" on the server
<Regenaxer> the user can take a new tablet and "activate" it
<Regenaxer> He gets a copy of the DB
<freemint> has it ever occurred to you that your solution is so complicated that it has to be wrong and if so what convinced that it is the easiest solution?
<Regenaxer> I see no fault at the moment :)
<Regenaxer> Has to be tested a lot of course
<Regenaxer> So again good that we don't start yet :)
<razzy> if it has no simple interface, people will have trouble working with it
<Regenaxer> razzy, right
<Regenaxer> not interface, but concepts
<Regenaxer> Users must understand what it means
<razzy> yes, simple concept wrap-up/interface
<Regenaxer> Which objects they can change or create in which situation
<razzy> and more than 3 rules and you lost them
ubLIX has joined #picolisp
<razzy> maybe 7 rules in special hardcore cases and educated people.
<Regenaxer> They use it all day, so they are well into the concepts
<razzy> i do not know your usecase
<razzy> uko
<Regenaxer> afp
razzy has quit [Ping timeout: 252 seconds]
<beneroth> hi all
<beneroth> interesting log
<beneroth> good quote to put at top of picolisp tutorials:
<beneroth> <freemint> just write loops when you want loops. The reason is simple: Do not lie to the program what your true intentions are. If you intention is to loop do not tell the story by recursion.
<beneroth> :D
<beneroth> :)
viaken has quit [Quit: kernel upgrade]
viaken has joined #picolisp
<freemint> beneroth yeah
<freemint> "speak the truth or atleast don't lie"
<beneroth> T
<beneroth> also makes it easier for the follow programmer who has to read your code later (including yourself in 6 months)
<freemint> i really fell in love with "Fehlerrechnung" in Physiks
<freemint> maybe stockholm Syndrom anyhow. i am done with my protocol for today. atleast that is what it looks like?
<freemint> beneroth i got an interesting question. "Why does an bigger than statically expected part of the PicoLisp Community speak german?
<freemint> "
<freemint> There are no resources (docs, etc.) in German which would attract German people
<freemint> there are no resources (docs, etc.) in German which would attract German people
<freemint> lingua franca is german
<freemint> *english
<freemint> Picolisp is not very discoverable as a programming language made in German
<freemint> it is not obvious to me that Regenaxer's business makes more likely to encounter in PicoLisp In Germany
* freemint notices he is tired
<freemint> Possible hypothesis: Google ranks picolisp higher in Germany
<freemint> Germans are more likely to stick in the irc when there are German people
<freemint> Picolisp better fits a German mindset.
<freemint> If the last what makes PicoLisp particularly german?
<Regenaxer> ret
<Regenaxer> I think not only German
<Regenaxer> Somehow there is also an Indian aspect
<freemint> could an increased number of Indians be explained by their larger programer number?
<Regenaxer> perhaps
<freemint> Why do you think it has an Indian aspect?
<Regenaxer> My closer contact was with 3 guys of Indian origin
<Regenaxer> One really in India, one in Ottawa, one in Dubai
<freemint> did they find it independently?
<Regenaxer> yes
<freemint> do you keep statistics about the number of mailing-list members?
<Regenaxer> no stats, it just grew over time
<Regenaxer> I have the list
<Regenaxer> atm 195 members
<freemint> one day it would be interesting to do a analysis over time. How many members a hacker news article brings .. etc
<Regenaxer> Not so big changes, always +1 or +2
<freemint> whether the redesign of the website increased membership
<Regenaxer> seems not
<freemint> ok why the f++k do analysis when we have Regenaxer as "machine learning oracle"
<freemint> ;)
<freemint> have you spotted other interesting ideas?
<freemint> *trends
* freemint notices he is tired
* freemint notices he already noted that
<Regenaxer> np
<Regenaxer> Watching videos, drinking Whiskey, talking with wife
<freemint> you said "not only German aspects", what German aspects do you see in PicoLisp?
<Regenaxer> uh
<Regenaxer> you brought that up
<Regenaxer> I don't see any
<freemint> as an possible hypothesis to explain a perceived anomaly
<freemint> Having "long words but few atoms" ?
<freemint> I have no usefull theory either
<Regenaxer> amazing!
* beneroth likes to point out that there quite some, albeit seemingly small at first look (but running deep), cultural differences between Germans and german-speaking Swiss.
<beneroth> Regenaxer, I like such "singing" e-guitar playing
<beneroth> s/like/love
<beneroth> bookmarked
<Regenaxer> I love(d) Rory Gallagher
<Regenaxer> beneroth, yes, Swiss is very different
<beneroth> I think like half or so of the German Immigrants which came here in a wave some years ago left again.
<freemint> i do not get your amazement but on the other i do not expect to be amazed at this https://m.youtube.com/watch?v=9rhbyVCKa44
<beneroth> Regenaxer, I didn't know about Rory, thanks!
<beneroth> "Jimi Hendrix was asked how it felt to be the world's greatest guitarist, he is reported to have said: ‘I don't know, go ask Rory Gallagher’"
<beneroth> (Wikipedia)
<beneroth> freemint, well I grew up with Nintendo GameBoy, so this 8-bit sounds are nostalgia. :)
<beneroth> though fireemblem is not as iconic as pokémon: https://www.youtube.com/watch?v=Y7XfFk5Ytv8
<Regenaxer> freemint, seems this is on the other end of the spectrum
<Regenaxer> Rory is extremely "life", no electronic effects whatsoever, all just with guitar and virtuosity
<beneroth> hm.. I suspect 8-bit midi and rock/metal guitar are not really on the same spectrum :D
<Regenaxer> yep
<Regenaxer> hard to compare
orivej has joined #picolisp
<Regenaxer> I used to play electric guitar too, so I can value his playing
<Regenaxer> no chance to ever get close
<Regenaxer> not even 5%
<Regenaxer> When I was a teenager, I played some of his songs at half speed
<Regenaxer> with a magnetic reel tape
<beneroth> can't find a video.. but on a CCC congress a few years ago there was an art installation, a midi player (able to play midi files) made up with real instruments (so some mechanics and electronics)
<Regenaxer> So I could find out the tones he fingeres at that speed
<beneroth> impressive
<beneroth> I love metal also for the aspect that it is played live on stage, usually without any playback, by bands who created the songs and lyrics all themselves :)
<Regenaxer> yeah, life is most important
<Regenaxer> only life is *really* music
<beneroth> I know what you mean, though then you lack a word for the other thing ;)
<Regenaxer> The above shadow play is in fact not soo fast. But this one:
<beneroth> I know this song!
<Regenaxer> :)
<Regenaxer> A simpl rock
<Regenaxer> Not sure who composed
<Regenaxer> normally Rory only sang his originals
<Regenaxer> anyway, past times ;)
<Regenaxer> Let's look forward
<beneroth> aye. when Blind Guardian plays near your location I will drag you there, haha.
<beneroth> and you should drag me to some concert :)
<Regenaxer> Metal, ok! :)
<Regenaxer> You know Eisbrecher?
<beneroth> sure
<Regenaxer> Alex is living 50 m from here
<Regenaxer> Wesselsky
<beneroth> ah!
<freemint> The song i linked is a very faithful recreation of an orchestra song which underscored the final battle of the first video game i bought for my 3ds without asking for permission. I get shutters everyone i hear that song, both in 8bit and orchestra version but the 8bit is even better by a little since it is simpler
<Regenaxer> Not here most of the time
<beneroth> probably a good symptom of his career :)
<Regenaxer> freemint, so it is a nostalgic memory?
<Regenaxer> beneroth, yeah, so it seems a hard life
<beneroth> yeah, surely a hard life. all the travelling all the time :/
<Regenaxer> He is an adoptive son of the uncle of the former owner of my house ;)
<Regenaxer> or cousin perhaps
<beneroth> ah, so you got a connection, kinda :D
ubLIX has quit [Quit: ubLIX]
<Regenaxer> lots of Wesselskys here
<Regenaxer> not so close
<beneroth> hehe, T, your sentence was just funny :)
<Regenaxer> The house next to mine was the sister, then his house
<Regenaxer> :)
<beneroth> (; Regenaxer house previous-owner uncle adopted-sons 1)
<Regenaxer> yeah, I lost overview
<beneroth> you need a graph DB for the social graph :P
<Regenaxer> That's life in a small village
<Regenaxer> T
<beneroth> I grew up in a small village. half the population had the same family name (though it was 2 different families)
<Regenaxer> hehe, yeah
<beneroth> vine, vegetables and hopfen village
<Regenaxer> nice
<Regenaxer> and cheese?
<beneroth> not so much
alexshendi has joined #picolisp
<Regenaxer> Not so high in the mountains then
<Regenaxer> vine
<beneroth> well there was cheese dairy next to my parents house. which was a little annoying, because it had two pigs in a small cage which got feed the rests of cheesemaking
<beneroth> no, not in the mountains at all. flat part of switzerland (well, many hills). just a few km south of german border.
<Regenaxer> Why annoying? Good cheese to the pigs?
<beneroth> flies
<Regenaxer> ah
<beneroth> later the cheese dairy closed, then a baker settled in, baking croissants and stuff for the zurich airport. that smelled better :)
<Regenaxer> indeed
<freemint> Regenaxer you could said that ... but a nostalgic memory when i was overwhelmed with awesome
<beneroth> :)
<Regenaxer> :)
alexshendi has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
<freemint> the orchestral version has something you would call an "drop" in dubstep and the 8bit version manages to recreate that faithfully
<beneroth> clouds should really be rebuilt with one hardware piece per client...
<beneroth> oh nice, the attack/exploit doesn't require root
<freemint> beneroth nah cloud is useful
<beneroth> it's not reading the CPU cache (like meltdown and spectre attacks)
<beneroth> freemint, sure, but not secure :P
<freemint> there are things which do not need to be secure,
<freemint> i would say most does not need to be secure against side channels
<beneroth> sure. did you check where your ebanking servers are running? :P
<freemint> not at all
<beneroth> their (authors of the attack above) proof-of-concept is stealing TLS private keys from a TLS server running on another process on the same CPU.
<beneroth> getting the private key of a TLS cert e.g. of a ebanking web application allows MitM :)
<freemint> i am aware
<freemint> although you would need to trick out some js magic too
<freemint> but is more doable than to rely on it
<freemint> also a short look in to the relevant guidelines suggests bank are quiet regulated there
<beneroth> T
<beneroth> thanks for the link, freemint
<freemint> it also contains a link to the relevant specification
<alexshendi> Hi, will any of you picolispers be at 35c3?
<beneroth> me
<freemint> not yet thought about it.
<freemint> of my friends will though
freemint2 has joined #picolisp
freemint has quit [Ping timeout: 272 seconds]