Le 06/10/2018 à 19:39, Le_Forgeron a écrit :
> Le 06/10/2018 à 12:04, William F Pokorny a écrit :
> 
>> Glad to hear you are making progress.
>>
> 
> And at the current state, I learn that libsdl (1.2 and 2) is not thread
> friendly, it wants (nah, requires) that the thread that make the display
> and pull event to be the MAIN thread (and not another child, even if
> alone to make the calls)...
> 
> But it's working with libsdl2. As a kludge so far.
> 

Now integrating... and the more I know libsdl & libsdl2, the more I hate
them.

I was hoping to have both kind of display available, when both are
installed, and selecting the one which is present when one only is
there, even allowing the user to select explicitly amongst SDL, SDL2, or
text.

They made incompatible API, on purpose they said... so it might have
been possible.

But :
* their include files define the same macro and define, but do not use
the same protection mechanism (that part, I can handle more or less, not
elegant, but doable)
* they kept some identical function interface, including SDL_Init() !!
which means the first linked library initialize its internal structure
and blocks the initialization for the second library, and without
initialized structure, other calls crash.

So back to the blue-print, to make a choice between SDL2 and SDL when
both are present... and maybe restoring the raw X11 port, updated for
the new rendering mode of block, that one could be safe to live in
parallel with SDL(1/2). [should I nickname SDL Ranma ? maybe, as you can
only have one at the same time, but at least Ranma 1/2 is a funny anime,
and I like Ranma, not SDL)


Given the added value of SDL2 vs SDL (the title of the window is set and
updated on pause with SDL2), the hierarchy seems obvious when both are
available.
(yet, have to allow --without-..  to allow user to force the choice)

See you next week.

Post a reply to this message

Am 08.10.2018 um 22:16 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> Am 08.10.2018 um 21:33 schrieb jr:
>>>> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
>>>> a single code and library.
>>> given the threads issue you mentioned, maybe a different library altogether?  > >
I think Tk would "fit the bill" i
> n many respects.
>>
>> Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
>> an abomination, a Frankensteinian monstrosity.
> 
> lol.  (that sounds almost like .. allergic)
> 
> well I can't "speak" C++ so really cannot comment.  as component in a C program
> though, Tcl (and Tk) are pretty straightforward wrt using.  there are of course
> "problems", like (n)curses and Tcl wrangling over who controls the std* streams,
> otoh, Tk (with Tcl, Perl, whatever) runs on all platforms.  (I'd love to know
> though what makes it "monsterous").

The C++/Tk authors boast that their library pretty much preserves the
syntax familiar from Tcl/Tk.

The Tcl syntax is /very/ different from common C/C++, and to achieve
this feat they used some features of the C++ language in manners that
would make every sane C++ programmer's skin crawl.


C++/Tk is, in every sense, a joke takem too far.


I didn't even know C bindings for Tk existed; maybe they are more
faithful to the target language.


I'm not sure how Tcl as a component in a C program would look like.
After all, last time I checked, Tcl is a language, not a library.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 08.10.2018 um 22:16 schrieb jr:
> >> I think Tk would "fit the bill" in many respects.
> >> Don't come anywhere /near/ the POV-Ray code with C++/Tk!  ...
> > I'd love to know though what makes it "monsterous").

> The C++/Tk authors boast that their library pretty much preserves the
> syntax familiar from Tcl/Tk.

this is the first time I have seen "C++/Tk" juxtaposed.

afaik, the only thing (Tcl/)Tk and C++ have in common is the (approximate) year
of when development began; Tcl turned 30 last year.

> The Tcl syntax is /very/ different from common C/C++, and to achieve
> this feat they used some features of the C++ language in manners that
> would make every sane C++ programmer's skin crawl.

and it does not make sense (to me, at any rate).  the whole "idea" is either of
two deployment scenarios:
a) you have some kind of interpreter/shell and provide applications as scripts,
perhaps supported by custom shared libs.
b) you integrate one or more interpreters in your own, usually C, code, and
provide part(s) of the application functionality as scripts (built-ins or user
supplied, whatever).

there's literally no point[*] in the exercise you described.

[*] again, just me.

> C++/Tk is, in every sense, a joke takem too far.

it does sound a little .. perverted.

> I didn't even know C bindings for Tk existed; maybe they are more
> faithful to the target language.

it's how it (Tcl) started.  as a C library to provide a "tool control language",
to drive other command-line apps.  Tk was (so I read) an effort to build on
Apple's HyperCard concept(s) but constrained by need to be modular.

the introduction to the first edition of the "Tcl and the Tk Toolkit" book by
*the man* John Ousterhout (Addison-Wesley Publ.) makes excellent reading.

alternatively, reading
https://en.wikipedia.org/wiki/Tcl#Interfacing_with_other_languages
followed by
https://en.wikipedia.org/wiki/Tcl#Syntax_and_fundamental_semantics
gives an ok outline.

> I'm not sure how Tcl as a component in a C program would look like.
> After all, last time I checked, Tcl is a language, not a library.

