karswell_ has quit [Remote host closed the connection]
karswell_ has joined #picolisp
<Nistur>
Regenaxer: this may be a bit of a silly question, but if I'm writing a C<-->pil wrapper for imagemagick, would you like for me to pull it out as a standalone pil library, so other people might be able to use it? Would anyone be interested in it?
<Regenaxer>
Not sure. In my view, pil32 is quite obsolete, so I would not waste too much effort on it
<Nistur>
well... my intention is that I'll get my program working in pil32 because that's what I have working now... then I'll extend the native wrapper to support pil64... it will mean rewriting a bunch of stuff, sure, but I will have a test case then to make sure it all works fine
<Regenaxer>
For pil64 we need no wrapper
<Nistur>
hmmm, so it will just be a (de im:genesis () (native "libMagickWand.so" "MagickWandGenesis")) :P
<Nistur>
but having a look at the MagickWand stuff, there are a few things which might make sense to be more lispified, rather than just exposing everything directly
<Regenaxer>
Yes, but still it is a completely different glue. Basically just one-liners I would think
<Nistur>
also, pil32 works on all my systems without problem, even the 64 bit computers I have have more issues with pil64... I will admit to not having tried particularly hard on my linux x64 system, but as I said, it's the computer I use least frequently, so even if that does work, it doesn't help my development overly much... I couldn't get pil64 running natively on macOS, or as emu on any machine... so even
<Nistur>
if pil32 is obsolete, it's the solution I have that works :P
<Regenaxer>
Perhaps not completely obsolete :)
<Regenaxer>
But all new things went into pil64
<Nistur>
like native :P
<Regenaxer>
I definitely would go with emu
<Regenaxer>
yes
<Regenaxer>
or coroutines and namespaces
<Nistur>
is there a reason they couldn't be backported to pil32? If I decided I needed one of them _could_ I make them work do you think?I am not sure I do, I'm just curious :)
<Regenaxer>
also some debug things and DB acceses
<Regenaxer>
yes
<Regenaxer>
It needs assembly in most cases
<Regenaxer>
well, coroutines need it
<Regenaxer>
namespaces could be implemented, but it is a lot of work
<Regenaxer>
pil32 uses a different hashing internally
<Nistur>
I don't think that I will need any of those things for my current project... buuuuuuuuuuuuuuut it may be something which would interest me to do in future, to try and get more feature parity... as a learning exercise the same as all my other projects :) I tend to pick projects which are barely useful just to see how they'd work
<Regenaxer>
yes, good thing :)
<Regenaxer>
Even mobile devices are mainly 64-bit these days
<Regenaxer>
And Apple prohibits 32-bit Apps
<Nistur>
I am not saying I'm normal by any means, but I own more 32 bit devices than 64 bit ones
<Regenaxer>
yes, you said
<Nistur>
I probably have approaching the same amount of 16 bit ones too :P
<Nistur>
and a couple of 8 bit ones
<Nistur>
apparently I also own a device with a hybrid 64-bit/20-bit CPU, that acts like a 4-bit processor
<Nistur>
my beloved HP-48G calculator :P
<Regenaxer>
cool :)
<Nistur>
I'm not saying that I'll get pil working on my calculator... but if I had some time off work, it would be quite high on my list of things to try to do for the hell of it :P
<Regenaxer>
yep, but the 'emu' ;)
<Regenaxer>
s/the/then
<Nistur>
Regenaxer: as you weren't aware of the compiling sword fighting, do you know xkcd at all?
<Regenaxer>
sure
<Nistur>
ahh, so you know the two comics I was going to link then :P
<Regenaxer>
The first one yes, but not the second :)
<Nistur>
:)
<Regenaxer>
The first one I found (and saved the image) even before I knew xkcd
<Nistur>
if you save the image, you lose the alt text though!
<Regenaxer>
Anyway, don't you give 'emu' another try on your systems?
<Regenaxer>
As I understand it, the problem yesterday had to do with -fpic
<Regenaxer>
Position-independent code
<Nistur>
well, for my Asus transformer (x64 CPU, but running x86 OS because of reasons) emu builds
<Regenaxer>
ok, good to know
<Regenaxer>
iirc it complained about symtab
<Regenaxer>
*FPic (bool (opt)) in src64/mkAsm.l
<Nistur>
I think I've changed the source folders since I've tried last time... I THINK I got the previous attempts from the website directly, but now everything's pointing to the bitbucket I was linked to the other day
<Regenaxer>
(if *FPic
<Regenaxer>
(in "emu.symtab"
<Regenaxer>
(setq
<Nistur>
this version builds on my pi as well
<Regenaxer>
is it the newest?
<Nistur>
from bitbucket, yes, as of yesterday
<Nistur>
I didn't pull today
<Regenaxer>
good
<Regenaxer>
Latest is from 10th
<Nistur>
ok, macOS still complains
<Regenaxer>
But these things did not change anyway
<Regenaxer>
"emu.symtab" thing?
<Nistur>
yup
<Regenaxer>
It must be this *FPic issue
<Regenaxer>
in Makefile:
<Regenaxer>
./mkAsm $(ARCH) "$(SYS)" $(FMT) $(OS) base "" ...
<Regenaxer>
the "" corresponds to *FPic in mkAsm.l
<Regenaxer>
So strange, it must be NIL (ie. "")
<Regenaxer>
Perhaps it needs a 'make clean' first? Some old stuff lying around?
<cess11_>
At least from a programmers perspective, most people will like the shiny surfaces.
<Regenaxer>
Let's see
<Nistur>
Regenaxer: I got it to compile btw... the issue was that you have marked a bunch of things as extern, but then when you link it, you don't have emu.base.o in that library, so it cannot find it... if I add emu.base.o to all 3 targets it compiles...
<Nistur>
doesn't run of course :D segfault :P
<Regenaxer>
hmm, so it is a different handling of the extern directive in the C compiler?
<Regenaxer>
Strange indeed
<Regenaxer>
And why "of course" crashing?
<Nistur>
because nothing is going right for me :D
<Regenaxer>
oh ;)
<Regenaxer>
It is that stupid Apple/Clang stuff
<Nistur>
wasn't meant to be a statement of your code, don't worry :P
<Nistur>
it shouldn't be, I'm using gcc
<Regenaxer>
ah, even more strange
<Regenaxer>
Then why these 'extern' issues?
<Regenaxer>
"add emu.base.o" is no good idea
<Regenaxer>
You duplicate all the code
<Nistur>
yup, I thought so
<Regenaxer>
and it is not clear what is called
<Nistur>
http://ix.io/17B6 but that's what I have to make it compile and link so far
<Regenaxer>
So the shared libs should not contain the base system
<Regenaxer>
Marking as extern in C is fine
<Nistur>
I don't disagree. I was just seeing if it would solve that error
<Regenaxer>
The linker must take care of it
<Regenaxer>
ok, yeah
<Regenaxer>
It must be some linker option
<Regenaxer>
The SHARED options
<Regenaxer>
ah, because you removed the xx-dynamic-yy thingy ;)
<Nistur>
I have a mac mini set up at home... I also have a cisco switch in my attic... not that I don't trust you, but if I get around to it, I can set it up so it's on a separate network than my home network, and you can use it to test on :P
<Regenaxer>
Something is needed to link it as a shared lib
eeproks has quit [Remote host closed the connection]
<Regenaxer>
We must find out why "-export-dynamic" cannot be used
<Nistur>
I have it compiling nicer now, I copied some flags from the 32 bit makefile :P
<Nistur>
it's still segfaulting
<Nistur>
so I'm checking out what gdb says
<Nistur>
I assume, even when running picolisp without any files (ie not through pil) then it still loads and parses some lisp, based on what it's doing here...
<Nistur>
my stuff is really not important at all :P I can use pil32 quite happily :P
<Regenaxer>
Would be nice to have emu running on Darwin though
<Regenaxer>
I think Jon Kleiser (Mailing list) got it running there some time ago
<Nistur>
I should probably sign up for the mailing list
<Regenaxer>
yes, but you can also browse the archive
<Nistur>
I just meant in general :)
<Regenaxer>
yes, good idea
<Nistur>
how much of pil32 is portable, d'you think? I mean, if I actually tried to build it on my PS2, which has the linux kit on it, so I've got a proper POSIX environment, with a(n albeit ancient) Linux kernel and a gcc toolchain...
<Regenaxer>
Is quite portable then I think. More than pil64
<Nistur>
sounds fun :D
abel-normand has quit [Ping timeout: 260 seconds]
<beneroth>
hi all
<Regenaxer>
Hi beneroth!
<beneroth>
Regenaxer, will look into this Fuchsia news. though new Google OS does not necessarily mean that android mobiles will be a thing of the past. maybe some other company continues to develop and support it (e.g. Samsung or so?)
<Regenaxer>
Yeah, I expected that too. There is a huge Android code base meanwhile
<beneroth>
but yeah, so it comes as expected: Google goes opensource path to get support & gratis work by community, and then when the platform captured the market they go EEE. seems it was too hard to get the EEE fully through via proprietary pre-installed apps :/
<beneroth>
similar story as with Google+ (XMPP/Jabber bridge) and other stuff
<cess11_>
I think so too.
orivej has quit [Ping timeout: 268 seconds]
<Nistur>
Regenaxer: ok, so using pil64 native, say I have a pair of functions in the .so which are: SomeContext* CreateContext(void); SomeContext* DestroyContext( SomeContext* ctx );... and let's say that I want to have two glue functions which for testing purposes do (destroy_context (create_context))... how would I pass things between them?
<Nistur>
(native libname "CreateContext" 'N) I _think_ is the first one, but the second appears to be incorrect somehow
<Nistur>
oh wait
<Nistur>
ignore me
<Nistur>
I forgot to put the return type in the native call
<Nistur>
:D
<Nistur>
I have no idea whether it's right yet, but I've hit some error reporting in the .so, so the fact it's NOT complaining now makes me happy