hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> It could be one executable, but that's some work.  (Two vfe/frontends,
> parse a command line, don't start the Qt loop). I can easily whip of a
> copy of the current unix povray-3.8 but built with qmake.  Plus, even if
> I don't start the gui, it's still linked to, and will load all of that
> unused Qt graphics baggage.

out of interest, without gui, what are the differences to "stock" povray?

btw, installed Qt5 but hit another snag with the qtpovray build.  apparently,
(q)make does not pick up the QT5DIR environment variable.  when make enters the
'qt/gui' directory, compilation fails with "does not name a type" error(s); it's
not using the qt5 include files (in four of the -I switches).


regards, jr.

Post a reply to this message

On 06/26/2018 05:45 PM, jr wrote:
> hi,
> 
> dick balaska <dic### [at] buckosoftcom> wrote:
>> It could be one executable, but that's some work.  (Two vfe/frontends,
>> parse a command line, don't start the Qt loop). I can easily whip of a
>> copy of the current unix povray-3.8 but built with qmake.  Plus, even if
>> I don't start the gui, it's still linked to, and will load all of that
>> unused Qt graphics baggage.
> 
> out of interest, without gui, what are the differences to "stock" povray?

I should be equivalent to povray-3.8.0-alpha-something. My last merge 
was from the release/v3.8.0 branch on 2017-12-02.
povray on unix is built with autoconf/make/g++.
qtpovray on unix is built with qmake/make/g++.
If I did my job well, it will run exactly the same.

> 
> btw, installed Qt5 but hit another snag with the qtpovray build.  apparently,
> (q)make does not pick up the QT5DIR environment variable.  when make enters the
> 'qt/gui' directory, compilation fails with "does not name a type" error(s); it's
> not using the qt5 include files (in four of the -I switches).
> 

Try
$ qmake -qt=qt5 -r
or
$ export QT_SELECT=qt5
$ qmake -r

Ref:
https://unix.stackexchange.com/questions/116254/how-do-i-change-which-version-of-qt-is-used-for-qmake

BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu 
18.  I've thought about spinning up a Slackware 14.1 because of you. :)

> 
> regards, jr.
> 
> 
> 


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > out of interest, without gui, what are the differences to "stock" povray?
> I should be equivalent to povray-3.8.0-alpha-something. ...

ok.

> > btw, installed Qt5 but hit another snag with the qtpovray build.  ...
> Try
> $ qmake -qt=qt5 -r
> or
> $ export QT_SELECT=qt5
> $ qmake -r
> Ref:
>
https://unix.stackexchange.com/questions/116254/how-do-i-change-which-version-of-qt-is-used-for-qmake

that link helped, the '--version' providing the clue.  /usr/bin/qmake is a
symbolic link.  :-) installation of Qt5 left the existing link alone, easily
remedied.  and leading to another problem.  sorry.

Script started on Wed 27 Jun 2018 11:33:46 BST
jr@crow:13:qtpovray$ make
cd qt/libpovray/ && ( test -e Makefile || /usr/bin/qmake
/tmp/B/qtpovray/qt/libpovray/libpovray.pro -o Makefile ) && make -f Makefile
make[1]: Entering directory `/tmp/B/qtpovray/qt/libpovray'

runs ok until:

g++ -c -pipe -O2 -march=native -mtune=native -fPIC -std=gnu++11 -Wall -W
-D_REENTRANT -fPIC -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_WIDGETS_LIB
-DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../vfe -I../vfe -I../libpovray -I../platform
-isystem /usr/include/qt5 -isystem /usr/include/qt5/QtWidgets -isystem
/usr/include/qt5/QtGui -isystem /usr/include/qt5/QtCore -I. -I.
-I/usr/lib64/qt5/mkspecs/linux-g++ -o codeeditor.o editor/codeeditor.cpp
editor/codeeditor.cpp: In member function ‘void
CodeEditor::configure(PreferenceData*)’:
editor/codeeditor.cpp:112:8: error: ‘class CodeEditor’ has no member named
‘setTabStopDistance’
  this->setTabStopDistance(fm.width(spaces));
        ^
make[1]: *** [codeeditor.o] Error 1
make[1]: Leaving directory `/tmp/B/qtpovray/qt/gui'
make: *** [sub-qt-gui-make_first-ordered] Error 2
jr@crow:14:qtpovray$

