<Regenaxer>
Anyway, let's try with a modified Makefile first
<Regenaxer>
Changed Makefile, testing
<Regenaxer>
Done, the TGZ got marginally bigger
<Regenaxer>
from 358 KiB to 584
<Regenaxer>
That's tolerable, right?
<Regenaxer>
aw-, can you test it in your setup?
<Regenaxer>
I released it
<tankf33der>
Regenaxer: works.
<Regenaxer>
Cool! :)
<Regenaxer>
I'm very glad we found this solution
<aw->
works
<Regenaxer>
:))
<aw->
Regenaxer: indeed, this is great
<Regenaxer>
I was too much worried about the size
<aw->
.tgz isn't very big
<aw->
584K
<Regenaxer>
yeah
<Regenaxer>
I have a stupid paranoia
<Regenaxer>
Running light without overbyte
<aw->
that paranoia is very much appreciated
orivej has joined #picolisp
<Regenaxer>
ok :)
<aw->
Regenaxer: why does the makefile define ASM, but then $(LIB)/sysdefs: calls clang directly?
<aw->
instead of $(ASM)
<Regenaxer>
oh, yes, stupid
<Regenaxer>
I change it
<aw->
same in lib.bc
<Regenaxer>
Released once more
<Regenaxer>
yeah, fixed
<aw->
sorry
<aw->
oh you spotted it too
<aw->
ok
<Regenaxer>
vip spotted it :)
<aw->
this deserves an announcement on the mailing list
<Regenaxer>
hmm, a bit too early I think
<aw->
haha ok
<Regenaxer>
We get too many questions ;)
<Regenaxer>
Like why (file) does not work :D
<Regenaxer>
scnr
<aw->
:)
orivej has quit [Ping timeout: 240 seconds]
<Regenaxer>
beneroth here?
<Regenaxer>
I abandoned using (+Swap +List +Ref +Link)
<Regenaxer>
+Swap does not work well with external symbols
<Regenaxer>
I use plain (+List +Ref +Link)
<Regenaxer>
+Swap would need to be made more clever
<Regenaxer>
I don't want to start that now
<beneroth>
back now
<Regenaxer>
My use case doesn't actually need it, the list is not such long :)
<beneroth>
ok
<Regenaxer>
Just to keep you informed
<beneroth>
else why not use an explicit separate entity, instead of an "anonymous separate entity" via swap?
<beneroth>
yeah thanks, appreciated :)
<Regenaxer>
yes, this is better
<Regenaxer>
as you said yesterday
<beneroth>
maybe make it even a +Key +List +Link and use request to deduplicate :P
<beneroth>
well depends on the usage
<Regenaxer>
T
<Regenaxer>
A separate entity is more powerful anyway
<beneroth>
T
<beneroth>
costs maybe 2-4 line of codes and a few internal symbols
<Regenaxer>
yeah
<beneroth>
but also more maintainable I think
<Regenaxer>
extendable
<beneroth>
+Swap is really just good for +String when they are not as big to make Blob useful
<beneroth>
yeah
<Regenaxer>
yes, that was the intention
<beneroth>
I like to do Entities with 1-1 joints
<Regenaxer>
right
<beneroth>
for cases where is additional information only required in some objects (if a second parent entity would not make sense)
<beneroth>
or when...in majority of queries only one or the other is of interest, even when its logically 1 single entity/unit
<Regenaxer>
and to make loading fast
<beneroth>
exactly
<Regenaxer>
eg during seach
<beneroth>
a partitioned object/entity, in a way
<Regenaxer>
very efficient in space and speed
<Regenaxer>
memory space, not disk
<beneroth>
T
<beneroth>
disk too, if variation between objects is big, less diversity in object size
<Regenaxer>
indeed, block size
<beneroth>
e.g. I have a general Organisation entity, but actionally multiple types of organisations exist (different business relationship), and a single organisation might be none, one, or multiple of this extra/sub- types
<beneroth>
so I have the organisation-type-specific stuff in a separate metadata entity which has a 1:1 joint to the general organisation
<beneroth>
so also separated indexes
<Regenaxer>
good
<beneroth>
I feel this is a good flexible approach, as I expect longterm many changes to the type-specific metadata and additional subtypes
<beneroth>
decoration instead of inheritance
<Regenaxer>
yeah, decoration is a good term
<beneroth>
I think it is the technical correct one even (well deduced from the Decoration Pattern from GoF)
<Regenaxer>
I see
<beneroth>
and yeah, the lisp view has a bit of "design patterns (especially OOP) are a bit of a language smell"...but I would argue we also have patterns in lisp, for sure
<beneroth>
less need for design patterns than java certainly, because the language is much more flexible/powerful, allows better abstractions
<Regenaxer>
Pattern is a quite overloaded term
<beneroth>
and patterns always are at risk of being cargo culted.. but still some good stuff in there
<beneroth>
T
<Regenaxer>
The compression factor of *.ll is stunning. This shows how redundan the LLVM-IR code really is
<Regenaxer>
I should have tried earlier
rob_w has quit [Quit: Leaving]
<tankf33der>
i think sparc fails because llvm6 has different memcpy declarations.
<Regenaxer>
I see, it is still 6 on sparc?
<Regenaxer>
Perhaps that memcpy version did not exist yet?
<tankf33der>
it has 5 params
<tankf33der>
maybe.
<Regenaxer>
Is sparc still maintained?
<beneroth>
kinda not really
<tankf33der>
all solaris yes.
<beneroth>
there is a FOSS project
<tankf33der>
:)
<Regenaxer>
ok
<beneroth>
Oracle still takes support payments, but they fired all SUN hardware/solaris guys afaik