Re: Storing functions in the database

[Alexander Burger]

Hi Joh-Tob,

> Reading the full 'doc helps. The solution was 'Any.
> 
> : (rel body (+Any +Need))
> -> +Function

Yes, almost. The +Need is wrong though, it is a prefix class and is at least not
clean here.

Also, as I always keep saying, be careful with +Need. It makes usually only
sense for values which are initialized by the system at object-creation time.
But if you absolutely want it, use (+Need +Any).

♪♫ Alex
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: TC -> Loop Transformation?

[Lindsay John Lawrence]

Hi Christopher,

Congratulations on the new baby. You'll have lots of late nights to code
now...or maybe not.

This may give some added insight into what you are trying to accomplish...
https://rosettacode.org/wiki/Jump_anywhere#PicoLisp

The code example there was worth some time to study for me, especially in
consideration of scoping. It may even have been my lisp enlightenment
moment (= code data).

/Lindsay



>

Unclear licensing

[Christopher Howard]

Hello list. I'm having a lot of fun with picolisp, doing practice
problems and working with different codes. One concern I have though is
that most of the files in the Picolisp 16.12 release do not have proper
license labeling. For legal safety and to avoid confusion, we need to
have at least *every source code* file in the release labeled at the top
of the file with the applicable license. This is especially important
since you have some files in the release that are under different
licenses (e.g., some elisp under GPL-2); also you have javascript files
that are served by some of your libraries and, when served, end up
looking like they have no license at all (if someone inspects the
javascript code) when (presumably) the javascript also is freely licensed.

Is that already something on your TODO list? I am willing to help with
this... I just need to know if you want me to create a patch against the
stable version 16.12, or some other release. Of course, the danger with
me being involved is you might at some point claim I've misrepresented
your licensing intentions.

-- 
https://qlfiles.net
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: TC -> Loop Transformation?

[Christopher Howard]

Hi, sorry about the delayed response — just had a new baby and have been
in the hospital for a few days.

What I am trying to accomplish is be able to represent algorithms in a
recursive format (which is often what comes naturally to me and seems
cleaner and easier to understand) without the stack penalty. This is why
TCO is baked into Scheme and CL, as the lisp people usually have this
mindset. If you don't, that is fine and probably not worth an extended
discussion. In my Haskell days, I represented most algs in some
recursive format, though I found out there was usually some higher level
abstraction available encapsulating the recursion.

The "macro" I wrote seems to accomplish what I want, though I'm thinking
maybe there are a few things in the macro code itself that could be
improved. E.g., it seems a little weird throwing an exception, but I
wasn't sure how else to do a non-local jump. And there is potential also
for variable name collisions between the macro variables and the
function that is passed in.

On 03/04/2017 11:46 PM, Alexander Burger wrote:
> Hi Christopher,
> 
> thanks for sharing these ideas!
> 
> However I'm a bit clueless about what you want to achieve.
> 
>> Hi, I while ago I asked how I might somehow represent a loop as a a tail
>> call recursion, so as to give me the pattern I like without the call
>> penalties.
> 
> Isn't it a lot easier to write a 'while', 'for' or 'do' loop then?
> 
> ♪♫ Alex
> 

-- 
https://qlfiles.net
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Storing functions in the database

[Joh-Tob Schäg]

Hello,

i try to store a function is a database. Can somebody spot what i am doing
wrong?

(pool "types.db") #empty
: (class +Function +Entity)
-> +Function
: (rel name (+Idx +String))
-> +Function
: (rel body (+Bag +Bag +Need))
-> +Function
? (select +Function)
{5} (+Function)
   name "1-to-N-sum"

{2} (+Function)
   name "fakultät"

{6} (+Function)
   name "sum2"