the library version is 5.7.1.


> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)

:-)  maybe that's a subconscious .. yearning for the old days.  ;-)

if you do make it 14.2 though, which most use.  apparently, 15.0 is a
possibility for later this year.


regards, jr.

Post a reply to this message

On 06/27/2018 01:00 PM, jr wrote:
> hi,

> editor/codeeditor.cpp:112:8: error: ‘class CodeEditor’ has no member named
> ‘setTabStopDistance’
>    this->setTabStopDistance(fm.width(spaces));
>          ^

Sorry about that. I actually fixed that (debian defaults to an older 
"official" version of Qt) but I didn't push the changes back to github.
https://github.com/dickbalaska/qtpovray/commit/d70eede7700cbde40cbdbd6347a4a50ef85763a2

Try it now.

Also note the repo changed names.

git clone https://github.com/dickbalaska/qtpovray.git
cd qtpovray
git checkout qtpovray
qmake
make -j4
qt/gui/qtpovray        # run the executable


 >> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
 >> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)
 >
 > :-)  maybe that's a subconscious .. yearning for the old days.  ;-)

Yeah, I miss working for hours to get an integrated apache/php/ssl chain
(or postfix/dovecot/ssl).  Typing "sudo apt upgrade" is too easy.
I stuck with slackware for so long because, loyalty, and because I 
wanted to be more intimate with those tools.  These days, I just want it 
to work. :)

 >
 > if you do make it 14.2 though, which most use.  apparently, 15.0 is a
 > possibility for later this year.
 >

I thought of that. But my google says 14.2 uses qt-5.6.1 (or 5.7.1 or 
5.9.5)  The main reason for the exercise would be to build with qt-4.8 .

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > editor/codeeditor.cpp:112:8: error: ‘class CodeEditor’ has no member > Sorry
about that. I actually fixed that 
(debian defaults to an older
> "official" version of Qt) but I didn't push the changes back to github.
> Try it now.
> Also note the repo changed names.
>
> git clone https://github.com/dickbalaska/qtpovray.git
> cd qtpovray
> git checkout qtpovray
> qmake
> make -j4

thank you, both for the whole thing + the renaming.
now works as expected.

> qt/gui/qtpovray        # run the executable

ah, yes.  another problem, afraid to say..

start 'qtpovray', open a scene file, looks ok in editor, click the green arrow,
and:

  chdir:  /home/jr/wip/pov/media
  command:

appears in Consoles.POV-Ray box, and the following is appended to the Xserver's
log:

[12:47:59.570] WARN unhandled message: command: "stream fatal " text: "No input
file provided" ((null):0)
[12:47:59.570] WARN ErrorExit:  "No input file provided" ((null):0)

no other, discernable activity.  [raised eyebrow emoji, if I knew it]

from the 'qtpov.ini':

[General]
recentWorkspaces=/home/jr/.cache/qtpovray/b.pws

[EditorColors]

[Keys]

[Preferences]
PovrayExecutable=/usr/local/bin/povray380a
PovrayIncludes=/usr/local/share/povray-3.8/include
PovrayInsertMenu=


no idea what a "PovrayInsertMenu" is, is it needed?

>  >> BTW, I am running two VMs for testing right now, Ubuntu 16 and Ubuntu
>  >> 18.  I've thought about spinning up a Slackware 14.1 because of you. :)
>  >
>  > :-)  maybe that's a subconscious .. yearning for the old days.  ;-)
>
> Yeah, I miss working for hours to get an integrated apache/php/ssl chain
> (or postfix/dovecot/ssl).  Typing "sudo apt upgrade" is too easy.

</grin>

> I stuck with slackware for so long because, loyalty, and because I
> wanted to be more intimate with those tools.  These days, I just want it
> to work. :)
>  > if you do make it 14.2 though, which most use.  apparently, 15.0 is a
>  > possibility for later this year.
> I thought of that. But my google says 14.2 uses qt-5.6.1 (or 5.7.1 or
> 5.9.5)  The main reason for the exercise would be to build with qt-4.8 .

ok.  I'll be happy to test building here should you decide to go for it


regards, jr.

Post a reply to this message

On 06/28/2018 12:39 PM, jr wrote:
> hi,

> 
>> qt/gui/qtpovray        # run the executable
> 
> ah, yes.  another problem, afraid to say..
> 
> start 'qtpovray',

