Release R15 of the yuqk fork has an implementation supporting constant 
identifiers / macro parameters. They are indicated by using a leading 
'_' character in the name.

Aside: I have hopes this mechanism a step toward enabling the safe 
passing of function pointers into yuqk's inbuilt functions.

Attached a first pass at a little documentation for the feature.

Bill P.

Post a reply to this message

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

William F Pokorny <ano### [at] anonymousorg> wrote:
> Release R15 of the yuqk fork has an implementation supporting constant
> identifiers / macro parameters. They are indicated by using a leading
> '_' character in the name.
>
> Aside: I have hopes this mechanism a step toward enabling the safe
> passing of function pointers into yuqk's inbuilt functions.
>
> Attached a first pass at a little documentation for the feature.
>
> Bill P.

Very nice - I hope that works out the way you/we/everyone would like.

"Parse Error:
Attempt to #undef a constant identifier.
The identifier is:
    '_V99'
Due the leading '_' the existing identifier can only be read.
Fatal error in parser: Cannot parse input."

Is that a scene-wide global thing?
Due to some need to actually undefine or redefine a variable, maybe the leading
underscore could be a safeguard, rather than a complete lockout.

Maybe have some mechanism by which you can do the equivalent of su in a shell to
override the protections set in place to prevent casual/inadvertent overwriting.

Only saying this because it might make some things pretty awkward to code from
scratch / covert from legacy scenes into yuqk.

I dunno - maybe doing scene development you might want to have the safeguard in
place for the main scene, but during experimentation you want to turn off the
protection, but not scene-wide, only in the little test block of code that
you're fiddling with.

Just a thought.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> Release R15 of the yuqk fork has an implementation supporting constant
> identifiers / macro parameters. They are indicated by using a leading
> '_' character in the name.
>
> Aside: I have hopes this mechanism a step toward enabling the safe
> passing of function pointers into yuqk's inbuilt functions.
>
> Attached a first pass at a little documentation for the feature.

There are quite a lot of include files out there that use a starting underscore
to prevent name space collisions. Many of these variables are also variable and
not 'static/constant'. Would that break scene's and includes?


(Would, for example a '#let' keyword for immutables be an option, or is that an
awful lot more work.)

ingo

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> Release R15 of the yuqk fork has an implementation supporting constant
> identifiers / macro parameters. They are indicated by using a leading
> '_' character in the name.

agree with ingo, a keyword would be "cleaner".  we already can write:

  #macro foo(optional a)  ...  #end

suggest a 'const' or such ?  ie

  #macro foo(a, const b, optional c)  ...  #end


regards, jr.

Post a reply to this message

On 2024-06-27 11:44 (-4), William F Pokorny wrote:
> Release R15 of the yuqk fork has an implementation supporting constant
> identifiers / macro parameters. They are indicated by using a leading
> '_' character in the name.

I also agree with Ingo: a keyword or directive would be better, such as:

  #const MagicNumber = 12345;

I'm thinking a keyword modifier would be more flexible than a directive,
for example:

  #declare const GlobalVal = 12345;
  #local const LocalVal = 54321;

Post a reply to this message

Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2024-06-27 11:44 (-4), William F Pokorny wrote:
> > Release R15 of the yuqk fork has an implementation supporting constant
> > identifiers / macro parameters. They are indicated by using a leading
> > '_' character in the name.
>
> I also agree with Ingo: a keyword or directive would be better, such as:
>
>   #const MagicNumber = 12345;
>
> I'm thinking a keyword modifier would be more flexible than a directive,
> for example:
>
>   #declare const GlobalVal = 12345;
>   #local const LocalVal = 54321;

Hmmm.   Yes, but maybe no?
Why not just have another separate type of declaration?

#declare
#local
#constant

We've also discussed
#persistent

as well as PRAGMA

So maybe #constant can ONLY be changed by specifically using another #constant
directive.

I dunno - I'm not really a computer language person, but the pro's and cons of
each approach ought to be hashed out with an eye towards Pov-Ray 4.0

- BW

Post a reply to this message

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


#macro Add(_immuInt, otherInt)
......
#end

#declare Res = Add(99,1)

#declare _immu = 99;

