"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

"Mr" <m******r******at_hotmail_dot_fr> wrote:
> "ingo" <nomail@nomail> wrote:
> > "Mr" <m******r******at_hotmail_dot_fr> wrote:

> 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?

Using Nim and a library nimscripter I made a simple image renderer, the way you
suggested here. Most of the rendering procedures are compiled and are made
available to the VM so they run at "max" speed. Math functions already run at
max speed in the VM. This all is then available in the scripting language.

In my little app you can create patterns from math functions and render those.
You can add POV style like turbulence and gray scale mapping, instead of our
color_map.

You compile the render engine and then render the .nims scripts with it. Just
like POV-Ray renders SDL, but without the need for writing a parser etc.

It does work, but it is not a smooth path yet. Not every thing is possible
(yet?) with this way of creating an app.

https://gist.github.com/ingoogni/8e1f74f8ea7250da778a202648e96e9b

the script for the image:
---%<------%<------%<---
import math

proc sincos(x, y: float): float =
  return (1 + (sin(x) * cos(y))) * 0.5


proc main() =

  var img = initPGM("sincos.pgm")
  img.gamma = srgb

  let
    gm = Pattern(
      funk: sincos,
      greymap: @[(0.0,0.0),(0.5,0.2),(0.8,0.7),(1.0,0.0)],
      turbulence: (
        strength: (x: 1.6, y: 2.2),
        lambda: 2.5,
        omega: 0.7,
        octaves: 6
      )
    )
    width = 640
    height = 480
    viewportWidth = 30.0
    viewportHeight = 0.0
    #viewportHeight = viewportWidth * (height / width)  # Maintain aspect ratio
    grid = gm.render(width, height, viewportWidth, viewportHeight)

  img.writePGM(grid)


when isMainModule:
  main()
---%<------%<------%<---

Post a reply to this message

Attachments:
Download 'sincos.png' (280 KB)

Preview of image 'sincos.png'

On 4/2/25 05:13, ingo wrote:
>        turbulence: (
>          strength: (x: 1.6, y: 2.2),
>          lambda: 2.5,
>          omega: 0.7,
>          octaves: 6
>        )

Interesting. I'm impressed you implemented at 2D perlin turbulence() for 
this demo code!

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 4/2/25 05:13, ingo wrote:
> >        turbulence: (
> >          strength: (x: 1.6, y: 2.2),
> >          lambda: 2.5,
> >          omega: 0.7,
> >          octaves: 6
> >        )
>
> Interesting. I'm impressed you implemented at 2D perlin turbulence() for
> this demo code!
>
> Bill P.

Sorry to disappoint you, a bit. I scaled down my "old" 3d version to 2d. The 3d
version is used in a slowly growing audio synthesis project where tiles with
patterns are used as the "sound source". I'm not realy happy with the
turbulence yet, it doesn't work as smooth as POV-Ray's implementation.


ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
> > "ingo" <nomail@nomail> wrote:
> > > "Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> > 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?
>
> Using Nim and a library nimscripter I made a simple image renderer, the way you
> suggested here. Most of the rendering procedures are compiled and are made
> available to the VM so they run at "max" speed. Math functions already run at
> max speed in the VM. This all is then available in the scripting language.
>
> In my little app you can create patterns from math functions and render those.
> You can add POV style like turbulence and gray scale mapping, instead of our
> color_map.
>
> You compile the render engine and then render the .nims scripts with it. Just
> like POV-Ray renders SDL, but without the need for writing a parser etc.
>
> It does work, but it is not a smooth path yet. Not every thing is possible
> (yet?) with this way of creating an app.
>
> https://gist.github.com/ingoogni/8e1f74f8ea7250da778a202648e96e9b
>
> the script for the image:
> ---%<------%<------%<---
> import math
>
> proc sincos(x, y: float): float =
>   return (1 + (sin(x) * cos(y))) * 0.5
>
>
> proc main() =
>
>   var img = initPGM("sincos.pgm")
>   img.gamma = srgb
>
>   let
>     gm = Pattern(
>       funk: sincos,
>       greymap: @[(0.0,0.0),(0.5,0.2),(0.8,0.7),(1.0,0.0)],
>       turbulence: (
>         strength: (x: 1.6, y: 2.2),
>         lambda: 2.5,
>         omega: 0.7,
>         octaves: 6
>       )
>     )
>     width = 640
>     height = 480
>     viewportWidth = 30.0
>     viewportHeight = 0.0
>     #viewportHeight = viewportWidth * (height / width)  # Maintain aspect ratio
>     grid = gm.render(width, height, viewportWidth, viewportHeight)
>
>   img.writePGM(grid)
>
>
> when isMainModule:
>   main()
> ---%<------%<------%<---

The fact that it does work is already a huge achievement ! Ignoring the syntax I
wonder, did you create the previous routines in POV originally? and if so, do
you think there could be a way to compare fairly render times? Should rather
only the parse to render ratio be considered ? with your approach, would
separate builds have to be made afresh for every scene? About the nim script
language, though it is said to have some removed functionality, is it still
"Turing complete" ? ...Meaning, as much as POV/INC sdl?

Post a reply to this message

"Mr" <m******r******at_hotmail_dot_fr> wrote:

> The fact that it does work is already a huge achievement ! Ignoring the syntax I
> wonder, did you create the previous routines in POV originally? and if so, do
> you think there could be a way to compare fairly render times? Should rather
> only the parse to render ratio be considered ? with your approach, would
> separate builds have to be made afresh for every scene? About the nim script
> language, though it is said to have some removed functionality, is it still
> "Turing complete" ? ...Meaning, as much as POV/INC sdl?

The syntax can be adapted using macros. I've not tried it yet, only just started
with macros. But when you look at my code it is quite crude. It will be polished
a bit more.

No, I did it straight in Nim, but I have quite some graphics stuff in Nim to
build from. As render times are concerned, this is currently one thread and I'm
working on a multithreaded version. It's about half way.

Once done I'll compare a similar pattern, but POV-Ray will win as I so far have
no clue how to implement SIMD intrinsics. On my machine that would mean 24
thread each doing one calculation vs. 24 threads each doing ~8 calculations at
once.

One only has to build the renderer.nim once and then you can rewrite and render
many scripts on it without rebuilding.

Yes it is Turing complete, as far as I know. It has a bit of a problem with
pointers and c-libraries. It is a more capable language than POV-Ray SDL. Most
of Nim's "pure" libraries should work in script:
https://github.com/nim-lang/Nim/tree/devel/lib/pure

But, beware, I'm certainly no Nim specialist. Also, there are / must be other
languages that can do this. At least good old LISP can.

ingo

Post a reply to this message

"ingo" <nomail@nomail> wrote:
> "Mr" <m******r******at_hotmail_dot_fr> wrote:
>
> I'm working on a multithreaded version. It's about half way.
>

a 4000x4000 image took 1 minute 7 seconds. Multi threaded works, the same image
takes 2 sec 968 ms.

Next, clean up and polish.

ingo

Post a reply to this message