POV-Ray : Newsgroups : povray.pov4.discussion.general : Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0) Server Time
13 Nov 2024 03:01:29 EST (-0500)
  Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0) (Message 16 to 25 of 25)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: William F Pokorny
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 29 Jun 2024 14:36:26
Message: <6680542a$1@news.povray.org>
On 6/29/24 01:00, jr wrote:
> hi,
> 
> just a couple of thoughts.
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> ...
>> One day, not long ago, it hit me that maybe identifier prefixes would be
>> a way we could implement reasonably broad, useful constant-ness - ...
>>
>> Given I'm going to delay to implement a build configuration option for
>> this feature, do you think some other prefix would be better? ('_r',
>> 'ro_', 'r_', ?)
> 
> "democracy" eh ?! </grin>.  given those options, 'ro_' would be my choice, as
> it's "mnemonic".
> 

Yeah, and ro_ fits with my keyword prefix direction too.

> 
>> Aside 1: I have still bugs and issues with the current global / local
>> dictionary behavior in v3.8+ to sort... Our implementation doesn't match
>> our documentation and we probably need a #top (or #upid (upvar n))
>> directive alongside #directive and #local.
> 
> having read ingo's Nim language examples, I really like the "everything is
> immutable unless" approach.  safe.  perhaps all macro args (as you wrote
> somewhere) ought to be "ro" by default, and an explicit 'upvar N' required for
> every exception ?  (that (upvar N) :-) would be _seriously_ nice to have)
> 

I've been thinking about those examples too & my response to Ingo's 
question. I failed / bailed on my initial attempts to make a macro 
parameters constant always - but success would have meant a SDL change 
much more likely to break current code than an 'ro_' prefix. I hadn't 
thought much at all about a keyword to change defaulted read-only to 
something mutable via a new keyword.

It might be we could check that the mutability of the parameter in the 
macro matches the caller's ID mutability, but there are limits to how 
much checking like that we can do given SDL isn't compiled and linked. 
We'd be paying the price of the overhead on every call to the macro.

 From what I've seen people mostly use the macro 'pass by reference and 
change' and '#declare ID' as mechanisms to return multiple values or to
define what they want global as with the yuqk munction concept compiling 
users functions only once. (We now have the tuple return and assignment 
mechanisms in v3.8.)

Another thing which might be possible nearer term, would be to make 
mixed use of #declare and #local with the same variable name inside 
macros illegal in yuqk (or in just the debug compile).

See the attached file for a few examples of how mixing one identifier 
name with both #local and #declare can result in instability. The macro 
parameter - change by reference - issue aside.

We should mention too, for those stumbling across this thread later, 
that a good solution for all the macro-ish exposures to inadvertent 
identifier change is to use functions when dealing with just math and a 
return a value.

Bill P.


Post a reply to this message


Attachments:
Download 'instabilitywithlocalanddeclareuse.txt' (3 KB)

From: Bald Eagle
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 29 Jun 2024 14:55:00
Message: <web.668057a14bc5dc751f9dae3025979125@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> agree, a in-one-place collection of things needing doing, plus "feature
> requests", is very much needed.

Well, this has been brought up by myself and other before,

I think the easiest thing to do would simply be use a collaboration tool or
project management tool and get _something_ started.

https://opensource.com/business/15/7/five-open-source-alternatives-google-docs


Then we could start with a general outline of what we _have_ complete with
hyperlinks to the wiki or whatever works best to illustrate the concept.

Then maybe separate documents that "mirror" the source code, where we could
strip out all of the extraneous non-code stuff, for enhanced readability (with
links to original).  Then people with coding experience could read and comment
on the code, and perhaps even insert hyperlinks between where one piece of code
utilizes a variable, and the (faraway) place in the code where that variable
gets updated last.

Obviously to-do list and desired features.
Coders could begin scribbling scratch code and other people could be inspired
and take it a step further.

The advantage here is that if the outline structure is maintained well, it'll be
a lot easier to find than sifting through 30 years of haphazard forum posts.

Users could then have a personal "wiki page".

FAQ type material could be organized to provide "one code example for every
keyword", micro-tutorials on coding methods / algorithms / tricks, working
examples of tricky syntax, etc.

Macros could be assembled so that people could look things up in an index and
find what they were looking for.
Desired features could be exemplified with macros, and then converted to source
code by people who have the c++ experience but don't understand the goal /
algorithm needed.

And since it should pretty much be all text, with hyperlinks to graphics,
articles, pdf documents, websites, etc, it should be fairly small to store local
copies - which means every collaborator has a copy / backup.

- BW


Post a reply to this message

From: jr
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 29 Jun 2024 15:40:00
Message: <web.668062ca4bc5dc75c7a7971d6cde94f1@news.povray.org>
hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...

