<Regenaxer>
beneroth: When thinking about the construct yesterdan (or ((not (val @X ...))) ((gt0 (val @X ...
<Regenaxer>
This looks very much like the *normal* behavior of all the filter predicates
<Regenaxer>
i.e. when the search criterium is NIL, it is ignored
<Regenaxer>
So isn't it that your predicate is simply (range (1 . T) @Obj property) ?
<Regenaxer>
In fact, even (range (1 . T) is not needed normally, as it takes all objects which either don't have the value, or one between 1 and infinie, so it filters only those which are <= 0. Do values <=0 exist?
abel-normand has joined #picolisp
<beneroth>
will come back on this later
<beneroth>
gotta go :)
<Regenaxer>
ok :)
aw- has quit [Quit: Leaving.]
<tankfeeder>
morning
<Regenaxer>
Hi tankfeeder
coffeecup12345 has joined #picolisp
<tankfeeder>
i've implement word break on dynamic programming
<tankfeeder>
both pils compiles and pass buildin tests.
<tankfeeder>
issue closed.
<tankfeeder>
Regenaxer: would you like add illumos-openindiana to README?
abel-normand has joined #picolisp
<clacke[m]>
awesome
<clacke[m]>
aqesome
zod_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<beneroth>
awesome. great stuff, tankfeeder
<beneroth>
Regenaxer, yeah, you are right, the (range) would probably work as intended. afaik there are no values <0 in the DB, but I'm not sure without checking. its a legacy DB with a lot many weird entries.
<beneroth>
what cost me some hours yesterday was the fact that I initially thought that not all pilog values had to be given explicitly to every predicate.. I assumed the values which were fixed/defined by a higher "scope" would be available automatically.. e.g. reference values passed in from lisp level.
<beneroth>
I guess I was wrong on that. some stuff appeared to work first, but than I ran into strange issues. after much debugging I adapted all predicate definitions and all predicate "calls" to always having all involved values in their parameters.. then it worked cleanly
DKordic has joined #picolisp
orivej has quit [Ping timeout: 260 seconds]
<Regenaxer>
ret
<Regenaxer>
tankfeeder, OK, can do, though it sounds esotheric to me. What is the correct term? Full "illumos-openindiana"?
<Regenaxer>
beneroth
<beneroth>
afaik the basic/core system is illumos. and openindiana is a distribution based on this
<Regenaxer>
right, this is quite different from Lisp variables
<Regenaxer>
Does it look as "Linux" to the build process?
<Regenaxer>
ie. which sys/* is picked?
<beneroth>
solaris I would guess
<beneroth>
illumos is the FOSS clone/fork of solaris.
<Regenaxer>
ah, right
<beneroth>
and will probably become more important, as solaris is dying, this might be used to keep legacy systems running.
<beneroth>
they also try to establish themselves as good server OS with some features that Linux does not have, but I don't know how much of a appeal it really has...
<beneroth>
Regenaxer, the "all used variables has to be given via parameters" I totally overlooked and was really not nice...
<beneroth>
:)
coffeecup12345 has quit [Ping timeout: 258 seconds]
<Regenaxer>
Where did you see that?
<beneroth>
and I ended up with about 18 predicates, each one consisting of about 2-10 rules
<Regenaxer>
oh
<beneroth>
Regenaxer, is it wrong? my stuff seemed not to work correctly (but some stuff worked) when I didn't specify all values in all parameters
<beneroth>
yeah, pretty complicated query :D
<Regenaxer>
What do mean with "specify"
<Regenaxer>
Pilog variables don't need to be bound initially
<Regenaxer>
I suspect that the built-in predicates do most of what you need
<Regenaxer>
by chaining
<Regenaxer>
both in generator and in filter clausel
<Regenaxer>
clauses
<beneroth>
(be foo (@A @B) (val @B @A property)) vs. (be foo (@A) (val @B @A property)), called like (pilog '(@B (db 'idx '+Class "reference-value") (select (@A) .... (foo @A))
abel-normand has quit [Ping timeout: 260 seconds]
<beneroth>
it is ok and correct to not specify @B in the parameter for the predicate here, or isn't it?
<beneroth>
Regenaxer, well my pilog code can probably be optimized a bit.. happened already when you showed me the correct usage of (val)... but I just started, so okay :)
<beneroth>
and the export ran really fast. to select nearly 4k records out of 21k in the database, to run the query and generate the export it only took few seconds.. 2-3 or so.
<beneroth>
and this with yet only one single generator clause, and one single DB file...
<beneroth>
so still room for improvement
<beneroth>
impressive
<cess11>
Yeah. Snappy like a proper weapon as long as the data and queries aren't too badly involved with each other.
<cess11>
File I/O is almost always the only relevant bottleneck as far as I can tell.
<beneroth>
T
<beneroth>
but pil DB makes pretty simple and clever use of OS / FS caching
<cess11>
Network throughput can probably be made a problem but I haven't found a reasonable way to accomplish this yet. Perhaps with an old fashioned modem.
<beneroth>
most DBMS try to circumvent them and do it themselves.. I'm not so sure that it always gives better results..
<beneroth>
and the graph architecture of pil DB and having a unique identifier for every record gives some easily self-optimizing caching behaviours...
<cess11>
It does, so in general there's almost no waiting with a pooled and working db, at least as long as it is properly block sized and so on.
<Regenaxer>
sorry, busy here ...
<Regenaxer>
Not sure I understand your issue with 'val'
<Regenaxer>
it would be better not to have a separate 'db'
<Regenaxer>
can't this done in the select?
<beneroth>
T, but I have to reuse the same value on lisp level, that is why I did it on lisp level
<beneroth>
the db in the mapping is here just in the example
<Regenaxer>
then you can *return* it from the select
<Regenaxer>
(select (@Obj @B ...)
<Regenaxer>
bind multiple values
<Regenaxer>
not only the object
<beneroth>
yeah..the question is entirely not about that
<Regenaxer>
ok
<Regenaxer>
what is "specify"?
<beneroth>
define....set...
<beneroth>
spezifieren?
<beneroth>
spezifizieren
<Regenaxer>
if not, it is NIL
<beneroth>
the question is if I can use @B within predicate 'foo without listing @B in the argument list of 'foo
<Regenaxer>
yes, then it is NIL
<beneroth>
yes.. which it shouldn't be. @B is here a reference value with an globally fixed value.
<Regenaxer>
The problem with the filter predicates in lib/pilog.l is that they are not pure
<beneroth>
so it has to be in the argument list passed down to end up with the same values, right?
<Regenaxer>
in the sense that they bind values
<Regenaxer>
they are just filters
<Regenaxer>
problem we saw with 'same' yesterday
<beneroth>
yeah, but that was not the issue. the issue was that @B was NIL when I expected it to be the value which it got on a higher scope.
<beneroth>
if scope is the right term. unify level is maybe more correct. dunno.
<Regenaxer>
hmm, with "argument list" you mean the initial var bindings in 'goal'
<beneroth>
no, that () within (be foo (THIS HERE) ....)
<Regenaxer>
yes, unification is always in that level
<beneroth>
yeah the initial var bindings are not existing within foo unless those vars are in the "argument list" of foo
<beneroth>
right?
<beneroth>
that was my missing insight which caused me a lot trouble
<beneroth>
habits et al
<Regenaxer>
they are *never* visible inside foo
<Regenaxer>
they are on *that* level
<Regenaxer>
not in predicates called there
<Regenaxer>
no dynamic binding as in Lisp
<beneroth>
(be foo (@B) ..@B = initial binding) VERSUS (be foo () @B = NIL or whatever it gets bind to on this level)
<Regenaxer>
hmm, (be foo () @B = NIL does not exist
<beneroth>
yeah, the no dynamic binding thing I didn't know and assumed wrongly out of lisp habits
<Regenaxer>
(be foo () (bar @X) (mumble @X))
<Regenaxer>
@X springs in existence on that level
<Regenaxer>
may be bound by 'bar'
<beneroth>
lets take your foo and do (goal @X "bla (foo)) -> is @X within (foo) now "bla" ? no it isn't
<Regenaxer>
right
<beneroth>
(goal @X "bla" (foo @X) -> within foo, @X is "bla" as already bound and passed down
<beneroth>
right?
<Regenaxer>
@X is meaningless here
<Regenaxer>
(goal @X "bla (foo)) I mean
<Regenaxer>
no matter what 'foo' thinks about @X
<Regenaxer>
so it is meaningless
<beneroth>
I wanted to force foo to think of @X as "bla" and nothing else
<beneroth>
as @X being in this use case a reference value to be compared against
<Regenaxer>
Then @X is also not needed. Just write (foo "bla")
<beneroth>
yeah, or (foo {213}) if the value is not a symbol but an external symbol. or @X if you pass it down from above.
<cess11>
Values can't be transfered with variables through the query, the binding is extremely weak and shallow in Prolog and Prolog-like languages. I'm guessing globals could be more convenient if it's still a dump/export procedure.
<Regenaxer>
I think the term "pass it down from above" is wrong
<beneroth>
ok, well how to do/use a globale in pilo?
<beneroth>
maybe
<Regenaxer>
doesn't exist in Prolog
<Regenaxer>
A global is an assertion, a fact
<beneroth>
maybe the term is wrong. I don't know the right term. I describe it as I see it.
<Regenaxer>
(be Myglob)
<Regenaxer>
or (asserta ...
<cess11>
There's intermixing with Lisp, I'm assuming that allows for setting and getting values from variables.
<beneroth>
when those facts are results of lisp, how to communicate those facts from lisp to pilog level
<Regenaxer>
with (^ @Var (lisp ...))
<beneroth>
my current approach seems to work correctly
<Regenaxer>
I just think it is too complicated
<beneroth>
hm.. this would probably be a nicer and more pilog-ish way
<Regenaxer>
I don't know your data model
<Regenaxer>
not only prologish, but using the linkage of generators and filters
<beneroth>
I don't think it matters, the topic is about reference values.
<Regenaxer>
normally no additional predicates should be necessary
<beneroth>
(the db model I meant)
<beneroth>
well..stuff goes like this..
<beneroth>
if record has in +Link property this specific external object -> success, else skip this record
<beneroth>
"specifc external object" == my "reference value"
<Regenaxer>
yes, and this object is linked
<Regenaxer>
so it should be in the generator
<Regenaxer>
and filter
<beneroth>
I'm talking about the filter
<beneroth>
how to represent it in the filter
<Regenaxer>
you need both
<beneroth>
either I'm completely confused or we don't talk about the same thing
<cess11>
Can't it be both?
<beneroth>
schlimmer geht immer
<Regenaxer>
say you want @@ to point to an object with key 123
<beneroth>
yeah
<cess11>
Because I'm quite confused and also not sure what we're talking about exactly.
<Regenaxer>
the filter is (val 123 @@ link key)
<Regenaxer>
that's all
<beneroth>
so I take you would make this as a fact? I currently do an initial binding for @@ and pass @@ to every predicate which compares against it
<Regenaxer>
if 'link' is the +Link to those objs
yuckyikas is now known as yumaikas
<Regenaxer>
no
<Regenaxer>
just this (val ..) as a filter
<beneroth>
hm.. right, didn't think of that. though that makes additional object loading necessary. and I hardcode the key...hm...
<cess11>
Unless you want to share this particular part of your query with other queries it is unnecessary to 'be it.
<beneroth>
but yeah, this is more elegant, agreed
<Regenaxer>
did you check the examples in app/gui.l?
<beneroth>
cess11, the same reference value is used in multiple predicates
<Regenaxer>
There are such selects
<beneroth>
no I didn't
<Regenaxer>
Generator: (nm +CuSu @Cus (cus +Ord))
<beneroth>
cess11, and yes, some predicates are used within other predicates, and generally all predicates I use 2 times
<Regenaxer>
Filter: (tolr @Cus @@ cus nm)
<Regenaxer>
or (nm +CuSu @Sup (sup +Item) (itm +Pos) ord)
<Regenaxer>
(tolr @Sup @@ pos itm sup nm)
<Regenaxer>
these are links across several steps
<Regenaxer>
+Joints to be correct
<beneroth>
this is finding patterns within the link graph. but I don't see any particular key value hardcoded.
<beneroth>
link graph = graph formed by +Links
<beneroth>
I mean
<beneroth>
I have
<beneroth>
+Contact, having an +Address property, having an +Country property. I want to select for all +Contacts which happen to have +Country 'name "Deutschland"
<Regenaxer>
exactly such a case as above
<Regenaxer>
very simple
<beneroth>
where is the value "Deutschland" ?
<Regenaxer>
(name +Country "Deutschland" (adr +Contact)) is the generator
<Regenaxer>
of course "Deutschland" will be in a @Var
<Regenaxer>
typically
<beneroth>
yes, and this @Var gets binded in initial binding?
<Regenaxer>
(part "Deutschland" @@ adr cntry) is the filter
<beneroth>
that is what I did. yes same level for the generators. but not for the filters, unless (part "Deutschland" @@ adr cntry) is directly within the select.. if it is within a predicate within a predicate used there... what then?
<beneroth>
then the initial binded value has to be explicitly passed down through those predicates, yes?
<Regenaxer>
No problem, you du (myFilter @Var) ...
<beneroth>
yes.
<Regenaxer>
T
<beneroth>
and I didn't know that (myFilter) is not good enough
<Regenaxer>
But are you sure you need special predicates?
<beneroth>
and because I have many reference values, this ended up with (myFilter @Var1 @Var2 .....)
<Regenaxer>
may be ok, I just wonder
<beneroth>
I think so, maybe I could optimize some away
<Regenaxer>
I believe you can directly express the E/R situations
<Regenaxer>
they follow all links, ĵoints, lists and indexes
<beneroth>
all those predicates I use two times, first within (or) in the select, and then again within a (cond ((prove ..)) to find out which predicate made this record be selected
<Regenaxer>
How to "find out"? Cant you see that in the properties of found objects?
orivej has joined #picolisp
<beneroth>
Regenaxer, not easily. its 4-10 criterias or so.. so easiest just to check those criteria again with the predicate which does exactly this
<Regenaxer>
ok, in the filter?
<Regenaxer>
you filter twice?
<beneroth>
I use the predicate, e.g. "member-current-year" within (or ((member-current-year @Obj)) .. other predicates) as filter in the (select), and then within the (pilog) prog I do (cond ((prove member-current-year))) as some parts of the output have to be different depending on which of the predicates within the (or) filter made the record pass
<beneroth>
so I do not filter twice
<beneroth>
I filter once, with (or multiple filters)
<Regenaxer>
Ok, understand
<Regenaxer>
good then
<beneroth>
as an improvement I probably could hardcode some reference values instead of binding them in initial binding
<Regenaxer>
Perhaps not a speed gain
<Regenaxer>
So the main point of confusion was the scope of Pilog var bindings
<beneroth>
yeah, actually probably a slight speed lose, as this adds additional db lookups which now are only done once
<beneroth>
exactly!
<beneroth>
YES!
<beneroth>
you know there were some other minor issues and misunderstandings before, but those were resolved (with your earlier help). that binding misunderstanding I had all the time but didn't realise until late night
<beneroth>
so yeah, I will easily remember this now :)
<Regenaxer>
:)
<beneroth>
and the big rescue mission was successful. still some minor stuff to do tomorrow, but all in all the clients big issue could be resolved by the power of picolisp and pilog :)
<Regenaxer>
good to hear!
<beneroth>
once again, thanks to you and cess11 and all others who helped me getting into pilog in record short time xD
<Regenaxer>
welcome!
<beneroth>
<3
<beneroth>
bbl
<beneroth>
schönen Abend Alex :)
<Regenaxer>
you too!
<Regenaxer>
:)
rob_w has joined #picolisp
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
Regenaxer has quit [Remote host closed the connection]
Regenaxer has joined #picolisp
coffeecup12345 has joined #picolisp
coffeecup12345 has quit [Ping timeout: 252 seconds]
<cess11>
beneroth: I think you'll find pilog and Prolog to be a much nicer experience later on, when you're less stressed and have read some more on the logic programming techniques and perspectives. It's a really, really clever way of expressing programs that is far away from both day-to-day-lisp and imperative/procedural styles as well.
<cess11>
I've only looked at it for a short time, a couple of months or so, so I'm not fluent in either pilog or Prolog but I recognise some problem solving patterns from elsewhere, for example program building as a kind of set theory where one defines sets and their overlap, sort of.
<cess11>
Don't think it was many weeks ago I asked here about how to write rules in pilog, and then realised it was a bit of a stupid question since variables basically make the difference.
<cess11>
Variables being program expression rather than containers for values to be passed around is a little tricky to apply in practice but very powerful.
karswell_ has joined #picolisp
<cess11>
When I read the Power of Prolog-link it irritated me a little that I hadn't read it earlier but in the long run it won't matter much.
<cess11>
Looking at real Prolog code also helps, at first it is too easy to imply semantic meaning to symbols and tutorial examples are usually quite dumb so they don't handle that, instead they chug along as if it couldn't be a problem for the newbie.
<cess11>
likes(lisa, george). That kind of dumb and allowing too much belief in semantics.
karswell_ is now known as karswell
alexshendi has joined #picolisp
alexshendi has quit [Read error: Connection reset by peer]
rob_w has quit [Read error: Connection reset by peer]
alexshendi has joined #picolisp
zod has joined #picolisp
zod has quit [Client Quit]
zod has joined #picolisp
<beneroth>
thanks cess11
<beneroth>
I agree
<beneroth>
in way this was a good forced approach to learn pilog now. real data and real uses make stuff easier to grok, bare examples are prone to make one believe into the wrong essentials
<beneroth>
good wording with the set theory
<beneroth>
I think I grokked that conceptually. what I lack is a finer understanding of the mechanics and a feeling for good pilog style. it is indeed orthogonal to lisp style.