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> tankf33der: hehehe i'll check it out
<rick42> sup, a-dub!
<rick42> tankf33der: your patch works here too. thanks!
<rick42> all tests pass \o/
ubLX has quit [Quit: ubLX]
orivej has quit [Ping timeout: 240 seconds]
<aw-> rick42: hi,
<aw-> what did tankf33der fix?
<aw-> tankf33der: you also write pilAsm? cool!
alexshendi has quit [Ping timeout: 245 seconds]
_whitelogger has joined #picolisp
xkapastel has quit [Quit: Connection closed for inactivity]
<tankf33der> aw-: just a little
<Regenaxer> Cool tankf33der! Congratulations!!
<Regenaxer> Just a minor optim, as I wrote yesterday, 'nul4' check is a *little* better I think
<Regenaxer> Let me change and release it
<Regenaxer> Done
<Regenaxer> Can you test?
<tankf33der> not now but today
<Regenaxer> Great! Thanks!
<Regenaxer> And thanks rick42 again for finding this!
<Regenaxer> But what is *really* frustrating is that nobody discovered it yet!!!
<Regenaxer> This means noone seems to have run the unit tests in the west
<aw-> Regenaxer: what was the bug?
<Regenaxer> The localtime structure contains 32bit numbers
<Regenaxer> signed
<Regenaxer> but the ld4 instruction in pil64 loads an unsigned number
<Regenaxer> So instead of -18000 we get 4294949296 for the zone offset
<Regenaxer> So the sad thing is nobody in the US really uses PicoLisp
<aw-> hmmm
<aw-> localtime?
<Regenaxer> under Linux at least
<aw-> what function?
<Regenaxer> tzo
<aw-> (tzo) ?
<Regenaxer> T
<Regenaxer> Check the irc log for yesterday's discussion
<aw-> just rgrepped all my code, seems I never used it
<Regenaxer> Me neither
<aw-> i know i use (time) and (date) quite a lot
<Regenaxer> but the unit tests do
<Regenaxer> yeah
<aw-> and (datSym) and all those variants
<Regenaxer> 'tzo' would better have been implemented as a native call
<aw-> ok so, tzo isn't used except in unit tests, no harm done ;)
<Regenaxer> Yes, no harm
<Regenaxer> But the trouble is that the unit test complain
<Regenaxer> So nobody noticed and reported
<aw-> hmmm.. the unit tests fail?
<Regenaxer> Since around summer 2017
<Regenaxer> yes, immediately stop
<aw-> why wasn't it noticed?
<Regenaxer> See the irc log
<Regenaxer> That's the question
<aw-> all my computers/servers are in UTC
<aw-> i wouldn't notice any timezone issues
<Regenaxer> yes, and you are east of Greenwhich
<Regenaxer> like me or tankf33der
<Regenaxer> And most other users I know, India, Dubai, China
<Regenaxer> they all have positive tzo
<Regenaxer> Negative is only the Americas and some southern islands ;)
<aw-> ahaha yeah
<aw-> interesting… i don't think we have any customers changing the timezone on their servers with pil
<aw-> could lead to weird bugs if they do change it though.. let me know when the bugfix is out
<Regenaxer> Out already
<aw-> fast
<aw-> ok thanks
<Regenaxer> The fix was easy, I just did not know that it was wrong ;)
<Regenaxer> I dont use (tzo) in commercial projects, but in a few tool scripts here only
<Regenaxer> To fix file timestamps
<aw-> for my apps using timezone I force them to work in UTC with (date T)
<aw-> ahaha
<aw-> easier
<Regenaxer> true
<Regenaxer> But to see my current changes to files I prefer local time
<Regenaxer> As you know, I depend mentally a lot on time stamps. Thats why I don't like Git and other repositories
<Regenaxer> as they destroy this meta info
<aw-> yeah
<aw-> ok well, glad you managed to fix it
<Regenaxer> yeah, and tankf33der's solution was correct too
<Regenaxer> I just had 'nul4' in mind to check for negative
<Regenaxer> BTW, did you get any feedback for your job offering?
orivej has joined #picolisp
alexshendi has joined #picolisp
alexshendi has quit [Ping timeout: 245 seconds]
alexshendi has joined #picolisp
<Regenaxer> During the last years, whenever I had package problems in Debian, it was due to the Python mess
<Regenaxer> Dependencies
<Regenaxer> Non-fixable problems in apt
juscur has joined #picolisp
razzy has joined #picolisp
<Regenaxer> No, I'm wrong. tankf33der's solution is correct, same as in 'native'
<tankf33der> ii want test your version
<tankf33der> lets see
<tankf33der> doing
<Regenaxer> wait
<Regenaxer> it is wrong
<Regenaxer> I want to clean up both cases
<tankf33der> i want test to experience
<Regenaxer> ok, released :)
<tankf33der> yes, its wrong
<Regenaxer> yeah
<Regenaxer> needs 100000000 instead of 80000000
<Regenaxer> but 100000000 is not good on the machine level
<tankf33der> checking
<Regenaxer> So I changed all to the same as native and your version
<tankf33der> testing again both branches
<Regenaxer> ok
<Regenaxer> thanks!
<tankf33der> works all ranges
<tankf33der> even UTC
<Regenaxer> Great! :)
<tankf33der> with 0 result
<Regenaxer> Which 0?
<tankf33der> UTC
<Regenaxer> ah
<tankf33der> works too
<Regenaxer> ok
_whitelogger has joined #picolisp
xkapastel has joined #picolisp
juscur has quit [Ping timeout: 256 seconds]
ubLIX has joined #picolisp
razzy has quit [Remote host closed the connection]
razzy` has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
razzy` has left #picolisp [#picolisp]
razzy has joined #picolisp
ubLIX has quit [Ping timeout: 240 seconds]
<beneroth> thanks Regenaxer and tankf33der
<beneroth> How new is (tzo) ?
<beneroth> the few instances where I need this information, I used some dirty hack
aw- has quit [Ping timeout: 244 seconds]
<tankf33der> tzo since jan2017
<beneroth> so, brand new :P ^^
<Regenaxer> yep
<Regenaxer> In lib/form.l there is a matching one for the client side, "*TZO" global
<Regenaxer> I think it is older
alexshendi has joined #picolisp
<rick42> hello pil people!
<rick42> thanks for fixing issue
<rick42> works here too: http://sprunge.us/4bugR3
<alexshendi> rick42: do you mean the red pil people or the blue pil people?
<rick42> Regenaxer: my issues with running tests is that I am *not* on a linux system, but bsd systems; so the tzo test (which only ran on linux systems) never ran here. anyway that's my excuse :)
<rick42> i was just fooling around with a voidlinux system yesterday ...
<rick42> it was fun, but back to work!
<rick42> alexshendi: lol
<beneroth> rick42, can you recommend voidlinux now?
<rick42> well, not really, b/c i've only played with it for a few hours yesterday.
<rick42> but, so far, I like it
<rick42> the init system is simple and fast ... does that mean it can do whatever you want for your project's purposes? idk
<tankf33der> now i do all on voidlinux for monthes
<tankf33der> 50ram usage after boot, cli only
<rick42> tankf33der: ok. i didn't know that. i guess you like it so far?
<rick42> very nice
<tankf33der> and monocypher tests runs faster
<tankf33der> i dont know why
<tankf33der> i like it, but failed install on xfs, failback to ext4
<tankf33der> who cares, right? :)
<rick42> i used ext4 too
<rick42> i didn't even try xfs :)
<tankf33der> very ok
<tankf33der> from irix ang SGI
<rick42> in the installer when it asked for type of disk partitioning (like EFI), i was looking for MBR, but i only found "dos" so i picked that. :)
<rick42> irix. wow. i havent used irix in more than a decade
<tankf33der> pil works out of box
<tankf33der> tests passed.
<rick42> on irix?
<tankf33der> yeap
<rick42> very nice
<tankf33der> check makefile of pil32
* rick42 goes off to check
<rick42> what did you change? strip -f?
<tankf33der> :)
<rick42> tankf33der: did you do the first irix port of picolisp?
<rick42> pil32
<tankf33der> yea
<rick42> oh alright, then, Regenaxer, you have to change the CREDITS file to add IRIX to the list already beside Mike's name
<rick42> :)
<tankf33der> AIX port was much harder.
<tankf33der> ~20-30h in sum.
<rick42> i'm sure. aix prolly 42% posix compliant? :D
<rick42> wow
<tankf33der> all fight was in makefile. insane.
<rick42> did you need to add any #ifdefs into the code?
<tankf33der> known minimum.
<tankf33der> easy to grep to find out.
<rick42> ha!:
<rick42> PICOLISP-FLAGS = -maix32 -Wl,-brtl -Wl,-bexpall
<rick42> DYNAMIC-LIB-FLAGS = -maix32 -Wl,-G -shared -lm
<rick42> you have to research all this ^^^
<rick42> you *had*
<tankf33der> dont try at home.
<rick42> :)
<tankf33der> afk.
<rick42> ok cu!
<Regenaxer> ret
ubLIX has joined #picolisp
<Regenaxer> Yes rick42, I was aware that you are a BSD (and Mac?) user mainly
<Regenaxer> But in general nobody reported this
<rick42> Regenaxer: why is tzo not tested on non-linux platforms?
<Regenaxer> I think the localtime() call is different
<rick42> ok
<Regenaxer> I added IRIX/Mihail to CREDITS
<rick42> \o/
<rick42> thanks
<rick42> looks like the tm structure is the same between freebsd's libc and glibc
<rick42> but i understand how you don't want/need to be checking this for every c lib
<rick42> the tm_gmtoff field (offset from UTC in seconds) doesn't appear to be in the POSIX standard (I check the opengroup site quickly)
<rick42> so, checking only on linux machines is ok
<rick42> (it just so happened that freebsd libc supported tm_gmtoff also.)
<rick42> openbsd also provides tm_gmtoff: https://man.openbsd.org/localtime
<rick42> netbsd too (openbsd probably inherited it from netbsd :)
xkapastel has quit [Quit: Connection closed for inactivity]
<rick42> for musl, tm_gmtoff can be #ifdefed in. interesting https://raw.githubusercontent.com/esmil/musl/master/include/time.h
<rick42> the #ifdef logic in musl time.h seems to indicate that tm_gmtoff (and tm_zone) are additions/extensions to tm to be found in BSDs and GNU C libs (only?)
<rick42> those were "turned on" in my musl-based voidlinux box -- which is why localtime could return tm_gmtoff there
<rick42> perhaps more than i (and you!) wanted to know about this :)
<beneroth> :)
xkapastel has joined #picolisp
orivej has quit [Ping timeout: 268 seconds]