Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » [Proposal] The maintainer and the future of TURTLE package
Re: [Proposal] The maintainer and the future of TURTLE package [message #55947 is a reply to message #55946] Tue, 05 January 2021 19:05 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1133
Registered: December 2006
Senior Contributor
mirek wrote on Tue, 05 January 2021 12:00

Speaking of which: It would be great if your automated building infrastructure started scanning UppHub. Do you think it would be possible?

Theoretically, yes.
What do I need to do for that?


Regards,
Novo
Re: [Proposal] The maintainer and the future of TURTLE package [message #55948 is a reply to message #55947] Tue, 05 January 2021 20:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13038
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 05 January 2021 19:05
mirek wrote on Tue, 05 January 2021 12:00

Speaking of which: It would be great if your automated building infrastructure started scanning UppHub. Do you think it would be possible?

Theoretically, yes.
What do I need to do for that?

Preliminary: Start here:

https://github.com/ultimatepp/ultimatepp/blob/master/upphub. root

then scan through all lists, clone/pull nests, compile (or even test).

I will create some docs about the listings json format soon...

[Updated on: Tue, 05 January 2021 20:22]

Report message to a moderator

Re: [Proposal] The maintainer and the future of TURTLE package [message #55960 is a reply to message #54415] Thu, 07 January 2021 10:15 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Mirek,

If you have no objections, I'd like to mark the current version of Turtle package as "technical preview" until we implement a security/login mechanism.

Best regards,
Oblivion


Re: [Proposal] The maintainer and the future of TURTLE package [message #55963 is a reply to message #55960] Thu, 07 January 2021 13:40 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13038
Registered: November 2005
Ultimate Member
Oblivion wrote on Thu, 07 January 2021 10:15
Hello Mirek,

If you have no objections, I'd like to mark the current version of Turtle package as "technical preview" until we implement a security/login mechanism.

Best regards,
Oblivion


Sure.

Anyway, sorry for somewhat late reply, but are you sure you want to go there wrt login? I mean, originally I planned that login mechanism will be left to be implemented by client in some web langauge (or Skylark).
Re: [Proposal] The maintainer and the future of TURTLE package [message #55964 is a reply to message #55963] Thu, 07 January 2021 15:16 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Mirek,
Quote:
are you sure you want to go there wrt login? I mean, originally I planned that login mechanism will be left to be implemented by client in some web langauge (or Skylark).


The thing is I didn't know the original design decisions and the prospect for the Turtle package, until now. Smile
So I assumed that it is expected to be implemented. This is actually a good news and a reasonable approach.

I have no objections to less work on my side. Very Happy Thus what I'd like to do now is document the simple wire protocol and add a better description to README.

As a side note: I already implemented a proof-of-concept Turtle-protocol based VirtualGui/SshGui (as ssh2 sub-system, usingo our SSH package) that effectively solves the security/login problem for U++ remote frontend.
And implemented a simple TurtleCtrl prototype that works with both html/ws and this ssh2 backends.

Best regards,
Oblivion





Re: [Proposal] The maintainer and the future of TURTLE package [message #55965 is a reply to message #55964] Thu, 07 January 2021 15:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13038
Registered: November 2005
Ultimate Member
Quote:

As a side note: I already implemented a proof-of-concept Turtle-protocol based VirtualGui/SshGui (as ssh2 sub-system, usingo our SSH package) that effectively solves the security/login problem for U++ remote frontend.
And implemented a simple TurtleCtrl prototype that works with both html/ws and this ssh2 backends.


Sounds good. It is all yours now Smile

Mirek
Re: [Proposal] The maintainer and the future of TURTLE package [message #55993 is a reply to message #55948] Sun, 10 January 2021 05:28 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1133
Registered: December 2006
Senior Contributor
mirek wrote on Tue, 05 January 2021 14:22
Novo wrote on Tue, 05 January 2021 19:05
mirek wrote on Tue, 05 January 2021 12:00

Speaking of which: It would be great if your automated building infrastructure started scanning UppHub. Do you think it would be possible?

Theoretically, yes.
What do I need to do for that?

Preliminary: Start here:

https://github.com/ultimatepp/ultimatepp/blob/master/upphub. root

then scan through all lists, clone/pull nests, compile (or even test).

I will create some docs about the listings json format soon...


Initial version works.
I can read json file from internet, retrieve repo url, scan for *.upp files, and build them.
Unfortunately, the very first error I get with the package Urr is
undefined reference to `main'

I can read more settings from the json file, like to build a package or not, supported platforms and compilers.
In my own current configuration I manually support lists of packages for each platform. That includes U++.


Regards,
Novo
Re: [Proposal] The maintainer and the future of TURTLE package [message #55998 is a reply to message #55993] Sun, 10 January 2021 18:41 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1133
Registered: December 2006
Senior Contributor
Novo wrote on Sat, 09 January 2021 23:28

I can read more settings from the json file, like to build a package or not, supported platforms and compilers.

On second thought, I won't be able to pass configuration parameters from a json file, which I read on a master node, to a worker node, which is dynamically generating build steps.

This means that I can support only two modes:
1) All projects should be buildable on all platforms with all compilers.
2) I manually support lists of build steps.

1 is much easier to support.
2 is more realistic.


Regards,
Novo
Re: [Proposal] The maintainer and the future of TURTLE package [message #56004 is a reply to message #55998] Tue, 12 January 2021 03:14 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1133
Registered: December 2006
Senior Contributor
It would be great to add code below to packages Turtle and Skylark:
#ifdef flagMAIN
CONSOLE_APP_MAIN {
}
#endif

That would allow me to build repos Turtle and Skylark fully automatically.

TIA


Regards,
Novo
Re: [Proposal] The maintainer and the future of TURTLE package [message #56005 is a reply to message #56004] Tue, 12 January 2021 06:48 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Hello Novo,
Quote:
It would be great to add code below to packages Turtle and Skylark:


I have added the lines to Turtle/Init.cpp, please check.


Best regards,
Oblivion


Re: [Proposal] The maintainer and the future of TURTLE package [message #56006 is a reply to message #56005] Tue, 12 January 2021 07:15 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1133
Registered: December 2006
Senior Contributor
Oblivion wrote on Tue, 12 January 2021 00:48
Hello Novo,
Quote:
It would be great to add code below to packages Turtle and Skylark:


I have added the lines to Turtle/Init.cpp, please check.


Best regards,
Oblivion

Thanks! It would be great to do the same with Skylark.

I cannot build Turtle on Mac.
./umk .,/Users/ssg/dvlp/cpp/code/upp/git/uppsrc examples/WebHelloWorld CLANGcpp17 -bus
/Users/ssg/dvlp/cpp/code/upp/git/uppsrc/CtrlLib/CtrlUtil.h:57:7: error: redefinition of 'PrinterJob'
class PrinterJob {
      ^
/Users/ssg/dvlp/cpp/code/upp/git/uppsrc/VirtualGui/VirtualGui.h:109:7: note: previous definition is here
class PrinterJob { // Dummy only...
      ^


Regards,
Novo
Re: [Proposal] The maintainer and the future of TURTLE package [message #56007 is a reply to message #56006] Tue, 12 January 2021 09:03 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 827
Registered: August 2007
Experienced Contributor
Quote:
I cannot build Turtle on Mac.
./umk .,/Users/ssg/dvlp/cpp/code/upp/git/uppsrc examples/WebHelloWorld CLANGcpp17 -bus


Is your build system reading the *upp files? Turtle examples allow GUI/TURTLEGUI switching and it seems like the TURTLEGUI flag in the package configuration file is not getting activated. This flag should bring in the CtrlLib/Turtle packages in a mutually exclusive way.)

Maybe I should remove the switch from the reference examples. (Since these switches are already available to user, with project templates.)


Edit: I have removed the switch from the examples. Please check.


Best regards,
Oblivion


[Updated on: Tue, 12 January 2021 09:22]

Report message to a moderator

Re: [Proposal] The maintainer and the future of TURTLE package [message #56009 is a reply to message #56007] Tue, 12 January 2021 20:33 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1133
Registered: December 2006
Senior Contributor
Oblivion wrote on Tue, 12 January 2021 03:03

Edit: I have removed the switch from the examples. Please check.


Best regards,
Oblivion

It is still broken:
/Users/ssg/dvlp/cpp/code/upp/git/uppsrc/VirtualGui/VirtualGui.h:110:22: error: expected member name or ';' after declaration specifiers; 'nullptr' is a keyword in Objective-C++
        NilDraw             nil;
        ~~~~~~~             ^
/usr/include/objc/objc.h:106:16: note: expanded from macro 'nil'
#   define nil nullptr
               ^

This is a MacOS problem. Theoretically, it should be detected by an Upp build. But Upp build seems to be fine.


Regards,
Novo
Re: [Proposal] The maintainer and the future of TURTLE package [message #56010 is a reply to message #56007] Tue, 12 January 2021 20:38 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1133
Registered: December 2006
Senior Contributor
Oblivion wrote on Tue, 12 January 2021 03:03

Is your build system reading the *upp files?

Nope. I'm not parsing .upp files. I'm planning to make my own replacement of umk in the future, but this task has low priority.
Supporting of the build system is a full time job already.


Regards,
Novo
Re: [Proposal] The maintainer and the future of TURTLE package [message #56052 is a reply to message #56004] Tue, 19 January 2021 09:34 Go to previous message
mirek is currently offline  mirek
Messages: 13038
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 12 January 2021 03:14
It would be great to add code below to packages Turtle and Skylark:
#ifdef flagMAIN
CONSOLE_APP_MAIN {
}
#endif

That would allow me to build repos Turtle and Skylark fully automatically.

TIA


Is this a good idea?

I mean I understand you cannot compile without it, but in that case maybe you should just ignore non-main packages - compiling examples should do.

Or alternatively, you can detect non-main package and simply generate a project with empty CONSOLE_APP_MAIN and using the package you are testing.

Last alternative is to put something like above to the Core.

Putting it to every single package out there seems ugly.

Mirek
Previous Topic: Want to use CLANG with MSBT64 toolchain
Next Topic: Technology lab vs External resources
Goto Forum:
  


Current Time: Tue Jan 19 10:39:36 CET 2021

Total time taken to generate the page: 0.01578 seconds