Well that's progress!

> open a scene file, looks ok in editor, click the green arrow,
> and:
> 
>    chdir:  /home/jr/wip/pov/media
>    command:
> 
> appears in Consoles.POV-Ray box, and the following is appended to the Xserver's
> log:
> 
> [12:47:59.570] WARN unhandled message: command: "stream fatal " text: "No input
> file provided" ((null):0)
> [12:47:59.570] WARN ErrorExit:  "No input file provided" ((null):0)
> 
> no other, discernable activity.  [raised eyebrow emoji, if I knew it]
> 

Although you may be looking at the file in the editor, you haven't 
selected it for rendering. (No input file provided).
Try right-click on the filename in the Resources view and "Select for 
Render"

Weird my tutorial fails to mention this step.
http://www.buckosoft.com/qtpovray/tutorial/

I am concerned in your report that the "No input file provided" message 
did not appear in the Consoles.POV-Ray box. That's a bug.

> from the 'qtpov.ini':
> 
> [General]
> recentWorkspaces=/home/jr/.cache/qtpovray/b.pws
> 
> [EditorColors]
> 
> [Keys]
> 
> [Preferences]
> PovrayExecutable=/usr/local/bin/povray380a
> PovrayIncludes=/usr/local/share/povray-3.8/include
> PovrayInsertMenu=
> 
> 
> no idea what a "PovrayInsertMenu" is, is it needed?

Not needed, but a cool feature. It is adopted from the POV-Ray for 
Windows insert menu. Basically it is a pile of code snippets with 
preview graphics that you can insert into your SDL.
http://www.buckosoft.com/qtpovray/insertText/

 > PovrayExecutable=/usr/local/bin/povray380a

This line is dead. It is left over from the websockets edition and is 
unused.



-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> Although you may be looking at the file in the editor, you haven't
> selected it for rendering. (No input file provided).
> Try right-click on the filename in the Resources view and "Select for
> Render"

will do.  how does qtpovray invoke povray?  is the name hardwired?  I have only
executables named 'povrayNN*', a symlink would be not as convenient for my
setup, the ("dead") .ini file option looks so much better.  would it be much
work to "resurrect" it?

> Weird my tutorial fails to mention this step.
> http://www.buckosoft.com/qtpovray/tutorial/
>
> I am concerned in your report that the "No input file provided" message
> did not appear in the Consoles.POV-Ray box. That's a bug.

</weak-sounding-hurrah>  :-)

> > no idea what a "PovrayInsertMenu" is, is it needed?
> Not needed, but a cool feature. It is adopted from the POV-Ray for
> Windows insert menu. Basically it is a pile of code snippets with
> preview graphics that you can insert into your SDL.
> http://www.buckosoft.com/qtpovray/insertText/

I'll look into this.  thanks.

>  > PovrayExecutable=/usr/local/bin/povray380a
> This line is dead. It is left over from the websockets edition and is
> unused.


regards ,jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> > Try right-click on the filename in the Resources view and "Select for
> > Render"
> will do.

success.  :-)

btw, is there a legit way to 'wget' the documentation part of your website?
convenience..

cheers.


regards, jr.

Post a reply to this message

hi,

how does one re-open the render view + Consoles widgets after they have been
closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.

happened because I rendered a static scene, clicked that editor tab shut, opened
another scene, then the associated ini, chose that for rendering.  however, the
view of the previous image remained, so I clicked it shut - only not to find a
way to reopen it.

btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
and I get:

xdg-open: file '/usr/share/qtpovray-3.8/scenes/index.htm' does not exist
xdg-open: file '/usr/share/qtpovray-3.8/html/index.html' does not exist

also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
per invocation.

[19:23:28.805] WARN
Unhandled PrintStatusChanged
 ((null):0)

[19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)

would like to read the tutorial etc, but, probably because I'm a bit dense at
times, the "compass" feature does not work for me, which "next" button?


regards, jr.

Post a reply to this message

On 06/28/2018 03:08 PM, jr wrote:
> hi,
> 
> how does one re-open the render view + Consoles widgets after they have been
> closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.

I think I can add the 'view' menu.  Currently, it is Qt magic. 
Right-click on one of the docking borders. That is, the "Resources" 
header or the "Consoles" header. It will give you a list of available 
windows to turn on and off.

