"Bald Eagle" <cre### [at] netscapenet> wrote:

> [...] I have way too many spreadsheets and little pieces
> of paper with scribbles . . .

https://www.zim-wiki.org/index.html  a desktop wiki fur such things. I has
options /plugins for version control (even Fossil i.r.r.c)

There are several similar tools like Zim


ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> One (two) more of POV-Ray's internals that I would like to see made available in
> SDL, the objects current transformation matrix and it's inverse. But build in
> turn, resize would be nice to haves,

Ah, and this is why if we could just have a Point *object*, then we could union
that with an object and transform everything at once.  Inverse is already
implemented.

Post a reply to this message

"ingo" <nomail@nomail> wrote:

> https://www.zim-wiki.org/index.html  a desktop wiki fur such things. I has
> options /plugins for version control (even Fossil i.r.r.c)

Oh, heck yeah!!!
This is exactly the kind of thing I wanted to do - hyperlinked to documents and
files!  Potentially with multiple links to the same item.
You are a mind-reader, in a timely fashion.

> There are several similar tools like Zim

Please enlighten me!

- BW

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > I so agree, everything ought to have "sensible defaults" for all but location
> > (and perhaps size).
>
> (?)
> Well, considering the troubles people go through, 30 years in, I would say that
> a default location at the origin not only makes sense, but is desirable.
> [I always pause when I realize that torus {} doesn't take a vector location like
> sphere{}, and I have to translate it afterwards, and I still fail to provide a
> radius for cylinder when writing one from scratch.]
>
> Rotate and scale, when not at the origin, really mess with people's heads.

yes.  the "all but location" was just (habitual ?) personal perspective.


> (Which reminds me, I ought to write macros like Turn () and Resize () to
> translate objects to the origin, perform the inbuilt operation, and translate
> back to original location.  Macro names are just off the top of my head)
>
> Default sizes ought to be in reference to the unit cell, unless there's some
> specific reason to do otherwise.  Text {} defaults to 1. Image_map,
> height_field, and maybe others default to 1x1, df3 and maybe others default to
> the unit cube....
>
> I think that one of the basic themes for 4.0 ought to be consistency.
> In size, in uv-mapping vectors, in syntax, and whatever else we can manage.


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> Please enlighten me!
>

https://www.giuspen.net/cherrytree/   https://github.com/giuspen/cherrytree

https://tiddlywiki.com/ Single page web app

https://wikidpad.sourceforge.net/


An alternative way is simple text files in one directory and then a separate
directory structure with a tree of metadata tags. In those you keep the symbolic
links to documents that match the tag.

Going fancy, start your document with the tags. Write software that monitors the
tags dirs and when you copy a simlink to an other tag dir update the tags in the
original document. Same with deletions.I used such a system in the 90' and 00's
to manage my music collection.

....and that is just the beginning, if you keep the news group messages in mbox
you can simlink those too, your file syatem is a database after all .... ;)

ingo

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Ah, and this is why if we could just have a Point *object*, then we could union
> that with an object and transform everything at once.  Inverse is already
> implemented.

Just as an idea,

#declare Thing = object{
  local_centre = <1,1,1>
  sphere{
   <2,2,2>, 1
   rotate <20,70, 3> #rotates around the origin
  }
  sphere{
    <0,0,0>, 1
    rotate_local <20,70,3> #rotates around the local_centre
  }
  rotate <33,33,3>
  rotate_local <-45,90,22>
}

global and local axis.

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> >I'm not referring to type here which is another issue, just the
> > "declare" or "var" keyword... I don't see why it's important.
>
> A "big" difference is that in POV-Ray you have to tell a variable whether it is
> local or not. In many languages this is different. Every variable declared
> inside a block is local and it can't escape that block.
>
> So in Nim:
>
> var chicken = 1
>
> for i in 0 ..< 10:
>   let n = i + i
>   chicken += n
>
> echo chicken
> echo n # fails compilation, Error: undeclared identifier: 'n'
>
> it fails not because it is let (immutable), but because it's local.
>
> There is quite a body of research on what a good beginners language should look
> like. Python scores very high on these. One aspect in several of these
> researches made me chuckle, as I had the same problem decades ago. It is hard to
> grasp 'while' and 'for' loops (Warp wrote a tutorial on it). Using the keyword
> 'every 'makes it more understandable for novices. Another hard one is OOP except
> for the composition of records/objects.
>
> The main problem in POV-Ray is that there are two aspects to it, the 'scripting'
> part and the 'objects' part and that is actually well done. Compare it with the
> javascript 3D stuff, or Vapory https://github.com/Zulko/vapory . If one would
> repurpose an existing language for POV-Ray SDL then look for a language with
> extensive macro abilities to build a DSL so one can have a distinct render
> object sections an distinct script/code sections, similar to POV-Ray now.
>
> ingo

I don't know enough to have an opinion about using a database oriented POV
workflow, which does sound very powerful, but I did have a look at the  overview
descriptions of the nim language, and though there are some aspects that I don't
naturally enjoy in its syntax, they probably are specifically the ones that
every one around here seem to be asking for, also the fact that it can be
interpreted and compiled... Well, wouldn't this make it suited to be a scene
description language that could get accelerated as a compiled version just
before parsing?

Post a reply to this message

"Mr" <m******r******at_hotmail_dot_fr> wrote:
[...] also the fact that it can be
> interpreted and compiled... Well, wouldn't this make it suited to be a scene
> description language that could get accelerated as a compiled version just
> before parsing?

Nims (the scripting language) does not support everything Nim does. I.i.r.c it
does not work with dll's, etc. Interoperation with Nim the way you suggest is
not easy, but it can be done. Nims is about as fast as Python, maybe a little
bit slower.

I do not see compilation as necessity, but it is certainly useful for include
files that could be compiled to be plug-ins for POV-Ray. It may also be of use
for animations.

ingo

Post a reply to this message

hi,

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> [...] also the fact that it can be
> > interpreted and compiled... Well, wouldn't this make it suited to be a scene
> > description language that could get accelerated as a compiled version just
> > before parsing?
>
> Nims (the scripting language) does not support everything Nim does. I.i.r.c it
> does not work with dll's, etc. Interoperation with Nim the way you suggest is
> not easy, but it can be done. Nims is about as fast as Python, maybe a little
> bit slower.
>
> I do not see compilation as necessity, but it is certainly useful for include
> files that could be compiled to be plug-ins for POV-Ray. It may also be of use
> for animations.

wanted to take a look at nim but it's .. not for me.  after building the
package, not yet installed, nothing, I already find my ~/.cache directory having
a 'nim' subdirectory with tons of .. who-knows-what ?  and the main site, I
loved the look of the documentation page, but _every_ link you click, you wind
up on github ??  tja.  shame really, the idea of using macros to output SDL
appealed.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

> wanted to take a look at nim but it's .. not for me.

https://nim-lang.org/documentation.html

installing on windows is straight forward except when the Anti Virus Maffia
starts to nag.

On freeBSD it's in ports/packages and it installed flawless for me.

https://nim-lang.org/install_unix.html


ingo

Post a reply to this message