a really sharp language lawyer might argue it isn't even a language - as such,
more a set of (12) rules for parsing + substituting strings (EIAS =="everything
is a string").  Tcl has no reserved "keywords", any and all commands can be
renamed (or deleted).

(as an analogy, think of each Tcl command as a separate "program", each taking
one or more argument "words" and returning one result (perhaps empty))

as component of a C (or other compiled) application, it provides access to
scripting via one or more interpreters you create; and has "goodies"
(conveniences?), like easy hash tables etc.


regards, jr.

Post a reply to this message

Am 13.10.2018 um 19:01 schrieb jr:

>> The Tcl syntax is /very/ different from common C/C++, and to achieve
>> this feat they used some features of the C++ language in manners that
>> would make every sane C++ programmer's skin crawl.
> 
> and it does not make sense (to me, at any rate).  the whole "idea" is either of
> two deployment scenarios:
> a) you have some kind of interpreter/shell and provide applications as scripts,
> perhaps supported by custom shared libs.
> b) you integrate one or more interpreters in your own, usually C, code, and
> provide part(s) of the application functionality as scripts (built-ins or user
> supplied, whatever).

Well, interfacing C++ to Tk (the library providing the GUI widgets)
isn't so stupid. Might be an easy way to create a portable GUI. (Though
I guess more modern frameworks like Qt make it even easier.)

Shoehorning the Tcl syntax into C++, now that's pure madness of
Lovecraftian proportions, as we apparently both agree.

But it's fascinating that they get away without a parser. Presumably,
stuff like

    button(".b") -text("Say Hello") -command(hello);
    pack(".b") -padx(20) -pady(6);

works because they co-opt the arithmetic operator `-` for a totally
different purpose that has nothing to do with arithmetics at all.

>> I didn't even know C bindings for Tk existed; maybe they are more
>> faithful to the target language.
> 
> it's how it (Tcl) started.  as a C library to provide a "tool control language",
> to drive other command-line apps.  Tk was (so I read) an effort to build on
> Apple's HyperCard concept(s) but constrained by need to be modular.

Don't confuse the two. Tcl is an iterpreted language. Tk is a library
originally written for Tcl.

When I say C bindings for Tk, I mean a direct interface from C to the Tk
library, without having to use the Tcl interpreter as an intermediate layer.


>> I'm not sure how Tcl as a component in a C program would look like.
>> After all, last time I checked, Tcl is a language, not a library.
> 
> a really sharp language lawyer might argue it isn't even a language - as such,
> more a set of (12) rules for parsing + substituting strings (EIAS =="everything
> is a string").  Tcl has no reserved "keywords", any and all commands can be
> renamed (or deleted).
> 
> (as an analogy, think of each Tcl command as a separate "program", each taking
> one or more argument "words" and returning one result (perhaps empty))

That's what I always do. To me, Tcl is a shell-ish scripting language.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Well, interfacing C++ to Tk (the library providing the GUI widgets)
> isn't so stupid. Might be an easy way to create a portable GUI. (Though
> I guess more modern frameworks like Qt make it even easier.)
>
> Shoehorning the Tcl syntax into C++, now that's pure madness of
> Lovecraftian proportions, as we apparently both agree.
>
> But it's fascinating that they get away without a parser. Presumably,
> stuff like
>
>     button(".b") -text("Say Hello") -command(hello);
>     pack(".b") -padx(20) -pady(6);
>
> works because they co-opt the arithmetic operator `-` for a totally
> different purpose that has nothing to do with arithmetics at all.

replace the parentheses with whitespace and you have two complete (well-formed,
I'd say) commands.  still, weird.


> >> I didn't even know C bindings for Tk existed; maybe they are more
> >> faithful to the target language.
> >
> > it's how it (Tcl) started.  as a C library to provide a "tool control language",
> > to drive other command-line apps.  Tk was (so I read) an effort to build on
> > Apple's HyperCard concept(s) but constrained by need to be modular.
>
> Don't confuse the two. Tcl is an iterpreted language.

s/is/was/  :-)

byte-compiles.  quite a number of years now.


> Tk is a library
> originally written for Tcl.

yes.


> When I say C bindings for Tk, I mean a direct interface from C to the Tk
> library, without having to use the Tcl interpreter as an intermediate layer.

have not done this myself but expect it to be a straightforward as using Tcl.
(after all, developed by the same people)