#declare Res = Add(_immu, 1)

In the second use of the macro, would it be required that the 'referenced' value
is also declared immutable?

ingo

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Cousin Ricky <ric### [at] yahoocom> wrote:
> > On 2024-06-27 11:44 (-4), William F Pokorny wrote:
> > > Release R15 of the yuqk fork has an implementation supporting constant
> > > identifiers / macro parameters. They are indicated by using a leading
> > > '_' character in the name.
> >
> > I also agree with Ingo: a keyword or directive would be better, such as:
> >
> >   #const MagicNumber = 12345;
> >
> > I'm thinking a keyword modifier would be more flexible than a directive,
> > for example:
> >
> >   #declare const GlobalVal = 12345;
> >   #local const LocalVal = 54321;

"modifier", yes.  +1.


> Hmmm.   Yes, but maybe no?
> Why not just have another separate type of declaration?

the keyword modifier, more often than not I think, would be in close proximity
to the variable where/when it's used.  an advantage.


> ...
> So maybe #constant can ONLY be changed by specifically using another #constant
> directive.

if a variable's value can/will change "at runtime", #constant would simply be
misleading.


> I dunno - I'm not really a computer language person, but the pro's and cons of
> each approach ought to be hashed out with an eye towards Pov-Ray 4.0

maybe "4.x" could have a revamped "SDL 2.0", with more "introspection" tools, so
we can write better, "type safe" code.


regards, jr.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> I dunno - I'm not really a computer language person, but the pro's and cons of
> each approach ought to be hashed out with an eye towards Pov-Ray 4.0
>

Just as an example how it works in an other language. In the Nim programming
language the following will not work as all proc parameters are immutable int
types. With Nim procs immutable arguments is the default, unless one uses "var":

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

let
  a = 1
  b = 2

let res = dothing(a, b)


This one will work as c is declared and assigned a value, c is immutable (let)

proc dothing(a: int, b: int): int =
  let c = a + b
  return c

let
  a = 1
  b = 2

let res = dothing(a, b)


This will work as a is now of type var int, a mutable variable:

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

var  a = 1
let  b = 2

a = dothing(a, b)

In the last example 'a' is 'var' in the proc and 'a' has to be "declared" as
'var', else the Nim compiler nags.

Changing a variable "declared" using 'let' into a 'var', or the other way
around, is not possible.

N.B. the last two examples can coexist next to each other in one file/program.
Depending on whether 'a' is a 'var' or not, the compiler chooses the proper
proc.

ingo

Post a reply to this message

On 6/27/24 18:47, Cousin Ricky wrote:
> On 2024-06-27 11:44 (-4), William F Pokorny wrote:
>> Release R15 of the yuqk fork has an implementation supporting constant
>> identifiers / macro parameters. They are indicated by using a leading
>> '_' character in the name.
> 
> I also agree with Ingo: a keyword or directive would be better, such as:
> 
>    #const MagicNumber = 12345;
> 
> I'm thinking a keyword modifier would be more flexible than a directive,
> for example:
> 
>    #declare const GlobalVal = 12345;
>    #local const LocalVal = 54321;
> 

Thanks, everyone, for the feedback & thinking toward v4.0.

The yuqk fork is intended to be a playpen for features like this. 
Nothing about any given change or feature is set in stone. It might be 
the current implementation for read only variables gets dumped in part 
or in total after using it for while. I think it a decent approach, but 
I've not used it nearly enough myself to know. It is, likely, the only 
sort of global-ish thing doable with respect to identifier constant-ness 
given the state of our current Scene Description Language (SDL).

With our SDL and parser, we don't have a cleanly scoped and typed 
'variable' declaration system which allows more naturally for the 
propagation and maintenance of constant information. (Any v4.0 SDL 
re-work should probably treat scene identifiers complete apart from the 
language variables)

My initial runs at some constant identifier support started with the 
idea of all macro parameters being considered constant. However, I ran 
across cases where users had macros which used the pass by reference and 
change behavior.

I then started to look at a new 'const' keyword only with macro 
parameters while thinking about how I might extend its usage before 
concluding. There are a great many complications due how our language 
and parser work which drive the need for language refinement or ugly, 
complicated code infrastructure. I dropped the whole idea for years.

