<rick42>
lolol ---> <Regenaxer> This f*ck* Python stuff
<rick42>
beneroth: \o
<rick42>
i started using python in the early 2000s. it was annoying back then too :)
<Regenaxer>
Hello rick42!
<rick42>
especially when almost all the python coders thought they had to make a class for literally every little thing.
<Regenaxer>
I don't even really use it
<Regenaxer>
I't be happy if I could just install and upgrade it
<rick42>
yes
<Regenaxer>
T, "class for literally every" I saw that when I tried to modify that whawsapp lib
<Regenaxer>
sick
<rick42>
that's a reason why I never got into intalling any ruby-based software ... because you had to install the bloated riby runtime. the sysadmin in me said "enough!" :)
<Regenaxer>
:)
<rick42>
now python is already installed on the machine because other system sw uses it :(
alexshendi has joined #picolisp
<rick42>
so, Regenaxer, not many north americans use pil as compared to europeans (for example)? that's interesting to me
<rick42>
(you had mentioned something like that in the past few days here)
<rick42>
(related to tzo find)
ubLIX has quit [Quit: ubLIX]
<Regenaxer>
yes, at least nobody ran lib/test.l under Linux
<Regenaxer>
(and reported the problem)
<Regenaxer>
South Americans neither ;)
<beneroth>
rick42, you've got a mission
<Regenaxer>
yess :)
<rick42>
lol
<rick42>
me and joebo?
<Regenaxer>
good team
<beneroth>
cyborgar
<beneroth>
he became inactive I think :(
<beneroth>
well I suspect.
<Regenaxer>
yes, quite silent
<Regenaxer>
but gr
<beneroth>
last I know he moved to Chigaco
<Regenaxer>
grp
<beneroth>
Chicago?
<Regenaxer>
Argentina
<rick42>
haha. joebo can help me stand up :)
<Regenaxer>
I mean grp is in Argentina
<rick42>
i thought joebo was in Ohio (not Chicago) news to me
<rick42>
ah user in Argentina! nice!
<Regenaxer>
grp is a long-time user
<Regenaxer>
was at least
<rick42>
ok nice to know
<beneroth>
A shoemaker sent his two sons to a far away country, to look for business opportunities. First son reports back: Sorry Father, no business here, they don't wear any shoes here! - Second son reports back: Amazing business opportunity here! They don't wear any shoes yet!
<Regenaxer>
ok, (tzo) is not often used, and nobody needs to run lib/test.l
<rick42>
excellent!
<Regenaxer>
beneroth, cool
<rick42>
Regenaxer: when I type `./pil +` is that only turning on the `*Dbg` flag? if so, how does that happen? thanks
<Regenaxer>
It turns the *Dbg global on, yes, *before* any files are loaded
<Regenaxer>
So lib.l and following files can do various things
<Regenaxer>
eg remember source infos
<rick42>
ok. the reason why i'm asking is that on freebsd I'm getting:
<rick42>
$ ./pil +
<rick42>
:(
<rick42>
Segmentation fault (core dumped)
<rick42>
i wonder if tankf33der has seen this; if not, it's my "personl problem" lol
<Regenaxer>
what happens with bin/picolisp ? and then bin/picolisp + ?
<rick42>
ill check
<rick42>
i get : prompts in both cases (iow all ok)
<Regenaxer>
ok
<Regenaxer>
then bin/picolisp lib.l +
<rick42>
$ bin/picolisp lib.l +
<rick42>
Segmentation fault (core dumped)
<Regenaxer>
oh
<Regenaxer>
So it is lib.l
<Regenaxer>
probably at the very end
<rick42>
should i start commenting out bits of it?
<rick42>
ok
<rick42>
I'll check
<Regenaxer>
### Debug ###
<Regenaxer>
`*Dbg
<rick42>
right
<Regenaxer>
strange
<rick42>
i.e., i don't have to check above that line -- it's happeing below
<tankf33der>
all freebsd should work
<tankf33der>
never seen this before
<rick42>
thankd tankf33der
<tankf33der>
even freebsd 12
<rick42>
thanks
<Regenaxer>
what if you comment the editor stuff?
<Regenaxer>
(pil "editor") might be destroyed
<tankf33der>
rick42: what version? pil 32 or 64
<rick42>
tankf33der: fyi
<rick42>
$ uname -r
<rick42>
12.0-RELEASE
<rick42>
pil64
<tankf33der>
worked
<tankf33der>
i will try tomorrow
<rick42>
ok personal problem. i will check here thanks
<Regenaxer>
you could $ rm .pil/editor
<Regenaxer>
It will be re-created
<Regenaxer>
or better save it
<rick42>
that was it! y?
<Regenaxer>
mv it
<Regenaxer>
oh
<Regenaxer>
We could inspect it to find out what happened
<Regenaxer>
removed already?
<rick42>
before i rm-ed it:
<rick42>
$ ls -l /usr/home/rick/.pil/editor
<rick42>
-rw-r--r-- 1 rick rick 0 Sep 26 13:42 /usr/home/rick/.pil/editor
<rick42>
empty file
<Regenaxer>
ah
<Regenaxer>
loading should work though
<rick42>
yes + works now
<Regenaxer>
Good
<Regenaxer>
still a little strange
<rick42>
check this out:
<rick42>
$ bin/picolisp lib.l +
<rick42>
: ^D
<rick42>
$ touch ~/.pil/editor
<rick42>
$ bin/picolisp lib.l +
<rick42>
Segmentation fault (core dumped)
<rick42>
wha??? :)
<Regenaxer>
hu
<Regenaxer>
I tried here, works
<Regenaxer>
So only BSD version has problems?
<rick42>
tankf33der: are you at a freebsd 12 box? can you try?
<tankf33der>
not today
<rick42>
ok
<rick42>
now that it's broken, i'll go back to commenting out lib.l
<rick42>
but first, lunch. priorities :)
<Regenaxer>
yeah!
<tankf33der>
freebsd 12 x64?
<rick42>
(at tzo -18000, it's lunchtime now :)
<rick42>
tankf33der: yes
<tankf33der>
ok
<tankf33der>
what about pil32?
<tankf33der>
how you bootstrap pil64?
<rick42>
with the .s files
<tankf33der>
java? pil32? sysdef?
<tankf33der>
ok
<Regenaxer>
Later you could check to load a normal empty file
<rick42>
i can try pil32 but i have to install gcc :)
<rick42>
hehehe
<tankf33der>
its ok
<Regenaxer>
(out "a") (load "a")
<Regenaxer>
on a process without (pil "editor") of course ;)
<Regenaxer>
To see if it chokes on loading an empty file in general
<beneroth>
Regenaxer probably doesn't really use shared hosting
<Regenaxer>
yes, and I fixed the issue I think, but thanks tankf33der
<Regenaxer>
Not shared hosting, but many domains for a single certificate on one server
<beneroth>
shared hosting would be multiple separate virtual hosts on the same server, and usually shared hosting means the separate virtual hosts are owned by different people/clients
<Regenaxer>
yes
xkapastel has joined #picolisp
alexshendi has joined #picolisp
<beneroth>
Regenaxer, what is TAB in picolisp?
<beneroth>
^I
<beneroth>
thanks
<rick42>
Regenaxer, tankf33der: here is the reason for abending:
<rick42>
$ bin/picolisp
<rick42>
: (info "lib.l")
<rick42>
Segmentation fault (core dumped)
<rick42>
not getting file/dir info from OS
<tankf33der>
ok
<rick42>
beneroth: you're so good at pil, you're answering your own questions! lol
<tankf33der>
make sense
<tankf33der>
probably f12 did break up api and we will have to split before f12 and after
<rick42>
ah
<rick42>
prolly stat(2)
<Regenaxer>
beneroth, or "\t"
<Regenaxer>
So probably tankf33der is right and the sys/*defs are not matching (any more)
<tankf33der>
f12 release candidate worked
<Regenaxer>
I see
<rick42>
tankf33der, fyi my box is at p2:
<rick42>
$ freebsd-version -uk
<rick42>
12.0-RELEASE-p2
<rick42>
12.0-RELEASE-p2
<tankf33der>
i dont have installed f12
<tankf33der>
see f11x64 only
<tankf33der>
tomorrow
<rick42>
many thanks tankf33der
<tankf33der>
cant sleep
<tankf33der>
downloading f12
<tankf33der>
lets see
<rick42>
hehe
<rick42>
here's something unexpected. i have an older version of pil on this same f12-p2 box and it works!
<rick42>
$ ls -l bin/picolisp
<rick42>
-rwxr-xr-x 1 rick rick 206112 Oct 1 2017 bin/picolisp
<rick42>
$ bin/picolisp
<rick42>
: (version)
<rick42>
17.9.27
<rick42>
-> (17 9 27)
<rick42>
: (info "lib.l")
<rick42>
-> (12380 736702 . 43349)
<rick42>
why?
<beneroth>
interesting
<rick42>
i keep old versions :)
<rick42>
I have the tarball -- i will rebuild it
<tankf33der>
lets check installation from scratch and sleep then
<beneroth>
tankf33der, you don't need to do this :)
<beneroth>
you're awesome
<rick42>
agreed (on both counts). get some rest
<rick42>
Rebuilt 17.9.27 and now is segfaulting -- getting closer
<rick42>
$ bin/picolisp
<rick42>
: (version)
<rick42>
17.9.27
<rick42>
-> (17 9 27)
<rick42>
: (info "lib.l")
<rick42>
Segmentation fault (core dumped)
<rick42>
old and new build file sizes:
<rick42>
$ ls -l ~/{work,builds}/picoLisp-17.9.27/bin/picolisp
<rick42>
-rwxr-xr-x 1 rick rick 206112 Oct 1 2017 /usr/home/rick/builds/picoLisp-17.9.27/bin/picolisp
<rick42>
-rwxr-xr-x 1 rick rick 215928 Jan 29 16:03 /usr/home/rick/work/picoLisp-17.9.27/bin/picolisp
<rick42>
i see (what you two where talking about earlier). i'm a bit slow :)
<Regenaxer>
np :)
<Regenaxer>
Should we change the build process in general?
<beneroth>
I'm barely usable anymore today :(
<Regenaxer>
So that it *always* uses sysdefs?
<Regenaxer>
Yeah, me too
<rick42>
beneroth: get rest!!! :)
<beneroth>
would make sense, no? it probably will not increase build time significantly, no?
<rick42>
Regenaxer: maybe
<Regenaxer>
No, build time does not matter
<rick42>
T
<beneroth>
rick42, I don't want to. I need to finish this (nearly done) and I would be motivated to do more. (maybe unable ...)
<Regenaxer>
Needs a C compilation pass
<Regenaxer>
Currently only emu uses sysdefs iirc
<beneroth>
would this be an added built dependence for C compiler? clang compatibility etc?
<Regenaxer>
Not sure about what it involves
<beneroth>
s/dependence/dependency
<Regenaxer>
I don't remember now
<beneroth>
C compiler is not needed for building pil64 now, no?
<Regenaxer>
yes, not needed
<beneroth>
so this would be an additional dependency
<Regenaxer>
But usually available
<beneroth>
yeah, and prolly clang compatible too, not gcc-only (like pil32)
<beneroth>
that should be checked
<Regenaxer>
yes, plain C
<Regenaxer>
the mkAsm scripts need to be changed
<Regenaxer>
hmm, but not enough
<Regenaxer>
there are the *defs files, but also *code
<Regenaxer>
So there is never a complete independence
<Regenaxer>
We are talking only about the src64/sys/*.defs.l files here
<rick42>
T
<Regenaxer>
*code.l might change too
<Regenaxer>
(though less probable)
<Regenaxer>
In Linux never anything changed so far
<Regenaxer>
x86, ppc64 and arm64
<Regenaxer>
Not sure at the moment if it would be a good idea
<Regenaxer>
To change the build processes
<rick42>
huh. gened the new defs and make clean && make, and now the linker complains about "undefined reference to `stderr'". also s/stderr/stdin and s/stderr/stdout
<Regenaxer>
Better than now at least
<Regenaxer>
yes
<Regenaxer>
*code.l
<Regenaxer>
Hand-coded parts
<rick42>
that needs changing too?
<rick42>
ok
<Regenaxer>
I don't know the *BSD systems
<rick42>
less src/*code*
<Regenaxer>
src64/*.code.l
<rick42>
sorry wrong terminal lol
<Regenaxer>
src64/sys/*.code.l
<Regenaxer>
;)
<rick42>
yes
* rick42
just keeps typing until the computer says it's ok
<Regenaxer>
:)
<rick42>
i have NO idea what to add there :)
<Regenaxer>
I looked at what the C compilers generate
<Regenaxer>
little test C progs
<rick42>
ah
<Regenaxer>
tedious
<Regenaxer>
But I don't remember if I or someone else did he bsd versions
<rick42>
mansur's name is in this one
<Regenaxer>
yeah!
<rick42>
it's *his* fault! lol
<Regenaxer>
:(
<rick42>
just kidding ofc
<Regenaxer>
sure
<Regenaxer>
So it seems that libc was completely changed in freebsd meanwhile
<rick42>
hmmm. yeah lotsa changes in the stat block
<rick42>
of commands
<Regenaxer>
They obviously did not get it right in the first try
<rick42>
hehehe
<rick42>
funny, because file info should be a stable thing now
<Regenaxer>
Not sure what they changed
<rick42>
are they trying to do something fancy like incorporate zfs? i have no idea.
<Regenaxer>
Not on that level
<rick42>
"one interface to rule them all"
<Regenaxer>
not in stat
<rick42>
right
<Regenaxer>
You think the *code.l needs to be changed too?
<Regenaxer>
defs is easy
<rick42>
honestly, i ahev NO idea
<Regenaxer>
taking stuff from sysdefs
<rick42>
have
<Regenaxer>
Lets wait for master tankf33der
<rick42>
agreed :)
<Regenaxer>
:)
<Regenaxer>
Too late here *not* to break things
<Regenaxer>
family is sleeping already
<rick42>
smart
<Regenaxer>
:)
<rick42>
ok you should too! :)
<rick42>
thanks for your help as always!
<Regenaxer>
Thanks a lot for investigating!
<beneroth>
maybe they changed the glibc ?
<Regenaxer>
probably
<beneroth>
eh libc, away from glibc xD
<rick42>
like Reg said libc
<Regenaxer>
some structures
<rick42>
hehehe beneroth
<beneroth>
the big thing about linux is ABI compatibility, so they ensure to not change things whenever possible :)
<Regenaxer>
beneroth, dont struggle too long today!
<rick42>
T
<beneroth>
yeah I finished my work
<beneroth>
successfully :)
<rick42>
\o/
<Regenaxer>
The ABI is on the processor arch level
<Regenaxer>
seems the same on all OSes
<beneroth>
export from filemaker, import into pil DB, some data cleaning, special export :)
<Regenaxer>
ABI is concerned about register usages etc
<beneroth>
ok, then API
<beneroth>
T
<Regenaxer>
yes
<beneroth>
ABI is more about compilers, e.g. padding in struct etc.