mario-go` has quit [Quit: ERC (IRC client for Emacs 25.1.1)]
mario-goulart has joined #picolisp
rob_w has joined #picolisp
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
mtsd has joined #picolisp
razzy has quit [Quit: Connection closed]
miskatonic has joined #picolisp
orivej has joined #picolisp
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #picolisp
rob_w has quit [Quit: Leaving]
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
<aw->
hi all
<Regenaxer>
Hi aw-
<beneroth>
hi aw-, Regenaxer :)
<Regenaxer>
Wuff, another project release! Cool
<Regenaxer>
That's why you need to detect deceased parents
<beneroth>
yeah
<beneroth>
aw-, awesome! I will definitely use this soonish!
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #picolisp
razzy has joined #picolisp
<razzy>
tomorow jitsi?
<Regenaxer>
razzy, no, 3rd of July
<Regenaxer>
see announcement in Mailing list
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #picolisp
<razzy>
so only first fridays?
<Regenaxer>
No, first and third
<Regenaxer>
8 and 16 UTC
<razzy>
tomorrow is third friday in month
<beneroth>
you like to present something?
<Regenaxer>
razzy, true
<razzy>
um, no. i would like to have training in llvm
<razzy>
but also i have trip with kids, so i would be able only to listen
<Regenaxer>
My knowledge in LLVM is not more (in fact even much much less) than what is in the ref I posted here
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #picolisp
<razzy>
well yes, but it has many pages. i estimated a month of trials end errors before i would be able to think about valid changes to pil21 sources.
<razzy>
Regenaxer: show of your workflow would reduce that time.
<razzy>
but again, i would be only partially present tomorrow.
<Regenaxer>
tomorrow isn't a meeting anyway ;)
<beneroth>
razzy, yeah so better on the 3rd when you might not be on a trip and then you can fully participate :)
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
<razzy>
i am looking at mailing list. I did not find discussion points for 3rd.
<Regenaxer>
Yes, it says "every second Friday"
<Regenaxer>
We discussed here in irc about 1st and 3rd
<Regenaxer>
I wrote that in the mail on 3rd of June and askid for comments, but nobody objected
<beneroth>
there was no other discussion
<beneroth>
there aren't (yet?) any dicussion points defined for 3rd
<razzy>
i mean, program. what will be talks about
<beneroth>
we know as much as you do
<razzy>
if llvm is there, i will go great lengths to be there.
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #picolisp
<Regenaxer>
good
<Regenaxer>
LLVM will surely be an issue, not sure when
<Regenaxer>
pil21 is perhaps too early still
<beneroth>
Regenaxer, I really grokked namespaces
<Regenaxer>
Great! :)
<beneroth>
and I see more practical issues when heavily combining pilDB and namespaces, at least when working with multiple ones
<Regenaxer>
:)
<beneroth>
the interning of property names is really impractical....
<beneroth>
maybe I can compile some code for illustration
<Regenaxer>
But if properties were not interned, we could not make private properties
<Regenaxer>
and access is a lot slower
<beneroth>
T
<Regenaxer>
"equal" comparisons
<beneroth>
but in pilDB context there are a lot of properties around... including index root nodes etc.
<beneroth>
my current case was
<beneroth>
Entity, fully in 'pico
<beneroth>
function in 'foo, (symbols 'foo 'pico)
<beneroth>
function does (iter (tree 'nr '+BarEntity E)) (yes with Hook)
<Regenaxer>
Perhps the rule should be not to invert the search order
<beneroth>
nr was not interned previously in 'pico, ends up in 'foo, does not match with the tree root node name
<Regenaxer>
yes
<beneroth>
congratulation
<Regenaxer>
if the order stays the same, it does not matter where it is
<beneroth>
I didn't though you will be able to talk yourself out of this, but you just did
<beneroth>
:D
<Regenaxer>
not really
<Regenaxer>
I did not stick to that rule ;)
mtsd has quit [Quit: Leaving]
<beneroth>
I just understand you as I could solve my issue
miskatonic has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
<beneroth>
by doing (symbols 'pico 'foo) even when I put my function into 'foo
<beneroth>
yeah will try that approach
<beneroth>
how practical it is
<beneroth>
technically sound
<beneroth>
thanks, Regenaxer
<Regenaxer>
yes, me too
<Regenaxer>
I must check the PilBoxes again under this aspect
<beneroth>
eventually we need to document some kind of convention for practical namespace usage
<beneroth>
then maybe it gets more popular
<Regenaxer>
exactly
<beneroth>
it's very involved
<Regenaxer>
yeah
<beneroth>
it's in the "C++ too much power" territory a bit, if you know what I mean :)
<Regenaxer>
the namespaces can be manipulated inside libs (like in pil21/src/llvm.l), but an app must load and use them in constant order
<beneroth>
aye
<Regenaxer>
interesting stuff :)
<beneroth>
my current plan is to have all entities/relations/etc (everything in DB) in 'pico
<beneroth>
even when libraries my work with them
<beneroth>
library functions etc. usually in a library-specific nsp
<Regenaxer>
yes
<beneroth>
of course this doesn't rule out working with a nsp and database stuff per se, can be useful for special use cases e.g. your legacy db import/ext use case
<beneroth>
but this is very special
<beneroth>
okay
<beneroth>
thanks :)
<Regenaxer>
thanks to you for digging into it
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #picolisp
DKordic has joined #picolisp
razzy has quit [Quit: Connection closed]
<beneroth>
Regenaxer, an idea might be to support 2 nsp search orders, one for fetching (current one) and one for new interns.
<beneroth>
e.g. (symbols 'foo 'pico) search symbols first in foo, than in pico. but when not found create them always in 'pico
<beneroth>
(locale) can be used to clearly define symbols in a specific namespace
<beneroth>
just an idea, not sure how feasible
<Regenaxer>
I think this does not change anything
<Regenaxer>
creating in pico
<Regenaxer>
(pico foo) has the same effect
<beneroth>
it would make it much easier to ensure local variables and especially property names end up in pico
<Regenaxer>
ie searches both, then creates in pico
<beneroth>
yes, but the order matters. now pico shadows foo
<beneroth>
I would like to createby default in pico, but let foo shadow pico
<Regenaxer>
Hmm, this makes it even more confusing
<beneroth>
of course possible by explicitly using nsp prefixes everywhere.. but well
<beneroth>
I have a library which has its own namespace, and uses the namespace 'fs to call functions from the filesystem library
<beneroth>
but in the current library I'm also constructing objects and properties which should end up in 'pico
<beneroth>
of course possible by explicitly using nsp prefixes everywhere.. but well
<Regenaxer>
To have them end up, 'export' is good
<beneroth>
another solution is of course at the beginning of the library file to (locale) all symbols into pico intended for property names which are not used otherwise..
<beneroth>
also ugly
<beneroth>
ah right
<beneroth>
right I forgot about export
<Regenaxer>
I use that for pilog in pil21
<beneroth>
I like to wish it for pil64 :P
<Regenaxer>
not in pil64 yet
<Regenaxer>
yes
<beneroth>
aye, I've got use cases :d
<beneroth>
:D
<beneroth>
hehe
<Regenaxer>
Perhaps for now you can steal it from pil21?
<Regenaxer>
So we can test it
<Regenaxer>
then into pil64 any time, it is easy
<beneroth>
you mean: I should implement it and patch my pil64 with it? that is a possibility
<Regenaxer>
just needs doc etc.
<Regenaxer>
just copy to a local file
<Regenaxer>
it is in lib.l
<Regenaxer>
besides 'local'
<beneroth>
yeah I can surely do the docs. not sure if I'm brave enough to write pil asm, but I could try
<beneroth>
ah
<Regenaxer>
No asm needed
<beneroth>
hahaha
<beneroth>
I see
<beneroth>
ok will do
<beneroth>
thx
<Regenaxer>
a 3 liner :)
<Regenaxer>
If it turns out useful, I put it into standard lib.l
<beneroth>
what's the link to your pil21 distro again? or should I take it from the repo?
<beneroth>
yes, you might export something to the third nsp which is already shadowed in your file by the 2nd nsp
<beneroth>
but this might be legitime and intended
<Regenaxer>
I dont think so, because you cannot use it then without nsp~
<beneroth>
the point of such games (basically any nsp usage besides just dropping everything into a separate one like in pilbox) is to have clearly separated internal trees, which you end up using intermixed
<beneroth>
you can change the search order and you're good
<beneroth>
I basically look at libraries and nsp as: each library is populating (= interning into) their namespace. in the main application / top level I use pico and either a fitting search order or nsp prefixes
<beneroth>
libraries might use other libraries, so they can use their own search order where feasible
<Regenaxer>
I decided not to use pico as app nsp
<Regenaxer>
always a private on
<beneroth>
so you also have an app nsp?
<Regenaxer>
(symbols 'ap 'htm 'pico)
<beneroth>
for what? when you want to add another layer on top of the add / using the app somewhere?
<Regenaxer>
To avoid having pico the first
<Regenaxer>
the rule is not to change the order
<beneroth>
smells like YAGNI to me, as if when the need arises you can still do that by just putting a (symbols) in front of the (load) to load everything
<Regenaxer>
between loading and running
<beneroth>
hmmm
<beneroth>
T
<Regenaxer>
The htm lib says (symbols 'htm 'pico)
<beneroth>
goes against my approach
<beneroth>
completely
<Regenaxer>
You could also use (symbols 'htm 'pico) in the app
<beneroth>
yeah but what about having more than 1 library on the same level? how to decide the order then?
<Regenaxer>
but then app symbols go to htm
<beneroth>
e.g. A, B, C
<beneroth>
A: (symbols 'a 'pico)
<Regenaxer>
this is not so critical
<beneroth>
B: (symbols 'b 'pico)
<beneroth>
C: (symbols 'c 'pico)
<Regenaxer>
as long as you don't change the order
<beneroth>
resulting app using all three
<Regenaxer>
yes
<beneroth>
(symbols 'c 'b 'a 'pico) ?
<Regenaxer>
(ap c b a pic|)
<beneroth>
and now you remove 'b library and replace with 'x library
<Regenaxer>
the point is never to *reverse* the order
<beneroth>
I don't see how this is less of a longterm maintenance horror
<Regenaxer>
What horror?
<beneroth>
I want to have the possibility to re-arrange and add/remove libraries over the course of the software project
<beneroth>
as one library might replace another
<Regenaxer>
yes, good, just keep the order
<beneroth>
or might not be needed anymore
<beneroth>
or new one is required for a new feature
<beneroth>
well if we keep the order
<Regenaxer>
yes
<beneroth>
then we have the stuff within the libraries private, good
<beneroth>
but on the app/main scope
<beneroth>
you must still kinda ensure no shadowing/clashes of global names
<Regenaxer>
the point is that non-localized symbols fall through
<Regenaxer>
for definitions you get a redefined
<Regenaxer>
for properties it is not critical where exactly they reside
<beneroth>
I would go as far and having only (symbols 'pico) in the app/main level. all access to other namespaces is not implicit (which is the case with search order) but explicit with prefix or (import)
<Regenaxer>
That's ugly
<beneroth>
for properties it is not, as long you don't want to access them cross-namespace
<beneroth>
then its ugly
<Regenaxer>
no, but if the "a" lib has (a pico)
<beneroth>
only if the property name got exported before
<Regenaxer>
then in the app it should be 'a' before 'pico'
<beneroth>
yes
<beneroth>
and then you make an object
<beneroth>
like
<beneroth>
in 'a you have a function which returns a list of objects (non-database objects)
<beneroth>
all property access you do outside of 'a needs to be prefixed
<beneroth>
I want to have a function with the same name in other libraries
<beneroth>
well the ability to have it
<beneroth>
and still call both from top level when it makes sense
<Regenaxer>
If you don't change the search order while the program runs, you have none of such problems
<Regenaxer>
with properties
<beneroth>
then I can define symbol names in each library as I want, not having to think about the environment in which the library gets used (which I might know nothing about during time of writing)
<beneroth>
T
<Regenaxer>
So what is your proposal?
<beneroth>
but without changing search order, the power and usefulness of namespaces is mostly wasted
<Regenaxer>
No, *changing* the namespaces per se is OK
<Regenaxer>
The *order* should not be changed
<Regenaxer>
'a' was loaded in (a pico)
<Regenaxer>
'b' was loaded in (b pico)
<Regenaxer>
'c' was loaded in (c pico)
<Regenaxer>
You have you app (ap a c pico)
<Regenaxer>
then later (ap b pico)
<Regenaxer>
etc.
<Regenaxer>
The relative order stays the same
<Regenaxer>
And 'c's symbols are either in 'c' or in 'pico'
<Regenaxer>
'b's are in 'b' or 'pico' etc.
<beneroth>
yes, I like to call functions from all namespaces
<beneroth>
in ap
<Regenaxer>
good
<beneroth>
while not having to worry about them clashing
<Regenaxer>
exactly
<Regenaxer>
They may be overshadowing
<Regenaxer>
So 'pp' might be useful ;)
<beneroth>
(ap b pico)
<beneroth>
how to call something from c?
<beneroth>
prefixing or?
<Regenaxer>
You decide on top of a file the order
<Regenaxer>
(ap c b pico)
<beneroth>
yeah so every file might have another order
<Regenaxer>
I never used prefixes in applications so far
<Regenaxer>
only pil21/src/lib/llvm.l, but that is special
<beneroth>
I tend to see the prefixes as the main way, and the search order as a way to syntax sugar the prefix way
<Regenaxer>
I would not access c~foo without c in the search order
<beneroth>
aye, that I expected
<beneroth>
so if you require c~foo in your app, you do (ap c b pico)
<Regenaxer>
You "declare" on top of the file your intention
<beneroth>
yes
<Regenaxer>
i.e. to use 'c'
<beneroth>
and now you have to worry during writing of 'c library that no name in it is shadowing anything from 'b you might end up needing in your app
<Regenaxer>
perhaps
<Regenaxer>
real-live example:
<Regenaxer>
We have (already now) lib/ps.l and lib/svg.l
<beneroth>
while not knowing that you even will have a 'b library and an app, because you write the 'c library independent of that for another app
<Regenaxer>
they have many identical functions
<beneroth>
good example
<beneroth>
yeah
<Regenaxer>
rect, ps, font etc
<Regenaxer>
So we can do (ap ps pico) to use postscript
<Regenaxer>
and (ps svg pico) to use svg
<Regenaxer>
depending on the situation
<beneroth>
yes, and when we use both, because we offer both exports...
<Regenaxer>
I meant: and (ap svg pico) to use svg
<beneroth>
on app level, I would stay solely in (symbols 'pico) and do svg~rect and ps~rect
<Regenaxer>
svg and ps never make sense together
<beneroth>
or use (symbols 'lst 'prg) for syntax sugar
<beneroth>
why not? your app offers download of postscript report and as svg file
<Regenaxer>
No, svg~rect is not good
<Regenaxer>
It may be identical code
<Regenaxer>
ignorant of the namespace
<Regenaxer>
(font "Helvetica") (ps "foo")
<Regenaxer>
a prefix would be bad here
<Regenaxer>
You switch the behavior by just setting the search order when loading
<beneroth>
where is your identical code? in the implementation of (rect) ? or you mean the code calling both these libraries?
<Regenaxer>
ps then with ghostscript, and svg with rsvg-convert
<beneroth>
miskatonic, the older solution to create PDFs with pil was based on PostScript, a newer approach is based on SVG. both can also used to just create SVG/PS stuff independently
<Regenaxer>
I switched to svg because there is no ghostscript on PilBox
<beneroth>
ah that was the reason?
<beneroth>
I thought that the SVG way is just more powerful or so
<beneroth>
flexibler/easier
<Regenaxer>
I did not find *any* good support to generate PDF on Android
<Regenaxer>
Yes, that too
<beneroth>
yeah
<beneroth>
android only pretends to be a general computing device
<Regenaxer>
well, not so flexible, it needs XML like structures
<Regenaxer>
so more strict
<beneroth>
it is a crippled general computing device
<Regenaxer>
PostScript is a kind of Forth
<Regenaxer>
more free
<beneroth>
okay
<Regenaxer>
A big pain it was to generate a document stretching several pages
<beneroth>
yeah I believe PostScript can be used to make network printers into port scanners, at least under some conditions maybe
<Regenaxer>
each page must be a <svg>
<Regenaxer>
In postscript I just say "draw page" and "new page" (forgot the exact syntax)
<Regenaxer>
So you can break pages at any moment
<Regenaxer>
In svg I use a coroutine to generate lines
<Regenaxer>
And the main loop builds the <svg>s
<miskatonic>
xml-like structures are easy to exprss as s-expression, allowing for mixing svg into lisp code
<Regenaxer>
right
<beneroth>
T
<tankf33der>
Regenaxer: new pil21 releases this week?
<Regenaxer>
I hope so. Sorry, was busy the last days
casaca has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #picolisp
casaca has joined #picolisp
casaca has quit [Excess Flood]
casaca has joined #picolisp
casaca has quit [Excess Flood]
casaca has joined #picolisp
casaca has quit [Excess Flood]
orivej has quit [Ping timeout: 240 seconds]
orivej_ has joined #picolisp
Nistur has quit [Ping timeout: 256 seconds]
orivej_ has quit [Ping timeout: 260 seconds]
orivej has joined #picolisp
Nistur has joined #picolisp
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #picolisp
miskatonic has quit [Quit: ERC (IRC client for Emacs 24.5.1)]