> 
> btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
> and I get:
> 
> xdg-open: file '/usr/share/qtpovray-3.8/scenes/index.htm' does not exist
> xdg-open: file '/usr/share/qtpovray-3.8/html/index.html' does not exist

If you didn't install them, that's pretty much what you get.  I am going 
to dim those menu entries if they don't exist. And add a bit in the 
config dialog so you can point to wherever those directories live on 
your system.  I just added those two menus last night, having discovered 
the pretty awesome distribution/scenes directory (open that in firefox).

> 
> also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
> per invocation.
> 
> [19:23:28.805] WARN
> Unhandled PrintStatusChanged
>   ((null):0)

This is debug foo. I should remove it from production.  Basically povray 
is telling me something I'm ignoring.

> 
> [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
> resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)

This one is interesting.  Um, what it means is um ...
I would guess maybe it's trying to draw to one of the windows you closed 
(although Qt should be filtering that).

> 
> would like to read the tutorial etc, but, probably because I'm a bit dense at
> times, the "compass" feature does not work for me, which "next" button?

Last night I copied
http://www.buckosoft.com/qtpov/
to
http://www.buckosoft.com/qtpovray/

and didn't fix the database driven navigation.  (I needed the url for 
the debian package.) Use the first one and ignore the bits about a 
separate websockets executable, and everywhere else read "qtpovray" 
where it says "qtpov".
I am going to rework that so it can be included with the package.

> 
> 
> regards, jr.

Thanks for trying it out!



-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

On 06/28/2018 01:54 PM, jr wrote:
> hi,

> 
> will do.  how does qtpovray invoke povray?  is the name hardwired?  I have only
> executables named 'povrayNN*', a symlink would be not as convenient for my
> setup, the ("dead") .ini file option looks so much better.  would it be much
> work to "resurrect" it?

povray is built into qtpovray.  There is no need for a separate 
executable.  A symlink would be of no value because there is nothing to 
point to. ;)



-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > how does one re-open the render view + Consoles widgets after they have been
> > closed?  a GUI usually has a 'view' menu entry to toggle such panels on/off.
>
> I think I can add the 'view' menu.  Currently, it is Qt magic.
> Right-click on one of the docking borders. That is, the "Resources"
> header or the "Consoles" header. It will give you a list of available
> windows to turn on and off.

I tried switching all except 'main' off, then there seems to be no "docking
border"s.

> > btw, the 'help' and 'sample scenes' are not installed (did not "make install"),
> If you didn't install them, that's pretty much what you get.  I am going
> to dim those menu entries if they don't exist.

yes, or (as many do) a simple "ok" type dialog with message?

> And add a bit in the
> config dialog so you can point to wherever those directories live on
> your system.

sounds good.  more flexibility.

>  I just added those two menus last night, having discovered
> the pretty awesome distribution/scenes directory (open that in firefox).

I have those too, did them for povray 3.7.

> > also, many of the 'PrintStatusChanged' warnings, and one Xcb error, it seems,
> > per invocation.
> >
> > [19:23:28.805] WARN
> > Unhandled PrintStatusChanged
> >   ((null):0)
>
> This is debug foo. I should remove it from production.  Basically povray
> is telling me something I'm ignoring.

ok.

> > [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
> > resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)
>
> This one is interesting.  Um, what it means is um ...
> I would guess maybe it's trying to draw to one of the windows you closed
> (although Qt should be filtering that).

I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
existing .pws files).

> > would like to read the tutorial etc, but, probably because I'm a bit dense at
> > times, the "compass" feature does not work for me, which "next" button?
> Last night I copied
> http://www.buckosoft.com/qtpov/
> to
> http://www.buckosoft.com/qtpovray/
> and didn't fix the database driven navigation.  (I needed the url for
> the debian package.) Use the first one and ignore the bits about a
> separate websockets executable, and everywhere else read "qtpovray"
> where it says "qtpov".
> I am going to rework that so it can be included with the package.

cool.

> Thanks for trying it out!

soon you'll be pulling your hair out because I'll be nitpicking and flood you
with "feature requests".  :-)

speaking of which, the name of the current workspace (file) would be good to
have in the titlebar, or somewhere prominent.

