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

hi,

"ingo" <nomail@nomail> wrote:
> "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 ...

n/a.


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

I built a package for Slackware with the 2.2.0 source archive (high density !!
:-), expands from 7.5M to a little over 1930M), and  was "put off" by the
"litter"; building a package has never before added stuff outside the (/tmp)
designated locations, the nim build did (though that may be the maintainer's
doing, rather than an inherent thing).  also, "other, github-related gripes" ;-)

had not yet looked at FreeBSD, but will in the coming days, thx for the
reminder.


regards, jr.

Post a reply to this message

On 3/18/25 04:01, Mr wrote:
> I'm sure more expert people in various languages will be able to teach me
> something important from what is probably a naive question :  What if in POV 4
> we had the possibility to use spaces or tabs as a synonym to what curly braces
> currently do, but we could still use those braces themselves ?
> 
> That way new comers would feel at first glance that the language is as easy to
> learn as Python, and would rapidly understand as they do in Python, that what
> matters is that they do know what scope they're in.
> 
> and eventually, depending on *whichever* option gets to become the most popular
> among core developers and power users, it can become a maintenance cost
> reduction to drop one or the other?
> 
> Inspiration for this idea? of course, python... I love how it has grown able to
> do type annotations, switch cases, etc. and while across versions leverage many
> advanced concepts teaching them to me as it went, and now they are there, I love
> how a new comer could still pick it up exactly the way I did, with a human
> readable almost fiction-book like syntax, and still produce scripts that do
> work, syntactic-sugar-free.  BUT I know there must be a reason why those curly
> braces are still there isn't there? so I trust people to tell me... maybe so
> that POV acts as a launching pad to learn C-like languages in which it is itself
> developed?
> 

Significant whitespace is a terrible, terrible idea, and Guido should be 
smacked for it. Because we *knew* it was a terrible idea before Python 
was even a gleam in his eye. Makefiles taught us that years earlier.

You ever had an entire build blow up because someone else on the dev 
team edited a file using different editor settings, and it introduced an 
*invisible* syntax error that took half a day to track down while 
everyone else's work ground to a halt? I have.

-- 
John Campbell
jca### [at] lynnci-ncom

Post a reply to this message

John Campbell <jca### [at] lynnci-ncom> wrote:
> On 3/18/25 04:01, Mr wrote:
> > I'm sure more expert people in various languages will be able to teach me
> > something important from what is probably a naive question :  What if in POV 4
> > we had the possibility to use spaces or tabs as a synonym to what curly braces
> > currently do, but we could still use those braces themselves ?
> >
> > That way new comers would feel at first glance that the language is as easy to
> > learn as Python, and would rapidly understand as they do in Python, that what
> > matters is that they do know what scope they're in.
> >
> > and eventually, depending on *whichever* option gets to become the most popular
> > among core developers and power users, it can become a maintenance cost
> > reduction to drop one or the other?
> >
> > Inspiration for this idea? of course, python... I love how it has grown able to
> > do type annotations, switch cases, etc. and while across versions leverage many
> > advanced concepts teaching them to me as it went, and now they are there, I love
> > how a new comer could still pick it up exactly the way I did, with a human
> > readable almost fiction-book like syntax, and still produce scripts that do
> > work, syntactic-sugar-free.  BUT I know there must be a reason why those curly
> > braces are still there isn't there? so I trust people to tell me... maybe so
> > that POV acts as a launching pad to learn C-like languages in which it is itself
> > developed?
> >
>
> Significant whitespace is a terrible, terrible idea, and Guido should be
> smacked for it. Because we *knew* it was a terrible idea before Python
> was even a gleam in his eye. Makefiles taught us that years earlier.
>
> You ever had an entire build blow up because someone else on the dev
> team edited a file using different editor settings, and it introduced an
> *invisible* syntax error that took half a day to track down while
> everyone else's work ground to a halt? I have.
>
> --
> John Campbell
> jca### [at] lynnci-ncom

Sure it happens, until the ide is properly configured.

Post a reply to this message