With yuqk, I've been forced to create prefixed language SDL keywords to 
fix bugs and enable features. Over time, I started to see it's more or 
less the same kind of weak scoping of functionality in our SDL. Where I 
adopted prefixed keywords the source code too became more understandable 
and manageable. I now plan, over time, to broadly adopt SDL keyword 
prefixes. With this next R15 yuqk release I'll have three in keyword 
prefixes in play with ii_ (input image), ip_ (internal 
pattern/perturbation) and it_ (internal turbulence).

One day, not long ago, it hit me that maybe identifier prefixes would be 
a way we could implement reasonably broad, useful constant-ness - though 
not completely robust, constant-ness. When I started to really look at 
implementing the idea, it turned out it was an amount of code work I 
could manage.

While working in yuqk, the features implemented are often not exactly 
what I'd wish for in v4.0! They are what I can manage and/or am forced 
to do in the context of the yuqk/POV-Ray implementation as it is.


---
(BW) > Is that a scene-wide global thing?

Currently, it's always on and acts depending on context and what's 
defined in each context. There isn't yet a way to configure with the 
feature off as there is with no lower case identifier checking - which 
is on by default in yuqk.

I think you're right, I need to go work on that configuration option 
before releasing R15. We should be able to create executable(s) with the 
checking off.

As for users switching the checking on and off on the fly... I think, 
such control runs counter to the aim of the constant-ness feature itself.

---
(ingo, jr, et al)

I realize there is a fair bit of _xyz parameter and identifier usage. 
It's in a lot of my own stuff too. Much of that will break - sometimes 
while pointing out existing exposures too. I haven't played enough to 
have a feel for the level of pain.

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_', ?)

---
(jr)

Remember yuqk reduced the functionality of the 'optional' keyword to 
just macro parameters due bugs and that when I really looked at broader 
use, I found a new world space for confusing, extremely difficult to 
debug, SDL bugs.

---

The larger view is the yuqk fork is breaking compatibility with official 
POV-Ray releases.

I don't do it lightly because I want to be able to run scenes aimed at 
official releases too, but breakage is unavoidable given I want to 
address certain bugs, features and deficiencies.

Bill P.


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.

Post a reply to this message

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

> > > I'm thinking a keyword modifier would be more flexible than a directive,
> > > for example:
> > >
> > >   #declare const GlobalVal = 12345;
> > >   #local const LocalVal = 54321;
>
> "modifier", yes.  +1.



>
> > Hmmm.   Yes, but maybe no?
> > Why not just have another separate type of declaration?
>
> the keyword modifier, more often than not I think, would be in close proximity
> to the variable where/when it's used.  an advantage.

In the absence of a concrete example, I'm wondering how the modifier would be
"more flexible", and what "close proximity to the variable where/when it's
used." means.

> > ...
> > So maybe #constant can ONLY be changed by specifically using another #constant
> > directive.
>
> if a variable's value can/will change "at runtime", #constant would simply be
> misleading.

Sort of.  I think the underlying idea is that it's not forever immutable, but
protected from unintentional and silent reassignment of it's value.

What about #protected?
It could be like function {}, where once declared, the parser throws an
(intelligible) error unless it's #undef'd before redeclaring.

The trick is balancing ease-of-coding with good coding practices, and new-user
friendly syntax so that we don't further steepen the learning curve.


> maybe "4.x" could have a revamped "SDL 2.0", with more "introspection" tools, so
> we can write better, "type safe" code.

Well YES.  Those sorts of things have long been wanted.
Camera location keyword/identifiers that would function like image_height, etc.
Identifier typing, especially for use in #read.
Differentiating things like vectors of different sizes, floats, etc.
View frustum coordinates or an internally defined 3D view frustum (maybe an
internal function that takes a length for the direction vector) that one can do
inside () tests with.

What really needs to be done is to draw a "map" of what we have coupled with
what we'd like to see.  That would function as a brainstorming vehicle, and a
to-do list.

Macros that people have written over the decades could be used as inspiration,
and I'm sure there are code libraries and things on GitHub, etc that have actual
c++ code or whatever language 4.x will be written in.