> >> I'm not sure how Tcl as a component in a C program would look like.
> >> After all, last time I checked, Tcl is a language, not a library.
> >
> > a really sharp language lawyer might argue it isn't even a language - as such,
> > more a set of (12) rules for parsing + substituting strings (EIAS =="everything
> > is a string").  Tcl has no reserved "keywords", any and all commands can be
> > renamed (or deleted).
> >
> > (as an analogy, think of each Tcl command as a separate "program", each taking
> > one or more argument "words" and returning one result (perhaps empty))
>
> That's what I always do. To me, Tcl is a shell-ish scripting language.

nor an uncommon view, I guess.   the simple syntax certainly leads some to
equate that with simple language.


regards, jr.

Post a reply to this message

typos + poor wording.  </sigh>

"jr" <cre### [at] gmailcom> wrote:
> > When I say C bindings for Tk, I mean a direct interface from C to the Tk
> > library, without having to use the Tcl interpreter as an intermediate layer.
>
> have not done this myself but expect it to be a straightforward as using Tcl.
> (after all, developed by the same people)

as straightforward as.  meant when linking to (Tcl) library, note that a subset
of functions (like memory allocator) can be used without an interpreter.


> > That's what I always do. To me, Tcl is a shell-ish scripting language.
>
> nor an uncommon view, I guess.   the simple syntax certainly leads some to
> equate that with simple language.

not, not nor.  :-)


regards, jr.

Post a reply to this message

Le 10/10/2018 à 22:35, Le_Forgeron a écrit :
> See you next week.
> 

Some progress, even if I'm not yet very happy:

https://github.com/LeForgeron/povray/tree/unix/display-window

There is LibSDL2 port (exclusive for linkage with LibSDL1.2), as well as
a basic X11 (without alpha, as alpha is not handle by X11 core).

The same binary can be used to choose the X11 or libsdl via command
switch -y (2 for X11, 3 & 4 for libsdl, 1 for text), when more than one
is detected. (-y is also --preview )

X11 has an icon,  something lost in SDL port.

I got some inspiration (a lot ?) from 3.1 and 3.6, but I'm not yet sure
it is a good idea to disable the destroy window (well, intercept it, but
it get ignored). More tests to do.

The X11 display is from DISPLAY variable, so far so fine. But not yet
able to get inserted in existing window.

There was a lot of luxury in 3.6, and I just went for a basic true color
display. I have also doubt about exposure events, as there is a backing
store. (Just glad to have know that iconification dismissed backing
store, so Map event must be handled when restoring from iconic)

On animation, the previous image is kept but darkened as new background.

Post a reply to this message

Attachments:
Download 'povx11.png' (130 KB)

Preview of image 'povx11.png'

On 10/16/2018 05:54 PM, Le_Forgeron wrote:

> 
> On animation, the previous image is kept but darkened as new background.
> 

I like that.

That is an interesting render pattern in your sample image.  Which is that?

-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

Le 18/10/2018 à 00:01, dick balaska a écrit :
> On 10/16/2018 05:54 PM, Le_Forgeron wrote:
> 
>>
>> On animation, the previous image is kept but darkened as new background.
>>
> 
> I like that.
> 
> That is an interesting render pattern in your sample image.  Which is that?
> 

Render_Block_Size=16
Render_Block_Step=3
Render_Pattern=4

with 12 threads, and 256 as height & width.

Post a reply to this message

On 10/16/18 5:54 PM, Le_Forgeron wrote:
> Le 10/10/2018 à 22:35, Le_Forgeron a écrit :
...
> 
> There is LibSDL2 port (exclusive for linkage with LibSDL1.2), as well as
> a basic X11 (without alpha, as alpha is not handle by X11 core).
> 
> The same binary can be used to choose the X11 or libsdl via command
> switch -y (2 for X11, 3 & 4 for libsdl, 1 for text), when more than one
> is detected. (-y is also --preview )
> 
...
> 

Playing some with your current hgpovray38 (45eb09ed7) with the thought 
of creating a re-based branch of your windowing changes I can merge into 
my version of POV-Ray.

Issue 1)
I can get an x11 window and a sdl2 window, but not an sdl window though 
it looks like 'make' created and linked x11, sdl and sdl2. The options 
which seemed to work were -y | --preview [x11 | sdl | text]. Is your 
intention not to enable 'sdl1.2' if sdl2 is present or all 4 options as 
it seemed to me you were saying above?

Issue 2)
I'm also attaching an image from the x11 option. I three times got 
something like it where one block didn't update. On the first two 
POV-Ray core dumped on closing the window/program exit. On the last - 
for the attached image - POV-Ray closed the display (used +p) on 
detecting but the POV-Ray process itself didn't exit. Wasn't burning any 
CPU, it was just hung and I had to use the kill command from the command 
line.

If I get some time next week I'll see if I can a debug compile to hang, 
crash or both for more informatino. I had no trouble with SDL2 windows.
Ubunut 18.04 - same set up as you as far as I know.

Aside: Ignore the image's *_segfault.png suffix. I named it thinking 
POV-Ray would crash on exit as had the previous two cases, but then it 
hung instead.

Issue 3)
The x11 option is opening the preview on the screen where the command is 
issued. The sdl2 option seems to always be opening on the primary 
screen. Not dug any here though so perhaps something my screen dual 
screen set up. The current 3.8 master follows your x11 preview screen 
behavior in opening on the screen where the command was issued.

Bill P.

Post a reply to this message

Attachments:
Download 'x11_segfault.png' (53 KB)

Preview of image 'x11_segfault.png'