-> NIL
? (get {6} 'body)
-> NIL
? (get {2} 'body)
-> NIL
? (get {2} body)
-> NIL
? (request '(+Function) 'body '((N X) (+ N X )))  #New Function with this
body is created because nothing found
-> {13}
? (show {13})
-> (+Function)
? (request '(+Function) 'body '((N X) (+ N X )))  #New Function with this
body is created again!
-> {14}

Re: future?

[Jakob Eriksson]

> 10 mars 2017 kl. 01:17 skrev  :
> 
> Thanks for your comments and insights, Jakob.
> I just want to shortly assure you that I really liked your emails and your 
> participation.


Thanks.


> Sidenote:
> Before GitHub, sourceforge.net was the singular main hoster for FOSS 
> sourcecode.
> They lost their status when they bundled the downloads with adware (and 
> malware).

Something like that can happen.

But I stand by my point - github and it's social network is unique.




> 
> BitKeeper vs. Linux (the reason we have git now).

So thanks to Bitkeeper we could push the state of the art away from CVS. Great.



> 
> GitHub:
> On 2017-03-01 GitHub introduced
...

> Basically, when uploading FOSS-licensed content to GitHub, the uploader 
> automatically grants GitHub a special license, so actually a case of 
> dual-licensing.
> The problem now is, that when the content is copyrighted by other authors 
> beside the uploader, 
> then the uploader cannot (in usual cases) actually grant this license legally 
> to GitHub, as most FOSS-licenses forbid sublicensing and/or removal of the 
> original attributions.
> 


Just ... not accurate.

https://news.ycombinator.com/item?id=13767975




> I don't believe GitHub will take big damage because of this, especially as 
> there is no serious contender on the rise.

Exactly there's none.

> But it's surely a sign that GitHub is not a singularity from the usual 
> development of such things.
> It's not an idealistic group of nerds anymore, but a big company (e.g. lookup 
> the "github meritocracy" drama).

I never said nor implied such a thing.
I just observe that github is the largest community of software developers in 
the history of the Universe.


> For the other points mentioned by you and others about picolisp:
> Just do it. PicoLisp is MIT-licensed. Action speaks louder than words.

Put up or shut up? Of course you are right. About me. Because I know where to 
find everything picolisp related. But I argue (maybe incorrectly) that there 
can be other people in a kind of Hitchikers guide to the Galaxy situation - 
Picolisp is behind the leopard etc...


But all this is beside the point for PicoLisp, we know now that it won't come 
to github. I just wanted to defend my own viewpoint, I didn't like how I was 
understood.


> This!
> I'm on it.

Speaking of, anybody tried to compile emu pico in emscripten?

-- Jakob 

Re: future?

[Rowan Thorpe]

[reply to beneroth regarding git-hosting so a bit off-topic for
picolisp, just to quickly say...]

On 10 March 2017 at 02:17,   wrote:
> ..[snip]..
> GitHub:
> On 2017-03-01 GitHub introduced new Terms of Service (which you
> automatically accept by continueing to use their service)
> ..[snip]..
> Some projects already moved away from GitHub because of this.
>
> https://www.mirbsd.org/permalinks/wlog-10_e20170301-tg.htm
> http://joeyh.name/blog/entry/removing_everything_from_github/

..many thanks for pointing this out (the new TOS seems to have gone
live 9 days ago). This sort of thing is why there was such a
long-winded debate on debian-devel mailing-list about migrating to a
git platform - but not to github, bitbucket, etc - not even to
gitlab.com (uses non-free enterprise-gitlab). I'd always felt mixed
about hosting F/LOSS on github (initially done as a shortcut around
the time/cost of setting up self-hosting), so I stealth-migrated my
repos to a few other platforms last year and then decided my real move
would be to self-hosted gogs, and in light of this news I'll push that
schedule rather than grokking github-legalese, so thanks. From what
Thorsten says in one of those links, it seems there's only an issue
for a github-hosted repo when commits are made after 1 March, which
gives a little wiggle-room for now, and luckily git makes migration
super-easy.

-- 
Rowan Thorpe

"A riot is the language of the unheard." - Dr. Martin Luther King
"There is a great difference between worry and concern. A
worried person sees a problem, and a concerned person solves a
problem." - Harold Stephens
"Ignorance requires no apologies when it presents questions
rather than assertions." - Michael Sierchio (OpenSSL mailing list)
"What we need more than an end to wars is an end to the
beginning of all wars." - Franklin Roosevelt
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: future?

[andreas]

clarification about the GitHub legalese:

My point is not "do not use github" but "github is not a singularity, no 
exception to the fact that they might close or suddenly turn into a bad actor".

I personally don't believe that this is the point yet nor that their ToS change 
was made with bad intentions.
My current view agrees with this HN comment: 
https://news.ycombinator.com/item?id=13770443

Basically, GitHub moves the legal responsibility from itself to the uploader.
There is no clear incompatibility with FOSS-licenses at the moment.
But such incompatibilities are not ruled out completely or for future GitHub 
service changes.
A minority (afaik) weights the risks so high that they chose not to use GitHub 
anymore.

Me personally, I find it very bad how they introduced this ToS-change, and 
secondly why should the move the legal risks to mostly private persons and 
non-profit FOSS-projects?
Why don't they keep the legal risk on GitHub, when they have the money and 
lawyers to check, and secondly when that legal risk is probably only arising 
when they would introduce bigger changes in how GitHub services work?
That would be a service for the FOSS-people, not just great technical 
infrastructure but also legal protection from risks that solely come from how 
GitHub behaves.

/beneroth