a lot of points/issues "touched on", food for thought.  will, in the coming
days, try and set out the response "gut feeling" tells me, structured, for your
inbox.



@Bald Eagle.
> Users could then have a personal "wiki page".

a wiki s/ware would be perfect.  personally, I think 'fossil' should "be on the
table".


> ... it should be fairly small to store local copies ...

no need to worry, in this day and age.  (the machine which took the place of the


common access will be the "bug bear" imo.


regards, jr.


Post a reply to this message

From: Bald Eagle
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 29 Jun 2024 16:35:00
Message: <web.66806fcd4bc5dc751f9dae3025979125@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> a wiki s/ware would be perfect.  personally, I think 'fossil' should "be on the
> table".

I'm game.  I can download that and we can see about getting something started.

> (the machine which took the place of the common access will be the "bug bear" imo.

We are truly 2 people separated by a common language.

- BW


Post a reply to this message

From: jr
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 29 Jun 2024 17:20:00
Message: <web.668079b44bc5dc75c7a7971d6cde94f1@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > a wiki s/ware would be perfect.  personally, I think 'fossil' should "be on the
> > table".
>
> I'm game.  I can download that and we can see about getting something started.

<https://www.fossil-scm.org/home/doc/trunk/www/index.wiki>


> > (the machine which took the place of the common access will be the "bug bear" imo.
>
> We are truly 2 people separated by a common language.

</grin>.  "struggling against the same s/ware configuration", more like.
apparently, the GBP currency sign (too) makes the web l/f "unhappy"; I wrote,
"showing off", that crow's "replacement" has 1.5T (truly mind-boggling "space",
on two M.2 SSDs), for under 100 of our currency units; cheaper still now.


regards, jr.


Post a reply to this message

From: Bald Eagle
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 29 Jun 2024 17:35:00
Message: <web.66807cdd4bc5dc751f9dae3025979125@news.povray.org>
"jr" <cre### [at] gmailcom> wrote:

> > I'm game.  I can download that and we can see about getting something started.
>
> <https://www.fossil-scm.org/home/doc/trunk/www/index.wiki>

I'm already "up and running" - just need to figure out how you log in to the
system to start doing stuff.

- BW


Post a reply to this message


Attachments:
Download 'setup.png' (51 KB)

Preview of image 'setup.png'
setup.png


 

From: ingo
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 30 Jun 2024 02:05:00
Message: <web.6680f5014bc5dc7517bac71e8ffb8ce3@news.povray.org>
"ingo" <nomail@nomail> wrote:

>
> Just as an example how it works in an other language. In the Nim programming
> language

I should have added one more option as it does what one can do with macro's.
Note there is now no output type specified and thus no return value. 'a' is
modified "in place".

proc dothing(a: var int, b: int) =
  a = a + b


var  a = 1
let  b = 2

dothing(a, b) # or a.dothing(b)

echo a  #printed result is sum of and b

ingo


Post a reply to this message

From: William F Pokorny
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 2 Jul 2024 11:32:25
Message: <66841d89$1@news.povray.org>
On 6/29/24 14:36, William F Pokorny wrote:
>>> Given I'm going to delay to implement a build configuration option for
>>> this feature, do you think some other prefix would be better? ('_r',
>>> 'ro_', 'r_', ?)
>>
>> "democracy" eh ?! </grin>.  given those options, 'ro_' would be my 
>> choice, as
>> it's "mnemonic".
>>
> 
> Yeah, and ro_ fits with my keyword prefix direction too.

Release 15 of the yuqk fork has moved to the ro_ prefix to indicate the 
identifier is read-only. The build configure script option to disable 
the feature was added and is: --disable-read-only-identifiers

Bill P.


Post a reply to this message

From: Bald Eagle
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 8 Jul 2024 08:15:00
Message: <web.668bd7624bc5dc75c103d2725979125@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:

> > <https://www.fossil-scm.org/home/doc/trunk/www/index.wiki>

Curious if anyone has the ability and inclination to run this in server mode, or
alternatively if someone knows of a peer-to-peer (P2P) style collaborative
document editing FOSS software that would serve our purpose.

- BW


Post a reply to this message

From: ingo
Subject: Re: Suggest v4.0 read only identifiers. (yuqk R15 v0.6.9.0)
Date: 9 Jul 2024 12:00:00
Message: <web.668d5e774bc5dc7517bac71e8ffb8ce3@news.povray.org>
There is http://chiselapp.com/ that hosts fossils (kind of like github) and you
can control who has access to the data. I used it in the past, worked fine then
and then not and then again. Seems to look ok now.

ingo


"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
> > > <https://www.fossil-scm.org/home/doc/trunk/www/index.wiki>
>
> Curious if anyone has the ability and inclination to run this in server mode


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.