(see, it's already started..  :-))


regards, jr.

Post a reply to this message

On 06/28/2018 05:50 PM, jr wrote:
> hi,

>>
>> I think I can add the 'view' menu.  Currently, it is Qt magic.
>> Right-click on one of the docking borders. That is, the "Resources"
>> header or the "Consoles" header. It will give you a list of available
>> windows to turn on and off.
> 
> I tried switching all except 'main' off, then there seems to be no "docking
> border"s.
> 

Hmm, yes I see. You're kind of screwed, eh?

The toolbar has a grabber on the left side. Try to right-click that, or 
someplace on the toolbar that's not a button.


> 
>>> [19:51:01.141] WARN QXcbConnection: XCB error: 3 (BadWindow), sequence: 2374,
>>> resource id: 8682978, major code: 40 (TranslateCoords), minor code: 0 ((null):0)
>>
>> This one is interesting.  Um, what it means is um ...
>> I would guess maybe it's trying to draw to one of the windows you closed
>> (although Qt should be filtering that).
> 
> I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
> existing .pws files).

Since this is something between Qt and X11, it would be helpful to know 
when this error^H^H warning occurred.  My X log just has a ton of 
"monitor on, monitor off".


> 
> soon you'll be pulling your hair out because I'll be nitpicking and flood you
> with "feature requests".  :-)
> 
> speaking of which, the name of the current workspace (file) would be good to
> have in the titlebar, or somewhere prominent.
> 
> (see, it's already started..  :-))

I guess I should open the github bug thingy.

> 
> 
> regards, jr.
> 
> 


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> >> I think I can add the 'view' menu.  Currently, it is Qt magic.
> > I tried switching all except 'main' off, then there seems to be no "docking
> > border"s.
> Hmm, yes I see. You're kind of screwed, eh?

didn't you mean "screwy"?  :-)

> The toolbar has a grabber on the left side. Try to right-click that, or
> someplace on the toolbar that's not a button.

either way, thanks, easy -- once one knows.

> >>> [19:51:01.141] WARN QXcbConnection: XCB error: ...
> >> This one is interesting.  Um, what it means is um ...
> >> I would guess maybe it's trying to draw to one of the windows you closed
> >> (although Qt should be filtering that).
> > I wonder then whether it's one of the small "ok" type dialogs on starting (w/out
> > existing .pws files).
> Since this is something between Qt and X11, it would be helpful to know
> when this error^H^H warning occurred.  My X log just has a ton of
> "monitor on, monitor off".

I understand.  will try and pay closer attention when I'll use/play with
'qtpovray'.

> > soon you'll be pulling your hair out because I'll be nitpicking and flood you
> > with "feature requests".  :-)
> >
> > speaking of which, the name of the current workspace (file) would be good to
> > have in the titlebar, or somewhere prominent.
> >
> > (see, it's already started..  :-))
>
> I guess I should open the github bug thingy.

I'll make it worth your while: whether checked or not, "large icons" is,
apparently, all that is on offer.  ;-)


regards, jr.

Post a reply to this message

I don't get git.
My last merge of povray was from master on 12/17/17.
At the time, source/base/version.h was reporting povray as version
3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"