- BW

Post a reply to this message

On 6/28/24 01:13, ingo wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> 
> #macro Add(_immuInt, otherInt)
> ......
> #end
> 
> #declare Res = Add(99,1)
> 
> #declare _immu = 99;
> 
> #declare Res = Add(_immu, 1)
> 
> In the second use of the macro, would it be required that the 'referenced' value
> is also declared immutable?
> 
> ingo
> 

If I'm understanding you, no with respect to the macro, identifier pass 
by reference issue.

As long as you have _immuInt as the first macro Add() parameter name, 
the call can be Add(_immu,1) or Add(Res,1) and neither _immu or Res can 
be changed by any #local or #declare use of _immuInt inside the macro.

That said, the Res identifier is not protected from someone writing:

     #declare Res = 42;

inside the macro while  	

     #declare _immu = 42;

will be illegal inside the Add() macro. So, it's not necessary the _ 
prefix immutability be indicated in both the macro parameter and more 
global calling space - but it is a good idea, if you want protection 
from someone making more global changes from within the macro.

Related. The hole in the prefix based constant-ness is that it is NOT 
propagated into macros called. For example,

#macro Add(V1,V2)
     #local V1 = V1+V2;
     V1
#end

    #declare _immu = 42;
    #declare Val99 = Add(_immu,1);

will still result in the _immu getting clobbered. The best practice 
would be to always use macro parameter names with the _ prefix - unless 
you are truly aiming to change identifiers by reference inside the 
macro.

Bill P.

Post a reply to this message

On 6/28/24 00:47, Cousin Ricky wrote:

>> Release R15 of the yuqk fork has an implementation supporting constant
>> identifiers / macro parameters. They are indicated by using a leading
>> '_' character in the name.

    Mmmm, this can break some of my code /o\

> I also agree with Ingo: a keyword or directive would be better, such as:
> 
>    #const MagicNumber = 12345;

    [like]

-- 
+---------------------------------------------------------------------+
|          https://tube.interhacker.space/a/tth/video-channels        |
+---------------------------------------------------------------------+

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > > > [Cousin Ricky]
> > > > I'm thinking a keyword modifier would be more flexible than a directive,
> > > > for example:
> > > >
> > > >   #declare const GlobalVal = 12345;
> > > >   #local const LocalVal = 54321;
> >
> > "modifier", yes.  +1.
>
> > > Why not just have another separate type of declaration?
> >
> > the keyword modifier, more often than not I think, would be in close proximity
> > to the variable where/when it's used.  an advantage.
>
> In the absence of a concrete example, I'm wondering how the modifier would be
> "more flexible", and what "close proximity to the variable where/when it's
> used." means.

the "close proximity" thing is shown in CR's suggestion, note the 'const'
immediately in front of the variable in question.

"flexible", for instance, a (say) '#constant' directive alone and the macro
definition would still offer no "visual clues" wrt the arguments also could not
be used in expressions either.

(and remember, I'm no "language designer" either :-))


> > if a variable's value can/will change "at runtime", #constant would simply be
> > misleading.
> Sort of.  I think the underlying idea is that it's not forever immutable, but
> protected from unintentional and silent reassignment of it's value.
> What about #protected?
> It could be like function {}, where once declared, the parser throws an
> (intelligible) error unless it's #undef'd before redeclaring.

see reply to WFP.


> The trick is balancing ease-of-coding with good coding practices, and new-user
> friendly syntax so that we don't further steepen the learning curve.
>
> > maybe "4.x" could have a revamped "SDL 2.0", with more "introspection" tools, so
> > we can write better, "type safe" code.
>
> Well YES.  Those sorts of things have long been wanted. ...
> What really needs to be done is to draw a "map" of what we have coupled with
> what we'd like to see.  That would function as a brainstorming vehicle, and a
> to-do list.

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


regards, jr.

Post a reply to this message

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".


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


regards, jr.

Post a reply to this message

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)

"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

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
'crow' earlier this year has two M.2 "drives" -- 1.5T total, not even £100)

common access will be the "bug bear" imo.


regards, jr.

Post a reply to this message

"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

"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

"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'

"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

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

"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

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