From: Kenny Tilton
Subject: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C15F511.3AD73DD7@nyc.rr.com>
OK, I just sent out the first batch of distros of Semaphors, source
included, licensed under GNU GPL for now.
Sorry, not set up for downloads from a URL, but if you are curious I
will be happy send anyone a ZIP file with the source and doc.
Note that this changes what I said about needing ACL to explore the
dataflow engine. But you do need a CL compiler with decent MOP support.
My old original MCL implementation of course was MOP-less, so we could
resurrect that if absolutely necessary.
otoh, the GUI stuff comes next and that will be ACL/CG-based at first,
so... I don't know, you can at least read the doc. I'd say if in doubt
go ahead and ask me to email it to you, it's only a couple hundred K
right now.
The first public project/tutorial will be a CLOS class browser. The
evolution of that will go in the doc as an extended tutorial.
Then we start on a Common Lisp GUI. :)
kenny
tilton technology/clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> OK, I just sent out the first batch of distros of Semaphors, source
> included, licensed under GNU GPL for now.
I guess that's a good thing, but for the uninitiated, what *is*
Semaphors?
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C16382E.E9023B25@nyc.rr.com>
Andreas Bogk wrote:
> I guess that's a good thing, but for the uninitiated, what *is*
> Semaphors?
Sorry. From the slowly developing PDF doc (which I would be happy to
send to anyone):
"Semaphors let you define selected slots of CLOS instances as if they
were cells in a spreadsheet. As with spreadsheet cells, a semaphoric
slot (semaphor, for short) can have bound to it a literal value or a
formula. The formula is any Lisp form which, when wrapped in a suitable
macro, enjoys access to anaphoric variables �self (the CLOS instance of
the slot) and (via the macro cached-value) the most recent value
calculated by the formula).
If a rule dynamically accesses another semaphor, a dependency is
automatically recorded. Each time a rule runs the dependencies are
re-evaluated, so a branching rule may depend on different semaphors from
time to time.
When a semaphor changes, all semaphors dependent on that semaphor are
recalu-lated. This eager evaluation cascades through the dependency
graph, though if any recalculated semaphor happens to come up with the
same value as before, propagation does not continue to its dependents.
The user may define callback echo functions which also are invoked when
a semaphor changes, and before propagation to other semaphors. For
example, a semaphor for the color slot of a widget has an echo method
which triggers a screen update so the new color gets shown.
Echo functions are the output of the overall model. Input to the model
is achieved by setting special variable semaphors to information culled
from OS events."
kenny
Now that I see this posting, I think that the name is a little
misappropriate.
"Semaphore" is used in some natural languages to mean "street
light". Hence Dijkstra's use of the term for his P and V operations on
"semaphores" in conjunction to concurrent system programming.
Are you sure you want to use such an overloaded term?
Cheers
PS. May I also suggest the Lesser GPL as a license?
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C16A790.3BB179CE@nyc.rr.com>
Marco Antoniotti wrote:
>
> Now that I see this posting, I think that the name is a little
> misappropriate.
I am aware of the conflict. If it becomes a big deal I can rename. Right
now the first question is whether anyone finds Semaphors interesting. If
not, we're done.
otherwise, i have been calling them semaphors for six years, I would not
mind a new name, maybe something shorter. we'll have a "name that hack"
contest.
>
> "Semaphore" is used in some natural languages to mean "street
> light". Hence Dijkstra's use of the term for his P and V operations on
> "semaphores" in conjunction to concurrent system programming.
>
Semaphores are also the name for the paddles used in ship-to-ship
signalling, where they manage to spell out messages character by
character. That seems to be conveying quite a richer message than the
simple booleans of unix semaphores, so maybe Dijkstra got it wrong.
OTOH, railroad semaphores are not so rich, so Dijkstra's is in line with
that.
> Are you sure you want to use such an overloaded term?
Natural language is like that, so I do not think it is much of a
problem. Like, what is the downside? What would actually be the problem
if the names were close?
Finally, there /is/ a signaling quality to dataflow. The signal is "I
have changed. You used me in a calculation. Your calculation is now out
of date. Recalculate now."
>
> PS. May I also suggest the Lesser GPL as a license?
>
Strong possibility. I just figured start GPL and see what happens. I can
change from GPL to LGPL but not from LGPL to GPL.
kenny
From: Dr. Edmund Weitz
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <m37krtf0b1.fsf@bird.agharta.de>
Kenny Tilton <·······@nyc.rr.com> writes:
> Strong possibility. I just figured start GPL and see what happens. I
> can change from GPL to LGPL but not from LGPL to GPL.
Pardon me, but it's still _your_ code, isn't it? I suppose you can
change one line, declare it to be a new release and go from (L)GPL to
whatever license you want. Isn't that the case?
Edi.
···@agharta.de (Dr. Edmund Weitz) writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
> > Strong possibility. I just figured start GPL and see what
> > happens. I can change from GPL to LGPL but not from LGPL to GPL.
> Pardon me, but it's still _your_ code, isn't it? I suppose you can
> change one line, declare it to be a new release and go from (L)GPL to
> whatever license you want. Isn't that the case?
Indeed.
The only way the author would be unable to do that would be if he
_explicitly_ signed over _exclusive_ copyright to someone else, let's
say, the FSF.
This is one of the all-too-common misunderstandings that should
underline the rather critical point:
Read your software licenses, and be sure you _know_ you understand
them, as opposed to merely _thinking_ you understand them.
Much of the flaming that surrounds such licenses as the GPL, LGPL, BSD
licenses, and Mozilla licenses comes from not having carefully
understood the licenses and their implications.
When people are buying ACL licenses from Franz, or Windows NT licenses
from Microsoft, people tend to be aware that they ought to look
carefully at the provisions and understand their implications. For
some strange reason, the brain tends to shut off when looking at
"would-be-free licenses."
For the most part, the result of that "shut-off" is that the free
license people first hear about becomes "heavenly," whilst the
alternatives are all slightly "of the devil."
On rare occasions, somebody feels that they have gotten "burned"
because they shut their brain off when picking a license, and
essentially switches parity. Suddenly the formerly-loved GPL is "of
the devil," RMS is Satan incarnate, and BSD is the "only truly free"
option. Or, because "Someone STOLE my CODE!!!", BSD becomes evil, and
the LGPL isn't nearly hard-core enough in "protecting my code from
evil."
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www3.sympatico.ca/cbbrowne/lsf.html
"If God meant us to be vegetarians why'd He make cows out of meat?"
-- seen on a bumper sticker
········@acm.org writes:
> ···@agharta.de (Dr. Edmund Weitz) writes:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> > > Strong possibility. I just figured start GPL and see what
> > > happens. I can change from GPL to LGPL but not from LGPL to GPL.
>
> > Pardon me, but it's still _your_ code, isn't it? I suppose you can
> > change one line, declare it to be a new release and go from (L)GPL to
> > whatever license you want. Isn't that the case?
>
> Indeed.
>
> The only way the author would be unable to do that would be if he
> _explicitly_ signed over _exclusive_ copyright to someone else, let's
> say, the FSF.
I'm not sure it's about the wording.
Since the GPL is more restrictive, I would be surprised if anyone
already in legitimate possession of a copy of the software under LGPL
terms was obliged to stop using it under those terms. Were thtat so,
that would invalidate the usability of LGPL'd code because everyone
would live in fear that the authors of such code would retroactively
change the terms under which such term was received.
The author is certainly free to change the terms under which new code
is distributed, but s/he is at that point competing with prior
releases under less restrictive terms. I don't know if the status of
the originally LGPL'd code would be that of an already established
legal contract (and so free to exploit its terms for whatever duration
the contract specifies, which to my knowledge is "indefinitely") or
else at least, is an offer to form a contract, and, in such case, if
some "reasonable, forseeable, and legally detrimental" [terms of art]
action has taken place on the assumption that the LGPL terms were to
be available under said contract, I would think promissory estoppel
would apply.
("I'm not a lawyer but..." I think promissory estoppel is a basic
component of the theory of contracts at least in the US, and I suspect
under any system that derives from English common law, though I'm less
sure of that. Does anyone familiar with non-US law, and especially
with multinational law know how broadly this kind of thing applies?)
For those who don't know what promissory estoppel is, I dug up a
pretty concise explanation from http://dictionary.law.com/ that
matches my understanding (except that I'm used to the words
"disadvantage" in line 3 being specifically instead "legal
detriment").
promissory estoppel
n. a false statement treated as a promise by a court when the
listener had relied on what was told to him/her to his/her
disadvantage. In order to see that justice is done a judge will
preclude the maker of the statement from denying it. Thus, the legal
inability of the person who made the false statement to deny it makes
it an enforceable promise called "promissory estoppel," or an
"equitable estoppel." Example: Bernie Blowhard tells Arthur Artist
that Blowhard has a contract to make a movie and wants Artist to
paint the background scenery in return for a percentage of the
profits. Artist paints, and Blowhard then admits he needed the
scenery to try to get a movie deal which fell through and there are
no profits to share. Artist sues and the judge finds that Blowhard
cannot deny a contract with Artist and gives Artist judgment for the
value of his work.
Kent M Pitman <······@world.std.com> writes:
> Since the GPL is more restrictive, I would be surprised if anyone
> already in legitimate possession of a copy of the software under LGPL
> terms was obliged to stop using it under those terms. Were thtat so,
> that would invalidate the usability of LGPL'd code because everyone
> would live in fear that the authors of such code would retroactively
> change the terms under which such term was received.
No, the FSF's licenses -- being user-focused -- don't allow for the
author to revoke them. That's their big criticism of some of the
newer Open Source-alike licenses, like Apple's.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C17290B.DCFF8604@nyc.rr.com>
Kent M Pitman wrote:
>
> I don't know if the status of
> the originally LGPL'd code would be that of an already established
> legal contract ...
Both the GPL and LGPL state explicitly that there will be no other
restrictions on the use beyond those stated in each license, so long as
the licensee remains in compliance with the terms of the license.
And neither license indicates a time limit. So once LGPL always LGPL or
looser, but never "further restricted".
kenny
Kenny Tilton <·······@nyc.rr.com> writes:
> Kent M Pitman wrote:
> >
> > I don't know if the status of
> > the originally LGPL'd code would be that of an already established
> > legal contract ...
>
> Both the GPL and LGPL state explicitly that there will be no other
> restrictions on the use beyond those stated in each license, so long as
> the licensee remains in compliance with the terms of the license.
>
> And neither license indicates a time limit. So once LGPL always LGPL or
> looser, but never "further restricted".
Yes, I'm sure what you say is so, but that doesn't address the
statement you quoted.
The LGPL vaguely takes the form of a unilateral contract, though I
don't know if that's the instrument it purports to be. It observes at
one point that you don't have to "accept" it, but that you won't get your
rights any other way. It doesn't really discuss plainly what action
constitutes acceptance. Ordinarily, as I understand it, full performance
under a unilateral contract constitutes acceptance, but I'm not sure what
constitutes performing this contract. Before acceptance has been
done, there is no contract, but there is a state in which the offeree
can have acted in a way that is legally detrimental to himself or herself
and you can still hold the offeror to the terms of the contract....
If the contract is accepted, then the stuff you say is in play; the questin
is what the state of things is if the contract is not (yet) accepted.
I don't know if that's a question the legal system has. Maybe it's a
well-defined th ing. I'm only saying it's a question I have. :-)
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C178438.1FE6BB88@nyc.rr.com>
Kent M Pitman wrote:
>
> The LGPL vaguely takes the form of a unilateral contract, though I
> don't know if that's the instrument it purports to be. It observes at
> one point that you don't have to "accept" it, but that you won't get your
> rights any other way. It doesn't really discuss plainly what action
> constitutes acceptance.
From the LGPL:
"5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying
or distributing the Program (or any work based on the Program), you
indicate your acceptance of this License to do so, and all its terms and
conditions for copying, distributing or modifying the Program or works
based on it. "
Elsewhere I read something from the GNU enforcement bloke:
"Licenses are not contracts: the work's user is obliged to remain within
the bounds of the license not because she voluntarily promised, but
because she doesn't have any right to act at all except as the license
permits. "
Full text: http://www.gnu.org/philosophy/enforcing-gpl.html
Disclaimer: IANAL, TINLA
kenny
Kenny Tilton <·······@nyc.rr.com> writes:
> Disclaimer: IANAL, TINLA
^= This is Not L---? A---?
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Erik Naggum
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3217195429393922@naggum.net>
* Thomas F. Burdick
| Kenny Tilton <·······@nyc.rr.com> writes:
|
| > Disclaimer: IANAL, TINLA
| ^= This is Not L---? A---?
FWIW, "This is Not Legal Advice" IMO. HTH. HAND.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.
"Erik Naggum" <····@naggum.net> wrote in message
·····················@naggum.net...
> * Thomas F. Burdick
> | Kenny Tilton <·······@nyc.rr.com> writes:
> |
> | > Disclaimer: IANAL, TINLA
> | ^= This is Not L---? A---?
>
> FWIW, "This is Not Legal Advice" IMO. HTH. HAND.
>
ROTFLMAO, YMMV.
Heading off to join the AAAAA,
Geoff
Geoff Summerhayes wrote:
>
> "Erik Naggum" <····@naggum.net> wrote in message
> ·····················@naggum.net...
> > * Thomas F. Burdick
> > | Kenny Tilton <·······@nyc.rr.com> writes:
> > |
> > | > Disclaimer: IANAL, TINLA
> > | ^= This is Not L---? A---?
> >
> > FWIW, "This is Not Legal Advice" IMO. HTH. HAND.
> >
>
> ROTFLMAO, YMMV.
>
> Heading off to join the AAAAA,
> Geoff
The Association for the Abolition of the Abberant or Absent Apostrophe?
I haven't heard of them in a l_o_n_g time!
"Ian Wild" <········@eurocontrol.int> wrote in message
······················@eurocontrol.int...
> Geoff Summerhayes wrote:
> >
> > Heading off to join the AAAAA,
> > Geoff
>
> The Association for the Abolition of the Abberant or Absent Apostrophe?
> I haven't heard of them in a l_o_n_g time!
Anonymous Association Against Acronym Abuse, actually.
Geoff
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C18066C.71E0D3DE@nyc.rr.com>
I am not a lawyer, this is not legal advice.
Just saw that for the first time a couple of days ago.
"Thomas F. Burdick" wrote:
>
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Disclaimer: IANAL, TINLA
> ^= This is Not L---? A---?
>
"I am not a lawyer, this is not legal advice."
Just saw that for the first time a couple of days ago.
kenny
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C170DA3.8A309A0E@nyc.rr.com>
········@acm.org wrote:
>
> ···@agharta.de (Dr. Edmund Weitz) writes:
> > Kenny Tilton <·······@nyc.rr.com> writes:
> > > Strong possibility. I just figured start GPL and see what
> > > happens. I can change from GPL to LGPL but not from LGPL to GPL.
>
> > Pardon me, but it's still _your_ code, isn't it? I suppose you can
> > change one line, declare it to be a new release and go from (L)GPL to
> > whatever license you want. Isn't that the case?
>
> Indeed.
>
> The only way the author would be unable to do that would be if he
> _explicitly_ signed over _exclusive_ copyright to someone else, let's
> say, the FSF.
With all due respect, that is wrong in any material sense. If someone
thinks they might want GPL control they must not release it under the
less restrictive LGPL; there is no going back. Subsequent licenses
cannot rescind earlier licenses.
There is a lot going on here.
First, let's control one of the variables by supposing the original
LGPLed release was awesome. In another post I have already explained why
in this case I do not think I can use tantalizing new features to draw
folks into the strait jacket of the GNU GPL once they have the LGPLed
original.
Second, can I /distribute/ a new version under the GPL? Sure, and
everyone is free to ignore me and use the LGPL version. It is an NOP. I
may as well stand on the corner and ask people to pay me to let them
breathe.
The only reason to issue a license is to control how people use the
software, so...I cannot go from LGPL to GPL.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Second, can I /distribute/ a new version under the GPL? Sure, and
> everyone is free to ignore me and use the LGPL version. It is an NOP. I
> may as well stand on the corner and ask people to pay me to let them
> breathe.
Thats an oversimplification of the cost-benefit analysis of both the
decision to use a new license by the develop and the decision to use
the same package's next version under a new license. The restriction
of the license is not the only thing people consider when comparing
software. What if you decided to incorporate some GPLed code into
your program, then you either have make something like guile's one-off
LGPL variant, or you could just convert entirely to GPL. So now the
old version is indeed LGPL, but it is not as technically relevant
because your new version has a feature they can't reproduce without
being effectively GPLed or re-implementing and branching. There are
countless other situations where we cannot simply reduce the analysis
to the "restrictiveness" of the license.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
Kenny Tilton <·······@nyc.rr.com> writes:
> With all due respect, that is wrong in any material sense. If someone
> thinks they might want GPL control they must not release it under the
> less restrictive LGPL; there is no going back. Subsequent licenses
> cannot rescind earlier licenses.
I think we need to define what "going back" means.
If I release version 1.0 of my software under the LGPL, I can still
release it later again under GPL, however, I cannot revoke the license
for anybody who downloaded the LGPL version. The effect is that the
user now can choose which license he wants to accept. In that sense
"going back" doesn't work.
However, if I have released 1.0 under LGPL, I can still release
version 1.1 under GPL, so in that sense, "going back" works. That is
of course, unless I have accepted and integrated LGPL patches from
people. I can still talk people into changing the license for their
patches, or sign over the copyright to me.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C179402.5DC6094C@nyc.rr.com>
Andreas Bogk wrote:
> However, if I have released 1.0 under LGPL, I can still release
> version 1.1 under GPL, so in that sense, "going back" works.
I covered that in a couple of replies. At that point I am in a
tug-of-war with version 1.0, hoping to do stuff in 1.1 and beyond which
is so awesome people accept the stricter license.
Semaphors 1.0 is six years old, mature and battle-hardened (massive
use). I have successfully built an intense application with it. It is a
rich mechanism so I am sure there is still a lot of fun to be had with
it, I just doubt version 1.0 could be marginalized by any possible 1.1.
And why worry about it when i can start with GPL instead of LGPL, which
is all I said.
I do believe this horse is dead. :)
kenny
Kenny Tilton <·······@nyc.rr.com> writes:
> Andreas Bogk wrote:
> > However, if I have released 1.0 under LGPL, I can still release
> > version 1.1 under GPL, so in that sense, "going back" works.
> I covered that in a couple of replies. At that point I am in a
> tug-of-war with version 1.0, hoping to do stuff in 1.1 and beyond
> which is so awesome people accept the stricter license.
Indeed. If you release a version that is _massively_ superior, and
orphan support for the "other version," it is fairly likely that
people will feel compelled to move over, unless there's something
really compelling about the "other version."
Two cases in point, this year:
- TuxRacer; a 3D game involving penguins (go figure...) was
originally released under the GPL. The authors have taken the code
private; version 1.0 is under a "shrink-wrap-style-software"
license.
The new version isn't distributable without buying it from the
authors, which means the old version has a compelling quality that
the "new, improved!" version doesn't have.
- Quanta; an HTML editor (that groks PHP) has similarly been
"privatized" by some of its authors.
The "unarguable non-freeness" of the new version again demonstrates
that there's a compelling reason for a group to spring up to
maintain the old version.
> Semaphors 1.0 is six years old, mature and battle-hardened (massive
> use). I have successfully built an intense application with it. It is a
> rich mechanism so I am sure there is still a lot of fun to be had with
> it, I just doubt version 1.0 could be marginalized by any possible 1.1.
If 1.1 is _reasonably_ usable (e.g. - has a "sufficiently free
license"), and is compellingly better from a technical standpoint, I'd
think that to on balance allow it to "marginalize" version 1.0...
> And why worry about it when i can start with GPL instead of LGPL,
> which is all I said.
Which is fine :-).
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.ntlug.org/~cbbrowne/sap.html
"well, take it from an old hand: the only reason it would be easier
to program in C is that you can't easily express complex problems
in C, so you don't." -- Erik Naggum, comp.lang.lisp
········@acm.org writes:
> Indeed. If you release a version that is _massively_ superior, and
> orphan support for the "other version," it is fairly likely that
> people will feel compelled to move over, unless there's something
> really compelling about the "other version."
Ghostscript is an excellent example of a software where the author has
turned this into a business model: new versions are under an open
license that prevents any commercial use, and become free software
after some time (I think it was a year).
Ghostscript is in every other printer these days, and of course
printer manufacturers want support and the latest version, so the
author sells a lot of licenses. At the same time, he provides the
open source community with a high quality product.
Andreas
--
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
(Michel Serres)
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C170191.991D450E@nyc.rr.com>
"Dr. Edmund Weitz" wrote:
>
> Pardon me, but it's still _your_ code, isn't it? I suppose you can
> change one line, declare it to be a new release and go from (L)GPL to
> whatever license you want. Isn't that the case?
Yes, but once I license under the LGPL I cannot take that back. A newer
more restricted license can be ignored.
Now one can argue that /future/ work can be issued under the stricter
GPL, but then the LGPLed version (I wager) gets picked up by folks who
extend that. In the end I go back to the LGPL so I can rejoin what I
think would be the main fork.
So I have started with the GPL and will shift to LGPL if that starts to
make sense. To be honest I have learned this much but I still do not get
the whole picture. IANAL nor have I been hanging out with a crowd that
worries about this stuff, so I am not fluent in the issues.
For example it took me a lonnngg time to figure out the GNU GPL was
ideal for me, a way to share source without giving away forever the
option of licensing it commercially.
Now I want to focus on sharing/documenting Semaphors and think about
LGPL if it becomes an issue. If no one else digs Semaphors we're done.
:)
kenny
Kenny Tilton <·······@nyc.rr.com> writes:
>
> So I have started with the GPL and will shift to LGPL if that starts to
> make sense. To be honest I have learned this much but I still do not get
> the whole picture. IANAL nor have I been hanging out with a crowd that
> worries about this stuff, so I am not fluent in the issues.
>
> For example it took me a lonnngg time to figure out the GNU GPL was
> ideal for me, a way to share source without giving away forever the
> option of licensing it commercially.
I don't think that there are many people thinking that the GPL is a
better choice when wanting to go into commercial licensing later on.
As soon as anyone else contributes code (which I assume you want if
you use either GPL or LGPL), you have to make him sign over his code
to you (which probably is a tremendous bureaucratic effort that only
the FSF affords to do[1]) or to make him agree with your commercial
use.
In contrast, the LGPL allows anyone, especially you who probably knows
the code best, to combine it with own extensions to a commercial
release.
> Now I want to focus on sharing/documenting Semaphors and think about
> LGPL if it becomes an issue. If no one else digs Semaphors we're done.
> :)
By the way, I also don't think semaphor a good name.
> kenny
Yours, Nicolas.
[1] This may be only paranoia of Stallman. On the other hand, imagine
the following scenario: someone makes small but important
contributions to Linux or Emacs. Now, some time after these changes
have been widely accepted, Microsoft stands up and claims rights for
this and derived code, because that person was working for them at
that time (note that the FSF also requires the employer to agree).
Finally, one important point which not everyone might know.
Generally, the FSF signs over the code back to the author. So, at
least at the beginning, author and FSF have the same rights. Of
course, this will change when new contributors sign code over to the
FSF.
Nicolas Neuss <·····@ortler.iwr.uni-heidelberg.de> writes:
> I don't think that there are many people thinking that the GPL is a
> better choice when wanting to go into commercial licensing later on.
> As soon as anyone else contributes code (which I assume you want if
> you use either GPL or LGPL), you have to make him sign over his code
> to you (which probably is a tremendous bureaucratic effort that only
> the FSF affords to do[1]) or to make him agree with your commercial
> use.
Right. One option for Kenny would be to release all other versions as
open source, but with no redistribution rights (just a note that if
somebody wants to use it in their software, they should contact
him. Then he can grant non-commercial rights it, or commercial rights,
or whatever, to the individual person or project).
--
Brian Palmer
"Whoever fights monsters should see to it that in the process he does
not become a monster. And when you look long into an abyss, the abyss
also looks into you" - Nietzsche
Nicolas Neuss <·····@ortler.iwr.uni-heidelberg.de> writes:
> I don't think that there are many people thinking that the GPL is a
> better choice when wanting to go into commercial licensing later on.
> As soon as anyone else contributes code (which I assume you want if
> you use either GPL or LGPL), you have to make him sign over his code
> to you (which probably is a tremendous bureaucratic effort that only
> the FSF affords to do[1]) or to make him agree with your commercial
> use.
Actually, the GPL is very friendly with a dual Open / Proprietary
combination. Yes, the author needs to own the code. But, owning the
code, s/he can release it under the GPL, and offer paying customers a
license that will let them use it in their closed-source product. The
LGPL already gives this to them at no cost, and is thus a big loss for
the artisan toolmaker.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Nicolas Neuss <·····@ortler.iwr.uni-heidelberg.de> writes:
>
> > I don't think that there are many people thinking that the GPL is a
> > better choice when wanting to go into commercial licensing later on.
> > As soon as anyone else contributes code (which I assume you want if
> > you use either GPL or LGPL), you have to make him sign over his code
> > to you (which probably is a tremendous bureaucratic effort that only
> > the FSF affords to do[1]) or to make him agree with your commercial
> > use.
>
> Actually, the GPL is very friendly with a dual Open / Proprietary
> combination. Yes, the author needs to own the code. But, owning the
> code, s/he can release it under the GPL, and offer paying customers a
> license that will let them use it in their closed-source product. The
> LGPL already gives this to them at no cost, and is thus a big loss for
> the artisan toolmaker.
Sure, legally they can make such an offer. But the commercial value of an
option is computed by something like the difference between what the market
will bear without the option and what it will bear with the option.
Now, let's suppose you have a car with a computer and you've got the world's
only automatic pilot (not just cruise control--this one turns corners, stops
for small animals, mows the grass while you're away on weekends). You
approach Ford. For says, "golly, no one else has this. it will make
people want OUR cars. that will increase our volume of sales. plus, it's
cool functionality, too, and that adds value to the car, so we can charge
more." So they decide to charge customers a $5000 upgrade and you, a tough
negotiator, get $2500 of each such thing.
Now, let's look at the other scenario: you GPL the thing so anyone can
install this thing, but you say to Ford, "if you want to charge for it, just
ask me. I'll be happy to write a license." Ford's marketeers think about
this. They look at how it will affect their volume. Well, one doesn't have
to get a Ford in order to get this, so scratch the increase in volume. Sure,
maybe some poor sap will not be able to figure out how to install the RPM
on their dashboard computer, but you've worked hard to make the installation
convennient, so that's not very likely. Besides, the other vendors who didn't
buy have $5000 free for every car they want to sell at this level of
functionality, so they have a lot of market capital available to figure out
how to put out a REALLY GOOD brochure and to staff a help line explaining how
to install this. "Yes, it's true, say their expensive commercials, that Ford
is thinking about offering it in their cars, but it will drive the cost of an
equivalent car from $20,000 to $25,000 because that GREEDY guy [you will really
want to sue them over that remark, since you were SURE that only a guy who
charges money for his software was alllowed to be legally called greedy] who
wrote the software wants his cut and Ford wants their cut, but, says Toyota,
WE'RE not greedy like them and we offer you this whole thing for free." Back
at Toyota central, they're laughing their [whatever]s off because though they
make no money on the GPL'd version, its easy availability enhances their image
and the fact is that a car they have had trouble selling against Ford's $20K
car is now going to be an easy sell, because Ford will have to charge $25K.
Heck, they might even be able to afford to raise the price to $21K or $22K
and still have more featurism than the Ford $25K model because Ford was enough
of a sucker to buy your GPL'd license instead of use the stuff free.
Meanwhile, Ford doesn't quite figure this out, but senses there's a problem,
so they say to you "We'll only pay $500" thinking maybe they can charge $1000.
You, of course, are ecstatic, because this is a lot of money to you. You
run out and tell your friends how great this GPL stuff is and how you're going
to be rich. Meanwhile, Ford, who made the decision of going with you, has
enormous losses this quarter and teeters on bankruptcy. Probably not your
concern, though. "THose guys just don't know how to manage money," you say.
"Right," says your friend, the financial analyst. "They should known better
than to have bought your license when the thing was already available free."
"You just can't admit free software really works," you say back, irritated.
Of course, this story is entirely hypothetical. An American car company like
Ford would never screw up this badly financially, and a Japanese car company
like Toyota would never take blatant financial advantage of the market if an
American company did screw up. So you'll have to use SOME imagination here.
But I don't think I'm kidding when I say: the legal option to allow
someone to license your software while giving it away to others for
free is NOT the same as the market advisability of doing so. No more so
than saying it's ok to open all the windows in your house in the winter while
running the heater because you still retain the OPTION of closing the windows
in a room where you do want heat.
AND BTW, regarding the utter myth and propaganda that normally follows
paragraph 1 when a Follower of the One and Only One True Way of the
GPL sees my remark about $2500/car, let me nip that in the bud. They
quickly calculate that x million cars are sold (let's just say 1M for
round numbers because I'm bad at math), so that's $2.5 billion you'll
be making on your invention at $2500/car. That's too much for one
person to make, will say the GPL supporters, many (though not all) of
whom are wealth-redistributionist in their politics. "No one should
be allowed that sum of money because they will be rich and everyone
else will be poor" they will chant. The market isn't as moral as all
of that, so it doesn't believe the 'because' part of that statement,
but it *does* believe the first part. The market abhors one person
getting rich for more practical reasons: anyone with half a brain can
compute that for less than $2.5B they can develop THEIR OWN tool that
does the same thing as yours, and they can suffer along with only
$1250/car royalties, allowing Ford (in scenario 1) to sell the feature
maybe for only $2500 now, since there's a competitor, and only to get
$1250/car themselves, and not to get quite the volume of increased
sales they wanted. So Ford makes lots of money for the first six
months until the competitor version hits the market in a Volkswagon,
and then things level off a bit.. And suddenly you're making "only"
$1.25 billion. But some other guy then comes along and says, "hey, I
could do with _only_ .6 billion" and so he offers to develop a competitor
that is sold for _only_ $600/car .... and so it goes, with the market
squeezing out profits that didn't relate to cost and value, until the
market approaches the price it should have charged, not for moral reasons
but for practical reasons. The are dollars to be made for fast entry to
a market, for having a great new idea, etc. but they are fleeting. As
soon as your competitors see there's a wide-open source of free money, the
free money will vanish. So all this stuff I always hear where people
multiply out some huge number assuming it will get paid forever and
customers will be eternally screwed by your extortion is just so much
alarmism. The fact is that your best protection against competitive market
entry is to seek a RATIONAL market price so that someone will not see too
much free money being taken by you and they will see the cost of DEVELOPING
equivalent product to be the barrier. So the free market even encourages
people to not be too outlandish.
The real problem in here is software patents since they can inhibit
competitive forces. I have no patience with software patents nor
anything that protects properly independent reinvention. But let's not
get those two processes confused. People often point to capitalism as
the problem, and it's not. People need their development cost protected
from piracy, and things like copyright and trade secret do that. Patenting
doesn't protect JUST against piracy, though it does that too; its problem
is that it blocks ALL entry, including indepenent discovery. And that is
horrible.
Kent M Pitman <······@world.std.com> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Nicolas Neuss <·····@ortler.iwr.uni-heidelberg.de> writes:
> >
> > > I don't think that there are many people thinking that the GPL is a
> > > better choice when wanting to go into commercial licensing later on.
> > > As soon as anyone else contributes code (which I assume you want if
> > > you use either GPL or LGPL), you have to make him sign over his code
> > > to you (which probably is a tremendous bureaucratic effort that only
> > > the FSF affords to do[1]) or to make him agree with your commercial
> > > use.
> >
> > Actually, the GPL is very friendly with a dual Open / Proprietary
> > combination. Yes, the author needs to own the code. But, owning the
> > code, s/he can release it under the GPL, and offer paying customers a
> > license that will let them use it in their closed-source product. The
> > LGPL already gives this to them at no cost, and is thus a big loss for
> > the artisan toolmaker.
>
> Sure, legally they can make such an offer. But the commercial value of an
> option is computed by something like the difference between what the market
> will bear without the option and what it will bear with the option.
>
> Now, let's suppose you have a car with a computer and you've got the world's
> only automatic pilot (not just cruise control--this one turns corners, stops
> for small animals, mows the grass while you're away on weekends). You
> approach Ford. For says, "golly, no one else has this. it will make
> people want OUR cars. that will increase our volume of sales. plus, it's
> cool functionality, too, and that adds value to the car, so we can charge
> more." So they decide to charge customers a $5000 upgrade and you, a tough
> negotiator, get $2500 of each such thing.
The problem with your example is that it doesn't apply to this
instance. You're talking about an end product that the author's
giving away for free while simultaneously trying to sell this product
to Ford to bundle with their product. Semaphors are a tool for
building an end product (but one that needs to ship along with the
product). So, sure, there's a freely available version, but if it's
GPL, it can only be used to develop GPL software. I don't imagine
anyone would advertise their product as "Now with Semaphors!" anymore
than they would "Now with CLOS!". Instead, they'd advertise the
features they used this tool to develop, and just pay to use the tool.
I agree with your analysis as far as it applies to end-user products,
but tools are a different thing.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> The problem with your example is that it doesn't apply to this
> instance. You're talking about an end product that the author's
> giving away for free while simultaneously trying to sell this product
> to Ford to bundle with their product. Semaphors are a tool for
> building an end product (but one that needs to ship along with the
> product). So, sure, there's a freely available version, but if it's
> GPL, it can only be used to develop GPL software.
What do you mean it can only be used to develop GPL software? It's "free"
software isn't it? How is its use thus restricted? It seems to me, for
example, that it can also be used in-house for the production of arbitrary
packaged services as long as it's not itself distributed. Consider Emacs.
It would be naive to say that Emacs can only be used to construct more Emacs.
I can also use it to edit contracts for non-GPL agreements, to type in the
text of non-GPL programs, and even as the execution engine of a web product
based on proprietary services written in GNU emacs lisp and offered in a
non-GPL'd manner to the public at large through the web because I am not
through that vehicle offering any modified form of emacs to the public at
large.
It seems to me this latter technique (behaving as a server) is utterly
general. If you make me a product that you allege is GPL'd, such as
perhaps an automatic pilot, I can incorporate it into a server, let's
call it "OnBoard", and I can serve it by satellite to every vehicle in
the world for free (if I can solve bandwidth problems) such that it
can be called as a subroutine the same as if it were physically
present in memory. Instead of distributing the program, I'll just
take positional data into my home base (which, hey!, I can sell to the
government and big corporations--cool) and I'll yield back advice
about where to turn.
I see no violation of GPL here. What is the part about only
developing other GPL'd things?? This seems "obvious" to me. And it
damned well better not be patented by anyone, though I know it's the
vogue of the day to do things like that. It would be a funny/sad
irony if Microsoft DID patent such a technique, though, allowing them
to (a) have an antidote to GPL and (b) to be the ONLY company with
such an antidote...
> I don't imagine anyone would advertise their product as "Now with
> Semaphors!" anymore than they would "Now with CLOS!".
I haven't been tracking the whole of this conversation so don't know what
Semaphore is or how it relates.
> Instead,
> they'd advertise the features they used this tool to develop, and
> just pay to use the tool.
The only aspect of something like CLOS that strikes me off the bat to cause
an issue for GPL is that it means you have to have intensely high bandwidth
for my server strategy to succeed. You're basically talking about then
substituting a WAN for a computer's bus so that every low-level operation
goes through the server in order to avoid GPL issues. That could slow things
down a lot, and the speed of light would become an issue, but it doesn't
render it impossible IF the high-level application is of finite complexity
such that slow execution speed still yielded an appropriate realtime result.
With appropriate parallelism, caching, and other tricks, you might find you
could even do better than what seemed theoretically possible, too. Assuming
patents (the world's real market enemy) didn't get in the way of that, as
well. Also, with careful remodularization to isolate the task that required
this extra functionality, and then to migrate that functionality back to the
factory, replaced by bigger granularity, less frequent operations, you could
win, too.
I'm reminded of back when Multics wanted Emacs and the operating system
authors didn't think the machine could bear the real-time effect of having
every program wake up on every keystroke (the reason they'd chosen line
at a time I/O--so the operating system could handle most I/O). They invented
the echoin system call that allowed the program to say to the operating
system "I'm in character-at-a-time-mode but for the next 15 characters, if
they are any of the following set, it will suffice for you to just accumulate
and echo characters AS IF I were not needing them one at a time. Just burst
them to me all at once if the person types anything outside the following
self-inserting set or if they exceed the fifteen character window." In
effect, this made system performance fine, and papered over the need for
high-bandwidth interaction in a way not dissimilar to how I'd expect
GPL-evading servers to do, one day not too far in the future when people
decide to get serious about working around GPL.
> I agree with your analysis as far as it applies to end-user products,
> but tools are a different thing.
[ Anyone who didn't read Kent's post, should. I hate having low
response-to-quoting ratios, so I'm just quoting the lines I want to
respond to, not his entire point leading up to them. If you want to
know why he'd say whatever I'm quoting, go look and see. ]
Kent M Pitman <······@world.std.com> writes:
> ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > The problem with your example is that it doesn't apply to this
> > instance. You're talking about an end product that the author's
> > giving away for free while simultaneously trying to sell this product
> > to Ford to bundle with their product. Semaphors are a tool for
> > building an end product (but one that needs to ship along with the
> > product). So, sure, there's a freely available version, but if it's
> > GPL, it can only be used to develop GPL software.
>
> What do you mean it can only be used to develop GPL software?
I thought we were talking about software-for-redistribution here,
because the GPL doesn't constrain in-house development, you're right.
Of course, maybe it was only me who was talking limiting himself to
redistribution.
> It seems to me this latter technique (behaving as a server) is
> utterly general.
It's theoretically general. For practical purposes, only a limited
set of applications can do this, because bandwidth is still kind of
expensive, and I don't think it's going to become massively cheap
anytime soon. I might be wrong, but I think it'll be at *least*
another economic cycle before this happens.
For someone who's trying to both share and sell a development
tool-library, this is a definite weakness in the GPL. Probably one
could devise a license that would count this as a sort of
distribution, but it wouldn't be very useful. The only reason anyone
uses the GPL is because "everyone" does. A world with more than a
couple GPL-alike licenses would become really painful really fast.
RMS and Eben Moglin (the FSF counsel) made some noise about revising
the GPL to address this linking-by-making-it-a-server problem. If the
FSF added that restriction to all its software, then such a license
would be fairly usable, but they're the only ones with the will and
ability to change enough software to such a license to make it usable.
A more problematic (for the tool author) version of this same way
around the GPL would be to "not link" by wrapping the tool in a CORBA
server, and distributing that GPL package separately from the rest of
the application. I don't think this would be a problem for Kenny
because, for his tool, this would be *waaaay* too much of a
performance hit.
> > I don't imagine anyone would advertise their product as "Now with
> > Semaphors!" anymore than they would "Now with CLOS!".
>
> I haven't been tracking the whole of this conversation so don't know what
> Semaphore is or how it relates.
Sometimes usenet can be as bad as eavesdropping :-). Semaphors are
Kenny Tilton's simple-constraints extension to CLOS that he wants to
share with the community, but he also wants to leave his commercial
options open, if people other than himself get excited about it.
[I hate speaking for others, but I think that's a good summary of his
posts on the subject]. This isn't (or wasn't supposed to be?) an
abstract discussion about the GPL, but one very concrete.
> I'm reminded of back when Multics wanted Emacs and the operating system
> authors didn't think the machine could bear the real-time effect of having
> every program wake up on every keystroke (the reason they'd chosen line
> at a time I/O--so the operating system could handle most I/O). They invented
> the echoin system call that allowed the program to say to the operating
> system "I'm in character-at-a-time-mode but for the next 15 characters, if
> they are any of the following set, it will suffice for you to just accumulate
> and echo characters AS IF I were not needing them one at a time. Just burst
> them to me all at once if the person types anything outside the following
> self-inserting set or if they exceed the fifteen character window." In
> effect, this made system performance fine, and papered over the need for
> high-bandwidth interaction in a way not dissimilar to how I'd expect
> GPL-evading servers to do, one day not too far in the future when people
> decide to get serious about working around GPL.
Yeah, a technique like that would probably be useful for getting
around the GPL in a very large number of cases. On that note, I do
hope the FSF revises the GPL to address this, before it becomes too
outdated, and doesn't provide enough protections for authors to feel
comfortable sharing their work.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C180D7C.2DD0C0AB@nyc.rr.com>
"Thomas F. Burdick" wrote:
>
> Kent M Pitman <······@world.std.com> writes:
>
> > ···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > > I don't imagine anyone would advertise their product as "Now with
> > > Semaphors!" anymore than they would "Now with CLOS!".
two things. first, from the cover of my ACL box: "Allegro CL dynamic
object oriented programming system...Featuring CLOS". Also the tag line
"Franz Inc. The Leader in Dynamic Objects". Who needs an encyclopedia to
diss us when the number one vendor is making like Peter denying Jesus
six times before the cock crowed? <g> Just kidding, they're trying to
make a buck. Language and tool vendors sure crowed about "we do OO!"
back when everyone thought it was the Next Great Thing.
Second: "Now with Semaphors!"? I like it. :) And I will not be surprised
if that happens. But they won't call it Semaphors unless I LGPL it. Once
they see the functionality they'll just dust off all the constraints
research and replicate it easily. All I have done is blend the dataflow
in seamlessly with the host language, and stay away from the tar pit of
multi-way constraints...ok, and settle for the perturbation model over
the refinement model. The constraints crowd tended to make new
languages, and they went a bridge too far with the multi-way thing.
> Sometimes usenet can be as bad as eavesdropping :-). Semaphors are
> Kenny Tilton's simple-constraints extension to CLOS that he wants to
> share with the community, but he also wants to leave his commercial
> options open, if people other than himself get excited about it.
>
> [I hate speaking for others, but I think that's a good summary of his
> posts on the subject].
Sounds about right. I truly have not thought it through, but
counterintuitively I might be more inclined to go LGPL if Semaphors
really took off. Why release it completely if no one is going to use it?
:)
But again, I really do not think anyone needs my code. once folks see
what is going on and how cool it is, they'll be assigning Semaphors as a
student project in grad school. It's really very obvious. Easier than
implementing OO, certainly, and no one has too much trouble reinventing
that for diff language vendors.
kenny
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C17790F.4BDEB59D@nyc.rr.com>
Nicolas Neuss wrote:
>
> As soon as anyone else contributes code (which I assume you want if
> you use either GPL or LGPL), you have to make him sign over his code
> to you (which probably is a tremendous bureaucratic effort that only
> the FSF affords to do[1])
Why is it "probably...a tremendous bureaucratic effort"?
kenny
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<·················@nyc.rr.com>...
>
> Why is it "probably...a tremendous bureaucratic effort"?
because you have to get paper signed, by the person authorised to sign
it (often not the author of the code) for every bit of code you want
to use that you didn't write. A real pain.
--tim
Kenny Tilton <·······@nyc.rr.com> writes:
> Nicolas Neuss wrote:
> >
> > As soon as anyone else contributes code (which I assume you want if
> > you use either GPL or LGPL), you have to make him sign over his code
> > to you (which probably is a tremendous bureaucratic effort that only
> > the FSF affords to do[1])
>
> Why is it "probably...a tremendous bureaucratic effort"?
>
> kenny
OK, I guess you're right and it isn't for your single project. It
means more effort for the contributor (but to be sure to be allowed to
contribute, he should anyway get the written permission of his
employer - if there is any).
Perhaps, you should also make things clear then, by choosing a license
like the QPL which allows you exclusive rights. Equal rights for all
users is in my eyes one of the central points of the GPL and LGPL.
Nicolas.
Nicolas Neuss <·····@ortler.iwr.uni-heidelberg.de> writes:
> OK, I guess you're right and it isn't for your single project. It
> means more effort for the contributor (but to be sure to be allowed to
> contribute, he should anyway get the written permission of his
> employer - if there is any).
Actually, a contributor only needs to get this permission in those
barbaric lands that view an employee as a serf and count said serf's
off-work production as the property of the company. Of course, since
California is still this barbaric, one does need to consider the
barbarians, but hopefully we won't be in this medieval situation
forever -- and not all the world is uncivilized, so we sure shouldn't
forget about them.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas Burdick wrote:
> Actually, a contributor only needs to get this permission in those
> barbaric lands that view an employee as a serf and count said serf's
> off-work production as the property of the company. Of course, since
> California is still this barbaric, one does need to consider the
> barbarians,
Are you sure about California? I'm sure I remember reading
something from the California Labor Code, or whatever it's
called, that very specifically forbade employers to claim
rights to such work. Am I confused?
--
Gareth McCaughan ················@pobox.com
.sig under construc
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C17A525.290D81E@nyc.rr.com>
Nicolas Neuss wrote:
> OK, I guess you're right and it isn't for your single project. It
> means more effort for the contributor (but to be sure to be allowed to
> contribute, he should anyway get the written permission of his
> employer - if there is any).
Well, Semaphors are kind of all or nothing, it is a different paradigm
so it is hard to do halfway. So I doubt anyone will use this at work for
a while. And then there will be no problem because I will either LGPL it
or license it very reasonably.
Anyway, anyone getting involved will already be doing GPL stuff or will
just be doing it for the fun of it if they groove on Semaphors like I
do.
>
> Perhaps, you should also make things clear then, by choosing a license
> like the QPL which allows you exclusive rights.
[waiting for someone to yell "take it to gnu.misc.discuss!" <g>...] As
others have noted, nothing about either GNU license restricts me from
doing other things with my copyrighted work, so I do not need the QPL to
"allow [me] exclusive rights".
I did look at the QPL, looked good at first. But it is not GGPL
compatible. To a degree I am hitching my wagon to the GGPL for whatever
that is worth in the way of reaching more people, and of course in hope
of bringing down M$. :)
(No one interested in using Semaphors commercially should hesitate, it
will be licensed reasonably.)
> Equal rights for all
> users is in my eyes one of the central points of the GPL and LGPL.
>
Well, the GPL is a little tricky. Your understanding is correct for all
but one user--the copyright owner/licensor.
kenny
Kenny Tilton <·······@nyc.rr.com> writes:
...
> > Perhaps, you should also make things clear then, by choosing a license
> > like the QPL which allows you exclusive rights.
>
> [waiting for someone to yell "take it to gnu.misc.discuss!" <g>...]
In spite of the <g>, I want to remark on this...
The reason that I, at least, do not ever say this and sometimes
indulge the discussion myself is that (a) I like to talk about such
issues in context, (b) I think there is a good density of smart people
here that I'd rather talk to, and (c), most importantly, I think that
the issue of how to productize things is as CRITICAL to the process of
succeeding with lisp as any technical matter.
People say we're short success stories, but it's not always technical
matters that have caused this. Symbolics is a should-have-been
success story, but it was largely killed by business problems, not
technical ones. And until our community starts to learn tha business
problems don't just solve themselves, that good technology does not
automatically beat out bad, and that we have to each actively work to
assure that bad business practices aren't going to kill good ideas,
we're going to be haunted by people claiming that Lisp is the problem.
Because people are always looking for scapegoats if it's their own
failure, and people from outside are always looking for random
quasi-data to pretend to back up their own non-scientific
observations.
One might say that it doesn't matter that Lisp talk to external
languages and that maybe foreign function call should be better talked
about on comp.lang.c, but we have all finally learned better. I think
discussion of gpl is on par with such technical interface matters and
a first class part of the fabric of what it is to be Lisp, which is to
say, how do we present our products to the marketplace.
There may even turn out to be technical reasons for needing to know the
business model people are using somewhere down the line, in order to build
in programmatic safeguards that people are or aren't doing certain things.
But even absent such arguments, I think it's a worthwhile area of discussion.
No one of us controls this newsgroup, so we can't reach a true
consensus on what it is and isn't right to discuss here. But at least
I hope I've offered some tenuous justification of my own posts on this
matter and some confort to those who would do likewise (regardless of whether
they do so to agree with me or to disagree with me; as I always say: there
are no political answers, only political questions.)
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C17852B.A60B5A64@nyc.rr.com>
Nicolas Neuss wrote:
> > Now I want to focus on sharing/documenting Semaphors and think about
> > LGPL if it becomes an issue. If no one else digs Semaphors we're done.
> > :)
>
> By the way, I also don't think semaphor a good name.
Sorry, what I meant was "If one else likes the functionality offered by
Semaphors then I and CliniSys employees will be the only ones who have
to use that name, so there will be no need to worry about the name
'Semaphors'"
kenny
From: Arseny Slobodjuck
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c174a2d.48310316@news.vtc.ru>
On Wed, 12 Dec 2001 07:00:56 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>If no one else digs Semaphors we're done.
>:)
I'm using similar thing for about 3 years in numeric calculation
program written in C++ and calling it Maker. Maybe I'll publish it
some day, just want to state that it is independent work.
BTW, did you think about following kind of circular dependencies ?
Suppose you want to have two cells, one should hold Celsius
temperature (C) and other - Kelvin temperature (K). So when you change
C, K recalculates to C + 273 and when you change K, C becomes K - 273.
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C178E1B.C73874CD@nyc.rr.com>
Arseny Slobodjuck wrote:
>
> On Wed, 12 Dec 2001 07:00:56 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
> >If no one else digs Semaphors we're done.
> >:)
> I'm using similar thing for about 3 years in numeric calculation
> program written in C++ and calling it Maker. Maybe I'll publish it
> some day, just want to state that it is independent work.
No problem. There is a ton of "prior art". Garnet, COSI, the entire
constraints programme, Maker <g>....
>
> BTW, did you think about following kind of circular dependencies ?
> Suppose you want to have two cells, one should hold Celsius
> temperature (C) and other - Kelvin temperature (K). So when you change
> C, K recalculates to C + 273 and when you change K, C becomes K - 273.
That has been addressed to some degree already, more is planned.
Right now, if C and K are declared to be "cyclic", the engine tolerates
this:
(def-sm-echo (C) (self newValue oldValue)
(setf (K self)....))
...and at the same time:
(def-sm-echo (K) (self newValue oldValue)
(setf (C self)....))
Otherwise it signals an error rather than loop indefinitely.
A next step would be to allow:
(make-instance 'thermometer
:C (sm? (- (K self) 273)))
:K (sm? (+ (C self) 273))))
At that point you could say (setf (K it) 0) and then C would have a
value, or vice versa. But until then the system would, I don't
know..return nil? ...signal an "unbound" error?
A more ambitious step would be something new for Semaphors (which I
always enjoy doing): a facility to allow on-the-fly creation of a rule
for two different slots in one shot. But that gets into solving a single
given formula for different variables--not hard, I just have not run
into a need for that on the things I have happened to use Semaphors for.
kenny
From: Arseny Slobodjuck
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c189f9e.17324371@news.vtc.ru>
On Wed, 12 Dec 2001 17:00:33 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
> (make-instance 'thermometer
> :C (sm? (- (K self) 273)))
> :K (sm? (+ (C self) 273))))
>
>At that point you could say (setf (K it) 0) and then C would have a
>value, or vice versa. But until then the system would, I don't
>know..return nil? ...signal an "unbound" error?
I think, when Semaphore system can not handle it properly it most like
an error. Same as for cycles of 3,4,5... cells.
Have a flag - Computed Value -vs- Entered Value
start both (all) with CVs, nil if you try to eval
when one gets an EV (set), set CV & eval the others
- or time-stamps, last EV wins
just some high-level ideas
Arseny Slobodjuck <····@crosswinds.net> wrote in message
······················@news.vtc.ru...
> On Wed, 12 Dec 2001 17:00:33 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
> > (make-instance 'thermometer
> > :C (sm? (- (K self) 273)))
> > :K (sm? (+ (C self) 273))))
> >
> >At that point you could say (setf (K it) 0) and then C would have a
> >value, or vice versa. But until then the system would, I don't
> >know..return nil? ...signal an "unbound" error?
> I think, when Semaphore system can not handle it properly it most like
> an error. Same as for cycles of 3,4,5... cells.
From: Kenny Tilton
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C192B3C.9952BF4C@nyc.rr.com>
Well, on further thought, the thermometer is not such a good example,
and good examples are important. As kent says, "Concrete comes with
details".
I would handle a thermometer one of two ways:
1. pick a unit of measure (probably Kelvin) and make it a Kelvin
thermometer, offering readouts in F or C as separate derived slots (or
just let normal functions unrelated to semaphors do the conversion).
2. Store temperature as (make-measurement :value 98.6 :units
:fahrenheight)
I like the latter because if we are going to be dealing with physical
measurements we may as do it right, and I do not think the number 98.6
by itself means anything. Better to encapsulate unit and number in a
self-documenting structure which forces application code to deal with
the units. (any attempt to do straight arithmetic with the readout
(mistakenly assuming it was, say, celsius) gets nailed by approach two
but not approach one.
A better example is scrolling. The position of the scroll bar thumb
reflects the page position, the page positon changes according to the
position of the scroll bar thumb. Not only that, it should be possible
to open the document to a position other than the top, so is a
functional approach even possible?
hey, maybe that timestamp idea is not so bad. that actually is the
spirit of a lot of what I do to solve these nasty problems where data is
flowing in from multiple sources: I just let arbitrary code set a
certain value, figuring the last one in is the one I want. But one of
the big wins of Cells (ne Semaphors) is the declarative thing: all the
semantics possible for a slot in one rule.
So I could have a rule which first looked for the latest time stamp of
initial, thumb and page positions and then uses the latest.
Well, you just reminded me that I have long planned on winning some
efficiency by having Synapses (filters between two Cells) operate
directly on the using cell when the used cell changed. For example:
:balance-now (sm? (- (balance-start-of-day self) (transactions-today
(fSetDelta #'-)))))
Then the Synapse would instead of triggering reevaluation of the whole
rule simply subtract the delta of the day's action from the most recent
value of balance-now. of course this is not a very expensive rule to
run, but where the rule was a hog this would be worthwhile.
getting back to scrolling, something like that would preserve the
advantage of being able to look one place to see all the semantics of a
value. I would have an abstract scroll-position:
:scroll-position (sm? (or (initial-position (fSet #'identity))
(page-position <same>)
(thumb-position <etc>
kenny
"Michael J. Ferrador" wrote:
>
> Have a flag - Computed Value -vs- Entered Value
>
> start both (all) with CVs, nil if you try to eval
> when one gets an EV (set), set CV & eval the others
>
> - or time-stamps, last EV wins
> just some high-level ideas
>
> Arseny Slobodjuck <····@crosswinds.net> wrote in message
> ······················@news.vtc.ru...
> > On Wed, 12 Dec 2001 17:00:33 GMT, Kenny Tilton <·······@nyc.rr.com>
> > wrote:
> >
> > > (make-instance 'thermometer
> > > :C (sm? (- (K self) 273)))
> > > :K (sm? (+ (C self) 273))))
> > >
> > >At that point you could say (setf (K it) 0) and then C would have a
> > >value, or vice versa. But until then the system would, I don't
> > >know..return nil? ...signal an "unbound" error?
>
> > I think, when Semaphore system can not handle it properly it most like
> > an error. Same as for cycles of 3,4,5... cells.
From: Arseny Slobodjuck
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c19d07a.5738251@news.vtc.ru>
On Thu, 13 Dec 2001 22:23:54 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>Well, on further thought, the thermometer is not such a good example,
>and good examples are important.
Real case is like your scrolling example. But it have too many
unnecessary details...
>As kent says, "Concrete comes with
>details".
I don't like details.
>
>I would handle a thermometer one of two ways:
>
>1. pick a unit of measure (probably Kelvin) and make it a Kelvin
>thermometer, offering readouts in F or C as separate derived slots (or
>just let normal functions unrelated to semaphors do the conversion).
_Unrelated_. I want to avoid that.
>
>2. Store temperature as (make-measurement :value 98.6 :units
>:fahrenheight)
Yes ! I love that !
>A better example is scrolling. The position of the scroll bar thumb
>reflects the page position, the page positon changes according to the
>position of the scroll bar thumb. Not only that, it should be possible
>to open the document to a position other than the top, so is a
>functional approach even possible?
If you mean (1), of course it possible, but ugly.
>hey, maybe that timestamp idea is not so bad.
You're not using it ? I have used recursion at the beginning, but then
rewrote all the stuff with timestamps.
>So I could have a rule which first looked for the latest time stamp of
>initial, thumb and page positions and then uses the latest.
If you're not demanding consistency from the whole 'worksheet' then
yes.
From: Arseny Slobodjuck
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c19d4cb.6843880@news.vtc.ru>
On Thu, 13 Dec 2001 19:13:30 GMT, "Michael J. Ferrador"
<·····@orn.com> wrote:
>Have a flag - Computed Value -vs- Entered Value
>
>start both (all) with CVs, nil if you try to eval
>when one gets an EV (set), set CV & eval the others
>
>- or time-stamps, last EV wins
Absolutely. But it mean change rules (and a flag) each
time one of circular cells changed, it's too expensive :(
BTW, I have a termins - 'terminal' for EV and 'non-terminal'
for CV. I steal it in formal language theory, hope they
don't need it anymore.
Hey maybe I just invented an non expensive answer.
Have to check it.. But it can't be that smb didn't invent
it 40+ years ago. On ENIAC... Horse-driven...
"Arseny Slobodjuck" <····@inbox.ru> wrote in message
·····················@news.vtc.ru...
> On Thu, 13 Dec 2001 19:13:30 GMT, "Michael J. Ferrador"
> <·····@orn.com> wrote:
>
> >Have a flag - Computed Value -vs- Entered Value
> >
> >start both (all) with CVs, nil if you try to eval
> >when one gets an EV (set), set CV & eval the others
> >
> >- or time-stamps, last EV wins
>
> Absolutely. But it mean change rules (and a flag) each
> time one of circular cells changed, it's too expensive :(
> BTW, I have a termins - 'terminal' for EV and 'non-terminal'
> for CV. I steal it in formal language theory, hope they
> don't need it anymore.
>
Why not just compare the new value with the old value and
only make changes when it's different?
Rough sketch for a class...
(defmethod this-writer ((self class) value)
(unless (eq-family-testfn (slot-value obj 'this) newvalue)
;; make sure everyone can see the new value
(setf (slot-value obj 'this) newvalue)
;; fix everything else
(setf (that-writer self) ...)
(setf (the-other-writer self) ...))
Geoff
From: Arseny Slobodjuck
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c1aa701.2015017@news.vtc.ru>
On Fri, 14 Dec 2001 16:15:56 GMT, "Geoff Summerhayes"
<·············@hNoOtSmPaAiMl.com> wrote:
>> >Have a flag - Computed Value -vs- Entered Value
>> >
>> >start both (all) with CVs, nil if you try to eval
>> >when one gets an EV (set), set CV & eval the others
>> >
>> >- or time-stamps, last EV wins
>>
>> Absolutely. But it mean change rules (and a flag) each
>> time one of circular cells changed, it's too expensive :(
>> BTW, I have a termins - 'terminal' for EV and 'non-terminal'
>> for CV. I steal it in formal language theory, hope they
>> don't need it anymore.
>>
>
>Why not just compare the new value with the old value and
>only make changes when it's different?
>Rough sketch for a class...
>
>(defmethod this-writer ((self class) value)
newvalue ?
> (unless (eq-family-testfn (slot-value obj 'this) newvalue)
> ;; make sure everyone can see the new value
> (setf (slot-value obj 'this) newvalue)
> ;; fix everything else
> (setf (that-writer self) ...)
> (setf (the-other-writer self) ...))
You mean, avoid cycling by that smart set procedure ? Unfortunately,
it will not working for floats, even if you have two complement
formulas, i.e. B = A * 2 <-> A = B / 2, error will arise and all
becomes cycling... But that is much like an OT already.
From: Kenny Tilton
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C1EAEDA.9E8ECC51@nyc.rr.com>
Arseny Slobodjuck wrote:
>
> On Fri, 14 Dec 2001 16:15:56 GMT, "Geoff Summerhayes"
> <·············@hNoOtSmPaAiMl.com> wrote:
>
> >> >Have a flag - Computed Value -vs- Entered Value
> >> >
> >> >start both (all) with CVs, nil if you try to eval
> >> >when one gets an EV (set), set CV & eval the others
> >> >
> >> >- or time-stamps, last EV wins
> >>
> >> Absolutely. But it mean change rules (and a flag) each
> >> time one of circular cells changed, it's too expensive :(
> >> BTW, I have a termins - 'terminal' for EV and 'non-terminal'
> >> for CV. I steal it in formal language theory, hope they
> >> don't need it anymore.
> >>
> >
> >Why not just compare the new value with the old value and
> >only make changes when it's different?
> >Rough sketch for a class...
> >
> >(defmethod this-writer ((self class) value)
> newvalue ?
> > (unless (eq-family-testfn (slot-value obj 'this) newvalue)
> > ;; make sure everyone can see the new value
> > (setf (slot-value obj 'this) newvalue)
> > ;; fix everything else
> > (setf (that-writer self) ...)
> > (setf (the-other-writer self) ...))
>
> You mean, avoid cycling by that smart set procedure ? Unfortunately,
> it will not working for floats, even if you have two complement
> formulas, i.e. B = A * 2 <-> A = B / 2, error will arise and all
> becomes cycling... But that is much like an OT already.
I think the idea behind eq-family-testfn is to provide control over
issues like float results deviating by very small amounts for the same
morally equivalent computation. Cells (ne Semaphors) has a callback like
that, a GF with the parameters: instance, slotname, oldvalue newvalue.
And yes, Cells works via "smart setf", but in (setf
slot-value-using-class), ie lower down than Geoff's quick example.
Similarly dependencies are identified automatically (in
slot-value-using-class) so the user does not worry about which other
cells need notification once it has been determined that a cell has
changed.
So, no, no timestamp yet. I was thinking of that to resolve a specific
dataflow issue where one of several sources determined a value and the
choice really was based on which source changed most recently.
btw, you mentioned not wanting to have a flag or something like that,
saying it was too slow. Makes me wonder if you are doing some intensive
numerical analysis for which Cells might prove too expensive.
kenny
clinisys
From: Arseny Slobodjuck
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c1f4217.3734519@news.vtc.ru>
On Tue, 18 Dec 2001 02:46:46 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>I think the idea behind eq-family-testfn is to provide control over
>issues like float results deviating by very small amounts for the same
>morally equivalent computation.
Didn't wanted to tell about it, but what about giant vectors or
matrices of floats or just 1M strings ?
>And yes, Cells works via "smart setf", but in (setf
>slot-value-using-class), ie lower down than Geoff's quick example.
>So, no, no timestamp yet. I was thinking of that to resolve a specific
>dataflow issue where one of several sources determined a value and the
>choice really was based on which source changed most recently.
Making a one typed source cell instead of two as you suggested before
seems more eleghant to me. But I'm not insist on that handling of such
situalions must necessarily present! I thinking about it last months,
therefore I asked about it. But it seems to me I found the way to do
it in my realisation. But first I'll read Steele's paper whether it
being done better 20 years ago...
>btw, you mentioned not wanting to have a flag or something like that,
>saying it was too slow. Makes me wonder if you are doing some intensive
>numerical analysis for which Cells might prove too expensive.
I'm still learning English, so information loss occurs in both
directions. BTW, where does lower-down found ? What I talked about is
applicable only to my realisation, where dependencies are being
processed once all 'woksheet' filled in. In that processing, internal
information is gennerated and then that information is used when cells
changed. If we change dependencies each time some cell values being
changed all that internal structures ought to be rebuilt. Moreover
it's slightly not right. If you have no such internal structures, you
have no such problem.
From: Kenny Tilton
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C1F7FB1.89A8AF97@nyc.rr.com>
Arseny Slobodjuck wrote:
>
> On Tue, 18 Dec 2001 02:46:46 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
> >I think the idea behind eq-family-testfn is to provide control over
> >issues like float results deviating by very small amounts for the same
> >morally equivalent computation.
> Didn't wanted to tell about it, but what about giant vectors or
> matrices of floats or just 1M strings ?
Well, I know you do not like details <g>, but when it comes down to
optimizing (and that is what we are talking about here) it's /all/ in
the details. So I will just have to guess at the details and offer a
solution to one of my guesses.
OK, on the 1M string: the requirement is to destructively modify the
string to avoid consing, then have propagation kicked off even though
the slot value per se goes unchanged. What I would do is define a new
kind of Cell, maybe cell-mutable.
(defmodel whatever ()
((big$ :cell :mutable :initarg :big$ :accessor big$)))
Then I would fudge the semantics of setf to be:
(setf <mutable-place> <mutation>)
ie, setf /applies/ a coded mutation to the slot value:
(setf (mutation mystring) `(insert ,new-chars :at ,offset))
A (setf slot-value-using-class) for such slots (diff cells end up with
diff slot definitions) would modify the wrapped string by decoding the
mutation value. An alternative would be to set mutation to a function to
be applied to the string, but with the approach given we also have the
option of letting cells dependent on the string limit their interest to
a portion of the string or certain operations against that string. This
would work by giving dependent cell a synapse which makes explicit the
interest in the string. Something like that.
If messing with the semantics of (setf SVUC) proved to be bad news, I
could always just invent MUTATEF and require the programmer to use that
to mutate large structures.
The nice thing about Lisp and CLOS and MOP and open source is that one
never gets backed into a corner; where the normal approach (recopying
the whole slot value) is too expensive, a little subterfuge can achieve
efficiency without breaking the system.
> I'm still learning English, so information loss occurs in both
> directions. BTW, where does lower-down found ?
Sorry, Geoff had tossed off a "smart setf" which sat outside (above?)
slot-value and (setf slot-value). Cells work by specializing
slot-value-using-class, which is reached from slot-value. "lower-down"
was my metaphor for, well, here I go again, a lower-level function.
> If we change dependencies each time some cell values being
> changed all that internal structures ought to be rebuilt.
No, because we have the dependency information so everything that flows
from a state change is highly targeted. Change one cell and only those
cells dependent on that one cell get recalculated. Nothing necessarily
gets rebuilt, by the way, tho in this case:
:my-cell (sm? (if (^a) (^b) (^c)))
where A changes between nil and non-nil the dependency switches between
c and b, so one dependency gets rewired. But if A is true and B changes,
my-cell gets a new value but no rewiring takes place; the dependencies
do not change.
> Moreover it's slightly not right.
What flaw do you see? Might again come down to some implementation
detail I have not made clear. FWIW, I have done a ton of work using
Cells and really pushed them to the limit, and they work even where I
expect them to fail. That said, I recently did some rewiring to resolve
a longstanding theoretical flaw that to date had only caused a little
inefficiency, and maybe more such holes exist, but in the field Cells
just work.
> If you have no such internal structures, you
> have no such problem.
You can run but you cannot hide. :) And again it comes down to details,
and I think we are doing a fair job of communicating even tho neither of
us knows what the other is doing. :)
What is saved by not tracking dependencies is lost by not knowing those
dependencies; if a cell changes, what needs recomputing? Everything? No,
you mentioned timestamps, perhaps this is the lazy way? each time a
value is used, you check to see if the operands used in the calculation
are current? meaning you are recording which operands were used and what
timestamp they had when used. But you must check recursively, because if
A uses B and B uses C and then C changes, an access to A will look at B
and think it has the current value unless B recursively checks its
current-ness.
So the lazy approach works even harder than the eager approach, unless
we just throw the burden of keeping state consistent back on the
programmer, defeating the whole paradigm. The lazy approach has to check
current-ness on each access, because it never knows what might have
changed. The eager approach is decisive: it knows what to change, it
changes it, recursively seeing to an optimally minimum recalculation of
the overall dependency graph, and then it is done. Thereafter slot
access need check only the status of the slot accessed before simply
returning its slot value.
kenny
clinisys
From: Arseny Slobodjuck
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c20d4b2.34080855@news.vtc.ru>
On Tue, 18 Dec 2001 17:36:55 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>> >I think the idea behind eq-family-testfn is to provide control over
>> >issues like float results deviating by very small amounts for the same
>> >morally equivalent computation.
>> Didn't wanted to tell about it, but what about giant vectors or
>> matrices of floats or just 1M strings ?
>
>Well, I know you do not like details <g>, but when it comes down to
>optimizing (and that is what we are talking about here) it's /all/ in
>the details. So I will just have to guess at the details and offer a
>solution to one of my guesses.
>
>OK, on the 1M string: the requirement is to destructively modify the
>string to avoid consing, then have propagation kicked off even though
>the slot value per se goes unchanged. What I would do is define a new
>kind of Cell, maybe cell-mutable.
I meant, checking for equality may have an overhead. It's more lazy
to implement a system without such checking (because 1-it may have an
overhead, 2-it can have an errors on floats). It may be done with help
of timestamps or (maybe) something else.
>was my metaphor for, well, here I go again, a lower-level function.
lower-level is ok. It's clear.
>> If we change dependencies each time some cell values being
>> changed all that internal structures ought to be rebuilt.
>
>No, because we have the dependency information so everything that flows
>from a state change is highly targeted.
Sorry, you mean highly targeted lower-down ?
>Change one cell and only those
>cells dependent on that one cell get recalculated.
>Nothing necessarily
>gets rebuilt, by the way, tho in this case:
>
> :my-cell (sm? (if (^a) (^b) (^c)))
>
>where A changes between nil and non-nil the dependency switches between
>c and b, so one dependency gets rewired. But if A is true and B changes,
>my-cell gets a new value but no rewiring takes place; the dependencies
>do not change.
That way it's all right. You didn't changed the rules in process of
dataflow. You just calculated a cell taking cells a,b,c as inputs,
no matther how you combined them.
>
>> Moreover it's slightly not right.
>
>What flaw do you see? Might again come down to some implementation
>detail I have not made clear.
I mean, it's not right to do rewiring in process of propagation.
Or there should be some theory, letting this in some cases.
That theory shoud prove that calculations ends up (no endless
loop) and result of calculations will be same as expected in
all combinations of inputs. I don't see how to reach that goals
with such rewiring anarchy.
>> If you have no such internal structures, you
>> have no such problem.
>
>You can run but you cannot hide. :) And again it comes down to details,
>and I think we are doing a fair job of communicating even tho neither of
>us knows what the other is doing. :)
You are right. But I'm sorry, I'm not ready to discuss my
propagation method until I'll read some papers in the field and
found it's description. Maybe it's silly to think nobody thinked it
out, but you read a number of papers and not found it... There is
unhealthy tendency last time to patent every 2+2, so I may loose a
right to use a method just talking about it here. Or it's a
paranoia...
As about your COWS (Cells that Originally Were Semaphores). I'm still
not familiar with CLOS, all the more MOP, so I'll not understand it
by now. Although maybe I'll understand CLOS investigating Cells ;)
From: Kenny Tilton
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C21398F.4D0F6DAB@nyc.rr.com>
Arseny Slobodjuck wrote:
>
> I meant, checking for equality may have an overhead. It's more lazy
> to implement a system without such checking (because 1-it may have an
> overhead, 2-it can have an errors on floats). It may be done with help
> of timestamps or (maybe) something else.
OK, understood. Like I said, the so-called "lazy" scheme never knows
what has changed so it has these problems. My dataflow model takes a
change and sees to its propagation, period. Everything is then
up-to-date so any valid value is known to be current. (Invalid values
are ones that have never been accessed before and will then be computed
for the first time, establishing dependencies so they get updated when
necessary.)
One issue here is that slot writing does not happen as often as slot
access, so I like having the work done when the write perturbs the
system.
More importantly, the lazy model is not a true dataflow model in that
the propagation does not happen automatically, other logic rather
randomly I imagine brings any given data point up-to-date.
> >No, because we have the dependency information so everything that flows
> >from a state change is highly targeted.
> Sorry, you mean highly targeted lower-down ?
Not sure which way to take that, so I will answer the two
interpretations I see:
1. The /process/ of recording dependency information happens
transparently/automatically and at a very low level, during slot-value
or (setf slot-value), ie when CLOS slots get read or written.
2. The targets per se are cells which define values for attributes of
model instances, so that is at a very high level, at the level of
abstraction of the model.
eg, I might have the color of a flame dependent on the temperature and
material that is burning. that is high level to me. then the rule looks
like:
(make-instance 'flame
:color (sm? (decide-color (temp self) (fuel <some-fire>)))
...and the dependencies and dataflow are set up transparently (except
for the necessary 'sm?' form). So that is going on at a very low level.
> I mean, it's not right to do rewiring in process of propagation.
I gather you have read about systems which do that? I did see talk of
updating the most recent direction in which data flowed in multi-way
constraints, but that is all. I also saw something about computing the
dependency graph once when the user grabbed a widget for dragging, so
response would be adequate. Which implies the dependency graph can be
worked if needed (by watching an initial uninformed perturbation?) but
is not normally available.
Cells definitely spend system resources to produce their benefits, I
just think the resources are well-spent given those benefits.
> Or there should be some theory, letting this in some cases.
> That theory shoud prove that calculations ends up (no endless
> loop) and result of calculations will be same as expected in
> all combinations of inputs.
Well, the multi-way crowd concedes they have trouble getting the results
they expect, forcing them into elaborate schemes to try to get control
over the computation. I remember reading about "walkabout strengths" and
deciding, OK, this like trying to contain fusion, fuggedaboutit for my
simple needs.
> I don't see how to reach that goals
> with such rewiring anarchy.
Cells at first seemed anarchic, but really it was just that I was no
longer in control of the order of computation. I was programming
declaratively, the engine was computing "just in time" and so the order
was an accident of the order in which I coded access to other cells and
the vagaries of runtime branching.
That sounded out of control, but I made a leap of faith and let go of
that control, and in hindsight, duh, if I want my programming life made
easier I very much want some well-behaved engine taking over some of the
work, hopefully the dreariest and without making it hard to express
myself.
Multi-way and partial constraints are way cool, but then you go nuts
trying to get the results you wanted. I have done a tremendous amount of
work with Cells and what I find is that I can always describe my models
in terms of one-way cause-effect. The more ambitious stuff pays off I
think when it goes looking for solutions the programmer/user cannot sort
out.
> Maybe it's silly to think nobody thinked it
> out, but you read a number of papers and not found it... There is
> unhealthy tendency last time to patent every 2+2, so I may loose a
> right to use a method just talking about it here. Or it's a
> paranoia...
understood, good luck with your invention. I concluded that if others
got stoked about Cells it was no good keeping the internals to myself
because they would be too easy to replicate.
>
> As about your COWS (Cells that Originally Were Semaphores). I'm still
> not familiar with CLOS, all the more MOP, so I'll not understand it
> by now. Although maybe I'll understand CLOS investigating Cells ;)
Well, I keep mentioning slot-value-using-class, but that is hidden from
the Cell user, so you do not need to be MOP-savvy. CLOS, yes, and indeed
you will have a lot more fun doing CLOS with Cells than without. Watch
this space for news of Cells Release 2 by email (or SourceForge if I can
figure out how to upload files) sometime in the next week.
COWS. I like it. And since we then have "COWS Only Briefly Open
ceLls"...COBOL?
moooo,
kenny
clinisys
From: Arseny Slobodjuck
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c24a3e4.27443451@news.vtc.ru>
On Tue, 18 Dec 2001 17:36:55 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>> >No, because we have the dependency information so everything that flows
>> >from a state change is highly targeted.
>> Sorry, you mean highly targeted lower-down ?
>
>Not sure which way to take that, so I will answer the two
>interpretations I see:
>
>1. The /process/ of recording dependency information happens
>transparently/automatically and at a very low level, during slot-value
>or (setf slot-value), ie when CLOS slots get read or written.
>
>2. The targets per se are cells which define values for attributes of
>model instances, so that is at a very high level, at the level of
>abstraction of the model.
3. Actually I tried to joke. I just didn't understand that statement
about high targeting. Did you wanted to accent on high significance of
data propagation ?
>I gather you have read about systems which do that?
Not yet. It's appeared to me that you doing such rewiring.
>I did see talk of
>updating the most recent direction in which data flowed in multi-way
>constraints, but that is all.
I recently discovered comp.constraints FAQ, a number of links...
From: Kenny Tilton
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C24D305.86952F16@nyc.rr.com>
Arseny Slobodjuck wrote:
>
> On Tue, 18 Dec 2001 17:36:55 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
> >> >No, because we have the dependency information so everything that flows
> >> >from a state change is highly targeted.
> >> Sorry, you mean highly targeted lower-down ?
> >
> >Not sure which way to take that, so I will answer the two
> >interpretations I see:
> >
[...]
> 3. Actually I tried to joke.
You succeeded! It sounded funny when I read it, but you are taking the
trouble to post in my native language so I tried not to laugh. Now I am
highly amused by and no longer so deeply concerned over your meaning. :)
> I just didn't understand that statement
> about high targeting.
"highly" as in "very"...here's a better phrase "precisely targeted". eg,
if a character is typed in a centered text widget we know to recalculate
the width and position of the widget. if the widget is left-justified we
know to recalculate just the width. If the widget is fixed-width,...etc.
The write-up on COSI (that or in the talk I heard) makes the same point:
when the model gets perturbed, we know exactly where to go to bring
things up to date, so we get an efficiency edge to compensate for the
cost of maintaining the dependency info. And the dependency cost is
incurred mostly at instance initialization time, while the propagation
efficiency pays off for the life of the instance.
> Did you wanted to accent on high significance of
> data propagation ?
Yes, that is the big win in terms of program correctness. Also efficent
support for declarative programming, which in turn makes hard problems
tractable by decomposing them into so many easy declarations.
Maybe I have been programming this way so long I cannot explain it, I
take too much for granted. try this: the dataflow /is/ the solution, it
is not just keeping things up to date in support of some procedural
solution. A small amount of procedural glue feeds OS events into the
application model/dataflow. Cell formulas have as much procedural code
as they need to make their calculations. A small amount of procedural
code gets triggered when cells change value, manifesting said change
outside the application model (usually by updating the window).
>
> >I gather you have read about systems which do that?
> Not yet. It's appeared to me that you doing such rewiring.
No, just that the precise targeting is sensitive to actual dependencies,
not possible dependencies. The example I use is familiar by now:
(make-instance 'my-class :my-slot (sm? (if (^a) (^b) (^c))))
The cell my-slot of any given instance at any one point in time will
have dependencies on A and either B or C. This was accidental, btw; I
just noticed it early on. Thought it was a flaw in the mechanism until I
realized it was Deeply Correct: as long as A is true, the value of C
means nothing to my-slot.
Note however that if one ducks the functional approach and codes:
(let ((a (^a))(b (^b))(c (^c)))
(if a b c))
Then dependencies exist on A, B, and C. (dependencies arise when another
cell-based slot is accessed.) Of course this is nothing new; IF is a
special form precisely so only one form branch gets evaluated.
>
> I recently discovered comp.constraints FAQ, a number of links...
Let me know if you find anything interesting, I have a little collection
over here, always enjoy finding more prior art. It is a cool technology
that has never taken root. Cells will change that. :)
kenny
clinisys
From: Arseny Slobodjuck
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c25603e.16720703@news.vtc.ru>
On Sat, 22 Dec 2001 18:34:20 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>> I just didn't understand that statement
>> about high targeting.
>
>"highly" as in "very"...here's a better phrase "precisely targeted".
Ah. Now I got what did you meant. If we taking a general constraints
problem, say P(A,B,C) where P - predicate and A changes, we don't know
whether we should change B or C to preserve consistency. In Cells you
know exactly one variable which should be changed and that variable
bound to constraint. I.e. for each constraint there is only one
variable that should forcedly be changed always. That's problem with
my twoway constraints - I want to change that 'output' cell and expect
that other cell changes. That's just one more description, please,
don't answer how it can be done, I already know it.
What's more interesting - how CP guys name that restricted problem if
they do it at all. BTW, 'spreadsheet' has a 'spread' as a substring
which is IIUC a synonym for 'propagation'.
I'm highly targeting some good spreadsheet sources by now.
>> >I gather you have read about systems which do that?
>> Not yet. It's appeared to me that you doing such rewiring.
>
>No, just that the precise targeting is sensitive to actual dependencies,
>not possible dependencies. The example I use is familiar by now:
>
> (make-instance 'my-class :my-slot (sm? (if (^a) (^b) (^c))))
>
>The cell my-slot of any given instance at any one point in time will
>have dependencies on A and either B or C.
But will calculation of my-slot get triggered only by two cells in any
one point in time or calculation will occur on each of A,B,C change ?
I.e. if your propagation mashine 'knows' about 'If' effect ? In any
case rewiring here is matter of efficiency, nothing hurts if we
replace this with A,B,C dependence. I talked about real, arbitrary
rewiring.
>> I recently discovered comp.constraints FAQ, a number of links...
>Let me know if you find anything interesting, I have a little collection
>over here, always enjoy finding more prior art.
Of course. Maybe it's better doing this in comp.constraints ?
>It is a cool technology
>that has never taken root. Cells will change that. :)
Good luck. Hope this discussion help a little to promote it.
From: Kenny Tilton
Subject: Re: Circular Ref Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C25A980.52B17D01@nyc.rr.com>
Arseny Slobodjuck wrote:
> That's problem with
> my twoway constraints - I want to change that 'output' cell and expect
> that other cell changes. That's just one more description, please,
> don't answer how it can be done, I already know it.
OK, I see. You know, it just occurred to me that in my system, purely
for debugging purposes, I pass the triggering cell as an argument to the
rule of the cell that needs to be recalculated. I could probably make
good use of that in the few places I have tricky dependencies. Hmmm...
>
> how CP guys name that restricted problem if
> they do it at all.
Sannella (93) just says "one-way" constraint.
Steele (80) cites this paper as the source of the phrase he uses "the
data flow model of computation":
J.B. Dennis, "First Version Data Flow Procedure Language ", Technical
Memo MAC TM61, May, 1975,
MIT Laboratory for Computer Science
I believe I have also seen the adjectives "linear" and "deterministic"
applied. And the comparison to spreadsheets is common.
> BTW, 'spreadsheet' has a 'spread' as a substring
> which is IIUC a synonym for 'propagation'.
I never looked at it that way, but maybe you are right. I always had the
image of just spreading the values out across a sheet of paper, but it
could be as you say that it refers to a change to one value spreading
out to change other values.
> >The cell my-slot of any given instance at any one point in time will
> >have dependencies on A and either B or C.
> But will calculation of my-slot get triggered only by two cells in any
> one point in time or calculation will occur on each of A,B,C change ?
Only by two cells. if A is true, changes to C do not trigger my-slot's
recalculation. Each time a rule runs, each cell that gets sampled
records the fact that my-slot sampled it. Cells that were sampled in the
preceding run but not this time forget about my-slot. So if A gets read
and is true, then B gets read, so now A and B know about my-slot. If A
goes to false the rule runs again (A tells my-slot to run) and this time
A and C get sampled. B forgets my-slot, C notices my-slot, A just
carries on as before.
> I talked about real, arbitrary
> rewiring.
wow, arbitrary rewiring? anarchy indeed. maybe in neural nets?
>
> Maybe it's better doing this in comp.constraints ?
Let's cross-post and see what happens.
kenny
clinisys
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C1907B1.78DF02A0@nyc.rr.com>
Arseny Slobodjuck wrote:
>
> On Wed, 12 Dec 2001 17:00:33 GMT, Kenny Tilton <·······@nyc.rr.com>
> wrote:
>
> > (make-instance 'thermometer
> > :C (sm? (- (K self) 273)))
> > :K (sm? (+ (C self) 273))))
> >
> >At that point you could say (setf (K it) 0) and then C would have a
> >value, or vice versa. But until then the system would, I don't
> >know..return nil? ...signal an "unbound" error?
> I think, when Semaphore system can not handle it properly it most like
> an error. Same as for cycles of 3,4,5... cells.
Welllllll, this is kind of tricky.
first of all, normal semaphors do signal an error if they reach an
access to X while trying to compute X, regardless of the length of the
dependency chain (your "3,4,5...cells").
second, i do not want to get into multi-way constraints, that's like
attacking Russia in winter.
what we could do, I think, is a "see-saw" rule over exactly two cells
(we'll try this instead of semaphors--no one has used the word "cell"
for anything have they?) That is unambiguous.
Not that you were saying this, but could we do a "see-saw" chain? ala:
a <- (/ b 2) implying b <- (* a 2)
b <- (/ c 2)
That much would be ok, but add: c <- (* pi a)
I don't know, I just build apps and deal with what comes up, haven't
encountered that stuff anywhere. The simple case of two cells mirroring
each other comes up in scrolling, where the thumb both determines and
reflects the scroll position of the page. I solved that by using the
echo functions to set each other, which is not as self documenting as
having rules defined along with the slots themselves. So maybe a nice
incremental improvement someday.
As for whether it is an error or if we can just return nil in the
original thermometer example when neither K nor C has been supplied,
well, I have never been a big fan of unboundedness. I always initform
stuff to nil. Maybe that is a mistake? I suppose I would rather get the
unbound error on the spot rather than stagger on a few more instructions
until an attempt to do arithmetic with nil drops out.
I guess it comes down to: at the level of abstraction of the model,
could the thermometer ever reasonably not offer a temperature reading?
Is it an electric thermometer that is turned off? Something like that.
kenny
Kenny Tilton <·······@nyc.rr.com> writes:
> (we'll try this instead of semaphors--no one has used the word "cell"
> for anything have they?)
Yes, for function and value cells of symbols.
From: Arseny Slobodjuck
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3c19c5c1.2993193@news.vtc.ru>
On Thu, 13 Dec 2001 19:52:15 GMT, Kenny Tilton <·······@nyc.rr.com>
wrote:
>what we could do, I think, is a "see-saw" rule over exactly two cells
>(we'll try this instead of semaphors--no one has used the word "cell"
>for anything have they?) That is unambiguous.
>
>Not that you were saying this, but could we do a "see-saw" chain? ala:
>
> a <- (/ b 2) implying b <- (* a 2)
> b <- (/ c 2)
>
>That much would be ok, but add: c <- (* pi a)
Hey I not inviting you to go so far. Actually I didn't do it in my
library because of inadequate complication of recalc algorithms,
so I slipping out without it (not so difficult). But if there were
simple way, such equivalent cells were convenient. I come to that
'worksheet' program organisation when I noticed that different
calculations are scattered through the code, not organized and
complete state of all variables that should be calculated is not
guaranteed to be consistent. Then see: if you don't know apriori
the units of temperature that user uses, you then have to have
'normalization' formula _out_ of your 'worksheet' that bring the
data user entered to one definite kind of units. In the case
of Celsius - Kelvin formula is simple, but there is other cases,
involving third cells...
But I'm not the user of the Semaphore library. Let see what users say.
>As for whether it is an error or if we can just return nil in the
>original thermometer example when neither K nor C has been supplied,
>well, I have never been a big fan of unboundedness. I always initform
>stuff to nil.
Ah. I think about it too, but in C++ it seems differently.
>Maybe that is a mistake? I suppose I would rather get the
>unbound error on the spot rather than stagger on a few more instructions
>until an attempt to do arithmetic with nil drops out.
I solved that that way: Maker have 'Closed' and 'Opened' states.
When it 'Open' you can insert and delete cells/rules in it.
When you 'Close' it, Maker recalculates and continues to be
consistent. If user didn't supplied the values, values being Nil,
and if user didn't inserted the rule, it is unbound.
From: Dmitri Ivanov
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <9v83t1$2507$1@news.aha.ru>
Kenny Tilton <·······@nyc.rr.com> wrote in message
······················@nyc.rr.com...
> Marco Antoniotti wrote:
> >
> > Now that I see this posting, I think that the name is a little
> > misappropriate.
>
> I am aware of the conflict. If it becomes a big deal I can rename.
Right
> now the first question is whether anyone finds Semaphors interesting.
If
> not, we're done.
>
> otherwise, i have been calling them semaphors for six years, I would
not
> mind a new name, maybe something shorter. we'll have a "name that
hack"
> contest.
I guess Semaphors is a kind of constraint programming extension of CL.
The term "Constraint Propagation" was introduced almost two decades ago.
Everyone can consult NG comp.constraints for more information.
---
Sincerely,
Dmitri Ivanov
www.aha.ru/~divanov
From: Kenny Tilton
Subject: Re: Announcing release of Semaphors under GNU GPL
Date:
Message-ID: <3C179FCC.15DB903F@nyc.rr.com>
Dmitri Ivanov wrote:
> I guess Semaphors is a kind of constraint programming extension of CL.
> The term "Constraint Propagation" was introduced almost two decades ago.
> Everyone can consult NG comp.constraints for more information.
Absolutely. The only difference is in the engineering. Also constraints
research is much more ambitious in general than Semaphors. For example
they deal with multi-way constraints. Given the rule A = L x W, any of
A, L or W can be perturbed. they also deal with partial information,
accepting rules such as A > B.
In general, it seems to me the interest there is more about building
logic engines which can find solutions to tough problems given
constraints which limit the search space.
Semaphors were developed in the field just to build highly responsive
interactive applications, and a linear dataflow model (like a
spreadsheet) has handled everything I have encountered to date.
COSI and Garnet are closest to what Semaphors do in that both are
concerned foremost with building apps where the problem is not so much a
huge solution space but rather complicated (yet fully known) data
interdependencies. Being able to express these one simple rule at a time
and then have a dataflow engine handle the rest is sweet.
kenny