I picked up that version number (and didn't really care).

In my head, I noticed a discrepancy when clipka suggested I call mine
v3.80.0 (why not 3.81.0 ?).

Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
most of the branches.

I just merged autobuild/alpha_v380.  In source/base/version.h I picked
up #define POV_RAY_PRERELEASE "alpha.9606898" and the copyright changed
from 2017 to 2018.
But, I still have
#define POV_RAY_PATCHLEVEL_INT      1
instead of
#define POV_RAY_PATCHLEVEL_INT      0
which is in the merged-from file.

Why?  I have not altered this, and if I had, I should get a conflict.
If makes me nervous for whatever other files I may not have picked up
changes on.

https://github.com/dickbalaska/qtpovray/commit/f0eb4228ecfe624e905fe04367a73d3cc514f8fa#diff-456b041bdd8c9f06ec0514302ebba61b
( https://tinyurl.com/y7t5hh8x )
-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Am 16.07.2018 um 10:44 schrieb dick balaska:

> My last merge of povray was from master on 12/17/17.
> At the time, source/base/version.h was reporting povray as version
> 3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"
> 
> I picked up that version number (and didn't really care).
> 
> In my head, I noticed a discrepancy when clipka suggested I call mine
> v3.80.0 (why not 3.81.0 ?).
> 
> Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
> most of the branches.

For the records, that was not a burp. Here's what had happened:

- What is now v3.8.0 (currently in alpha phase) was originally slated to
be released as v3.7.1, and as such had already reached beta phase (and,
for a few days, even RC phase) before being rebranded as v3.8.0.

- Upon reaching beta phase, v3.7.1 was branched off `master` so that
finalization of that version could happen in a separate branch
(`release/v3.7.1`), while the master branch could continue to be used
for adding new features. At that point, the master branch was bumped to
version number v3.7.2-alpha.

- When it was decided that v3.7.1 would be too different from v3.7.0, it
was re-branded v3.8.0.

- While v3.8.0 was put back into alpha stage, it was originally expected
that the version would quickly fast-forward to RC phase again. It was
therefore left in its own branch (though now renamed `release/v3.8.0`),
while the master branch was bumped to the next version number, v3.8.1.

- When it became obvious that v3.8.0-beta wasn't going to be just a few
days ahead, all the changes in the master branch (i.e. changes
originally slated for a later version) were also merged into v3.8.0, and
that version moved back into the master branch. (Technically this was
done by simply merging v3.8.0 into the master branch.)

Post a reply to this message

Am 16.07.2018 um 10:44 schrieb dick balaska:

> My last merge of povray was from master on 12/17/17.
> At the time, source/base/version.h was reporting povray as version
> 3.8.1-alpha as per a 12/2/17 clipka "Merge branch 'release v3.8.0'"
> 
> I picked up that version number (and didn't really care).
> 
> In my head, I noticed a discrepancy when clipka suggested I call mine
> v3.80.0 (why not 3.81.0 ?).
> 
> Now I see clipka fixed that burp on 12/10/17. 3.8.0 has bubbled through
> most of the branches.

"Most" is the keyword here.

> I just merged autobuild/alpha_v380.  In source/base/version.h I picked
> up #define POV_RAY_PRERELEASE "alpha.9606898" and the copyright changed
> from 2017 to 2018.
> But, I still have
> #define POV_RAY_PATCHLEVEL_INT      1
> instead of
> #define POV_RAY_PATCHLEVEL_INT      0
> which is in the merged-from file.
> 
> Why?  I have not altered this, and if I had, I should get a conflict.
> If makes me nervous for whatever other files I may not have picked up
> changes on.

Unfortunately, v3.8.0-alpha.9606898 was built just /before/ the merge of
`master` and `release/v3.8.0`.

This means your version number details are determined as follows:

- The _common base_ is the last common ancestor (including merges) of
`qtpovray` and `autobuild/alpha_v380`. That would be commit bb85b4fd
dated 2017-11-18, then on the `release/v3.8.0` branch. On that commit,
the version number details were as follows:

    #define POV_RAY_MAJOR_VERSION_INT   3
    #define POV_RAY_MINOR_VERSION_INT   8
    #define POV_RAY_REVISION_INT        0
    #define POV_RAY_PATCHLEVEL_INT      0
    #define POV_RAY_PRERELEASE          "alpha"

- One line of inheritance would be via the `master` branch and then
`qtpovray`, starting with the merge commit b3038c26 dated 2017-12-03.
While this commit leaves the version number unchanged /on the master
branch/, the commit /does/ constitute a version number change with
respect to the _common base_, changing the following:

    #define POV_RAY_REVISION_INT        1

- The second line of inheritance would be via `release/v3.8.0` and then
`autobuild/alpha_v380`. The only version number changes with respect to
the _common base_ in this line of inheritance are changes of the
prerelease ID, with the last such change being the following:

    #define POV_RAY_PRERELEASE          "alpha.9606898"

So you have one line of inheritance saying POV_RAY_REVISION_INT needs to
be changed to 1, and another line of inheritance saying
POV_RAY_PRERELEASE needs to be changed from "alpha" to "alpha.9606898".

Since the changes seem to be independent, no conflict is raised, leaving
you with version number v3.8.1-alpha.9606898.

Post a reply to this message

On 07/16/2018 08:57 AM, clipka wrote:

> while the master branch was bumped to the next version number, v3.8.1.

That makes sense.  I retract 'burp'.

(I had assumed [1] you changed 3.7.1 to 3.8.0 and changed the 7 to 8 and
forgot to change 1 to 0.)


[1] When you assume ...

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message